Gestion programme moussanada avec openerp

Institut National de
Statistiques d’Economie Appliquée
Projet de Fin d’Etudes
*****
Conception et réalisation en OpenERP d’un système
d’information pour le programme Moussanada de l’ANPME
Juin 2014
Préparé par : Wafa ELKIHAL
-
Sous la direction de : Mr. Adil KABBAJ (INSEA)
Mme. Souad KINANAE (ANPME)
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 :
 Mr. Mohamed Nabil QASMI (INSEA)
 Mr. Adil KABBAJ (INSEA)
 Mr. Said MATAICH (ANPME)
ROYAUME DU MAROC
*-*-*-*-*
HAUT COMMISSARIAT AU PLAN
*-*-*-*-*-*-*-*
INSTITUT NATIONAL DE
DE STATISTIQUE ET D’ECONOMIE
APPLIQUEE
I N S E A

4
Dédicaces
A Dieu le tout puissant, mon créateur.
A mon 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.
A ma mère,
Ma raison d’être, ma raison de vivre, la lanterne qui éclaire
mon chemin et m’illumine de douceur et d’amour.
A mes frères.
A ma famille, mes amies et à tous mes proches.
Wafa

5
Remerciements
C’est pour moi un plaisir autant qu’un devoir de remercier toutes les personnes qui ont
pu contribuer de près ou de loin à l’élaboration de ce projet, qui m’ont aidé , m’ont
soutenu et ont fait en sorte que ce travail ait lieu.
Ainsi, j’adresse plus particulièrement mes plus sincères remerciements à Mr. Adil
KABBAJ, Professeur à l’INSEA et mon encadrant dans ce stage pour la confiance qu’il m’a
témoigné mais aussi pour la qualité de son encadrement, sa disponibilité et ses compétences
pédagogiques dont il a su me faire profiter. Je garde de son encadrement un exemple de
rigueur pédagogique et de sa personne un modèle de probité.
Il m’est agréable aussi de porter mes vifs remerciements à Monsieur Larbi
BENRAZZOUK le directeur général de l’agence ANPME qui a accepté ma demande de
stage, à Monsieur Said MATAICH et Madame Souad KINANE qui m’ont encadré tout au
long de ce projet.
J’adresse aussi mes remerciements à toute l’équipe du travail et à leur tête Mr.
DAOUDA Inouss Yago, le chef du projet, pour son soutien et ses précieux conseils.
Que tous les membres du jury retrouvent ici l’expression de ma reconnaissance pour
avoir accepté d’évaluer mon travail.

6
Résumé
Dans le cadre de la formation spécialisée Ingénieur d’état en Informatique à l’INSEA,
nous disposons d’une période de stage de quatre à six mois pour approfondir nos
connaissances et mettre en épreuve nos compétences acquises. Durant ce stage, effectué au
sein de l’Agence Nationale pour la Promotion des Petites et Moyennes Entreprises
« ANPME », nous avions pour objectif la conception et la réalisation d'un module OpenERP
pour la gestion du programme d’appui Moussanada afin d’améliorer et d’optimiser son
système d’information. Le travail a été effectué au sein d’un groupe, dirigé par un chef de
projet qui répartit les tâches et valide la partie qui nous a été affecté.
Dans un premier temps, nous avons eu pour mission de cerner le sujet et de délimiter le
périmètre du projet. Ensuite et après une analyse approfondie de la problématique, nous avons
pu diviser le projet en parties à savoir la gestion de la candidature, la gestion de la
contractualisation et la gestion du répertoire des compétences. Pour chaque partie, nous avons
suivi le processus d’étude des spécifications et des besoins, l’analyse, l’élaboration d’un
modèle conceptuel du système, puis la réalisation et la mise en œuvre.
Pour mener à bien le projet, nous avons suivi le cycle de développement en SCRUM, en
respectant les étapes de cette méthode, nous avons pu relever de manière itérative les besoins
de l’entreprise et nous avons dressé les objectifs à atteindre, pour la modélisation du système
nous avons utilisé le langage UML et lors de la réalisation de l’application, nous avons eu
recours à l’utilisation de plusieurs outils tout en respectant les différentes spécifications.
Finalement, chaque partie développée a été intégrée dans OpenERP et validée lors de la
réunion avec le client.
Mots-clefs:
Moussanada, OpenERP, La gestion de la candidature, La gestion de la contractualisation, La
gestion du répertoire des compétences

7
Abstract
As part of the State Engineer specialized training in Computer at INSEA, we have a
probationary period of four to six months to deepen our knowledge and to test our skills.
During this internship, conducted within the National Agency for the Promotion of Small and
Medium Enterprises ANPME, we aim to design and implementation of a module for
OpenERP management support Moussanada program in order to improve and optimize its
information system. The work was conducted in a group led by a project manager who
distributes tasks and validates the part that we were assigned.
At first, we had a mission to identify the subject and to define the scope of the project.
And then after a thorough analysis of the problem, we were able to divide the project into
parts, namely the management of the application, management contracting and management
skills inventory. For each part, we followed the process of studying the specifications and
needs analysis, development of a conceptual model of the system, then the realization and
implementation.
To complete the project, we followed the development cycle SCRUM, following the
steps of this method, we were able to iteratively identify business needs and we developed the
objectives for modeling system we used the UML and during the implementation of the
application, we resorted to the use of several tools while respecting the different
specifications. Finally, each part has been developed in OpenERP integrated and validated at
the meeting with the client.
Keywords:
Moussanada, OpenERP, Management contracting, Management of the application,
management skills inventory

8
Liste des abréviations
Abréviation Désignation
ANPME Agence Nationale pour la Promotion des Petites et Moyennes
entreprises
BPMN Business Process, model and notations
CNSS Caisse Nationale de Sécurité Sociale
CRM Customer Relationship Management
DPCI Délégations Provinciales du Commerce et de l’Industrie
ERP Entreprise Resource planning
GEDA Gestion électronique des dossiers d’appuis
MLD Modèle Logique des Données
MVC Model View Controller
PME Petite et Moyenne Entreprise
PV Procès-Verbal
RC Répertoire des compétences
SI Système d’Information
SSP Service Suivi et Planification
UML Unified Modeling langage
XML eXtensible Markup Language

9
Table des figures
Figure 1 : Organigramme de l’ANPME................................................................................... 18
Figure 2 : Interface d’accueil de l’ancienne application GEDA .............................................. 20
Figure 3 : Menu principal de l’application GEDA.................................................................. 20
Figure 4 : Cycle de la méthode Scrum .................................................................................... 23
Figure 5 : Liste des tâches à réaliser pendant le projet............................................................ 25
Figure 6 : Estimation des durées des tâches du planning........................................................ 26
Figure 7 : Parties prenantes dans le projet............................................................................... 28
Figure 8 : Processus global du programme d’appui ................................................................ 29
Figure 9 : Diagramme de collaboration du BPMN pour le processus .................................... 31
Figure 10 : Diagramme des cas d’utilisation pour le processus............................................... 33
Figure 11 : Diagramme de collaboration du BPMN pour le processus Contractualisation ... 38
Figure 12 : Diagramme des cas d’utilisation « Gestion de la contractualisation » ................. 39
Figure 13 : Diagramme de collaboration du BPMN pour le processus Référencement ........ 43
Figure 14 : Diagramme des cas d’utilisation « Référencement » ......................................... 44
Figure 15 : Diagramme de séquence « Traiter une candidature ».......................................... 49
Figure 16 : Traiter une contractualisation ............................................................................... 51
Figure 17 : Diagramme de packages....................................................................................... 52
Figure 18 : Vue globale du Diagramme des classes............................................................... 54
Figure 19 : Package 1 « Entreprise »....................................................................................... 55
Figure 20 : Diagramme des classes du package II ................................................................. 57
Figure 21 : Diagramme des classes du package III................................................................. 59
Figure 22 : Diagramme des classes du package IV................................................................. 60
Figure 23 : Diagramme des classes du package V.................................................................. 61
Figure 24 : Diagramme d’état-transition «Dossier de contractualisation».............................. 62
Figure 25 : Architecture technique d’un ERP .......................................................................... 64
Figure 26 : Architecture modulaire d’un ERP ........................................................................ 65
Figure 27 : Architecture d'un module d'OpenERP.................................................................. 66
Figure 28 : Page d’Authentification du Responsable de service Suivi et Planification........... 71
Figure 29 : Menu principal du Responsable de service Suivi et Planification......................... 71
Figure 30 : Formulaire d’ajout d’une entreprise ..................................................................... 72
Figure 31 : Formulaire d’ajout des chiffres d’affaire d’une entreprise ................................... 73
Figure 32 : Formulaire d’ajout d’une candidature ................................................................... 73

10
Figure 33 : Formulaire d’ajout d’un domaine d’intervention.................................................. 74
Figure 34 : Formulaire d’ajout des documents administratifs................................................. 74
Figure 35 : Etat initiale de la candidature « Brouillon » .......................................................... 75
Figure 36 : Passage de l’état Brouillon vers CA validé .......................................................... 75
Figure 37 : Saisie du rating par le chef Pôle Appui et Animation .......................................... 75
Figure 38 : Passage de l’état CV validé vers Rating validé .................................................... 76
Figure 39: Passage de l’état Rating validé vers l’état présélectionné ...................................... 76
Figure 40 : Passage de l’état présélectionnée vers l’état Eligible ........................................... 77
Figure 41 : Génération du PV d'éligibilité .............................................................................. 78
Figure 42 : Table zone sous access ......................................................................................... 79
Figure 43 : Conception du domaine zone................................................................................ 80
Figure 44 : Intégration du plugin.............................................................................................. 81
Figure 45 : La connexion avec le serveur ............................................................................... 81
Figure 46 : Choix de la base des données ............................................................................... 82
Figure 47 : Ouverture d’un nouveau rapport........................................................................... 82
Figure 48 : Choix du module à traiter ..................................................................................... 82
Figure 49 : L’envoi du rapport au serveur............................................................................... 83
Figure 50 : Configuration du serveur mail sortant .................................................................. 84
Figure 51 : Exemple d’un modèle réalisé « Lettre d’éligibilité » ........................................... 85
Figure 52 : Page d’accueil....................................................................................................... 97
Figure 53 : Liste des classes de notre projet............................................................................ 97
Figure 54 : Séléction des tables à importer ........................................................................... 100
Figure 55 : La jointure des champs ....................................................................................... 100
Figure 56 : Table aprés l’importation.................................................................................... 101

11
Liste des tableaux
Tableau 1 : Acteurs participant « coté ANPME »................................................................... 24
Tableau 2 : Acteurs participant « coté INSEA »..................................................................... 24
Tableau 3 : Description du scénario « Soumettre la demande de la candidature ».................. 34
Tableau 4 : Description du scénario « Traiter la demande de la candidature » ....................... 36
Tableau 5 : Description du scénario «Vérifier le dossier de contractualisation»..................... 41
Tableau 6: Traiter la demande de référencement ..................................................................... 45
Tableau 7 : Dictionnaire des données ...................................................................................... 95

Table des matières
12
Table des matières
Liste des abréviations................................................................................................................. 8
Table des figures ........................................................................................................................ 9
Liste des tableaux..................................................................................................................... 11
Introduction générale ................................................................................................................ 14
Partie 1 Contexte génaral du projet ..................................................................................... 15
Chapitre 1 Présentation de l’organisme d’accueil........................................................ 16
1.1 Présentation de l’ANPME........................................................................................ 16
1.2 Rôles et missions ..................................................................................................... 16
1.3 Le service Système d’Information de l’ANPME ..................................................... 19
Chapitre 2 Présentation du projet................................................................................ 20
2.1 Etude et critique de l’existant................................................................................... 20
2.1.1 Description de l’existant................................................................................... 20
2.1.2 Critique de l’existant ........................................................................................ 21
2.2 Contexte général du projet ....................................................................................... 21
2.3 Description des objectifs du projet........................................................................... 21
2.4 Conduite du projet.................................................................................................... 22
2.4.1 Motifs du choix de la méthode agile SCRUM ................................................. 22
2.4.2 Présentation de la méthode SCRUM................................................................ 22
2.5 Organisation du projet.............................................................................................. 23
2.5.1 Participants au projet........................................................................................ 24
2.5.2 Planning du projet ............................................................................................ 24
2.5.3 Estimation des tâches ....................................................................................... 26
Conclusion................................................................................................................................ 26
Partie 2 Analyse et conception du projet............................................................................. 27
Chapitre 3 Analyse et conception du projet............................................................ 28
3.1 Description du métier............................................................................................... 28
3.2 Analyse des besoins des utilisateurs......................................................................... 30
3.2.1 Workflow du traitement « gestion de la candidature » .................................... 30
3.2.3 Workflow du traitement « gestion de la contractualisation »........................... 37
3.2.4 Workflow du traitement « Référencement»..................................................... 42
3.3 Etude conceptuelle ................................................................................................... 46

