Gestion flotte acheminement_courrier

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 -
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

- 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 -
I. Contexte général du projet .............................................................................................- 19 -
II. Objectifs du projet.......................................................................................................- 19 -
Chapitre 3 : Plan d’Assurance Qualité (PAQ)..........................................................................- 21 -
I. Organisation.....................................................................................................................- 21 -
II. Méthode de travail.......................................................................................................- 22 -
III. Planification du projet ................................................................................................- 26 -
IV. Risques..........................................................................................................................- 29 -
Conclusion de la partie................................................................................................................- 30 -
Partie II : Etude fonctionnelle et conception .............................- 31 -
Chapitre 1 : Etude préliminaire.................................................................................................- 32 -
I. Etude de l’existant...........................................................................................................- 32 -
II. Critique de l’existant...................................................................................................- 35 -
III. Solution apportée.........................................................................................................- 36 -
Chapitre 2 : Etude fonctionnelle ................................................................................................- 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 -
Chapitre 3 : Conception..............................................................................................................- 52 -
I. Diagramme de classes : Description ..............................................................................- 52 -
II. Diagramme de classes par métiers.............................................................................- 52 -
Partie III. Etude technique et réalisation...................................- 59 -
Chapitre 1. Technologie mises en œuvre...................................................................................- 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 -
Chapitre 2 : Etude de convergence............................................................................................- 65 -
I. Besoins métiers de l’application.....................................................................................- 65 -
II. Modules existants.........................................................................................................- 66 -
III. Croisement Besoins/Fonctionnalités OpenERP........................................................- 68 -
Chapitre 3 : Paramétrage de modules.......................................................................................- 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 -
Chapitre 4. Développement du module « Acheminement ».....................................................- 77 -
I. Logique de développement d’un module OpenERP ....................................................- 77 -

- 13 -
II. Les workflows ..............................................................................................................- 84 -
III. Ecrans d’applications..................................................................................................- 86 -
Chapitre 5 : Tests et Déploiement..............................................................................................- 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 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

- 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 -
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
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.
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)
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 -
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 -
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 -
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 -
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 -
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 -
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 -
Figure 5 : Diagramme de Gantt définitif

- 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 -
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
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
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 -
 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 -
 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 -
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 -
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 -
 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 -
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
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 -
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 -
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 -
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 -
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 -
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
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
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
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 -
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 -
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é
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
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
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

- 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 -
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 -
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 -
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é
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
2. A. il y’a un problème
1. Il rejette l’objet
2. Il rédige un message
3. Le système enregistre
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 -
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"
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
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 -
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 -
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 -
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 -
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 -
 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
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
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
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 -
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 -
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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Gestion flotte acheminement_courrier

Similaire à Gestion flotte acheminement_courrier (20)

Plus de HORIYASOFT

Plus de HORIYASOFT (20)

Gestion flotte acheminement_courrier