SlideShare une entreprise Scribd logo
1  sur  102
Télécharger pour lire hors ligne
ROYAUME DU MAROC
*-*-*-*-*
HAUT COMMISSARIAT AU PLAN
*-*-*-*-*-*-*-*
INSTITUT NATIONAL
DE STATISTIQUE ET D’ECONOMIE APPLIQUEE
Projet de Fin d’Etudes
*****
N° 113
Préparé par : ZONGO Joel
SONMANDE Goulwindin Salif
Sous la direction de : Mlle. Rajaa SAIDI (INSEA)
M. Najib OURADI (BAM)
Soutenu publiquement comme exigence partielle en vue de l’obtention du
Diplôme d’Ingénieur d’Etat
Option : INFORMATIQUE
Devant le jury composé de :
M. A. HACHIMI ALAOUI (INSEA)
Mlle. Rajaa SAIDI (INSEA)
M. Najib OURADI (BAM)
Conception et Réalisation d’une application pour la
gestion de la flotte et de l’acheminement courrier
- 2 -
- 3 -
Résumé
Poste Maroc est une entreprise exerçant principalement dans trois métiers dont le pôle
courrier. Ce dernier occasionne des charges qui doivent être maitrisées surtout à la vue de la
baisse générale du volume de courriers échangés depuis ces dernières années. La réduction de
ces charges, majoritairement liées à l’acheminement des courriers, passe une maitrise de
l’information nécessitant la mise en place d’un système informatique.
C’est dans ce cadre que s’inscrit notre travail qui traite de la conception et la réalisation
d’une application de gestion de la flotte et de l’acheminement courrier. Nous étions amenés à
réaliser une application sous OpenERP capable de répondre aux besoins spécifiques. Couplée
à JasperReports, cette application devra permettre de générer des rapports PDF.
Compte tenu du type d’application à développer, nous avons opté pour la méthode de
développement SCRUM, au cours de laquelle nous avons dû subdiviser notre projet en fonction
des besoins métiers. Cela nous a permis d’effectuer une analyse de chaque besoin en profondeur
lors de la phase de modélisation. Pour ce qui est de la phase de réalisation, elle fut réalisé en
grande majorité grâce aux langages python et XML.
Mots clés : OpenERP, python, XML, Jasper Reports
- 4 -
Dédicaces
A mon père et à ma mère, Piga et Christine ZONGO,
qui malgré la distance, ont su trouver les mots justes
pour me soutenir tout au long de mon cursus. Aucune
dédicace ne saurait être assez éloquente pour exprimer
mon respect et ce que vous méritez pour les sacrifices
effectués à mon égard.
A mes très chères sœurs, pour tous nos moments
passés ensemble. Je vous dédie ce travail en vous
souhaitant un avenir radieux et plein de promesses.
A toute la grande famille, à mes amis, et à tous ceux
qui ont cru en moi, et qui me donne envie d’aller de
l’avant, je vous remercie tous. Votre soutien et vos
encouragements me donnent la force de continuer.
Joël ZONGO
- 5 -
Dédicaces
À ma chère mère
ma raison d’être, ma raison de vivre, la lanterne qui
éclaire mon chemin.
À mon cher père
en signe d’amour, de reconnaissance et de gratitude
pour tous les soutiens
et les sacrifices dont il a fait preuve à mon égard.
À mes chers frères et chères sœurs
Aucun mot, ni aucun signe ne pourront décrire votre
implication dans mon épanouissement.
À tous mes amis
En témoignage de l’amitié sincère et du soutien
inébranlable que vous m’avez apporté.
je dédie ce travail.
Salif SONMANDE
- 6 -
- 7 -
Remerciements
Nous tenons à remercier tous ceux qui nous ont soutenu tout au long de ce travail.
Pour commencer notre remercions d’abord les responsables de Barid Al Maghrib qui
ont bien voulu nous ouvrir leur porte et qui nous ont permis de disposer d’un cadre idéal de
travail.
Notre prochain remerciement à notre encadreur externe, Mr. Najib OURADI, direction
de la Division des Solutions et d’Améliorations Continues. Son écoute et sa disponibilité tout
au long du projet nous a été d’une aide précieuse.
Nous remercions également Mlle Rajaa SAIDI, professeur à l’Institut National
Statistiques et d’Economie Appliquées pour avoir accepté de nous encadrer et qui a contribué
grandement à la reussite du projet à travers ses différents conseils.
Nous ne saurions omettre dans nos remerciements tout le personnel de Barid Al Maghrib
et plus particulièrement à Mr ERRADI Yacine du service acheminement, et à Abdel SBIA de
la Direction de la Poste Numerique et Télécoms.
Pour finir, nous tenons à remercier le corps enseignant de l’INSEA pour l’enseignement
de qualité dont nous avons bénéficié ainsi que le le personnel administratif et tout ceux qui de
près ou de loin ont contribué au succès de ce projet.
- 8 -
Liste des abréviations
BAM : Barid Al Maghrib
EA: Enterprise Architect
ERP: Enterprise Resource Planning PAQ
SQL: Structured Query Language
UML: Unified Modeling Language
XML : Extensible Markup Language
PAQ : Plan d’Assurance Qualité
- 9 -
Liste des figures
Figure 1 : Organisation des acteurs du projet...................................................................................- 22 -
Figure 2 : Structure de la méthode SCRUM ......................................................................................- 24 -
Figure 3 : Déroulement des sprints ...................................................................................................- 24 -
Figure 4 : Diagramme de GANTT prévisionnel ..................................................................................- 27 -
Figure 5 : Diagramme de Gantt définitif............................................................................................- 28 -
Figure 6 : Diagramme des cas d'utilisation "site"..............................................................................- 43 -
Figure 7 : Diagramme de cas d'utilisation "région"...........................................................................- 45 -
Figure 8.: Diagramme de séquence pour le cas d’utilisation « s’authentifier »...............................- 47 -
Figure 9 : Diagramme de séquence pour le cas d’utilisation « Gérer les axes de transport »..........- 48 -
Figure 10 : Cas d'utilisation "siège"...................................................................................................- 49 -
Figure 11 : Cas d'utilisation "administrateur" ...................................................................................- 51 -
Figure 12 : Gestion des ordres de services........................................................................................- 53 -
Figure 13 : Gestion des dépêches......................................................................................................- 54 -
Figure 14 : Gestion du suivi des dépêches ........................................................................................- 55 -
Figure 15 : Gestion des ressources Humaines...................................................................................- 56 -
Figure 16 : Gestion du parc automobile............................................................................................- 57 -
Figure 17 : Logo OpenERP .................................................................................................................- 60 -
Figure 18 : Gestion sur OpenERP.......................................................................................................- 61 -
Figure 19 : Python .............................................................................................................................- 61 -
Figure 20 : PostgreSQL ......................................................................................................................- 62 -
Figure 21 : XML..................................................................................................................................- 63 -
Figure 22 : DIA ...................................................................................................................................- 63 -
Figure 23 : Acheminement : Besoins métiers....................................................................................- 65 -
Figure 24 : Modules existants ...........................................................................................................- 66 -
Figure 25 : Module Ressources Humaines ........................................................................................- 67 -
Figure 26 : Module Parc automobile.................................................................................................- 67 -
Figure 27 : JasperReports .................................................................................................................- 68 -
Figure 28 : Croisement Besoins/Modules existants..........................................................................- 69 -
Figure 29 : classe "entité"..................................................................................................................- 72 -
Figure 30 : Entité : vue formulaire.....................................................................................................- 72 -
Figure 31 : Vue héritée : syntaxe.......................................................................................................- 73 -
Figure 32 : Maquette du rapport sur "ordre de service" ..................................................................- 74 -
Figure 33 : Rapport au format PDF pour un ordre de service...........................................................- 75 -
Figure 34 : Structure du module acheminement..............................................................................- 78 -
Figure 35 : Fichier d’initialisation __init__.py ...................................................................................- 79 -
Figure 36 : Fichier de description __openerp__.py...........................................................................- 80 -
Figure 37 : Description de l’objet carte carburant ............................................................................- 82 -
Figure 38 : Vue formulaire d'un employé..........................................................................................- 82 -
Figure 39 : Vue liste employés ..........................................................................................................- 83 -
Figure 40 : Vue Kanban ordres de service « validés siège »..............................................................- 83 -
Figure 41 : Vue graphe du workflow des ordres de service..............................................................- 85 -
Figure 42 : Création d'un ordre de service........................................................................................- 86 -
Figure 43 : Authentification...............................................................................................................- 87 -
Figure 44 : Vue formulaire ordre "validé région"..............................................................................- 88 -
Figure 45 : Vue kanban ordre de service "validé siège"....................................................................- 88 -
Figure 46 : Vue formulaire dépêche « validée siège » ......................................................................- 89 -
- 10 -
Figure 47 : Vue Kanban Dépêches "validée siège"............................................................................- 90 -
Figure 48 : Suivi de dépêche : Vue formulaire ..................................................................................- 91 -
Figure 49 : Suivi de dépêches, vue "calendar" ..................................................................................- 91 -
Figure 50 : Liste des modules OpenERP ............................................................................................- 93 -
Figure 51 : Description du module Acheminement ..........................................................................- 94 -
Figure 52 : Dépendances du module Acheminement : ressources humaines (hr) & parc automobile
(fleet).................................................................................................................................................- 94 -
Figure 53.: page 1 ordre de service.................................................................................................- 100 -
Figure 54.: page 2 ordre de service.................................................................................................- 101 -
- 11 -
Table des matières
Introduction générale...................................................................- 14 -
Partie I : Contexte général du projet..........................................- 15 -
Introduction de la partie.............................................................................................................- 15 -
Chapitre 1 : Présentation de l’organisme d’accueil .................................................................- 16 -
Introduction du chapitre.........................................................................................................- 16 -
I. Présentation de Barid Al Maghrib.................................................................................- 16 -
II. Domaines d’activités....................................................................................................- 16 -
III. Prestations de services.................................................................................................- 17 -
Conclusion du chapitre ...........................................................................................................- 18 -
Chapitre 2 : Présentation du projet...........................................................................................- 19 -
Introduction du chapitre.........................................................................................................- 19 -
I. Contexte général du projet .............................................................................................- 19 -
II. Objectifs du projet.......................................................................................................- 19 -
Conclusion du chapitre ...........................................................................................................- 20 -
Chapitre 3 : Plan d’Assurance Qualité (PAQ)..........................................................................- 21 -
Introduction du chapitre.........................................................................................................- 21 -
I. Organisation.....................................................................................................................- 21 -
II. Méthode de travail.......................................................................................................- 22 -
III. Planification du projet ................................................................................................- 26 -
IV. Risques..........................................................................................................................- 29 -
Conclusion du chapitre ...........................................................................................................- 30 -
Conclusion de la partie................................................................................................................- 30 -
Partie II : Etude fonctionnelle et conception .............................- 31 -
Introduction de la partie.............................................................................................................- 31 -
Chapitre 1 : Etude préliminaire.................................................................................................- 32 -
Introduction du chapitre.........................................................................................................- 32 -
I. Etude de l’existant...........................................................................................................- 32 -
II. Critique de l’existant...................................................................................................- 35 -
III. Solution apportée.........................................................................................................- 36 -
Conclusion du chapitre ...........................................................................................................- 38 -
Chapitre 2 : Etude fonctionnelle ................................................................................................- 39 -
Introduction du chapitre.........................................................................................................- 39 -
I. Spécifications des besoins fonctionnels..........................................................................- 39 -
II. Identification des acteurs et les rôles .........................................................................- 40 -
- 12 -
III. Diagrammes de cas d’utilisation ................................................................................- 42 -
Conclusion du chapitre ...........................................................................................................- 51 -
Chapitre 3 : Conception..............................................................................................................- 52 -
Introduction du chapitre.........................................................................................................- 52 -
I. Diagramme de classes : Description ..............................................................................- 52 -
II. Diagramme de classes par métiers.............................................................................- 52 -
Conclusion du chapitre ...........................................................................................................- 57 -
Conclusion de la partie................................................................................................................- 58 -
Partie III. Etude technique et réalisation...................................- 59 -
Introduction de la partie.............................................................................................................- 59 -
Chapitre 1. Technologie mises en œuvre...................................................................................- 60 -
Introduction du chapitre.........................................................................................................- 60 -
I. OpenERP version 7 .........................................................................................................- 60 -
II. Le langage Python .......................................................................................................- 61 -
III. PostgreSQL..................................................................................................................- 62 -
IV. Le langage XML ..........................................................................................................- 63 -
V. Le logiciel DIA .................................................................................................................- 63 -
VI. Le logiciel IReport 5.5.0..............................................................................................- 64 -
VII. Editeurs utilisés............................................................................................................- 64 -
Conclusion du chapitre ...........................................................................................................- 64 -
Chapitre 2 : Etude de convergence............................................................................................- 65 -
Introduction du chapitre.........................................................................................................- 65 -
I. Besoins métiers de l’application.....................................................................................- 65 -
II. Modules existants.........................................................................................................- 66 -
III. Croisement Besoins/Fonctionnalités OpenERP........................................................- 68 -
Conclusion du chapitre ...........................................................................................................- 70 -
Chapitre 3 : Paramétrage de modules.......................................................................................- 71 -
Introduction du chapitre.........................................................................................................- 71 -
I. Paramétrage du module Ressources Humaines « hr ».................................................- 71 -
II. Paramétrage du module Parc Automobile « fleet »..................................................- 73 -
III. Paramétrage du module Jasper Reports...................................................................- 73 -
Conclusion du chapitre ...........................................................................................................- 76 -
Chapitre 4. Développement du module « Acheminement ».....................................................- 77 -
Introduction du chapitre.........................................................................................................- 77 -
I. Logique de développement d’un module OpenERP ....................................................- 77 -
- 13 -
II. Les workflows ..............................................................................................................- 84 -
III. Ecrans d’applications..................................................................................................- 86 -
Conclusion du chapitre ...........................................................................................................- 92 -
Chapitre 5 : Tests et Déploiement..............................................................................................- 93 -
Introduction du chapitre.........................................................................................................- 93 -
I. Installation du module Acheminement..........................................................................- 93 -
II. Tests unitaires..............................................................................................................- 95 -
III. Tests d’intégration.......................................................................................................- 95 -
IV. Recette ..........................................................................................................................- 95 -
V. Sites pilotes.......................................................................................................................- 96 -
VI. Formations ...................................................................................................................- 96 -
Conclusion chapitre.................................................................................................................- 96 -
Conclusion de la partie................................................................................................................- 96 -
Conclusion générale......................................................................- 97 -
Bibliographie.................................................................................- 98 -
Webographie .................................................................................- 98 -
Annexes..........................................................................................- 99 -
Annexe I : Installation de OpenERP 7 sur Ubuntu.......................................................................- 99 -
Annexe II : document papier utilisé par BAM, un ordre de service...........................................- 100 -
Annexe III. Tableau d’acheminement.....................................................................................- 102 -
- 14 -
Introduction générale
L’activité courrier consiste en la distribution des courriers émanant des particuliers ou
des entreprises, à des délais raisonnables avec des niveaux de qualité et sécurité en phase avec
leurs besoins. La tendance mondiale de cette activité est à la baisse depuis plusieurs années. En
effet, nous assistons à une chute du volume de courriers échangés, due à l’avènement des
échanges électroniques et des restrictions budgétaires des entreprises.
A l’instar des autres services postaux, Poste Maroc n’échappe pas à ce phénomène.
Malheureusement, les leviers pour compenser ce déficit du chiffre d’affaire sont très rares, voire
inexistants. D’où la nécessité d’agir sur une baisse des charges. C’est dans cette optique que
Poste Maroc a entrepris des démarches de réduction de charges dans certains départements,
notamment dans le service Acheminement où plusieurs dépenses peuvent être maitrisées par
l’informatisation de certaines tâches. Cela s’est soldé par une décision de mettre en place un
système informatique capable de gérer le processus actuel de l’acheminement des courriers sans
impacter à la qualité des services rendus.
L’implémentation d’un tel système fut l’objet de notre étude durant la période de stage.
Notre mission était de faire la « conception et réalisation d’une application de gestion de la
flotte et de l’acheminement courrier ». Pour mener à bien ce projet, nous l’avons subdivisé en
plusieurs parties au cours desquelles nous avons effectué des analyses sur les spécifications du
système à concevoir, avant de passer à la réalisation avec des outils appropriés. Dans ce présent
rapport, nous entamerons d’abord par une présentation du contexte général. Par la suite, nous
procéderons à une étude préalable, ainsi qu’une conception détaillée du système. Puis nous
terminerons par une étude technique ainsi qu’une présentation des résultats obtenus après la
mise en œuvre du projet.
- 15 -
Partie I : Contexte général du projet
Introduction de la partie
Avant d’entamer la réalisation d’un projet, il est essentiel de le contextualiser afin
d’avoir une vision claire sur les ressources humaines et matérielles à mettre en place, les
différents enjeux, ainsi que le temps nécessaire à son accomplissement. C’est dans cette
optique que s’inscrit cette première partie qui sera énumérée en plusieurs phases. Nous
présenterons en premier lieu l’organisme ayant soumis ce projet. Par la suite, nous
réaliserons un plan d’assurance qualité après avoir fait une description du projet et ses
principaux objectifs
Chapitre 1 : Présentation de l’organisme d’accueil
Introduction du chapitre
Avant d’entrer dans les détails du projet, nous allons tout d’abord présenter l’organisme
qui nous a ouvert ses portes. Les points qui suivront, constituent un résumé sur l’identité de
l’entreprise, ses domaines d’activités et les services qu’elle offre.
I. Présentation de Barid Al Maghrib
Barid al Maghrib (BAM) ou Poste Maroc est un établissement public marocain de droit
public. Il a été créé en 1998 suite à la séparation des secteurs « Postes et Télécommunications ».
Il a été transformé en Août 2010 en société anonyme, dont le capital est entièrement détenu par
l’Etat.
L’histoire de BAM commence depuis 1892 et treize villes étaient reliées entre elles à
l’époque. Le 22 mai 1912 le premier timbre est émis pour remplacer les cachets qui étaient
utilisés.
De nos jours, Poste Maroc est une entreprise multi-services qui fournit des prestations
dans le domaine des services financiers en plus des domaines du courrier et de la messagerie.
En effet, en Juin 2010, la poste se lance dans le secteur bancaire en créant une filiale baptisée Al
Barid Bank.
BAM est constitué d’un ensemble de pôles dont le pôle courrier constitué à son tour de
directions dont la Direction d’Industrialisation et de l’Efficacité Opérationnelle (DEIO). Nous
avons réalisé notre stage au sein d’une division de ladite direction. C’est la Division Solution
et Amélioration continue dont les missions dans BAM sont :
 Assistance à maitrise d’ouvrage au métier courrier ;
 Support technique aux sites courrier ;
 Veille technologique.
II. Domaines d’activités
Barid Al Maghrib opère principalement dans trois métiers : le courrier, la messagerie et
les services financiers. Le courrier représente environ 50% de son chiffre d’affaire.
L’activité courrier connaît une évolution positive de ses performances. Ces bons
résultats sont le fruit des efforts déployés pour le développement du portefeuille client,
l’amélioration de la qualité de service et la réduction des délais d’acheminement.
Pour sa part, la filiale bancaire Al Barid Bank, lancé en Juin 2010 a renforcé la mission
de service universel de BAM. En effet, l’activité des services financiers a enregistré des
Chapitre 1 : Présentation de l’organisme d’accueil
- 17 -
développements majeurs s’articulant autour de la mise à niveau et l’élargissement de l’offre
pour tous les marocains.
Avec la marque Amana dans l’activité messagerie, il y a lieu de souligner les bons
résultats enregistrés ces dernières années et qui trouvent leurs explications essentiellement dans
l’évolution de la gamme de services messagerie nationale et surtout dans un meilleur
positionnement sur le segment des entreprises.
III. Prestations de services
Les prestations de services offertes sont nombreuses. Selon le domaine d’activité, un
ensemble de services sont proposés aux clients.
III.1. L’activité courrier
L’activité courrier cible une large clientèle : institutions, administrations, particuliers,
entreprises ainsi que la presse. La chaîne de valeur courrier comprend le dépôt, la collecte, le
traitement, l’acheminement et la distribution des lettres et autres objets au niveau national et
international. L’activité courrier est devenue, ainsi, un fournisseur de solutions adaptées aux
besoins complexes des entreprises. Aux particuliers, elle propose des services de distribution
de courrier à des délais raisonnables avec des niveaux de qualité et de sécurité en phase avec
leurs besoins.
III.2. L’activité messagerie
Poste Maroc est l’opérateur historique de messagerie et du transport de documents et de
colis au niveau national et international. Son offre répond à des besoins multiples et diversifiés
de ses clients Entreprises et Particuliers à travers une large gamme de services se déclinant sur
le plan national et international.
a. Sur le plan national
 Amana Messagerie nationale : Service de Messagerie nationale permettant
la livraison des colis et des documents dans des délais express et rapides
garantis couvrant tout le territoire national :
 Amana Transport et Logistiques : Service de Transport de marchandises en
lots groupés ou en camion complet à travers l’offre, partout au Maroc ;
b. Sur le plan international
Chapitre 1 : Présentation de l’organisme d’accueil
- 18 -
Poste Maroc offre une large gamme de services de messagerie internationale, rapide et
économique vers plus de 200 pays à travers :
 Amana International Express : Service de messagerie Express internationale
assurant la livraison dans des délais Express garantis allant de 2 à 4 jours ;
 Amana International : Service de messagerie rapide internationale assurant
la livraison dans des délais allant de 5 à 7 jours ;
 Colis Postaux : Service de messagerie économique internationale assurant la
livraison dans des délais allant de 5 à 15 jours.
III.3. L’activité service financier
Cette activité est assurée par la filiale Al Barid Bank. A l’instar des autres structures
bancaires, nous pouvons citer quelques services :
 La gestion de compte courant ;
 La gestion de compte d’épargne ;
 Le transfert d’argent national et international ;
 La bancassurance ;
 Le crédit bancaire ;
 Le service de change.
Conclusion du chapitre
A travers ce chapitre, nous avons fait un bref historique de Barid Al Maghrib, en prenant
soins de préciser les domaines d’activités et les services proposés. Maintenant, il est question
de connaitre les contours du projet qui nous a été confié tout au long de notre stage au sein de
la division solutions et amélioration continue.
Chapitre 2 : Présentation du projet
Introduction du chapitre
Ce chapitre est dédié à la description du présent projet. Nous allons dans un premier
temps, donner le contexte général du projet, qui consistera à donner les motivations qui ont
conduit à sa réalisation et les ambitions qui lui sont associées. Par la suite, nous préciserons les
objectifs généraux.
I. Contexte général du projet
Barid Al Maghrib conduit une stratégie destinée à intégrer les nouvelles technologies
dans ses métiers pour conforter sa position de leadership tout en diversifiant la gamme de ses
prestations, à respecter les standards internationaux de qualité et à concilier entre sa mission de
service public et marchés concurrentiels.
Il travaille sans relâche à proposer les meilleurs services à sa clientèle. Cependant, la
clientèle devient de plus en plus exigeante. C’est alors que BAM doit continuellement trouver
les voies et moyens pour réussir à concrétiser ses ambitions. L’une des activités principales de
BAM est l’acheminement des courriers. Cette activité permet d’assurer un lien de proximité
grâce à de nombreuses agences qui désenclavent les régions les plus reculées du pays et donnent
la possibilité à tous les citoyens de rester en contact avec l'ensemble du territoire et avec
l'extérieur.
Dans la gestion de l’acheminement des courriers, les différentes agences font d’abord le
traitement de ces courriers en local, avant de les transférer dans leurs destinations respectives.
Des retards peuvent alors être engendrés suivant les agences, et BAM n’a pas un moyen pour
contrôler les agences lointaines, ni pour savoir si les courriers sont bien transmis.
Dans cette optique, de nos nombreuses réflexions ont été menée pour savoir les
réponses à apporter aux problèmes posés. C’est dans ce cadre, que se situe la présente réflexion,
qui a pour thème : « conception et réalisation d'une application de gestion de la flotte et de
l'acheminement courriers ». Les objectifs de ce projet sont multiples et ceci fera l’objet de la
section suivante.
II. Objectifs du projet
Le système, qui sera développé, permettra à BAM de pouvoir savoir à chaque instant,
les informations essentielles sur l’acheminement d’un courrier donné. Il pourra ainsi assurer la
cohérence du service avec ses ambitions. Le projet ainsi défini a pour objectif de :
 Assurer la poursuite de la modernisation des différents outils de production en utilisant