Table des matières
13
3.3.1 Diagramme de séquence.................................................................................. 46
3.3.2 Diagramme de packages.................................................................................. 52
3.3.3 Diagramme des classes..................................................................................... 53
3.3.4 Diagramme d’état-transition « Dossier de contractualisation »....................... 62
Partie 3 Réalisation et mise en œuvre de l’application .................................................... 63
Chapitre 4 Réalisation et mise en œuvre de l’application................................................. 64
4.1 Contexte fonctionnel du projet................................................................................. 64
4.1.1 ERP................................................................................................................... 64
4.1.2 Architecture modulaire..................................................................................... 64
4.1.3 OpenERP .................................................................................................. 65
4.1.4 Architecture d’un module d’OpenERP ............................................................ 66
4.1.5 Etapes d’intégration d’un module dans OpenERP........................................... 67
4.2 Outils de réalisation................................................................................................. 67
4.3 Présentation de l’application .................................................................................... 70
4.3.1 Traitement d’une candidature........................................................................... 70
4.3.1 Génération du PV d’éligibilité ......................................................................... 77
Chapitre 5 Migration des données .......................................................................... 79
5.1 Etude préalable des deux bases de données .............................................................. 79
5.2 Migration.................................................................................................................. 80
Chapitre 6 Reporting............................................................................................... 81
Chapitre 7 Intégration du mailing ........................................................................... 84
Chapitre 8 L’aspect de sécurité............................................................................... 86
Conclusion générale ................................................................................................................. 89
Bibliographie............................................................................................................................ 90
Annexes.................................................................................................................................... 91
Annexe A Dictionnaire Des Données ................................................................................ 92
Annexe B Documentation avec Sphinx............................................................................. 96
Annexe C Identification des règles de gestion .................................................................. 98
Annexe D Exemple d’importation de la table activité ..................................................... 100

14
Introduction générale
Les technologies de l’information ont connu une importante évolution durant ces
dernières années, ce qui a donné comme résultat l’émergence de plusieurs solutions
informatiques qui permettent de créer une synergie entre les intervenants des différentes
divisions et départements dans le but d’optimiser le fonctionnement global.
L’Agence Nationale pour la Promotion des Petites et Moyennes Entreprises fait partie
de ces entreprises qui cherchent à moderniser leur SI, et souhaite mettre en place un système
pour la gestion de son programme d’appui Moussanada qui accorde aux petites et moyennes
entreprises un accompagnement pour l’exécution de plusieurs actions de modernisation.
Le processus métier de Moussanada comporte trois phases majeures qui sont le traitement des
candidatures, la contractualisation et le référencement des prestataires dans le répertoire des
compétences de l’ANPME.
Par ailleurs, l’ANPME a opté pour le progiciel OpenERP pour la gestion de son SI qui
propose des modules pour la gestion des ressources humaines, la comptabilité ainsi que
d’autres modules, mais il ne permet pas la gestion des programmes spécifiques tels que le
programme d’appui Moussanada.
C’est dans ce contexte que nous avons conçu et implémenté un module composé des
parties suivantes : la candidature, la contractualisation et le référencement.
Le rapport suivant est structuré comme suit :
Partie 1 situe le contexte du projet à travers la présentation de l’organisme d’accueil, la
définition de la problématique ainsi que la démarche suivie pour la réalisation.
Partie 2 concerne l’étude fonctionnelle, à savoir la spécification des besoins recensés auprès
des différents acteurs du système, l’analyse et l’étude conceptuelle du système.
Partie 3 présente les différentes technologies utilisées et expose ensuite les résultats de
l’implémentation. Finalement nous présentons la conclusion du travail ainsi que les
perspectives envisagées.

15
Partie 1
Contexte général du projet
L’objectif visé de cette partie est de présenter l’organisme d’accueil ainsi que
la problématique. Ensuite elle décrit la méthode de conduite du projet tout en
expliquant les motifs de ce choix et la planification qui en découle.

Chapitre 1 Présentation de l’organisme d’accueil
16
1.1 Présentation de l’ANPME [4]
Instrument opérationnel des pouvoirs publics en matière de développement des PME,
l’Agence Nationale pour la Promotion de la Petite et Moyenne Entreprise est au cœur du
dispositif marocain d’appui aux entreprises. Grâce à la large gamme de produits qu’elle a pu
développer et enrichir depuis sa création en 2002, l’ANPME accompagne les PME à
développer leur Compétitivité.
L’ANPME met à la disposition des PME deux programmes phares qui sont :
 Le programme Imtiaz qui vise un accompagnement volontariste d'entreprises
sélectionnées, repose sur l'établissement de Contrats de Croissance avec ces entreprises
et l'octroi d'une prime à l'investissement matériel et immatériel correspondant à 20% de
l'investissement total et plafonnée à 5 millions de DH, les bénéficiaires apportant un
minimum de 20% de l'investissement total en fonds propres, le reliquat étant financé par
un prêt bancaire
 Le programme Moussanada qui vise un accompagnement des entreprises dans leur
démarche de modernisation et d'amélioration de la productivité par la mise en place de
programmes d'appui transverses et sectoriels et par le financement, à hauteur de 60%, du
coût total des prestations de services et/ou d'acquisition des systèmes d'information,
plafonné à 1 million de DH.
Ces programmes s'inscrivent dans le cadre du Pacte National pour l'émergence Industrielle
(PNEI) signé en février 2009, cadre de référence de l'action de l'Agence, car il concentre de
manière contractuelle les engagements mutuels des différents opérateurs économiques, et
représente un gage de bonne exécution des mesures proposées et de leur financement.
1.2 Rôles et missions [4]
Conformément à l’article 5 de la loi formant la PME, l’ANPME est l’instrument
opérationnel des pouvoirs publics en matière de promotion et de développement de la PME.
A ce titre, la mission principale de l’ANPME est de piloter et de coordonner le programme
national de la mise à niveau. A cet effet, l’ANPME œuvre à :
 L’élaboration et la mise en œuvre de programmes visant la création, la promotion et la
mise à niveau des entreprises à travers une prise en charge d’une partie des dépenses
engagées par la PME dans le cadre de ces programmes.
 La contribution à l’amélioration de l’environnement des PME par le biais du soutien et
de l’encouragement aux réseaux et aux structures des PME, de l’assistance et de la
promotion du partenariat au niveau national et international ainsi qu’entre PME et
grandes entreprises, de la proposition de mesures de simplification administratives.

17
 L’amélioration de l’accès de la PME aux terrains et locaux professionnels à des prix
avantageux, grâce à une prise en charge d’une partie des coûts d’aménagement des
infrastructures y afférentes.
La structure organisationnelle de l’agence est modelée pour être orientée vers la PME comme
suit : (Fig. 1)
 La direction générale ;
 Une cellule chargée du contrôle de gestion ;
 Un chargé de mission ;
 Deux pôles comprenant deux divisions pour les activités directes et deux divisions pour
les activités de support ;
 Une division des ressources humaines et financières.
La figure 1 présente l’organisation de l’agence en spécifiant les différents services ainsi que
les divisions.

18
Figure 1 : Organigramme de l’ANPME [4]

19
1.3 Le service Système d’Information de l’ANPME [4]
Le service Système d’Information est chargé d’une part de définir les objectifs
stratégiques du système d’information de l’agence notamment l’élaboration des cahiers des
charges, de définir et de formuler les besoins en termes d’informations des utilisateurs du
système et d’autre part gérer l’infrastructure informatique depuis la définition de la
configuration globale, jusqu’aux aspects techniques concernant l’administration, la sécurité,
l’optimisation de l’utilisation ainsi que l’assistance aux utilisateurs.
Le Service Système d’Information est chargé de:
 Assurer le bon fonctionnement de l’infrastructure informatique et du réseau de
l’ANPME ;
 Gérer, maintenir et faire évoluer l’infrastructure applicative ;
 Assister les utilisateurs ;
 Administrer le réseau informatique et le système de la sécurité informatique.

Chapitre 2 Présentation du projet
20
2.1 Etude et critique de l’existant
L’étude de l’existant est une étape clé dans la réalisation de n’importe quelle application
informatique, quel que soit le domaine concerné. Il s’agit d’une étude permettant de
comprendre la problématique du projet.
2.1.1 Description de l’existant
Pour la gestion du programme Moussanada, plusieurs systèmes informatiques ont été
mis en place. L'application actuellement en production appelée GEDA est développée sous
Access. Il s’agit d’une application de gestion des documents relatifs à ce programme.
La figure 2 présente le menu de l’application GEDA, cette dernière donne l’accès aux
dossiers de candidatures, aux référentiels ainsi qu’aux statistiques.
Figure 2 : Interface d’accueil de l’ancienne application GEDA [3]
La figure 3 est une capture de la page d’accès aux dossiers de candidatures, elle permet
d’enregistrer, de visualiser les demandes et de vérifier par la suite l’exhaustivité des
informations.
Figure 3 : Menu principal de l’application GEDA [3]

21
2.1.2 Critique de l’existant
L'application actuellement en production est développée sous Access ce qui a engendré
plusieurs inconvénients à savoir :
 L’ergonomie des interfaces ;
 L’absence d’interface d’échange entre les parties prenantes ;
 La lenteur du système ;
 Problèmes dans l’enregistrement des données.
La base de données de l’ancienne application présentait des problèmes liés à la
redondance des données. Après l’avoir analysé, nous avons constaté qu’il y a des problèmes
de normalisation. Par exemple, la suppression d’une entité pourra engendrer la suppression de
d’autres entités qui lui sont relatives.
2.2 Contexte général du projet
Dans un souci de modernisation du système d'information et afin de pallier aux
problèmes présents dans l'application GEDA, l'ANPME a prévu de mettre en œuvre un
modèle qui permettra d'assurer l'intégrité des données, la non-redondance de l'information et
facilitera l'échange entre les différents utilisateurs du système afin de réduire le temps de
traitement.
Ce besoin émane de la volonté de bénéficier des avantages en terme de puissance de la
plateforme OpenERP et donc palier aux problèmes d’évolutivités recensés dans l’ancienne
application dédiée à la gestion électronique des documents d’appui basé sur le système de
gestion de base de donnée Access. Il s’inscrit dans un cadre à doubles finalités, à savoir une
formation sur les techniques de développement en environnement OpenERP et un
accompagnement dans la mise en place du projet.
2.3 Description des objectifs du projet
Le système d'information à développer doit permettre l’ANPME de doter d’un outil de
gestion moderne et complet et il a par conséquent les objectifs suivants:
 Analyse, conception, développement et la génération des rapports pour les parties
suivantes :
o Candidature : Il s’agit de la gestion du processus d’enregistrement et du
traitement des demandes de candidatures en vue de leur accorder les avantages
du programme Moussanada.
o Contractualisation : C’est la deuxième étape qui concerne la préparation des
contrats entre l’entreprise bénéficiaire, le prestataire et l’ANPME.
o Référencement : Il s’agit de l’inscription des entreprises prestataires dans le
répertoire des compétences de l’ANPME.

22
 Assurer la communication entre les différentes parties prenantes du projet, internes et
externes, afin d'optimiser le processus du programme;
 Avoir un tableau de bord permettant de donner une vue globale sur le déroulement des
activités;
 La reprise des données historiques dans le nouveau schéma de la base de données à
partir d’Access;
 La gestion du rating bancaire : Vu les interactions permanentes entre les institutions
bancaires et l’ANPME, cette gestion bancaire vise à simplifier la procédure de rating au
moyen du système ;
 La gestion de portefeuille Rimaniste porte sur la gestion d’affaires par partenaire
Rimaniste, à savoir les dossiers à succès et ceux non aboutis ;
 La mise en place des portails pour les différents acteurs pour simplifier et favoriser les
