Gestion flotte acheminement_courrier

  • 298 views
Uploaded on

Conception et Réalisation d’une application pour la …

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
298
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
46
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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