les nouvelles technologies qui facilitent l’exécution des différentes tâches ;
Chapitre 2 : Présentation du projet
- 20 -
 Construire une base de données sur le référentiel acheminement (véhicules, chauffeurs,
sites, horaires de transport) ;
 Maitriser l’exécution du chemin d’acheminement, détecter et justifier les écarts ;
 Offrir une gestion souple et maitrisée de la création et mise à jour de nouveaux axes et
horaires d’acheminement (workflow) ;
 Offrir au siège et aux entités desservies par le chemin d’acheminement, un outil
collaboratif facilitant le pilotage opérationnel.
Conclusion du chapitre
Nous avons défini le contexte général et les objectifs du projet dans les points
précédents. Nous allons, dans le chapitre suivant, préciser les différentes modalités à savoir :
quelle sera son organisation, la méthode de travail que nous allons suivre pour sa réalisation, le
planning et les risques liés.
Chapitre 3 : Plan d’Assurance Qualité (PAQ)
Introduction du chapitre
Le plan d’assurance qualité est un document qui relate les différents éléments permettant
de s’assurer de la mise en œuvre et de l’efficacité des activités prévues dans le cahier de charges.
Ce document permet au client et au prestataire de service d’être sur la même longueur
d’onde en ce qui concerne le contexte, les enjeux ainsi que les véritables attentes du client sur
le projet à réaliser.
La réalisation d’un tel document passe par plusieurs étapes. Dans ce rapport, nous nous
attarderons notamment sur quelques-unes à savoir l’organisation, la méthode de travail utilisée,
la planification du projet et les risques éventuels encourus.
I. Organisation
Pour mener à bien notre projet, nous l’avons organisé en définissant les rôles des
différents acteurs qui y interviennent.
I.1. Maitre d’ouvrage
Parfois appelée « maîtrise d’ouvrage », notée MOA, le maitre d’ouvrage est celui qui
maitrise l’idée de base du projet, et représente au mieux les utilisateurs finaux à qui l’ouvrage
est destiné. Il définit l’objectif du projet, son calendrier, et le budget qui y est consacré.
Dans notre projet, l’ouvrage qui est le résultat attendu, est une application OpenERP de
gestion de l’acheminement courrier au sein de Barid Al Maghrib. Ce besoin a été émis par le
Service Acheminement de la Division des Opérations. Cette dernière appartenant elle-même à
la Direction d’Industrialisation et d’Efficacité Opérationnelle (DIEO) du Pôle Courrier. Par
conséquent, le service d’acheminement constitue la maitrise d’ouvrage de notre projet.
I.2. Maitre d’œuvre
Aussi appelée « maitrise d’œuvre » MOE, elle est l’entité retenue par le maitre
d’ouvrage pour la réalisation de l’ouvrage dans les conditions de délais, de qualités et de couts
fixés. Il prend connaissance du besoin exprimé et qui tâche d’y répondre informatiquement.
Dans ce projet, la mission de maitrise d’œuvre nous incombe avec le soutien technique de la
Direction de la Poste Numérique et Télécom.
Chapitre 3 : Plan d’Assurance Qualité (PAQ)
- 22 -
I.3. Assistant Maitre d’Ouvrage
L’assistant a pour fonction principale d’aider le maitre d’ouvrage à définir, piloter et
exploiter le projet réalisé par le maitre d’œuvre. Il aide ce dernier à mieux appréhender le projet,
en définissant les priorités sur les différentes fonctionnalités à réaliser. Dans notre projet, cette
mission a été attribué à la Direction des Solutions et d’Améliorations Continues (DSAC) du
Pôle Courrier.
Figure 1 : Organisation des acteurs du projet
II. Méthode de travail
« Aucune méthode n’est magique, aucune ne garantit la réussite d’un projet. Sinon tous
les projets informatiques seraient de brillantes réussites » [WEB06]. C’est une citation retrouvée
sur internet qui résume parfaitement notre position sur la question du choix des méthodes de
travail. Ce choix était l’une des étapes déterminantes dans le déroulement de notre projet. Il doit
correspondre au contexte de celui-ci. Autrement dit, il doit être en phase avec les particularités
et les différentes exigences, afin d’obtenir un produit de qualité qui répond aux attentes du
client.
Pour la mise en œuvre de notre projet, nous avons opté pour l’utilisation d’une méthode
agile. Ce choix de la méthode n’est pas hasardeux, puisque nous avons pris en compte un certain
nombre de critères tels le profil et la disponibilité des acteurs, les priorités du projet, la stabilité
du projet et le profil du projet. En effet, les besoins de notre projet évoluaient au fur et à mesure,
et il fallait faire des livraisons récurrentes après la réalisation d’une portion de l’application. De
Chapitre 3 : Plan d’Assurance Qualité (PAQ)
- 23 -
plus, à la vue de l’importance du projet, une disponibilité ou une mobilisation des différents
acteurs n’étaient pas à craindre au sein de Barid Al Maghrib. De plus, compte tenu du profil du
projet, qui est le développement d’un module OpenERP, la méthode agile était plus que
recommandée.
II.1. Les méthodes agiles
Les méthodes agiles sont des procédés qui visent à apporter plus de valeurs aux clients,
aux utilisateurs, ainsi qu’une grande satisfaction dans leur travail aux membres de l’équipe. Le
but fondamental de ce type de méthode est la maximisation de la valeur ajoutée. En effet, le
développement s’effectuera par itérations successives, avec possibilité de changer de priorité à
la fin de chaque itération.
Une tentative de définition de Scott Ambler, ingénieur canadien spécialisé sur les
méthodes agiles serait : « Une méthode agile est une approche itérative et incrémentale pour le
développement de logiciel, réalisé de manière très collaborative par des équipes
responsabilisées, appliquant un cérémonial minimal, qui produisent un logiciel de grande
qualité dans un délai contraint, répondant aux besoins changeant des utilisateurs »
Considérées souvent comme une nouvelle culture, les méthodes agiles possèdent les
valeurs et les principes suivants :
 Livrer fréquemment et régulièrement le logiciel ;
 Faire des cycles de développement court et limité dans le temps ;
 Constituer une équipe complète pour un développement ;
 Gérer les membres de l’équipe en les responsabilisant ;
 Avoir le représentant des utilisateurs sur le même site que le reste de l’équipe ;
 Produire des plans à plusieurs niveaux : détaillés uniquement pour le court terme
et plus généraux pour le moyen terme ;
 Développer en intégrant le code de façon continue ;
 Faire des bilans de projet dans le but d’améliorer la façon de travailler ;
Plusieurs méthodes, de nos jours, respectent ces principes et sont qualifiées d’agiles.
Mais l’engouement pour la méthode Scrum a mis fin à une hypothétique rivalité entre les
méthodes agiles [OUV01]. En effet, celle-ci est la plus populaire de toutes et sera utilisée par
la suite car compatible avec les besoins du client.
II.2. La méthode Scrum
Scrum tient son nom d’un terme emprunté au vocabulaire du sport rugby, « mêlée ».
Elle utilise les valeurs et l’esprit du rugby et les adapte aux projets de développement. Comme
Chapitre 3 : Plan d’Assurance Qualité (PAQ)
- 24 -
son nom l’indique, Scrum consiste en une équipe soudée, travaillant de manière collective, dont
les travaux convergent tous vers les buts préalablement définis. Et c’est la même similitude au
rugby pour avancer le ballon pendant une « mêlée ».
Scrum fait partie des approches itératives et incrémentales dont le modèle de cycle de
développement est basé sur une phase qui se répète plusieurs fois successivement. C’est la
notion d’itération ou « sprint » dans Scrum (cf. Figure 2).
Figure 2 : Structure de la méthode SCRUM
Tous les sprints se déroulent selon le même schéma, et on y fait à chaque fois les mêmes
types de travaux. Avec une méthode agile comme Scrum, les activités de spécifications et de
conception sont continues, et on part du principe que l’architecture va évoluer, dans une certaine
limite, pendant la vie du projet.
Figure 3 : Déroulement des sprints
Tout au long du projet du projet, nous avons eu à réaliser plusieurs sprints. La durée de
ces sprints variait énormément en fonction de leur complexité.
 Gestion des sites et des axes de transport ;
 Gestion des ordres de service et des dépêches ;
 Gestion du suivi des dépêches ;
 Gestion des acteurs et des rôles de sécurité ;
 Gestion du reporting ;
 Paramétrage du module de Ressources Humaines ;
 Paramétrage du module de Parc Automobile.
Chapitre 3 : Plan d’Assurance Qualité (PAQ)
- 25 -
Ces sprints ont été réalisés de manière chronologique et ont nécessité la participation de
tous les acteurs du projet.
II.3. Les acteurs au cœur du projet
Dans un projet Scrum, les différents acteurs doivent être répartis en fonction de trois
rôles essentiels : le ScrumMaster, le ProductOwner, et l’équipe.
a. Le ScrumMaster
Il joue le rôle de médiateur entre les membres de son équipe et le client lorsque cela
s’avère nécessaire. Un client mécontent aura affaire par exemple au ScrumMaster, qui trouvera
un compromis entre les deux parties. Dans notre projet, ce rôle a été joué l’assistant du maitre
d’ouvrage. Il faisait l’intermédiaire entre nous, qui formons l’équipe, et le représentant des
futurs utilisateurs de l’application.
b. Le ProductOwner
Il est le représentant dans l’équipe de toutes les personnes qui utiliseront l’application.
Il est chargé de définir l’objectif du projet et de le partager avec l’équipe qui le développe. Pour
cela, il identifie les fonctionnalités requises dont a besoin l’application, puis les collecte dans
une liste appelée « backlog de produit ». Durant notre stage, ce rôle fut joué par le maitre
d’ouvrage du projet.
c. L’équipe
L’équipe est composée des « techniciens » qui vont travailler sur le projet, guidé par le
ScrumMaster et aidé par le ProductOwner. Elle a le rôle principal puisque c’est elle qui
développera l’application au cours des sprints. Nous avons formé cette équipe avec la
participation de la Direction du Poste Numérique et Télécom. En d’autres termes, le rôle de
l’équipe a été joué par la maitrise d’œuvre du projet. Des réunions sont organisées
régulièrement lors de chaque sprint, afin de faire des mises au point, sur l’état d’avancement et
sur de possibles améliorations à prendre en compte.
Pour conclure, nous pouvons dire que Scrum est un bon cadre de gestion de projets. Elle
ne préconise aucune pratique d’ingénierie pour garantir la qualité d’un produit. Sa flexibilité
pendant la réalisation et son cadre de travail y fait sa force. Elle imite le principe de l’état
d’esprit du rugby : avancer tous ensemble vers un but commun. Ce dernier faisant ainsi
référence à la réussite du projet.
Chapitre 3 : Plan d’Assurance Qualité (PAQ)
- 26 -
III. Planification du projet
La planification constitue l’une des étapes primordiales dans le déroulement d’un projet.
Elle consiste à prévoir le déroulement des différentes phases du projet, en fonction des besoins
exprimés dans le cahier de charges et de la méthode de travail utilisée. Ces diverses phases
constituent des sprints, dans lesquelles nous devons réaliser un livrable du produit. Autrement
dit, nous devons développer dans chaque sprint un fragment de l’application, à travers une
analyse des spécifications des besoins, du codage, ainsi que des tests unitaires.
Au début du stage, nous avons réalisé une planification prévisionnelle du projet, dans
laquelle nous avons estimé les durées de réalisation possible pour chaque sprint. Ces durées,
exprimées en nombre de jours ouvrables de la semaine sont représentées dans le diagramme de
Gantt prévisionnel ci-dessous (cf. Figure 4).
A la fin du stage, nous avons mis en place une planification définitive qui relate les
détails de ce qui a été réalisé pendant le déroulement du projet. Cette planification a été illustrée
dans le diagramme de Gantt définitif représenté un peu plus bas (cf. Figure 5).
Quelques écarts ont été remarqués après une comparaison des deux planifications
réalisées. Cela s’explique par le fait que certaines parties furent plus difficiles que d’autres, et
ont demandé ainsi plus de ressources (temps, recherches, etc.). Les écarts majeurs ont été
remarqués au niveau de la gestion des ordres de services, la gestion du suivi des dépêches et le
reporting.
 La gestion des ordres de service
Initialement prévu pour six jours ouvrables, la gestion des ordres des ordres de services
a nécessité autant de jours supplémentaires pour sa mise en place.
En effet, la compréhension et la mise en place du système de workflow n’a pas été une
chose aisée. Il nous était difficile de trouver un document qui explique correctement son
intégration dans un module OpenERP. Quand bien même on trouvait des documentations
officielles, celles-ci se limitaient à nous expliquer les bienfaits et avantages qu’auront les
workflows dans notre système d’information, et non comment les mettre en place.
Après plusieurs jours de recherches, nous avons décidé de coupler les réponses
approximativement recueillies dans les forums dédiés, au code d’un module OpenERP utilisant
déjà les workflows, « purchase ». Par la suite, nous avons pu surmonter cette difficulté, mais
avec un retard sur la planification initiale. (cf Figure 4 et 5)
 La gestion du suivi des dépêches
Celle-ci fut réalisée en deux temps : la gestion de suivi de base, et la gestion des
contraintes liés aux diverses règles métiers. Elle a accusé un retard de deux jours ouvrables par
rapport à la planification initiale. La première a été réalisée dans les temps car elle ne présentait
pas de difficultés particulières. Quant au second, elle nécessitait l’appellation de plusieurs
fonctions pythons en arrière-plan. En effet, notre utilisation du python jusque-là était limitée à
la création de classes des différents objets. L’heure était venue pour nous de créer nos propres
Chapitre 3 : Plan d’Assurance Qualité (PAQ)
- 27 -
fonctions pour les incorporer dans les vues XML. Cela nous a pris un peu plus de temps car il
fallait trouver une manière d’intégrer et d’appeler les fonctions pythons dans le module. (cf.
Figure 4 et 5)
 Le reporting
Prévu initialement pour cinq jours, la gestion du reporting a duré finalement sept jours
ouvrables. Cela est dû aux tests effectués sur plusieurs outils de reporting. En effet, afin de
pouvoir générer des documents en PDF, nous avons eu recours à un certain nombre d’outils.
Tout d’abord nous avons opté pour l’OpenOffice. Cela s’est avéré ne pas être un succès, puisque
ce dernier était très limité en ce qui concerne la mise en forme des données. Ensuite, nous avons
survolé d’autres outils tels « Pentaho reports », « wkhtmltopdf », «Geraldo Reports » par
manque de tutoriels expliquant correctement leurs modes de fonctionnement. Au final, notre
choix s’est porté sur « Jasper Reports », qui en plus de générer des documents en PDF, nous
proposait toute une panoplie d’extensions possibles. L’essai de presque tous ces outils a ainsi
occasionné une énorme perte de temps par rapport à la planification initiale.
Figure 4 : Diagramme de GANTT prévisionnel
Chapitre 3 : Plan d’Assurance Qualité (PAQ)
- 28 -
Figure 5 : Diagramme de Gantt définitif
Chapitre 3 : Plan d’Assurance Qualité (PAQ)
- 29 -
IV. Risques
Tout projet, du fait même de son caractère unique, comporte une part de risques dont la
nature peut être variée (techniques, juridiques, sociaux, humains, etc.). Il est donc primordial
d’effectuer une étude avant le début du projet, en vue de mesurer les risques particuliers qui y
sont liés. Les principaux risques que nous avons pu déceler sont les suivants.
Risques 1
Probabilité 2
Impacts Mesure de maitrise
Développer en OpenERP
OpenERP était une nouvelle
technologie que l’on ne connaissait
pas et dont la documentation ou les
forums d’aides dédiés étaient
rarissimes.
avérée fort
Ce risque a été maitrisé par
une auto-formation
technique en OpenERP.
Non connaissance du langage python
OpenERP est majoritairement
développé en python. La
connaissance du python était
essentielle pour le développement
spécifique d’un module
avérée moyen
La lecture de tutoriels nous
a permis de surmonter cette
difficulté
Risque de choix de la méthode de travail
C’était la première fois que nous
devons utiliser SCRUM dans un
projet, ou d’une méthode agile en
général.
probable faible
La présence dans l’équipe
d’un utilisateur expert en
Scrum a permis de nous
guider lors des différentes
étapes au cours des sprints
Risque humain
L’application à réaliser permet de
suivre les différents mouvements
des employés. Le siège pourra
surveiller les différentes activités
de ses employés (les retards
engendrés, la non concordance
entre l’itinéraire à effectuer et le
carburant utilisé, le non –respect
du tableau d’acheminement). Cela
peut inciter les employés à saisir de
fausses informations pour saboter
les données de l’application.
probable faible
Il peut être maitrisé par la
formation, la sensibilisation
et l’accompagnement des
employés lors du
déploiement
1
Probabilité que ce risque se réalise
2
L’impact de ce risque pour le bon déroulement du projet
Chapitre 3 : Plan d’Assurance Qualité (PAQ)
- 30 -
Conclusion du chapitre
A travers ce chapitre, nous avons mis en place le plan d’assurance qualité dans laquelle
nous avons exposé notre organisation, la méthode de travail adoptée, la planification
prévisionnelle et définitive ainsi que les risques possibles que nous pourrions rencontrés. Ce
chapitre scellait aussi par la même occasion la dernière phase de cette première partie.
Conclusion de la partie
Dans cette partie, nous avons présenté le projet dans son contexte général en mettant en
évidence ses objectifs majeurs, et la conduite à utiliser pour le mener à bien. La partie suivante
consistera à une étude fonctionnelle ainsi qu’une conception détaillée des besoins de
l’organisme.
Partie II : Etude fonctionnelle et conception
Introduction de la partie
Dans cette partie, il est question d’effectuer une étude approfondie du système à
mettre en place. Cela passe par une analyse simultanée de l’existant et du cahier de
charge, afin de mettre en évidence le besoin d’un nouveau système capable de répondre
aux exigences de l’entreprise.
Ainsi, nous allons, dans un premier temps, faire l’étude préalable qui consiste à
recenser l’existant, et les insuffisances du système actuel en vue de proposer des
solutions adéquates. Ensuite, nous entamerons la seconde phase où nous allons effectuer
une étude fonctionnelle. Dans celle-ci, nous présenterons les différents acteurs de
l’application, ainsi que les besoins fonctionnels à satisfaire. Nous clôturerons par la suite
cette partie, par une présentation d’une conception détaillée de l’application, à l’aide de
diagrammes UML.
Chapitre 1 : Etude préliminaire
Introduction du chapitre
Cette étude consiste essentiellement à étudier la faisabilité du projet. Nous allons
premièrement faire une analyse de la façon dont sont gérées les activités du pôle courrier.
Ensuite, nous allons évoquer les faiblesses rencontrées dans cette démarche, avant de proposer
des solutions à appliquer pour améliorer le fonctionnement du système actuel.
I. Etude de l’existant
La première étape de l’étude préalable consiste à mettre en évidence le fonctionnement
actuel du système, à savoir les différentes actions mises en jeu lors de l’acheminement d’un
courrier. Pour une bonne compréhension du processus actuel, certaines notions indispensables
sont à définir.
I.1. Définitions de quelques concepts clés
a. Organisation
La gestion des activités du pôle courrier de BAM est assurée par trois principales
couches : le siège, les régions et les sites. En effet, suivant un découpage propre à Barid Al
Maghrib et non suivant le découpage administratif, le Maroc a été divisé en plusieurs régions.
Ces régions ont sous leurs responsabilités les différents sites qui leur sont affectés. Ces sites
peuvent être des centres de traitement et de distribution (CTD), des agences, un centre de
courrier international(CCI), etc. Le siège, quant à lui, a le dernier mot dans les différentes
activités effectuées. Il coordonne les opérations des différentes régions, qui, à leur tour assurent
une meilleure cohésion des tâches au niveau des sites.
b. Ordre de service
Un ordre de service est une décision qui précise les modalités d’exécution de tout, ou
d’une partie des prestations qui déterminent le fonctionnement de Barid Al Maghrib. Il est
traduit sous forme de documents où sont consignées toutes les informations nécessaires à son
exécution. Ces informations sont entre autres :
 La fréquence d’envoi des dépêches dans la semaine ;
 les horaires de départs et d’arrivées théoriques des dépêches ;
 la date d’effet : la date à partir de laquelle, l’ordre de service doit être mis en
exploitation ;
Chapitre 1 : Etude préliminaire
- 33 -
 les axes de transport ;
 le véhicule qui sera utilisé pour le transport et le convoyeur qui est associé.
Un ordre de service n’a pas de date d’expiration. Cependant, son arrêt peut être
explicitement demandé par un autre, et c’est à partir de l’instant précisé dans le nouvel ordre
que l’ancien n’est plus valable. Sa création peut être faite par le siège, mais aussi par les régions.
Dans le cas d’une région, une validation par le siège est obligatoire avant que celui-ci devienne
actif. Elle doit être faite avant sa mise en exploitation. (Annexe II)
c. Dépêche
Une dépêche est constituée d’un ensemble d’envois, formés par un site à destination
d’un autre. Elle peut être créée par le siège mais aussi par les régions. Lors de sa création par
une région, elle doit être obligatoirement validée par le siège avant d’être exploitable. Cette
création intervient suite à l’approbation d’un ordre de service. Après validation, elle est
considérée comme active, tant qu’un ordre de service émis ne sollicite explicitement sa
désactivation.
Classifiée selon des types prédéfinis, son acheminement est réalisé par des moyens de
transport, via un envoi direct ou par l’intermédiaire d’un transit ou de plusieurs transits. Les
types de dépêche peuvent être : Lettre et Carte (LC), Autre Objet(AO), etc.
d. Moyens de transport
Un moyen de transport désigne, dans son sens le plus général, un outil utilisé par
l’Homme afin de se déplacer d’un point A à un point B. Barid Al Maghrib possède plusieurs
types de moyens de transport. Nous pouvons citer :
 Les Véhicules de service
Ce sont des véhicules confiés par Barid Al Maghrib à certains salariés pour les besoins
d’acheminement. Ces véhicules peuvent être des voitures, des fourgonnettes, des camions, ou
même des motos. Chaque véhicule de service appartient à un site spécifique. Il est lié à un
chauffeur ou conducteur qui est censé en prendre soin.
 Les transporteurs agréés
Ils représentent les transporteurs nationaux tels que : CTM, STCR, ou ONCF, mais aussi
les compagnies aériennes. Barid Al Maghrib adopte l’utilisation de ses transporteurs agréés
dans le cas où leur coût de transport des dépêches sur une distance est inférieur à celui des
véhicules de service.
Chapitre 1 : Etude préliminaire
- 34 -
 Les transporteurs Rekkas