interactions entre eux.
Il est à noter, que dans les chapitres qui suivent, nous allons traiter la gestion de la
candidature, la contractualisation, le référencement ainsi que la migration des données.
Pour les portails et la gestion du portefeuille Rimaniste, ils seront traités dès la livraison du
premier produit au client.
2.4 Conduite du projet
Une méthode agile propose de vérifier au fur et à mesure que le projet évolue dans la bonne
direction, son principe est simple : il s’agit de découper le projet en plusieurs étapes ou petits
projets. Chacune de ces étapes doit aboutir à la création d’un élément fonctionnel de
l’ensemble, qui s’inscrit dans les objectifs du projet.
2.4.1 Motifs du choix de la méthode agile SCRUM
Parmi les différentes méthodes agiles connues, nous nous sommes mis d’accord avec le
chef de projet sur la méthode SCRUM (Fig. 4) pour sa conformité avec la nature de notre
projet et l’environnement du travail. Une telle méthode va nous permettre de développer
l’application de manière incrémentale en maintenant une liste totalement transparente des
demandes d’évolutions ou de corrections à implémenter. De surcroit, cette méthode permet
d’avoir un maximum d’interaction avec le client afin de définir pas à pas le cahier des charges
et les éventuelles corrections.
2.4.2 Présentation de la méthode SCRUM [8]
La méthode Scrum se base sur les principes clefs suivants :
 Interaction du client : la méthode Scrum privilégie les individus et donne l’importance aux
valeurs du travail accompli, ceci améliore la productivité et l’efficacité de ce qui est
fourni.

23
 Priorité au produit: dans les méthodes agiles, le seul critère qui influence l’avancement du
projet est la fiabilité du produit fourni.
 Collaboration du client : elle est indispensable pour l’avancement du projet et
l’implémentation de toutes les fonctionnalités préétablies.
 Flexibilité aux fluctuations : Scrum est conçue pour s’adapter aux changements en
assurant un plan macroscopique précis et adaptatif, elle est réactive aux fluctuations des
marchés et s'assure en plus que le logiciel développé répond parfaitement à ses véritables
besoins.
Le schéma suivant (Fig. 4) représente les éléments constitutifs de la méthode Scrum.
Figure 4 : Cycle de la méthode Scrum [5]
-L’équipe : Elle est constitué afin de disposer de toutes les compétences nécessaires au
développement du produit.
-Sprint : Scrum utilise la technique des blocs de temps pour créer de la régularité.
-Backlog : Scrum impose peu d’artefacts à l’équipe pendant le développement.
2.5 Organisation du projet
Dans cette partie nous allons décrire l’organisation et les dispositions spécifiques prises
par le groupe du projet dans le but d’obtenir et d’assurer le niveau de qualité exigé dans les
spécifications.

24
2.5.1 Participants au projet
Les participants au projet se répartissent en deux groupes :
 Côté ANPME (Tab. 1)
Personne Rôle
Mr. YAGO Inouss Consultant OpenERP
Mme. KINANE Souad Responsable SI
Mlle. CHAHMI Lamiae Stagiaire ANPME
Tableau 1 : Acteurs participant « coté ANPME »
 Côté INSEA (Tab. 2)
Personne Rôle
Mr. KABBAJ Adil Professeur à INSEA
Mlle. ELKIHAL Wafa Stagiaire élève ingénieur
Tableau 2 : Acteurs participant « coté INSEA »
2.5.2 Planning du projet
La planification est une étape indispensable pour la réussite d’un projet informatique.
Pour cela, nous avons établi un macro-planning des tâches à effectuer ainsi que leurs durées
approximatives de réalisation et nous avons découpé notre projet en Sprint. Ce planning a été
réalisé suite aux différentes réunions avec nos encadrants.
Ce travail a été effectué avec le diagramme de Gantt qui est un outil qui permet la
modélisation de la planification des tâches nécessaires à la réalisation du projet.
Le projet est divisé en quatre Sprints de durée variable entre trois, quatre ou cinq
semaines selon la consistance des tâches à réaliser et la figure 5 montre l’ensemble des tâches
qui ont été planifiées.

25
Figure 5 : Liste des tâches à réaliser pendant le projet
Chaque sprint constitue un jalon qui, une fois réalisé, aboutit à un produit qui peut être mis en
production. Pour notre projet les livrables sont les suivants :
 Pour le sprint 1: Rédaction du dossier de spécifications fonctionnelles
Rédaction du rapport du stage, partie 1
 Pour le sprint 2: Réalisation du document de la conception
Réalisation de la recette 1 « Partie de la candidature »
 Pour le sprint 3: Réalisation du dossier de la conception
Réalisation de la recette 2 « Partie de la contractualisation et
répertoire des compétences »
 Pour le sprint 4: Présentation du projet complet
Réalisation du manuel d’utilisateur
Réalisation du manuel technique
Présentation du rapport final

26
2.5.3 Estimation des tâches
La figure 6 présente l’estimation des durées de chaque Sprint réalisé ainsi que le livrable
associé. Ce diagramme de Gantt a été réalisé avec MS Project.
Figure 6 : Estimation des durées des tâches du planning.
Conclusion
Ce chapitre a été le point de départ pour la présentation de notre projet, dans la mesure
où il décrit son contexte général. Dans la suite, nous allons décrire le processus métier et
détailler les différentes fonctionnalités qui nous ont permis de constituer le dossier de la
conception.

27
Partie 2
Analyse et conception du projet
Dans cette partie, nous présentons l’analyse et la conception des parties
développées de notre module, ceci concerne le processus de la candidature et
son éligibilité ensuite celle de référencement au répertoire des compétences
et enfin la phase de contractualisation entre les parties prenantes.

Chapitre 3 Analyse et conception du projet
28
3.1 Description du métier
Le programme Moussanada fait intervenir plusieurs parties prenantes (Fig. 7) :
 La PME est placée au cœur de la procédure et constitue la cible du programme d’appui ;
 L’état représenté par le Ministère de l’Economie et des Finances ainsi que le Ministère de
l’Industrie du commerce et des nouvelles technologies, joue un rôle stratégique et
financier dans le cadre de la convention de partenariat avec l’ANPME ;
 L’ANPME joue un rôle stratégique et opérationnel dans la mesure où elle joue un rôle
d’intermédiaire entre le prestataire et le bénéficiaire et met à la disposition de ce dernier
un ensemble de prestataires référencés ;
 Le prestataire joue un rôle promotionnel et opérationnel. C’est une entreprise qui propose
des offres de services auprès de l’ANPME. Le bénéficiaire ayant validé le choix du
prestataire, signe une convention de prestation de services avec le bénéficiaire ;
 Le partenaire est une personne physique ou morale, publique ou privée, nationale ou
internationale, contribuant à une action conjointe avec l’ANPME ;
 Relais d’informations : il s’agit des acteurs régionaux jouant le rôle de relais
d’information et de communication de l’ANPME auprès des entreprises pouvant
bénéficier du programme. Le réseau Rimane en est un exemple, il est constitué
d’intervenants relevant des Délégations Provinciales du Commerce et de l’Industrie ;
 Les banques interviennent pour le renseignement du rating des entreprises candidates. Il
s’agit de tableaux de notation des entreprises basées sur des grilles de scoring tenant en
compte plusieurs critères.
Figure 7 : Parties prenantes dans le projet

29
La mission du programme Moussanada comprend la réception de la demande de
candidature, la vérification de l’éligibilité au programme d’appui, la contractualisation dans le
cas favorable et finalement le suivi des actions. Le client ayant choisi son prestataire doit faire
une demande de référencement de ce dernier dans le répertoire des compétences de l’ANPME
au cas où il n’y figure pas. Son dossier de contractualisation demeure suspendu jusqu’à ce que
le référencement soit effectué.
La figure 8 permet de donner une vue global sur le processus Moussanada.
Figure 8 : Processus global du programme d’appui [3]
Le but de Moussanada est la modernisation de l’entreprise à travers la réalisation
d’actions d’appuis réalisées par des prestataires. Ces actions d’appuis sont subventionnées en
partie par l’ANPME.
Et d’après la figure les différentes étapes de ce programme pourront être résumées comme tel:
 Saisie de la demande de l’entreprise cliente ;
 Vérification de l’éligibilité au programme Moussanada ;
 La contractualisation ;
 La gestion du répertoire des compétences ou bien ce que nous appelons le référencement ;
 Le suivi des actions.
Aux vus de toutes ces procédures résumant l’activité du programme, et suite à des contraintes
du temps nous allons se concentrer dans notre travail sur les phases majeurs du projet citant : *
 La gestion de la candidature et son workflow ;
 La gestion de la contractualisation ;
 La gestion du répertoire des compétences.
Saisie de
la demande
Vérification
de l’éligibilité
Contractualisation
Référencement
Suivi des actions

30
3.2 Analyse des besoins des utilisateurs
L’identification des cas d’utilisations permet de décrire et de formaliser les exigences et
les fonctionnalités. Pour avoir une vision plus claire, nous avons choisi de les regrouper par
module. Rappelons que notre système se compose de trois modules essentiels qui sont la
candidature, la contractualisation et le référencement.
3.2.1 Workflow du traitement « gestion de la candidature »
3.2.1.1 Description du workflow [1]
La procédure d’éligibilité de la demande dans le programme Moussanada correspond au
contrôle des entreprises bénéficiaires concernant le respect des exigences fixées pour la
validation de demande d’appui. Elle débute par une soumission de la candidature de
l’entreprise souhaitant bénéficier du programme Moussanada, candidature appuyée par la
constitution de documents spécifiques tels que l’attestation fiscale et la CNSS, le registre de
commerce, l’attestation du chiffre d’affaire ainsi que le formulaire de candidature. Une fois la
candidature réceptionnée par le service de secrétariat du suivi et planification, celui-ci procède
à l’enregistrement du dossier de demande d’appui ce qui engendrera un accusé de réception
chez l’entreprise candidate.
La demande enfin enregistrée sera transmise au chef du service appui et animation qui
aura comme mission d’évaluer la crédibilité bancaire du candidat. Pour cela, il envoie une
demande de rating bancaire à la banque concernée par le demandeur. L’un des intérêts de ce
projet serait de disposer d’un portail pour les institutions bancaires qui pourront renseigner les
valeurs de rating pour chaque bénéficiaire dans un délai de 2 jours. Si l’évaluation bancaire
n’est pas favorable, le chef de suivi et planification ou le secrétariat du pôle appui et animation
envoi une lettre de refus qui se fera à partir du système réalisé, et dans un deuxième temps, via
un fax.
Dans le cas d’un rating favorable, le chef de suivi et planification procède à la
vérification des documents requis et envoie des demandes de compléments dans la perspective
de compléter le dossier d’appui. Une fois le dossier complet, il édite le PV d’éligibilité aussi
appelé PV de présélection, et notifie par voie électronique le demandeur. Le PV d’éligibilité est
ensuite délivré au chef de division qui effectuera les tâches suivantes :
 Vérifier la conformité du PV d’éligibilité
 Affecter le dossier d’appui à un chef de projet
 Signer le PV d’éligibilité
 Signer la lettre de notification d’accord délivrée au demandeur
L’étape suivante concerne le chef de projet qui se charge de rentrer en contact avec
l’entreprise bénéficiaire dans le but d’actualiser les données du demandeur à savoir mettre à
jour le statut et valider les informations du dossier d’appui. Il devra aussi participer à la

31
définition des actions et leur priorisation dans le cadre d’actions planifiées dans le cadre d’un
plan progrès.
3.2.1.2 Processus métier
La figure 9 présente le diagramme de collaboration qui décrit le workflow du traitement
de la candidature de l’entreprise cliente.
Ce diagramme permet de représenter les échanges et les interactions qui se nouent entre deux
ou plusieurs unités d'affaires représenté par des Bassins. Les Bassins sont définis comme étant
les Participants de cette collaboration. Les messages échangés entre les participants du
diagramme de Collaboration sont présentés à l'aide du symbole Flux de message. Ce symbole
permet de connecter les bassins entre eux.
Figure 9 : Diagramme de collaboration du BPMN pour le processus
: Passerelle parallèle
: Passerelle exclusive

32
3.2.1.3 Diagramme des cas d’utilisation « Traitement d’une candidature »
Ce diagramme des cas d’utilisation modélise les interactions entre les différents acteurs
interne tel que : le chef de service Suivi et Planification, le chef de service Appui et Animation,
le chef de division et des acteurs externes tel que : les institutions bancaires et l’entreprise
candidate. (Fig. 10)
Les cas d’utilisation associés à ce module sont :
 Soumettre la demande de la candidature ;
 Traiter la demande ;
o Vérifier l’éligibilité ;
o Demander la valeur du rating ;
 Choisir un chargé de projet ;
 Affecter le dossier à un chargé de projet ;
 Valider l’éligibilité de l’entreprise ;
 Traiter la valeur du rating reçu.

33
Figure 10 : Diagramme des cas d’utilisation pour le processus

