ROYAUME DU MAROC
*-*-*-*-*
HAUT COMMISSARIAT AU PLAN
*-*-*-*-*-*-*-*
INSTITUT NATIONAL
DE STATISTIQUE ET D’ECONOMIE APPLIQ...
- 2 -
- 3 -
Résumé
Poste Maroc est une entreprise exerçant principalement dans trois métiers dont le pôle
courrier. Ce dernier o...
- 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
p...
- 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
...
- 6 -
- 7 -
Remerciements
Nous tenons à remercier tous ceux qui nous ont soutenu tout au long de ce travail.
Pour commencer notr...
- 8 -
Liste des abréviations
BAM : Barid Al Maghrib
EA: Enterprise Architect
ERP: Enterprise Resource Planning PAQ
SQL: St...
- 9 -
Liste des figures
Figure 1 : Organisation des acteurs du projet........................................................
- 10 -
Figure 47 : Vue Kanban Dépêches "validée siège".......................................................................
- 11 -
Table des matières
Introduction générale...................................................................- 14 -
P...
- 12 -
III. Diagrammes de cas d’utilisation .................................................................................
- 13 -
II. Les workflows ....................................................................................................
- 14 -
Introduction générale
L’activité courrier consiste en la distribution des courriers émanant des particuliers ou
des...
- 15 -
Partie I : Contexte général du projet
Introduction de la partie
Avant d’entamer la réalisation d’un projet, il est ...
Chapitre 1 : Présentation de l’organisme d’accueil
Introduction du chapitre
Avant d’entrer dans les détails du projet, nou...
Chapitre 1 : Présentation de l’organisme d’accueil
- 17 -
développements majeurs s’articulant autour de la mise à niveau e...
Chapitre 1 : Présentation de l’organisme d’accueil
- 18 -
Poste Maroc offre une large gamme de services de messagerie inte...
Chapitre 2 : Présentation du projet
Introduction du chapitre
Ce chapitre est dédié à la description du présent projet. Nou...
Chapitre 2 : Présentation du projet
- 20 -
 Construire une base de données sur le référentiel acheminement (véhicules, ch...
Chapitre 3 : Plan d’Assurance Qualité (PAQ)
Introduction du chapitre
Le plan d’assurance qualité est un document qui relat...
Chapitre 3 : Plan d’Assurance Qualité (PAQ)
- 22 -
I.3. Assistant Maitre d’Ouvrage
L’assistant a pour fonction principale ...
Chapitre 3 : Plan d’Assurance Qualité (PAQ)
- 23 -
plus, à la vue de l’importance du projet, une disponibilité ou une mobi...
Chapitre 3 : Plan d’Assurance Qualité (PAQ)
- 24 -
son nom l’indique, Scrum consiste en une équipe soudée, travaillant de ...
Chapitre 3 : Plan d’Assurance Qualité (PAQ)
- 25 -
Ces sprints ont été réalisés de manière chronologique et ont nécessité ...
Chapitre 3 : Plan d’Assurance Qualité (PAQ)
- 26 -
III. Planification du projet
La planification constitue l’une des étape...
Chapitre 3 : Plan d’Assurance Qualité (PAQ)
- 27 -
fonctions pour les incorporer dans les vues XML. Cela nous a pris un pe...
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...
Chapitre 3 : Plan d’Assurance Qualité (PAQ)
- 30 -
Conclusion du chapitre
A travers ce chapitre, nous avons mis en place l...
Partie II : Etude fonctionnelle et conception
Introduction de la partie
Dans cette partie, il est question d’effectuer une...
Chapitre 1 : Etude préliminaire
Introduction du chapitre
Cette étude consiste essentiellement à étudier la faisabilité du ...
Chapitre 1 : Etude préliminaire
- 33 -
 les axes de transport ;
 le véhicule qui sera utilisé pour le transport et le co...
Chapitre 1 : Etude préliminaire
- 34 -
 Les transporteurs Rekkas
Ces types de transporteurs sont sollicités, lorsque Bari...
Chapitre 1 : Etude préliminaire
- 35 -
A la fin de la journée, un rapport est effectué au sein des sites sur les différent...
Chapitre 1 : Etude préliminaire
- 36 -
Il est à noter qu’il est souvent impossible d’utiliser ces fichiers Excel pour la r...
Chapitre 1 : Etude préliminaire
- 37 -
 L’abandon de fichiers Excel : Le passage des fichiers Excel aux bases de
données ...
Chapitre 1 : Etude préliminaire
- 38 -
Conclusion du chapitre
Cette étude nous a permis de passer en revue le fonctionneme...
Chapitre 2 : Etude fonctionnelle
Introduction du chapitre
Ce point consistera à présenter l’application à développer en te...
Chapitre 2 : Etude fonctionnelle
- 40 -
I.4. Gestion du parc automobile
Le parc automobile est constitué d’un ensemble de ...
Chapitre 2 : Etude fonctionnelle
- 41 -
Nous avons pu identifier quatre acteurs qui pourront interagir avec l’application....
Chapitre 2 : Etude fonctionnelle
- 42 -
II.4. L’administrateur
La maintenance et la gestion du système mis en place seront...
Chapitre 2 : Etude fonctionnelle
- 43 -
Figure 6 : Diagramme des cas d'utilisation "site"
Description du cas d’utilisation...
Chapitre 2 : Etude fonctionnelle
- 44 -
Enchaînement nominal :
1. Le responsable veut créer un suivi pour une dépêche
2. I...
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
s...
Chapitre 2 : Etude fonctionnelle
- 46 -
Description du cas d’utilisation « Gérer les dépêches de sa région»
Identification...
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 dan...
Chapitre 2 : Etude fonctionnelle
- 48 -
La figure 9 représente le diagramme de séquence pour le cas d’utilisation « Gérer ...
Chapitre 2 : Etude fonctionnelle
- 49 -
III.3. Diagramme des cas d’utilisation « Siège »
Le responsable de siège a pour pr...
Chapitre 2 : Etude fonctionnelle
- 50 -
Description du cas d’utilisation « Valider l'ordre de service ou la dépêche créé p...
Chapitre 2 : Etude fonctionnelle
- 51 -
III.4. Diagramme du cas d’utilisation « Administrateur »
Le diagramme correspondan...
Chapitre 3 : Conception
Introduction du chapitre
La conception correspond à la phase de modélisation du système à concevoi...
Chapitre 3 : Conception
- 53 -
Pour un ordre de service, il ressort que nous voulons connaitre sa mission, ses heures de
d...
Chapitre 3 : Conception
- 54 -
II.2. Gestion des dépêches
Les entités qui vont être utiles pour cette partie sont :
 Depe...
Chapitre 3 : Conception
- 55 -
Pour pouvoir assurer le suivi des dépêches, nous avons besoins de connaitre, pour
l’entité ...
Chapitre 3 : Conception
- 56 -
Figure 15 : Gestion des ressources Humaines
II.5. Gestion du parc automobile
A ce niveau, i...
Chapitre 3 : Conception
- 57 -
 vehicle_log_services : intervention sur le véhicule ;
 vehicle_log_contract : Contrat su...
Conclusion de la partie
À travers cette partie, nous avons effectué un certain nombre d’études qui nous ont
permis tout d’...
Partie III. Etude technique et réalisation
Introduction de la partie
Cette partie a pour but de mettre en lumière le trava...
Chapitre 1. Technologie mises en œuvre
Introduction du chapitre
Pour le développement des fonctionnalités énoncées ci-haut...
Chapitre 1. Technologie mises en œuvre
- 61 -
Avec plus 3000 modules à sa disposition, OpenERP couvre de multiples domaine...
Chapitre 1. Technologie mises en œuvre
- 62 -
OpenERP a été développé en Python et utilise son propre Framework : le Frame...
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
Prochain SlideShare
Chargement dans…5
×

Gestion flotte acheminement_courrier

2 060 vues

Publié le

Conception et Réalisation d’une application pour la
gestion de la flotte et de l’acheminement courrier à la poste
avec openerp 7

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
2 060
Sur SlideShare
0
Issues des intégrations
0
Intégrations
6
Actions
Partages
0
Téléchargements
177
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Gestion flotte acheminement_courrier

  1. 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
  2. 2. - 2 -
  3. 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. - 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. - 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. 6. - 6 -
  7. 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 28. Chapitre 3 : Plan d’Assurance Qualité (PAQ) - 28 - Figure 5 : Diagramme de Gantt définitif
  29. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 ».

×