Ces types de transporteurs sont sollicités, lorsque Barid Al Maghrib décide de faire appel
à des personnes et non à des sociétés de transport. Dans ce cas, un contrat est signé avec ces
personnes pour assurer le transport et la sécurité des dépêches à transporter. La manière dont
ces dépêches vont être transférées importe peu.
Les Rekkas, ou tout simplement les individus sous contrat de transport avec Barid Al
Maghrib, se portent garant pour transmettre les dépêches dans les délais indiqués. Nous
pouvons distinguer les Rekkas gérant et les Rekkas distribution.
e. Les axes de transport
Les axes de transport désignent les différents trajets que peut prendre un véhicule à partir
d’un site donné. Ils sont définis par un certain nombre de caractéristiques tels que la distance,
le type de l’axe, les sites ou entités de départ et d’arrivée, etc.
f. Table d’acheminement 235
La table d’acheminement 235 est présentée sous forme d’un tableau récapitulatif de tous
les termes définis ci-dessus. En d’autres termes, elle regroupe toutes les dépêches créées après
que les ordres de services aient été validés. Pour une dépêche donnée, nous pouvons y observer
la fréquence d’envoi, le moyen de transport utilisé, l’axe de transport emprunté, les horaires de
départs et d’arrivées théoriques et réelles. (Annexe III)
I.2. Processus actuel de l’acheminement courrier
Le processus de l’acheminement courrier à Barid Al Maghrib suit la logique du tableau
235. En effet, après la création des dépêches issue des ordres de services, les informations du
tableau d’acheminement ne varie pas jusqu’à la signature d’un autre ordre de service.
Tous les jours, des dépêches sont envoyées d’un site à un autre, d’une ville à une autre,
d’une région à une autre. Nous pouvons considérer l’exemple suivant issu d’une ligne du
tableau. « Des dépêches seront envoyées tous les lundi au vendredi d’un site de Rabat à un site
d’Agadir à partir de 23h30 à bord d’un véhicule de service, en faisant escale à Casablanca. Ce
véhicule devrait arriver aux environs de 06h ». Afin de respecter cet ordre émanant du siège
général, et retranscrit dans le tableau 235, le chef du site signera durant la soirée, une décharge
indiquant le départ du véhicule de son site. A la réception des dépêches à Agadir, son
homologue en fera pareille en signant une autre décharge. Ces différentes décharges signées
révéleront ensuite les retards effectués par les chauffeurs et les raisons avancées expliquant ces
retards.
Chapitre 1 : Etude préliminaire
- 35 -
A la fin de la journée, un rapport est effectué au sein des sites sur les différents départs
et arrivés qui ont eu lieu. Ces rapports, stockés dans des fichiers Excel, seront transmis au siège
pour un bilan des activités et s’assurer de la qualité du travail réalisé. Dans le cas d’un arrêt
dans un site donné, des dépêches pourront être déposées en vue d’un transfert futur si elles
devaient y faire escale, et d’autres pourront y rester si c’était leurs destinations. En résumé, tout
dépendra de ce qui est prévu dans le tableau 235. (cf. Annexe III.)
Tel est le processus actuel de l’acheminement des courriers au sein de Barid Al Maghrib.
Les limites de ce processus seront le prochain point que nous allons aborder afin de proposer
des solutions aux problèmes rencontrés.
II. Critique de l’existant
L’une des difficultés majeures que rencontre ce système est la « non centralisation des
données ». Cela empêche la mise en place de statistiques explicatives du fonctionnement global
de l’entreprise. Ces statistiques peuvent être entre autre la connaissance du degré d’exécution
du tableau d’acheminement 235, du taux d’incidents rencontrés dans chaque site.
En effet, les sites gèrent indépendamment les différents acheminements et ont leur
propre base de données qu’ils mettent à jour librement. Ils utilisent Excel pour conserver les
informations des différents acheminements et ce, de façon journalière. Cela augmente le
nombre de fichiers à leur disposition. Les sites doivent envoyer ces fichiers au siège qui se
retrouve ainsi avec un trop grand nombre de fichiers à gérer.
L’utilisation des fichiers Excel peut occasionner des pertes lors des transferts vers le
siège, ou même des erreurs de saisie. Ces erreurs de saisie peuvent amener deux situations
possibles. Le problème peut être détecté, et dans ce cas, le fichier est corrigé et renvoyé au
siège. Dans le cas contraire, cela peut avoir des conséquences sur les décisions futures à prendre.
On observe ainsi une perte de temps considérable entre les différents transferts de fichiers en
comparaison à un système où aucun transfert ne sera nécessaire du fait de la centralisation des
données.
D'ailleurs, en ce qui concerne le transfert des fichiers, il arrive que des sites ne les
effectuent pas. Un exemple concret de conséquence sur le non transfert des fichiers, est la
réaffectation d’un salarié à un autre site. Le siège n’étant pas informé, peut toujours envoyer
des articles (tenues, chaussures) au salarié. Les articles seront redirigés vers le site approprié,
mais avec un effort supplémentaire.
Aussi, le siège éprouve souvent du mal à réagir efficacement face à certaines demandes.
Par exemple, il arrive qu’une demande de ravitaillement en carburant soit incomprise par le
siège étant donné qu’il n’a aucune idée sur l’utilisation de ce carburant.
Chapitre 1 : Etude préliminaire
- 36 -
Il est à noter qu’il est souvent impossible d’utiliser ces fichiers Excel pour la réalisation
de certaines tâches. Sur la base du fonctionnement actuel, il n’existe aucune possibilité de
connaitre la position des véhicules. Pourtant cela pourrait s’avérer très utile dans certaines
situations d’urgences. Par exemple, le système pourra aider à connaitre rapidement la position
d’un véhicule en cas d’incident sur un axe de transport, grâce à son GPS.
En résumé, les difficultés liées à la méthode actuelle sont :
 Non centralisation des données ;
 Données non protégées ;
 Nombre trop élevé de fichiers Excel à gérer ;
 Perte de temps considérable ;
 Possibilité d’incohérence des données entre le siège et un site donné ;
 Difficulté de réaction prompte et efficace de la part du siège ou des sites ;
 Risque de perte de fichiers ;
 Aucune statistique pour mieux comprendre le fonctionnement des différents
sites ;
 Pénurie de carburant due à la création abusive des dépêches (sans informer le
siège).
III. Solution apportée
Au vue des limites du système existant, nous sommes amenés à proposer des solutions
qui répondent aux objectifs de Barid Al Maghrib et qui par la même occasion, pallient aux
lacunes répertoriées. Cette résolution peut se présenter sous trois points : la partie gestion,
organisation et technique.
III.1. La partie Gestion
Cette partie consiste à développer un système basé sur plusieurs modules à savoir
l’acheminement, le parc automobile, et les ressources humaines.
Les principaux objectifs de ce système seront :
 Utilisation des profils pour mieux gérer les droits d’accès aux fichiers : Cela
permettra aux utilisateurs de n’avoir accès qu’aux données dont ils ont le
privilège ;
 Mise en place d’un circuit de validation des dépêches et des ordres de services,
intégrant les acteurs (Responsables de l’acheminement au niveau du siège et des
régions) ;
Chapitre 1 : Etude préliminaire
- 37 -
 L’abandon de fichiers Excel : Le passage des fichiers Excel aux bases de
données constitue une des plus grandes évolutions du système. Cela résoudra les
problèmes liés aux pertes de temps, aux transferts de fichiers avec des erreurs,
au nombre trop élevé de fichiers à gérer, etc. ;
 Mise en place d’un système de reporting : pour la création des rapports
permettant de mieux appréhender les voies et moyens pour accroitre le
rendement de Barid Al Maghrib. Ces rapports pourront être générés au format
PDF ;
 Interface de gestion de l’acheminement courrier : pour un meilleur suivi des
dépêches en apportant des solutions aux différents problèmes y afférant ;
 Gestion du parc automobile : pour une meilleure gestion des véhicules et des
chauffeurs qui y sont affectés. Cela permettra de résoudre les problèmes dû aux
demandes de ravitaillement du carburant non comprise par le siège, ou plus
généralement les incidents qui surviennent lors des transferts des dépêches ;
 Fonction de messagerie : pour assurer la communication entre les différents
acteurs du système ;
 Gestion de ressources humaines.
III.2. La partie Organisation
En termes d’organisation, ce système serait capable d’assurer une meilleure répartition
entre les différents intervenants, leur offrir des espaces personnels, et aussi leur permettre un
accès facile ainsi qu’une coordination.
III.3. La partie Technique
Pour le développement des fonctionnalités susmentionnées, la Direction de la Poste
Numérique et Télécom a mis à notre disposition une plateforme Open source. En effet, cette
direction est chargée de l’ingénierie marketing et de la commercialisation de plusieurs services.
Il existe plusieurs types d’ERPs Open Source. Celui utilisé par la direction de la Poste
Numérique et Télécom est l’OpenERP (cf. Technologies mises en œuvre). C’est est un logiciel
offrant plusieurs fonctionnalités telles que la gestion comptable et financière, la gestion de la
production, la gestion des achats, la gestion des stocks, la gestion des ressources humaines, etc.
Malgré la non-couverture de toutes les activités requises, OpenERP permet le développement
de modules personnalisés. Ce qui nous permettra de couvrir au maximum les fonctionnalités
attendues de l’application.
Chapitre 1 : Etude préliminaire
- 38 -
Conclusion du chapitre
Cette étude nous a permis de passer en revue le fonctionnement présent de
l’acheminement des dépêches à travers une étude de l’existant. Nous avons fait des propositions
pour résoudre certaines difficultés rencontrées. Notre étude ayant été validée, nous pouvons
maintenant passer à la phase de spécifications qui feront l’objet du chapitre suivant.
Chapitre 2 : Etude fonctionnelle
Introduction du chapitre
Ce point consistera à présenter l’application à développer en termes de fonctionnalités
offertes. Il présentera le système qui répond aux besoins exprimés par le client. L’étude
fonctionnelle construit l’édifice qui sert de contrat entre le client et le prestataire d’une solution
informatique. Par ce contrat, le client reconnait que ses besoins sont satisfaits et le prestataire
s’engage à fournir un produit conforme.
I. Spécifications des besoins fonctionnels
L’étude préalable a montré les défauts que présente le système de gestion actuel. Elle a
également présenté les besoins du client en termes de fonctionnalités. Ce présent point a pour
but de spécifier un système conforme aux besoins exprimés par les utilisateurs. Ces derniers
pourront effectuer les tâches suivantes.
I.1. Gestion des ordres de services
La gestion des ordres de services permettra la création, la modification, la suppression
et la validation d’un ordre de service. L’ordre ainsi créé sera soumis à la validation d’un
utilisateur ayant un rôle spécifique. De même, un ordre de service peut être supprimé si au bout
d’un certain temps, sa validation n’est pas acquise, ou modifié si cela est explicitement demandé
au travers de l’application.
En outre, il est fondamental que les utilisateurs puissent consulter les ordres de services
créés afin de savoir les différentes caractéristiques associées, pour pouvoir prendre les décisions
appropriées.
I.2. Gestion des dépêches
La gestion des dépêches suit le même principe que celle des ordres de services.
Cependant une dépêche est liée forcément à un ordre de service préalablement créé. On dit donc
qu’une dépêche est la concrétisation de l’exécution d’un ordre de service.
I.3. Gestion des suivis de dépêches
Pour une dépêche créée, il faut assurer son acheminement de l’entité de départ à l’entité
d’arrivée. Entre ces deux sites, il peut y avoir des points de transit qui assureront l’aiguillage de
la dépêche à la bonne destination. La gestion de suivi consistera ainsi à recueillir les différents
horaires possibles, pour en déduire les retards et les statistiques éventuels.
Chapitre 2 : Etude fonctionnelle
- 40 -
I.4. Gestion du parc automobile
Le parc automobile est constitué d’un ensemble de véhicules faisant objet de contrat
avec les fournisseurs et nécessitant des interventions (réparations). Ces interventions peuvent
engendrer divers coûts.
Cette fonctionnalité a pour but de fournir un moyen efficace pour s’assurer du bon
déroulement de l’acheminement des dépêches.
I.5. Gestion des ressources humaines
Les ressources humaines sont ce qu’il y’a de fondamental dans une entreprise. Toutes
les activités de l’entreprise en dépendent. Une bonne organisation des ressources humaines
(affection optimale des postes, affectation au site) assure la prospérité de l’entreprise. Il est donc
plus que crucial de fournir à l’entreprise, un outil de gestion des employés. Cet outil permettra
entre autres l’ajout des employés en leur affectant des sites, l’attribution des identifiants de
connexion, la gestion du processus de recrutement, la gestion des congés, la gestion du système
de pointage, etc.
I.6. Gestion de l’édition des rapports
L’édition des rapports est introduite pour donner un moyen de mesurer les performances
de Barid Al Maghrib (BAM), au travers des différentes statistiques significatives. Ces
statistiques permettront à BAM de connaitre les différentes difficultés rencontrées dans la
gestion de l’acheminement et de prendre ainsi des décisions adéquates. L’édition de rapport
consiste également en l’impression de document papier. Par exemple, un chauffeur qui assure
le transport d’une dépêche aura besoin d’un document papier de l’ordre de services afin de
savoir ce qu’il lui incombe d’accomplir comme tâches.
Les différents besoins exprimés nous conduisent à la nécessité de pouvoir distinguer les
personnes qui vont se servir du système pour une raison ou une autre. Dans ce but, nous allons
créer des acteurs et les rôles qui leur seront affectés. Ainsi, un acteur ne pourra faire que ce dont
il est habilité.
II. Identification des acteurs et les rôles
Les acteurs sont les utilisateurs du système. Ils sont désignés par le maitre d’ouvrage.
Chaque acteur doit être nommé, mais, pour trouver son nom, il faut penser à son rôle. En en
effet, un acteur représente un ensemble cohérent de rôles joués vis-à-vis d’un système.
Chapitre 2 : Etude fonctionnelle
- 41 -
Nous avons pu identifier quatre acteurs qui pourront interagir avec l’application. Ces
acteurs sont : Responsable acheminement site, Responsable acheminement région, Responsable
acheminement siège et administrateur.
II.1. Responsable acheminement site
Il aura un pouvoir de supervision sur toutes les activités relevant de son site uniquement.
C’est un utilisateur qui aura le privilège de :
 attribuer des tâches à ses subordonnés ;
 vérifier les départs et les arrivés de dépêches dans son site et d’en informer le
siège en cas de besoin ;
 créer une instance pour suivre les dépêches originaires de son site ;
 générer des rapports.
Tout cela s’effectue à travers un espace personnel, lui garantissant ainsi une meilleure
gestion et une vue plus globale de son site.
II.2. Responsable acheminement région
Il a principalement un rôle de :
 Consultation des activités des sites ;
 Gestion des employés ;
 Gestion des véhicules ;
 Gestion des ordres de services ;
 Gestion des dépêches.
Il est important de noter que ce responsable ne peut gérer que ce qui est propre à sa
région. Il dispose à son tour d’un espace personnel qui lui permettra de gérer efficacement les
sites liés. Un ordre de service ou une dépêche créée par la région doit être soumis à la validation
du siège avant d’être opérationnel.
II.3. Responsable acheminement siège
Il a le plein pouvoir quant à la gestion de l’acheminement des dépêches sur toutes les
régions et sur tous les sites. Il possède aussi un espace personnel lui permettant une meilleure
gestion de la flotte et de l’acheminement des courriers.
Chapitre 2 : Etude fonctionnelle
- 42 -
II.4. L’administrateur
La maintenance et la gestion du système mis en place seront faites par l’administrateur.
En effet, ce dernier s’occupera non seulement de la gestion des utilisateurs dans le système,
mais aussi d’une révision périodique des fonctionnalités de l’application pour s’assurer de leurs
bons fonctionnements.
Un système informatique, c’est un ensemble d’acteurs et de rôles joués. Pour une
meilleure assimilation des points évoqués plus haut, nous allons utiliser un langage de
modélisation graphique. Le choix de la modélisation s’est porté sur le langage UML. C’est un
langage utilisé en développement logiciel, et en conception orientée objet. Les composantes qui
nous intéressent dans ce présent document sont : le diagramme de classe, le diagramme de
séquence et le diagramme de cas d’utilisation. Le point suivant portera sur le diagramme de cas
d’utilisation.
III. Diagrammes de cas d’utilisation
UML permet de formaliser les besoins, c’est-à-dire de les représenter sous une forme
graphique suffisamment simple pour être compréhensible par toutes les personnes impliquées
dans le projet. Souvent le maître d’ouvrage et les utilisateurs ne sont pas des informaticiens. Il
leur faut donc un moyen simple d’exprimer leurs besoins. C’est précisément le rôle des
diagrammes de cas d’utilisation. Ils permettent de recenser les grandes fonctionnalités d’un
système.
Dans la suite du rapport, nous allons concevoir les diagrammes des cas d’utilisation
selon les attentes en termes de fonctionnalités pour chaque acteur. Les plus importants cas
d’utilisation seront décrits à l’aide de scenarios, ou d’un diagramme de séquence.
III.1. Diagramme des cas d’utilisation de « Site »
Les sites sont l’objet même de la nécessité d’un système de gestion centralisé. Pour
chaque site, il y’a un acteur « Responsable acheminement site » qui pourra effectuer les tâches
comme nous l’avons spécifié lors de l’identification des acteurs. Le diagramme de cas
d’utilisation correspondant à cet acteur est le suivant (cf. Figure 6).
Chapitre 2 : Etude fonctionnelle
- 43 -
Figure 6 : Diagramme des cas d'utilisation "site"
Description du cas d’utilisation « Gérer le suivi des dépêches »
Identification
Nom du cas : Gérer le suivi des dépêches
But : détail des points pour permettre à un responsable de site d’assurer
l’acheminement des dépêches dont son site en est le point origine ou un point transit.
Acteur Principal : Responsable acheminement site
Séquencement
Le cas d’utilisation commence quand le chef de site souhaite créer ou modifier un suivi
de dépêche.
Préconditions
le système est lancé, le responsable est authentifié et le site est gestionnaire ou le point
de transit d’au moins une dépêche.
Chapitre 2 : Etude fonctionnelle
- 44 -
Enchaînement nominal :
1. Le responsable veut créer un suivi pour une dépêche
2. Il sélectionne la dépêche objet du suivi
3. Il renseigne l’heure de départ de la dépêche
4. Le système vérifie que la dépêche peut être envoyée à l’heure de départ
saisie
5. Le système affecte un numéro au suivi et l’enregistre
6. Terminer le traitement
Scénario alternatif 1 :
Il démarre au point 4 de l’enchaînement nominal.
4. A. la dépêche ne peut pas être envoyée à l’heure de départ saisie
1. le système affiche une notification pour indiquer une violation de
contrainte sur l’heure de départ saisie
2. revenir au point 3 de l’enchaînement nominal
Scénario alternatif 2 :
Il démarre au point 1 de l’enchaînement nominal
1. Le responsable veut modifier un suivi créé pour un autre site
2. Le système vérifie que le site auquel appartient le responsable est bien le
point de destination de la dépêche
3. il renseigne l’heure d’arrivée de la dépêche
4. Le système vérifie que l’heure d’arrivée est supérieure à l’heure de départ
5. Terminer le traitement
Scénario alternatif 3 :
Il démarre au point 4 du Scénario alternatif 2.
4. A. l’heure d’arrivée est inférieure à l’heure de départ
1. le système affiche une notification pour indiquer une violation de
contrainte sur l’heure de d’arrivée
2. revenir au point 3 du Scénario alternatif 2
Scénario alternatif 4 :
Il démarre au point 2 du Scénario alternatif 2
2. A. le site de l’utilisateur connecté est un point de transit de la dépêche
Chapitre 2 : Etude fonctionnelle
- 45 -
1. il saisit l’heure d’arrivée de la dépêche dans son site et celle de départ de
son site
2. revenir au point 5 du Scénario alternatif 2
Post-conditions
Une interface pour le suivi de la dépêche est créée pour permettre aux différents sites
concernés par la dépêche d’interagir pour son acheminement.
III.2. Diagramme des cas d’utilisation de « Région »
Pour rappel, La région est constituée d’un ensemble de sites. Le responsable
acheminement région a donc sous sa responsabilité les sites liés. Son principal rôle est d’assurer
la gestion de la création des dépêches, des ordres de services et des axes de transport. Le
diagramme correspondant aux possibilités offertes à un responsable de région est le suivant :
Figure 7 : Diagramme de cas d'utilisation "région"
Chapitre 2 : Etude fonctionnelle
- 46 -
Description du cas d’utilisation « Gérer les dépêches de sa région»
Identification
Nom du cas : Gérer les dépêches de sa région
But : Permettre à une région de créer, supprimer, modifier ou consulter une dépêche
Acteur Principal : le responsable acheminement région
Séquencement
Préconditions : le système est lancé, le responsable est authentifié
Enchaînement nominal :
1. Il choisit l’opération à effectuer
2. Il veut créer une dépêche
3. Il fournit les informations
4. Il valide les saisies
5. Le système attribut un code à la dépêche et l’enregistre
6. Terminer le traitement
Scénario alternatif 1 :
Il démarre au point 2 de l’enchaînement nominal.
2. A. Il veut modifier une dépêche
1. Il sélectionne la dépêche
2. Il modifie les informations souhaitées en prenant soins d’ajouter un
message d’explication
3. Il change l’état de la dépêche
4. revenir au point 6 de l’enchaînement nominal
Scénario alternatif 2 :
Il démarre au point 2 de l’enchaînement nominal
2. A. le responsable veut supprimer une dépêche
1. Il sélectionne la dépêche
2. Il valide la suppression
3. Le système vérifie les contraintes de dépendance sont respectées
4. Le système supprime la dépêche
5. aller au point 6 de l’enchaînement nominal
Scénario alternatif 3 :
Chapitre 2 : Etude fonctionnelle
- 47 -
Il démarre au point 3 du Scénario alternatif 2 :
2. A. la dépêche est utilisée dans le système
1. Le système affiche une notification pour signaler que la dépêche ne peut
être supprimée.
2. aller au point 5 du Scénario alternatif 2
Post-conditions
On devrait se retrouver avec une dépêche en moins en cas de succès ou aucun
changement en cas d’échec.
NB : La gestion des ordres de service suit la même description que celle des dépêches.
La figure suivante (cf. Figure 8) présente le diagramme de séquence pour le cas d’utilisation
« s’authentifier ».
Figure 8.: Diagramme de séquence pour le cas d’utilisation « s’authentifier »
Chapitre 2 : Etude fonctionnelle
- 48 -
La figure 9 représente le diagramme de séquence pour le cas d’utilisation « Gérer les axes de
transport »
Figure 9 : Diagramme de séquence pour le cas d’utilisation « Gérer les axes de transport »
Chapitre 2 : Etude fonctionnelle
- 49 -
III.3. Diagramme des cas d’utilisation « Siège »
Le responsable de siège a pour principales missions, la gestion des validations des ordres
de services, des dépêches ou des axes de transport créés au niveau régional. Il pourra également
effectuer d’autres tâches qui sont précisées dans le diagramme de la figure 10.
Figure 10 : Cas d'utilisation "siège"
Chapitre 2 : Etude fonctionnelle
- 50 -
Description du cas d’utilisation « Valider l'ordre de service ou la dépêche créé par la
région»
Identification
Nom du cas : Valider l'ordre de services ou la dépêche créé par la région
But : Permettre la validation des dépêches ou des ordres de services créés par les
régions
Acteur Principal : le responsable acheminement siège
Séquencement
Préconditions : le système est lancé, le chef de siège est authentifié
Enchaînement nominal :
1. Il sélectionne un ordre de service ou une dépêche
2. Il vérifie qu’il n’y a aucun problème sur l’objet (dépêche ou ordre de
service)
3. Il valide les saisies
4. Le système change l’état de l’objet
5. Terminer le traitement
Scénario alternatif 1 :
Il démarre au point 2 de l’enchaînement nominal.
2. A. il y’a un problème
1. Il rejette l’objet
2. Il rédige un message
3. Le système enregistre
4. revenir au point 5 de l’enchaînement nominal
Post-conditions
On devrait se retrouver avec une dépêche ou un ordre de services validé. En cas de rejet
un message obligatoire justifiant le rejet est rédigé.
Chapitre 2 : Etude fonctionnelle
- 51 -
III.4. Diagramme du cas d’utilisation « Administrateur »
Le diagramme correspondant à l’administrateur est illustré par la figure 11 :
Figure 11 : Cas d'utilisation "administrateur"
Conclusion du chapitre
Ce chapitre nous a permis d’avoir une connaissance des différents profils d’utilisateurs
qui vont utiliser l’application. Cette étude nous a offert une bonne base pour entamer le chapitre
suivant, qui traitera les diagrammes de classes mettant en jeu des objets qui nous permettront
d’expliquer une partie du fonctionnement de l’entreprise.
Chapitre 3 : Conception
Introduction du chapitre
La conception correspond à la phase de modélisation du système à concevoir dans un
langage de conception bien précis. Comme au chapitre précédent, nous utiliserons UML pour
construire le diagramme de classes. Le choix de ce diagramme réside dans son utilité réelle
pour la suite du projet.
I. Diagramme de classes : Description
Le diagramme de classes est considéré comme le plus important et est le seul à être
obligatoire lors d’une modélisation orientée objet. Après avoir présenté les cas d’utilisation,
nous avons vu qu’ils permettaient de représenter le système du point de vue des acteurs. Le
diagramme de classe quant à lui présente la structure interne du système. Il permet de
représenter de façon abstraite et statique, les objets qui vont interagir pour la réalisation des cas
d’utilisation. Pour pouvoir tracer ce diagramme, il sera nécessaire de déterminer d’abord les
objets manipulés qu’on représentera sous forme de classes ainsi que les différentes relations qui
les lient entre elles.
II. Diagramme de classes par métiers
Lors des divers entretiens que nous avons effectués, il ressort que le système à
développer devra permettre de réaliser les besoins exprimés dans la phase précédente. Pour une
meilleure organisation et vu le nombre élevé de cas d’utilisation, nous allons raisonner
principalement sur les grands points.
II.1. Gestion des ordres de services
Pour la gestion des ordres de services nous aurons besoin des entités suivantes :
 Ordre : cette entité permettra de faire persister les Ordres de services ;
 Vehicule : elle contiendra les informations sur les Véhicules ;
 Entite : elle permettra de stocker les caractéristiques des sites, des régions et du siège ;
 Ville : nous allons y renseigner toutes les villes concernées par les activités ;
 Employe : cette entité permettra de gérer les employés ;
 Message : pour expliquer les raisons d’un refus de validation d’un ordre de service ;
 Frequence : la fréquence d’exécution de l’ordre de services ;
 CarteCarburant : les Cartes de consommations de Carburant qui seront affectées au