34
3.2.1.4 Description des scénarios
Pour bien comprendre les différentes fonctionnalités du système, nous avons élaboré la
description de quelques scénarios.
Description du scénario « Soumettre la demande de la candidature »
Sommaire d’identification
Titre Soumettre la demande de la candidature
Résumé Ce cas d’utilisation illustre la procédure qui
permet à un client de remplir et soumettre le
formulaire de la demande de candidature.
Acteurs Client / PME
Description du scénario
Pré-condition Client authentifié
Scénario nominal
1. Le client sollicite la création d’une
candidature ;
2. Le système envoie le formulaire à remplir ;
3. Le client remplit les informations requises ;
4. Le système vérifie si tous les champs
obligatoires ont été remplis ;
5. Le système vérifie si la candidature existe
déjà ;
6. La nouvelle candidature est enregistrée ;
Enchaînements
alternatifs
A1 : Le client n’a pas rempli un champ obligatoire.
L’enchaînement A1 démarre au point 4 du
scénario nominal.
4.1. Le système informe le client qu’il doit remplir
le champ
Le scénario nominal reprend au point 3
Post-condition La candidature du client est enregistrée
Tableau 3 : Description du scénario « Soumettre la demande de la candidature »

35
Description du scénario « Traiter la demande»
Titre Traiter la demande
Résumé
Ce cas d’utilisation illustre la procédure qui
permet au chef de suivi et de planification de
traiter la demande du client tout en vérifiant son
éligibilité.
Acteurs Chef de suivi et de planification
Description des scénarios
Pré-condition Chef authentifié
Scénario nominal
1. Le chef du service « suivi et planification »
demande de visualiser la liste des demandes;
2. Le système affiche la liste des candidatures à
traiter ;
3. Le chef choisit une candidature pour la
traiter ;
4. Le chef vérifie les informations saisies ;
5. Le chef vérifie si le rating reçu de la banque
concernant l’entreprise candidate est valide
ou non ;
6. Le chef vérifie la validité du Chiffre
d’Affaire ;
7. Le chef notifie les autres acteurs de
l’éligibilité ou non de l’entreprise.
Enchaînements
alternatifs
A1 : Le chef de suivi et planification détecte une
erreur au niveau des informations saisies
scénario nominal
4.1. Le chef envoie une notification au client
pour qu’il modifie les champs erronés.
A2 : Le chef de suivi et planification détecte que
le rating n’est pas valide

36
scénario nominal
5.1. Le chef envoie une notification au client
pour lui indiquer la non validité de son rating
Le scénario nominal reprend au point 1.
Post-condition La décision est prise concernant la candidature
(éligible ou non).
Tableau 4 : Description du scénario « Traiter la demande de la candidature »

37
3.2.3 Workflow du traitement « gestion de la contractualisation »
3.2.31 Description du workflow [1]
La procédure de la contractualisation survient après la déclaration de l’éligibilité du
candidat qui devient à cet effet bénéficiaire des actions demandées et consiste en l’élaboration
des clauses régissant les accords triparties entre entreprise bénéficiaire, l’ANPME et le
prestataire.
Le chef de division assigne un chef de projet au dossier de l’entreprise bénéficiaire, ce dernier
est tenu d’examiner les offres de services dans le cadre des actions individuelles comme dans le
cadre des actions planifiées dans le cadre d’un plan progrès.
Dès réception du procès-verbal de présélection, le chef de projet prend contact avec le
bénéficiaire et le prestataire, dans le but de s’assurer de la cohérence des documents à fournir
pour le dossier de contractualisation.
Les documents à fournir par le bénéficiaire ou prestataire sont les suivants:
 Les contrats de prestations de services.
 Les offres de services.
 Les conventions de partenariat.
Le chef de projet en possession de ces documents a pour mission de vérifier le respect et
la cohérence des documents par rapport aux canevas de l’ANPME. Il doit vérifier le
référencement du bureau d’études et du consultant qui assurera l’accompagnement.
Entres autres, le chef de projet devra s’assurer du respect des plafonds de contribution prévus
par l’ANPME par action et par zone. Celui-ci pourra approuver le dossier de contractualisation
et statuera sur l’opportunité d’une visite. Cette visite donnera lieu à un rapport de visite de
lancement du projet. Ce dossier de contractualisation une fois constitué et approuvé sera
transmis au chef de suivi et planification. Dans le cas où le consultant prestataire n’est pas
référencé, le chef de projet pourra entamer la procédure de référencement.

38
Figure 11 : Diagramme de collaboration du BPMN pour le processus Contractualisation

39
La figure 11 présente le diagramme de collaboration qui décrit le workflow du traitement de la
contractualisation.
Ce diagramme permet de représenter les échanges et les interactions entre le chef de projet qui
se charge de la vérification de la validité du dossier reçu, le chef de division ainsi que le
prestataire.
3.2.3.3 Diagramme des cas d’utilisation « Gestion de la contractualisation »
La figure 12 présente le diagramme des cas d’utilisation qui modélise les interactions entre les
différents acteurs tel que : le chef de projet, le bénéficiaire ainsi que le prestataire. Les cas
d’utilisation associés à ce module sont :
 Vérifier le dossier de contractualisation ;
 Validation du dossier de contractualisation ;
 Vérification du référencement du prestataire ;
 Visualiser les dossiers des clients ;
 Notifier le bénéficiaire de l’état de son dossier.
Figure 12 : Diagramme des cas d’utilisation « Gestion de la contractualisation »

40
Description du scénario «Vérifier le dossier de contractualisation»
Titre Vérifier le dossier de contractualisation
Résumé
permet à un chef de projet de vérifier le
respect du dossier de contractualisation
selon les critères de l’ANPME en
l’occurrence la cohérence des documents
par rapport aux canevas, le référencement
du bureau d’études du consultant et le
respect des plafonds de contributions de
l’ANPME.
Acteurs Chef de projet
Pré-condition Chef de projet authentifié
Scénario nominal 1. Le chef de projet demande à visualiser
les demandes de contractualisation
reçues ;
2. Le système affiche la liste des
dossiers reçus ;
3. Le chef choisit un dossier pour le
traiter ;
4. Le chef vérifie la cohérence des
documents par rapport aux canevas ;
5. Le chef vérifie le référencement du
bureau d’études du consultant ;
6. Le chef vérifie le respect des plafonds
de contributions de l’ANPME ;
Enchaînements
A1 : Le chef de projet détecte le non-
respect de l’un des critères de validité d’un
dossier de contractualisation

41
alternatifs scénario nominal
4.1. Le chef envoie une notification au
bénéficiaire pour qu’il règle ce problème.
A2 : Le prestataire n’est pas référencé au
répertoire des compétences de l’ANPME.
L’enchainement A2 démarre au point 5 du
scénario nominal
5.1 Le chef envoie une demande de
référencement du prestataire, si ce dernier
ne vérifie pas les critères de référencement,
le chef de projet demande au bénéficiaire
de choisir un prestataire référencé.
Le scénario nominal reprend au point 1.
Post-condition
1. La décision est prise concernant le
dossier de contractualisation (validé ou
non)
2. Validation de la convention de
partenariat.
Tableau 5 : Description du scénario «Vérifier le dossier de contractualisation»

42
3.2.4 Workflow du traitement « Référencement»
3.2.4.1 Description du workflow [1]
Le répertoire des compétences constitue un ensemble d’informations structurées
concernant les prestataires susceptibles d’être présélectionnés dans le cadre de la mobilisation
de l’expertise directement par l’ANPME, le(s) entreprise(s) ou le(s) partenaire(s). Une
classification peut être effectuée suivant les domaines d’activité ou par nature d’intervention.
Le référencement des prestataires dans ce répertoire passe par l’examen de :
L’éligibilité du prestataire:
 Un dirigeant de formation supérieure d’au moins bac +4 ;
 En situation régulière vis-à-vis de l'administration des Impôts, de la CNSS et du
Registre de Commerce.
 Domaine(s) d’intervention du consultant
 Disposant d’une attestation référence délivrée par une entreprise bénéficiaire et au nom
du consultant dans des missions faisant partie de l’offre Moussanada de l’ANPME
Dans ce cadre, la procédure de référencement débute par une demande de référencement du
prestataire ou du consultant qui pourra se faire via le site de l’ANPME, ou tout autre moyen de
contact. Toute cette procédure est accompagnée d’interaction ANPME/demandeur, par le biais
soit du chef de projet.
Dans la mesure où le prestataire n’est pas référencé, le chef de projet envoie une demande de
constitution de dossier technique et administratif.
Dès réception de ce dit dossier, le chef de projet est en charge de l’évaluation technique du
dossier de référencement en effectuant les points suivants :
 Examiner la présentation générale du prestataire et ses moyens techniques
 Étudier le(s) cv(s)/fiches projets de(s) consultant(s), en vue de confirmer l’adéquation
de leurs compétences et expériences par rapport aux profils exigés
 Vérifier la conformité des attestations de références
 Soumettre pour l’évaluation de la conformité du dossier administratif chef de projet
promotion de la consultance locale
Cette évaluation technique est suivie d’une évaluation administrative assignée au chef de
projet. A l’issue de cette évaluation, les responsables pourront préparer le PV de référencement
ainsi que la lettre de référencement pour l’étape finale qui est le référencement du consultant ou
du prestataire dans le cas d’approbation de référencement.
Dans le cas de non validation du dossier administratif et technique, une lettre de regret sera
préparée et soumise au chef de division. La dernière étape concernent le chef de division ou le

43
chef de pôle qui à la réception du PV de référencement devra le signer et soumettre la lettre de
référencement ou regret à la direction générale.
La figure 13 présente le diagramme de collaboration qui décrit le workflow du traitement du
référencement.
Ce diagramme permet de représenter les échanges et les interactions entre le chef de projet qui
se charge du traitement de la demande et le prestataire qui initie la procédure par la soumission
de la demande d’inscription dans le répertoire des compétences.
Figure 13 : Diagramme de collaboration du BPMN pour le processus Référencement

44
3.2.4.3 Diagramme des cas d’utilisation « Référencement »
Ce diagramme modélise les interactions entre les différents acteurs tel que : Le directeur
général, le responsable du répertoire des compétences ainsi que le prestataire.
Les cas d’utilisation associés à ce module sont :
 Traiter la demande de référencement ;
 Inscrire le prestataire dans le répertoire des compétences ;
 Suivre l’évolution de la demande ;
 Mettre à jour les documents administratifs.
Figure 14 : Diagramme des cas d’utilisation « Référencement »

45
Description du scénario «Traiter la demande de référencement»
Titre Traiter la demande de référencement
Résumé
permet à un responsable du répertoire des
compétences faisant partie d’un comité de
sélection de vérifier la validité de la demande de
référencement du client.
Acteurs Responsable RC
Pré-condition Acteur authentifié
Scénario nominal
1. Le Responsable RC demande de visualiser
les demandes de référencement ;
2. Le système affiche la liste des demandes
reçues ;
3. Le responsable choisit une demande pour la
traiter ;
4. Le responsable vérifie la validité de la
demande ;
Enchaînements
alternatifs
A1 : Le responsable détecte un problème au
niveau de la demande.
scénario nominal
4.1. Le responsable envoie une notification au
prestataire pour qu’il règle sa demande.
Post-condition
1. La décision est prise concernant la demande du
client (acceptée ou non)
2. Inscription du prestataire au répertoire des
compétences.
Tableau 6: Traiter la demande de référencement

46
3.3 Etude conceptuelle
3.3.1 Diagramme de séquence
Les diagrammes de séquences permettent de représenter les interactions entre les acteurs
et le système selon un ordre chronologique. La modélisation de ces interactions consiste en
l’identification des scénarios possibles des différents cas d’utilisation.
3.3.1.1 Diagramme de séquence du module « candidature »
Nous allons traiter l’exemple du cas d’utilisation « Traitement d’une demande de
candidature » (Fig. 15)

47

48

49
Figure 15 : Diagramme de séquence « Traiter une candidature »

50
Le système permet à une entreprise au préalable de créer une candidature.
Dés qu’elle clique sur le bouton créer, le formulaire apparaît. Un ensemble d’informations
concernant la demande doivent être saisies et des documents doivent être joignés.
Le formualaire est en suite enregistré et reste à l’état brouillon. Le chef de suivi et planification
procéde au traitement de l’éligibilité des demandes.
La demande passe de l’état Brouillon vers CA validé si le chiffre d’affaire est valide.
Elle passe de l’état Rating valide si la valeur du rating reçu de la banque partenaire et saisi par
le chef de service pôle et animation est valide.
Elle passe par la suite à l’état présélectionné en cas de vérification que les docuements joints
sont valides
Et finalement la candidature est validée par le chef de division, affecté par le chef de suivi
et planification, et qui affecte lui-même un chef de projet au dossier courant.
Ce dernier reçoit un PV et commence la procédure de la contractualisation avec la PME
bénéficiaire et la candidiature est enregistrée dans la base des données avec un état Eligible.
3.3.1.2 Diagramme de séquence du module « contractualisation »
Nous avons traité aussi le scénario du cas d’utilisation lié à la contractualisation. (Fig. 16)

