1. ROYAUME DU MAROC *-*-*-*-* HAUT COMMISSARIAT AU PLAN *-*-*-*-*-*-*-* INSTITUT NATIONAL DE STATISTIQUE ET DECONOMIE APPLIQUEE Projet de Fin dEtudes ***** N 113 Prpar 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 lobtention du Diplme dIngnieur dEtat Option : INFORMATIQUE Devant le jury compos de : M. A. HACHIMI ALAOUI (INSEA) Mlle. Rajaa SAIDI (INSEA) M. Najib OURADI (BAM) Conception et Ralisation dune application pour la gestion de la flotte et de lacheminement courrier

2. - 2 - 3. - 3 - Rsum Poste Maroc est une entreprise exerant principalement dans trois mtiers dont le ple courrier. Ce dernier occasionne des charges qui doivent tre maitrises surtout la vue de la baisse gnrale du volume de courriers changs depuis ces dernires annes. La rduction de ces charges, majoritairement lies lacheminement des courriers, passe une maitrise de linformation ncessitant la mise en place dun systme informatique. Cest dans ce cadre que sinscrit notre travail qui traite de la conception et la ralisation dune application de gestion de la flotte et de lacheminement courrier. Nous tions amens raliser une application sous OpenERP capable de rpondre aux besoins spcifiques. Couple JasperReports, cette application devra permettre de gnrer des rapports PDF. Compte tenu du type dapplication dvelopper, nous avons opt pour la mthode de dveloppement SCRUM, au cours de laquelle nous avons d subdiviser notre projet en fonction des besoins mtiers. Cela nous a permis deffectuer une analyse de chaque besoin en profondeur lors de la phase de modlisation. Pour ce qui est de la phase de ralisation, elle fut ralis en grande majorit grce aux langages python et XML. Mots cls : OpenERP, python, XML, Jasper Reports 4. - 4 - Ddicaces A mon pre et ma mre, Piga et Christine ZONGO, qui malgr la distance, ont su trouver les mots justes pour me soutenir tout au long de mon cursus. Aucune ddicace ne saurait tre assez loquente pour exprimer mon respect et ce que vous mritez pour les sacrifices effectus mon gard. A mes trs chres surs, pour tous nos moments passs ensemble. Je vous ddie 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 daller de lavant, je vous remercie tous. Votre soutien et vos encouragements me donnent la force de continuer. Jol ZONGO 5. - 5 - Ddicaces ma chre mre ma raison dtre, ma raison de vivre, la lanterne qui claire mon chemin. mon cher pre en signe damour, de reconnaissance et de gratitude pour tous les soutiens et les sacrifices dont il a fait preuve mon gard. mes chers frres et chres surs Aucun mot, ni aucun signe ne pourront dcrire votre implication dans mon panouissement. tous mes amis En tmoignage de lamiti sincre et du soutien inbranlable que vous mavez apport. je ddie ce travail. Salif SONMANDE 6. - 6 - 7. - 7 - Remerciements Nous tenons remercier tous ceux qui nous ont soutenu tout au long de ce travail. Pour commencer notre remercions dabord les responsables de Barid Al Maghrib qui ont bien voulu nous ouvrir leur porte et qui nous ont permis de disposer dun cadre idal de travail. Notre prochain remerciement notre encadreur externe, Mr. Najib OURADI, direction de la Division des Solutions et dAmliorations Continues. Son coute et sa disponibilit tout au long du projet nous a t dune aide prcieuse. Nous remercions galement Mlle Rajaa SAIDI, professeur lInstitut National Statistiques et dEconomie Appliques pour avoir accept de nous encadrer et qui a contribu grandement la reussite du projet travers ses diffrents conseils. Nous ne saurions omettre dans nos remerciements tout le personnel de Barid Al Maghrib et plus particulirement Mr ERRADI Yacine du service acheminement, et Abdel SBIA de la Direction de la Poste Numerique et Tlcoms. Pour finir, nous tenons remercier le corps enseignant de lINSEA pour lenseignement de qualit dont nous avons bnfici ainsi que le le personnel administratif et tout ceux qui de prs ou de loin ont contribu au succs de ce projet. 8. - 8 - Liste des abrviations 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 dAssurance Qualit 9. - 9 - Liste des figures Figure 1 : Organisation des acteurs du projet...................................................................................- 22 - Figure 2 : Structure de la mthode SCRUM ......................................................................................- 24 - Figure 3 : Droulement des sprints ...................................................................................................- 24 - Figure 4 : Diagramme de GANTT prvisionnel ..................................................................................- 27 - Figure 5 : Diagramme de Gantt dfinitif............................................................................................- 28 - Figure 6 : Diagramme des cas d'utilisation "site"..............................................................................- 43 - Figure 7 : Diagramme de cas d'utilisation "rgion"...........................................................................- 45 - Figure 8.: Diagramme de squence pour le cas dutilisation sauthentifier ...............................- 47 - Figure 9 : Diagramme de squence pour le cas dutilisation Grer les axes de transport ..........- 48 - Figure 10 : Cas d'utilisation "sige"...................................................................................................- 49 - Figure 11 : Cas d'utilisation "administrateur" ...................................................................................- 51 - Figure 12 : Gestion des ordres de services........................................................................................- 53 - Figure 13 : Gestion des dpches......................................................................................................- 54 - Figure 14 : Gestion du suivi des dpches ........................................................................................- 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 mtiers....................................................................................- 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 hrite : 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 dinitialisation __init__.py ...................................................................................- 79 - Figure 36 : Fichier de description __openerp__.py...........................................................................- 80 - Figure 37 : Description de lobjet carte carburant ............................................................................- 82 - Figure 38 : Vue formulaire d'un employ..........................................................................................- 82 - Figure 39 : Vue liste employs ..........................................................................................................- 83 - Figure 40 : Vue Kanban ordres de service valids sige ..............................................................- 83 - Figure 41 : Vue graphe du workflow des ordres de service..............................................................- 85 - Figure 42 : Cration d'un ordre de service........................................................................................- 86 - Figure 43 : Authentification...............................................................................................................- 87 - Figure 44 : Vue formulaire ordre "valid rgion"..............................................................................- 88 - Figure 45 : Vue kanban ordre de service "valid sige"....................................................................- 88 - Figure 46 : Vue formulaire dpche valide sige ......................................................................- 89 - 10. - 10 - Figure 47 : Vue Kanban Dpches "valide sige"............................................................................- 90 - Figure 48 : Suivi de dpche : Vue formulaire ..................................................................................- 91 - Figure 49 : Suivi de dpches, vue "calendar" ..................................................................................- 91 - Figure 50 : Liste des modules OpenERP ............................................................................................- 93 - Figure 51 : Description du module Acheminement ..........................................................................- 94 - Figure 52 : Dpendances du module Acheminement : ressources humaines (hr) & parc automobile (fleet).................................................................................................................................................- 94 - Figure 53.: page 1 ordre de service.................................................................................................- 100 - Figure 54.: page 2 ordre de service.................................................................................................- 101 - 11. - 11 - Table des matires Introduction gnrale...................................................................- 14 - Partie I : Contexte gnral du projet..........................................- 15 - Introduction de la partie.............................................................................................................- 15 - Chapitre 1 : Prsentation de lorganisme daccueil .................................................................- 16 - Introduction du chapitre.........................................................................................................- 16 - I. Prsentation de Barid Al Maghrib.................................................................................- 16 - II. Domaines dactivits....................................................................................................- 16 - III. Prestations de services.................................................................................................- 17 - Conclusion du chapitre ...........................................................................................................- 18 - Chapitre 2 : Prsentation du projet...........................................................................................- 19 - Introduction du chapitre.........................................................................................................- 19 - I. Contexte gnral du projet .............................................................................................- 19 - II. Objectifs du projet.......................................................................................................- 19 - Conclusion du chapitre ...........................................................................................................- 20 - Chapitre 3 : Plan dAssurance Qualit (PAQ)..........................................................................- 21 - Introduction du chapitre.........................................................................................................- 21 - I. Organisation.....................................................................................................................- 21 - II. Mthode 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 prliminaire.................................................................................................- 32 - Introduction du chapitre.........................................................................................................- 32 - I. Etude de lexistant...........................................................................................................- 32 - II. Critique de lexistant...................................................................................................- 35 - III. Solution apporte.........................................................................................................- 36 - Conclusion du chapitre ...........................................................................................................- 38 - Chapitre 2 : Etude fonctionnelle ................................................................................................- 39 - Introduction du chapitre.........................................................................................................- 39 - I. Spcifications des besoins fonctionnels..........................................................................- 39 - II. Identification des acteurs et les rles .........................................................................- 40 - 12. - 12 - III. Diagrammes de cas dutilisation ................................................................................- 42 - Conclusion du chapitre ...........................................................................................................- 51 - Chapitre 3 : Conception..............................................................................................................- 52 - Introduction du chapitre.........................................................................................................- 52 - I. Diagramme de classes : Description ..............................................................................- 52 - II. Diagramme de classes par mtiers.............................................................................- 52 - Conclusion du chapitre ...........................................................................................................- 57 - Conclusion de la partie................................................................................................................- 58 - Partie III. Etude technique et ralisation...................................- 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 utiliss............................................................................................................- 64 - Conclusion du chapitre ...........................................................................................................- 64 - Chapitre 2 : Etude de convergence............................................................................................- 65 - Introduction du chapitre.........................................................................................................- 65 - I. Besoins mtiers de lapplication.....................................................................................- 65 - II. Modules existants.........................................................................................................- 66 - III. Croisement Besoins/Fonctionnalits OpenERP........................................................- 68 - Conclusion du chapitre ...........................................................................................................- 70 - Chapitre 3 : Paramtrage de modules.......................................................................................- 71 - Introduction du chapitre.........................................................................................................- 71 - I. Paramtrage du module Ressources Humaines hr .................................................- 71 - II. Paramtrage du module Parc Automobile fleet ..................................................- 73 - III. Paramtrage du module Jasper Reports...................................................................- 73 - Conclusion du chapitre ...........................................................................................................- 76 - Chapitre 4. Dveloppement du module Acheminement .....................................................- 77 - Introduction du chapitre.........................................................................................................- 77 - I. Logique de dveloppement dun module OpenERP ....................................................- 77 - 13. - 13 - II. Les workflows ..............................................................................................................- 84 - III. Ecrans dapplications..................................................................................................- 86 - Conclusion du chapitre ...........................................................................................................- 92 - Chapitre 5 : Tests et Dploiement..............................................................................................- 93 - Introduction du chapitre.........................................................................................................- 93 - I. Installation du module Acheminement..........................................................................- 93 - II. Tests unitaires..............................................................................................................- 95 - III. Tests dintgration.......................................................................................................- 95 - IV. Recette ..........................................................................................................................- 95 - V. Sites pilotes.......................................................................................................................- 96 - VI. Formations ...................................................................................................................- 96 - Conclusion chapitre.................................................................................................................- 96 - Conclusion de la partie................................................................................................................- 96 - Conclusion gnrale......................................................................- 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 dacheminement.....................................................................................- 102 - 14. - 14 - Introduction gnrale Lactivit courrier consiste en la distribution des courriers manant des particuliers ou des entreprises, des dlais raisonnables avec des niveaux de qualit et scurit en phase avec leurs besoins. La tendance mondiale de cette activit est la baisse depuis plusieurs annes. En effet, nous assistons une chute du volume de courriers changs, due lavnement des changes lectroniques et des restrictions budgtaires des entreprises. A linstar des autres services postaux, Poste Maroc nchappe pas ce phnomne. Malheureusement, les leviers pour compenser ce dficit du chiffre daffaire sont trs rares, voire inexistants. Do la ncessit dagir sur une baisse des charges. Cest dans cette optique que Poste Maroc a entrepris des dmarches de rduction de charges dans certains dpartements, notamment dans le service Acheminement o plusieurs dpenses peuvent tre maitrises par linformatisation de certaines tches. Cela sest sold par une dcision de mettre en place un systme informatique capable de grer le processus actuel de lacheminement des courriers sans impacter la qualit des services rendus. Limplmentation dun tel systme fut lobjet de notre tude durant la priode de stage. Notre mission tait de faire la conception et ralisation dune application de gestion de la flotte et de lacheminement courrier . Pour mener bien ce projet, nous lavons subdivis en plusieurs parties au cours desquelles nous avons effectu des analyses sur les spcifications du systme concevoir, avant de passer la ralisation avec des outils appropris. Dans ce prsent rapport, nous entamerons dabord par une prsentation du contexte gnral. Par la suite, nous procderons une tude pralable, ainsi quune conception dtaille du systme. Puis nous terminerons par une tude technique ainsi quune prsentation des rsultats obtenus aprs la mise en uvre du projet. 15. - 15 - Partie I : Contexte gnral du projet Introduction de la partie Avant dentamer la ralisation dun projet, il est essentiel de le contextualiser afin davoir une vision claire sur les ressources humaines et matrielles mettre en place, les diffrents enjeux, ainsi que le temps ncessaire son accomplissement. Cest dans cette optique que sinscrit cette premire partie qui sera numre en plusieurs phases. Nous prsenterons en premier lieu lorganisme ayant soumis ce projet. Par la suite, nous raliserons un plan dassurance qualit aprs avoir fait une description du projet et ses principaux objectifs 16. Chapitre 1 : Prsentation de lorganisme daccueil Introduction du chapitre Avant dentrer dans les dtails du projet, nous allons tout dabord prsenter lorganisme qui nous a ouvert ses portes. Les points qui suivront, constituent un rsum sur lidentit de lentreprise, ses domaines dactivits et les services quelle offre. I. Prsentation 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 sparation des secteurs Postes et Tlcommunications . Il a t transform en Aot 2010 en socit anonyme, dont le capital est entirement dtenu par lEtat. Lhistoire de BAM commence depuis 1892 et treize villes taient relies entre elles lpoque. Le 22 mai 1912 le premier timbre est mis pour remplacer les cachets qui taient utiliss. 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 crant une filiale baptise Al Barid Bank. BAM est constitu dun ensemble de ples dont le ple courrier constitu son tour de directions dont la Direction dIndustrialisation et de lEfficacit Oprationnelle (DEIO). Nous avons ralis notre stage au sein dune division de ladite direction. Cest la Division Solution et Amlioration continue dont les missions dans BAM sont : Assistance maitrise douvrage au mtier courrier ; Support technique aux sites courrier ; Veille technologique. II. Domaines dactivits Barid Al Maghrib opre principalement dans trois mtiers : le courrier, la messagerie et les services financiers. Le courrier reprsente environ 50% de son chiffre daffaire. Lactivit courrier connat une volution positive de ses performances. Ces bons rsultats sont le fruit des efforts dploys pour le dveloppement du portefeuille client, lamlioration de la qualit de service et la rduction des dlais dacheminement. Pour sa part, la filiale bancaire Al Barid Bank, lanc en Juin 2010 a renforc la mission de service universel de BAM. En effet, lactivit des services financiers a enregistr des 17. Chapitre 1 : Prsentation de lorganisme daccueil - 17 - dveloppements majeurs sarticulant autour de la mise niveau et llargissement de loffre pour tous les marocains. Avec la marque Amana dans lactivit messagerie, il y a lieu de souligner les bons rsultats enregistrs ces dernires annes et qui trouvent leurs explications essentiellement dans lvolution 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 dactivit, un ensemble de services sont proposs aux clients. III.1. Lactivit courrier Lactivit courrier cible une large clientle : institutions, administrations, particuliers, entreprises ainsi que la presse. La chane de valeur courrier comprend le dpt, la collecte, le traitement, lacheminement et la distribution des lettres et autres objets au niveau national et international. Lactivit courrier est devenue, ainsi, un fournisseur de solutions adaptes aux besoins complexes des entreprises. Aux particuliers, elle propose des services de distribution de courrier des dlais raisonnables avec des niveaux de qualit et de scurit en phase avec leurs besoins. III.2. Lactivit messagerie Poste Maroc est loprateur historique de messagerie et du transport de documents et de colis au niveau national et international. Son offre rpond des besoins multiples et diversifis de ses clients Entreprises et Particuliers travers une large gamme de services se dclinant 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 dlais express et rapides garantis couvrant tout le territoire national : Amana Transport et Logistiques : Service de Transport de marchandises en lots groups ou en camion complet travers loffre, partout au Maroc ; b. Sur le plan international 18. Chapitre 1 : Prsentation de lorganisme daccueil - 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 dlais Express garantis allant de 2 4 jours ; Amana International : Service de messagerie rapide internationale assurant la livraison dans des dlais allant de 5 7 jours ; Colis Postaux : Service de messagerie conomique internationale assurant la livraison dans des dlais allant de 5 15 jours. III.3. Lactivit service financier Cette activit est assure par la filiale Al Barid Bank. A linstar des autres structures bancaires, nous pouvons citer quelques services : La gestion de compte courant ; La gestion de compte dpargne ; Le transfert dargent national et international ; La bancassurance ; Le crdit 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 prciser les domaines dactivits et les services proposs. 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 amlioration continue. 19. Chapitre 2 : Prsentation du projet Introduction du chapitre Ce chapitre est ddi la description du prsent projet. Nous allons dans un premier temps, donner le contexte gnral du projet, qui consistera donner les motivations qui ont conduit sa ralisation et les ambitions qui lui sont associes. Par la suite, nous prciserons les objectifs gnraux. I. Contexte gnral du projet Barid Al Maghrib conduit une stratgie destine intgrer les nouvelles technologies dans ses mtiers 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 marchs concurrentiels. Il travaille sans relche proposer les meilleurs services sa clientle. Cependant, la clientle devient de plus en plus exigeante. Cest alors que BAM doit continuellement trouver les voies et moyens pour russir concrtiser ses ambitions. Lune des activits principales de BAM est lacheminement des courriers. Cette activit permet dassurer un lien de proximit grce de nombreuses agences qui dsenclavent les rgions les plus recules du pays et donnent la possibilit tous les citoyens de rester en contact avec l'ensemble du territoire et avec l'extrieur. Dans la gestion de lacheminement des courriers, les diffrentes agences font dabord le traitement de ces courriers en local, avant de les transfrer dans leurs destinations respectives. Des retards peuvent alors tre engendrs suivant les agences, et BAM na pas un moyen pour contrler les agences lointaines, ni pour savoir si les courriers sont bien transmis. Dans cette optique, de nos nombreuses rflexions ont t mene pour savoir les rponses apporter aux problmes poss. Cest dans ce cadre, que se situe la prsente rflexion, qui a pour thme : conception et ralisation d'une application de gestion de la flotte et de l'acheminement courriers . Les objectifs de ce projet sont multiples et ceci fera lobjet de la section suivante. II. Objectifs du projet Le systme, qui sera dvelopp, permettra BAM de pouvoir savoir chaque instant, les informations essentielles sur lacheminement dun courrier donn. Il pourra ainsi assurer la cohrence du service avec ses ambitions. Le projet ainsi dfini a pour objectif de : Assurer la poursuite de la modernisation des diffrents outils de production en utilisant les nouvelles technologies qui facilitent lexcution des diffrentes tches ; 20. Chapitre 2 : Prsentation du projet - 20 - Construire une base de donnes sur le rfrentiel acheminement (vhicules, chauffeurs, sites, horaires de transport) ; Maitriser lexcution du chemin dacheminement, dtecter et justifier les carts ; Offrir une gestion souple et maitrise de la cration et mise jour de nouveaux axes et horaires dacheminement (workflow) ; Offrir au sige et aux entits desservies par le chemin dacheminement, un outil collaboratif facilitant le pilotage oprationnel. Conclusion du chapitre Nous avons dfini le contexte gnral et les objectifs du projet dans les points prcdents. Nous allons, dans le chapitre suivant, prciser les diffrentes modalits savoir : quelle sera son organisation, la mthode de travail que nous allons suivre pour sa ralisation, le planning et les risques lis. 21. Chapitre 3 : Plan dAssurance Qualit (PAQ) Introduction du chapitre Le plan dassurance qualit est un document qui relate les diffrents lments permettant de sassurer de la mise en uvre et de lefficacit des activits prvues dans le cahier de charges. Ce document permet au client et au prestataire de service dtre sur la mme longueur donde en ce qui concerne le contexte, les enjeux ainsi que les vritables attentes du client sur le projet raliser. La ralisation dun tel document passe par plusieurs tapes. Dans ce rapport, nous nous attarderons notamment sur quelques-unes savoir lorganisation, la mthode de travail utilise, la planification du projet et les risques ventuels encourus. I. Organisation Pour mener bien notre projet, nous lavons organis en dfinissant les rles des diffrents acteurs qui y interviennent. I.1. Maitre douvrage Parfois appele matrise douvrage , note MOA, le maitre douvrage est celui qui maitrise lide de base du projet, et reprsente au mieux les utilisateurs finaux qui louvrage est destin. Il dfinit lobjectif du projet, son calendrier, et le budget qui y est consacr. Dans notre projet, louvrage qui est le rsultat attendu, est une application OpenERP de gestion de lacheminement courrier au sein de Barid Al Maghrib. Ce besoin a t mis par le Service Acheminement de la Division des Oprations. Cette dernire appartenant elle-mme la Direction dIndustrialisation et dEfficacit Oprationnelle (DIEO) du Ple Courrier. Par consquent, le service dacheminement constitue la maitrise douvrage de notre projet. I.2. Maitre duvre Aussi appele maitrise duvre MOE, elle est lentit retenue par le maitre douvrage pour la ralisation de louvrage dans les conditions de dlais, de qualits et de couts fixs. Il prend connaissance du besoin exprim et qui tche dy rpondre informatiquement. Dans ce projet, la mission de maitrise duvre nous incombe avec le soutien technique de la Direction de la Poste Numrique et Tlcom. 22. Chapitre 3 : Plan dAssurance Qualit (PAQ) - 22 - I.3. Assistant Maitre dOuvrage Lassistant a pour fonction principale daider le maitre douvrage dfinir, piloter et exploiter le projet ralis par le maitre duvre. Il aide ce dernier mieux apprhender le projet, en dfinissant les priorits sur les diffrentes fonctionnalits raliser. Dans notre projet, cette mission a t attribu la Direction des Solutions et dAmliorations Continues (DSAC) du Ple Courrier. Figure 1 : Organisation des acteurs du projet II. Mthode de travail Aucune mthode nest magique, aucune ne garantit la russite dun projet. Sinon tous les projets informatiques seraient de brillantes russites [WEB06]. Cest une citation retrouve sur internet qui rsume parfaitement notre position sur la question du choix des mthodes de travail. Ce choix tait lune des tapes dterminantes dans le droulement de notre projet. Il doit correspondre au contexte de celui-ci. Autrement dit, il doit tre en phase avec les particularits et les diffrentes exigences, afin dobtenir un produit de qualit qui rpond aux attentes du client. Pour la mise en uvre de notre projet, nous avons opt pour lutilisation dune mthode agile. Ce choix de la mthode nest pas hasardeux, puisque nous avons pris en compte un certain nombre de critres tels le profil et la disponibilit des acteurs, les priorits 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 rcurrentes aprs la ralisation dune portion de lapplication. De 23. Chapitre 3 : Plan dAssurance Qualit (PAQ) - 23 - plus, la vue de limportance du projet, une disponibilit ou une mobilisation des diffrents acteurs ntaient pas craindre au sein de Barid Al Maghrib. De plus, compte tenu du profil du projet, qui est le dveloppement dun module OpenERP, la mthode agile tait plus que recommande. II.1. Les mthodes agiles Les mthodes agiles sont des procds qui visent apporter plus de valeurs aux clients, aux utilisateurs, ainsi quune grande satisfaction dans leur travail aux membres de lquipe. Le but fondamental de ce type de mthode est la maximisation de la valeur ajoute. En effet, le dveloppement seffectuera par itrations successives, avec possibilit de changer de priorit la fin de chaque itration. Une tentative de dfinition de Scott Ambler, ingnieur canadien spcialis sur les mthodes agiles serait : Une mthode agile est une approche itrative et incrmentale pour le dveloppement de logiciel, ralis de manire trs collaborative par des quipes responsabilises, appliquant un crmonial minimal, qui produisent un logiciel de grande qualit dans un dlai contraint, rpondant aux besoins changeant des utilisateurs Considres souvent comme une nouvelle culture, les mthodes agiles possdent les valeurs et les principes suivants : Livrer frquemment et rgulirement le logiciel ; Faire des cycles de dveloppement court et limit dans le temps ; Constituer une quipe complte pour un dveloppement ; Grer les membres de lquipe en les responsabilisant ; Avoir le reprsentant des utilisateurs sur le mme site que le reste de lquipe ; Produire des plans plusieurs niveaux : dtaills uniquement pour le court terme et plus gnraux pour le moyen terme ; Dvelopper en intgrant le code de faon continue ; Faire des bilans de projet dans le but damliorer la faon de travailler ; Plusieurs mthodes, de nos jours, respectent ces principes et sont qualifies dagiles. Mais lengouement pour la mthode Scrum a mis fin une hypothtique rivalit entre les mthodes agiles [OUV01]. En effet, celle-ci est la plus populaire de toutes et sera utilise par la suite car compatible avec les besoins du client. II.2. La mthode Scrum Scrum tient son nom dun terme emprunt au vocabulaire du sport rugby, mle . Elle utilise les valeurs et lesprit du rugby et les adapte aux projets de dveloppement. Comme 24. Chapitre 3 : Plan dAssurance Qualit (PAQ) - 24 - son nom lindique, Scrum consiste en une quipe soude, travaillant de manire collective, dont les travaux convergent tous vers les buts pralablement dfinis. Et cest la mme similitude au rugby pour avancer le ballon pendant une mle . Scrum fait partie des approches itratives et incrmentales dont le modle de cycle de dveloppement est bas sur une phase qui se rpte plusieurs fois successivement. Cest la notion ditration ou sprint dans Scrum (cf. Figure 2). Figure 2 : Structure de la mthode SCRUM Tous les sprints se droulent selon le mme schma, et on y fait chaque fois les mmes types de travaux. Avec une mthode agile comme Scrum, les activits de spcifications et de conception sont continues, et on part du principe que larchitecture va voluer, dans une certaine limite, pendant la vie du projet. Figure 3 : Droulement des sprints Tout au long du projet du projet, nous avons eu raliser plusieurs sprints. La dure de ces sprints variait normment en fonction de leur complexit. Gestion des sites et des axes de transport ; Gestion des ordres de service et des dpches ; Gestion du suivi des dpches ; Gestion des acteurs et des rles de scurit ; Gestion du reporting ; Paramtrage du module de Ressources Humaines ; Paramtrage du module de Parc Automobile. 25. Chapitre 3 : Plan dAssurance Qualit (PAQ) - 25 - Ces sprints ont t raliss de manire chronologique et ont ncessit la participation de tous les acteurs du projet. II.3. Les acteurs au cur du projet Dans un projet Scrum, les diffrents acteurs doivent tre rpartis en fonction de trois rles essentiels : le ScrumMaster, le ProductOwner, et lquipe. a. Le ScrumMaster Il joue le rle de mdiateur entre les membres de son quipe et le client lorsque cela savre ncessaire. Un client mcontent aura affaire par exemple au ScrumMaster, qui trouvera un compromis entre les deux parties. Dans notre projet, ce rle a t jou lassistant du maitre douvrage. Il faisait lintermdiaire entre nous, qui formons lquipe, et le reprsentant des futurs utilisateurs de lapplication. b. Le ProductOwner Il est le reprsentant dans lquipe de toutes les personnes qui utiliseront lapplication. Il est charg de dfinir lobjectif du projet et de le partager avec lquipe qui le dveloppe. Pour cela, il identifie les fonctionnalits requises dont a besoin lapplication, puis les collecte dans une liste appele backlog de produit . Durant notre stage, ce rle fut jou par le maitre douvrage du projet. c. Lquipe Lquipe est compose des techniciens qui vont travailler sur le projet, guid par le ScrumMaster et aid par le ProductOwner. Elle a le rle principal puisque cest elle qui dveloppera lapplication au cours des sprints. Nous avons form cette quipe avec la participation de la Direction du Poste Numrique et Tlcom. En dautres termes, le rle de lquipe a t jou par la maitrise duvre du projet. Des runions sont organises rgulirement lors de chaque sprint, afin de faire des mises au point, sur ltat davancement et sur de possibles amliorations prendre en compte. Pour conclure, nous pouvons dire que Scrum est un bon cadre de gestion de projets. Elle ne prconise aucune pratique dingnierie pour garantir la qualit dun produit. Sa flexibilit pendant la ralisation et son cadre de travail y fait sa force. Elle imite le principe de ltat desprit du rugby : avancer tous ensemble vers un but commun. Ce dernier faisant ainsi rfrence la russite du projet. 26. Chapitre 3 : Plan dAssurance Qualit (PAQ) - 26 - III. Planification du projet La planification constitue lune des tapes primordiales dans le droulement dun projet. Elle consiste prvoir le droulement des diffrentes phases du projet, en fonction des besoins exprims dans le cahier de charges et de la mthode de travail utilise. Ces diverses phases constituent des sprints, dans lesquelles nous devons raliser un livrable du produit. Autrement dit, nous devons dvelopper dans chaque sprint un fragment de lapplication, travers une analyse des spcifications des besoins, du codage, ainsi que des tests unitaires. Au dbut du stage, nous avons ralis une planification prvisionnelle du projet, dans laquelle nous avons estim les dures de ralisation possible pour chaque sprint. Ces dures, exprimes en nombre de jours ouvrables de la semaine sont reprsentes dans le diagramme de Gantt prvisionnel ci-dessous (cf. Figure 4). A la fin du stage, nous avons mis en place une planification dfinitive qui relate les dtails de ce qui a t ralis pendant le droulement du projet. Cette planification a t illustre dans le diagramme de Gantt dfinitif reprsent un peu plus bas (cf. Figure 5). Quelques carts ont t remarqus aprs une comparaison des deux planifications ralises. Cela sexplique par le fait que certaines parties furent plus difficiles que dautres, et ont demand ainsi plus de ressources (temps, recherches, etc.). Les carts majeurs ont t remarqus au niveau de la gestion des ordres de services, la gestion du suivi des dpches et le reporting. La gestion des ordres de service Initialement prvu pour six jours ouvrables, la gestion des ordres des ordres de services a ncessit autant de jours supplmentaires pour sa mise en place. En effet, la comprhension et la mise en place du systme de workflow na pas t une chose aise. Il nous tait difficile de trouver un document qui explique correctement son intgration dans un module OpenERP. Quand bien mme on trouvait des documentations officielles, celles-ci se limitaient nous expliquer les bienfaits et avantages quauront les workflows dans notre systme dinformation, et non comment les mettre en place. Aprs plusieurs jours de recherches, nous avons dcid de coupler les rponses approximativement recueillies dans les forums ddis, au code dun module OpenERP utilisant dj 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 dpches Celle-ci fut ralise en deux temps : la gestion de suivi de base, et la gestion des contraintes lis aux diverses rgles mtiers. Elle a accus un retard de deux jours ouvrables par rapport la planification initiale. La premire a t ralise dans les temps car elle ne prsentait pas de difficults particulires. Quant au second, elle ncessitait lappellation de plusieurs fonctions pythons en arrire-plan. En effet, notre utilisation du python jusque-l tait limite la cration de classes des diffrents objets. Lheure tait venue pour nous de crer nos propres 27. Chapitre 3 : Plan dAssurance 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 manire dintgrer et dappeler les fonctions pythons dans le module. (cf. Figure 4 et 5) Le reporting Prvu initialement pour cinq jours, la gestion du reporting a dur finalement sept jours ouvrables. Cela est d aux tests effectus sur plusieurs outils de reporting. En effet, afin de pouvoir gnrer des documents en PDF, nous avons eu recours un certain nombre doutils. Tout dabord nous avons opt pour lOpenOffice. Cela sest avr ne pas tre un succs, puisque ce dernier tait trs limit en ce qui concerne la mise en forme des donnes. Ensuite, nous avons survol dautres outils tels Pentaho reports , wkhtmltopdf , Geraldo Reports par manque de tutoriels expliquant correctement leurs modes de fonctionnement. Au final, notre choix sest port sur Jasper Reports , qui en plus de gnrer des documents en PDF, nous proposait toute une panoplie dextensions possibles. Lessai de presque tous ces outils a ainsi occasionn une norme perte de temps par rapport la planification initiale. Figure 4 : Diagramme de GANTT prvisionnel 28. Chapitre 3 : Plan dAssurance Qualit (PAQ) - 28 - Figure 5 : Diagramme de Gantt dfinitif 29. Chapitre 3 : Plan dAssurance Qualit (PAQ) - 29 - IV. Risques Tout projet, du fait mme de son caractre unique, comporte une part de risques dont la nature peut tre varie (techniques, juridiques, sociaux, humains, etc.). Il est donc primordial deffectuer une tude avant le dbut du projet, en vue de mesurer les risques particuliers qui y sont lis. Les principaux risques que nous avons pu dceler sont les suivants. Risques 1 Probabilit 2 Impacts Mesure de maitrise Dvelopper en OpenERP OpenERP tait une nouvelle technologie que lon ne connaissait pas et dont la documentation ou les forums daides ddis taient rarissimes. avre fort Ce risque a t maitris par une auto-formation technique en OpenERP. Non connaissance du langage python OpenERP est majoritairement dvelopp en python. La connaissance du python tait essentielle pour le dveloppement spcifique dun module avre moyen La lecture de tutoriels nous a permis de surmonter cette difficult Risque de choix de la mthode de travail Ctait la premire fois que nous devons utiliser SCRUM dans un projet, ou dune mthode agile en gnral. probable faible La prsence dans lquipe dun utilisateur expert en Scrum a permis de nous guider lors des diffrentes tapes au cours des sprints Risque humain Lapplication raliser permet de suivre les diffrents mouvements des employs. Le sige pourra surveiller les diffrentes activits de ses employs (les retards engendrs, la non concordance entre litinraire effectuer et le carburant utilis, le non respect du tableau dacheminement). Cela peut inciter les employs saisir de fausses informations pour saboter les donnes de lapplication. probable faible Il peut tre maitris par la formation, la sensibilisation et laccompagnement des employs lors du dploiement 1 Probabilit que ce risque se ralise 2 Limpact de ce risque pour le bon droulement du projet 30. Chapitre 3 : Plan dAssurance Qualit (PAQ) - 30 - Conclusion du chapitre A travers ce chapitre, nous avons mis en place le plan dassurance qualit dans laquelle nous avons expos notre organisation, la mthode de travail adopte, la planification prvisionnelle et dfinitive ainsi que les risques possibles que nous pourrions rencontrs. Ce chapitre scellait aussi par la mme occasion la dernire phase de cette premire partie. Conclusion de la partie Dans cette partie, nous avons prsent le projet dans son contexte gnral en mettant en vidence ses objectifs majeurs, et la conduite utiliser pour le mener bien. La partie suivante consistera une tude fonctionnelle ainsi quune conception dtaille des besoins de lorganisme. 31. Partie II : Etude fonctionnelle et conception Introduction de la partie Dans cette partie, il est question deffectuer une tude approfondie du systme mettre en place. Cela passe par une analyse simultane de lexistant et du cahier de charge, afin de mettre en vidence le besoin dun nouveau systme capable de rpondre aux exigences de lentreprise. Ainsi, nous allons, dans un premier temps, faire ltude pralable qui consiste recenser lexistant, et les insuffisances du systme actuel en vue de proposer des solutions adquates. Ensuite, nous entamerons la seconde phase o nous allons effectuer une tude fonctionnelle. Dans celle-ci, nous prsenterons les diffrents acteurs de lapplication, ainsi que les besoins fonctionnels satisfaire. Nous clturerons par la suite cette partie, par une prsentation dune conception dtaille de lapplication, laide de diagrammes UML. 32. Chapitre 1 : Etude prliminaire Introduction du chapitre Cette tude consiste essentiellement tudier la faisabilit du projet. Nous allons premirement faire une analyse de la faon dont sont gres les activits du ple courrier. Ensuite, nous allons voquer les faiblesses rencontres dans cette dmarche, avant de proposer des solutions appliquer pour amliorer le fonctionnement du systme actuel. I. Etude de lexistant La premire tape de ltude pralable consiste mettre en vidence le fonctionnement actuel du systme, savoir les diffrentes actions mises en jeu lors de lacheminement dun courrier. Pour une bonne comprhension du processus actuel, certaines notions indispensables sont dfinir. I.1. Dfinitions de quelques concepts cls a. Organisation La gestion des activits du ple courrier de BAM est assure par trois principales couches : le sige, les rgions et les sites. En effet, suivant un dcoupage propre Barid Al Maghrib et non suivant le dcoupage administratif, le Maroc a t divis en plusieurs rgions. Ces rgions ont sous leurs responsabilits les diffrents sites qui leur sont affects. Ces sites peuvent tre des centres de traitement et de distribution (CTD), des agences, un centre de courrier international(CCI), etc. Le sige, quant lui, a le dernier mot dans les diffrentes activits effectues. Il coordonne les oprations des diffrentes rgions, qui, leur tour assurent une meilleure cohsion des tches au niveau des sites. b. Ordre de service Un ordre de service est une dcision qui prcise les modalits dexcution de tout, ou dune partie des prestations qui dterminent le fonctionnement de Barid Al Maghrib. Il est traduit sous forme de documents o sont consignes toutes les informations ncessaires son excution. Ces informations sont entre autres : La frquence denvoi des dpches dans la semaine ; les horaires de dparts et darrives thoriques des dpches ; la date deffet : la date partir de laquelle, lordre de service doit tre mis en exploitation ; 33. Chapitre 1 : Etude prliminaire - 33 - les axes de transport ; le vhicule qui sera utilis pour le transport et le convoyeur qui est associ. Un ordre de service na pas de date dexpiration. Cependant, son arrt peut tre explicitement demand par un autre, et cest partir de linstant prcis dans le nouvel ordre que lancien nest plus valable. Sa cration peut tre faite par le sige, mais aussi par les rgions. Dans le cas dune rgion, une validation par le sige est obligatoire avant que celui-ci devienne actif. Elle doit tre faite avant sa mise en exploitation. (Annexe II) c. Dpche Une dpche est constitue dun ensemble denvois, forms par un site destination dun autre. Elle peut tre cre par le sige mais aussi par les rgions. Lors de sa cration par une rgion, elle doit tre obligatoirement valide par le sige avant dtre exploitable. Cette cration intervient suite lapprobation dun ordre de service. Aprs validation, elle est considre comme active, tant quun ordre de service mis ne sollicite explicitement sa dsactivation. Classifie selon des types prdfinis, son acheminement est ralis par des moyens de transport, via un envoi direct ou par lintermdiaire dun transit ou de plusieurs transits. Les types de dpche peuvent tre : Lettre et Carte (LC), Autre Objet(AO), etc. d. Moyens de transport Un moyen de transport dsigne, dans son sens le plus gnral, un outil utilis par lHomme afin de se dplacer dun point A un point B. Barid Al Maghrib possde plusieurs types de moyens de transport. Nous pouvons citer : Les Vhicules de service Ce sont des vhicules confis par Barid Al Maghrib certains salaris pour les besoins dacheminement. Ces vhicules peuvent tre des voitures, des fourgonnettes, des camions, ou mme des motos. Chaque vhicule de service appartient un site spcifique. Il est li un chauffeur ou conducteur qui est cens en prendre soin. Les transporteurs agrs Ils reprsentent les transporteurs nationaux tels que : CTM, STCR, ou ONCF, mais aussi les compagnies ariennes. Barid Al Maghrib adopte lutilisation de ses transporteurs agrs dans le cas o leur cot de transport des dpches sur une distance est infrieur celui des vhicules de service. 34. Chapitre 1 : Etude prliminaire - 34 - Les transporteurs Rekkas Ces types de transporteurs sont sollicits, lorsque Barid Al Maghrib dcide de faire appel des personnes et non des socits de transport. Dans ce cas, un contrat est sign avec ces personnes pour assurer le transport et la scurit des dpches transporter. La manire dont ces dpches vont tre transfres importe peu. Les Rekkas, ou tout simplement les individus sous contrat de transport avec Barid Al Maghrib, se portent garant pour transmettre les dpches dans les dlais indiqus. Nous pouvons distinguer les Rekkas grant et les Rekkas distribution. e. Les axes de transport Les axes de transport dsignent les diffrents trajets que peut prendre un vhicule partir dun site donn. Ils sont dfinis par un certain nombre de caractristiques tels que la distance, le type de laxe, les sites ou entits de dpart et darrive, etc. f. Table dacheminement 235 La table dacheminement 235 est prsente sous forme dun tableau rcapitulatif de tous les termes dfinis ci-dessus. En dautres termes, elle regroupe toutes les dpches cres aprs que les ordres de services aient t valids. Pour une dpche donne, nous pouvons y observer la frquence denvoi, le moyen de transport utilis, laxe de transport emprunt, les horaires de dparts et darrives thoriques et relles. (Annexe III) I.2. Processus actuel de lacheminement courrier Le processus de lacheminement courrier Barid Al Maghrib suit la logique du tableau 235. En effet, aprs la cration des dpches issue des ordres de services, les informations du tableau dacheminement ne varie pas jusqu la signature dun autre ordre de service. Tous les jours, des dpches sont envoyes dun site un autre, dune ville une autre, dune rgion une autre. Nous pouvons considrer lexemple suivant issu dune ligne du tableau. Des dpches seront envoyes tous les lundi au vendredi dun site de Rabat un site dAgadir partir de 23h30 bord dun vhicule de service, en faisant escale Casablanca. Ce vhicule devrait arriver aux environs de 06h . Afin de respecter cet ordre manant du sige gnral, et retranscrit dans le tableau 235, le chef du site signera durant la soire, une dcharge indiquant le dpart du vhicule de son site. A la rception des dpches Agadir, son homologue en fera pareille en signant une autre dcharge. Ces diffrentes dcharges signes rvleront ensuite les retards effectus par les chauffeurs et les raisons avances expliquant ces retards. 35. Chapitre 1 : Etude prliminaire - 35 - A la fin de la journe, un rapport est effectu au sein des sites sur les diffrents dparts et arrivs qui ont eu lieu. Ces rapports, stocks dans des fichiers Excel, seront transmis au sige pour un bilan des activits et sassurer de la qualit du travail ralis. Dans le cas dun arrt dans un site donn, des dpches pourront tre dposes en vue dun transfert futur si elles devaient y faire escale, et dautres pourront y rester si ctait leurs destinations. En rsum, tout dpendra de ce qui est prvu dans le tableau 235. (cf. Annexe III.) Tel est le processus actuel de lacheminement 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 problmes rencontrs. II. Critique de lexistant Lune des difficults majeures que rencontre ce systme est la non centralisation des donnes . Cela empche la mise en place de statistiques explicatives du fonctionnement global de lentreprise. Ces statistiques peuvent tre entre autre la connaissance du degr dexcution du tableau dacheminement 235, du taux dincidents rencontrs dans chaque site. En effet, les sites grent indpendamment les diffrents acheminements et ont leur propre base de donnes quils mettent jour librement. Ils utilisent Excel pour conserver les informations des diffrents acheminements et ce, de faon journalire. Cela augmente le nombre de fichiers leur disposition. Les sites doivent envoyer ces fichiers au sige qui se retrouve ainsi avec un trop grand nombre de fichiers grer. Lutilisation des fichiers Excel peut occasionner des pertes lors des transferts vers le sige, ou mme des erreurs de saisie. Ces erreurs de saisie peuvent amener deux situations possibles. Le problme peut tre dtect, et dans ce cas, le fichier est corrig et renvoy au sige. Dans le cas contraire, cela peut avoir des consquences sur les dcisions futures prendre. On observe ainsi une perte de temps considrable entre les diffrents transferts de fichiers en comparaison un systme o aucun transfert ne sera ncessaire du fait de la centralisation des donnes. D'ailleurs, en ce qui concerne le transfert des fichiers, il arrive que des sites ne les effectuent pas. Un exemple concret de consquence sur le non transfert des fichiers, est la raffectation dun salari un autre site. Le sige ntant pas inform, peut toujours envoyer des articles (tenues, chaussures) au salari. Les articles seront redirigs vers le site appropri, mais avec un effort supplmentaire. Aussi, le sige prouve souvent du mal ragir efficacement face certaines demandes. Par exemple, il arrive quune demande de ravitaillement en carburant soit incomprise par le sige tant donn quil na aucune ide sur lutilisation de ce carburant. 36. Chapitre 1 : Etude prliminaire - 36 - Il est noter quil est souvent impossible dutiliser ces fichiers Excel pour la ralisation de certaines tches. Sur la base du fonctionnement actuel, il nexiste aucune possibilit de connaitre la position des vhicules. Pourtant cela pourrait savrer trs utile dans certaines situations durgences. Par exemple, le systme pourra aider connaitre rapidement la position dun vhicule en cas dincident sur un axe de transport, grce son GPS. En rsum, les difficults lies la mthode actuelle sont : Non centralisation des donnes ; Donnes non protges ; Nombre trop lev de fichiers Excel grer ; Perte de temps considrable ; Possibilit dincohrence des donnes entre le sige et un site donn ; Difficult de raction prompte et efficace de la part du sige ou des sites ; Risque de perte de fichiers ; Aucune statistique pour mieux comprendre le fonctionnement des diffrents sites ; Pnurie de carburant due la cration abusive des dpches (sans informer le sige). III. Solution apporte Au vue des limites du systme existant, nous sommes amens proposer des solutions qui rpondent aux objectifs de Barid Al Maghrib et qui par la mme occasion, pallient aux lacunes rpertories. Cette rsolution peut se prsenter sous trois points : la partie gestion, organisation et technique. III.1. La partie Gestion Cette partie consiste dvelopper un systme bas sur plusieurs modules savoir lacheminement, le parc automobile, et les ressources humaines. Les principaux objectifs de ce systme seront : Utilisation des profils pour mieux grer les droits daccs aux fichiers : Cela permettra aux utilisateurs de navoir accs quaux donnes dont ils ont le privilge ; Mise en place dun circuit de validation des dpches et des ordres de services, intgrant les acteurs (Responsables de lacheminement au niveau du sige et des rgions) ; 37. Chapitre 1 : Etude prliminaire - 37 - Labandon de fichiers Excel : Le passage des fichiers Excel aux bases de donnes constitue une des plus grandes volutions du systme. Cela rsoudra les problmes lis aux pertes de temps, aux transferts de fichiers avec des erreurs, au nombre trop lev de fichiers grer, etc. ; Mise en place dun systme de reporting : pour la cration des rapports permettant de mieux apprhender les voies et moyens pour accroitre le rendement de Barid Al Maghrib. Ces rapports pourront tre gnrs au format PDF ; Interface de gestion de lacheminement courrier : pour un meilleur suivi des dpches en apportant des solutions aux diffrents problmes y affrant ; Gestion du parc automobile : pour une meilleure gestion des vhicules et des chauffeurs qui y sont affects. Cela permettra de rsoudre les problmes d aux demandes de ravitaillement du carburant non comprise par le sige, ou plus gnralement les incidents qui surviennent lors des transferts des dpches ; Fonction de messagerie : pour assurer la communication entre les diffrents acteurs du systme ; Gestion de ressources humaines. III.2. La partie Organisation En termes dorganisation, ce systme serait capable dassurer une meilleure rpartition entre les diffrents intervenants, leur offrir des espaces personnels, et aussi leur permettre un accs facile ainsi quune coordination. III.3. La partie Technique Pour le dveloppement des fonctionnalits susmentionnes, la Direction de la Poste Numrique et Tlcom a mis notre disposition une plateforme Open source. En effet, cette direction est charge de lingnierie marketing et de la commercialisation de plusieurs services. Il existe plusieurs types dERPs Open Source. Celui utilis par la direction de la Poste Numrique et Tlcom est lOpenERP (cf. Technologies mises en uvre). Cest est un logiciel offrant plusieurs fonctionnalits telles que la gestion comptable et financire, 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 activits requises, OpenERP permet le dveloppement de modules personnaliss. Ce qui nous permettra de couvrir au maximum les fonctionnalits attendues de lapplication. 38. Chapitre 1 : Etude prliminaire - 38 - Conclusion du chapitre Cette tude nous a permis de passer en revue le fonctionnement prsent de lacheminement des dpches travers une tude de lexistant. Nous avons fait des propositions pour rsoudre certaines difficults rencontres. Notre tude ayant t valide, nous pouvons maintenant passer la phase de spcifications qui feront lobjet du chapitre suivant. 39. Chapitre 2 : Etude fonctionnelle Introduction du chapitre Ce point consistera prsenter lapplication dvelopper en termes de fonctionnalits offertes. Il prsentera le systme qui rpond aux besoins exprims par le client. Ltude fonctionnelle construit ldifice qui sert de contrat entre le client et le prestataire dune solution informatique. Par ce contrat, le client reconnait que ses besoins sont satisfaits et le prestataire sengage fournir un produit conforme. I. Spcifications des besoins fonctionnels Ltude pralable a montr les dfauts que prsente le systme de gestion actuel. Elle a galement prsent les besoins du client en termes de fonctionnalits. Ce prsent point a pour but de spcifier un systme conforme aux besoins exprims par les utilisateurs. Ces derniers pourront effectuer les tches suivantes. I.1. Gestion des ordres de services La gestion des ordres de services permettra la cration, la modification, la suppression et la validation dun ordre de service. Lordre ainsi cr sera soumis la validation dun utilisateur ayant un rle spcifique. De mme, un ordre de service peut tre supprim si au bout dun certain temps, sa validation nest pas acquise, ou modifi si cela est explicitement demand au travers de lapplication. En outre, il est fondamental que les utilisateurs puissent consulter les ordres de services crs afin de savoir les diffrentes caractristiques associes, pour pouvoir prendre les dcisions appropries. I.2. Gestion des dpches La gestion des dpches suit le mme principe que celle des ordres de services. Cependant une dpche est lie forcment un ordre de service pralablement cr. On dit donc quune dpche est la concrtisation de lexcution dun ordre de service. I.3. Gestion des suivis de dpches Pour une dpche cre, il faut assurer son acheminement de lentit de dpart lentit darrive. Entre ces deux sites, il peut y avoir des points de transit qui assureront laiguillage de la dpche la bonne destination. La gestion de suivi consistera ainsi recueillir les diffrents horaires possibles, pour en dduire les retards et les statistiques ventuels. 40. Chapitre 2 : Etude fonctionnelle - 40 - I.4. Gestion du parc automobile Le parc automobile est constitu dun ensemble de vhicules faisant objet de contrat avec les fournisseurs et ncessitant des interventions (rparations). Ces interventions peuvent engendrer divers cots. Cette fonctionnalit a pour but de fournir un moyen efficace pour sassurer du bon droulement de lacheminement des dpches. I.5. Gestion des ressources humaines Les ressources humaines sont ce quil ya de fondamental dans une entreprise. Toutes les activits de lentreprise en dpendent. Une bonne organisation des ressources humaines (affection optimale des postes, affectation au site) assure la prosprit de lentreprise. Il est donc plus que crucial de fournir lentreprise, un outil de gestion des employs. Cet outil permettra entre autres lajout des employs en leur affectant des sites, lattribution des identifiants de connexion, la gestion du processus de recrutement, la gestion des congs, la gestion du systme de pointage, etc. I.6. Gestion de ldition des rapports Ldition des rapports est introduite pour donner un moyen de mesurer les performances de Barid Al Maghrib (BAM), au travers des diffrentes statistiques significatives. Ces statistiques permettront BAM de connaitre les diffrentes difficults rencontres dans la gestion de lacheminement et de prendre ainsi des dcisions adquates. Ldition de rapport consiste galement en limpression de document papier. Par exemple, un chauffeur qui assure le transport dune dpche aura besoin dun document papier de lordre de services afin de savoir ce quil lui incombe daccomplir comme tches. Les diffrents besoins exprims nous conduisent la ncessit de pouvoir distinguer les personnes qui vont se servir du systme pour une raison ou une autre. Dans ce but, nous allons crer des acteurs et les rles qui leur seront affects. Ainsi, un acteur ne pourra faire que ce dont il est habilit. II. Identification des acteurs et les rles Les acteurs sont les utilisateurs du systme. Ils sont dsigns par le maitre douvrage. Chaque acteur doit tre nomm, mais, pour trouver son nom, il faut penser son rle. En en effet, un acteur reprsente un ensemble cohrent de rles jous vis--vis dun systme. 41. Chapitre 2 : Etude fonctionnelle - 41 - Nous avons pu identifier quatre acteurs qui pourront interagir avec lapplication. Ces acteurs sont : Responsable acheminement site, Responsable acheminement rgion, Responsable acheminement sige et administrateur. II.1. Responsable acheminement site Il aura un pouvoir de supervision sur toutes les activits relevant de son site uniquement. Cest un utilisateur qui aura le privilge de : attribuer des tches ses subordonns ; vrifier les dparts et les arrivs de dpches dans son site et den informer le sige en cas de besoin ; crer une instance pour suivre les dpches originaires de son site ; gnrer des rapports. Tout cela seffectue travers un espace personnel, lui garantissant ainsi une meilleure gestion et une vue plus globale de son site. II.2. Responsable acheminement rgion Il a principalement un rle de : Consultation des activits des sites ; Gestion des employs ; Gestion des vhicules ; Gestion des ordres de services ; Gestion des dpches. Il est important de noter que ce responsable ne peut grer que ce qui est propre sa rgion. Il dispose son tour dun espace personnel qui lui permettra de grer efficacement les sites lis. Un ordre de service ou une dpche cre par la rgion doit tre soumis la validation du sige avant dtre oprationnel. II.3. Responsable acheminement sige Il a le plein pouvoir quant la gestion de lacheminement des dpches sur toutes les rgions et sur tous les sites. Il possde aussi un espace personnel lui permettant une meilleure gestion de la flotte et de lacheminement des courriers. 42. Chapitre 2 : Etude fonctionnelle - 42 - II.4. Ladministrateur La maintenance et la gestion du systme mis en place seront faites par ladministrateur. En effet, ce dernier soccupera non seulement de la gestion des utilisateurs dans le systme, mais aussi dune rvision priodique des fonctionnalits de lapplication pour sassurer de leurs bons fonctionnements. Un systme informatique, cest un ensemble dacteurs et de rles jous. Pour une meilleure assimilation des points voqus plus haut, nous allons utiliser un langage de modlisation graphique. Le choix de la modlisation sest port sur le langage UML. Cest un langage utilis en dveloppement logiciel, et en conception oriente objet. Les composantes qui nous intressent dans ce prsent document sont : le diagramme de classe, le diagramme de squence et le diagramme de cas dutilisation. Le point suivant portera sur le diagramme de cas dutilisation. III. Diagrammes de cas dutilisation UML permet de formaliser les besoins, cest--dire de les reprsenter sous une forme graphique suffisamment simple pour tre comprhensible par toutes les personnes impliques dans le projet. Souvent le matre douvrage et les utilisateurs ne sont pas des informaticiens. Il leur faut donc un moyen simple dexprimer leurs besoins. Cest prcisment le rle des diagrammes de cas dutilisation. Ils permettent de recenser les grandes fonctionnalits dun systme. Dans la suite du rapport, nous allons concevoir les diagrammes des cas dutilisation selon les attentes en termes de fonctionnalits pour chaque acteur. Les plus importants cas dutilisation seront dcrits laide de scenarios, ou dun diagramme de squence. III.1. Diagramme des cas dutilisation de Site Les sites sont lobjet mme de la ncessit dun systme de gestion centralis. Pour chaque site, il ya un acteur Responsable acheminement site qui pourra effectuer les tches comme nous lavons spcifi lors de lidentification des acteurs. Le diagramme de cas dutilisation correspondant cet acteur est le suivant (cf. Figure 6). 43. Chapitre 2 : Etude fonctionnelle - 43 - Figure 6 : Diagramme des cas d'utilisation "site" Description du cas dutilisation Grer le suivi des dpches Identification Nom du cas : Grer le suivi des dpches But : dtail des points pour permettre un responsable de site dassurer lacheminement des dpches dont son site en est le point origine ou un point transit. Acteur Principal : Responsable acheminement site Squencement Le cas dutilisation commence quand le chef de site souhaite crer ou modifier un suivi de dpche. Prconditions le systme est lanc, le responsable est authentifi et le site est gestionnaire ou le point de transit dau moins une dpche. 44. Chapitre 2 : Etude fonctionnelle - 44 - Enchanement nominal : 1. Le responsable veut crer un suivi pour une dpche 2. Il slectionne la dpche objet du suivi 3. Il renseigne lheure de dpart de la dpche 4. Le systme vrifie que la dpche peut tre envoye lheure de dpart saisie 5. Le systme affecte un numro au suivi et lenregistre 6. Terminer le traitement Scnario alternatif 1 : Il dmarre au point 4 de lenchanement nominal. 4. A. la dpche ne peut pas tre envoye lheure de dpart saisie 1. le systme affiche une notification pour indiquer une violation de contrainte sur lheure de dpart saisie 2. revenir au point 3 de lenchanement nominal Scnario alternatif 2 : Il dmarre au point 1 de lenchanement nominal 1. Le responsable veut modifier un suivi cr pour un autre site 2. Le systme vrifie que le site auquel appartient le responsable est bien le point de destination de la dpche 3. il renseigne lheure darrive de la dpche 4. Le systme vrifie que lheure darrive est suprieure lheure de dpart 5. Terminer le traitement Scnario alternatif 3 : Il dmarre au point 4 du Scnario alternatif 2. 4. A. lheure darrive est infrieure lheure de dpart 1. le systme affiche une notification pour indiquer une violation de contrainte sur lheure de darrive 2. revenir au point 3 du Scnario alternatif 2 Scnario alternatif 4 : Il dmarre au point 2 du Scnario alternatif 2 2. A. le site de lutilisateur connect est un point de transit de la dpche 45. Chapitre 2 : Etude fonctionnelle - 45 - 1. il saisit lheure darrive de la dpche dans son site et celle de dpart de son site 2. revenir au point 5 du Scnario alternatif 2 Post-conditions Une interface pour le suivi de la dpche est cre pour permettre aux diffrents sites concerns par la dpche dinteragir pour son acheminement. III.2. Diagramme des cas dutilisation de Rgion Pour rappel, La rgion est constitue dun ensemble de sites. Le responsable acheminement rgion a donc sous sa responsabilit les sites lis. Son principal rle est dassurer la gestion de la cration des dpches, des ordres de services et des axes de transport. Le diagramme correspondant aux possibilits offertes un responsable de rgion est le suivant : Figure 7 : Diagramme de cas d'utilisation "rgion" 46. Chapitre 2 : Etude fonctionnelle - 46 - Description du cas dutilisation Grer les dpches de sa rgion Identification Nom du cas : Grer les dpches de sa rgion But : Permettre une rgion de crer, supprimer, modifier ou consulter une dpche Acteur Principal : le responsable acheminement rgion Squencement Prconditions : le systme est lanc, le responsable est authentifi Enchanement nominal : 1. Il choisit lopration effectuer 2. Il veut crer une dpche 3. Il fournit les informations 4. Il valide les saisies 5. Le systme attribut un code la dpche et lenregistre 6. Terminer le traitement Scnario alternatif 1 : Il dmarre au point 2 de lenchanement nominal. 2. A. Il veut modifier une dpche 1. Il slectionne la dpche 2. Il modifie les informations souhaites en prenant soins dajouter un message dexplication 3. Il change ltat de la dpche 4. revenir au point 6 de lenchanement nominal Scnario alternatif 2 : Il dmarre au point 2 de lenchanement nominal 2. A. le responsable veut supprimer une dpche 1. Il slectionne la dpche 2. Il valide la suppression 3. Le systme vrifie les contraintes de dpendance sont respectes 4. Le systme supprime la dpche 5. aller au point 6 de lenchanement nominal Scnario alternatif 3 : 47. Chapitre 2 : Etude fonctionnelle - 47 - Il dmarre au point 3 du Scnario alternatif 2 : 2. A. la dpche est utilise dans le systme 1. Le systme affiche une notification pour signaler que la dpche ne peut tre supprime. 2. aller au point 5 du Scnario alternatif 2 Post-conditions On devrait se retrouver avec une dpche en moins en cas de succs ou aucun changement en cas dchec. NB : La gestion des ordres de service suit la mme description que celle des dpches. La figure suivante (cf. Figure 8) prsente le diagramme de squence pour le cas dutilisation sauthentifier . Figure 8.: Diagramme de squence pour le cas dutilisation sauthentifier 48. Chapitre 2 : Etude fonctionnelle - 48 - La figure 9 reprsente le diagramme de squence pour le cas dutilisation Grer les axes de transport Figure 9 : Diagramme de squence pour le cas dutilisation Grer les axes de transport 49. Chapitre 2 : Etude fonctionnelle - 49 - III.3. Diagramme des cas dutilisation Sige Le responsable de sige a pour principales missions, la gestion des validations des ordres de services, des dpches ou des axes de transport crs au niveau rgional. Il pourra galement effectuer dautres tches qui sont prcises dans le diagramme de la figure 10. Figure 10 : Cas d'utilisation "sige" 50. Chapitre 2 : Etude fonctionnelle - 50 - Description du cas dutilisation Valider l'ordre de service ou la dpche cr par la rgion Identification Nom du cas : Valider l'ordre de services ou la dpche cr par la rgion But : Permettre la validation des dpches ou des ordres de services crs par les rgions Acteur Principal : le responsable acheminement sige Squencement Prconditions : le systme est lanc, le chef de sige est authentifi Enchanement nominal : 1. Il slectionne un ordre de service ou une dpche 2. Il vrifie quil ny a aucun problme sur lobjet (dpche ou ordre de service) 3. Il valide les saisies 4. Le systme change ltat de lobjet 5. Terminer le traitement Scnario alternatif 1 : Il dmarre au point 2 de lenchanement nominal. 2. A. il ya un problme 1. Il rejette lobjet 2. Il rdige un message 3. Le systme enregistre 4. revenir au point 5 de lenchanement nominal Post-conditions On devrait se retrouver avec une dpche ou un ordre de services valid. En cas de rejet un message obligatoire justifiant le rejet est rdig. 51. Chapitre 2 : Etude fonctionnelle - 51 - III.4. Diagramme du cas dutilisation Administrateur Le diagramme correspondant ladministrateur est illustr par la figure 11 : Figure 11 : Cas d'utilisation "administrateur" Conclusion du chapitre Ce chapitre nous a permis davoir une connaissance des diffrents profils dutilisateurs qui vont utiliser lapplication. 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 dexpliquer une partie du fonctionnement de lentreprise. 52. Chapitre 3 : Conception Introduction du chapitre La conception correspond la phase de modlisation du systme concevoir dans un langage de conception bien prcis. Comme au chapitre prcdent, nous utiliserons UML pour construire le diagramme de classes. Le choix de ce diagramme rside dans son utilit relle pour la suite du projet. I. Diagramme de classes : Description Le diagramme de classes est considr comme le plus important et est le seul tre obligatoire lors dune modlisation oriente objet. Aprs avoir prsent les cas dutilisation, nous avons vu quils permettaient de reprsenter le systme du point de vue des acteurs. Le diagramme de classe quant lui prsente la structure interne du systme. Il permet de reprsenter de faon abstraite et statique, les objets qui vont interagir pour la ralisation des cas dutilisation. Pour pouvoir tracer ce diagramme, il sera ncessaire de dterminer dabord les objets manipuls quon reprsentera sous forme de classes ainsi que les diffrentes relations qui les lient entre elles. II. Diagramme de classes par mtiers Lors des divers entretiens que nous avons effectus, il ressort que le systme dvelopper devra permettre de raliser les besoins exprims dans la phase prcdente. Pour une meilleure organisation et vu le nombre lev de cas dutilisation, 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 entits suivantes : Ordre : cette entit permettra de faire persister les Ordres de services ; Vehicule : elle contiendra les informations sur les Vhicules ; Entite : elle permettra de stocker les caractristiques des sites, des rgions et du sige ; Ville : nous allons y renseigner toutes les villes concernes par les activits ; Employe : cette entit permettra de grer les employs ; Message : pour expliquer les raisons dun refus de validation dun ordre de service ; Frequence : la frquence dexcution de lordre de services ; CarteCarburant : les Cartes de consommations de Carburant qui seront affectes au vhicule. 53. Chapitre 3 : Conception - 53 - Pour un ordre de service, il ressort que nous voulons connaitre sa mission, ses heures de dpart et darrive, sa date de dbut de validit, son statut, son tat, sa date de cration, sa frquence denvoi dans la semaine. Un ordre de service met en relation plusieurs entits de lentreprise et nous lui affectons un employ. Un vhicule est utilis pour excuter un ordre de services suivant un axe de transport. Un ordre de service cr par une rgion peut tre rejet. Dans ce cas, on lui associ un message dtaillant les raisons du rejet. (cf. Figure 13) Figure 12 : Gestion des ordres de services Lutilisation de diffrentes couleurs, dans la figure 13, indique la diffrence avec les classes implmentes dj dans OpenERP et celles que nous avons ajoutes. OpenERP possde dj les classes : employee, department, vehicle do le nom en anglais. Pour viter de refaire ce qui existe dj, nous avons choisi dutiliser lhritage. Lhritage, nous permet davoir tous les attributs de la classe mre, auxquels on peut ajouter nos propres attributs. Nous allons dans la suite de cette partie, dcrire les modles OpenERP dont nos modles ont hrites. Il sagit des points 4 et 5 sur les ressources humaines et le parc automobile. 54. Chapitre 3 : Conception - 54 - II.2. Gestion des dpches Les entits qui vont tre utiles pour cette partie sont : Depeche : cette entit reprsente une dpche avec tous ses attributs ; typeDepeche : elle correspond au type dune dpche ; Region : toutes les rgions cres sont reprsentes dans cette entit ; Entite : pour les entits qui y sont associes ; Message : pour expliquer les raisons dun refus de validation dun ordre de service ; Ordre : pour lordre de service associ ; Ville : pour les villes qui y sont associes. Pour une dpche, il ya lieu de connaitre son statut et son tat savoir si elle est valide, non valide ou rejete. Elle concerne des entits et est associe un ordre de services. Chaque dpche appartient un type bien dfini et nous pouvons lui joindre un message. (cf. Figure 15) Figure 13 : Gestion des dpches II.3. Gestion des suivis de dpches Les entits utilises seront : SuiviDepeche : cette entit permettra de stocker les informations pour suivre les dpches ; Entite : pour les entits associes ; Depeche : pour les dpches associes. 55. Chapitre 3 : Conception - 55 - Pour pouvoir assurer le suivi des dpches, nous avons besoins de connaitre, pour lentit suiviDepeche, les attributs tels que : la date de cration, les heures de dpart et darrive relle des dpches. (cf. Figure 14) Figure 14 : Gestion du suivi des dpches II.4. Gestion des ressources humaines Cette partie donne lieu dutiliser les entits : Employee : les employs sont reprsents travers cette entit ; employee_category : un employ appartient une catgorie et plusieurs catgories existent ; Department : les sites, les rgions et le sige seront logiquement reprsents par cette entit ; User : pour permettre la connexion des utilisateurs, les informations seront stockes ici. Un employ travaille pour un dpartement et peut y tre responsable. Il peut avoir un mentor et peut galement tre li un utilisateur. Il appartient au moins une catgorie. (cf. Figure 15) 56. Chapitre 3 : Conception - 56 - Figure 15 : Gestion des ressources Humaines II.5. Gestion du parc automobile A ce niveau, il nous sera important de connaitre les informations suivantes : Vehicle ; vehicle_model : modle du vhicule ; vehicle_tag : tiquette de vhicule ; 57. Chapitre 3 : Conception - 57 - vehicle_log_services : intervention sur le vhicule ; vehicle_log_contract : Contrat sur le vhicule ; contract_state : tat du contrat ; vehicle_log_fuel : consommation de carburant. Un vhicule appartient un modle. Tout au long de son utilisation, il peut faire lobjet de plusieurs interventions et consomme du carburant dont il est ncessaire de connaitre les cots de consommation. Un employ est affect au vhicule en tant que chauffeur. (cf. Figure 16) Figure 16 : Gestion du parc automobile Conclusion du chapitre La conception nous a permis de construire les schmas de base de donnes sur lequel toute lapplication sera construite. Compte tenu de la mthode de dveloppement par sprints que nous avons adopte, nous avons construit le diagramme par domaine mtiers. Toutefois en regroupant ces diffrents diagrammes, nous obtenons le diagramme correspondant au systme tout entier. 58. Conclusion de la partie travers cette partie, nous avons effectu un certain nombre dtudes qui nous ont permis tout dabord de comprendre le problme pos et les diffrents enjeux. Ensuite, nous avons exprim de faon concrte la solution propose travers la cration de profil utilisateur et des cas dutilisations. Ces cas dutilisations ont t dcrits laide de scnarios ou de diagrammes de squence. Enfin, nous avons construit le diagramme de classes correspondant au systme dvelopper. La conception ainsi ralise, il ya lieu maintenant de passer la concrtisation des concepts tudis. 59. Partie III. Etude technique et ralisation Introduction de la partie Cette partie a pour but de mettre en lumire le travail ralis au cours des diffrents sprints. En premier lieu nous aborderons les outils que nous avons eu utiliser tout au long du stage. Ensuite, nous entamerons un paramtrage des modules aprs avoir effectu une tude de convergence. Enfin, nous nous attarderons sur la ralisation du module Acheminement et les tests de dploiement effectus ; et le tout, illustr par des captures dcrans de lapplication. 60. Chapitre 1. Technologie mises en uvre Introduction du chapitre Pour le dveloppement des fonctionnalits nonces ci-haut lors des phases de conception, nous avons eu utiliser un certains nombres doutils. Dans ce chapitre, nous dtaillerons ces diffrentes technologies ainsi que leur rle pendant la ralisation du projet. I. OpenERP version 7 Figure 17 : Logo OpenERP Les ERPs (Entreprise Resource Planning), aussi appels Progiciel de Gestion Intgr (PGI), sont des applications dont le but est de coordonner lensemble des activits dune entreprise autour dun mme systme dinformation. Leur principe fondateur est de construire des applications correspondants aux diverses fonctions prcdemment cites, de manire modulaire. Ces modules devraient tre indpendants entre eux, tout en partageant une base de donnes unique. Il existe deux catgories dERPs : les ERPs propritaires, et les ERPs Open source. Les ERPs Open Source sont diffrents des ERPs propritaires, non pas en terme de fonctionnalits disponibles, mais sur tout ce qui touche la licence du produit, ainsi qu la personnalisation de ce dernier. La rduction des cots lis au non achat des licences dutilisation permet lentreprise, dinvestir largent ainsi conomis, dans une personnalisation accrue de leur ERP pour avoir un logiciel sur mesure, rpondant aux besoins de leurs activits. LERP que nous avons eu utiliser au cours de notre stage est lOpenERP. Fond en 2005 en Belgique par Fabien Pinckaers, il est devenu lERP Open source le plus tlcharg au monde. Il reprsente la nouvelle gnration des ERP avec son modle 100% Open source, sa modularit qui fait sa plus grande force ainsi que sa compatibilit avec les nouvelles technologies. Dailleurs, la rcompense reue lors des Bossie Award 2013 du meilleur logiciel Open source pour la deuxime anne conscutive nest pas une surprise en soi. Sa version 7 utilise tout au long de ce projet offre une interface web, une intgration forte avec Google Docs mais aussi une messagerie intgre ou encore des liens avec les rseaux sociaux. 61. Chapitre 1. Technologie mises en uvre - 61 - Avec plus 3000 modules sa disposition, OpenERP couvre de multiples domaines de gestion. Il suit les besoins du march, et son aspect volutif est plus quadmirable. Anciennement appel Tiny ERP , Ope