véhicule.
Chapitre 3 : Conception
- 53 -
Pour un ordre de service, il ressort que nous voulons connaitre sa mission, ses heures de
départ et d’arrivée, sa date de début de validité, son statut, son état, sa date de création, sa
fréquence d’envoi dans la semaine. Un ordre de service met en relation plusieurs entités de
l’entreprise et nous lui affectons un employé. Un véhicule est utilisé pour exécuter un ordre de
services suivant un axe de transport. Un ordre de service créé par une région peut être rejeté.
Dans ce cas, on lui associé un message détaillant les raisons du rejet. (cf. Figure 13)
Figure 12 : Gestion des ordres de services
L’utilisation de différentes couleurs, dans la figure 13, indique la différence avec les
classes implémentées déjà dans OpenERP et celles que nous avons ajoutées. OpenERP possède
déjà les classes : employee, department, vehicle d’où le nom en anglais. Pour éviter de refaire
ce qui existe déjà, nous avons choisi d’utiliser l’héritage. L’héritage, nous permet d’avoir tous
les attributs de la classe mère, auxquels on peut ajouter nos propres attributs.
Nous allons dans la suite de cette partie, décrire les modèles OpenERP dont nos modèles
ont héritées. Il s’agit des points 4 et 5 sur les ressources humaines et le parc automobile.
Chapitre 3 : Conception
- 54 -
II.2. Gestion des dépêches
Les entités qui vont être utiles pour cette partie sont :
 Depeche : cette entité représente une dépêche avec tous ses attributs ;
 typeDepeche : elle correspond au type d’une dépêche ;
 Region : toutes les régions créées sont représentées dans cette entité ;
 Entite : pour les entités qui y sont associées ;
 Message : pour expliquer les raisons d’un refus de validation d’un ordre de service ;
 Ordre : pour l’ordre de service associé ;
 Ville : pour les villes qui y sont associées.
Pour une dépêche, il y’a lieu de connaitre son statut et son état à savoir si elle est validée,
non validée ou rejetée. Elle concerne des entités et est associée à un ordre de services. Chaque
dépêche appartient à un type bien défini et nous pouvons lui joindre un message. (cf. Figure 15)
Figure 13 : Gestion des dépêches
II.3. Gestion des suivis de dépêches
Les entités utilisées seront :
 SuiviDepeche : cette entité permettra de stocker les informations pour suivre les
dépêches ;
 Entite : pour les entités associées ;
 Depeche : pour les dépêches associées.
Chapitre 3 : Conception
- 55 -
Pour pouvoir assurer le suivi des dépêches, nous avons besoins de connaitre, pour
l’entité suiviDepeche, les attributs tels que : la date de création, les heures de départ et
d’arrivée réelle des dépêches. (cf. Figure 14)
Figure 14 : Gestion du suivi des dépêches
II.4. Gestion des ressources humaines
Cette partie donne lieu d’utiliser les entités :
 Employee : les employés sont représentés à travers cette entité ;
 employee_category : un employé appartient à une catégorie et plusieurs
catégories existent ;
 Department : les sites, les régions et le siège seront logiquement représentés par
cette entité ;
 User : pour permettre la connexion des utilisateurs, les informations seront
stockées ici.
Un employé travaille pour un département et peut y être responsable. Il peut avoir un
mentor et peut également être lié à un utilisateur. Il appartient à au moins une catégorie. (cf.
Figure 15)
Chapitre 3 : Conception
- 56 -
Figure 15 : Gestion des ressources Humaines
II.5. Gestion du parc automobile
A ce niveau, il nous sera important de connaitre les informations suivantes :
 Vehicle ;
 vehicle_model : modèle du véhicule ;
 vehicle_tag : étiquette de véhicule ;
Chapitre 3 : Conception
- 57 -
 vehicle_log_services : intervention sur le véhicule ;
 vehicle_log_contract : Contrat sur le véhicule ;
 contract_state : état du contrat ;
 vehicle_log_fuel : consommation de carburant.
Un véhicule appartient à un modèle. Tout au long de son utilisation, il peut faire l’objet
de plusieurs interventions et consomme du carburant dont il est nécessaire de connaitre les coûts
de consommation. Un employé est affecté au véhicule en tant que chauffeur. (cf. Figure 16)
Figure 16 : Gestion du parc automobile
Conclusion du chapitre
La conception nous a permis de construire les schémas de base de données sur lequel
toute l’application sera construite. Compte tenu de la méthode de développement par sprints
que nous avons adoptée, nous avons construit le diagramme par domaine métiers. Toutefois en
regroupant ces différents diagrammes, nous obtenons le diagramme correspondant au système
tout entier.
Conclusion de la partie
À travers cette partie, nous avons effectué un certain nombre d’études qui nous ont
permis tout d’abord de comprendre le problème posé et les différents enjeux. Ensuite, nous
avons exprimé de façon concrète la solution proposée à travers la création de «profil utilisateur »
et des cas d’utilisations. Ces cas d’utilisations ont été décrits à l’aide de scénarios ou de
diagrammes de séquence. Enfin, nous avons construit le diagramme de classes correspondant
au système à développer. La conception ainsi réalisée, il y’a lieu maintenant de passer à la
concrétisation des concepts étudiés.
Partie III. Etude technique et réalisation
Introduction de la partie
Cette partie a pour but de mettre en lumière le travail réalisé au cours des différents
sprints. En premier lieu nous aborderons les outils que nous avons eu à utiliser tout au long du
stage. Ensuite, nous entamerons un paramétrage des modules après avoir effectué une étude de
convergence. Enfin, nous nous attarderons sur la réalisation du module « Acheminement » et
les tests de déploiement effectués ; et le tout, illustré par des captures d’écrans de l’application.
Chapitre 1. Technologie mises en œuvre
Introduction du chapitre
Pour le développement des fonctionnalités énoncées ci-haut lors des phases de
conception, nous avons eu à utiliser un certains nombres d’outils. Dans ce chapitre, nous
détaillerons ces différentes technologies ainsi que leur rôle pendant la réalisation du projet.
I. OpenERP version 7
Figure 17 : Logo OpenERP
Les ERPs (Entreprise Resource Planning), aussi appelés Progiciel de Gestion Intégré
(PGI), sont des applications dont le but est de coordonner l’ensemble des activités d’une
entreprise autour d’un même système d’information. Leur principe fondateur est de construire
des applications correspondants aux diverses fonctions précédemment citées, de manière
modulaire. Ces modules devraient être indépendants entre eux, tout en partageant une base de
données unique.
Il existe deux catégories d’ERPs : les ERPs propriétaires, et les ERPs Open source. Les
ERPs Open Source sont différents des ERPs propriétaires, non pas en terme de fonctionnalités
disponibles, mais sur tout ce qui touche à la licence du produit, ainsi qu’à la personnalisation
de ce dernier. La réduction des coûts liés au non achat des licences d’utilisation permet à
l’entreprise, d’investir l’argent ainsi économisé, dans une personnalisation accrue de leur ERP
pour avoir un logiciel sur mesure, répondant aux besoins de leurs activités.
L’ERP que nous avons eu à utiliser au cours de notre stage est l’OpenERP. Fondé en
2005 en Belgique par Fabien Pinckaers, il est devenu l’ERP Open source le plus téléchargé au
monde. Il représente la nouvelle génération des ERP avec son modèle 100% Open source, sa
modularité qui fait sa plus grande force ainsi que sa compatibilité avec les nouvelles
technologies. D’ailleurs, la récompense reçue lors des Bossie Award 2013 du meilleur logiciel
Open source pour la deuxième année consécutive n’est pas une surprise en soi. Sa version 7
utilisée tout au long de ce projet offre une interface web, une intégration forte avec Google
Docs mais aussi une messagerie intégrée ou encore des liens avec les réseaux sociaux.
Chapitre 1. Technologie mises en œuvre
- 61 -
Avec plus 3000 modules à sa disposition, OpenERP couvre de multiples domaines de
gestion. Il suit les besoins du marché, et son aspect évolutif est plus qu’admirable.
Anciennement appelé « Tiny ERP », OpenERP est devenu plus récemment en mai dernier
« Odoo ». L’entreprise souhaiterait davantage d’énergie dans sa croissance commerciale tout
en maintenant les efforts d’écriture de son célèbre logiciel professionnel.
Figure 18 : Gestion sur OpenERP
II. Le langage Python
Figure 19 : Python
Chapitre 1. Technologie mises en œuvre
- 62 -
OpenERP a été développé en Python et utilise son propre Framework : le Framework
OpenObject. Il a été développé de façon modulaire. Autrement dit, il est possible d’ajouter ou
de retirer des modules pour changer le fonctionnement du programme : ajout, modification et
suppression des fonctionnalités. La personnalisation d’une instance d’OpenERP peut se faire
de deux manières :
 Avec l’interface d’OpenERP, qui est plus de la configuration que du développement.
Les modifications resteront sur la base de données, et le déploiement du module sur une
autre instance nécessitera l’exportation dudit base de données.
 En créant des modules pythons dédiés, qui est de la programmation pure, basée sur
l’héritage d’objets. Le module ainsi crée sera un dossier contenant plusieurs fichiers
pythons et XML. Pour le déploiement du module sur une autre instance, il suffirait de
copier ce dossier dans le répertoire correspondant.
Le second point est la méthode de développement que nous avons opté car cela offrait
beaucoup d’avantages, que ça soit sur la qualité de notre formation, mais aussi au cas où l’on
voudrait exporter le module dans une autre instance. D’où l’utilisation du langage de
programmation python. C’est un langage multi-paradigme qui favorise la programmation
impérative structurée, et orientée objet. C’est un langage beaucoup apprécié par les pédagogues
car il propose une syntaxe simple à utiliser, qui permet une initiation aisée des concepts de base
de la programmation.
III. PostgreSQL
Figure 20 : PostgreSQL
PostgreSQL est le Système de Gestion de Base de Données qui stocke aussi bien les
données transactionnelles que les données de paramétrage d’OpenERP. Avant la création d’une
instance, OpenERP vous demande au préalable de créer une base de données sur PostgreSQL,
le tout à travers son interface web. Son utilisation, pendant les phases de développement, peut
s’effectuer directement par lignes de commandes, ou par interface graphique « pgadmin ».
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrier

Contenu connexe

Tendances

Rapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application AndroidRapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application AndroidBadrElattaoui
 
Soutenance PFE ingénieur génie logiciel
Soutenance PFE ingénieur génie logicielSoutenance PFE ingénieur génie logiciel
Soutenance PFE ingénieur génie logicielSiwar GUEMRI
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSFaissoilMkavavo
 
Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2Ben Abdelwahed Slim
 
Pfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEPfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEOussama Djerba
 
Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...Ayoub Mkharbach
 
Projet fin d’étude Conception et Mise en place d'un système fleet-tracking
Projet fin d’étude Conception et Mise en place d'un système fleet-trackingProjet fin d’étude Conception et Mise en place d'un système fleet-tracking
Projet fin d’étude Conception et Mise en place d'un système fleet-trackingBorhane Eddine Boulhila
 
Projet Fin D'étude Application Mobile
Projet Fin D'étude Application MobileProjet Fin D'étude Application Mobile
Projet Fin D'étude Application MobileRim ENNOUR
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Sofien Benrhouma
 
Rapport PFE Ingénieurs - ULT-2016 - Hamza Mefteh fini
Rapport PFE Ingénieurs - ULT-2016 - Hamza Mefteh finiRapport PFE Ingénieurs - ULT-2016 - Hamza Mefteh fini
Rapport PFE Ingénieurs - ULT-2016 - Hamza Mefteh finiHamza Mefteh
 
Présentation projet de fin d'étude
Présentation projet de fin d'étudePrésentation projet de fin d'étude
Présentation projet de fin d'étudeDonia Hammami
 