51
DiagrammeSequence_Contractualisation
Validation de la convention de partenariat
Préparation de la convention de
partenariat
Préparation du pv de selection
Validation/signature du dossier
contractuel
Notification (signature)
Approuver le dossier de
contractualisation
Vérification du respect des plafonds
lancer procédure de référencement
Vérifier référencement du Bureau d'étude
et condultant
Demande de correction des docs(BE/
prestatire)
Vérification de la conformité aux canevas
ANPME
Demande d'envoi des docs (BE/prestatire)
Vérification de la réception des docs
requis
Chef projet
Système
chef divisionChef SSP
Non reçu
reçu
alt
non conforme
conforme
alt
non référencé
référencé
alt
[respectés]opt
[convention partenariat préparée]opt
Validation de la convention de partenariat
Préparation de la convention de
partenariat
Préparation du pv de selection
Validation/signature du dossier
contractuel
Notification (signature)
Approuver le dossier de
contractualisation
Vérification du respect des plafonds
lancer procédure de référencement
Vérifier référencement du Bureau d'étude
et condultant
Demande de correction des docs(BE/
prestatire)
Vérification de la conformité aux canevas
ANPME
Demande d'envoi des docs (BE/prestatire)
Vérification de la réception des docs
requis
Figure 16 : Traiter une contractualisation
Ce processus fait intervenir le chef de projet qui vérifie le référencement du prestataire dans le
répertoire des compétences de l’ANPME et valide les documents contractuels. Ensuite le chef de
suivi et planification prépare le PV de sélection et la convention de partenariat qui sera validée et
signée par le chef de division.

52
3.3.2 Diagramme de packages
Figure 17 : Diagramme de packages
Notre application est structuré en cinq packages :
o Entreprise ;
o Référencement ;
o Candidature ;
o Contractualisation ;
o Zone.
Le package Entreprise contient les classes relatives à l’entreprise et ses secteurs d’activité,
constituant les interfaces homme/machine.
Le package Candidature regroupe l’ensemble des classes relatives à la procédure
d’inscription. Il fait appel aux classes du package Entreprise pour pouvoir effectuer les
différents traitements.
Le package Contractualisation encapsule des classes qui offrent différents informations sur
le processus de la Contractualisation. Il fait appel aux classes du package Candidature.
Le package Référencement regroupe l’ensemble des classes faisant partie du traitement du
référencement dans le Répertoire des Compétences, ces données seront importés par le package
Contractualisation pour pouvoir vérifier le référencement du prestataire chargé de la mission.

53
Le package Zone regroupe l’ensemble des classes qui décrit sa structure à savoir la ville, la
région, la DPCI ainsi que le Rimaniste.
3.3.3 Diagramme des classes
3.3.3.1 Découpage modulaire
Aux vus des besoins recensés dans le cahier des charges, il a été décidé d’inclure le
programme Moussanada dans un seul module qui définira les différentes transactions à
implémenter que nous appelons ANPME.
3.3.3.2 Dépendances modulaires
Pour mettre en place notre module, nous aurons besoins d’utiliser des modules qui sont
déjà définis dan OpenERP à savoir celui des ressources humaines, la comptabilité et le module
de la gestion des documents.

54
3.3.3.3 Vision globale du diagramme des classes
Figure 18 : Vue globale du Diagramme des classes

55
Pour décrire l’ensemble des entités du projet, nous avons créé un dictionnaire des
données (Annexe A) où nous avons précisé les différents types d’attributs ainsi que les
liaisons entre les tables.
Nous avons rédigé aussi l’ensemble des règles de gestion qui nous ont aidées à
concevoir notre modèle. (Annexe C).
3.3.3.4Description du diagramme des classes en packages
-Diagramme des classes du package I : Entreprise
Figure 19 : Package 1 « Entreprise »
Le diagramme suivant contient l’ensemble des « classes Entreprise » qui peuvent être
décrites comme suit :
● Grand secteur : Cette entité représente en termes de localisation
une segmentation de secteur sous forme d’agglomération. C’est l’entête d’une hiérarchie de
localisation.
● Secteur : Le secteur est un niveau de sous hiérarchie du
grand secteur.
● Sous-secteur : Le sous-secteur est le niveau le plus bas de la localisation
concernant les contacts avec l’ANPME.

56
● Activité : C’est le secteur d’activité liée au client de l’ANPME
L’entreprise ne peut avoir qu’une activité principale mais plusieurs domaines d’activités.
● Chiffre : Cette entité représente les informations sur le chiffre
d’affaire par année dans la fiche du candidat.
● Bank : La banque est l’entité communicante avec l’ANPME dans le but
de fournir les ratings de ses clients pour le bon déroulement de la procédure d’éligibilité.
● Entreprise: C’est l’entité qui a un contact professionnel avec l’ANPME, elle
peut constituer un bénéficiaire, un prestataire ou autre.
La classe Entreprise a deux liaisons avec la classe Ville :
 Liaison 1 : many2one comme ville de siège
 Liaison 2 : many2many come ville de production
La classe Secteur a une liaison many2many avec la classe Solution

57
-Diagramme des classes du package II : Référencement
Figure 20 : Diagramme des classes du package II

58
Le diagramme suivant contient l’ensemble des « classes Référencement » qui peuvent
être décrites comme suit :
 Formation pour l’intervenant :
Ce modèle représente l’historique des formations de consultants/experts chez le prestataire
 Expérience de conseil pour l’intervenant :
Ce modèle représente l’historique des expériences en conseil de consultants/experts chez le
prestataire.
 Expérience professionnelle de l’intervenant :
Ce modèle représente la liste des expériences professionnelles du consultant ou expert.
 Demande de référencement du prestataire :
Ce modèle représente la demande de référencement des prestataires pour l’inscription au
répertoire de compétences.
 Compétence linguistiques :
Ce modèle représente l’inventaire des langues de consultants/experts chez le prestataire.
 Intervenant :
La personne chargée de l’accompagnement d’une entreprise dans la réalisation de ses actions
 Prestataire :
Ce modèle représente soit une entreprise ou un cabinet de conseil, il regroupe un ensemble
d’intervenants.
 Référence :
Ce modèle représente les références de travail déposées lors de demande de référencement
pour le répertoire de compétences.
 Domaine d’intervention :
C’est le modèle représentant les domaines touchés par les partenaires.
 Action :
C’est une granularité du domaine d’intervention
Exemple 1 :
Domaine d’intervention : Informatique
Action : La mise en place d’un système d’information

59
Exemple 2 :
Domaine d’intervention : Qualité et audit
Action : Certification ISO
-Diagramme des classes du package III : Zone
Figure 21 : Diagramme des classes du package III
Le diagramme suivant contient l’ensemble des « classes Zone » qui peuvent être
● Ville : Ce modèle représente les villes.
● Région : Ce modèle représente les régions.
● DPCI : C’est le modèle représentant les DPCI.
● Rimaniste : C’est le modèle représentant le Rimaniste, une
personne chargée de rapprocher le principe d’accompagnement offert par l’ANPME aux
clients et il peut éventuellement jouer le rôle d’un intermédiaire entre l’ANPME et les
clients.

60
-Diagramme des classes du package IV : Candidature
Figure 22 : Diagramme des classes du package IV
Le diagramme suivant contient l’ensemble des « classes Candidature » qui peuvent être
● Instrument : C’est le programme dont peut bénéficier les candidats à
l’ANPME citant par exemple : Moussanada et Injaz.
● Candidature : La candidature est la demande formulée par l’entreprise dans le
but de procéder à l’éligibilité des programmes de l’ANPME.
D’après la figure 24, nous pouvons constater qu’une candidature ne concerne qu’un
seul instrument.

61
-Diagramme des classes du package V : Contractualisation
Figure 23 : Diagramme des classes du package V
Le diagramme suivant contient l’ensemble des « classes Contractualisation » qui
peuvent être décrites comme suit :
 Contractualisation : C’est le dossier de contractualisation élaboré à la
suite d’une procédure d’éligibilité validée. Cette entité contient une liste de détail faisant
référence aux contrats et aux actions demandées.
Parmi les liaisons établies avec la contractualisation sont les suivantes :
 Liaison 1 de type many2one avec la classe Candidature
 Liaison 2 de type many2one avec la classe Prestataire
 Liaison 3 de type many2many avec la classe Action
Nous constatons qu’un contrat ne concerne qu’une candidature dont l’état est éligible.

62
3.3.4 Diagramme d’état-transition « Dossier de contractualisation »
Figure 24 : Diagramme d’état-transition «Dossier de contractualisation»
Ce diagramme représente le changement d’état du dossier de contractualisation soumi
par le client bénéficiaire et nous peuvons le décrire comme suit :
 Dossier reçu ;
 Dossier en cours de validation : Cela dû à la vérification du dossier et la vérification
des documents administratifs joints ;
 Dossier valide : Cela dû au respect et à la cohérence du dossier aux canevas ANPME.
Conclusion
Dans cette partie, nous avons montré la passage de l’étude préalable des besoins à la
conception détaillée du système en passant par une analyse approfondie. Ce qui nous permet
de comprendre le système aussi bien dans sa globalité que dans les détails liés aux différents
objets qui le constituent. A ce stade, tous les détails qui permettent de passer à la réalisation
sont connus. La partie suivante constitue une synthèse de cette phase de mise en œuvre à
travers laquelle nous avons développé le processus de la candidature et la gestion de la
contractualisation ainsi que le répertoire des compétences de l’instrument Moussanada.

63
Partie 3
Réalisation et mise en œuvre de
l’application
L’objectif de cette partie est de présenter les principales fonctionnalités
implémentées ainsi que les différentes technologies utilisées durant la réalisation.

Chapitre 4 Réalisation et mise en œuvre de l’application
64
4.1 Contexte fonctionnel du projet
4.1.1 ERP
«Enterprise Resource Planning», signifiant littéralement en français, « planification des
ressources de l'entreprise. C’est un progiciel qui intègre les principales composantes
fonctionnelles de l'entreprise entre autres la gestion de production, la gestion commerciale, la
logistique, les ressources humaines, la comptabilité, le contrôle de gestion.
Les ERPs 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.
À l'aide de ce système unifié, les utilisateurs de différents métiers travaillent dans un
environnement applicatif identique qui repose sur une base de données unique. Ce modèle
permet d'assurer l’intégrité des données, la non-redondance de l'information, ainsi que la
réduction du temps de traitement.
Figure 25 : Architecture technique d’un ERP [6]
4.1.2 Architecture modulaire
Un ERP est un ensemble dont toutes les parties fonctionnent les unes avec les autres
d'où l'ergonomie et l'unicité des informations et donc la cohérence du SI.
Un ERP est modulaire dans le sens où il est possible de n'avoir qu'une ou plusieurs
applications en même temps, ou peu à peu. Les applications modulaires telles que les ERP
permettent d'être sûr de la compatibilité des modules entre eux, ils s'imbriquent comme des
blocs de Lego et fonctionnent ensemble.
Voici un exemple d'architecture modulaire (Fig. 26) qui tend à représenter tous les ERP:

65
Figure 26 : Architecture modulaire d’un ERP [6]
L'architecture modulaire schématisée ci-dessus intègre plusieurs modules retouchant
aux grandes fonctions d'une entreprise à savoir le module finance, la logistique et CRM.
4.1.3 OpenERP [6]
OpenERP est un progiciel de gestion intégré distribué sous licence libre comprenant les
ventes, la gestion de relation client (CRM), la gestion de projet, la gestion d'entrepôt, la
production, la comptabilité et les ressources humaines. OpenERP a trois composants séparés :
le serveur OpenERP-server qui stocke ses données dans une base PostgreSQL, le client
OpenERP -client qui s'installe sur le poste de l'utilisateur et le serveur web OpenERP -web
qui permet une utilisation depuis un navigateur. Ces trois composants communiquent par les
protocoles XML-RPC et NET-RPC.
Le logiciel est basé sur une forte architecture MVC, des flux de travail flexibles, une
interface-utilisateur graphique dynamique, une interface XML-RPC, et un système
personnalisable de comptes rendus avec une intégration pratique d'OpenOffice.org.
a. Modules fonctionnels
Les modules fonctionnels sont :
 Gestion de la relation client et fournisseur (CRM & SRM)
 Gestion des ventes et des achats
 Comptabilité analytique et financière
 Gestion de projets et des activités de services
 Ressources Humaines
 Gestion documentaire

66
b. Architecture
Un système OpenERP est basé sur une architecture MVC:
 Un serveur de base de données PostgreSQL
 Un serveur d'applications contenant les objets de gestion, le moteur de workflow, et le
générateur d'édition
 Un serveur de présentation, appelé OpenERP Web, qui permet à l'utilisateur de se
connecter à OpenERP avec n'importe quel navigateur internet. Ce serveur n'est pas
nécessaire si l'utilisateur utilise le client lourd mais qui nécessitera une installation
physique sur le poste de l'utilisateur.
4.1.4 Architecture d’un module d’OpenERP
Le développement d’un module OpenERP suppose la création d’un dossier dans le
répertoire d’installation du serveur server/bin/addons. Ce dossier est constitué des fichiers
d’initialisation, des fichiers Python et des fichiers de création des vues en XML.
Figure 27 : Architecture d'un module d'OpenERP [6]
Pour fonctionner, le répertoire du module OpenERP doit contenir les dossiers et les
fichiers suivants :
 Le fichier __openerp__.py : Il contient un dictionnaire unique Python avec la
déclaration du module, son nom ainsi que les dépendances.
 Le dossier Object : Il contient les déclarations des classes et le fichier
__init__.py
 Le dossier Views : Le dossier qui contient les différentes vues créées pour
chaque classe développée.

67
 Le dossier Security : Le dossier qui contient les fichiers de contrôle d’accès et les
règles pour les enregistrements.
 Le dossier Workflow : Le dossier qui contient les fichiers relatifs à la description des
différents processus réalisés dans le module.
 Le dossier Wizard : Le dossier qui contient des fichiers des assistants de
configuration.
 Le dossier Images : Le dossier qui contient les images de description du module et
les icônes du menu.
4.1.5 Etapes d’intégration d’un module dans OpenERP
Une fois le module développé avec tous les dossiers indispensables présentés
auparavant, nous passons à l’étape d’intégration dans OpenERP et nous suivons les étapes
suivantes :
1. Déplacer le répertoire dans le dossier addons d’openERP ;
2. Lancer le serveur openerp-server
3. Accéder à la page d’accueil d’OpenERP et créer la base des données ;
4. Mettre à jour les modules du progiciel pour faire apparaître le module spécifique ;
5. Installer le module.
4.2 Outils de réalisation
Sphinx [17]
Sphinx est un logiciel libre de type générateur de documentation. Il s'appuie sur des
fichiers au format reStructuredText, qu'il convertit en HTML, PDF et autres formats.
Il a été utilisé pour générer la documentation technique de notre projet sous forme des pages
html qui décrivent chaque classe développée. Pour plus d’informations, veuillez voir
l’annexe B.
Python [7]
Python est un langage de programmation objet, multi-paradigme et multi-plateformes. Il
favorise la programmation impérative structurée et orientée objet. Il est doté d'un typage
dynamique fort, d'une gestion automatique de la mémoire par ramasse-miettes et d'un système
de gestion d'exceptions.

68
Son utilisation dans notre projet avait pour objectif le développement des différentes classes
métiers.
OpenOffice [17]
OpenOffice.org est un projet né en vue de produire un intégré bureautique libre fondé
sur StarOffice, il fonctionne sur plusieurs plates-formes dont Windows. Son utilisation va
nous aider dans la phase de reporting, comme par exemple la génération du PV d’éligibilité.
Pour plus d’informations, veuillez voir la partie du reporting.
Navicat for PostgreSQL [16]
Navicat for PostgreSQL est un outil graphique pour l'administration de base de données
PostgreSQL, il est excellent et facile à utiliser. A travers lequel on peut créer et exécuter des
requêtes, des fonctions avec le puissant éditeur de SQL, et vous pouvez gérer vos données
avec nos polyvalents outils d'édition de données.
Navicat nous a permis de migrer de la base des données Access qui existait déjà dans l’ancien
système vers PostgreSQL, cette migration a été faite manuellement. Pour avoir plus
d’informations, veuillez voir la partie de la migration.
Eclipse [17]
Eclipse est un projet, décliné et organisé en un ensemble de sous-projets de
développements logiciels, de la Fondation Eclipse visant à développer un environnement de
production de logiciels libres qui soit extensible, universel et polyvalent, en s'appuyant
principalement sur Java.
PostgreSQL[13]
PostgreSQL est un système de gestion de base de données relationnelle et objet
(SGBDRO). C'est un outil libre disponible selon les termes d'une licence de type BSD.

69
Mozilla Thunderbird [15]
Mozilla Thunderbird est un programme de messagerie électronique Open-Source très
élaboré. Il est léger, extrêmement rapide, simple à utiliser et offre de nombreux avantages face
aux programmes concurrents.
Il a été choisi comme serveur de messagerie pour notre projet afin de gérer la partie mailing,
c’est-à-dire pourvoir envoyer des mails et des notifications via notre module à tout instant.
Modelio [12]
Modelio est un outil de modélisation UML disponible sur les plates-formes Windows,
Linux et Mac. Il intègre également la modélisation BPMN, et le support de la modélisation
des exigences, du dictionnaire, des règles métier et des objectifs. Modelio nous a permis à
travers sa riche gamme d'outils de représenter le diagramme de collaboration des différents
workflows traités tout au long de notre projet.
Git [11]
Un logiciel de gestion de versions (VCS en anglais) permet de stocker les différentes
versions d'un ensemble de fichiers afin de faciliter l'évolutivité d'une production informatique.
Par la suite nous utiliserons l'abréviation VCS pour désigner les logiciels de gestions de
versions. Certains termes sont spécifiques au monde des VCS ou à GIT et il est important de
bien les comprendre pour pouvoir travailler efficacement
Le système de gestion de versions se décline en trois types :
 Local : le dépôt se situe uniquement sur la machine de l'utilisateur
 Centralisé : les informations se situent sur un serveur central. L'information y est
principalement située et le ou les utilisateurs doivent s'y connecter pour travailler
 Distribué : les informations sont stockées sur un ensemble de machines de manière
distribuée. On peut reconstituer le contenu du projet à partir de n'importe quelle
machine, il n'y a pas un point de faiblesse comme dans le cas de l'architecture
centralisée.

70
PowerAMC [17]
PowerAMC est un logiciel de conception qui permet de modéliser les traitements
informatiques et leurs bases de données associées.
IReport [17]
Il s'agit d'un programme spécialement conçu pour la rédaction de compte-rendu visuel
pour JasperReports sur Linux. Il est entièrement écrit en Java.
Il a été utilisé pour pouvoir présenter le graphe des données saisies et permettre la prise de
décision par les chefs de services.
Xml [17]
Xml est l’acronyme de « eXtensible Markup language », c’est un langage simple et
puissant, il a été utilisé dans notre projet pour le développement des vues et des différents
formulaires.
4.3 Présentation de l’application
Dans cette partie, nous présentons ce qui a été réalisé, tout en décrivant quelques
interfaces du système Moussanada.
Le module « Candidature » a été entièrement achevé, les deux modules de contractualisation
et de référencement sont en cours de correction et de validation. Donc nous nous limitons
dans ce qui suit à la présentation de quelques interfaces du module candidature.
4.3.1 Traitement d’une candidature
Comme nous avons déjà vu, le workflow candidature passe par plusieurs phases, et
plusieurs acteurs interviennent lors du traitement.
L’acteur qui initie la procédure est le client qui accède à son espace nommé portail et saisi lui-
même ses informations. Au cas où la demande de candidature est envoyée par poste le
responsable du service Suivi et Planification se charge de saisir les différentes informations du
client.

71
4.3.1.1 Page d’authentification
Tout d’abord le chef de service Suivi et Planification s’authentifie pour accéder à son
espace.
Figure 28 : Page d’Authentification du Responsable de service Suivi et Planification
Si le login et le mot de passe sont corrects, le chef sera dirigé vers son espace, sinon il
sera censé ressaisir des informations valides pour garantir la sécurité et l’accès limité de
chaque acteur.
4.3.1.2 Présentation du menu principal
Figure 29 : Menu principal du Responsable de service Suivi et Planification
Comme il paraît clair sur la figure, le menu principal est constitué de plusieurs onglets :
 Messagerie : Elle permet la communication interne et externe entre
tous les acteurs.
 Programme d’appui : Il Présente le menu de Candidature, Instrument et
d’Entreprise.
 Répertoire de compétences : Il offre le menu Référencement, Moussanada IT et
Domaine d’intervention.
 Comptabilité : Pour gérer tout ce qui est financier.
 Ressources humaines : Pour gérer le personnel de l’agence.

72
Pour le chef de service Suivi et Planification, il a la possibilité de gérer la candidature, c’est-à-
dire une possibilité de la créer, la modifier ou même la supprimer.
Il lui a aussi été attribué tous les droits de gestion sur l’instrument et aussi sur l’entreprise.
Pour la partie de Répertoire de compétences, l’accès est limité, il ne peut pas créer les
demandes de référencement mais il peut les consulter, avec une possibilité de créer les
domaines d’interventions ainsi que les actions associées.
4.3.1.3 Création de l’entreprise candidate
Lors de la saisie des informations concernant la candidature, le responsable doit tout
d’abord saisir les informations de l’entreprise candidate si elle n’existe pas.
Parmi ces informations, nous citons :
 Raison sociale
 Adresse et site web
 Le registre Commercial et la CNSS
 Date de création de l’entreprise et la date de son démarrage
Figure 30 : Formulaire d’ajout d’une entreprise
Et aussi il y’a des informations essentielles qui doivent être saisies et qui présentent un
critère parmi les critères d’éligibilité de l’entreprise, c’est le chiffre d’affaire des trois
dernières années.
Nous pouvons éventuellement ajouter des informations concernant les activités de l’entreprise
et ses contacts.

73
Figure 31 : Formulaire d’ajout des chiffres d’affaire d’une entreprise
Après la création de l’entreprise candidate, le responsable saisit les informations concernant la
demande :
 Date de la demande
 Plan
 Le domaine d’intervention
 L’action demandée
 Le signataire de la demande
 Les documents administratifs joints
Figure 32 : Formulaire d’ajout d’une candidature
Le responsable ajoute le domaine d’intervention.

74
Figure 33 : Formulaire d’ajout d’un domaine d’intervention
Le responsable ajoute finalement les documents administratifs joints du dossier.
Figure 34 : Formulaire d’ajout des documents administratifs
4.3.1.3 Vérification du chiffre d’affaire
Le processus du traitement de la candidature débute par la vérification du chiffre d’affaires
qui respecte la règle suivante :
La moyenne du chiffre d’affaire des trois dernières années doit être inférieure à
150000000 dh

75
Figure 35 : Etat initiale de la candidature « Brouillon »
Si la règle est valide, la candidature passe de l’état Brouillon vers l’état CA validé.
Figure 36 : Passage de l’état Brouillon vers CA validé
4.3.1.4 Vérification du rating
A ce niveau, l’acteur qui prendra la charge de demander l’envoi du rating et tester sa validité
est le responsable de Pôle Appui et Animation.
Figure 37 : Saisie du rating par le chef Pôle Appui et Animation
Ce dernier saisit la valeur du rating reçu de la banque concernant l’entreprise candidate
et spécifie que le rating est valide ou non
Après cette intervention du chef de service de Pôle Appui et Animation, la main est revenue
au chef de suivi et planification pour continuer le traitement de la demande.
Après avoir validé le rating, la candidature passe de l’état CA validé vers l’état Rating
validé.

76
Figure 38 : Passage de l’état CV validé vers Rating validé
4.3.1.5 Vérification des documents administratifs
Et après, il passe à la vérification des documents administratifs et leur validité.
S’ils sont valides et légaux, la candidature passe de l’état Rating validé vers l’état
présélectionnée.
Figure 39: Passage de l’état Rating validé vers l’état présélectionné
4.3.1.6 Validation de la candidature
Jusqu’à ici le responsable doit envoyer un PV au chef de division choisi pour lui
préciser qu’un nouveau dossier de candidature lui a été attribué, et ce dernier sera chargé de
mentionner si la demande est éligible ou non et d’affecter ce dossier à un chef de projet qui
aura comme mission la vérification des informations saisies et l’établissement de la procédure
de la contractualisation.