Présentation PFE : Mise en place d’une solution de gestion intégrée (OpenERP...
Présentation PFE :  Mise en place d’une solution de gestion intégrée (OpenERP...Présentation PFE :  Mise en place d’une solution de gestion intégrée (OpenERP...
Présentation PFE : Mise en place d’une solution de gestion intégrée (OpenERP...Mohamed Cherkaoui
 
Présentation PFE - MarouaBouhachem VersionFinale
Présentation PFE - MarouaBouhachem VersionFinalePrésentation PFE - MarouaBouhachem VersionFinale
Présentation PFE - MarouaBouhachem VersionFinaleMaroua Bouhachem
 
Rapport de stage développement informatique
Rapport de stage développement informatique Rapport de stage développement informatique
Rapport de stage développement informatique MehdiOuqas
 
Rapport PFE faten_chalbi
Rapport PFE faten_chalbiRapport PFE faten_chalbi
Rapport PFE faten_chalbiFaten Chalbi
 
Rapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammamiRapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammamiDonia Hammami
 
Rapport Stage Capgemini Otmane DOUIEB
Rapport Stage Capgemini Otmane DOUIEBRapport Stage Capgemini Otmane DOUIEB
Rapport Stage Capgemini Otmane DOUIEBOtmaneDouieb
 
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)Yasmine Tounsi
 

Tendances (20)

Rapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application AndroidRapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application Android
 
Soutenance PFE ingénieur génie logiciel
Soutenance PFE ingénieur génie logicielSoutenance PFE ingénieur génie logiciel
Soutenance PFE ingénieur génie logiciel
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTS
 
Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2
 
Pfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEPfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEE
 
Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...
 
Projet fin d’étude Conception et Mise en place d'un système fleet-tracking
Projet fin d’étude Conception et Mise en place d'un système fleet-trackingProjet fin d’étude Conception et Mise en place d'un système fleet-tracking
Projet fin d’étude Conception et Mise en place d'un système fleet-tracking
 
Projet Fin D'étude Application Mobile
Projet Fin D'étude Application MobileProjet Fin D'étude Application Mobile
Projet Fin D'étude Application Mobile
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
 
Rapport PFE Ingénieurs - ULT-2016 - Hamza Mefteh fini
Rapport PFE Ingénieurs - ULT-2016 - Hamza Mefteh finiRapport PFE Ingénieurs - ULT-2016 - Hamza Mefteh fini
Rapport PFE Ingénieurs - ULT-2016 - Hamza Mefteh fini
 
Présentation projet de fin d'étude
Présentation projet de fin d'étudePrésentation projet de fin d'étude
Présentation projet de fin d'étude
 
Présentation PFE : Mise en place d’une solution de gestion intégrée (OpenERP...
Présentation PFE :  Mise en place d’une solution de gestion intégrée (OpenERP...Présentation PFE :  Mise en place d’une solution de gestion intégrée (OpenERP...
Présentation PFE : Mise en place d’une solution de gestion intégrée (OpenERP...
 
Rapport de stage
Rapport de stageRapport de stage
Rapport de stage
 
Présentation PFE - MarouaBouhachem VersionFinale
Présentation PFE - MarouaBouhachem VersionFinalePrésentation PFE - MarouaBouhachem VersionFinale
Présentation PFE - MarouaBouhachem VersionFinale
 
Rapport de stage développement informatique
Rapport de stage développement informatique Rapport de stage développement informatique
Rapport de stage développement informatique
 
Rapport PFE faten_chalbi
Rapport PFE faten_chalbiRapport PFE faten_chalbi
Rapport PFE faten_chalbi
 
Rapport pfe
Rapport pfeRapport pfe
Rapport pfe
 
Rapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammamiRapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammami
 
Rapport Stage Capgemini Otmane DOUIEB
Rapport Stage Capgemini Otmane DOUIEBRapport Stage Capgemini Otmane DOUIEB
Rapport Stage Capgemini Otmane DOUIEB
 
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
 

En vedette

Solution FleetMapper pour la gestion de conteneur à chargement avant
Solution FleetMapper pour la gestion de conteneur à chargement avantSolution FleetMapper pour la gestion de conteneur à chargement avant
Solution FleetMapper pour la gestion de conteneur à chargement avantDanny Blouin
 
Openerp à la poste maroc
Openerp à la poste marocOpenerp à la poste maroc
Openerp à la poste marocHORIYASOFT
 
Plateforme de gestion des projets de fin d'études
Plateforme de gestion des projets de fin d'étudesPlateforme de gestion des projets de fin d'études
Plateforme de gestion des projets de fin d'étudesMajdi SAIBI
 
Rapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaRapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaNazih Heni
 
Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Addi Ait-Mlouk
 
Logistics Management System_OOAD_PPT
Logistics Management System_OOAD_PPTLogistics Management System_OOAD_PPT
Logistics Management System_OOAD_PPTsourov_das
 
FleetMapper pour la gestion de la collecte municipale de déchets et recyclables
FleetMapper pour la gestion de la collecte municipale de déchets et recyclablesFleetMapper pour la gestion de la collecte municipale de déchets et recyclables
FleetMapper pour la gestion de la collecte municipale de déchets et recyclablesDanny Blouin
 
la contribution de la résilience organisationnelle et l'agilité organisationn...
la contribution de la résilience organisationnelle et l'agilité organisationn...la contribution de la résilience organisationnelle et l'agilité organisationn...
la contribution de la résilience organisationnelle et l'agilité organisationn...najwa sabouk
 
Devenir une organisation apprenante dans l'IT en 2014
Devenir une organisation apprenante dans l'IT en 2014Devenir une organisation apprenante dans l'IT en 2014
Devenir une organisation apprenante dans l'IT en 2014Nathaniel Richand
 
Pres 4 Introduction aux concepts d'organisation apprenante
Pres 4 Introduction aux concepts d'organisation apprenante Pres 4 Introduction aux concepts d'organisation apprenante
Pres 4 Introduction aux concepts d'organisation apprenante agkelley514
 
L'apprentissage organisationnel
L'apprentissage organisationnelL'apprentissage organisationnel
L'apprentissage organisationnelDavid Nowinsky
 
Une idée de l'organisation apprenante
Une idée de l'organisation apprenanteUne idée de l'organisation apprenante
Une idée de l'organisation apprenanteThierry Lemaire
 
Amélioration du système de gestion de transport avec Open tms
Amélioration du système de gestion de transport avec Open tmsAmélioration du système de gestion de transport avec Open tms
Amélioration du système de gestion de transport avec Open tmsHORIYASOFT
 
Rapport de stage de fin d'etude l3 angelito & hasina
Rapport de stage de fin d'etude l3 angelito & hasinaRapport de stage de fin d'etude l3 angelito & hasina
Rapport de stage de fin d'etude l3 angelito & hasinaAngelito Mandimbihasina
 
L’économie collaborative : « le retour des communs » ?
L’économie collaborative :  « le retour des communs » ?L’économie collaborative :  « le retour des communs » ?
L’économie collaborative : « le retour des communs » ?David VALLAT
 
Organisation apprenante: adaptation et innovation par et pour les personnes q...
Organisation apprenante: adaptation et innovation par et pour les personnes q...Organisation apprenante: adaptation et innovation par et pour les personnes q...
Organisation apprenante: adaptation et innovation par et pour les personnes q...David VALLAT
 
ECONOMIE COLLABORATIVE Université ouverte de lyon 2016
ECONOMIE COLLABORATIVE Université ouverte de lyon 2016ECONOMIE COLLABORATIVE Université ouverte de lyon 2016
ECONOMIE COLLABORATIVE Université ouverte de lyon 2016David VALLAT
 
comment éviter les pièges du powerpoint?
comment éviter les pièges du powerpoint?comment éviter les pièges du powerpoint?
comment éviter les pièges du powerpoint?Elena Moltó
 

En vedette (20)

Solution FleetMapper pour la gestion de conteneur à chargement avant
Solution FleetMapper pour la gestion de conteneur à chargement avantSolution FleetMapper pour la gestion de conteneur à chargement avant
Solution FleetMapper pour la gestion de conteneur à chargement avant
 
Openerp à la poste maroc
Openerp à la poste marocOpenerp à la poste maroc
Openerp à la poste maroc
 
Plateforme de gestion des projets de fin d'études
Plateforme de gestion des projets de fin d'étudesPlateforme de gestion des projets de fin d'études
Plateforme de gestion des projets de fin d'études
 
Rapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaRapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédia
 
Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...
 
Logistics Management System_OOAD_PPT
Logistics Management System_OOAD_PPTLogistics Management System_OOAD_PPT
Logistics Management System_OOAD_PPT
 
FleetMapper pour la gestion de la collecte municipale de déchets et recyclables
FleetMapper pour la gestion de la collecte municipale de déchets et recyclablesFleetMapper pour la gestion de la collecte municipale de déchets et recyclables
FleetMapper pour la gestion de la collecte municipale de déchets et recyclables
 
la contribution de la résilience organisationnelle et l'agilité organisationn...
la contribution de la résilience organisationnelle et l'agilité organisationn...la contribution de la résilience organisationnelle et l'agilité organisationn...
la contribution de la résilience organisationnelle et l'agilité organisationn...
 
Devenir une organisation apprenante dans l'IT en 2014
Devenir une organisation apprenante dans l'IT en 2014Devenir une organisation apprenante dans l'IT en 2014
Devenir une organisation apprenante dans l'IT en 2014
 
bank almaghrib
bank almaghribbank almaghrib
bank almaghrib
 
Pres 4 Introduction aux concepts d'organisation apprenante
Pres 4 Introduction aux concepts d'organisation apprenante Pres 4 Introduction aux concepts d'organisation apprenante
Pres 4 Introduction aux concepts d'organisation apprenante
 
L'apprentissage organisationnel
L'apprentissage organisationnelL'apprentissage organisationnel
L'apprentissage organisationnel
 
Une idée de l'organisation apprenante
Une idée de l'organisation apprenanteUne idée de l'organisation apprenante
Une idée de l'organisation apprenante
 
Amélioration du système de gestion de transport avec Open tms
Amélioration du système de gestion de transport avec Open tmsAmélioration du système de gestion de transport avec Open tms
Amélioration du système de gestion de transport avec Open tms
 
Rapport de stage de fin d'etude l3 angelito & hasina
Rapport de stage de fin d'etude l3 angelito & hasinaRapport de stage de fin d'etude l3 angelito & hasina
Rapport de stage de fin d'etude l3 angelito & hasina
 
L’économie collaborative : « le retour des communs » ?
L’économie collaborative :  « le retour des communs » ?L’économie collaborative :  « le retour des communs » ?
L’économie collaborative : « le retour des communs » ?
 
Organisation apprenante: adaptation et innovation par et pour les personnes q...
Organisation apprenante: adaptation et innovation par et pour les personnes q...Organisation apprenante: adaptation et innovation par et pour les personnes q...
Organisation apprenante: adaptation et innovation par et pour les personnes q...
 
ECONOMIE COLLABORATIVE Université ouverte de lyon 2016
ECONOMIE COLLABORATIVE Université ouverte de lyon 2016ECONOMIE COLLABORATIVE Université ouverte de lyon 2016
ECONOMIE COLLABORATIVE Université ouverte de lyon 2016
 
comment éviter les pièges du powerpoint?
comment éviter les pièges du powerpoint?comment éviter les pièges du powerpoint?
comment éviter les pièges du powerpoint?
 
Procédure de formation
Procédure de formationProcédure de formation
Procédure de formation
 

Similaire à Gestion flotte acheminement_courrier

Conception d'un module de gestion de la paie adapté au contexte marocain pour...
Conception d'un module de gestion de la paie adapté au contexte marocain pour...Conception d'un module de gestion de la paie adapté au contexte marocain pour...
Conception d'un module de gestion de la paie adapté au contexte marocain pour...HORIYASOFT
 
OURIREM-SALAH.pdf
OURIREM-SALAH.pdfOURIREM-SALAH.pdf
OURIREM-SALAH.pdfGhezza
 
Mise en place d'une solution VOIP sécurisée
Mise en place d'une solution VOIP sécuriséeMise en place d'une solution VOIP sécurisée
Mise en place d'une solution VOIP sécuriséeOlivierMawourkagosse
 
Contribution a la_realisation_dune_plate_forme_de_suivi_de_colis (1)
Contribution a la_realisation_dune_plate_forme_de_suivi_de_colis (1)Contribution a la_realisation_dune_plate_forme_de_suivi_de_colis (1)
Contribution a la_realisation_dune_plate_forme_de_suivi_de_colis (1)zakia saadaoui
 
Logistiques des Achats Internationaux au TERROUBI
Logistiques des Achats Internationaux au TERROUBILogistiques des Achats Internationaux au TERROUBI
Logistiques des Achats Internationaux au TERROUBIAbdoulaye MBENGUE
 
117607486-Application-Web-de-Gestion-de-stock-du-magasin-de-Faculte-de-Medeci...
117607486-Application-Web-de-Gestion-de-stock-du-magasin-de-Faculte-de-Medeci...117607486-Application-Web-de-Gestion-de-stock-du-magasin-de-Faculte-de-Medeci...
117607486-Application-Web-de-Gestion-de-stock-du-magasin-de-Faculte-de-Medeci...GHITAMASROUR
 
Mise en place d'une infrastructure basée sur OpenStack
Mise en place d'une infrastructure basée sur OpenStack Mise en place d'une infrastructure basée sur OpenStack
Mise en place d'une infrastructure basée sur OpenStack Ahmed Slim
 
Rapport de stage de fin d'etudes du DUT
Rapport de stage de fin d'etudes du DUTRapport de stage de fin d'etudes du DUT
Rapport de stage de fin d'etudes du DUTKarim Souabni
 
La GRH à travers les compétences pour améliorer la performance de l’entreprise
La GRH à travers les compétences pour améliorer la performance de l’entrepriseLa GRH à travers les compétences pour améliorer la performance de l’entreprise
La GRH à travers les compétences pour améliorer la performance de l’entrepriseBelghanami Wassila Nadjet
 
La grh à travers les compétences pour améliorer la
La grh à travers les compétences pour améliorer laLa grh à travers les compétences pour améliorer la
La grh à travers les compétences pour améliorer laAllaeddine Makhlouk
 
Automatisation et supervision de la signalisation adaptée aux zones sensibles...
Automatisation et supervision de la signalisation adaptée aux zones sensibles...Automatisation et supervision de la signalisation adaptée aux zones sensibles...
Automatisation et supervision de la signalisation adaptée aux zones sensibles...mehdihanafi4
 
Rapport de projet de fin d’étude
Rapport  de projet de fin d’étudeRapport  de projet de fin d’étude
Rapport de projet de fin d’étudeOumaimaOuedherfi
 
Mémoire_SciencesPo_Alexis-Legrand_L’INTERNET-DES-OBJETS,-UN-PAS-VERS-LA-TRAN...
Mémoire_SciencesPo_Alexis-Legrand_L’INTERNET-DES-OBJETS,-UN-PAS-VERS-LA-TRAN...Mémoire_SciencesPo_Alexis-Legrand_L’INTERNET-DES-OBJETS,-UN-PAS-VERS-LA-TRAN...
Mémoire_SciencesPo_Alexis-Legrand_L’INTERNET-DES-OBJETS,-UN-PAS-VERS-LA-TRAN...Alexis Legrand
 
Mise En Place d'une Solution de Supervision Réseau
Mise En Place d'une Solution de Supervision Réseau Mise En Place d'une Solution de Supervision Réseau
Mise En Place d'une Solution de Supervision Réseau Yaya N'Tyeni Sanogo
 
Application web de la gestion mabrouki soukayna 3026(1)
Application web de la gestion    mabrouki soukayna 3026(1)Application web de la gestion    mabrouki soukayna 3026(1)
Application web de la gestion mabrouki soukayna 3026(1)Mohamed Tcatvtg
 

Similaire à Gestion flotte acheminement_courrier (20)

Conception d'un module de gestion de la paie adapté au contexte marocain pour...
Conception d'un module de gestion de la paie adapté au contexte marocain pour...Conception d'un module de gestion de la paie adapté au contexte marocain pour...
Conception d'un module de gestion de la paie adapté au contexte marocain pour...
 
OURIREM-SALAH.pdf
OURIREM-SALAH.pdfOURIREM-SALAH.pdf
OURIREM-SALAH.pdf
 
Rapport finiale
Rapport finialeRapport finiale
Rapport finiale
 
Mise en place d'une solution VOIP sécurisée
Mise en place d'une solution VOIP sécuriséeMise en place d'une solution VOIP sécurisée
Mise en place d'une solution VOIP sécurisée
 
Contribution a la_realisation_dune_plate_forme_de_suivi_de_colis (1)
Contribution a la_realisation_dune_plate_forme_de_suivi_de_colis (1)Contribution a la_realisation_dune_plate_forme_de_suivi_de_colis (1)
Contribution a la_realisation_dune_plate_forme_de_suivi_de_colis (1)
 
Logistiques des Achats Internationaux au TERROUBI
Logistiques des Achats Internationaux au TERROUBILogistiques des Achats Internationaux au TERROUBI
Logistiques des Achats Internationaux au TERROUBI
 
elk
elkelk
elk
 
cnam.pdf
cnam.pdfcnam.pdf
cnam.pdf
 
117607486-Application-Web-de-Gestion-de-stock-du-magasin-de-Faculte-de-Medeci...
117607486-Application-Web-de-Gestion-de-stock-du-magasin-de-Faculte-de-Medeci...117607486-Application-Web-de-Gestion-de-stock-du-magasin-de-Faculte-de-Medeci...
117607486-Application-Web-de-Gestion-de-stock-du-magasin-de-Faculte-de-Medeci...
 
Mise en place d'une infrastructure basée sur OpenStack
Mise en place d'une infrastructure basée sur OpenStack Mise en place d'une infrastructure basée sur OpenStack
Mise en place d'une infrastructure basée sur OpenStack
 
Rapport de stage de fin d'etudes du DUT
Rapport de stage de fin d'etudes du DUTRapport de stage de fin d'etudes du DUT
Rapport de stage de fin d'etudes du DUT
 
La GRH à travers les compétences pour améliorer la performance de l’entreprise
La GRH à travers les compétences pour améliorer la performance de l’entrepriseLa GRH à travers les compétences pour améliorer la performance de l’entreprise
La GRH à travers les compétences pour améliorer la performance de l’entreprise
 
La grh à travers les compétences pour améliorer la
La grh à travers les compétences pour améliorer laLa grh à travers les compétences pour améliorer la
La grh à travers les compétences pour améliorer la
 
Memoire final
Memoire finalMemoire final
Memoire final
 
Rapport Projet Fin d'Études PFE
Rapport Projet Fin d'Études PFERapport Projet Fin d'Études PFE
Rapport Projet Fin d'Études PFE
 
Automatisation et supervision de la signalisation adaptée aux zones sensibles...
Automatisation et supervision de la signalisation adaptée aux zones sensibles...Automatisation et supervision de la signalisation adaptée aux zones sensibles...
Automatisation et supervision de la signalisation adaptée aux zones sensibles...
 
Rapport de projet de fin d’étude
Rapport  de projet de fin d’étudeRapport  de projet de fin d’étude
Rapport de projet de fin d’étude
 
Mémoire_SciencesPo_Alexis-Legrand_L’INTERNET-DES-OBJETS,-UN-PAS-VERS-LA-TRAN...
Mémoire_SciencesPo_Alexis-Legrand_L’INTERNET-DES-OBJETS,-UN-PAS-VERS-LA-TRAN...Mémoire_SciencesPo_Alexis-Legrand_L’INTERNET-DES-OBJETS,-UN-PAS-VERS-LA-TRAN...
Mémoire_SciencesPo_Alexis-Legrand_L’INTERNET-DES-OBJETS,-UN-PAS-VERS-LA-TRAN...
 
Mise En Place d'une Solution de Supervision Réseau
Mise En Place d'une Solution de Supervision Réseau Mise En Place d'une Solution de Supervision Réseau
Mise En Place d'une Solution de Supervision Réseau
 
Application web de la gestion mabrouki soukayna 3026(1)
Application web de la gestion    mabrouki soukayna 3026(1)Application web de la gestion    mabrouki soukayna 3026(1)
Application web de la gestion mabrouki soukayna 3026(1)
 

Plus de HORIYASOFT

gnuhealthcon2022_abdrahman.pdf
gnuhealthcon2022_abdrahman.pdfgnuhealthcon2022_abdrahman.pdf
gnuhealthcon2022_abdrahman.pdfHORIYASOFT
 
Deployed eHealth solutions in Morocco_ ELKAFIL_MOROCCO.pptx
Deployed eHealth solutions in Morocco_ ELKAFIL_MOROCCO.pptxDeployed eHealth solutions in Morocco_ ELKAFIL_MOROCCO.pptx
Deployed eHealth solutions in Morocco_ ELKAFIL_MOROCCO.pptxHORIYASOFT
 
Hackaton euvsvirus-gnuhealth-federation
Hackaton euvsvirus-gnuhealth-federationHackaton euvsvirus-gnuhealth-federation
Hackaton euvsvirus-gnuhealth-federationHORIYASOFT
 
7 Conseils pour mettre en place un ERP dans votre entreprise
7 Conseils pour mettre en place un ERP dans votre entreprise7 Conseils pour mettre en place un ERP dans votre entreprise
7 Conseils pour mettre en place un ERP dans votre entrepriseHORIYASOFT
 
Telemedecine au maroc
Telemedecine au marocTelemedecine au maroc
Telemedecine au marocHORIYASOFT
 
Comptabilité SYSCOA avec Odoo V8
Comptabilité SYSCOA avec Odoo V8Comptabilité SYSCOA avec Odoo V8
Comptabilité SYSCOA avec Odoo V8HORIYASOFT
 
Gnuhealth at Software Freedom Day Casablanca 2016
Gnuhealth at Software Freedom Day Casablanca 2016Gnuhealth at Software Freedom Day Casablanca 2016
Gnuhealth at Software Freedom Day Casablanca 2016HORIYASOFT
 
Les Logiciels Libres sont ils plus sécurisés que les Logiciels Propriétaires ?
Les Logiciels Libres sont ils plus sécurisés que les Logiciels Propriétaires ?Les Logiciels Libres sont ils plus sécurisés que les Logiciels Propriétaires ?
Les Logiciels Libres sont ils plus sécurisés que les Logiciels Propriétaires ?HORIYASOFT
 
Migration gmao de openerp 6.1 vers odoo 8
Migration gmao de openerp 6.1 vers odoo 8Migration gmao de openerp 6.1 vers odoo 8
Migration gmao de openerp 6.1 vers odoo 8HORIYASOFT
 
Gestion Paie marocaine et RH avec openerp
Gestion Paie marocaine et RH avec openerpGestion Paie marocaine et RH avec openerp
Gestion Paie marocaine et RH avec openerpHORIYASOFT
 
Gestion programme moussanada avec openerp
Gestion programme moussanada avec openerpGestion programme moussanada avec openerp
Gestion programme moussanada avec openerpHORIYASOFT
 
Mise en conformité_module_finance_maroc
Mise en conformité_module_finance_marocMise en conformité_module_finance_maroc
Mise en conformité_module_finance_marocHORIYASOFT
 
Gestion de la_production_agricole_avec_openerp
Gestion de la_production_agricole_avec_openerpGestion de la_production_agricole_avec_openerp
Gestion de la_production_agricole_avec_openerpHORIYASOFT
 
Openerp pour les grossistes de médicament
Openerp pour les grossistes de médicamentOpenerp pour les grossistes de médicament
Openerp pour les grossistes de médicamentHORIYASOFT
 
Odoopriting opendays2014
Odoopriting opendays2014Odoopriting opendays2014
Odoopriting opendays2014HORIYASOFT
 
Projet tempus mission openerp
Projet tempus mission openerpProjet tempus mission openerp
Projet tempus mission openerpHORIYASOFT
 
Gestion de la paie maroc avec openerp 7
Gestion de la paie maroc avec openerp 7 Gestion de la paie maroc avec openerp 7
Gestion de la paie maroc avec openerp 7 HORIYASOFT
 
Plonegov projet egov
Plonegov projet egov Plonegov projet egov
Plonegov projet egov HORIYASOFT
 
Opentms nextma
Opentms nextmaOpentms nextma
Opentms nextmaHORIYASOFT
 
Strategic dimensions-of-free-and-open source-software-arabic
Strategic dimensions-of-free-and-open source-software-arabicStrategic dimensions-of-free-and-open source-software-arabic
Strategic dimensions-of-free-and-open source-software-arabicHORIYASOFT
 

Plus de HORIYASOFT (20)

gnuhealthcon2022_abdrahman.pdf
gnuhealthcon2022_abdrahman.pdfgnuhealthcon2022_abdrahman.pdf
gnuhealthcon2022_abdrahman.pdf
 
Deployed eHealth solutions in Morocco_ ELKAFIL_MOROCCO.pptx
Deployed eHealth solutions in Morocco_ ELKAFIL_MOROCCO.pptxDeployed eHealth solutions in Morocco_ ELKAFIL_MOROCCO.pptx
Deployed eHealth solutions in Morocco_ ELKAFIL_MOROCCO.pptx
 
Hackaton euvsvirus-gnuhealth-federation
Hackaton euvsvirus-gnuhealth-federationHackaton euvsvirus-gnuhealth-federation
Hackaton euvsvirus-gnuhealth-federation
 
7 Conseils pour mettre en place un ERP dans votre entreprise
7 Conseils pour mettre en place un ERP dans votre entreprise7 Conseils pour mettre en place un ERP dans votre entreprise
7 Conseils pour mettre en place un ERP dans votre entreprise
 
Telemedecine au maroc
Telemedecine au marocTelemedecine au maroc
Telemedecine au maroc
 
Comptabilité SYSCOA avec Odoo V8
Comptabilité SYSCOA avec Odoo V8Comptabilité SYSCOA avec Odoo V8
Comptabilité SYSCOA avec Odoo V8
 
Gnuhealth at Software Freedom Day Casablanca 2016
Gnuhealth at Software Freedom Day Casablanca 2016Gnuhealth at Software Freedom Day Casablanca 2016
Gnuhealth at Software Freedom Day Casablanca 2016
 
Les Logiciels Libres sont ils plus sécurisés que les Logiciels Propriétaires ?
Les Logiciels Libres sont ils plus sécurisés que les Logiciels Propriétaires ?Les Logiciels Libres sont ils plus sécurisés que les Logiciels Propriétaires ?
Les Logiciels Libres sont ils plus sécurisés que les Logiciels Propriétaires ?
 
Migration gmao de openerp 6.1 vers odoo 8
Migration gmao de openerp 6.1 vers odoo 8Migration gmao de openerp 6.1 vers odoo 8
Migration gmao de openerp 6.1 vers odoo 8
 
Gestion Paie marocaine et RH avec openerp
Gestion Paie marocaine et RH avec openerpGestion Paie marocaine et RH avec openerp
Gestion Paie marocaine et RH avec openerp
 
Gestion programme moussanada avec openerp
Gestion programme moussanada avec openerpGestion programme moussanada avec openerp
Gestion programme moussanada avec openerp
 
Mise en conformité_module_finance_maroc
Mise en conformité_module_finance_marocMise en conformité_module_finance_maroc
Mise en conformité_module_finance_maroc
 
Gestion de la_production_agricole_avec_openerp
Gestion de la_production_agricole_avec_openerpGestion de la_production_agricole_avec_openerp
Gestion de la_production_agricole_avec_openerp
 
Openerp pour les grossistes de médicament
Openerp pour les grossistes de médicamentOpenerp pour les grossistes de médicament
Openerp pour les grossistes de médicament
 
Odoopriting opendays2014
Odoopriting opendays2014Odoopriting opendays2014
Odoopriting opendays2014
 
Projet tempus mission openerp
Projet tempus mission openerpProjet tempus mission openerp
Projet tempus mission openerp
 
Gestion de la paie maroc avec openerp 7
Gestion de la paie maroc avec openerp 7 Gestion de la paie maroc avec openerp 7
Gestion de la paie maroc avec openerp 7
 
Plonegov projet egov
Plonegov projet egov Plonegov projet egov
Plonegov projet egov
 
Opentms nextma
Opentms nextmaOpentms nextma
Opentms nextma
 
Strategic dimensions-of-free-and-open source-software-arabic
Strategic dimensions-of-free-and-open source-software-arabicStrategic dimensions-of-free-and-open source-software-arabic
Strategic dimensions-of-free-and-open source-software-arabic
 

Gestion flotte acheminement_courrier

  • 1. ROYAUME DU MAROC *-*-*-*-* HAUT COMMISSARIAT AU PLAN *-*-*-*-*-*-*-* INSTITUT NATIONAL DE STATISTIQUE ET D’ECONOMIE APPLIQUEE Projet de Fin d’Etudes ***** N° 113 Préparé par : ZONGO Joel SONMANDE Goulwindin Salif Sous la direction de : Mlle. Rajaa SAIDI (INSEA) M. Najib OURADI (BAM) Soutenu publiquement comme exigence partielle en vue de l’obtention du Diplôme d’Ingénieur d’Etat Option : INFORMATIQUE Devant le jury composé de : M. A. HACHIMI ALAOUI (INSEA) Mlle. Rajaa SAIDI (INSEA) M. Najib OURADI (BAM) Conception et Réalisation d’une application pour la gestion de la flotte et de l’acheminement courrier
  • 3. - 3 - Résumé Poste Maroc est une entreprise exerçant principalement dans trois métiers dont le pôle courrier. Ce dernier occasionne des charges qui doivent être maitrisées surtout à la vue de la baisse générale du volume de courriers échangés depuis ces dernières années. La réduction de ces charges, majoritairement liées à l’acheminement des courriers, passe une maitrise de l’information nécessitant la mise en place d’un système informatique. C’est dans ce cadre que s’inscrit notre travail qui traite de la conception et la réalisation d’une application de gestion de la flotte et de l’acheminement courrier. Nous étions amenés à réaliser une application sous OpenERP capable de répondre aux besoins spécifiques. Couplée à JasperReports, cette application devra permettre de générer des rapports PDF. Compte tenu du type d’application à développer, nous avons opté pour la méthode de développement SCRUM, au cours de laquelle nous avons dû subdiviser notre projet en fonction des besoins métiers. Cela nous a permis d’effectuer une analyse de chaque besoin en profondeur lors de la phase de modélisation. Pour ce qui est de la phase de réalisation, elle fut réalisé en grande majorité grâce aux langages python et XML. Mots clés : OpenERP, python, XML, Jasper Reports
  • 4. - 4 - Dédicaces A mon père et à ma mère, Piga et Christine ZONGO, qui malgré la distance, ont su trouver les mots justes pour me soutenir tout au long de mon cursus. Aucune dédicace ne saurait être assez éloquente pour exprimer mon respect et ce que vous méritez pour les sacrifices effectués à mon égard. A mes très chères sœurs, pour tous nos moments passés ensemble. Je vous dédie ce travail en vous souhaitant un avenir radieux et plein de promesses. A toute la grande famille, à mes amis, et à tous ceux qui ont cru en moi, et qui me donne envie d’aller de l’avant, je vous remercie tous. Votre soutien et vos encouragements me donnent la force de continuer. Joël ZONGO
  • 5. - 5 - Dédicaces À ma chère mère ma raison d’être, ma raison de vivre, la lanterne qui éclaire mon chemin. À mon cher père en signe d’amour, de reconnaissance et de gratitude pour tous les soutiens et les sacrifices dont il a fait preuve à mon égard. À mes chers frères et chères sœurs Aucun mot, ni aucun signe ne pourront décrire votre implication dans mon épanouissement. À tous mes amis En témoignage de l’amitié sincère et du soutien inébranlable que vous m’avez apporté. je dédie ce travail. Salif SONMANDE
  • 7. - 7 - Remerciements Nous tenons à remercier tous ceux qui nous ont soutenu tout au long de ce travail. Pour commencer notre remercions d’abord les responsables de Barid Al Maghrib qui ont bien voulu nous ouvrir leur porte et qui nous ont permis de disposer d’un cadre idéal de travail. Notre prochain remerciement à notre encadreur externe, Mr. Najib OURADI, direction de la Division des Solutions et d’Améliorations Continues. Son écoute et sa disponibilité tout au long du projet nous a été d’une aide précieuse. Nous remercions également Mlle Rajaa SAIDI, professeur à l’Institut National Statistiques et d’Economie Appliquées pour avoir accepté de nous encadrer et qui a contribué grandement à la reussite du projet à travers ses différents conseils. Nous ne saurions omettre dans nos remerciements tout le personnel de Barid Al Maghrib et plus particulièrement à Mr ERRADI Yacine du service acheminement, et à Abdel SBIA de la Direction de la Poste Numerique et Télécoms. Pour finir, nous tenons à remercier le corps enseignant de l’INSEA pour l’enseignement de qualité dont nous avons bénéficié ainsi que le le personnel administratif et tout ceux qui de près ou de loin ont contribué au succès de ce projet.
  • 8. - 8 - Liste des abréviations BAM : Barid Al Maghrib EA: Enterprise Architect ERP: Enterprise Resource Planning PAQ SQL: Structured Query Language UML: Unified Modeling Language XML : Extensible Markup Language PAQ : Plan d’Assurance Qualité
  • 9. - 9 - Liste des figures Figure 1 : Organisation des acteurs du projet...................................................................................- 22 - Figure 2 : Structure de la méthode SCRUM ......................................................................................- 24 - Figure 3 : Déroulement des sprints ...................................................................................................- 24 - Figure 4 : Diagramme de GANTT prévisionnel ..................................................................................- 27 - Figure 5 : Diagramme de Gantt définitif............................................................................................- 28 - Figure 6 : Diagramme des cas d'utilisation "site"..............................................................................- 43 - Figure 7 : Diagramme de cas d'utilisation "région"...........................................................................- 45 - Figure 8.: Diagramme de séquence pour le cas d’utilisation « s’authentifier »...............................- 47 - Figure 9 : Diagramme de séquence pour le cas d’utilisation « Gérer les axes de transport »..........- 48 - Figure 10 : Cas d'utilisation "siège"...................................................................................................- 49 - Figure 11 : Cas d'utilisation "administrateur" ...................................................................................- 51 - Figure 12 : Gestion des ordres de services........................................................................................- 53 - Figure 13 : Gestion des dépêches......................................................................................................- 54 - Figure 14 : Gestion du suivi des dépêches ........................................................................................- 55 - Figure 15 : Gestion des ressources Humaines...................................................................................- 56 - Figure 16 : Gestion du parc automobile............................................................................................- 57 - Figure 17 : Logo OpenERP .................................................................................................................- 60 - Figure 18 : Gestion sur OpenERP.......................................................................................................- 61 - Figure 19 : Python .............................................................................................................................- 61 - Figure 20 : PostgreSQL ......................................................................................................................- 62 - Figure 21 : XML..................................................................................................................................- 63 - Figure 22 : DIA ...................................................................................................................................- 63 - Figure 23 : Acheminement : Besoins métiers....................................................................................- 65 - Figure 24 : Modules existants ...........................................................................................................- 66 - Figure 25 : Module Ressources Humaines ........................................................................................- 67 - Figure 26 : Module Parc automobile.................................................................................................- 67 - Figure 27 : JasperReports .................................................................................................................- 68 - Figure 28 : Croisement Besoins/Modules existants..........................................................................- 69 - Figure 29 : classe "entité"..................................................................................................................- 72 - Figure 30 : Entité : vue formulaire.....................................................................................................- 72 - Figure 31 : Vue héritée : syntaxe.......................................................................................................- 73 - Figure 32 : Maquette du rapport sur "ordre de service" ..................................................................- 74 - Figure 33 : Rapport au format PDF pour un ordre de service...........................................................- 75 - Figure 34 : Structure du module acheminement..............................................................................- 78 - Figure 35 : Fichier d’initialisation __init__.py ...................................................................................- 79 - Figure 36 : Fichier de description __openerp__.py...........................................................................- 80 - Figure 37 : Description de l’objet carte carburant ............................................................................- 82 - Figure 38 : Vue formulaire d'un employé..........................................................................................- 82 - Figure 39 : Vue liste employés ..........................................................................................................- 83 - Figure 40 : Vue Kanban ordres de service « validés siège »..............................................................- 83 - Figure 41 : Vue graphe du workflow des ordres de service..............................................................- 85 - Figure 42 : Création d'un ordre de service........................................................................................- 86 - Figure 43 : Authentification...............................................................................................................- 87 - Figure 44 : Vue formulaire ordre "validé région"..............................................................................- 88 - Figure 45 : Vue kanban ordre de service "validé siège"....................................................................- 88 - Figure 46 : Vue formulaire dépêche « validée siège » ......................................................................- 89 -
  • 10. - 10 - Figure 47 : Vue Kanban Dépêches "validée siège"............................................................................- 90 - Figure 48 : Suivi de dépêche : Vue formulaire ..................................................................................- 91 - Figure 49 : Suivi de dépêches, vue "calendar" ..................................................................................- 91 - Figure 50 : Liste des modules OpenERP ............................................................................................- 93 - Figure 51 : Description du module Acheminement ..........................................................................- 94 - Figure 52 : Dépendances du module Acheminement : ressources humaines (hr) & parc automobile (fleet).................................................................................................................................................- 94 - Figure 53.: page 1 ordre de service.................................................................................................- 100 - Figure 54.: page 2 ordre de service.................................................................................................- 101 -
  • 11. - 11 - Table des matières Introduction générale...................................................................- 14 - Partie I : Contexte général du projet..........................................- 15 - Introduction de la partie.............................................................................................................- 15 - Chapitre 1 : Présentation de l’organisme d’accueil .................................................................- 16 - Introduction du chapitre.........................................................................................................- 16 - I. Présentation de Barid Al Maghrib.................................................................................- 16 - II. Domaines d’activités....................................................................................................- 16 - III. Prestations de services.................................................................................................- 17 - Conclusion du chapitre ...........................................................................................................- 18 - Chapitre 2 : Présentation du projet...........................................................................................- 19 - Introduction du chapitre.........................................................................................................- 19 - I. Contexte général du projet .............................................................................................- 19 - II. Objectifs du projet.......................................................................................................- 19 - Conclusion du chapitre ...........................................................................................................- 20 - Chapitre 3 : Plan d’Assurance Qualité (PAQ)..........................................................................- 21 - Introduction du chapitre.........................................................................................................- 21 - I. Organisation.....................................................................................................................- 21 - II. Méthode de travail.......................................................................................................- 22 - III. Planification du projet ................................................................................................- 26 - IV. Risques..........................................................................................................................- 29 - Conclusion du chapitre ...........................................................................................................- 30 - Conclusion de la partie................................................................................................................- 30 - Partie II : Etude fonctionnelle et conception .............................- 31 - Introduction de la partie.............................................................................................................- 31 - Chapitre 1 : Etude préliminaire.................................................................................................- 32 - Introduction du chapitre.........................................................................................................- 32 - I. Etude de l’existant...........................................................................................................- 32 - II. Critique de l’existant...................................................................................................- 35 - III. Solution apportée.........................................................................................................- 36 - Conclusion du chapitre ...........................................................................................................- 38 - Chapitre 2 : Etude fonctionnelle ................................................................................................- 39 - Introduction du chapitre.........................................................................................................- 39 - I. Spécifications des besoins fonctionnels..........................................................................- 39 - II. Identification des acteurs et les rôles .........................................................................- 40 -
  • 12. - 12 - III. Diagrammes de cas d’utilisation ................................................................................- 42 - Conclusion du chapitre ...........................................................................................................- 51 - Chapitre 3 : Conception..............................................................................................................- 52 - Introduction du chapitre.........................................................................................................- 52 - I. Diagramme de classes : Description ..............................................................................- 52 - II. Diagramme de classes par métiers.............................................................................- 52 - Conclusion du chapitre ...........................................................................................................- 57 - Conclusion de la partie................................................................................................................- 58 - Partie III. Etude technique et réalisation...................................- 59 - Introduction de la partie.............................................................................................................- 59 - Chapitre 1. Technologie mises en œuvre...................................................................................- 60 - Introduction du chapitre.........................................................................................................- 60 - I. OpenERP version 7 .........................................................................................................- 60 - II. Le langage Python .......................................................................................................- 61 - III. PostgreSQL..................................................................................................................- 62 - IV. Le langage XML ..........................................................................................................- 63 - V. Le logiciel DIA .................................................................................................................- 63 - VI. Le logiciel IReport 5.5.0..............................................................................................- 64 - VII. Editeurs utilisés............................................................................................................- 64 - Conclusion du chapitre ...........................................................................................................- 64 - Chapitre 2 : Etude de convergence............................................................................................- 65 - Introduction du chapitre.........................................................................................................- 65 - I. Besoins métiers de l’application.....................................................................................- 65 - II. Modules existants.........................................................................................................- 66 - III. Croisement Besoins/Fonctionnalités OpenERP........................................................- 68 - Conclusion du chapitre ...........................................................................................................- 70 - Chapitre 3 : Paramétrage de modules.......................................................................................- 71 - Introduction du chapitre.........................................................................................................- 71 - I. Paramétrage du module Ressources Humaines « hr ».................................................- 71 - II. Paramétrage du module Parc Automobile « fleet »..................................................- 73 - III. Paramétrage du module Jasper Reports...................................................................- 73 - Conclusion du chapitre ...........................................................................................................- 76 - Chapitre 4. Développement du module « Acheminement ».....................................................- 77 - Introduction du chapitre.........................................................................................................- 77 - I. Logique de développement d’un module OpenERP ....................................................- 77 -
  • 13. - 13 - II. Les workflows ..............................................................................................................- 84 - III. Ecrans d’applications..................................................................................................- 86 - Conclusion du chapitre ...........................................................................................................- 92 - Chapitre 5 : Tests et Déploiement..............................................................................................- 93 - Introduction du chapitre.........................................................................................................- 93 - I. Installation du module Acheminement..........................................................................- 93 - II. Tests unitaires..............................................................................................................- 95 - III. Tests d’intégration.......................................................................................................- 95 - IV. Recette ..........................................................................................................................- 95 - V. Sites pilotes.......................................................................................................................- 96 - VI. Formations ...................................................................................................................- 96 - Conclusion chapitre.................................................................................................................- 96 - Conclusion de la partie................................................................................................................- 96 - Conclusion générale......................................................................- 97 - Bibliographie.................................................................................- 98 - Webographie .................................................................................- 98 - Annexes..........................................................................................- 99 - Annexe I : Installation de OpenERP 7 sur Ubuntu.......................................................................- 99 - Annexe II : document papier utilisé par BAM, un ordre de service...........................................- 100 - Annexe III. Tableau d’acheminement.....................................................................................- 102 -
  • 14. - 14 - Introduction générale L’activité courrier consiste en la distribution des courriers émanant des particuliers ou des entreprises, à des délais raisonnables avec des niveaux de qualité et sécurité en phase avec leurs besoins. La tendance mondiale de cette activité est à la baisse depuis plusieurs années. En effet, nous assistons à une chute du volume de courriers échangés, due à l’avènement des échanges électroniques et des restrictions budgétaires des entreprises. A l’instar des autres services postaux, Poste Maroc n’échappe pas à ce phénomène. Malheureusement, les leviers pour compenser ce déficit du chiffre d’affaire sont très rares, voire inexistants. D’où la nécessité d’agir sur une baisse des charges. C’est dans cette optique que Poste Maroc a entrepris des démarches de réduction de charges dans certains départements, notamment dans le service Acheminement où plusieurs dépenses peuvent être maitrisées par l’informatisation de certaines tâches. Cela s’est soldé par une décision de mettre en place un système informatique capable de gérer le processus actuel de l’acheminement des courriers sans impacter à la qualité des services rendus. L’implémentation d’un tel système fut l’objet de notre étude durant la période de stage. Notre mission était de faire la « conception et réalisation d’une application de gestion de la flotte et de l’acheminement courrier ». Pour mener à bien ce projet, nous l’avons subdivisé en plusieurs parties au cours desquelles nous avons effectué des analyses sur les spécifications du système à concevoir, avant de passer à la réalisation avec des outils appropriés. Dans ce présent rapport, nous entamerons d’abord par une présentation du contexte général. Par la suite, nous procéderons à une étude préalable, ainsi qu’une conception détaillée du système. Puis nous terminerons par une étude technique ainsi qu’une présentation des résultats obtenus après la mise en œuvre du projet.
  • 15. - 15 - Partie I : Contexte général du projet Introduction de la partie Avant d’entamer la réalisation d’un projet, il est essentiel de le contextualiser afin d’avoir une vision claire sur les ressources humaines et matérielles à mettre en place, les différents enjeux, ainsi que le temps nécessaire à son accomplissement. C’est dans cette optique que s’inscrit cette première partie qui sera énumérée en plusieurs phases. Nous présenterons en premier lieu l’organisme ayant soumis ce projet. Par la suite, nous réaliserons un plan d’assurance qualité après avoir fait une description du projet et ses principaux objectifs
  • 16. Chapitre 1 : Présentation de l’organisme d’accueil Introduction du chapitre Avant d’entrer dans les détails du projet, nous allons tout d’abord présenter l’organisme qui nous a ouvert ses portes. Les points qui suivront, constituent un résumé sur l’identité de l’entreprise, ses domaines d’activités et les services qu’elle offre. I. Présentation de Barid Al Maghrib Barid al Maghrib (BAM) ou Poste Maroc est un établissement public marocain de droit public. Il a été créé en 1998 suite à la séparation des secteurs « Postes et Télécommunications ». Il a été transformé en Août 2010 en société anonyme, dont le capital est entièrement détenu par l’Etat. L’histoire de BAM commence depuis 1892 et treize villes étaient reliées entre elles à l’époque. Le 22 mai 1912 le premier timbre est émis pour remplacer les cachets qui étaient utilisés. De nos jours, Poste Maroc est une entreprise multi-services qui fournit des prestations dans le domaine des services financiers en plus des domaines du courrier et de la messagerie. En effet, en Juin 2010, la poste se lance dans le secteur bancaire en créant une filiale baptisée Al Barid Bank. BAM est constitué d’un ensemble de pôles dont le pôle courrier constitué à son tour de directions dont la Direction d’Industrialisation et de l’Efficacité Opérationnelle (DEIO). Nous avons réalisé notre stage au sein d’une division de ladite direction. C’est la Division Solution et Amélioration continue dont les missions dans BAM sont :  Assistance à maitrise d’ouvrage au métier courrier ;  Support technique aux sites courrier ;  Veille technologique. II. Domaines d’activités Barid Al Maghrib opère principalement dans trois métiers : le courrier, la messagerie et les services financiers. Le courrier représente environ 50% de son chiffre d’affaire. L’activité courrier connaît une évolution positive de ses performances. Ces bons résultats sont le fruit des efforts déployés pour le développement du portefeuille client, l’amélioration de la qualité de service et la réduction des délais d’acheminement. Pour sa part, la filiale bancaire Al Barid Bank, lancé en Juin 2010 a renforcé la mission de service universel de BAM. En effet, l’activité des services financiers a enregistré des
  • 17. Chapitre 1 : Présentation de l’organisme d’accueil - 17 - développements majeurs s’articulant autour de la mise à niveau et l’élargissement de l’offre pour tous les marocains. Avec la marque Amana dans l’activité messagerie, il y a lieu de souligner les bons résultats enregistrés ces dernières années et qui trouvent leurs explications essentiellement dans l’évolution de la gamme de services messagerie nationale et surtout dans un meilleur positionnement sur le segment des entreprises. III. Prestations de services Les prestations de services offertes sont nombreuses. Selon le domaine d’activité, un ensemble de services sont proposés aux clients. III.1. L’activité courrier L’activité courrier cible une large clientèle : institutions, administrations, particuliers, entreprises ainsi que la presse. La chaîne de valeur courrier comprend le dépôt, la collecte, le traitement, l’acheminement et la distribution des lettres et autres objets au niveau national et international. L’activité courrier est devenue, ainsi, un fournisseur de solutions adaptées aux besoins complexes des entreprises. Aux particuliers, elle propose des services de distribution de courrier à des délais raisonnables avec des niveaux de qualité et de sécurité en phase avec leurs besoins. III.2. L’activité messagerie Poste Maroc est l’opérateur historique de messagerie et du transport de documents et de colis au niveau national et international. Son offre répond à des besoins multiples et diversifiés de ses clients Entreprises et Particuliers à travers une large gamme de services se déclinant sur le plan national et international. a. Sur le plan national  Amana Messagerie nationale : Service de Messagerie nationale permettant la livraison des colis et des documents dans des délais express et rapides garantis couvrant tout le territoire national :  Amana Transport et Logistiques : Service de Transport de marchandises en lots groupés ou en camion complet à travers l’offre, partout au Maroc ; b. Sur le plan international
  • 18. Chapitre 1 : Présentation de l’organisme d’accueil - 18 - Poste Maroc offre une large gamme de services de messagerie internationale, rapide et économique vers plus de 200 pays à travers :  Amana International Express : Service de messagerie Express internationale assurant la livraison dans des délais Express garantis allant de 2 à 4 jours ;  Amana International : Service de messagerie rapide internationale assurant la livraison dans des délais allant de 5 à 7 jours ;  Colis Postaux : Service de messagerie économique internationale assurant la livraison dans des délais allant de 5 à 15 jours. III.3. L’activité service financier Cette activité est assurée par la filiale Al Barid Bank. A l’instar des autres structures bancaires, nous pouvons citer quelques services :  La gestion de compte courant ;  La gestion de compte d’épargne ;  Le transfert d’argent national et international ;  La bancassurance ;  Le crédit bancaire ;  Le service de change. Conclusion du chapitre A travers ce chapitre, nous avons fait un bref historique de Barid Al Maghrib, en prenant soins de préciser les domaines d’activités et les services proposés. Maintenant, il est question de connaitre les contours du projet qui nous a été confié tout au long de notre stage au sein de la division solutions et amélioration continue.
  • 19. Chapitre 2 : Présentation du projet Introduction du chapitre Ce chapitre est dédié à la description du présent projet. Nous allons dans un premier temps, donner le contexte général du projet, qui consistera à donner les motivations qui ont conduit à sa réalisation et les ambitions qui lui sont associées. Par la suite, nous préciserons les objectifs généraux. I. Contexte général du projet Barid Al Maghrib conduit une stratégie destinée à intégrer les nouvelles technologies dans ses métiers pour conforter sa position de leadership tout en diversifiant la gamme de ses prestations, à respecter les standards internationaux de qualité et à concilier entre sa mission de service public et marchés concurrentiels. Il travaille sans relâche à proposer les meilleurs services à sa clientèle. Cependant, la clientèle devient de plus en plus exigeante. C’est alors que BAM doit continuellement trouver les voies et moyens pour réussir à concrétiser ses ambitions. L’une des activités principales de BAM est l’acheminement des courriers. Cette activité permet d’assurer un lien de proximité grâce à de nombreuses agences qui désenclavent les régions les plus reculées du pays et donnent la possibilité à tous les citoyens de rester en contact avec l'ensemble du territoire et avec l'extérieur. Dans la gestion de l’acheminement des courriers, les différentes agences font d’abord le traitement de ces courriers en local, avant de les transférer dans leurs destinations respectives. Des retards peuvent alors être engendrés suivant les agences, et BAM n’a pas un moyen pour contrôler les agences lointaines, ni pour savoir si les courriers sont bien transmis. Dans cette optique, de nos nombreuses réflexions ont été menée pour savoir les réponses à apporter aux problèmes posés. C’est dans ce cadre, que se situe la présente réflexion, qui a pour thème : « conception et réalisation d'une application de gestion de la flotte et de l'acheminement courriers ». Les objectifs de ce projet sont multiples et ceci fera l’objet de la section suivante. II. Objectifs du projet Le système, qui sera développé, permettra à BAM de pouvoir savoir à chaque instant, les informations essentielles sur l’acheminement d’un courrier donné. Il pourra ainsi assurer la cohérence du service avec ses ambitions. Le projet ainsi défini a pour objectif de :  Assurer la poursuite de la modernisation des différents outils de production en utilisant les nouvelles technologies qui facilitent l’exécution des différentes tâches ;
  • 20. Chapitre 2 : Présentation du projet - 20 -  Construire une base de données sur le référentiel acheminement (véhicules, chauffeurs, sites, horaires de transport) ;  Maitriser l’exécution du chemin d’acheminement, détecter et justifier les écarts ;  Offrir une gestion souple et maitrisée de la création et mise à jour de nouveaux axes et horaires d’acheminement (workflow) ;  Offrir au siège et aux entités desservies par le chemin d’acheminement, un outil collaboratif facilitant le pilotage opérationnel. Conclusion du chapitre Nous avons défini le contexte général et les objectifs du projet dans les points précédents. Nous allons, dans le chapitre suivant, préciser les différentes modalités à savoir : quelle sera son organisation, la méthode de travail que nous allons suivre pour sa réalisation, le planning et les risques liés.
  • 21. Chapitre 3 : Plan d’Assurance Qualité (PAQ) Introduction du chapitre Le plan d’assurance qualité est un document qui relate les différents éléments permettant de s’assurer de la mise en œuvre et de l’efficacité des activités prévues dans le cahier de charges. Ce document permet au client et au prestataire de service d’être sur la même longueur d’onde en ce qui concerne le contexte, les enjeux ainsi que les véritables attentes du client sur le projet à réaliser. La réalisation d’un tel document passe par plusieurs étapes. Dans ce rapport, nous nous attarderons notamment sur quelques-unes à savoir l’organisation, la méthode de travail utilisée, la planification du projet et les risques éventuels encourus. I. Organisation Pour mener à bien notre projet, nous l’avons organisé en définissant les rôles des différents acteurs qui y interviennent. I.1. Maitre d’ouvrage Parfois appelée « maîtrise d’ouvrage », notée MOA, le maitre d’ouvrage est celui qui maitrise l’idée de base du projet, et représente au mieux les utilisateurs finaux à qui l’ouvrage est destiné. Il définit l’objectif du projet, son calendrier, et le budget qui y est consacré. Dans notre projet, l’ouvrage qui est le résultat attendu, est une application OpenERP de gestion de l’acheminement courrier au sein de Barid Al Maghrib. Ce besoin a été émis par le Service Acheminement de la Division des Opérations. Cette dernière appartenant elle-même à la Direction d’Industrialisation et d’Efficacité Opérationnelle (DIEO) du Pôle Courrier. Par conséquent, le service d’acheminement constitue la maitrise d’ouvrage de notre projet. I.2. Maitre d’œuvre Aussi appelée « maitrise d’œuvre » MOE, elle est l’entité retenue par le maitre d’ouvrage pour la réalisation de l’ouvrage dans les conditions de délais, de qualités et de couts fixés. Il prend connaissance du besoin exprimé et qui tâche d’y répondre informatiquement. Dans ce projet, la mission de maitrise d’œuvre nous incombe avec le soutien technique de la Direction de la Poste Numérique et Télécom.
  • 22. Chapitre 3 : Plan d’Assurance Qualité (PAQ) - 22 - I.3. Assistant Maitre d’Ouvrage L’assistant a pour fonction principale d’aider le maitre d’ouvrage à définir, piloter et exploiter le projet réalisé par le maitre d’œuvre. Il aide ce dernier à mieux appréhender le projet, en définissant les priorités sur les différentes fonctionnalités à réaliser. Dans notre projet, cette mission a été attribué à la Direction des Solutions et d’Améliorations Continues (DSAC) du Pôle Courrier. Figure 1 : Organisation des acteurs du projet II. Méthode de travail « Aucune méthode n’est magique, aucune ne garantit la réussite d’un projet. Sinon tous les projets informatiques seraient de brillantes réussites » [WEB06]. C’est une citation retrouvée sur internet qui résume parfaitement notre position sur la question du choix des méthodes de travail. Ce choix était l’une des étapes déterminantes dans le déroulement de notre projet. Il doit correspondre au contexte de celui-ci. Autrement dit, il doit être en phase avec les particularités et les différentes exigences, afin d’obtenir un produit de qualité qui répond aux attentes du client. Pour la mise en œuvre de notre projet, nous avons opté pour l’utilisation d’une méthode agile. Ce choix de la méthode n’est pas hasardeux, puisque nous avons pris en compte un certain nombre de critères tels le profil et la disponibilité des acteurs, les priorités du projet, la stabilité du projet et le profil du projet. En effet, les besoins de notre projet évoluaient au fur et à mesure, et il fallait faire des livraisons récurrentes après la réalisation d’une portion de l’application. De
  • 23. Chapitre 3 : Plan d’Assurance Qualité (PAQ) - 23 - plus, à la vue de l’importance du projet, une disponibilité ou une mobilisation des différents acteurs n’étaient pas à craindre au sein de Barid Al Maghrib. De plus, compte tenu du profil du projet, qui est le développement d’un module OpenERP, la méthode agile était plus que recommandée. II.1. Les méthodes agiles Les méthodes agiles sont des procédés qui visent à apporter plus de valeurs aux clients, aux utilisateurs, ainsi qu’une grande satisfaction dans leur travail aux membres de l’équipe. Le but fondamental de ce type de méthode est la maximisation de la valeur ajoutée. En effet, le développement s’effectuera par itérations successives, avec possibilité de changer de priorité à la fin de chaque itération. Une tentative de définition de Scott Ambler, ingénieur canadien spécialisé sur les méthodes agiles serait : « Une méthode agile est une approche itérative et incrémentale pour le développement de logiciel, réalisé de manière très collaborative par des équipes responsabilisées, appliquant un cérémonial minimal, qui produisent un logiciel de grande qualité dans un délai contraint, répondant aux besoins changeant des utilisateurs » Considérées souvent comme une nouvelle culture, les méthodes agiles possèdent les valeurs et les principes suivants :  Livrer fréquemment et régulièrement le logiciel ;  Faire des cycles de développement court et limité dans le temps ;  Constituer une équipe complète pour un développement ;  Gérer les membres de l’équipe en les responsabilisant ;  Avoir le représentant des utilisateurs sur le même site que le reste de l’équipe ;  Produire des plans à plusieurs niveaux : détaillés uniquement pour le court terme et plus généraux pour le moyen terme ;  Développer en intégrant le code de façon continue ;  Faire des bilans de projet dans le but d’améliorer la façon de travailler ; Plusieurs méthodes, de nos jours, respectent ces principes et sont qualifiées d’agiles. Mais l’engouement pour la méthode Scrum a mis fin à une hypothétique rivalité entre les méthodes agiles [OUV01]. En effet, celle-ci est la plus populaire de toutes et sera utilisée par la suite car compatible avec les besoins du client. II.2. La méthode Scrum Scrum tient son nom d’un terme emprunté au vocabulaire du sport rugby, « mêlée ». Elle utilise les valeurs et l’esprit du rugby et les adapte aux projets de développement. Comme
  • 24. Chapitre 3 : Plan d’Assurance Qualité (PAQ) - 24 - son nom l’indique, Scrum consiste en une équipe soudée, travaillant de manière collective, dont les travaux convergent tous vers les buts préalablement définis. Et c’est la même similitude au rugby pour avancer le ballon pendant une « mêlée ». Scrum fait partie des approches itératives et incrémentales dont le modèle de cycle de développement est basé sur une phase qui se répète plusieurs fois successivement. C’est la notion d’itération ou « sprint » dans Scrum (cf. Figure 2). Figure 2 : Structure de la méthode SCRUM Tous les sprints se déroulent selon le même schéma, et on y fait à chaque fois les mêmes types de travaux. Avec une méthode agile comme Scrum, les activités de spécifications et de conception sont continues, et on part du principe que l’architecture va évoluer, dans une certaine limite, pendant la vie du projet. Figure 3 : Déroulement des sprints Tout au long du projet du projet, nous avons eu à réaliser plusieurs sprints. La durée de ces sprints variait énormément en fonction de leur complexité.  Gestion des sites et des axes de transport ;  Gestion des ordres de service et des dépêches ;  Gestion du suivi des dépêches ;  Gestion des acteurs et des rôles de sécurité ;  Gestion du reporting ;  Paramétrage du module de Ressources Humaines ;  Paramétrage du module de Parc Automobile.
  • 25. Chapitre 3 : Plan d’Assurance Qualité (PAQ) - 25 - Ces sprints ont été réalisés de manière chronologique et ont nécessité la participation de tous les acteurs du projet. II.3. Les acteurs au cœur du projet Dans un projet Scrum, les différents acteurs doivent être répartis en fonction de trois rôles essentiels : le ScrumMaster, le ProductOwner, et l’équipe. a. Le ScrumMaster Il joue le rôle de médiateur entre les membres de son équipe et le client lorsque cela s’avère nécessaire. Un client mécontent aura affaire par exemple au ScrumMaster, qui trouvera un compromis entre les deux parties. Dans notre projet, ce rôle a été joué l’assistant du maitre d’ouvrage. Il faisait l’intermédiaire entre nous, qui formons l’équipe, et le représentant des futurs utilisateurs de l’application. b. Le ProductOwner Il est le représentant dans l’équipe de toutes les personnes qui utiliseront l’application. Il est chargé de définir l’objectif du projet et de le partager avec l’équipe qui le développe. Pour cela, il identifie les fonctionnalités requises dont a besoin l’application, puis les collecte dans une liste appelée « backlog de produit ». Durant notre stage, ce rôle fut joué par le maitre d’ouvrage du projet. c. L’équipe L’équipe est composée des « techniciens » qui vont travailler sur le projet, guidé par le ScrumMaster et aidé par le ProductOwner. Elle a le rôle principal puisque c’est elle qui développera l’application au cours des sprints. Nous avons formé cette équipe avec la participation de la Direction du Poste Numérique et Télécom. En d’autres termes, le rôle de l’équipe a été joué par la maitrise d’œuvre du projet. Des réunions sont organisées régulièrement lors de chaque sprint, afin de faire des mises au point, sur l’état d’avancement et sur de possibles améliorations à prendre en compte. Pour conclure, nous pouvons dire que Scrum est un bon cadre de gestion de projets. Elle ne préconise aucune pratique d’ingénierie pour garantir la qualité d’un produit. Sa flexibilité pendant la réalisation et son cadre de travail y fait sa force. Elle imite le principe de l’état d’esprit du rugby : avancer tous ensemble vers un but commun. Ce dernier faisant ainsi référence à la réussite du projet.
  • 26. Chapitre 3 : Plan d’Assurance Qualité (PAQ) - 26 - III. Planification du projet La planification constitue l’une des étapes primordiales dans le déroulement d’un projet. Elle consiste à prévoir le déroulement des différentes phases du projet, en fonction des besoins exprimés dans le cahier de charges et de la méthode de travail utilisée. Ces diverses phases constituent des sprints, dans lesquelles nous devons réaliser un livrable du produit. Autrement dit, nous devons développer dans chaque sprint un fragment de l’application, à travers une analyse des spécifications des besoins, du codage, ainsi que des tests unitaires. Au début du stage, nous avons réalisé une planification prévisionnelle du projet, dans laquelle nous avons estimé les durées de réalisation possible pour chaque sprint. Ces durées, exprimées en nombre de jours ouvrables de la semaine sont représentées dans le diagramme de Gantt prévisionnel ci-dessous (cf. Figure 4). A la fin du stage, nous avons mis en place une planification définitive qui relate les détails de ce qui a été réalisé pendant le déroulement du projet. Cette planification a été illustrée dans le diagramme de Gantt définitif représenté un peu plus bas (cf. Figure 5). Quelques écarts ont été remarqués après une comparaison des deux planifications réalisées. Cela s’explique par le fait que certaines parties furent plus difficiles que d’autres, et ont demandé ainsi plus de ressources (temps, recherches, etc.). Les écarts majeurs ont été remarqués au niveau de la gestion des ordres de services, la gestion du suivi des dépêches et le reporting.  La gestion des ordres de service Initialement prévu pour six jours ouvrables, la gestion des ordres des ordres de services a nécessité autant de jours supplémentaires pour sa mise en place. En effet, la compréhension et la mise en place du système de workflow n’a pas été une chose aisée. Il nous était difficile de trouver un document qui explique correctement son intégration dans un module OpenERP. Quand bien même on trouvait des documentations officielles, celles-ci se limitaient à nous expliquer les bienfaits et avantages qu’auront les workflows dans notre système d’information, et non comment les mettre en place. Après plusieurs jours de recherches, nous avons décidé de coupler les réponses approximativement recueillies dans les forums dédiés, au code d’un module OpenERP utilisant déjà les workflows, « purchase ». Par la suite, nous avons pu surmonter cette difficulté, mais avec un retard sur la planification initiale. (cf Figure 4 et 5)  La gestion du suivi des dépêches Celle-ci fut réalisée en deux temps : la gestion de suivi de base, et la gestion des contraintes liés aux diverses règles métiers. Elle a accusé un retard de deux jours ouvrables par rapport à la planification initiale. La première a été réalisée dans les temps car elle ne présentait pas de difficultés particulières. Quant au second, elle nécessitait l’appellation de plusieurs fonctions pythons en arrière-plan. En effet, notre utilisation du python jusque-là était limitée à la création de classes des différents objets. L’heure était venue pour nous de créer nos propres
  • 27. Chapitre 3 : Plan d’Assurance Qualité (PAQ) - 27 - fonctions pour les incorporer dans les vues XML. Cela nous a pris un peu plus de temps car il fallait trouver une manière d’intégrer et d’appeler les fonctions pythons dans le module. (cf. Figure 4 et 5)  Le reporting Prévu initialement pour cinq jours, la gestion du reporting a duré finalement sept jours ouvrables. Cela est dû aux tests effectués sur plusieurs outils de reporting. En effet, afin de pouvoir générer des documents en PDF, nous avons eu recours à un certain nombre d’outils. Tout d’abord nous avons opté pour l’OpenOffice. Cela s’est avéré ne pas être un succès, puisque ce dernier était très limité en ce qui concerne la mise en forme des données. Ensuite, nous avons survolé d’autres outils tels « Pentaho reports », « wkhtmltopdf », «Geraldo Reports » par manque de tutoriels expliquant correctement leurs modes de fonctionnement. Au final, notre choix s’est porté sur « Jasper Reports », qui en plus de générer des documents en PDF, nous proposait toute une panoplie d’extensions possibles. L’essai de presque tous ces outils a ainsi occasionné une énorme perte de temps par rapport à la planification initiale. Figure 4 : Diagramme de GANTT prévisionnel
  • 28. Chapitre 3 : Plan d’Assurance Qualité (PAQ) - 28 - Figure 5 : Diagramme de Gantt définitif
  • 29. Chapitre 3 : Plan d’Assurance Qualité (PAQ) - 29 - IV. Risques Tout projet, du fait même de son caractère unique, comporte une part de risques dont la nature peut être variée (techniques, juridiques, sociaux, humains, etc.). Il est donc primordial d’effectuer une étude avant le début du projet, en vue de mesurer les risques particuliers qui y sont liés. Les principaux risques que nous avons pu déceler sont les suivants. Risques 1 Probabilité 2 Impacts Mesure de maitrise Développer en OpenERP OpenERP était une nouvelle technologie que l’on ne connaissait pas et dont la documentation ou les forums d’aides dédiés étaient rarissimes. avérée fort Ce risque a été maitrisé par une auto-formation technique en OpenERP. Non connaissance du langage python OpenERP est majoritairement développé en python. La connaissance du python était essentielle pour le développement spécifique d’un module avérée moyen La lecture de tutoriels nous a permis de surmonter cette difficulté Risque de choix de la méthode de travail C’était la première fois que nous devons utiliser SCRUM dans un projet, ou d’une méthode agile en général. probable faible La présence dans l’équipe d’un utilisateur expert en Scrum a permis de nous guider lors des différentes étapes au cours des sprints Risque humain L’application à réaliser permet de suivre les différents mouvements des employés. Le siège pourra surveiller les différentes activités de ses employés (les retards engendrés, la non concordance entre l’itinéraire à effectuer et le carburant utilisé, le non –respect du tableau d’acheminement). Cela peut inciter les employés à saisir de fausses informations pour saboter les données de l’application. probable faible Il peut être maitrisé par la formation, la sensibilisation et l’accompagnement des employés lors du déploiement 1 Probabilité que ce risque se réalise 2 L’impact de ce risque pour le bon déroulement du projet
  • 30. Chapitre 3 : Plan d’Assurance Qualité (PAQ) - 30 - Conclusion du chapitre A travers ce chapitre, nous avons mis en place le plan d’assurance qualité dans laquelle nous avons exposé notre organisation, la méthode de travail adoptée, la planification prévisionnelle et définitive ainsi que les risques possibles que nous pourrions rencontrés. Ce chapitre scellait aussi par la même occasion la dernière phase de cette première partie. Conclusion de la partie Dans cette partie, nous avons présenté le projet dans son contexte général en mettant en évidence ses objectifs majeurs, et la conduite à utiliser pour le mener à bien. La partie suivante consistera à une étude fonctionnelle ainsi qu’une conception détaillée des besoins de l’organisme.
  • 31. Partie II : Etude fonctionnelle et conception Introduction de la partie Dans cette partie, il est question d’effectuer une étude approfondie du système à mettre en place. Cela passe par une analyse simultanée de l’existant et du cahier de charge, afin de mettre en évidence le besoin d’un nouveau système capable de répondre aux exigences de l’entreprise. Ainsi, nous allons, dans un premier temps, faire l’étude préalable qui consiste à recenser l’existant, et les insuffisances du système actuel en vue de proposer des solutions adéquates. Ensuite, nous entamerons la seconde phase où nous allons effectuer une étude fonctionnelle. Dans celle-ci, nous présenterons les différents acteurs de l’application, ainsi que les besoins fonctionnels à satisfaire. Nous clôturerons par la suite cette partie, par une présentation d’une conception détaillée de l’application, à l’aide de diagrammes UML.
  • 32. Chapitre 1 : Etude préliminaire Introduction du chapitre Cette étude consiste essentiellement à étudier la faisabilité du projet. Nous allons premièrement faire une analyse de la façon dont sont gérées les activités du pôle courrier. Ensuite, nous allons évoquer les faiblesses rencontrées dans cette démarche, avant de proposer des solutions à appliquer pour améliorer le fonctionnement du système actuel. I. Etude de l’existant La première étape de l’étude préalable consiste à mettre en évidence le fonctionnement actuel du système, à savoir les différentes actions mises en jeu lors de l’acheminement d’un courrier. Pour une bonne compréhension du processus actuel, certaines notions indispensables sont à définir. I.1. Définitions de quelques concepts clés a. Organisation La gestion des activités du pôle courrier de BAM est assurée par trois principales couches : le siège, les régions et les sites. En effet, suivant un découpage propre à Barid Al Maghrib et non suivant le découpage administratif, le Maroc a été divisé en plusieurs régions. Ces régions ont sous leurs responsabilités les différents sites qui leur sont affectés. Ces sites peuvent être des centres de traitement et de distribution (CTD), des agences, un centre de courrier international(CCI), etc. Le siège, quant à lui, a le dernier mot dans les différentes activités effectuées. Il coordonne les opérations des différentes régions, qui, à leur tour assurent une meilleure cohésion des tâches au niveau des sites. b. Ordre de service Un ordre de service est une décision qui précise les modalités d’exécution de tout, ou d’une partie des prestations qui déterminent le fonctionnement de Barid Al Maghrib. Il est traduit sous forme de documents où sont consignées toutes les informations nécessaires à son exécution. Ces informations sont entre autres :  La fréquence d’envoi des dépêches dans la semaine ;  les horaires de départs et d’arrivées théoriques des dépêches ;  la date d’effet : la date à partir de laquelle, l’ordre de service doit être mis en exploitation ;
  • 33. Chapitre 1 : Etude préliminaire - 33 -  les axes de transport ;  le véhicule qui sera utilisé pour le transport et le convoyeur qui est associé. Un ordre de service n’a pas de date d’expiration. Cependant, son arrêt peut être explicitement demandé par un autre, et c’est à partir de l’instant précisé dans le nouvel ordre que l’ancien n’est plus valable. Sa création peut être faite par le siège, mais aussi par les régions. Dans le cas d’une région, une validation par le siège est obligatoire avant que celui-ci devienne actif. Elle doit être faite avant sa mise en exploitation. (Annexe II) c. Dépêche Une dépêche est constituée d’un ensemble d’envois, formés par un site à destination d’un autre. Elle peut être créée par le siège mais aussi par les régions. Lors de sa création par une région, elle doit être obligatoirement validée par le siège avant d’être exploitable. Cette création intervient suite à l’approbation d’un ordre de service. Après validation, elle est considérée comme active, tant qu’un ordre de service émis ne sollicite explicitement sa désactivation. Classifiée selon des types prédéfinis, son acheminement est réalisé par des moyens de transport, via un envoi direct ou par l’intermédiaire d’un transit ou de plusieurs transits. Les types de dépêche peuvent être : Lettre et Carte (LC), Autre Objet(AO), etc. d. Moyens de transport Un moyen de transport désigne, dans son sens le plus général, un outil utilisé par l’Homme afin de se déplacer d’un point A à un point B. Barid Al Maghrib possède plusieurs types de moyens de transport. Nous pouvons citer :  Les Véhicules de service Ce sont des véhicules confiés par Barid Al Maghrib à certains salariés pour les besoins d’acheminement. Ces véhicules peuvent être des voitures, des fourgonnettes, des camions, ou même des motos. Chaque véhicule de service appartient à un site spécifique. Il est lié à un chauffeur ou conducteur qui est censé en prendre soin.  Les transporteurs agréés Ils représentent les transporteurs nationaux tels que : CTM, STCR, ou ONCF, mais aussi les compagnies aériennes. Barid Al Maghrib adopte l’utilisation de ses transporteurs agréés dans le cas où leur coût de transport des dépêches sur une distance est inférieur à celui des véhicules de service.
  • 34. Chapitre 1 : Etude préliminaire - 34 -  Les transporteurs Rekkas Ces types de transporteurs sont sollicités, lorsque Barid Al Maghrib décide de faire appel à des personnes et non à des sociétés de transport. Dans ce cas, un contrat est signé avec ces personnes pour assurer le transport et la sécurité des dépêches à transporter. La manière dont ces dépêches vont être transférées importe peu. Les Rekkas, ou tout simplement les individus sous contrat de transport avec Barid Al Maghrib, se portent garant pour transmettre les dépêches dans les délais indiqués. Nous pouvons distinguer les Rekkas gérant et les Rekkas distribution. e. Les axes de transport Les axes de transport désignent les différents trajets que peut prendre un véhicule à partir d’un site donné. Ils sont définis par un certain nombre de caractéristiques tels que la distance, le type de l’axe, les sites ou entités de départ et d’arrivée, etc. f. Table d’acheminement 235 La table d’acheminement 235 est présentée sous forme d’un tableau récapitulatif de tous les termes définis ci-dessus. En d’autres termes, elle regroupe toutes les dépêches créées après que les ordres de services aient été validés. Pour une dépêche donnée, nous pouvons y observer la fréquence d’envoi, le moyen de transport utilisé, l’axe de transport emprunté, les horaires de départs et d’arrivées théoriques et réelles. (Annexe III) I.2. Processus actuel de l’acheminement courrier Le processus de l’acheminement courrier à Barid Al Maghrib suit la logique du tableau 235. En effet, après la création des dépêches issue des ordres de services, les informations du tableau d’acheminement ne varie pas jusqu’à la signature d’un autre ordre de service. Tous les jours, des dépêches sont envoyées d’un site à un autre, d’une ville à une autre, d’une région à une autre. Nous pouvons considérer l’exemple suivant issu d’une ligne du tableau. « Des dépêches seront envoyées tous les lundi au vendredi d’un site de Rabat à un site d’Agadir à partir de 23h30 à bord d’un véhicule de service, en faisant escale à Casablanca. Ce véhicule devrait arriver aux environs de 06h ». Afin de respecter cet ordre émanant du siège général, et retranscrit dans le tableau 235, le chef du site signera durant la soirée, une décharge indiquant le départ du véhicule de son site. A la réception des dépêches à Agadir, son homologue en fera pareille en signant une autre décharge. Ces différentes décharges signées révéleront ensuite les retards effectués par les chauffeurs et les raisons avancées expliquant ces retards.
  • 35. Chapitre 1 : Etude préliminaire - 35 - A la fin de la journée, un rapport est effectué au sein des sites sur les différents départs et arrivés qui ont eu lieu. Ces rapports, stockés dans des fichiers Excel, seront transmis au siège pour un bilan des activités et s’assurer de la qualité du travail réalisé. Dans le cas d’un arrêt dans un site donné, des dépêches pourront être déposées en vue d’un transfert futur si elles devaient y faire escale, et d’autres pourront y rester si c’était leurs destinations. En résumé, tout dépendra de ce qui est prévu dans le tableau 235. (cf. Annexe III.) Tel est le processus actuel de l’acheminement des courriers au sein de Barid Al Maghrib. Les limites de ce processus seront le prochain point que nous allons aborder afin de proposer des solutions aux problèmes rencontrés. II. Critique de l’existant L’une des difficultés majeures que rencontre ce système est la « non centralisation des données ». Cela empêche la mise en place de statistiques explicatives du fonctionnement global de l’entreprise. Ces statistiques peuvent être entre autre la connaissance du degré d’exécution du tableau d’acheminement 235, du taux d’incidents rencontrés dans chaque site. En effet, les sites gèrent indépendamment les différents acheminements et ont leur propre base de données qu’ils mettent à jour librement. Ils utilisent Excel pour conserver les informations des différents acheminements et ce, de façon journalière. Cela augmente le nombre de fichiers à leur disposition. Les sites doivent envoyer ces fichiers au siège qui se retrouve ainsi avec un trop grand nombre de fichiers à gérer. L’utilisation des fichiers Excel peut occasionner des pertes lors des transferts vers le siège, ou même des erreurs de saisie. Ces erreurs de saisie peuvent amener deux situations possibles. Le problème peut être détecté, et dans ce cas, le fichier est corrigé et renvoyé au siège. Dans le cas contraire, cela peut avoir des conséquences sur les décisions futures à prendre. On observe ainsi une perte de temps considérable entre les différents transferts de fichiers en comparaison à un système où aucun transfert ne sera nécessaire du fait de la centralisation des données. D'ailleurs, en ce qui concerne le transfert des fichiers, il arrive que des sites ne les effectuent pas. Un exemple concret de conséquence sur le non transfert des fichiers, est la réaffectation d’un salarié à un autre site. Le siège n’étant pas informé, peut toujours envoyer des articles (tenues, chaussures) au salarié. Les articles seront redirigés vers le site approprié, mais avec un effort supplémentaire. Aussi, le siège éprouve souvent du mal à réagir efficacement face à certaines demandes. Par exemple, il arrive qu’une demande de ravitaillement en carburant soit incomprise par le siège étant donné qu’il n’a aucune idée sur l’utilisation de ce carburant.
  • 36. Chapitre 1 : Etude préliminaire - 36 - Il est à noter qu’il est souvent impossible d’utiliser ces fichiers Excel pour la réalisation de certaines tâches. Sur la base du fonctionnement actuel, il n’existe aucune possibilité de connaitre la position des véhicules. Pourtant cela pourrait s’avérer très utile dans certaines situations d’urgences. Par exemple, le système pourra aider à connaitre rapidement la position d’un véhicule en cas d’incident sur un axe de transport, grâce à son GPS. En résumé, les difficultés liées à la méthode actuelle sont :  Non centralisation des données ;  Données non protégées ;  Nombre trop élevé de fichiers Excel à gérer ;  Perte de temps considérable ;  Possibilité d’incohérence des données entre le siège et un site donné ;  Difficulté de réaction prompte et efficace de la part du siège ou des sites ;  Risque de perte de fichiers ;  Aucune statistique pour mieux comprendre le fonctionnement des différents sites ;  Pénurie de carburant due à la création abusive des dépêches (sans informer le siège). III. Solution apportée Au vue des limites du système existant, nous sommes amenés à proposer des solutions qui répondent aux objectifs de Barid Al Maghrib et qui par la même occasion, pallient aux lacunes répertoriées. Cette résolution peut se présenter sous trois points : la partie gestion, organisation et technique. III.1. La partie Gestion Cette partie consiste à développer un système basé sur plusieurs modules à savoir l’acheminement, le parc automobile, et les ressources humaines. Les principaux objectifs de ce système seront :  Utilisation des profils pour mieux gérer les droits d’accès aux fichiers : Cela permettra aux utilisateurs de n’avoir accès qu’aux données dont ils ont le privilège ;  Mise en place d’un circuit de validation des dépêches et des ordres de services, intégrant les acteurs (Responsables de l’acheminement au niveau du siège et des régions) ;
  • 37. Chapitre 1 : Etude préliminaire - 37 -  L’abandon de fichiers Excel : Le passage des fichiers Excel aux bases de données constitue une des plus grandes évolutions du système. Cela résoudra les problèmes liés aux pertes de temps, aux transferts de fichiers avec des erreurs, au nombre trop élevé de fichiers à gérer, etc. ;  Mise en place d’un système de reporting : pour la création des rapports permettant de mieux appréhender les voies et moyens pour accroitre le rendement de Barid Al Maghrib. Ces rapports pourront être générés au format PDF ;  Interface de gestion de l’acheminement courrier : pour un meilleur suivi des dépêches en apportant des solutions aux différents problèmes y afférant ;  Gestion du parc automobile : pour une meilleure gestion des véhicules et des chauffeurs qui y sont affectés. Cela permettra de résoudre les problèmes dû aux demandes de ravitaillement du carburant non comprise par le siège, ou plus généralement les incidents qui surviennent lors des transferts des dépêches ;  Fonction de messagerie : pour assurer la communication entre les différents acteurs du système ;  Gestion de ressources humaines. III.2. La partie Organisation En termes d’organisation, ce système serait capable d’assurer une meilleure répartition entre les différents intervenants, leur offrir des espaces personnels, et aussi leur permettre un accès facile ainsi qu’une coordination. III.3. La partie Technique Pour le développement des fonctionnalités susmentionnées, la Direction de la Poste Numérique et Télécom a mis à notre disposition une plateforme Open source. En effet, cette direction est chargée de l’ingénierie marketing et de la commercialisation de plusieurs services. Il existe plusieurs types d’ERPs Open Source. Celui utilisé par la direction de la Poste Numérique et Télécom est l’OpenERP (cf. Technologies mises en œuvre). C’est est un logiciel offrant plusieurs fonctionnalités telles que la gestion comptable et financière, la gestion de la production, la gestion des achats, la gestion des stocks, la gestion des ressources humaines, etc. Malgré la non-couverture de toutes les activités requises, OpenERP permet le développement de modules personnalisés. Ce qui nous permettra de couvrir au maximum les fonctionnalités attendues de l’application.
  • 38. Chapitre 1 : Etude préliminaire - 38 - Conclusion du chapitre Cette étude nous a permis de passer en revue le fonctionnement présent de l’acheminement des dépêches à travers une étude de l’existant. Nous avons fait des propositions pour résoudre certaines difficultés rencontrées. Notre étude ayant été validée, nous pouvons maintenant passer à la phase de spécifications qui feront l’objet du chapitre suivant.
  • 39. Chapitre 2 : Etude fonctionnelle Introduction du chapitre Ce point consistera à présenter l’application à développer en termes de fonctionnalités offertes. Il présentera le système qui répond aux besoins exprimés par le client. L’étude fonctionnelle construit l’édifice qui sert de contrat entre le client et le prestataire d’une solution informatique. Par ce contrat, le client reconnait que ses besoins sont satisfaits et le prestataire s’engage à fournir un produit conforme. I. Spécifications des besoins fonctionnels L’étude préalable a montré les défauts que présente le système de gestion actuel. Elle a également présenté les besoins du client en termes de fonctionnalités. Ce présent point a pour but de spécifier un système conforme aux besoins exprimés par les utilisateurs. Ces derniers pourront effectuer les tâches suivantes. I.1. Gestion des ordres de services La gestion des ordres de services permettra la création, la modification, la suppression et la validation d’un ordre de service. L’ordre ainsi créé sera soumis à la validation d’un utilisateur ayant un rôle spécifique. De même, un ordre de service peut être supprimé si au bout d’un certain temps, sa validation n’est pas acquise, ou modifié si cela est explicitement demandé au travers de l’application. En outre, il est fondamental que les utilisateurs puissent consulter les ordres de services créés afin de savoir les différentes caractéristiques associées, pour pouvoir prendre les décisions appropriées. I.2. Gestion des dépêches La gestion des dépêches suit le même principe que celle des ordres de services. Cependant une dépêche est liée forcément à un ordre de service préalablement créé. On dit donc qu’une dépêche est la concrétisation de l’exécution d’un ordre de service. I.3. Gestion des suivis de dépêches Pour une dépêche créée, il faut assurer son acheminement de l’entité de départ à l’entité d’arrivée. Entre ces deux sites, il peut y avoir des points de transit qui assureront l’aiguillage de la dépêche à la bonne destination. La gestion de suivi consistera ainsi à recueillir les différents horaires possibles, pour en déduire les retards et les statistiques éventuels.
  • 40. Chapitre 2 : Etude fonctionnelle - 40 - I.4. Gestion du parc automobile Le parc automobile est constitué d’un ensemble de véhicules faisant objet de contrat avec les fournisseurs et nécessitant des interventions (réparations). Ces interventions peuvent engendrer divers coûts. Cette fonctionnalité a pour but de fournir un moyen efficace pour s’assurer du bon déroulement de l’acheminement des dépêches. I.5. Gestion des ressources humaines Les ressources humaines sont ce qu’il y’a de fondamental dans une entreprise. Toutes les activités de l’entreprise en dépendent. Une bonne organisation des ressources humaines (affection optimale des postes, affectation au site) assure la prospérité de l’entreprise. Il est donc plus que crucial de fournir à l’entreprise, un outil de gestion des employés. Cet outil permettra entre autres l’ajout des employés en leur affectant des sites, l’attribution des identifiants de connexion, la gestion du processus de recrutement, la gestion des congés, la gestion du système de pointage, etc. I.6. Gestion de l’édition des rapports L’édition des rapports est introduite pour donner un moyen de mesurer les performances de Barid Al Maghrib (BAM), au travers des différentes statistiques significatives. Ces statistiques permettront à BAM de connaitre les différentes difficultés rencontrées dans la gestion de l’acheminement et de prendre ainsi des décisions adéquates. L’édition de rapport consiste également en l’impression de document papier. Par exemple, un chauffeur qui assure le transport d’une dépêche aura besoin d’un document papier de l’ordre de services afin de savoir ce qu’il lui incombe d’accomplir comme tâches. Les différents besoins exprimés nous conduisent à la nécessité de pouvoir distinguer les personnes qui vont se servir du système pour une raison ou une autre. Dans ce but, nous allons créer des acteurs et les rôles qui leur seront affectés. Ainsi, un acteur ne pourra faire que ce dont il est habilité. II. Identification des acteurs et les rôles Les acteurs sont les utilisateurs du système. Ils sont désignés par le maitre d’ouvrage. Chaque acteur doit être nommé, mais, pour trouver son nom, il faut penser à son rôle. En en effet, un acteur représente un ensemble cohérent de rôles joués vis-à-vis d’un système.
  • 41. Chapitre 2 : Etude fonctionnelle - 41 - Nous avons pu identifier quatre acteurs qui pourront interagir avec l’application. Ces acteurs sont : Responsable acheminement site, Responsable acheminement région, Responsable acheminement siège et administrateur. II.1. Responsable acheminement site Il aura un pouvoir de supervision sur toutes les activités relevant de son site uniquement. C’est un utilisateur qui aura le privilège de :  attribuer des tâches à ses subordonnés ;  vérifier les départs et les arrivés de dépêches dans son site et d’en informer le siège en cas de besoin ;  créer une instance pour suivre les dépêches originaires de son site ;  générer des rapports. Tout cela s’effectue à travers un espace personnel, lui garantissant ainsi une meilleure gestion et une vue plus globale de son site. II.2. Responsable acheminement région Il a principalement un rôle de :  Consultation des activités des sites ;  Gestion des employés ;  Gestion des véhicules ;  Gestion des ordres de services ;  Gestion des dépêches. Il est important de noter que ce responsable ne peut gérer que ce qui est propre à sa région. Il dispose à son tour d’un espace personnel qui lui permettra de gérer efficacement les sites liés. Un ordre de service ou une dépêche créée par la région doit être soumis à la validation du siège avant d’être opérationnel. II.3. Responsable acheminement siège Il a le plein pouvoir quant à la gestion de l’acheminement des dépêches sur toutes les régions et sur tous les sites. Il possède aussi un espace personnel lui permettant une meilleure gestion de la flotte et de l’acheminement des courriers.
  • 42. Chapitre 2 : Etude fonctionnelle - 42 - II.4. L’administrateur La maintenance et la gestion du système mis en place seront faites par l’administrateur. En effet, ce dernier s’occupera non seulement de la gestion des utilisateurs dans le système, mais aussi d’une révision périodique des fonctionnalités de l’application pour s’assurer de leurs bons fonctionnements. Un système informatique, c’est un ensemble d’acteurs et de rôles joués. Pour une meilleure assimilation des points évoqués plus haut, nous allons utiliser un langage de modélisation graphique. Le choix de la modélisation s’est porté sur le langage UML. C’est un langage utilisé en développement logiciel, et en conception orientée objet. Les composantes qui nous intéressent dans ce présent document sont : le diagramme de classe, le diagramme de séquence et le diagramme de cas d’utilisation. Le point suivant portera sur le diagramme de cas d’utilisation. III. Diagrammes de cas d’utilisation UML permet de formaliser les besoins, c’est-à-dire de les représenter sous une forme graphique suffisamment simple pour être compréhensible par toutes les personnes impliquées dans le projet. Souvent le maître d’ouvrage et les utilisateurs ne sont pas des informaticiens. Il leur faut donc un moyen simple d’exprimer leurs besoins. C’est précisément le rôle des diagrammes de cas d’utilisation. Ils permettent de recenser les grandes fonctionnalités d’un système. Dans la suite du rapport, nous allons concevoir les diagrammes des cas d’utilisation selon les attentes en termes de fonctionnalités pour chaque acteur. Les plus importants cas d’utilisation seront décrits à l’aide de scenarios, ou d’un diagramme de séquence. III.1. Diagramme des cas d’utilisation de « Site » Les sites sont l’objet même de la nécessité d’un système de gestion centralisé. Pour chaque site, il y’a un acteur « Responsable acheminement site » qui pourra effectuer les tâches comme nous l’avons spécifié lors de l’identification des acteurs. Le diagramme de cas d’utilisation correspondant à cet acteur est le suivant (cf. Figure 6).
  • 43. Chapitre 2 : Etude fonctionnelle - 43 - Figure 6 : Diagramme des cas d'utilisation "site" Description du cas d’utilisation « Gérer le suivi des dépêches » Identification Nom du cas : Gérer le suivi des dépêches But : détail des points pour permettre à un responsable de site d’assurer l’acheminement des dépêches dont son site en est le point origine ou un point transit. Acteur Principal : Responsable acheminement site Séquencement Le cas d’utilisation commence quand le chef de site souhaite créer ou modifier un suivi de dépêche. Préconditions le système est lancé, le responsable est authentifié et le site est gestionnaire ou le point de transit d’au moins une dépêche.
  • 44. Chapitre 2 : Etude fonctionnelle - 44 - Enchaînement nominal : 1. Le responsable veut créer un suivi pour une dépêche 2. Il sélectionne la dépêche objet du suivi 3. Il renseigne l’heure de départ de la dépêche 4. Le système vérifie que la dépêche peut être envoyée à l’heure de départ saisie 5. Le système affecte un numéro au suivi et l’enregistre 6. Terminer le traitement Scénario alternatif 1 : Il démarre au point 4 de l’enchaînement nominal. 4. A. la dépêche ne peut pas être envoyée à l’heure de départ saisie 1. le système affiche une notification pour indiquer une violation de contrainte sur l’heure de départ saisie 2. revenir au point 3 de l’enchaînement nominal Scénario alternatif 2 : Il démarre au point 1 de l’enchaînement nominal 1. Le responsable veut modifier un suivi créé pour un autre site 2. Le système vérifie que le site auquel appartient le responsable est bien le point de destination de la dépêche 3. il renseigne l’heure d’arrivée de la dépêche 4. Le système vérifie que l’heure d’arrivée est supérieure à l’heure de départ 5. Terminer le traitement Scénario alternatif 3 : Il démarre au point 4 du Scénario alternatif 2. 4. A. l’heure d’arrivée est inférieure à l’heure de départ 1. le système affiche une notification pour indiquer une violation de contrainte sur l’heure de d’arrivée 2. revenir au point 3 du Scénario alternatif 2 Scénario alternatif 4 : Il démarre au point 2 du Scénario alternatif 2 2. A. le site de l’utilisateur connecté est un point de transit de la dépêche
  • 45. Chapitre 2 : Etude fonctionnelle - 45 - 1. il saisit l’heure d’arrivée de la dépêche dans son site et celle de départ de son site 2. revenir au point 5 du Scénario alternatif 2 Post-conditions Une interface pour le suivi de la dépêche est créée pour permettre aux différents sites concernés par la dépêche d’interagir pour son acheminement. III.2. Diagramme des cas d’utilisation de « Région » Pour rappel, La région est constituée d’un ensemble de sites. Le responsable acheminement région a donc sous sa responsabilité les sites liés. Son principal rôle est d’assurer la gestion de la création des dépêches, des ordres de services et des axes de transport. Le diagramme correspondant aux possibilités offertes à un responsable de région est le suivant : Figure 7 : Diagramme de cas d'utilisation "région"
  • 46. Chapitre 2 : Etude fonctionnelle - 46 - Description du cas d’utilisation « Gérer les dépêches de sa région» Identification Nom du cas : Gérer les dépêches de sa région But : Permettre à une région de créer, supprimer, modifier ou consulter une dépêche Acteur Principal : le responsable acheminement région Séquencement Préconditions : le système est lancé, le responsable est authentifié Enchaînement nominal : 1. Il choisit l’opération à effectuer 2. Il veut créer une dépêche 3. Il fournit les informations 4. Il valide les saisies 5. Le système attribut un code à la dépêche et l’enregistre 6. Terminer le traitement Scénario alternatif 1 : Il démarre au point 2 de l’enchaînement nominal. 2. A. Il veut modifier une dépêche 1. Il sélectionne la dépêche 2. Il modifie les informations souhaitées en prenant soins d’ajouter un message d’explication 3. Il change l’état de la dépêche 4. revenir au point 6 de l’enchaînement nominal Scénario alternatif 2 : Il démarre au point 2 de l’enchaînement nominal 2. A. le responsable veut supprimer une dépêche 1. Il sélectionne la dépêche 2. Il valide la suppression 3. Le système vérifie les contraintes de dépendance sont respectées 4. Le système supprime la dépêche 5. aller au point 6 de l’enchaînement nominal Scénario alternatif 3 :
  • 47. Chapitre 2 : Etude fonctionnelle - 47 - Il démarre au point 3 du Scénario alternatif 2 : 2. A. la dépêche est utilisée dans le système 1. Le système affiche une notification pour signaler que la dépêche ne peut être supprimée. 2. aller au point 5 du Scénario alternatif 2 Post-conditions On devrait se retrouver avec une dépêche en moins en cas de succès ou aucun changement en cas d’échec. NB : La gestion des ordres de service suit la même description que celle des dépêches. La figure suivante (cf. Figure 8) présente le diagramme de séquence pour le cas d’utilisation « s’authentifier ». Figure 8.: Diagramme de séquence pour le cas d’utilisation « s’authentifier »
  • 48. Chapitre 2 : Etude fonctionnelle - 48 - La figure 9 représente le diagramme de séquence pour le cas d’utilisation « Gérer les axes de transport » Figure 9 : Diagramme de séquence pour le cas d’utilisation « Gérer les axes de transport »
  • 49. Chapitre 2 : Etude fonctionnelle - 49 - III.3. Diagramme des cas d’utilisation « Siège » Le responsable de siège a pour principales missions, la gestion des validations des ordres de services, des dépêches ou des axes de transport créés au niveau régional. Il pourra également effectuer d’autres tâches qui sont précisées dans le diagramme de la figure 10. Figure 10 : Cas d'utilisation "siège"
  • 50. Chapitre 2 : Etude fonctionnelle - 50 - Description du cas d’utilisation « Valider l'ordre de service ou la dépêche créé par la région» Identification Nom du cas : Valider l'ordre de services ou la dépêche créé par la région But : Permettre la validation des dépêches ou des ordres de services créés par les régions Acteur Principal : le responsable acheminement siège Séquencement Préconditions : le système est lancé, le chef de siège est authentifié Enchaînement nominal : 1. Il sélectionne un ordre de service ou une dépêche 2. Il vérifie qu’il n’y a aucun problème sur l’objet (dépêche ou ordre de service) 3. Il valide les saisies 4. Le système change l’état de l’objet 5. Terminer le traitement Scénario alternatif 1 : Il démarre au point 2 de l’enchaînement nominal. 2. A. il y’a un problème 1. Il rejette l’objet 2. Il rédige un message 3. Le système enregistre 4. revenir au point 5 de l’enchaînement nominal Post-conditions On devrait se retrouver avec une dépêche ou un ordre de services validé. En cas de rejet un message obligatoire justifiant le rejet est rédigé.
  • 51. Chapitre 2 : Etude fonctionnelle - 51 - III.4. Diagramme du cas d’utilisation « Administrateur » Le diagramme correspondant à l’administrateur est illustré par la figure 11 : Figure 11 : Cas d'utilisation "administrateur" Conclusion du chapitre Ce chapitre nous a permis d’avoir une connaissance des différents profils d’utilisateurs qui vont utiliser l’application. Cette étude nous a offert une bonne base pour entamer le chapitre suivant, qui traitera les diagrammes de classes mettant en jeu des objets qui nous permettront d’expliquer une partie du fonctionnement de l’entreprise.
  • 52. Chapitre 3 : Conception Introduction du chapitre La conception correspond à la phase de modélisation du système à concevoir dans un langage de conception bien précis. Comme au chapitre précédent, nous utiliserons UML pour construire le diagramme de classes. Le choix de ce diagramme réside dans son utilité réelle pour la suite du projet. I. Diagramme de classes : Description Le diagramme de classes est considéré comme le plus important et est le seul à être obligatoire lors d’une modélisation orientée objet. Après avoir présenté les cas d’utilisation, nous avons vu qu’ils permettaient de représenter le système du point de vue des acteurs. Le diagramme de classe quant à lui présente la structure interne du système. Il permet de représenter de façon abstraite et statique, les objets qui vont interagir pour la réalisation des cas d’utilisation. Pour pouvoir tracer ce diagramme, il sera nécessaire de déterminer d’abord les objets manipulés qu’on représentera sous forme de classes ainsi que les différentes relations qui les lient entre elles. II. Diagramme de classes par métiers Lors des divers entretiens que nous avons effectués, il ressort que le système à développer devra permettre de réaliser les besoins exprimés dans la phase précédente. Pour une meilleure organisation et vu le nombre élevé de cas d’utilisation, nous allons raisonner principalement sur les grands points. II.1. Gestion des ordres de services Pour la gestion des ordres de services nous aurons besoin des entités suivantes :  Ordre : cette entité permettra de faire persister les Ordres de services ;  Vehicule : elle contiendra les informations sur les Véhicules ;  Entite : elle permettra de stocker les caractéristiques des sites, des régions et du siège ;  Ville : nous allons y renseigner toutes les villes concernées par les activités ;  Employe : cette entité permettra de gérer les employés ;  Message : pour expliquer les raisons d’un refus de validation d’un ordre de service ;  Frequence : la fréquence d’exécution de l’ordre de services ;  CarteCarburant : les Cartes de consommations de Carburant qui seront affectées au véhicule.
  • 53. Chapitre 3 : Conception - 53 - Pour un ordre de service, il ressort que nous voulons connaitre sa mission, ses heures de départ et d’arrivée, sa date de début de validité, son statut, son état, sa date de création, sa fréquence d’envoi dans la semaine. Un ordre de service met en relation plusieurs entités de l’entreprise et nous lui affectons un employé. Un véhicule est utilisé pour exécuter un ordre de services suivant un axe de transport. Un ordre de service créé par une région peut être rejeté. Dans ce cas, on lui associé un message détaillant les raisons du rejet. (cf. Figure 13) Figure 12 : Gestion des ordres de services L’utilisation de différentes couleurs, dans la figure 13, indique la différence avec les classes implémentées déjà dans OpenERP et celles que nous avons ajoutées. OpenERP possède déjà les classes : employee, department, vehicle d’où le nom en anglais. Pour éviter de refaire ce qui existe déjà, nous avons choisi d’utiliser l’héritage. L’héritage, nous permet d’avoir tous les attributs de la classe mère, auxquels on peut ajouter nos propres attributs. Nous allons dans la suite de cette partie, décrire les modèles OpenERP dont nos modèles ont héritées. Il s’agit des points 4 et 5 sur les ressources humaines et le parc automobile.
  • 54. Chapitre 3 : Conception - 54 - II.2. Gestion des dépêches Les entités qui vont être utiles pour cette partie sont :  Depeche : cette entité représente une dépêche avec tous ses attributs ;  typeDepeche : elle correspond au type d’une dépêche ;  Region : toutes les régions créées sont représentées dans cette entité ;  Entite : pour les entités qui y sont associées ;  Message : pour expliquer les raisons d’un refus de validation d’un ordre de service ;  Ordre : pour l’ordre de service associé ;  Ville : pour les villes qui y sont associées. Pour une dépêche, il y’a lieu de connaitre son statut et son état à savoir si elle est validée, non validée ou rejetée. Elle concerne des entités et est associée à un ordre de services. Chaque dépêche appartient à un type bien défini et nous pouvons lui joindre un message. (cf. Figure 15) Figure 13 : Gestion des dépêches II.3. Gestion des suivis de dépêches Les entités utilisées seront :  SuiviDepeche : cette entité permettra de stocker les informations pour suivre les dépêches ;  Entite : pour les entités associées ;  Depeche : pour les dépêches associées.
  • 55. Chapitre 3 : Conception - 55 - Pour pouvoir assurer le suivi des dépêches, nous avons besoins de connaitre, pour l’entité suiviDepeche, les attributs tels que : la date de création, les heures de départ et d’arrivée réelle des dépêches. (cf. Figure 14) Figure 14 : Gestion du suivi des dépêches II.4. Gestion des ressources humaines Cette partie donne lieu d’utiliser les entités :  Employee : les employés sont représentés à travers cette entité ;  employee_category : un employé appartient à une catégorie et plusieurs catégories existent ;  Department : les sites, les régions et le siège seront logiquement représentés par cette entité ;  User : pour permettre la connexion des utilisateurs, les informations seront stockées ici. Un employé travaille pour un département et peut y être responsable. Il peut avoir un mentor et peut également être lié à un utilisateur. Il appartient à au moins une catégorie. (cf. Figure 15)
  • 56. Chapitre 3 : Conception - 56 - Figure 15 : Gestion des ressources Humaines II.5. Gestion du parc automobile A ce niveau, il nous sera important de connaitre les informations suivantes :  Vehicle ;  vehicle_model : modèle du véhicule ;  vehicle_tag : étiquette de véhicule ;
  • 57. Chapitre 3 : Conception - 57 -  vehicle_log_services : intervention sur le véhicule ;  vehicle_log_contract : Contrat sur le véhicule ;  contract_state : état du contrat ;  vehicle_log_fuel : consommation de carburant. Un véhicule appartient à un modèle. Tout au long de son utilisation, il peut faire l’objet de plusieurs interventions et consomme du carburant dont il est nécessaire de connaitre les coûts de consommation. Un employé est affecté au véhicule en tant que chauffeur. (cf. Figure 16) Figure 16 : Gestion du parc automobile Conclusion du chapitre La conception nous a permis de construire les schémas de base de données sur lequel toute l’application sera construite. Compte tenu de la méthode de développement par sprints que nous avons adoptée, nous avons construit le diagramme par domaine métiers. Toutefois en regroupant ces différents diagrammes, nous obtenons le diagramme correspondant au système tout entier.
  • 58. Conclusion de la partie À travers cette partie, nous avons effectué un certain nombre d’études qui nous ont permis tout d’abord de comprendre le problème posé et les différents enjeux. Ensuite, nous avons exprimé de façon concrète la solution proposée à travers la création de «profil utilisateur » et des cas d’utilisations. Ces cas d’utilisations ont été décrits à l’aide de scénarios ou de diagrammes de séquence. Enfin, nous avons construit le diagramme de classes correspondant au système à développer. La conception ainsi réalisée, il y’a lieu maintenant de passer à la concrétisation des concepts étudiés.
  • 59. Partie III. Etude technique et réalisation Introduction de la partie Cette partie a pour but de mettre en lumière le travail réalisé au cours des différents sprints. En premier lieu nous aborderons les outils que nous avons eu à utiliser tout au long du stage. Ensuite, nous entamerons un paramétrage des modules après avoir effectué une étude de convergence. Enfin, nous nous attarderons sur la réalisation du module « Acheminement » et les tests de déploiement effectués ; et le tout, illustré par des captures d’écrans de l’application.
  • 60. Chapitre 1. Technologie mises en œuvre Introduction du chapitre Pour le développement des fonctionnalités énoncées ci-haut lors des phases de conception, nous avons eu à utiliser un certains nombres d’outils. Dans ce chapitre, nous détaillerons ces différentes technologies ainsi que leur rôle pendant la réalisation du projet. I. OpenERP version 7 Figure 17 : Logo OpenERP Les ERPs (Entreprise Resource Planning), aussi appelés Progiciel de Gestion Intégré (PGI), sont des applications dont le but est de coordonner l’ensemble des activités d’une entreprise autour d’un même système d’information. Leur principe fondateur est de construire des applications correspondants aux diverses fonctions précédemment citées, de manière modulaire. Ces modules devraient être indépendants entre eux, tout en partageant une base de données unique. Il existe deux catégories d’ERPs : les ERPs propriétaires, et les ERPs Open source. Les ERPs Open Source sont différents des ERPs propriétaires, non pas en terme de fonctionnalités disponibles, mais sur tout ce qui touche à la licence du produit, ainsi qu’à la personnalisation de ce dernier. La réduction des coûts liés au non achat des licences d’utilisation permet à l’entreprise, d’investir l’argent ainsi économisé, dans une personnalisation accrue de leur ERP pour avoir un logiciel sur mesure, répondant aux besoins de leurs activités. L’ERP que nous avons eu à utiliser au cours de notre stage est l’OpenERP. Fondé en 2005 en Belgique par Fabien Pinckaers, il est devenu l’ERP Open source le plus téléchargé au monde. Il représente la nouvelle génération des ERP avec son modèle 100% Open source, sa modularité qui fait sa plus grande force ainsi que sa compatibilité avec les nouvelles technologies. D’ailleurs, la récompense reçue lors des Bossie Award 2013 du meilleur logiciel Open source pour la deuxième année consécutive n’est pas une surprise en soi. Sa version 7 utilisée tout au long de ce projet offre une interface web, une intégration forte avec Google Docs mais aussi une messagerie intégrée ou encore des liens avec les réseaux sociaux.
  • 61. Chapitre 1. Technologie mises en œuvre - 61 - Avec plus 3000 modules à sa disposition, OpenERP couvre de multiples domaines de gestion. Il suit les besoins du marché, et son aspect évolutif est plus qu’admirable. Anciennement appelé « Tiny ERP », OpenERP est devenu plus récemment en mai dernier « Odoo ». L’entreprise souhaiterait davantage d’énergie dans sa croissance commerciale tout en maintenant les efforts d’écriture de son célèbre logiciel professionnel. Figure 18 : Gestion sur OpenERP II. Le langage Python Figure 19 : Python
  • 62. Chapitre 1. Technologie mises en œuvre - 62 - OpenERP a été développé en Python et utilise son propre Framework : le Framework OpenObject. Il a été développé de façon modulaire. Autrement dit, il est possible d’ajouter ou de retirer des modules pour changer le fonctionnement du programme : ajout, modification et suppression des fonctionnalités. La personnalisation d’une instance d’OpenERP peut se faire de deux manières :  Avec l’interface d’OpenERP, qui est plus de la configuration que du développement. Les modifications resteront sur la base de données, et le déploiement du module sur une autre instance nécessitera l’exportation dudit base de données.  En créant des modules pythons dédiés, qui est de la programmation pure, basée sur l’héritage d’objets. Le module ainsi crée sera un dossier contenant plusieurs fichiers pythons et XML. Pour le déploiement du module sur une autre instance, il suffirait de copier ce dossier dans le répertoire correspondant. Le second point est la méthode de développement que nous avons opté car cela offrait beaucoup d’avantages, que ça soit sur la qualité de notre formation, mais aussi au cas où l’on voudrait exporter le module dans une autre instance. D’où l’utilisation du langage de programmation python. C’est un langage multi-paradigme qui favorise la programmation impérative structurée, et orientée objet. C’est un langage beaucoup apprécié par les pédagogues car il propose une syntaxe simple à utiliser, qui permet une initiation aisée des concepts de base de la programmation. III. PostgreSQL Figure 20 : PostgreSQL PostgreSQL est le Système de Gestion de Base de Données qui stocke aussi bien les données transactionnelles que les données de paramétrage d’OpenERP. Avant la création d’une instance, OpenERP vous demande au préalable de créer une base de données sur PostgreSQL, le tout à travers son interface web. Son utilisation, pendant les phases de développement, peut s’effectuer directement par lignes de commandes, ou par interface graphique « pgadmin ».