77
Figure 40 : Passage de l’état présélectionnée vers l’état Eligible
Lorsque le chef de division valide la candidature, son état passe de Présélectionné vers
Eligible.
Une candidature éligible implique un dossier de contractualisation doit être élaboré entre
l’ANPME, l’entreprise bénéficiaire et le Prestataire, cette tâche est attribué à un chargé de
projet choisi par le chef de division.
Le chargé de projet aura la possibilité de gérer toutes les contractualisations (créer, modifier et
supprimer) mais pour les autres informations, il ne peut que les consulter.
Une fois la contractualisation est saisie, le prestataire peut commencer la mission sous le suivi
du chef de projet qui notifie le chef de division sur toutes les actions menées.
4.3.1 Génération du PV d’éligibilité
Suite à la validation d’une demande de candidature, le système doit générer
automatiquement un rapport appelé PV d’éligibilité qui doit résumer les informations sur
l’entreprise bénéficiaire. Nous l’avons réalisé en intégrant l’outil OpenOffice dans OpenERP
en se basant sur le modèle papier du PV utilisé à l’ANPME.
Nous présentons dans le chapitre 6, un aperçu sur les étapes de génération du rapport.
La figure présentée ci-après présente le PV réalisé généré sous format PDF.

78
Figure 41 : Génération du PV d'éligibilité
Conclusion
Dans cette partie, nous avons présenté les éléments de réalisation du système
Moussanada à travers une brève présentation des outils utilisés ainsi que quelques interfaces.
Dans ce qui suit, nous allons présenter les tâches réalisées dans les cadre du Sprint 4, tel que
la migration des données et la l’intégration du mailing dans OpenERP.

Chapitre 5 Migration des données
79
Après avoir presque achevé et testé le module réalisé, nous allons passer à la phase de la
migration pour pouvoir récupérer les données existantes dans l’ancienne application.
Le but de cette tâche est d’importer les données de la base des données Access vers
PostgreSQL. Nous avons commencé par l’étude de chaque modèle de données avant de
proposer toutes les solutions possibles et finir par choisir celle qui est la mieux adaptée pour
notre cas.
5.1 Etude préalable des deux bases de données
Suite à l’analyse des tables de l’ancienne base des données, nous nous sommes
retrouvés devant des problèmes de normalisation.
Le nouveau schéma réalisé a plusieurs avantages dont nous citons :
 Limiter les redondances des données
 Limiter les incohérences des données qui pourraient les rendre inutilisables.
Pour confirmer cette évolution il s’avère nécessaire de présenter un exemple pour préciser ce
que nous avons ajouté comme valeur :
 Pour le domaine zone qui inclut les tables de ville, région et DPCI, dans Access nous
avions une seule table globale qui regroupe toutes ces données.
Figure 42 : Table zone sous access
Ici nous constatons qu’il y a plusieurs répétitions. Alors pour insérer une ville il fallait
inscrire aussi les autres données comme la région et la DPCI et même la suppression d’une
ville peut engendrer la suppression d’une région. Et pour éviter tout cela, nous devons diviser
cette table en trois petites tables (Ville, région, DPCI) en respectant les jointures en ajoutant
les clés primaires et les clés étrangères.

80
Et voilà la nouvelle conception de ce domaine :
Figure 43 : Conception du domaine zone
5.2 Migration
Les solutions qui ont été proposées sont les suivantes :
 Solution 1 : Script d’importation
Cette solution consiste à élaborer un script qui a comme tâche de gérer l’ancienne
conception et de l’adapter pour la nouvelle conception. Mais cette solution semblait difficile à
réaliser parce que les données, qui nous ont été procurées, étaient plutôt un regroupement de
plusieurs tables qu’il fallait séparer, ajouter des ID pour chaque table et respecter les clés
étrangères.
 Solution 2 : importation manuelle
Cette solution se compose de plusieurs étapes et repose sur plusieurs logiciels, celui le
plus utilisé est Navicat For PostgreSQL.
Le choix était d’utiliser l’importation manuelle, la chose qui a demandé beaucoup d’effort et
surtout de temps. L’idée était d’importer les fichiers Excel de l’ancienne base de données et
essayer, avec des requêtes SQL, de séparer les tables, ajouter les colonnes où on va mettre les
clés primaire, respecter les correspondances entre les différentes tables. Et pour mieux
comprendre cette partie, un exemple d’importation des données est détaillé au niveau de
l’annexe D.

Chapitre 6 Reporting
81
Parmi les tâches que nous avons planifiées durant le projet est la génération des rapports
et pour avoir la possibilité d’imprimer dans OpenERP nous devons avant tout, installer
l’OpenOffice sur l’ordinateur, puis installer le module « OpenOffice Report Designer »,
existant dans OpenERP, et l’emporter vers OpenOffice.
Et voici ci-dessous les étapes nécessaires pour la réalisation d’un rapport à imprimer et pour
notre cas, nous avons pris comme exemple la génération du PV d’éligibilité de l’entreprise qui
contient des informations relatives à l’entreprise candidate et l’état de sa demande signé par le
chargé de projet.
Intégration du plugin dans OpenOffice
Figure 44 : Intégration du plugin
 Connexion avec le serveur
Figure 45 : La connexion avec le serveur

82
Choix de la base de données avec login et le mot de passe
Figure 46 : Choix de la base des données
Ouverture d’un nouveau rapport et choix du module à traiter
Figure 47 : Ouverture d’un nouveau rapport
 Après, nous choisissons le module à traiter
Figure 48 : Choix du module à traiter
Envoi du rapport au serveur
Après la création du fichier imprimable, on envoie le fichier à la classe voulu, on
cliquant sur « Send To Server » et une fenêtre s’ouvre, comme suivant :

83
Figure 49 : L’envoi du rapport au serveur
Enfin, nous mettons à jour le module, et un bouton « Imprimer » apparaît dans la vue
« liste » de la classe choisie.

Chapitre 7 Intégration du mailing
84
Tout d’abord nous avons commencé par l’installation du serveur de messagerie :
Mozilla Thunderbird
Après, nous avons configuré le serveur de messagerie sortant.
 Pour les serveurs Mail Sortant:
→ Paramètres / Serveurs technique / Email / Sortie de messagerie
Figure 50 : Configuration du serveur mail sortant
Pour Messagerie Sortante (SMTP):
 Description : Google Mail
 Nom du serveur : smtp.googlemail.com
 Port : 456
 Nom utilisateur : Adresse mail
 Méthode d'authentification : Normale
 Type de sécurité : SSL/TLS
Si nous avons réussi à configurer le serveur de messagerie sortant, nous pouvons alors utiliser
un des modèles personnalisés d’OpenERP « Template » pour envoyer du courrier.
 Pour les modèles:
Paramètres / technique / Email / Modèles

85
Figure 51 : Exemple d’un modèle réalisé « Lettre d’éligibilité »
Lors de la création d'un nouveau modèle, il y'a des champs à remplir et qui sont obligatoires :
Nom : Nom du modèle
S'applique à: Modèle à laquelle le modèle est lié [Ex: ordre de vente]
Forme : adresse de l'expéditeur
Pour : adresse e-mail de destination
Répondre à : adresse de réponse privilégiées
Sujet : Sujet du mail
Corps : corps de l'e-mail [texte brut ou au format HTML]
Ajouter signature : prédéfinir signature pour tous.
La Principale caractéristique d’email_templates est son onglet dynamique où nous pouvons
aller chercher le champ obligatoire à partir du modèle de document s'y rapportant et aussi
utiliser la valeur du champ dans [Forme, À, Objet, Corps].
Exemple : Classe du Module : Candidature
Champs : Chef de projet, Date de réception
Remarque :
Pour pouvoir envoyer des données via des mails (Exemple : les données concernant les
candidatures), nous devons ajouter dans la classe candidature la ligne :
_inherit = ['mail.thread', 'ir.needaction_mixin']
Et redémarrer le serveur.

Chapitre 8 L’aspect de sécurité
86
Chapitre 8 L’aspect de la sécurité
Dans notre projet, nous avons appliqué quelques règles de sécurité sur le module que
nous avons réalisé afin de sécuriser les transactions internes et externes, de restreindre l’accès
et de fixer une règle sur les enregistrements. Les règles sont les suivantes :
Le choix du système
Le système choisi était Ubuntu 12.04, vu qu’il offre un certain nombre d’avantages,
citant par exemple :
‣ Ubuntu fait clairement la distinction entre les utilisateurs normaux et les
administrateurs ;
‣ Les logiciels pour Ubuntu sont conservés dans un dépôt en ligne sécurisé qui ne
contient aucun logiciel trompeur ou malveillant ;
‣ Les logiciels open source comme Ubuntu permettent une détection rapide des failles
de sécurité ;
‣ Les correctifs de sécurité pour les logiciels open source comme Ubuntu sont publiés
fréquemment et rapidement ;
‣ Beaucoup de virus conçus pour atteindre principalement les systèmes basés sur
Windows n’affectent pas les systèmes Ubuntu.
Les droits d’accès
Avec OpenERP, vous créez et vous gérez les utilisateurs qui se connectent au système.
Vous pouvez leur assigner un groupe pour leur fournir des accès spécifiques aux applications
dont ils ont besoin. Les utilisateurs peuvent être désactivés un certain temps pendant lequel ils
ne pourront pas se connecter au système. Vous pouvez également définir les préférences de
chacun d'entre-deux. Trois concepts sont différenciés dans OpenERP;
 Les utilisateurs: personne identifiée par son login / mot de passe
 Les groupes : définir les droits des ressources d'accès
 Les rôles : déterminer les rôles / fonctions des utilisateurs
1. les utilisateurs
Ils représentent des personnes physiques. Elles sont identifiées par un login et un mot de
passe. Un utilisateur peut appartenir à plusieurs groupes et peut avoir plusieurs rôles.
Un utilisateur doit avoir une action mis en place. Cette action est exécutée lorsque l'utilisateur
se connecte au programme avec son login et son mot de passe.
Les préférences de l'utilisateur sont disponibles avec l'icône des préférences. Vous pouvez,
par exemple, par le biais de ces préférences, déterminer la langue de travail de l'utilisateur.

87
2. Les groupes
Un groupe définit un ensemble de zones fonctionnelles accessibles aux utilisateurs qui y
sont rattachés. Il permet de gérer les droits d'accès aux applications et tâches spécifiques dans
le système. Vous pouvez créer vos propres groupes ou utiliser ceux qui existent par défaut
dans le but de personnaliser la vue des menus que les utilisateurs pourront voir. Les droits de
lecture, d'écriture et de suppression peuvent être gérés ici.
 L'accès écriture: l'enregistrement et la création,
 L'accès lecture: la lecture d'un fichier,
 L'accès de l'exécution: les boutons de flux de travail ou des assistants.
3. Les rôles
Les rôles définissent une structure hiérarchique dans l'arbre. Ils représentent les
différents emplois / rôles à l'intérieur de l'entreprise. Le plus grand rôle a automatiquement les
droits de tous les rôles inférieurs.
Nous avons créé un fichier spécial dans le répertoire Security du module.
Le fichier qui définit les droits d'accès aux enregistrements dans la base de données est un
fichier.csv
Il porte toujours le même nom :
ir.model.access.csv
La première ligne contient le nom des champs séparés par une virgule
id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
 Id : Un identifiant unique pour la règle d’accès
 Name : Le nom de la règle. Il apparaîtra dans les pages de configuration d’OpenERP
 model_id :id : La table à laquelle s’applique cette règle. Le nom de la table doit être
toujours précédé par le préfixe model
 group_id :id : Le groupe d’utilisateurs auquel s’applique cette règle
 perm_read : La permission de lire les données (1 ou 0)
 perm_write : La permission de modifier les données (1 ou 0)
 perm_create : La permission de créer les données (1 ou 0)
 perm_unlink : La permission de supprimer les données (1 ou 0)

88
Exemple:
id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
appui_instrument_sp,ChefSSP,model_appui_instrument,group_appui_ssp_secretariat,1,0,0,0
appui_rating_sp,ChefSSP,model_appui_rating,group_appui_ssp_secretariat,1,1,0,0
Nous pouvons définir des règles sur les enregistrements afin de s'assurer par exemple qu'un
chef de projet ne visualise que ses propres candidatures.
L’historique des traces
L'historique des traces permet de suivre les modifications apportées par les utilisateurs
aux données de l’application, ainsi que l'exécution des différents traitements.
Utilisation du protocole SSL
Puisque l’application sera mise sur un serveur et les acteurs, appartenant au réseau, y
accéderont via un lien d’où la nécessité de ce protocole, sa mise en place va permettre la
sécurisation des transactions et des échanges sur Internet, entre les entités de l’agence, ainsi
qu’avec le client.
SSL fonctionne suivant un mode client-serveur. Il fournit les objectifs de sécurité suivants :
 l'authentification du serveur ;
 la confidentialité des données échangées ;
 l'intégrité des données échangées ;
 de manière optionnelle, l'authentification ou l'authentification forte du client avec
l'utilisation d'un certificat numérique ;
 la spontanéité, c'est-à-dire qu'un client peut se connecter de façon transparente à un
serveur auquel il se connecte pour la première fois ;
 la transparence, qui a contribué certainement à sa popularité.

Conclusion
89
Conclusion générale
Notre projet de fin d’études, effectué au sein de l’ANPME, avait pour objectif l’étude,
la conception et la réalisation d’une solution Open Source pour la gestion des dossiers d’appui
« Moussanada » en utilisant OpenERP.
Le stage effectué, nous a donné l’occasion de mettre en pratique nos connaissances
académiques dans un milieu professionnel. D’une part, Il nous a permis de développer
nos compétences techniques, d’approfondir nos connaissances théoriques et de pratiquer et
stimuler notre créativité. D’autre part, l’environnement de travail nous a permis d’améliorer
notre savoir-faire et notre rigueur, nous avons aussi développé le sens du travail du groupe et
de la bonne organisation au sein d’une équipe. Enfin, cette expérience a aiguisé nos
capacités d’analyse et de synthèse et a surtout fortifié notre motivation, notre détermination et
notre ambition.
Au terme de ce projet, l’ANPME dispose actuellement d’un système fonctionnel en ce
qui concerne la gestion de la candidature et des contractualisations et qui répond à toutes les
attentes du client. La démarche de la migration a été définie et testée sur les tables relatives à
la partie réalisée.
Comme perspectives, il sera bénéfique de mettre en place les deux workflows qui
restent celui de la contractualisation et le référencement, traiter aussi la partie de la gestion
des portails pour les utilisateurs, renforcer le côté de la sécurité en mettant en place un réseau
VPN pour sécuriser l’échange d’informations entre les entités externe tels que les institutions
bancaires et le personnel de l’agence. Cette stratégie sera beaucoup plus fiable que
l’authentification.

Bibliographie
90
Bibliographie et Webographie
Bibliographie
[1] : Manuel des procédures pour le programme Moussa nada, 2010
[2] : UML 2.0 Laurent AUDIBERT
[3] : Rapport d’analyse réalisé dans le cadre de GEDA, 2012
Webographie
[4] : anpme.ma
[5] : http://fr.wikipedia.org/wiki/Scrum_%28m%C3%A9thode%29
[6] : https://www.openerp.com/
[7] : http://fr.wikipedia.org/wiki/Python
[8] : http://www.aubryconseil.com/pages/Scrum
[9] : http://www.commentcamarche.net/contents/982-gantt-diagramme-de-gantt
[10] : http://fr.wikipedia.org/wiki/Xml
[11] : http://fr.wikipedia.org/wiki/Git
[12] : http://fr.wikipedia.org/wiki/Modelio
[13] : http://fr.wikipedia.org/wiki/PostgreSQL
[14] : http://fr.wikipedia.org/wiki/iReport
[15] : http://fr.wikipedia.org/wiki/Mozilla Thunderbird
[16] : http://fr.wikipedia.org/wiki/Navicat
[17] : http://fr.wikipedia.org/wiki/

Annexes
91
Annexes
Annexe A : Dictionnaire des données
Annexe B : Génération de la documentation avec SPHINX
Annexe C : Identification des règles de gestion
Annexe D : Exemple d’importation de la table activité

Annexe A Dictionnaire Des Données
92
Le dictionnaire des données que nous présentons dans cette partie, permettra de rendre
plus compréhensible les paquets du diagramme de classe présentées antérieurement.
Dans les tableaux du dictionnaire nous utilisons les notations ci-dessous :
 Désignation = Nom du champ
 Type =
o C : chaîne de caractère
o E : Entier
o R : Réel
o D : Date
o DH : Date/heure
o BN : Binaire
o S : Sélection
o REL : Relation
o FU : Calculé
o M2O : relation many2one
o M2M : relation many2many
o O2M : relation one2many
 Libellé = libellé du champ
 Type = Type de fichier
 Références

93
Nom de la Classe Désignation libellé Type Référence
Grand secteur name Nom C
code code C
secteur_ids secteurs O2M appui.secteur
description Description T
Etat Etat C
Secteur name Nom C
code Code C
grand_secteur_id Grand
secteurs
M20 appui.grand.secteur
sous_secteur_ids sous secteurs O2M appui.sous.secteur
Secteur name Nom C
code Code C
secteur_id Secteur M2O appui.secteur
activite_ids Activités O2M appui.activite
Activité name Nom C
sous_secteur_id Sous-secteur M2O appui.sous.secteur
Chiffres fiscalyear Année S
valeur Valeur R
entreprise_id Entreprise M2O entreprise
Partenaire forme_juridique Forme
juridique
S
fiscale Capital Capital C
activite_ids Activité M2M appui.activite
activite_principale_id Activiteprinc
ipale
M2O appui.activite
chifre_affaire_ids Chiffre O2M appui.chiffre
Cnssdate Cnssdate D

94
registre_commerce registre de
commerce
C
rue_production Rue C
date_creation Date de
création
D
date_demarrage Date de
démarrage
D
Rcdate Rcdate C
Cnss Cnss C
code_zip_production Code Zip C
cite_production Cité C
Patente Patente c
Organisme Organisme C
Banque email_rating Email rating C
Contractualisation PV PV BN
budget Budget F
Prestation_datedebut Prestation
date de début
D
Prestation_file Prestation
File
BN
Offre_date Offre Date D
Offre_file Offre File BN
Commentaire_visite Commentaire T
Date_visite Date de la
visite
D
Prestation_datefin Date de fin
de la
prestation
D
Convention_file Convention BN
Convention_date Date de la
convention
D
Candidature_id Candidature M2O Appui.candidature
Region_id Region M2O Appui.region

95
Tableau 7 : Dictionnaire des données
Prestataire_id Prestataire M2O Appui.prestataire
Action_ids Actions M2M Appui.action
Instrument name Instrment C
active Active B
code Code C
Budget Budget F
budget_secondaire_devise Budget
converti
R
pourcentage_instrument pourcentage
instrument
R
pourcentage_beneficiaire Pourcentage
bénéficiaire
R
pourcentage_banque Pourcentage
banque
R
Duree_max Duree max
du prog (J)
R appui.offre

Annexe B Documentation avec Sphinx
96
Parmi les tâches qui ont été planifié durant ce projet est la génération de la
documentation du projet et pour ce faire nous avons choisi comme outil « Sphinx ».
 Création du répertoire de documentation
Supposons que votre exemple d'application se trouve sur le chemin suivant :
APPDIR=$DEVDIR/myapps/example/src
1. Installer sphinx :
sudo apt-get install python-sphinx
2. Ajouter le répertoire de la documentation et les fichiers d'origine
La commande sphinx-quick Start vous pose quelques questions. La plupart des questions
peuvent être laissées à leur valeur par défaut, mais ici nous mettons en évidence certaines
pratiques celles à modifier. Le plus important est de préciser l’auto doc
 Edition du fichier conf.py
Le fichier de configuration ($ APPDIR / docs / conf.py) est très important pour sphinx,
il s'agit d'un fichier python qui sera exécutée avant toute génération de la documentation.
Le code à ajouter est celui qui obtient DEVDIR de l'environnement
sys.path.insert(0, devdir + '/myapps/example/src')
 Edition du fichier index.rst
Le fichier principal index.rst peut être modifié pour inclure vos modules de l'application
automatiquement.
 Génération de la documentation
o Génération .rst files :
Les fichiers rst. Sont automatiquement générés en utilisant la commande sphinx apidoc.
sphinx-apidoc -o $APPDIR/docs $APPDIR
o Génération de fichier html
Maintenant que vous avez tout en place, il suffit d'exécuter:

97
cd $APPDIR/docs
make html
Vous pouvez consulter votre documentation générée avec la commande suivante :
firefox $APPDIR/docs/_build/html/index.html
Figure 52 : Page d’accueil
La figure précédente 52 présente le modèle de notre projet et ses différentes classes
Chaque lien présente les caractéristiques de la classe concernée. (fig. 53)
Figure 53 : Liste des classes de notre projet

Annexe C Identification des règles de gestion
98
Parmi les règles de gestion recensées à partir de l’étude et l’analyse de l’existant, nous citons :
 Une région contient plusieurs villes
 Un Rimaniste peut déposer une ou plusieurs candidatures
 Un Rimaniste est affecté dans une seule délégation
 Une DPCI est composée de plusieurs villes
 A une seule délégation est affecté un ou plusieurs Rimanistes
 Une candidature ne concerne qu’un seul instrument
 Une candidature est liée à une seule ville et à une seule entreprise
 Une candidature peut comporter plusieurs actions, et une action est associée à
plusieurs candidatures
 Une candidature est liée à un ou plusieurs domaines d’intervention
 Un prestataire peut avoir plusieurs contrats
 Un contrat peut porter sur plusieurs actions
 Un contrat concerne une seule région
 Une candidature de demande d'appui est liée à un et un seul bénéficiaire
 Un bénéficiaire peut avoir plusieurs demandes d'appui
 Un Rimaniste peut être lié à plusieurs demandes d'appui
 Une demande d'appui peut être associée à un Rimaniste
 Une entreprise candidate a plusieurs chiffres d'affaires
 Un rating est saisi par une et une seule banque
 Un rating appartient à une et une seule entreprise candidate
 Une entreprise candidate a un et un seul rating par demande d’appui
 Une entreprise candidate a un et un seul rating par banque
 Une entreprise candidate peut avoir qu'un seul PV d'éligibilité par candidature
 Un PV d'éligibilité appartient à une et une seule entreprise candidate
 Une entreprise candidate peut avoir qu'un seul PV de présélection par candidature
 Un PV de présélection appartient à une et une seule entreprise candidate
 Une entreprise candidate peut avoir qu'un seul PV de sélection par candidature
 Un PV de sélection appartient à une et une seule entreprise candidate
 Un chef de projet est affecté à plusieurs actions
 Une action est associée à un et un seul chef de projet
 Un chef de division peut affecter plusieurs chefs de projet
 Un chef de projet est affecté par un et un seul chef de division

99
 Un bénéficiaire peut posséder plusieurs dossiers de contractualisation par dossier
d'appui
 Un dossier de contractualisation appartient à un et un seul bénéficiaire
 Un dossier de contractualisation peut appartenir à seul prestataire
 Un prestataire peut posséder plusieurs dossiers de contractualisations
 Une demande d'appui peut faire l'objet d'une lettre de refus
 Une lettre de refus est associée à une et une seule demande d'appui
 Un prestataire peut posséder plusieurs demandes de référencement
 Une demande de référencement appartient à un et un seul prestataire
 Un PV de référencement appartient à un et un seul prestataire
 Un prestataire peut posséder plusieurs PV de référencement
 Une lettre de référencement appartient à un et un seul prestataire
 Un prestataire peut posséder plusieurs lettres de référencement
 Une lettre de regret de référencement est liée à un seul prestataire
 Un prestataire peut avoir plusieurs lettres de regret de référencement
 Une entreprise peut avoir plusieurs activités

Annexe D Exemple de migration des données
100
Annexe D Exemple d’importation de la table activité
Il faut commencer par importer le fichier Excel procuré par le responsable du service
Suivi et Planification qui comporte la liste des activités.
Après, à l’aide d’une requêtes SQL (select DISTINCT) nous avons regroupé les activités
dans une table à part et leurs affecté des IDs.
Nous séléctionnons après les tables à importer.
Figure 54 : Séléction des tables à importer
Après avoir choisi la table, nous essayons de faire le mapping entre les champs source et
les champs destination. (Fig. 55)
Figure 55 : La jointure des champs

Annexe D Exemple de migration des données
101
Après l’importation la table activité se remplit par les données qui existaient déjà dans
l’ancienne application GEDA. (Fig. 56)
Figure 56 : Table aprés l’importation
Conclusion
La volumétrie pose un problème majeur dans la migration parce que seulement la table
des candidatures se compose d’environ 24000 lignes, cela engendre des difficultés de
manipulation de l’ancienne base de données.

Gestion programme moussanada avec openerp

Contenu connexe

Tendances

En vedette

Similaire à Gestion programme moussanada avec openerp

Plus de HORIYASOFT

Gestion programme moussanada avec openerp