SlideShare une entreprise Scribd logo
1  sur  54
2011-2012


                                      Master 2 Miage
      452 Bd Mohamed V
        (proximité place
            Yassir)
       CASABLANCA
      20500



                                    MEMOIRE DE STAGE



         Conception d’une application Android en Interaction avec
              Open ERP pour prise de commande à distance



                       Stage de 5 mois effectué au sein de la Société Nextma
                                               par :




                                    Nawfal B.A AKADIRI




                            Mémoire soutenu à l’Université le 25 Septembre 2012




Encadrant : M. AbdRahman El KAFIL                                                 Tuteur : M. Samir BENNANI
Remerciements

Louange à Dieu,

Je tiens à remercier :

   -   Mes chers parents, Moussibayi AKADIRI et Karimatou BOURAIMA qui m’ont toujours
       soutenue et encouragée
   -   M EL KAFIL, qui a accepté de me donner la possibilité d’effectuer mon stage dans son
       entreprise
   -   M KASSI & M ABBAS, pour leurs conseils avisés
   -   M BENNANI, pour son suivi malgré la maladie
   -   M ZURFLUH, pour son souci permanent de maintenir la qualité de la formation Miage
   -   Mme GALZIM, pour tous les efforts fournis au cours de ces années
   -   Tout le corps professoral
   -   Tous les étudiants de ma promotion
   -   Tous ceux qui de près ou de loin ont participé à la rédaction de ce mémoire




N.AKADIRI                                                                             Page 1
TABLE DES FIGURES

Figure 1 : Diagramme de Gant prévisionnel .................................................................................................... 10
Figure 2 : Diagramme de Pert .......................................................................................................................... 11
Figure 3 : Diagramme de Gant réel ................................................................................................................. 11
Figure 4 : Diagramme de cas d'utilisation ....................................................................................................... 13
Figure 5 : Diagramme de séquence - connexion au serveur ........................................................................... 14
Figure 6 : Diagramme de séquence - commande ............................................................................................ 15
Figure 7 : Architecture modulaire - Open ERP................................................................................................. 16
Figure 8 : Architecture Android ....................................................................................................................... 18
Figure 9 : Ecran de connexion ......................................................................................................................... 20
Figure 10 : Ecran Partenaire ............................................................................................................................ 21
Figure 11 : Ecran commande de produit ......................................................................................................... 21
Figure 12 : Paramétrage .................................................................................................................................. 22
Figure 13 : Bon de commande Open ERP ........................................................................................................ 22
Figure 14 : Extrait code 1 ................................................................................................................................. 23
Figure 15: Extrait code 2 .................................................................................................................................. 24
Figure 16 : Jeu d'essai - connexion .................................................................................................................. 24
Figure 17 : Jeu d'essai - prise de commande ................................................................................................... 25
Figure 18 : Structure d'un module................................................................................................................... 29
Figure 19 : Certification ................................................................................................................................... 39
Figure 20 : Synthèse Réflexion ........................................................................................................................ 44




N.AKADIRI                                                                                                                                            Page 2
TABLE DES MATIERES
INTRODUCTION .......................................................................................................................................................... 6

PARTIE 1 : CONTEXTE .................................................................................................................................................. 7

   A-        PRESENTATION DE LA SOCIETE ....................................................................................................................................... 7
   B-        DEFINITION DU SUJET .................................................................................................................................................. 8

PARTIE 2 : GESTION DE PROJET ET DEMARCHE D’INGENIERIE ..................................................................................... 9

   A-  CYCLE DE VIE.............................................................................................................................................................. 9
   B-  PLANIFICATION......................................................................................................................................................... 10
     1- Planification .................................................................................................................................................... 10
     2- Analyse des écarts ........................................................................................................................................... 12
   C- UML ..................................................................................................................................................................... 12
     1- Diagramme de cas d’utilisation ....................................................................................................................... 13
     2- Diagramme de séquence ................................................................................................................................. 13

PARTIE 3 : ENVIRONNEMENT TECHNIQUE .................................................................................................................16

   A-   OPEN ERP .............................................................................................................................................................. 16
     1- Architecture générale Open ERP ..................................................................................................................... 16
     2- Web services (XML-RPC) ...................................................................................................................................... 16
   B- POSTGRESQL .......................................................................................................................................................... 17
   C- TITANIUM ............................................................................................................................................................... 17
     1- Architecture générale ...................................................................................................................................... 17
     2- Limites ............................................................................................................................................................. 18
   D- ANDROÏD ................................................................................................................................................................ 18
     1- Architecture Androïd ....................................................................................................................................... 18
     2- Limites ............................................................................................................................................................. 19

PARTIE 4 : REALISATION & MISE EN ŒUVRE ..............................................................................................................20

   A-        INTERFACES ............................................................................................................................................................. 20
   B-        EXTRAIT DE CODE ...................................................................................................................................................... 23
   C-        JEU D’ESSAI ............................................................................................................................................................. 24
   D-        SYNTHESE DES TRAVAUX............................................................................................................................................. 25

PARTIE 5 : SUJET DE REFLEXION .................................................................................................................................27

   A-  CONTEXTE ............................................................................................................................................................... 27
        1-
         Les ERP et le monde de l’entreprise ................................................................................................................. 27
        2-
         La modularité .................................................................................................................................................. 28
        3-
         Intégration....................................................................................................................................................... 30
   B- DEMARCHE ACTUELLE DE GESTION DE PROJET ................................................................................................................. 31
     1- Qu’attendre d’une gestion de projet ? ............................................................................................................ 31
     2- La réalité du terrain ......................................................................................................................................... 32
   C- DEMARCHE AMELIOREE DE GESTION DE PROJET............................................................................................................... 33
     1- Gestion du changement & Formation ............................................................................................................. 33
     2- Planning de travail .......................................................................................................................................... 35
     3- Budgétisation .................................................................................................................................................. 36
     4- Recherche et développement (R&D) ............................................................................................................... 37
     5- Démarche qualité ............................................................................................................................................ 38
     6- Cycle de vie préconisé ...................................................................................................................................... 42
   D- SYNTHESE ............................................................................................................................................................... 43
             1-      Que retenir ? .................................................................................................................................................................43



N.AKADIRI                                                                                                                                                                                Page 3
2-      Limites de ma réflexion .................................................................................................................................................45

PARTIE 6 : BILAN ........................................................................................................................................................47

   A-      BILAN TECHNIQUE ..................................................................................................................................................... 47
   B-      BILAN PROFESSIONNEL ............................................................................................................................................... 48
   C-      BILAN PERSONNEL..................................................................................................................................................... 50

CONCLUSION .............................................................................................................................................................52

WEBOGRAPHIE ..........................................................................................................................................................53




N.AKADIRI                                                                                                                                                                        Page 4
TABLE DES ABEVIATIONS

Abréviation             Désignation
DUT                     Diplôme Universitaire de Technologie
ERP                     Enterprise Resource Planning
OS                      Operating System
PME                     Petites et Moyennes Entreprises
R&D                     Recherche et développement
SI                      Système d’information
SSII                    Société de Services en Ingénierie Informatique
TPE                     Très Petites Entreprises
XML                     Extensible Markup Language
XML RPC                 Extensible Markup Language – Remote
                        Procedure Call




N.AKADIRI                                                         Page 5
Introduction
   Les formations dispensées à l’ESG sont nombreuses et diversifiées. Au nombre de celles-ci, se
situant au confluent de la gestion et de l’informatique, la Miage. Cette dernière est un diplôme à
spécificité française qui a pour objectif de former des professionnels aptes à allier les nouvelles
technologies de l’information à la stratégie de l’entreprise. Formation dispensée en une période de
cinq années, elle inculque les notions de base de l’informatique et de la gestion à ses étudiants.

   Afin de mettre en valeur les connaissances acquises, deux stages sont requis : un en licence
Miage et un autre – final – qui vient sanctionner les cinq années de formation - en M2 Miage. C’est
ainsi qu’au cours de ces cinq derniers mois, j’ai eu à mettre en pratique les connaissances qui m’ont
été transmises auparavant. Plus encore, j’ai eu à apprendre de nouvelles choses. Tel est en effet l’un
des nombreux bénéfices des stages.

   Ainsi, ce mémoire qui n’a pas une visée technique vient présenter de façon synthétique - en me
mettant le plus possible dans la logique d’un chef de projet - l’ensemble des travaux accomplis au
cours de mon stage. Il est donc articulé en trois sections que sont :

   -   La synthèse des travaux : Cette section qui regroupe l’ensemble des activités de natures
       diverses – de la gestion de projet au développement - effectuées tout au long du stage. Y sont
       comprises les parties 1 à 4.
   -   Le sujet de réflexion : Résultat du fruit de mes réflexions – hors travail confié - sur
       l’entreprise, elle pose les bases d’une gestion de projet adaptée à la problématique récurrente
       d’intégration des modules ERP. La partie 5 vient donc traiter ce thème.
   -   Le bilan : Il vient faire la synthèse – à travers la partie 6 - de ce que ce stage m’a apporté sur
       le plan technique, professionnel et personnel.




N.AKADIRI                                                                                         Page 6
Partie 1 : Contexte
       A- Présentation de la société
   Fort de son expérience dans le domaine du logiciel libre, Monsieur AbdRahman El KAFIL se
lance en 2006, dès son retour de Belgique dans la création d’une Société de Services en Logiciels
Libres (SS2L). Sa vision est claire : accompagner les entreprises - en particulier marocaines - dans
la gestion de leur système d’information et ce en tirant au maximum profit des solutions open-
source. Ceci passe notamment par l’intégration, développement, la formation, maintenance…de
telles solutions au sein des entreprises.

   Ainsi, sa société – Nextma – propose diverses prestations aux entreprises tels que l’intégration de
progiciels de gestions d’entreprise (PGI-ERP) la gestion de la relation client (GRC-CRM), La mise
en place de solution de Business Intelligence (BI), de Synergiciels et collecticiels (Groupware), de
gestion électronique de Document (GED), d’Intranet d’entreprise et de gestions de contenu (CMS).

   L’ensemble des prestations proposées par Nextma – et tournant autour du libre - peuvent se
regrouper en quatre axes majeurs que sont :

      - La formation : Elle se compose d’un volet technique et fonctionnel qui permet
d'accompagner les organisations disposant d’équipes opérationnelles capables de mener à bien des
projets. Ces formations peuvent être établies sous forme de transferts de compétences, en phases
avales des projets.
      - Le support : Outre les formations dispensées, la société propose aux équipes dédiées au
développement des prestations de support d’aide à la maintenance afin de réduire le temps de
résolution des interrogations ou des difficultés que les entreprises pourraient rencontrer lors de la
mise en œuvre de certains logiciels.
      - Le conseil : La société assure des missions de conseil dans les domaines suivants : gestion
de contenu, travail collaboratif, dématérialisation des         procédures, migration vers le libre,
architecture et dimensionnement d'applications basées sur Open ERP.
      - Le développement : Il constitue le cœur de métier de Nextma et comprend le développement
sur la base de logiciels libres, de portails collaboratifs internet ou intranet…

   Par ailleurs, la société peut se targuer d’être le premier partenaire officiel d’Open ERP au Maroc.
Elle a ainsi contribué à la promotion de cet ERP en organisant plusieurs conférences dans les
universités et PME marocaines.




N.AKADIRI                                                                                      Page 7
Bien que l’effectif de l’entreprise soit peu consistant, elle bénéficie d’une certaine renommée.
Cette dernière étant le fruit de multiples services rendus dans le cadre de ses différentes prestations
aux entreprises marocaines tels que : Gaumar, Lydec, Pomelo Production mais aussi à quelques
filiales internationales tels que Fiat.

        B- Définition du sujet
   Open ERP, ERP Open source, possède un module qui permet aux commerciaux de pouvoir gérer
leurs ventes en toute flexibilité. Cependant pour les métiers exigeant un déplacement fréquent ou
intensif du commercial, cela s’avère vite pénible d’avoir à utiliser son ordinateur quand bien même
celui-ci serait léger. Ce qui se faisait jusque-là s’était que le commercial notait les commandes
effectuées sur papier puis les mettait à jour une fois de retour sur son poste de travail.

   Il fallait alors penser à un moyen plus adéquat qui permettrait au commercial d’effectuer ses
ventes, bien qu’en étant à distance de son lieu de travail ; et ce sans encombre. Sans nul doute, le
moyen le plus à même de nous permettre d’atteindre cet objectif a été le développement d’une
application mobile. Cette dernière constituera donc une extension à l’ERP. Ainsi, ceci permettra aux
commerciaux d’éviter d’attendre de rentrer au bureau pour saisir toutes les commandes et par
ailleurs permettra une meilleure efficacité.

   Il faudra donc développer avec le Framework Titanium, générateur de code multiplateforme, une
application mobile qui permettra, dans le cas où la connexion est disponible, aux commerciaux
d’effectuer des commandes. Ces dernières seront effectuées depuis leur mobile puis seront
synchronisées avec la base de données distante de l’ERP. En cas de problème de connexion dû en
majorité à l’environnement dans lequel évolue le commercial, les différentes commandes effectuées
seront stockées en local en attendant le rétablissement de la dite connexion. Par ailleurs, des
possibilités de pouvoir localiser le lieu de synchronisation des commandes doivent être prévues.

   Bien entendu l’application à concevoir doit être dans la même lignée que la politique de Nextma.
La dite politique comme nous l’avons vu qui est essentiellement basée sur la promotion et
l’utilisation des technologies Open-source. D’où leur utilisation à tous les niveaux du processus de
développement. Charité bien ordonnée commence par soi-même…




N.AKADIRI                                                                                       Page 8
Partie 2 : Gestion de projet et démarche d’ingénierie
    A- Cycle de vie
   Choisir un cycle de vie pour son projet n’est pas chose aisée. Le cas du projet se présentant à
nous ainsi que le cumul des expériences passées sont, en majeur partie, la base sur laquelle se
décide tout chef de projet dans le choix d’une démarche appropriée. Comme disait l’autre c’est le
terrain qui commande. Il faut savoir donc être flexible quitte à changer de démarche de gestion de
projet en plein projet !

   Lorsqu’il m’a été confié de réaliser cette application mobile qui puisse permettre des interactions
avec Open ERP, je ne savais pas trop dans quoi je m’embourbais. Je connaissais certes les bases
nécessaires pour le développement d’application mobile sous Android - notamment Java. Mais de
l’autre côté, c’était la première fois que j’étais réellement confronté à travailler avec de l’existant
plus particulièrement avec un ERP qui vient avec sa propre architecture, son propre
formalisme…Outre le fait que mon travail se basait sur une architecture existante, j’étais aussi
confronté au fait que Nextma attendait des résultats palpables très rapidement – normal c’est une
SSLL.

   Il m’est donc venu à l’esprit de faire ou plutôt d’utiliser un cycle de vie basé sur les méthodes
agiles. Mais qui parle de méthodes agiles suppose une maitrise d’ouvrage disponible entièrement.
Or je n’ai pas eu l’occasion de voir tout au long du projet le client final – prévu. Raison pour
laquelle je n’ai pas opté pour une démarche de gestion de projet basée sur de telles méthodes. Même
si l’on considère comme maître d’ouvrage mon directeur technique, la mise en place des méthodes
précédemment citées aurait été un échec cuisant en raison de la charge de travail de mon encadrant.

   Vu mon environnement de travail, j’ai préféré au tout début utiliser un cycle en V. Il faut dire
d’ailleurs que j’étais parti sur cette base car elle me permettait dès les premières semaines d’éditer
tout une série de documents afin de rassurer l’entreprise - cahier de charges, plan de test. Mais
après mûre réflexion, j’ai préféré opter pour       une méthode en spirale qui reprend certaines
caractéristiques du V mais avec la notion de prise en charge de risque.

   La méthode en spirale a été défini en 1988 par Barry Boehm dans son article "A Spiral Model of
Software Development and Enhancement". Nous savons qu’elle est basée sur un cycle itératif. Ainsi
on itère sur l’ensemble des phases d’un projet. L’itération de toutes les phases aurait pu sembler
longue à l’entreprise. J’ai donc décidé d’itérer uniquement sur les phases de conception et de
développement afin d’effectuer des validations par prototypage.




N.AKADIRI                                                                                       Page 9
En résumé, bien que les méthodes agiles m’aient semblé plus appropriées, elle n’aurait pas pu
marcher en raison des motifs précités. J’ai donc débuté mon projet sur un cycle en V mais très tôt
j’ai compris qu’il y avait assez de risques – notamment dû au Framework utilisé. Alors pour
remédier à cela, au niveau de la phase de développement, l’approche a été itératif et incrémental –
notamment en adoptant la méthode en spirale. Ce qui m’a permis de me rapprocher au mieux des
besoins des utilisateurs.

   B- Planification
       1- Planification
   La planification a consisté essentiellement à découper le projet en tâches puis à les hiérarchiser.
Après avoir hiérarchisé les différentes tâches, j’ai établi deux diagrammes que sont :

   -   Le diagramme de Gant
   -   Le diagramme de Pert

   Le diagramme de Gant m’a permis de contrôler l’état d’avancement du projet et le Pert quant à
lui m’a permis de gérer au mieux la ressource temps.

Planning prévisionnel




                            Figure 1 : Diagramme de Gant prévisionnel



N.AKADIRI                                                                                     Page 10
Figure 2 : Diagramme de Pert
Planning réel




                Figure 3 : Diagramme de Gant réel



N.AKADIRI                                           Page 11
2- Analyse des écarts
   Entre le prévisionnel et la réalité, il y a souvent des écarts. C’est d’ailleurs pour cela que l’on
parle de prévisions. Car personne ne sait de quoi sera fait l’avenir.

   Il faut avouer tout de même que pour la plupart des projets – que ce soit un projet d’école ou de
stage – auxquels j’ai participé, j’ai le souvenir d’avoir un tant soit peu réussi à tenir dans les délais
ou à accuser un léger retard sur les prévisions. Mais durant ce stage, ce fût tout une autre affaire !

   En effet, j’ai accusé un retard global de près de 2 semaines sur l’ensemble du projet. Enorme ! Je
le concède. Nonobstant cet aveu, à l’instant où j’écris ces lignes, je ne pense pas que j’aurai pu
mieux faire. Car les désagréments qui sont survenus sont vraiment uniques en leur genre. Ce sont
notamment : les problèmes au niveau du réseau internet lors de l’accès au serveur ERP de
l’entreprise et l’indisponibilité récurrente du portable Android. A vrai dire, ce dernier point je
l’avais prévu et j’avais pour objectif dans ma feuille de route de livrer le produit à Nextma quand
bien même je n’aurais pas pu faire le déploiement. Promesse qui a donc été tenue.

   C- UML
   Mon travail principal a été de comprendre les différentes interactions entre les modèles entrant
en jeu dans ma conception. Notamment les relations entre les modèles Open ERP - sales,
partner….Après avoir saisi cela, une modélisation basique a été faite pour la base de données en
locale sur le portable afin de ne récupérer du modèle original que les éléments qui m’ont été utiles
dans mon travail. Raison pour laquelle, je ne mentionnerai que le diagramme des cas d’utilisations
et quelques diagrammes de séquences car représenter le diagramme de classe sur lequel je me suis
basé (celui de l’ERP) serait trop volumineux et représenter celui qui a été fait en local ne
représenterait aucun intérêt.

   Notons aussi que représenter tous les diagrammes UML n’est pas une fin en soi mais c’est
l’usage qui en est fait des diagrammes mis à notre disposition qui fait toute la différence.




N.AKADIRI                                                                                        Page 12
1- Diagramme de cas d’utilisation




                         Figure 4 : Diagramme de cas d'utilisation

     2- Diagramme de séquence




N.AKADIRI                                                            Page 13
Figure 5 : Diagramme de séquence - connexion au serveur
Commentaires :

   Le commercial qui souhaite passer une commande doit tout d’abord se connecter. Après avoir
saisi les informations utiles à l’authentification au niveau de son mobile. Ces informations sont
alors parsées sous forme XML pour l’envoi via XML RPC au serveur. Après vérification, le
serveur renvoi la réponse qui est alors déparsée… Ceci donne alors au commercial la possibilité de
pouvoir effectuer une transaction – via l’affichage de l’écran d’accueil.




N.AKADIRI                                                                                 Page 14
Figure 6 : Diagramme de séquence - commande
Commentaires :

   Avant de passer toute commande, le commercial se doit bien sûr de se connecter. Après s’être
connecté, il synchronise les données – clients et produits – présents sur son portable avec ceux du
serveur. Une fois la synchronisation effectuée, une série de formulaires – notamment celui du choix
du partenaire et celui où il choisit les produits à vendre – lui sont affichées afin qu’il puisse
effectuer une transaction. Dès qu’il finit, et s’il le souhaite, il peut passer à la synchronisation des
ventes avec le serveur distant d’Open ERP.




N.AKADIRI                                                                                       Page 15
Partie 3 : Environnement technique

   A- Open ERP
      1- Architecture générale Open ERP
  En 2004, Fabien Pickaers s’appuie sur la grande diffusion qu’offre le logiciel libre pour lancer
Open ERP. Ce dernier comme son nom l’indique est un ERP open-source conçu à l’origine par un
belge et qui au fil du temps a pu se faire une place sur le marché grâce à la motivation de la
communauté qui la supporte. Comme la plupart de ses concurrents, il adopte un système modulaire
comme le montre la figure 7.




                         Figure 7 : Architecture modulaire - Open ERP
  Afin de communiquer avec l’ERP, l’éditeur a mis en place plusieurs protocoles de
communication que sont Net-RPC et XML-RPC.

          2- Web services (XML-RPC)
  L’hétérogénéité des langages de programmation et des systèmes à pousser la communauté, il y a
de cela quelques années à développer une technologie à même de permettre une communication
aisée entre eux. Ainsi est donc né XML-RPC. Comme nous pouvons le constater, cette technologie
date de près d’une dizaine d’années.




N.AKADIRI                                                                                 Page 16
Pour assurer cette communication, il fallait trouver un langage flexible tout en tirant parti
d’internet qui offrait déjà à l’époque un service d’interconnexion mondial. Le choix fût porté sur
XML, dont l’interopérabilité a fait ses preuves, couplé au protocole RPC. Ainsi, et ce de façon
brève, le client RPC demande l’exécution d’une méthode distante en prenant le soin de formaliser
cet appel dans un n fichier XML. La méthode distante traite la requête puis la renvoie au client,
toujours sous le format XML, qui se charge de parser ou de formater le résultat XML en données
utilisables.

   Dest technologies un tant soit peu meilleures ont vu le jour - Net-RPC. Mais le manque de
librairie – à ma connaissance – au niveau d’Android m’ont donc motivé à utiliser XML-RPC

    B- PostgreSQL
   Système de gestion de base de données relationnelles et objet, PostgreSQL comme la plupart de
ses concurrents permet d’exécuter des requêtes SQL de base. Aussi, il assure des traitements plus
complexes tels que les transactions, la réplication, la gestion des droits…

   Ce système de gestion de base de données, en raison de sécurité, n’autorise que les connexions
locales. Or la technologie XML-RPC précédemment citée n’a toute son utilité que lorsque la
connexion se fait à distance. Pour cela, Il a fallu modifier quelques fichiers de configuration
notamment les fichiers postgres.conf et pg_hba.conf.

    C- Titanium
       1- Architecture générale
   Titanium est un Framework permettant d’écrire son code une seule fois, et ce en JavaScript, et de
le générer pour diverses plateformes mobiles - notamment iPhone et Androïd. En effet, cet outil
génère du code natif à destination des plateformes mobiles supportées. Le programmeur écrit son
code en JavaScript - langage apparemment simple d’utilisation - et le code est généré en Java (pour
Androïd) et Objective-C (pour iPhone).
   Cela peut paraître plaisant car il permet de se départir des contraintes d’apprentissage d’un
nouvel langage. Bien sûr si l’on part du principe que JavaScript est bien plus facile d’apprentissage
que les langages précités – Java et Objective-C. Aussi, il permet au programmeur de travailler à un
haut niveau d’abstraction laissant ainsi la tâche au Framework de faire la « sale besogne ». Vu ainsi,
cet outil a tout pour séduire. Mais, il y a un « mais» !




N.AKADIRI                                                                                     Page 17
2- Limites
  Lorsqu’on passe à la pratique, la couche supplémentaire du Framework permettant la génération
de code rend lourde et lente la phase de développement. Sans compter les fuites de mémoire au
niveau du mobile en raison à la quantité importante de données rapatriées du serveur.

   Tout ceci mis en communion avec le fait de vouloir un prototype fonctionnel dans les meilleurs
délais ont fait, qu’en accord avec l’entreprise, nous avions décidé d’utiliser le langage natif
d’Androïd à savoir Java pour mener à bien le développement.

   D- Androïd
      1- Architecture Androïd
  Android est un système d’exploitation basé sur la distribution Linux. Il est destiné à des appareils
mobiles. Pour concevoir des applications sur cet OS, il faut posséder les bases nécessaires en Java.
Une imbrication et/ou une superposition de cinq couches, tel que le montre la figure 8, définisse
l’architecture d’Android. De la couche relative au noyau Linux à la plus haute qu’est la couche
application, tous les composants de l’OS s’évertuent à fournir des applications de qualité exploitant
au mieux les ressources du mobile.




                                 Figure 8 : Architecture Android



N.AKADIRI                                                                                     Page 18
C’est ainsi que :

   -   La couche Linux permet de gérer les traitements de base tels que la gestion de fichiers, la
       sécurité …
   -   Les couches Librairies ou Bibliothèques & Application Framework sont des couches
       destinées aux programmeurs.
   -   La couche Android Runtime quant à elle reprend les principales caractéristiques des
       librairies de base de Java en y ajoutant quelques spécificités telles que : la machine virtuelle
       Dalvik.

       2- Limites
   La notoriété du célèbre OS n’a pas laissé indifférent les pirates informatiques de tout bord. Ce
qui s’est traduit dans les faits par une augmentation exponentielle du nombre d’attaques
enregistrées.

   Pour s’en convaincre, il suffit de citer l’étude de Juniper Networks prenant en compte les
technologies mobiles les plus en vogue - à l’exclusion d’Apple en raison de la politique très fermée
de cette dernière - qui estime que les attaques sur Android entre 2010 et 2011 sont passées de 0,5 %
à 46,7% ! De plus, uniquement sur les sept derniers mois de l’année 2011, les logiciels malveillants
ciblant cette plateforme ont augmenté de 3325 % ! [w1]

   L’année 2012 a été marquée aussi par de nombreux soubresauts. Dernier en date, et pas des
moindres, la présentation d’un Framework modulaire – open source - d’exploit permettant à tout un
chacun de disposer d’une application Android malveillante faite sur mesure ! [w2]

   Google prend cependant ces menaces très au sérieux. Notamment avec Bouncer, son système de
détection de comportements malveillants qui malheureusement s’est révélé très vite inefficace. De
quoi s’interroger sur l’adjonction de technologies mobiles, en particulier celles basées sur Android,
au système d’information. Une brèche évidente de plus qui n’empêche cependant pas la Nasa de
mener actuellement des recherches qui à terme permettront d’équiper un nano satellite d’un
ordinateur de bord Android …[w3]




N.AKADIRI                                                                                      Page 19
Partie 4 : Réalisation & mise en œuvre
   A- Interfaces
  La section suivante présente quelques interfaces de l’application :




                                  Figure 9 : Ecran de connexion




N.AKADIRI                                                               Page 20
Figure 10 : Ecran Partenaire




            Figure 11 : Ecran commande de produit


N.AKADIRI                                           Page 21
Figure 12 : Paramétrage




            Figure 13 : Bon de commande Open ERP




N.AKADIRI                                          Page 22
B- Extrait de code
   L’utilité des commentaires n’est plus à démontrer. Cependant je ne peux pas dire que j’en ai mis
à tous les «coins de rue». En effet, j’en ai mis uniquement là où je l’ai jugé utile, comme le montre
les figures 14 et 15. Mais cela peut dépendre de chacun. De plus, la nature même du langage est
assez explicite : des si, sinon ….

   Parfois j’ai préféré ne carrément pas en mettre pour éviter de polluer le code qui était déjà assez
complexe à lire avec l’utilisation de librairies externes. En toute chose le juste milieu !




                                      Figure 14 : Extrait code 1




N.AKADIRI                                                                                     Page 23
Figure 15: Extrait code 2
    C- Jeu d’essai
   Lors de l’installation d’Open ERP, la possibilité nous est offerte lors de la création d’une base de
données de la charger avec des données de test. Il me semble que cette base de données couvre la
majorité si ce n’est la quasi-totalité des cas de figure.

   Je me suis aussi aidé d’un certain nombre de tests que j’ai établi dans un document remis à
l’entreprise afin de m’assurer de la conformité entre le résultat obtenu et les besoins du client. Les
figures 18 et 19 montrent notamment les jeux d’essai établis respectivement pour la connexion à
l’application et la prise de commande.




                                  Figure 16 : Jeu d'essai - connexion



N.AKADIRI                                                                                      Page 24
Figure 17 : Jeu d'essai - prise de commande
   D- Synthèse des travaux
   Ce stage a été une fois de plus l’occasion de me confronter au monde de l’entreprise. A
entreprises différentes, réalités différentes. Quoi de plus normal ! Car chaque entreprise à son vécu.
Mais aussi un ensemble de personnes différentes qui gravitent autour d’elle. Le tout a été donc de
pouvoir s’imprégner du mieux que possible de mon nouvel environnement.

   Il m’a été confié un projet de conception d’application mobile spécialement sous Android. Ce fût
une expérience nouvelle de concevoir autour d’une plateforme mobile. Le choix de l’outil de
développement – Framework Titanium – qui était, dès le départ, imposé par l’entreprise s’est vite
révélé problématique - notamment en raison des performances obtenues. Ce qui a nécessité de
suivre la procédure courante de développement des applications Android – utilisation du langage
Java. Il en a résulté de tout ce processus, une application qui pourra permettre à tout commercial en
déplacement de prendre des commandes sur son mobile et de les synchroniser à distance avec Open
ERP. Ce dernier se chargeant ensuite d’établir un bon de commande par client – sous forme de
devis – à valider ultérieurement.




N.AKADIRI                                                                                     Page 25
Par ailleurs, j’ai voulu comprendre un tant soit peu le principe de fonctionnement des modules
d’Open ERP. Ceci dans le but principal d’acquérir ne serait-ce que des connaissances basiques pour
de tel développement afin de mener à bien mon sujet de réflexion. Quoi de mieux que d’en
développer un module assez simpliste – en comparaison de ce qui se fait d’ordinaire. Chose que j’ai
faite en développant un module qui intègre les champs de géolocalisation au niveau du module de
vente d’Open ERP.

   La période de test a été la plus pénible. En effet, Android dispose d’un outil permettant d’émuler
le fonctionnement de l’OS sur son ordinateur. Seulement entre le virtuel et la réalité, l’écart est tel
que, la stupéfaction est bien souvent, au rendez-vous. La période de test n’a cessé de s’allonger car
le réseau de l’entreprise pour une raison qui, à ce jour, demeure toujours inconnue, ne facilitait pas
l’accès au serveur Open ERP quand on y tentait d’y accéder via un portable physique – malgré
l’ouverture des ports adéquats. Tantôt ça marchait, tantôt non ! Il a fallu bon nombre d’essai en
particulier sur un réseau externe pour déceler le problème qui était lié non seulement à la connexion
mais aussi à la quantité de données importées. Par ailleurs, les modifications de dernières minutes et
l’indisponibilité récurrente du portable – car appartenant à une personne souvent en déplacement -
n’ont fait que rallonger cette période de test.

   Quant à la rencontre avec le client – prévu -, elle n’a cessé d’être repoussée aux calendes
grecques pour des raisons multiples. Ce sont notamment la répercussion du retard accusé pour la
phase de test mais aussi du fait du programme chargé de l’encadrant. Cependant le développement
de l’application étant à présent terminée, elle sera de toute façon livrée au client, que ce soit durant
la période de mon stage ou en dehors.

   Voyons à présent tout un autre aspect de mon stage qui relate l’ensemble des réflexions faites –
suite à des discussions et des recherches personnelles - sur le fonctionnement de l’entreprise dans
une thématique donnée.




N.AKADIRI                                                                                       Page 26
Partie 5 : Sujet de réflexion
Titre : Nextma développe souvent des modules complémentaires pour Open ERP dans les
entreprises marocaines. On pourrait s’interroger sur la démarche de gestion de projet actuelle pour
le développement de tel module et penser à une amélioration de cette démarche pour produire des
modules hautement adaptatifs (en fonction de la configuration d’Open ERP au niveau de
l’entreprise commanditaire) et facilement évolutifs (avec les versions futures d’Open ERP).

   A- Contexte
       1- Les ERP et le monde de l’entreprise
   Dans les années 70, du côté des systèmes d’information, l’entreprise faisait en quelque sorte
« carrière solo ». Pour être plus explicite, disons que ses différentes cellules aussi bien internes,
qu’externes menaient une vie en autarcie du moins en ce qui concerne la gestion de leurs ressources
– notamment la ressource information. Que ce soit donc au niveau des échanges qui la liaient aux
autres entreprises ou des échanges entre les différents services, on assistait à un cloisonnement de
l’information.     Ceci a entraîné une barrière virtuelle entre les différentes entités en jeu dans
l’environnement de l’entreprise. Barrière qui s’est traduite bien évidemment par l’isolement de
l’information, la redondance et l’incohérence des données, la difficulté de mise à jour de ces
informations. ..

   Dans les années 80, l’ERP dont les prémisses remontent aux années 1960 devient petit à petit un
élément indispensable dans les entreprises qui sont désormais à la recherche d’information de
qualité. Et pour cause, les différents processus internes de l’entreprise qui autrefois étaient isolés
commencent à s’unifier et s’imbriquer dans un souci pour les décideurs d’avoir une vision
homogène et globale de leur système d’information.

   L’avènement d’internet dans les années 90 a donc donné aux ERP une importance plus accrue.
En effet internet a permis d’étendre le système d’information de ces entreprises. Cette révolution a
donc ajouté à l’unification des processus internes déjà entamée dans les années 80, l’unification des
processus externes. De plus avec la concurrence sans cesse croissante, l’entreprise a dû ainsi subir
de profondes mutations tant sur le plan organisationnel que technique. Au nombre de ces mutations
technologiques, l’utilisation - plus intensive - des ERP.

   Ces outils ont fait et font leur preuve car ils permettent d’homogénéiser l’ensemble des
informations de l’entreprise tout en permettant à ses différents acteurs de disposer de l’information
appropriée : que ce soit pour une vision synthétique de l’information pour le décideur ou pour le
traitement d’une transaction pour un opérateur.

   Comme dans la plupart des innovations dans le domaine technologique en particulier



N.AKADIRI                                                                                     Page 27
informatique, il existe des solutions dites propriétaires et des solutions open-source. La principale
différence entre ces deux types de solutions se trouvent dans le business-model qui est mis en place.
Pour la plupart des solutions dites propriétaires, la licence est vendue puis la maintenance est
assurée de facto. Tandis que pour les solutions dites open-source, la licence est gratuite et la
maintenance et/ou les services sont facturées. Nous ne nous attarderons pas sur ces points, tel n’est
pas notre sujet.

   Comme vu brièvement dans la partie 3, quel que soit le type d’ERP pour lequel on opte,
l’architecture est souvent la même. Il s’agit d’une architecture modulaire qui permet à l’entreprise
de développer des modules spécifiques pour enrichir les fonctionnalités de l’ERP si le besoin s’en
faire sentir. Bien que ce type d’architecture ait fait ses preuves dans bien d’autres domaines, elle
pose un problème majeur dans le cas des ERP. En effet, à chaque nouvelle version de l’ERP, les
modules précédents doivent être adaptés à la nouvelle version mais encore à la configuration de
l’entreprise cible !

   L’entreprise dans laquelle je me trouve est justement spécialisée dans les questions relatives à
tout ce qui touche de près ou de loin aux ERP en particulier à Open ERP. C’est à ce titre, qu’elle
intervient dans l’intégration d’Open ERP au niveau des entreprises marocaines - PME en particulier.

   La question que nous nous sommes posé était de savoir s’il n’y aurait pas une démarche de
gestion de projet adaptée pour produire des modules hautement adaptatifs (en fonction de la
configuration d’Open ERP au niveau de l’entreprise commanditaire) et facilement évolutifs (avec
les versions futures d’Open ERP). Il s’agit bel et bien d’adopter une démarche de gestion de projet
pouvant faciliter la compatibilité ascendante des modules. Question insoluble me diriez-vous ?
Possible ! Mais peut être que la question n’a jamais été posée ou n’a pas été formulée comme il se
devait.

   Avant de résoudre notre problème, tel un médecin, commençons tout d’abord à faire un
diagnostic plus détaillé. Ce qui reviendrait dans notre cas à mieux expliciter la modularité de
l’architecture d’Open ERP puis à décrire le processus d’intégration des modules.

          2- La modularité
   Un module Open ERP est une brique logicielle qui permet de personnaliser l’ERP selon ses
besoins. Le module est construit selon une architecture prédéfinie. Cette dernière se compose
généralement de dossiers imbriqués contenant des scripts python et des documents XML (tel que le
montre la figure 18) permettant de définir l’interaction entre les différents objets Open ERP.




N.AKADIRI                                                                                        Page 28
Figure 18 : Structure d'un module
   L’ERP est composé de plus de 300 modules et est continuellement en évolution. Selon le secteur
d’activité de l’entreprise, on peut trouver un ou plusieurs modules qui permettent à l’ERP de
s’adapter au mieux à ses besoins. On peut donc classer ces modules en fonction des services qu’ils
rendent. Cependant, dans le cadre de mon sujet de réflexion, une telle classification ne représentera
aucun intérêt. Raison pour laquelle l’ensemble de ces modules disponibles au niveau d’Open ERP
sera plutôt classé en deux catégories principales :

- Les modules de base : regroupe tous les modules indispensables au fonctionnement d’Open ERP.
- Les modules spécifiques : ce sont des modules que l’on a ajouté à Open ERP. Ces modules sont
développés soit par l’éditeur ou soit par des tiers.

   Ainsi, les modules spécifiques sont développés par deux entités que sont l’éditeur et les
partenaires. Nous verrons par la suite que c’est la deuxième catégorie de modules – lorsqu’elle est
développée par les partenaires - qui posent le plus de problème.




N.AKADIRI                                                                                    Page 29
3- Intégration
   Nous avons donc vu qu’un module Open ERP est un élément qui respecte certains critères qui lui
permettent de s’intégrer aisément dans Open ERP afin d’apporter une plus-value en terme de
fonctionnalités.

   Le développement de tels modules n’est pas si différent de celui qui est d’ordinaire connu en
développement informatique. En d’autres termes, nous avons trois phases principales à savoir la
phase d’analyse, de conception et d’implantation. De l’analyse effectuée, on en tire les différents
flux d’information de l’entreprise à implanter au niveau de l’ERP sous forme de modules.

   Après le recueil des besoins du client par l’intégrateur - via la phase d’analyse - vient un
benchmark. Ce dernier sert à répertorier les solutions existantes en termes de modules. Ceci
permettra de savoir si l’on doit concevoir un nouveau module de bout en bout ou faire une
extension ou encore une spécialisation d’un composant métier existant. Suite à cette étape de
benchmarking - analyse comparative -, l’intégrateur entame la phase de spécification fonctionnelle
par un premier découpage fonctionnel en dégageant les dépendances existantes. Par exemple pour
une application – un module - de gestion complète de stock, il pourra tout d’abord s’intéresser à la
gestion de produits qui est une fonctionnalité en créant un premier module. Puis passer à la gestion
du flux comptable – qui est associé à la gestion du stock – qu’il intégrera dans un autre module.

   Après le découpage susmentionné, l’intégrateur peut maintenir établir pour chaque découpage,
une conception ordonnée avec un périmètre fonctionnel défini. Ceci s’avère utile pour assurer
l’engrenage des composants.

   Analyse comparative assurée puis découpages effectués, l’intégrateur débute la conception des
maquettes pour chaque module dégagé. Maquettes qui seront validées par le client. Pour le reste, il
s’agit d’établir les diagrammes UML dont on a besoin puis de penser à la liste de rapports à
concevoir.

   En somme, l’intégrateur recueille donc les besoins de l’entreprise puis les modélise le tout en
utilisant différents modèles. Le plus coutant est UML car les relations entre les différents modules
sont souvent à préciser mais plus encore du fait que l’ensemble de l’architecture Open ERP est
basée sur des objets. A tout ceci, un diagramme de processus peut être établi afin d’avoir une vision
plus claire et synthétique des différents flux présents au niveau de l’activité analysée dans
l’entreprise.




N.AKADIRI                                                                                     Page 30
Lorsque l’on fait un tour sur le net, moult documentation font l’apologie d’Open ERP en vantant
sa flexibilité car permettant la « construction de bâtiment sur mesure »…Ces écrits peuvent t’ils être
qualifiés d’écrits partisans ou les mérites tant vantées le sont-ils véritablement ?

   Comme évoqué plus haut, Open ERP est modulable de bout en bout. Le principe de modularité
des fonctionnalités de l’ERP, qu’elles soient minimes ou complexes, est un atout indéniable qui
accroît son potentiel.

   Là où le bât blesse, c’est lorsque l’entreprise doit migrer de version de l’ERP entraînant quelques
fois, si ce n’est la quasi-totalité du temps, une obsolescence du module qui autrefois faisait la joie
des utilisateurs. Ainsi, la modularité d’Open ERP tant vantée par certains est à l’origine d’un autre
puzzle - pas celui de l’enrichissement du logiciel - mais plutôt celui de garantir une cohésion
pérenne des modules. Cette modularité ne présenterait donc pas que des avantages. En d’autres
termes, les modules c’est bien, mais ça ne résout pas tous les problèmes !

   Des lignes qui précèdent, on comprend aisément que quel que soit l’entreprise, qu’elle se nomme
Nextma ou autre, la problématique reste la même ! Comment véritablement améliorer l’intégration
de ces modules ?

   Ma démarche consiste donc à penser à une amélioration de cette intégration, précisément au
niveau des modules développés par Nextma. Pour ce faire, je me propose de travailler, non pas sur
le côté technique - python & compagnie - mais plutôt sur le côté gestion de projet. En effet, il est
connu que pour réussir la phase de maintenance d’un produit informatique, il faut faire une bonne
analyse mais surtout bien gérer son projet. Ce qui m’amène à penser que l’adoption d’une bonne
démarche de gestion de projet dans la création de modules est un gage de production de modules
plus facilement maintenables, hautement adaptatifs et évolutifs.

   Mais avant tout, existe t’il actuellement au niveau de Nextma, une démarche de gestion de projet
qui permette le développement de tels modules ? Comment faudrait-il améliorer cette démarche, si
démarche il y a, ou quelle démarche de gestion de projet adoptée pour résoudre notre problème
d’intégration ?

   B- Démarche actuelle de gestion de projet
   1- Qu’attendre d’une gestion de projet ?
   Un projet peut être défini comme une série d’actions orchestrées dans le temps, en fonction des
ressources disponibles, afin d’atteindre un objectif prédéfini. Objectif qui ne saurait être atteindre
qu’en gérant le projet.



N.AKADIRI                                                                                     Page 31
Gérer un projet équivaudrait donc à mener des troupes au combat. Bien entendu, l’on ne va pas
au combat sans mission et sans stratégie. De même dans un projet, la (les) mission(s) doivent être
clairement définie(s), les moyens pour y parvenir doivent être répertoriés et une démarche doit être
mise en place .Les démarches existantes pour mener à bien une gestion de projet sont assez
nombreuses. Elles ont pour point commun d’optimiser les ressources disponibles afin de converger,
autant que peut se faire, vers le but voulu.

   Pour mener à bien cette orchestration, il s’agit de façon générale d’initialiser le projet, de le
planifier, de le mettre en œuvre, de le contrôler puis de le clôturer. Ainsi, il en découle les grandes
étapes suivantes :

   -   Initialisation du projet
   -   Planification du projet : Etablissement d’un plan de travail
   -   Mise en œuvre du projet : Il s’agit ici, de gérer les différentes ressources entrant en jeu dans
       le cadre du projet afin d’atteindre ses objectifs.
   -   Contrôle du projet : A ce niveau, on effectue des suivis par rapport à la planification et à la
       coordination des ressources afin de détecter les éventuels écarts et d’y remédier le plus tôt
       possible.
   -   Clôture du projet : Finalisation du projet et bilan global afin d’en tirer des leçons et
       d’améliorer la qualité des projets futurs.

   2- La réalité du terrain
   Tout d’abord, mentionnons un point important qui sans lequel, la description actuelle de la
gestion de projet - pour le développement de modules - faite par Nextma risque d’être criblée de
critiques. Or, mon travail de réflexion ne vise pas un tel but.

   Jusqu’à tout récemment, Nextma développait un partenariat avec une société de la place. Mais
ce contrat, pour des raisons qui me sont inconnues a été rompu. Raison pour laquelle Nextma se
reconstitue une équipe. Elle mise donc sur l’apport des stages pour rénover son personnel. C’est
donc dans un tel climat de restructuration que j’ai débuté mon stage, ce qui fait que ma description
de la gestion de projet - pour le développement de modules - qui est pratiquée au niveau de
l’entreprise ne peut être qu’incomplète voire biaisée.

   En raison des points susmentionnés, il m’est donc impossible de décrire objectivement la gestion
de projet pratiquée dans le cadre du développement de modules par Nextma. Cependant, j’ai pu
constater au cours de ces cinq mois, quelques entaches notamment au niveau de l’initialisation du




N.AKADIRI                                                                                      Page 32
projet où les besoins ne sont pas forcément bien définis dès le départ ce qui par la suite, bien
évidemment, créé tout un imbroglio ou des projets à rallonge.

   N’allez surtout pas croire que Nextma peine à rattraper le train de la concurrence - du moins de
mon point de vue - car cela à l’air d’être chose courante dans le domaine. Selon Journal du Net qui
publiait, en s’appuyant sur une enquête en ligne réalisée entre février 2006 et mai 2012 auprès de
2000 répondants (dans 61 pays) qui ont mis en place l'ERP Oracle, Microsoft Dynamics ou SAP, un
dossier datant 23/07/2012 sur les projets ERP en général, le constat est alarmant : « En tout cas, en
2010, les entreprises interrogées par Panorama Consulting étaient 35,5% à affirmer dépasser le
temps de déploiement prévu initialement. Elles sont plus de 60% dans ce cas en 2012. » [w4]

   Est-ce une raison pour ne pas aller de l’avant et s’améliorer ? Bien sûr que non !

    C- Démarche améliorée de gestion de projet

   Après avoir donné un aperçu, qui je l’avoue est assez bref, de la démarche actuelle de gestion de
projet adoptée au niveau de l’entreprise, voyons à présent en quoi pourrait consister une démarche
de gestion de projet efficace à même de résoudre ma problématique.

   Il est un fait que les risques sont inhérents à tout projet, le développement de modules n’en fait
pas exception, bien au contraire. Il ne serait pas faux de dire que gérer ce genre de projet, comme
tout autre projet, revient à limiter au maximum les risques. On s’évertuera donc dans la suite de cet
exposé, autant que faire se peut à limiter les risques liés à l’intégration de modules Open ERP dans
l’entreprise.

            1- Gestion du changement & Formation
   Toute nouveauté, tout changement, au sein d’un groupe d’individus génère frustrations,
réticences. Ces sentiments générés sont le propre de l’homme qui préfère « ménager sa zone de
confort ». Pour cela il développe une série de mécanismes psychologiques et/ou physiques qui lui
permettent de faire écran avec ce qu’il juge intrusif.
   Dans de telles situations, il ne sert à rien d’imposer manu-militari le changement. Bien au
contraire, il faut ménager les individus en gérant au mieux ce changement. Gérer le changement
reviendrait donc, de façon globale, à les convaincre que la nouveauté voulue cadre bien avec leur
zone de confort. Cet exercice s’avère assez complexe car les individus d’un groupe ont des natures
et ambitions diverses.

   L’installation de nouveaux modules au sein d’une entreprise est dans ce sens perçu par les
utilisateurs comme un changement. Il convient donc d’intégrer dans sa gestion du projet - de façon


N.AKADIRI                                                                                    Page 33
parallèle - une politique de gestion du changement. Le développement de tels modules, bien souvent
complexes, se révèle être une tâche astreignante. Quoi donc de plus frustrant que d’avoir des
utilisateurs «capricieux» en face.

   Ce fait mentionné a été vécu par un membre de mon équipe où lors de la phase de recette, tous
les utilisateurs avaient adopté bon gré, mal gré le nouveau module à l’exception d’un seul qui pour
un rien faisait retarder la phase réelle d’exploitation du module.

   Lorsqu’on prend un tout petit peu de recul, on n’en vient à se dire que la faute ne revient pas
seulement à l’employé car elle est partagée. Il a dû développer des réticences du fait que le projet
n’ait pas été suffisamment, si l’on peut dire « marketé » comme il se devait auprès des employés.
En d’autres termes, il n’y a pas eu de gestion de changement qui suive. Pour être plus précis, disons
plutôt qu’il n’y a pas eu de gestion de changement en parallèle ; car si elle vient après le projet, il
est déjà trop tard !

   Structurer sa politique de gestion de changement s’avère donc utile. Mais nous sommes en droit
de nous poser la question légitime de savoir si une bonne de gestion de changement peut réellement
aider dans la résolution de notre thématique. Nous répondons, oui, du moins, elle résout une partie
du problème, notamment la facilité d’adaptation des modules dans les entreprises, mais pas
l’évolutivité des modules suite aux évolutions dictées par les versions nouvelles de l’ERP. Cet
aspect sera traité plus bas.

   Notons que cette gestion de changement peut être aussi pris en charge par l’entreprise elle-même
mais nous nous mettons ici dans l’optique qu’elle est confiée à l’équipe en charge de gérer le projet.

   Côté formation, le chef de projet devra prendre aussi le soin de mobiliser le personnel nécessaire
pour leur donner une formation adéquate. La formation dont nous parlons comprend deux volets :

    -   La formation en interne (au projet)
    -   La formation des utilisateurs

   La formation en interne regroupe toutes les formations que le chef de projet jugera nécessaire de
fournir à son équipe pour améliorer la qualité de leur développement.

   Quant à la formation des utilisateurs elle s’avère d’autant plus utile car il ne sert à rien de
dépenser de ses ressources à former son équipe et à certifier son module si en amont on ne pense
pas à la formation de ceux pour qui le module est destiné.




N.AKADIRI                                                                                      Page 34
Il convient donc d’intégrer l’axe formation à la politique de gestion de changement. Plus
particulièrement le deuxième volet de la formation à savoir la formation des utilisateurs. Ainsi, la
formation des utilisateurs et la gestion de changement interviendrait dans la résolution de
l’adaptabilité des modules en fonction de l’entreprise commanditaire. Tandis que la formation en
interne - notamment sur les règles de certification – permettra quant à elle d’assurer l’évolutivité
des modules. Nous parlerons plus bas de la certification au niveau de la démarche qualité.

            2- Planning de travail
   Dans cette section, nous nous efforcerons de dénombrer les étapes courantes, telles que perçues
durant mon stage, d’une planification de modules tout en mettant l’accent sur les endroits que l’on
juge important de réussir si l’on souhaite produire des modules plus évolutifs et/ou adaptatifs.
   -   Formations fonctionnelles : Vu qu’Open ERP est une grande forteresse, il est prétentieux de
penser la maitriser de bout en bout. Raison pour laquelle, l’équipe qui intervient sur le projet a
parfois besoin de mieux comprendre le fonctionnement de certains aspects de l’ERP. Il faut donc
prévoir ce fait au début en évaluant les compétences fonctionnelles de son équipe dans le domaine
d’action du projet.
   -   Analyse de l'existant : Développer un module, n’est pas une tâche en aparté. Elle fait partie
intégrante d’une logique globale. On peut la comparer à la construction d’une brique dans
l’édification d’un immeuble. En effet, la brique ne saurait être construite à la volée. Une étude
préalable s’avère donc nécessaire pour déterminer le type de brique, son contour, l’agencement avec
la structure de l’immeuble…
   Il en est de même pour l’analyse qui précède le développement d’un module. Comme toute
phase d’analyse, elle permettra de capturer les besoins des utilisateurs mais plus encore de s’assurer
de la faisabilité de ceux-ci car ici, on est limité à l’architecture de l’ERP. Aussi, dans cette phase
d’analyse, il faudra répertorier et décortiquer les différentes interactions - workflow – et les
dépendances existantes entre les modules déjà présents et ceux qui seront utiles au nouveau module
à concevoir.
   -   Développement : C’est à ce niveau qu’on « converti » l’analyse précédemment effectuée en
lignes de code. On s’appuie donc sur un langage. Mais pas n’importe lequel ! Celui sur lequel est
basé Open ERP à savoir python mais aussi sur un langage de balisage - précisément XML - qui
apporte une certaine souplesse au développement des modules.
   -   Migration des données : Cette phase peut s’avérer utile dans certains cas.
   -   Tests : Pas si différente des phases de tests connues du développement informatique. Cette
phase permet de s’assurer de l’adéquation des besoins des clients avec le module final.




N.AKADIRI                                                                                     Page 35
-      Capture des remarques et maintenance : Les remarques du client se prennent en majorité –
du moins selon ce que j’ai vu durant mon stage – vers la fin du projet quand le module est déjà
fonctionnel à près de 90 %.

   L’ensemble des trois phases (Tests, Capture des remarques et maintenance) peut s’étaler sur une
très longue période tant certains modules sont complexes. En plus de cela, la prise des remarques
vers la fin du projet ne fait que rallonger le délai de maintenance et par ailleurs celui de la fin du
projet.

   -      Déploiement du module : Permet de mettre en production le module développé. Elle
intervient après de nombreux va-et-vient entre les trois phases précédemment citées.

   Nous venons donc de voir que les phases citées ci-dessus (allant de la formation fonctionnelle au
déploiement du module) sont, de façon générale, celles qui sont pratiquées par Nextma pour le
développement de modules. A présent posons-nous la question de savoir quelles sont les
améliorations que l’on puisse apporter dans le cadre de la résolution de notre problématique ?

   De façon générale, les phases appliquées par Nextma sont assez intéressantes en soi. Cependant,
il convient d’intégrer deux éléments à cette planification. Le premier élément est en fait une
amélioration d’une phase déjà existante et le second est l’intégration d’une phase qui n’est pas
encore existante.

   Tout d’abord, il y a une chose qui nous interpelle. La phase « Capture des remarques » se
retrouve entre les tests et la maintenance. Il n’y a pas de mal en tant que tel mais pour ce genre de
projet, il convient de prendre les remarques du client le plus fréquemment possible afin d’éviter les
déconvenues. En effet, le développement de module n’étant pas une sinécure, il convient d’associer
le client au maximum tout au long du projet.

   Deuxième point à intégrer, ce sont les bilans en fin de projet. Il convient en effet d’établir une
base de connaissances d’ordre diverses – théoriques, managériales, organisationnelles – répertoriant
l’ensemble des problèmes rencontrés tout au long du projet et comment ils ont été résolus. Ainsi, à
chaque nouveau projet on améliorera les zones d’ombre.

             3- Budgétisation
   Dans cette partie, nous verrons comment faire pour établir un budget qui permette d’atteindre
notre objectif de développer des modules facilement évolutifs. Mais avant tout, rappelons
brièvement ce que c’est que la notion de budgétisation et quelle relation étroite se tisse entre
budgétisation et projet.



N.AKADIRI                                                                                     Page 36
La budgétisation est l’ensemble des procédés qui permettent de s’assurer que les ressources –
financières entre autres – dont nous disposons (ou disposeront) nous permettent(ou permettront) de
couvrir l’ensemble des dépenses auxquelles on est censé faire face. Cet exercice financier sensible
doit être mené avec rigueur.

   Bien évidemment, la budgétisation n’est pas faite en aparté, elle fait partie intégrante de la
gestion d’un projet. Ainsi, la budgétisation intervient dans la phase de planification, aussi bien
prévisionnelle que réelle. Elle permettra donc au chef de projet de s’assurer qu’il n’a pas les yeux
plus gros que le ventre mais surtout de rentabiliser le projet. Cette phase comme la quasi-totalité des
phases d’un projet nécessitera aussi l’aval de la direction.

   Des lignes qui précèdent nous avons pu saisir que l’établissement du budget est une étape
délicate, qui bien qu’à elle seule ne puisse faire la réussite d’un projet, y contribue
significativement. Le développement de modules évolutifs étant - avant tout - un projet, il est tout
fait normal qu’une bonne gestion du budget puisse produire des résultats probants. Mais, affirmer à
l’emporte-pièce qu’une bonne gestion du budget puisse permettre le développement de modules
plus évolutifs serait trop prosaïque. En effet, il conviendrait d’expliciter un peu plus cette assertion.

   Pour que la budgétisation nous soit profitable dans la résolution de notre problématique, il nous
faudra prendre en compte aussi bien les coûts directs que les coûts indirects. Ce sont notamment :

   -   Coût des salaires des employés travaillant sur le projet
   -   Coût des intervenants externes (consultant, formateur…)
   -   Coût de la qualité (certification, formation…)
   -   …

            4- Recherche et développement (R&D)
   Bien que dans le modèle économique de la firme Open ERP, le faible coût d’investissement
R&D est un atout vanté du fait qu’actuellement la R&D autour de l’ERP est assurée à 80 % par
l’ éditeur et à 18% par les éditeurs propriétaires, il me semble opportun d’inverser la tendance….
D’autant plus que la communauté fait partie intégrante de la stratégie de développement l’éditeur.
Pour cela le chef de projet devra constituer une équipe dédiée à plein temps à la R&D.
   Cette technique d’investissement R&D commence à voir le jour mais lentement. C’est le cas de
la société Axelor en France qui est une société de services spécialisée dans l'intégration d'ERP Open
Source. Cette société possède son propre centre de R&D et est l’auteur de nombreuses innovations
permettant d’améliorer dans la continuité Open ERP. Au nombre de ces innovations, nous pouvons
citer notamment : les plug-ins MS office, la nouvelle version web d’Open ERP … L’investissement



N.AKADIRI                                                                                        Page 37
dans la R&D permettrait d’aboutir à une innovation. Encore faut-il savoir quels types d’innovation
faire.

   Nextma étant une PME voire une TPE, les meilleurs types d’innovation qu’elle pourrait mettre
en place sont des innovations de marché ou de valeur. Or, de mon point de vue, la meilleure
innovation dont on a besoin dans notre cas de figure est une innovation de processus. En effet, il
convient de mettre en place de nouveaux procédés permettant d’améliorer l’adaptabilité et
l’évolution des modules. Les moyens étant limités, Nextma pourrait penser à mettre en place un
consortium d’entreprises qui uniront leurs ressources pour imposer de nouveaux processus, de
nouveaux standards au niveau du développement des modules Open ERP - et dans une plus large
mesure au niveau de la gestion de projet de tels modules.

   Détail important ; pour mener à bien cette stratégie d’investissement R&D, le chef de projet
devra pouvoir convaincre sa direction du bien-fondé de ces investissements à haut risque.

             5- Démarche qualité
   La qualité est un vaste domaine abordé dans presque tous les aspects de notre vie quotidienne.
Elle se révèle d’une grande utilité lorsqu’on sait l’utiliser à bon escient et ce dans un cadre bien
déterminé.

   Pour permettre une meilleure intégration des modules, il faudra donc adopter une démarche
qualité. Mais laquelle ? Comme il a été dit, le terme qualité regroupe plusieurs définitions. Il
faudrait, par soucis de clarté, préciser l’aspect qualité que pourrait adopté le chef de projet lors
d’une gestion de projet impliquant le développement de modules Open ERP. Je restreindrai donc
volontairement la qualité à la notion de certification.

   Le chef de projet soucieux de pouvoir mener à bien son projet de développement de module, et
ce par la même occasion permettre la production de modules hautement évolutifs, se doit de les
certifier. Encore faut-il qu’il en soit convaincu du bien-fondé de cette certification. Chose que je
m’évertuerai à prouver dans les lignes qui suivent.

   La certification désigne un processus qui permet d’attester de la conformité d’un produit ou d’un
service par rapport à des standards prédéfinis. Elle se fait généralement par un organisme accrédité.
Ainsi, la certification d’un module Open ERP est un processus qui vise à valider la conformité du
nouveau module par rapport à des standards définis par Open ERP. Elle permet donc aux modules
spécifiques d’être inclus dans l’ERP.

   Pour certifier son module Open ERP, cinq étapes principales sont nécessaires :


N.AKADIRI                                                                                    Page 38
-   L’analyse technique : Il s’agit de faire une analyse approfondie du code afin de détecter les
       erreurs éventuelles, la conformité des bonnes pratiques, la robustesse des modules….
   -   L’analyse fonctionnelle : Ici, l’éditeur essaye de déterminer la pertinence de l’approche
       adoptée par l’équipe projet.
   -   Validation/Non validation : Si le module est validé, un certificat est délivré dans le cas
       contraire, des propositions d’amélioration sont faites en vue d’améliorer la qualité du
       module.
   -   Insertion du module dans la suite logicielle
   -   Diffusion à la communauté

   La certification, comme le montre la figure 19, prône donc un apport des partenaires à la
   communauté      mais     surtout    un    contrôle   qualité   effectuée    par   Open       ERP.




                                      Figure 19 : Certification



N.AKADIRI                                                                                     Page 39
Jusque-là nous venons de découvrir le processus de certification mis en place par Open ERP.
Mais une question subsiste en quoi ce processus est-il gage d’une meilleure intégration des modules
ou d’une maintenance évolutive réussie sans lourdeur ?

   La certification de modules que se propose de faire l’éditeur moyennant rétribution financière est
une aubaine. En ce sens qu’après la certification, les modules comme nous l’avions vu
précédemment sont inclus dans les versions futures d’Open ERP.

   Gâteau sur la cerise, le module certifié bénéficie du contrat de maintenance Open ERP. Ce
contrat qui stipule entre autres conditions, qu’Open ERP se charge d’assurer la correction
d’éventuels bugs , de migrer et d’adapter ce module à chaque nouvelle sortie d’Open ERP. Comme
disait l’autre, que veut le peuple ?

   Nous y voilà ! « Migrer et adapter ce module » En effet si, à chaque nouvelle version d’Open
ERP, les modules nous sont livrés avec leur évolution ceci éviterait des coûts supplémentaires de
développement interne nécessaire pour garantir la conformité du module précédemment développé
avec la nouvelle version. Ceci permettrait donc à l’entreprise dans le futur, d’avoir l’assurance
complète – puisque stipulé contractuellement via le contrat de maintenance - que les modules
développés auparavant évolueront de manière transparente.

   Par le biais de ce contrat de maintenance, outre la correction et l’évolution du noyau interne
d’Open ERP, l’éditeur assure donc une évolution des modules – plus particulièrement les modules
spécifiques. L’évolution des modules spécifiques étant assurée en grande partie par le processus de
certification. Ainsi, la certification apporterait des profits aussi bien à l’équipe projet qu’au client.

   Bien que la majorité des recommandations faites pour mener à bien le projet se font au niveau
de la maîtrise d’œuvre, il est opportun de présenter les avantages qu’ont les deux parties à penser à
la certification Du côté de l’équipe projet ce sont notamment :

    -   L’économie en temps et en argent : cherté de la découverte de bugs tardifs, migration
        complexe de version…
    -   Le fait de pouvoir gagner la confiance du client
    -   Notoriété accrue : Via la certification, l’entreprise peut redorer son blason. En effet, c’est
        l’occasion idéale et rêvée pour l’équipe projet de (re)donner de la visibilité à leur entreprise
        en participant à l’enrichissement des fonctionnalités d’Open ERP – qui est d’ailleurs
        distribué dans plusieurs pays.




N.AKADIRI                                                                                          Page 40
Les avantages que tire le client à exiger auprès de la maîtrise d’œuvre la production de modules
    certifiés sont les suivants :

    -   Pouvoir migrer facilement son module vers les nouvelles versions de l’ERP tout en
        conservant la cohérence d’ensemble
    -   S’affranchir de passer différents contrats de maintenance avec différents éditeurs de
        modules. D’autant plus qu’Open ERP dispose de plusieurs modules mais plus encore d’une
        centaine de modules étroitement imbriqués !

   Cependant il y a toujours des possibilités que l’entreprise fasse une modification ultérieure sur le
module certifié. Il revient donc au chef de projet d’interdire, dans une clause contractuelle - entre lui
et la maîtrise d’ouvrage - l’ajout de modules non certifiés aux modules que son équipe aurait
développé. Ceci afin de s’assurer que les évolutions fonctionnelles et/ou techniques des modules
livrés suivront la même courbe qualité que leur développement initial.

   Plus encore, il lui revient aussi d’exiger avant tout développement que l’ensemble des modules
dont pourraient dépendre son module soient certifiés ! Agissant ainsi tel un conducteur qui conduit
avec prudence sur la route en prenant tout d’abord soin de son véhicule puis en respectant le code
de la route mais surtout en étant vigilant. En effet, ce conducteur, même s’il prend toutes ses
précautions, n’est pas sûr qu’un automobiliste tierce ne vienne le mettre en danger. On comprend à
travers cette métaphore du conducteur et de la voiture l’importance d’exiger des modules certifiés
de bout en bout.

   En somme, le processus de certification ne résout pas totalement le problème d’intégration des
modules mais en limite nettement les effets néfastes. Nextma pourrait donc penser à certifier ses
modules. Ceci pourrait lui permettre, par ailleurs, de supplanter les différentes sociétés opérant
dans le même secteur à l’échelle nationale mais aussi de contribuer à sa notoriété sur le plan
international. Ceci à travers la visibilité qu’elle pourrait acquérir par la certification de modules et
l’intégration de ces derniers à la suite logicielle.

   La certification serait donc un élément important à ne pas négliger dans tous les aspects de son
projet. Cependant, il y a un hic: “The only limitation is that if a bug or a problem in the migrations
results from changes which happened after the certification, they will not be covered by the bugfix
guarantee.” [w5] Autrement dit, après le processus de certification, si un bug survient malgré tout,
Open ERP ne le prend pas en charge. Ce qui nous ramènerait au problème de départ !




N.AKADIRI                                                                                       Page 41
Enfin, de façon plus générale, n’oublions pas que parler d’une démarche qualité revient à parler
d’une application de la qualité à tous les processus entrant en jeu au niveau de Nextma -
établissement du cahier des charges, recrutement des développeurs…Ainsi, mettre en place une
démarche qualité reviendrait, outre l’aspect certification, à favoriser au niveau de l’équipe projet –
et de façon plus globale au niveau de l’entreprise – l’émergence de nouvelles méthodes
organisationnelles, techniques, managériales et autres permettant d’améliorer la qualité des
développements de modules. Ceci entrainera inéluctablement une maintenance des modules moins
« lourde » et donc pourra résoudre le problème d’intégration des modules – principalement dans
leur aspect évolutif.

            6- Cycle de vie préconisé
   Bien que cette partie aurait bien pu être mise en tête de la section « Démarche améliorée de
gestion de projet », je l’ai volontairement mise à la fin car quoique l’on puisse dire, le cycle de vie
s’adopte non seulement en fonction de certains paramètres (risques, maturité de l’équipe…) mais
surtout en fonction du terrain.
   Le choix est donc laissé au chef de projet de faire jouer son ingéniosité ou son expérience sur son
projet qui devra conduire à une meilleure intégration des modules. Nonobstant ce constat, je me
permets de préconiser un cycle que je trouve plus adéquat.

   De mon point de vue, l’adoption de méthodes agiles pourrait permettre de produire des modules
plus adaptatifs. Soyons clair ; je ne viens pas ici faire l’apologie des méthodes agiles, non pas que je
les dénigre mais je reste pragmatique. En effet, les méthodes adoptées en général pour les projets ne
sont pas forcément mauvaises en soit mais c’est l’usage qui en est fait qui pose généralement
problème. Il en est de même pour les méthodes agiles. Voyons à présent, quels ont été les principes
fondateurs de ces méthodes dites agiles.

   Suite à des constats récurrents de mauvaise définition de besoins, de manque de communication
entre les différentes entités d’un projet, de l’augmentation du nombre de projet à effet tunnel, des
experts se sont regroupés afin de proposer des solutions adéquates. Ainsi, sont nées les méthodes
agiles. Ces dernières s’axent autour de 4 valeurs principales qui privilégient, comme le mentionne le
manifeste agile [w6] :

   -   Les individus et leurs interactions plus que les processus et les outils.
   -   Des logiciels opérationnels plus qu’une documentation exhaustive.
   -   La collaboration avec les clients plus que la négociation contractuelle.
   -   L’adaptation au changement plus que le suivi d’un plan.




N.AKADIRI                                                                                       Page 42
L’utilisation d’une méthode en particulier des méthodes agiles pourrait augmenter la qualité – au
sens large - du contrôle des modules.

   Nous avons donc vu que les quatre valeurs fondatrices des méthodes agiles donnent priorité aux
individus et aux interactions, aux logiciels opérationnels, à la collaboration étroite avec le client et à
une adaptation face au changement.

   Dans notre cas, la deuxième et la quatrième valeur créent plus de problèmes qu’ils n’en
résolvent.

   En effet, faut-il effectivement privilégier des modules fonctionnels à une documentation
exhaustive ? Si le but est de produire des modules sans les rendre au maximum évolutifs – comme à
l’accoutumée - alors oui ! Car la documentation minimale peut être appréciée dans ce cas. Or, nous
sommes dans une perspective où nous souhaitons produire des modules plus évolutifs. On
comprend donc aisément que la documentation dans une telle situation est de rigueur. Bien plus
encore, elle se soit d’être la plus exhaustive que possible.

   Quant à la quatrième valeur qui préconise une réactivité face aux éventuels changements - en
cours de projet - du client, nous sommes réticents à cette idée. Car, selon les dires d’un collègue, il
y aurait un projet de développement de module en cours actuellement à Nextma qui aurait dû
prendre fin il y a de cela bien longtemps mais qui ne cesse d’être repousser aux calendes grecques.
Pour cause, les besoins sans cesse renouvelés du client lors de la phase de recette. Il est donc plus
judicieux d’établir un PV explicite des besoins pour éviter de rallonger les délais qui sont déjà assez
durs à tenir. Ainsi chaque nouvelle demande fera l’ajout d’une prestation individuelle.

   En résumé, pour développer des modules hautement évolutifs, on peut faire de l’agile tout en
restant lucide !

    D- Synthèse
1- Que retenir ?
   Que de choses ont été dites. Si vous vous sentez perdu et ne savez plus où donner de la tête, c’est
le moment de faire le point.

   Il a été tout d’abord exposé le concept d’ERP puis celui de la relation étroite qu’entretiennent les
entreprises avec ce genre d’outils. Dans le même ordre d’idée, nous avons vu qu’Open ERP comme
ses confrères d’ERP est un véritable joyau d’entreprise, car d’une utilité évidente pour les acteurs -




N.AKADIRI                                                                                        Page 43
aussi bien interne qu’externes - de l’entreprise. Son paramétrage sur mesure permet d’adapter son
ERP à chaque entreprise.

   Cependant, ce paramétrage n’est pas infini. Et lorsque les limites sont atteintes, on tire profit
d’un autre aspect de l’ERP qui est son architecture modulaire. Mais là encore les déconvenues
surviennent relativement tôt. En effet lors de la migration de version, certains modules deviennent
désuets.

   Alors, entre besoin de migrer et besoin de maintenir la cohérence d’ensemble de ses modules,
l’entreprise fait face à un dilemme qui n’est toutefois pas totalement insolvable.

   Une solution toute simple serait d’apprendre à ne migrer qu’en cas d’extrêmes besoins et non
pour une propension à « être à la page ». Si malgré tout le besoin s’en fait sentir et qu’on a plus le
choix alors il faut prendre des précautions.

   Précautions qui débutent depuis la phase de gestion du projet. Ce sont ces précautions que j’ai
tenté d’énumérer dans les pages précédentes. Elles s’axent principalement autour de deux points :

   -   le choix de la méthode de gestion de projet
   -   la certification de modules (important)

   La certification, comme nous avons pu le voir, ne résout pas totalement le problème mais
permet de délocaliser la charge de travail en un seul endroit : Au niveau de l’éditeur – qui à priori
connaît mieux son logiciel - et non plus au niveau de l’équipe projet. Ceci permet donc de masquer
la problématique d’évolutivité des modules.




                                   Figure 20 : Synthèse Réflexion




N.AKADIRI                                                                                     Page 44
Ces aspects d’ordre managériaux et techniques à mettre en place au niveau de Nextma doivent
s’accompagner d’autres aspects tout aussi importants – car servant de pilier à la démarche - que
sont : les aspects juridictionnels (interdiction d’ajout de modules non certifié, définition formelle et
définitive des besoins…). Ces clauses contractuelles établies de façon appropriée aideront le chef
de projet à garantir la pérennité de ses modules dans le temps.

   Enfin, il a été préconisé qu’un cycle de vie reposant sur les méthodes dites agiles soit adopté. En
effet, nous avons vu plus haut que le choix du cycle de vie est dicté par tout un ensemble de critères
notamment sur le critère expérience du chef de projet. Des recommandations ont cependant été
faites pour l’adoption de méthodes agiles par Nextma lors de leur gestion de projet de
développement de modules. Choix qui semble plus opportun en raison de la forte réactivité
qu’exige ce genre de méthodes avec le client.

2- Limites de ma réflexion
   On a donc essayé dans les lignes qui ont précédé de faire une synthèse des points clés à cibler
pour améliorer l’efficacité de la démarche de gestion de projet au niveau de Nextma en vue de
conduire à des modules adaptatifs et évolutifs. Cependant l’honnêteté intellectuelle exige de moi
que je vous fasse à présent part des problèmes que peuvent soulever tout ce que j’ai eu à dire.

   En tout premier lieu, Cette démarche ne s’applique qu’au développement de modules complexes
et plus encore aux sociétés possédant un effectif élevé pouvant être affecté à un projet de
développement de modules. Inutile de faire une usine à gaz pour développer un module basique ! Je
pense donc que les points énoncés plus haut pour améliorer la démarche de gestion de projet ne
pourront être réellement appliqués par Nextma que lorsqu’elle disposera d’un effectif bien plus
conséquent. Pour s’en convaincre il suffit de se rappeler de ma proposition d’investir dans la R&D.
Demander à une entreprise telle que Nextma ne disposant pas de ressources – humaines,
financières…- colossales de prendre ce risque est un pari osé.

   Par ailleurs, la certification de modules qui représente indéniablement un atout peut très vite être
synonyme de baisse de revenus pour certains. En effet, il est indéniable qu’une telle certification
puisse faire grincer des dents bon nombre d’entreprises – dont probablement Nextma -                qui
« vivent » de cette adaptation constante de ces modules. Car une telle affaire, bien qu’utile, risque
de sonner le glas de leur commerce prolifique. Alors entre la théorie et la pratique, le fossé risque
d’être abyssal.

   N’oublions pas non plus que, demander au chef de projet de s’assurer que l’ensemble des
modules dont pourrait dépendre son projet soit certifié, quitte à ne pas s’engager sur un projet



N.AKADIRI                                                                                       Page 45
« juteux », risque de ne pas être toujours chose facile à faire…Et quand bien même les entreprises –
en particulier Nextma - trouveront l’importance de certifier, la limitation dans le contrat de
maintenance d’Open ERP poserait encore un problème. En effet, le processus de certification du
module peut ne pas déceler des problèmes qui se révèleront bien plus tard. Scénario qui nous
conduirait inéluctablement à dépenser à nouveau en coût et en argent…

   Concernant le cycle de vie, bien que la réactivité soit un point essentielle dans l’application des
méthodes agiles, j’ai voulu restreindre un tant soit peu cette réactivité qui donne par exemple au
client la possibilité de changer au besoin le contenu du cahier des charges. En effet, laisser le client
donner libre cours à ses désirs ou plutôt à ses caprices, c’est aussi lui donner la possibilité de mettre
en péril la budgétisation d’un projet qui prend en compte la certification des modules et par
conséquent annihiler tous les efforts qui auront pu être mis en place pour permettre une meilleure
adaptabilité et évolutivité des modules. Ce n’est donc plus une méthode agile a proprement parlé
qui a été recommandé à Nextma mais plutôt une méthode pseudo-agile car ne prenant pas en
compte tous les principes fondateurs des méthodes agiles.

   Notons enfin qu’étant resté dans la logique que Nextma ne soustraite pas une partie de ses
développements, l’ensemble des six recommandations formulées – Gestion de changement,
démarche qualité…- est encore un tant soit peu faisable. Mais si Nextma se décide, dans un avenir
proche ou lointain, pour une raison ou pour une autre à sous-traiter une partie de ses
développements, un niveau de complexité supérieure s’ajoutera car il faudra effectuer le suivi des
recommandations susmentionnées chez tous le ou le(s) sous-traitant(s)…




N.AKADIRI                                                                                       Page 46
Partie 6 : Bilan


   Si c’était à refaire, qu’aurai-je fais, quelles sont les leçons que j’ai pu en tirer ? En ce sens, Nick
Nolte disait : «J'ai commis bon nombre d'erreurs mais je n'ai aucun regret. Parfois c'est le seul
moyen d'apprendre.». Cette pensée résume bien le contenu auquel on peut s’attendre dans cette
dernière partie.

       A- Bilan technique
   Tous mes stages au cours de ces trois dernières années m’ont permis de m’imprégner du
processus courant de développement d’un logiciel : de l’analyse des besoins à l’implantation du
logiciel en passant par la phase de modélisation.

   Durant ce stage, bien qu’ayant étudié d’une façon ou d’une autre des modèles (analyse des
interactions des modèles de l’ERP) ou fait de la modélisation (base de données en local sur le
portable), j’ai pu noter une petite différence. Dans le sens où j’ai été amené à comprendre une
architecture déjà existante (celle d’Open ERP) afin de m’y conformer. Je pense que cela est plus
proche de la réalité des projets informatiques dans les entreprises où l’on n’a pas toujours la
possibilité de concevoir une solution à partir de « zéro» tel qu’on le fait souvent lors des travaux
pratiques à l’école.

   Aussi, à travers ce stage, j’ai pu me refaire une idée sur les Framework. En effet, ces outils de
rêve qui sont de véritables bijoux de programmation impressionnent de par leurs prestations.
Cependant, quand on se met à les utiliser allègrement, sans s’être imprégné de toute la mécanique
qui se cache derrière - ce qui est le cas de la majorité des développeurs - cela peut causer à la
longue un problème - dans la formation des développeurs. Ces derniers perdront ainsi
progressivement les connaissances de base de la programmation et/ou de certains langages car
voilées par le Framework.

   Dans le même ordre d’idée, les API, du genre Google Maps Api, mises souvent à la disposition
des développeurs sont utiles mais dès qu’elles subissent une restructuration profonde de l’éditeur,
on peut être contraint à revoir toute son application !

   Par ailleurs, comme je le mentionnais dans ma lettre de motivation lors de la recherche du stage,
au cours des deux stages précédents - l’un en DUT Informatique et l’autre en licence Miage - j’ai
eu à développer respectivement un client léger (utilise un navigateur internet) et un client lourd
(application de bureau). Je souhaitais donc m’investir dans le développement d’une application




N.AKADIRI                                                                                        Page 47
Android openerp nextma
Android openerp nextma
Android openerp nextma
Android openerp nextma
Android openerp nextma
Android openerp nextma

Contenu connexe

Tendances

Etude critique et amélioration de la gestion de la performance du service mai...
Etude critique et amélioration de la gestion de la performance du service mai...Etude critique et amélioration de la gestion de la performance du service mai...
Etude critique et amélioration de la gestion de la performance du service mai...darckdaxter
 
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webRapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webSalma Gouia
 
Application web Gestion RH ASP.NET MVC5
Application web Gestion RH ASP.NET MVC5Application web Gestion RH ASP.NET MVC5
Application web Gestion RH ASP.NET MVC5YounessLaaouane
 
Mémoire de Projet de Fin d’Etudes
Mémoire de Projet de Fin d’EtudesMémoire de Projet de Fin d’Etudes
Mémoire de Projet de Fin d’EtudesAicha OUALLA
 
rapport fin d'etude
rapport fin d'etuderapport fin d'etude
rapport fin d'etudesihem-med
 
Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...Ahmed Makni
 
Rapport de stage d'initiation 2015 Mahmoudi Mohamed Amine
Rapport de stage d'initiation 2015 Mahmoudi Mohamed AmineRapport de stage d'initiation 2015 Mahmoudi Mohamed Amine
Rapport de stage d'initiation 2015 Mahmoudi Mohamed AmineMohamed Amine Mahmoudi
 
Rapport stage
Rapport stageRapport stage
Rapport stageTECOS
 
Rapport de stage d'été
Rapport de stage d'étéRapport de stage d'été
Rapport de stage d'étéJinenAbdelhak
 
Medical openerp
Medical openerpMedical openerp
Medical openerpHORIYASOFT
 
Pour Écrire un Bon Rapport en Informatique
Pour Écrire un Bon Rapport en InformatiquePour Écrire un Bon Rapport en Informatique
Pour Écrire un Bon Rapport en InformatiqueLilia Sfaxi
 
rapport de stage
rapport de stagerapport de stage
rapport de stageMarouane Gh
 
Gestion programme moussanada avec openerp
Gestion programme moussanada avec openerpGestion programme moussanada avec openerp
Gestion programme moussanada avec openerpHORIYASOFT
 
Rapport Stage Capgemini Otmane DOUIEB
Rapport Stage Capgemini Otmane DOUIEBRapport Stage Capgemini Otmane DOUIEB
Rapport Stage Capgemini Otmane DOUIEBOtmaneDouieb
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITLina Meddeb
 
Rapport de projet de fin d’étude
Rapport  de projet de fin d’étudeRapport  de projet de fin d’étude
Rapport de projet de fin d’étudeOumaimaOuedherfi
 
Mesure de la performance du SI de camtel nguimo hermann 5.0
Mesure de la performance du SI de camtel  nguimo hermann 5.0Mesure de la performance du SI de camtel  nguimo hermann 5.0
Mesure de la performance du SI de camtel nguimo hermann 5.0Hermann NGUIMO
 

Tendances (20)

Etude critique et amélioration de la gestion de la performance du service mai...
Etude critique et amélioration de la gestion de la performance du service mai...Etude critique et amélioration de la gestion de la performance du service mai...
Etude critique et amélioration de la gestion de la performance du service mai...
 
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webRapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
 
Rapport de PFE
Rapport de PFERapport de PFE
Rapport de PFE
 
Application web Gestion RH ASP.NET MVC5
Application web Gestion RH ASP.NET MVC5Application web Gestion RH ASP.NET MVC5
Application web Gestion RH ASP.NET MVC5
 
Mémoire de Projet de Fin d’Etudes
Mémoire de Projet de Fin d’EtudesMémoire de Projet de Fin d’Etudes
Mémoire de Projet de Fin d’Etudes
 
rapport fin d'etude
rapport fin d'etuderapport fin d'etude
rapport fin d'etude
 
Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...
 
Rapport de stage d'initiation 2015 Mahmoudi Mohamed Amine
Rapport de stage d'initiation 2015 Mahmoudi Mohamed AmineRapport de stage d'initiation 2015 Mahmoudi Mohamed Amine
Rapport de stage d'initiation 2015 Mahmoudi Mohamed Amine
 
Rapport stage
Rapport stageRapport stage
Rapport stage
 
Rapport stage
Rapport stageRapport stage
Rapport stage
 
Rapport de stage d'été
Rapport de stage d'étéRapport de stage d'été
Rapport de stage d'été
 
Medical openerp
Medical openerpMedical openerp
Medical openerp
 
Pour Écrire un Bon Rapport en Informatique
Pour Écrire un Bon Rapport en InformatiquePour Écrire un Bon Rapport en Informatique
Pour Écrire un Bon Rapport en Informatique
 
rapport de stage
rapport de stagerapport de stage
rapport de stage
 
Gestion programme moussanada avec openerp
Gestion programme moussanada avec openerpGestion programme moussanada avec openerp
Gestion programme moussanada avec openerp
 
Rapport Stage Capgemini Otmane DOUIEB
Rapport Stage Capgemini Otmane DOUIEBRapport Stage Capgemini Otmane DOUIEB
Rapport Stage Capgemini Otmane DOUIEB
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
 
Rapport de projet de fin d’étude
Rapport  de projet de fin d’étudeRapport  de projet de fin d’étude
Rapport de projet de fin d’étude
 
Rapport de stage
Rapport de stageRapport de stage
Rapport de stage
 
Mesure de la performance du SI de camtel nguimo hermann 5.0
Mesure de la performance du SI de camtel  nguimo hermann 5.0Mesure de la performance du SI de camtel  nguimo hermann 5.0
Mesure de la performance du SI de camtel nguimo hermann 5.0
 

En vedette

Methodology for Establishing a System of Free Software in Health in a Morocca...
Methodology for Establishing a System of Free Software in Health in a Morocca...Methodology for Establishing a System of Free Software in Health in a Morocca...
Methodology for Establishing a System of Free Software in Health in a Morocca...HORIYASOFT
 
Openerp à la poste maroc
Openerp à la poste marocOpenerp à la poste maroc
Openerp à la poste marocHORIYASOFT
 
Gnuhealth at Software Freedom Day Casablanca 2016
Gnuhealth at Software Freedom Day Casablanca 2016Gnuhealth at Software Freedom Day Casablanca 2016
Gnuhealth at Software Freedom Day Casablanca 2016HORIYASOFT
 
Les Logiciels Libres sont ils plus sécurisés que les Logiciels Propriétaires ?
Les Logiciels Libres sont ils plus sécurisés que les Logiciels Propriétaires ?Les Logiciels Libres sont ils plus sécurisés que les Logiciels Propriétaires ?
Les Logiciels Libres sont ils plus sécurisés que les Logiciels Propriétaires ?HORIYASOFT
 
生死學期末報告
生死學期末報告生死學期末報告
生死學期末報告Allen
 
Odoopriting opendays2014
Odoopriting opendays2014Odoopriting opendays2014
Odoopriting opendays2014HORIYASOFT
 
Ignite CASABLANCA 2010l
Ignite CASABLANCA 2010lIgnite CASABLANCA 2010l
Ignite CASABLANCA 2010lHORIYASOFT
 
Comptabilité SYSCOA avec Odoo V8
Comptabilité SYSCOA avec Odoo V8Comptabilité SYSCOA avec Odoo V8
Comptabilité SYSCOA avec Odoo V8HORIYASOFT
 
Openerp pour les grossistes de médicament
Openerp pour les grossistes de médicamentOpenerp pour les grossistes de médicament
Openerp pour les grossistes de médicamentHORIYASOFT
 
Amélioration du système de gestion de transport avec Open tms
Amélioration du système de gestion de transport avec Open tmsAmélioration du système de gestion de transport avec Open tms
Amélioration du système de gestion de transport avec Open tmsHORIYASOFT
 
gestion de notariat avec openerp
gestion de notariat avec openerpgestion de notariat avec openerp
gestion de notariat avec openerpHORIYASOFT
 
Migration gmao de openerp 6.1 vers odoo 8
Migration gmao de openerp 6.1 vers odoo 8Migration gmao de openerp 6.1 vers odoo 8
Migration gmao de openerp 6.1 vers odoo 8HORIYASOFT
 
Gestion d"une société de transit avec openerp
Gestion d"une société de transit avec openerpGestion d"une société de transit avec openerp
Gestion d"une société de transit avec openerpHORIYASOFT
 

En vedette (13)

Methodology for Establishing a System of Free Software in Health in a Morocca...
Methodology for Establishing a System of Free Software in Health in a Morocca...Methodology for Establishing a System of Free Software in Health in a Morocca...
Methodology for Establishing a System of Free Software in Health in a Morocca...
 
Openerp à la poste maroc
Openerp à la poste marocOpenerp à la poste maroc
Openerp à la poste maroc
 
Gnuhealth at Software Freedom Day Casablanca 2016
Gnuhealth at Software Freedom Day Casablanca 2016Gnuhealth at Software Freedom Day Casablanca 2016
Gnuhealth at Software Freedom Day Casablanca 2016
 
Les Logiciels Libres sont ils plus sécurisés que les Logiciels Propriétaires ?
Les Logiciels Libres sont ils plus sécurisés que les Logiciels Propriétaires ?Les Logiciels Libres sont ils plus sécurisés que les Logiciels Propriétaires ?
Les Logiciels Libres sont ils plus sécurisés que les Logiciels Propriétaires ?
 
生死學期末報告
生死學期末報告生死學期末報告
生死學期末報告
 
Odoopriting opendays2014
Odoopriting opendays2014Odoopriting opendays2014
Odoopriting opendays2014
 
Ignite CASABLANCA 2010l
Ignite CASABLANCA 2010lIgnite CASABLANCA 2010l
Ignite CASABLANCA 2010l
 
Comptabilité SYSCOA avec Odoo V8
Comptabilité SYSCOA avec Odoo V8Comptabilité SYSCOA avec Odoo V8
Comptabilité SYSCOA avec Odoo V8
 
Openerp pour les grossistes de médicament
Openerp pour les grossistes de médicamentOpenerp pour les grossistes de médicament
Openerp pour les grossistes de médicament
 
Amélioration du système de gestion de transport avec Open tms
Amélioration du système de gestion de transport avec Open tmsAmélioration du système de gestion de transport avec Open tms
Amélioration du système de gestion de transport avec Open tms
 
gestion de notariat avec openerp
gestion de notariat avec openerpgestion de notariat avec openerp
gestion de notariat avec openerp
 
Migration gmao de openerp 6.1 vers odoo 8
Migration gmao de openerp 6.1 vers odoo 8Migration gmao de openerp 6.1 vers odoo 8
Migration gmao de openerp 6.1 vers odoo 8
 
Gestion d"une société de transit avec openerp
Gestion d"une société de transit avec openerpGestion d"une société de transit avec openerp
Gestion d"une société de transit avec openerp
 

Similaire à Android openerp nextma

546005863-Mon-Rapport-Stage-Technicien-Version-Final.pdf
546005863-Mon-Rapport-Stage-Technicien-Version-Final.pdf546005863-Mon-Rapport-Stage-Technicien-Version-Final.pdf
546005863-Mon-Rapport-Stage-Technicien-Version-Final.pdfMrShady1
 
Rapport Stage Alstom Otmane Douieb
Rapport Stage Alstom Otmane DouiebRapport Stage Alstom Otmane Douieb
Rapport Stage Alstom Otmane DouiebOtmaneDouieb
 
Plan d'affaires
Plan d'affairesPlan d'affaires
Plan d'affairesproviseur
 
Guide iphone dce solutions
Guide iphone dce solutionsGuide iphone dce solutions
Guide iphone dce solutionsDCE Solutions
 
Cours processus- production
Cours processus- productionCours processus- production
Cours processus- productionAmine Chahed
 
Rapport de stage - gestion commerciale @REC MEDIA
Rapport de stage - gestion commerciale @REC MEDIARapport de stage - gestion commerciale @REC MEDIA
Rapport de stage - gestion commerciale @REC MEDIAREDOUANIAbdessamad
 
Open a New Fast-food in Maastricht, The Netherlands? (FRE
Open a New Fast-food in Maastricht, The Netherlands? (FREOpen a New Fast-food in Maastricht, The Netherlands? (FRE
Open a New Fast-food in Maastricht, The Netherlands? (FREDeWinterP
 
Module 6 dossier final en pdf
Module 6 dossier final en pdfModule 6 dossier final en pdf
Module 6 dossier final en pdfDeWinterP
 
Guide des formations et des aides individuelles régionales du Sanitaire et So...
Guide des formations et des aides individuelles régionales du Sanitaire et So...Guide des formations et des aides individuelles régionales du Sanitaire et So...
Guide des formations et des aides individuelles régionales du Sanitaire et So...Handirect 05
 
La gestion prévisionnelle de l’entreprise : Outil d’aide à la décision
La gestion prévisionnelle de l’entreprise : Outil d’aide à la décisionLa gestion prévisionnelle de l’entreprise : Outil d’aide à la décision
La gestion prévisionnelle de l’entreprise : Outil d’aide à la décisionJadroun Sofiane
 
Mode d'emploi multicuiseur 4 en 1 Cuisinart msc600e - Notice
Mode d'emploi multicuiseur 4 en 1 Cuisinart msc600e - NoticeMode d'emploi multicuiseur 4 en 1 Cuisinart msc600e - Notice
Mode d'emploi multicuiseur 4 en 1 Cuisinart msc600e - Noticehabiague
 
JOB NETWORK - Réseau social collaboratif d’emploi
JOB NETWORK - Réseau social collaboratif d’emploiJOB NETWORK - Réseau social collaboratif d’emploi
JOB NETWORK - Réseau social collaboratif d’emploiYoussef NIDABRAHIM
 
Optimisation d'une stratégie web éditoriale
Optimisation d'une stratégie web éditorialeOptimisation d'une stratégie web éditoriale
Optimisation d'une stratégie web éditorialeDamien Mady
 
Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .Oussama Ben Sghaier
 
Guide pratqiue de recolte Fonds
Guide pratqiue de recolte FondsGuide pratqiue de recolte Fonds
Guide pratqiue de recolte FondsREALIZ
 

Similaire à Android openerp nextma (20)

546005863-Mon-Rapport-Stage-Technicien-Version-Final.pdf
546005863-Mon-Rapport-Stage-Technicien-Version-Final.pdf546005863-Mon-Rapport-Stage-Technicien-Version-Final.pdf
546005863-Mon-Rapport-Stage-Technicien-Version-Final.pdf
 
Rapport Stage Alstom Otmane Douieb
Rapport Stage Alstom Otmane DouiebRapport Stage Alstom Otmane Douieb
Rapport Stage Alstom Otmane Douieb
 
Rapport stage pact13
Rapport stage pact13Rapport stage pact13
Rapport stage pact13
 
PROJET JAVA BD MySQL
PROJET JAVA BD MySQLPROJET JAVA BD MySQL
PROJET JAVA BD MySQL
 
Bp nespresso efficienza-1
Bp nespresso efficienza-1Bp nespresso efficienza-1
Bp nespresso efficienza-1
 
Plan d'affaires
Plan d'affairesPlan d'affaires
Plan d'affaires
 
Guide iphone dce solutions
Guide iphone dce solutionsGuide iphone dce solutions
Guide iphone dce solutions
 
Rapport Projet Fin d'Études PFE
Rapport Projet Fin d'Études PFERapport Projet Fin d'Études PFE
Rapport Projet Fin d'Études PFE
 
MONITORING APPLICATIF
MONITORING APPLICATIFMONITORING APPLICATIF
MONITORING APPLICATIF
 
Cours processus- production
Cours processus- productionCours processus- production
Cours processus- production
 
Rapport de stage - gestion commerciale @REC MEDIA
Rapport de stage - gestion commerciale @REC MEDIARapport de stage - gestion commerciale @REC MEDIA
Rapport de stage - gestion commerciale @REC MEDIA
 
Open a New Fast-food in Maastricht, The Netherlands? (FRE
Open a New Fast-food in Maastricht, The Netherlands? (FREOpen a New Fast-food in Maastricht, The Netherlands? (FRE
Open a New Fast-food in Maastricht, The Netherlands? (FRE
 
Module 6 dossier final en pdf
Module 6 dossier final en pdfModule 6 dossier final en pdf
Module 6 dossier final en pdf
 
Guide des formations et des aides individuelles régionales du Sanitaire et So...
Guide des formations et des aides individuelles régionales du Sanitaire et So...Guide des formations et des aides individuelles régionales du Sanitaire et So...
Guide des formations et des aides individuelles régionales du Sanitaire et So...
 
La gestion prévisionnelle de l’entreprise : Outil d’aide à la décision
La gestion prévisionnelle de l’entreprise : Outil d’aide à la décisionLa gestion prévisionnelle de l’entreprise : Outil d’aide à la décision
La gestion prévisionnelle de l’entreprise : Outil d’aide à la décision
 
Mode d'emploi multicuiseur 4 en 1 Cuisinart msc600e - Notice
Mode d'emploi multicuiseur 4 en 1 Cuisinart msc600e - NoticeMode d'emploi multicuiseur 4 en 1 Cuisinart msc600e - Notice
Mode d'emploi multicuiseur 4 en 1 Cuisinart msc600e - Notice
 
JOB NETWORK - Réseau social collaboratif d’emploi
JOB NETWORK - Réseau social collaboratif d’emploiJOB NETWORK - Réseau social collaboratif d’emploi
JOB NETWORK - Réseau social collaboratif d’emploi
 
Optimisation d'une stratégie web éditoriale
Optimisation d'une stratégie web éditorialeOptimisation d'une stratégie web éditoriale
Optimisation d'une stratégie web éditoriale
 
Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .
 
Guide pratqiue de recolte Fonds
Guide pratqiue de recolte FondsGuide pratqiue de recolte Fonds
Guide pratqiue de recolte Fonds
 

Plus de HORIYASOFT

gnuhealthcon2022_abdrahman.pdf
gnuhealthcon2022_abdrahman.pdfgnuhealthcon2022_abdrahman.pdf
gnuhealthcon2022_abdrahman.pdfHORIYASOFT
 
Deployed eHealth solutions in Morocco_ ELKAFIL_MOROCCO.pptx
Deployed eHealth solutions in Morocco_ ELKAFIL_MOROCCO.pptxDeployed eHealth solutions in Morocco_ ELKAFIL_MOROCCO.pptx
Deployed eHealth solutions in Morocco_ ELKAFIL_MOROCCO.pptxHORIYASOFT
 
Hackaton euvsvirus-gnuhealth-federation
Hackaton euvsvirus-gnuhealth-federationHackaton euvsvirus-gnuhealth-federation
Hackaton euvsvirus-gnuhealth-federationHORIYASOFT
 
7 Conseils pour mettre en place un ERP dans votre entreprise
7 Conseils pour mettre en place un ERP dans votre entreprise7 Conseils pour mettre en place un ERP dans votre entreprise
7 Conseils pour mettre en place un ERP dans votre entrepriseHORIYASOFT
 
Telemedecine au maroc
Telemedecine au marocTelemedecine au maroc
Telemedecine au marocHORIYASOFT
 
Gestion Paie marocaine et RH avec openerp
Gestion Paie marocaine et RH avec openerpGestion Paie marocaine et RH avec openerp
Gestion Paie marocaine et RH avec openerpHORIYASOFT
 
Mise en conformité_module_finance_maroc
Mise en conformité_module_finance_marocMise en conformité_module_finance_maroc
Mise en conformité_module_finance_marocHORIYASOFT
 
Gestion de la_production_agricole_avec_openerp
Gestion de la_production_agricole_avec_openerpGestion de la_production_agricole_avec_openerp
Gestion de la_production_agricole_avec_openerpHORIYASOFT
 
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrierGestion flotte acheminement_courrier
Gestion flotte acheminement_courrierHORIYASOFT
 
Projet tempus mission openerp
Projet tempus mission openerpProjet tempus mission openerp
Projet tempus mission openerpHORIYASOFT
 
Gestion de la paie maroc avec openerp 7
Gestion de la paie maroc avec openerp 7 Gestion de la paie maroc avec openerp 7
Gestion de la paie maroc avec openerp 7 HORIYASOFT
 
Plonegov projet egov
Plonegov projet egov Plonegov projet egov
Plonegov projet egov HORIYASOFT
 
Opentms nextma
Opentms nextmaOpentms nextma
Opentms nextmaHORIYASOFT
 
Strategic dimensions-of-free-and-open source-software-arabic
Strategic dimensions-of-free-and-open source-software-arabicStrategic dimensions-of-free-and-open source-software-arabic
Strategic dimensions-of-free-and-open source-software-arabicHORIYASOFT
 
ADAPTATION ET INTEGRATION D’OPENERP POUR LA GESTION D’OFFICINE
ADAPTATION ET INTEGRATION D’OPENERP POUR LA GESTION D’OFFICINEADAPTATION ET INTEGRATION D’OPENERP POUR LA GESTION D’OFFICINE
ADAPTATION ET INTEGRATION D’OPENERP POUR LA GESTION D’OFFICINEHORIYASOFT
 
Implémentation d’une solution de géolocalisation des véhicules basée sur open...
Implémentation d’une solution de géolocalisation des véhicules basée sur open...Implémentation d’une solution de géolocalisation des véhicules basée sur open...
Implémentation d’une solution de géolocalisation des véhicules basée sur open...HORIYASOFT
 
Ce que perd le Maroc en ignorant le Logiciel Libre dans sa stratégie NTIC
Ce que perd le Maroc en ignorant le Logiciel Libre dans sa stratégie NTICCe que perd le Maroc en ignorant le Logiciel Libre dans sa stratégie NTIC
Ce que perd le Maroc en ignorant le Logiciel Libre dans sa stratégie NTICHORIYASOFT
 
5 ans de openerp au maroc : retour d'expériences
5 ans de openerp au maroc : retour d'expériences5 ans de openerp au maroc : retour d'expériences
5 ans de openerp au maroc : retour d'expériencesHORIYASOFT
 
Conception d'un module de gestion de la paie adapté au contexte marocain pour...
Conception d'un module de gestion de la paie adapté au contexte marocain pour...Conception d'un module de gestion de la paie adapté au contexte marocain pour...
Conception d'un module de gestion de la paie adapté au contexte marocain pour...HORIYASOFT
 

Plus de HORIYASOFT (19)

gnuhealthcon2022_abdrahman.pdf
gnuhealthcon2022_abdrahman.pdfgnuhealthcon2022_abdrahman.pdf
gnuhealthcon2022_abdrahman.pdf
 
Deployed eHealth solutions in Morocco_ ELKAFIL_MOROCCO.pptx
Deployed eHealth solutions in Morocco_ ELKAFIL_MOROCCO.pptxDeployed eHealth solutions in Morocco_ ELKAFIL_MOROCCO.pptx
Deployed eHealth solutions in Morocco_ ELKAFIL_MOROCCO.pptx
 
Hackaton euvsvirus-gnuhealth-federation
Hackaton euvsvirus-gnuhealth-federationHackaton euvsvirus-gnuhealth-federation
Hackaton euvsvirus-gnuhealth-federation
 
7 Conseils pour mettre en place un ERP dans votre entreprise
7 Conseils pour mettre en place un ERP dans votre entreprise7 Conseils pour mettre en place un ERP dans votre entreprise
7 Conseils pour mettre en place un ERP dans votre entreprise
 
Telemedecine au maroc
Telemedecine au marocTelemedecine au maroc
Telemedecine au maroc
 
Gestion Paie marocaine et RH avec openerp
Gestion Paie marocaine et RH avec openerpGestion Paie marocaine et RH avec openerp
Gestion Paie marocaine et RH avec openerp
 
Mise en conformité_module_finance_maroc
Mise en conformité_module_finance_marocMise en conformité_module_finance_maroc
Mise en conformité_module_finance_maroc
 
Gestion de la_production_agricole_avec_openerp
Gestion de la_production_agricole_avec_openerpGestion de la_production_agricole_avec_openerp
Gestion de la_production_agricole_avec_openerp
 
Gestion flotte acheminement_courrier
Gestion flotte acheminement_courrierGestion flotte acheminement_courrier
Gestion flotte acheminement_courrier
 
Projet tempus mission openerp
Projet tempus mission openerpProjet tempus mission openerp
Projet tempus mission openerp
 
Gestion de la paie maroc avec openerp 7
Gestion de la paie maroc avec openerp 7 Gestion de la paie maroc avec openerp 7
Gestion de la paie maroc avec openerp 7
 
Plonegov projet egov
Plonegov projet egov Plonegov projet egov
Plonegov projet egov
 
Opentms nextma
Opentms nextmaOpentms nextma
Opentms nextma
 
Strategic dimensions-of-free-and-open source-software-arabic
Strategic dimensions-of-free-and-open source-software-arabicStrategic dimensions-of-free-and-open source-software-arabic
Strategic dimensions-of-free-and-open source-software-arabic
 
ADAPTATION ET INTEGRATION D’OPENERP POUR LA GESTION D’OFFICINE
ADAPTATION ET INTEGRATION D’OPENERP POUR LA GESTION D’OFFICINEADAPTATION ET INTEGRATION D’OPENERP POUR LA GESTION D’OFFICINE
ADAPTATION ET INTEGRATION D’OPENERP POUR LA GESTION D’OFFICINE
 
Implémentation d’une solution de géolocalisation des véhicules basée sur open...
Implémentation d’une solution de géolocalisation des véhicules basée sur open...Implémentation d’une solution de géolocalisation des véhicules basée sur open...
Implémentation d’une solution de géolocalisation des véhicules basée sur open...
 
Ce que perd le Maroc en ignorant le Logiciel Libre dans sa stratégie NTIC
Ce que perd le Maroc en ignorant le Logiciel Libre dans sa stratégie NTICCe que perd le Maroc en ignorant le Logiciel Libre dans sa stratégie NTIC
Ce que perd le Maroc en ignorant le Logiciel Libre dans sa stratégie NTIC
 
5 ans de openerp au maroc : retour d'expériences
5 ans de openerp au maroc : retour d'expériences5 ans de openerp au maroc : retour d'expériences
5 ans de openerp au maroc : retour d'expériences
 
Conception d'un module de gestion de la paie adapté au contexte marocain pour...
Conception d'un module de gestion de la paie adapté au contexte marocain pour...Conception d'un module de gestion de la paie adapté au contexte marocain pour...
Conception d'un module de gestion de la paie adapté au contexte marocain pour...
 

Android openerp nextma

  • 1. 2011-2012 Master 2 Miage 452 Bd Mohamed V (proximité place Yassir) CASABLANCA 20500 MEMOIRE DE STAGE Conception d’une application Android en Interaction avec Open ERP pour prise de commande à distance Stage de 5 mois effectué au sein de la Société Nextma par : Nawfal B.A AKADIRI Mémoire soutenu à l’Université le 25 Septembre 2012 Encadrant : M. AbdRahman El KAFIL Tuteur : M. Samir BENNANI
  • 2. Remerciements Louange à Dieu, Je tiens à remercier : - Mes chers parents, Moussibayi AKADIRI et Karimatou BOURAIMA qui m’ont toujours soutenue et encouragée - M EL KAFIL, qui a accepté de me donner la possibilité d’effectuer mon stage dans son entreprise - M KASSI & M ABBAS, pour leurs conseils avisés - M BENNANI, pour son suivi malgré la maladie - M ZURFLUH, pour son souci permanent de maintenir la qualité de la formation Miage - Mme GALZIM, pour tous les efforts fournis au cours de ces années - Tout le corps professoral - Tous les étudiants de ma promotion - Tous ceux qui de près ou de loin ont participé à la rédaction de ce mémoire N.AKADIRI Page 1
  • 3. TABLE DES FIGURES Figure 1 : Diagramme de Gant prévisionnel .................................................................................................... 10 Figure 2 : Diagramme de Pert .......................................................................................................................... 11 Figure 3 : Diagramme de Gant réel ................................................................................................................. 11 Figure 4 : Diagramme de cas d'utilisation ....................................................................................................... 13 Figure 5 : Diagramme de séquence - connexion au serveur ........................................................................... 14 Figure 6 : Diagramme de séquence - commande ............................................................................................ 15 Figure 7 : Architecture modulaire - Open ERP................................................................................................. 16 Figure 8 : Architecture Android ....................................................................................................................... 18 Figure 9 : Ecran de connexion ......................................................................................................................... 20 Figure 10 : Ecran Partenaire ............................................................................................................................ 21 Figure 11 : Ecran commande de produit ......................................................................................................... 21 Figure 12 : Paramétrage .................................................................................................................................. 22 Figure 13 : Bon de commande Open ERP ........................................................................................................ 22 Figure 14 : Extrait code 1 ................................................................................................................................. 23 Figure 15: Extrait code 2 .................................................................................................................................. 24 Figure 16 : Jeu d'essai - connexion .................................................................................................................. 24 Figure 17 : Jeu d'essai - prise de commande ................................................................................................... 25 Figure 18 : Structure d'un module................................................................................................................... 29 Figure 19 : Certification ................................................................................................................................... 39 Figure 20 : Synthèse Réflexion ........................................................................................................................ 44 N.AKADIRI Page 2
  • 4. TABLE DES MATIERES INTRODUCTION .......................................................................................................................................................... 6 PARTIE 1 : CONTEXTE .................................................................................................................................................. 7 A- PRESENTATION DE LA SOCIETE ....................................................................................................................................... 7 B- DEFINITION DU SUJET .................................................................................................................................................. 8 PARTIE 2 : GESTION DE PROJET ET DEMARCHE D’INGENIERIE ..................................................................................... 9 A- CYCLE DE VIE.............................................................................................................................................................. 9 B- PLANIFICATION......................................................................................................................................................... 10 1- Planification .................................................................................................................................................... 10 2- Analyse des écarts ........................................................................................................................................... 12 C- UML ..................................................................................................................................................................... 12 1- Diagramme de cas d’utilisation ....................................................................................................................... 13 2- Diagramme de séquence ................................................................................................................................. 13 PARTIE 3 : ENVIRONNEMENT TECHNIQUE .................................................................................................................16 A- OPEN ERP .............................................................................................................................................................. 16 1- Architecture générale Open ERP ..................................................................................................................... 16 2- Web services (XML-RPC) ...................................................................................................................................... 16 B- POSTGRESQL .......................................................................................................................................................... 17 C- TITANIUM ............................................................................................................................................................... 17 1- Architecture générale ...................................................................................................................................... 17 2- Limites ............................................................................................................................................................. 18 D- ANDROÏD ................................................................................................................................................................ 18 1- Architecture Androïd ....................................................................................................................................... 18 2- Limites ............................................................................................................................................................. 19 PARTIE 4 : REALISATION & MISE EN ŒUVRE ..............................................................................................................20 A- INTERFACES ............................................................................................................................................................. 20 B- EXTRAIT DE CODE ...................................................................................................................................................... 23 C- JEU D’ESSAI ............................................................................................................................................................. 24 D- SYNTHESE DES TRAVAUX............................................................................................................................................. 25 PARTIE 5 : SUJET DE REFLEXION .................................................................................................................................27 A- CONTEXTE ............................................................................................................................................................... 27 1- Les ERP et le monde de l’entreprise ................................................................................................................. 27 2- La modularité .................................................................................................................................................. 28 3- Intégration....................................................................................................................................................... 30 B- DEMARCHE ACTUELLE DE GESTION DE PROJET ................................................................................................................. 31 1- Qu’attendre d’une gestion de projet ? ............................................................................................................ 31 2- La réalité du terrain ......................................................................................................................................... 32 C- DEMARCHE AMELIOREE DE GESTION DE PROJET............................................................................................................... 33 1- Gestion du changement & Formation ............................................................................................................. 33 2- Planning de travail .......................................................................................................................................... 35 3- Budgétisation .................................................................................................................................................. 36 4- Recherche et développement (R&D) ............................................................................................................... 37 5- Démarche qualité ............................................................................................................................................ 38 6- Cycle de vie préconisé ...................................................................................................................................... 42 D- SYNTHESE ............................................................................................................................................................... 43 1- Que retenir ? .................................................................................................................................................................43 N.AKADIRI Page 3
  • 5. 2- Limites de ma réflexion .................................................................................................................................................45 PARTIE 6 : BILAN ........................................................................................................................................................47 A- BILAN TECHNIQUE ..................................................................................................................................................... 47 B- BILAN PROFESSIONNEL ............................................................................................................................................... 48 C- BILAN PERSONNEL..................................................................................................................................................... 50 CONCLUSION .............................................................................................................................................................52 WEBOGRAPHIE ..........................................................................................................................................................53 N.AKADIRI Page 4
  • 6. TABLE DES ABEVIATIONS Abréviation Désignation DUT Diplôme Universitaire de Technologie ERP Enterprise Resource Planning OS Operating System PME Petites et Moyennes Entreprises R&D Recherche et développement SI Système d’information SSII Société de Services en Ingénierie Informatique TPE Très Petites Entreprises XML Extensible Markup Language XML RPC Extensible Markup Language – Remote Procedure Call N.AKADIRI Page 5
  • 7. Introduction Les formations dispensées à l’ESG sont nombreuses et diversifiées. Au nombre de celles-ci, se situant au confluent de la gestion et de l’informatique, la Miage. Cette dernière est un diplôme à spécificité française qui a pour objectif de former des professionnels aptes à allier les nouvelles technologies de l’information à la stratégie de l’entreprise. Formation dispensée en une période de cinq années, elle inculque les notions de base de l’informatique et de la gestion à ses étudiants. Afin de mettre en valeur les connaissances acquises, deux stages sont requis : un en licence Miage et un autre – final – qui vient sanctionner les cinq années de formation - en M2 Miage. C’est ainsi qu’au cours de ces cinq derniers mois, j’ai eu à mettre en pratique les connaissances qui m’ont été transmises auparavant. Plus encore, j’ai eu à apprendre de nouvelles choses. Tel est en effet l’un des nombreux bénéfices des stages. Ainsi, ce mémoire qui n’a pas une visée technique vient présenter de façon synthétique - en me mettant le plus possible dans la logique d’un chef de projet - l’ensemble des travaux accomplis au cours de mon stage. Il est donc articulé en trois sections que sont : - La synthèse des travaux : Cette section qui regroupe l’ensemble des activités de natures diverses – de la gestion de projet au développement - effectuées tout au long du stage. Y sont comprises les parties 1 à 4. - Le sujet de réflexion : Résultat du fruit de mes réflexions – hors travail confié - sur l’entreprise, elle pose les bases d’une gestion de projet adaptée à la problématique récurrente d’intégration des modules ERP. La partie 5 vient donc traiter ce thème. - Le bilan : Il vient faire la synthèse – à travers la partie 6 - de ce que ce stage m’a apporté sur le plan technique, professionnel et personnel. N.AKADIRI Page 6
  • 8. Partie 1 : Contexte A- Présentation de la société Fort de son expérience dans le domaine du logiciel libre, Monsieur AbdRahman El KAFIL se lance en 2006, dès son retour de Belgique dans la création d’une Société de Services en Logiciels Libres (SS2L). Sa vision est claire : accompagner les entreprises - en particulier marocaines - dans la gestion de leur système d’information et ce en tirant au maximum profit des solutions open- source. Ceci passe notamment par l’intégration, développement, la formation, maintenance…de telles solutions au sein des entreprises. Ainsi, sa société – Nextma – propose diverses prestations aux entreprises tels que l’intégration de progiciels de gestions d’entreprise (PGI-ERP) la gestion de la relation client (GRC-CRM), La mise en place de solution de Business Intelligence (BI), de Synergiciels et collecticiels (Groupware), de gestion électronique de Document (GED), d’Intranet d’entreprise et de gestions de contenu (CMS). L’ensemble des prestations proposées par Nextma – et tournant autour du libre - peuvent se regrouper en quatre axes majeurs que sont : - La formation : Elle se compose d’un volet technique et fonctionnel qui permet d'accompagner les organisations disposant d’équipes opérationnelles capables de mener à bien des projets. Ces formations peuvent être établies sous forme de transferts de compétences, en phases avales des projets. - Le support : Outre les formations dispensées, la société propose aux équipes dédiées au développement des prestations de support d’aide à la maintenance afin de réduire le temps de résolution des interrogations ou des difficultés que les entreprises pourraient rencontrer lors de la mise en œuvre de certains logiciels. - Le conseil : La société assure des missions de conseil dans les domaines suivants : gestion de contenu, travail collaboratif, dématérialisation des procédures, migration vers le libre, architecture et dimensionnement d'applications basées sur Open ERP. - Le développement : Il constitue le cœur de métier de Nextma et comprend le développement sur la base de logiciels libres, de portails collaboratifs internet ou intranet… Par ailleurs, la société peut se targuer d’être le premier partenaire officiel d’Open ERP au Maroc. Elle a ainsi contribué à la promotion de cet ERP en organisant plusieurs conférences dans les universités et PME marocaines. N.AKADIRI Page 7
  • 9. Bien que l’effectif de l’entreprise soit peu consistant, elle bénéficie d’une certaine renommée. Cette dernière étant le fruit de multiples services rendus dans le cadre de ses différentes prestations aux entreprises marocaines tels que : Gaumar, Lydec, Pomelo Production mais aussi à quelques filiales internationales tels que Fiat. B- Définition du sujet Open ERP, ERP Open source, possède un module qui permet aux commerciaux de pouvoir gérer leurs ventes en toute flexibilité. Cependant pour les métiers exigeant un déplacement fréquent ou intensif du commercial, cela s’avère vite pénible d’avoir à utiliser son ordinateur quand bien même celui-ci serait léger. Ce qui se faisait jusque-là s’était que le commercial notait les commandes effectuées sur papier puis les mettait à jour une fois de retour sur son poste de travail. Il fallait alors penser à un moyen plus adéquat qui permettrait au commercial d’effectuer ses ventes, bien qu’en étant à distance de son lieu de travail ; et ce sans encombre. Sans nul doute, le moyen le plus à même de nous permettre d’atteindre cet objectif a été le développement d’une application mobile. Cette dernière constituera donc une extension à l’ERP. Ainsi, ceci permettra aux commerciaux d’éviter d’attendre de rentrer au bureau pour saisir toutes les commandes et par ailleurs permettra une meilleure efficacité. Il faudra donc développer avec le Framework Titanium, générateur de code multiplateforme, une application mobile qui permettra, dans le cas où la connexion est disponible, aux commerciaux d’effectuer des commandes. Ces dernières seront effectuées depuis leur mobile puis seront synchronisées avec la base de données distante de l’ERP. En cas de problème de connexion dû en majorité à l’environnement dans lequel évolue le commercial, les différentes commandes effectuées seront stockées en local en attendant le rétablissement de la dite connexion. Par ailleurs, des possibilités de pouvoir localiser le lieu de synchronisation des commandes doivent être prévues. Bien entendu l’application à concevoir doit être dans la même lignée que la politique de Nextma. La dite politique comme nous l’avons vu qui est essentiellement basée sur la promotion et l’utilisation des technologies Open-source. D’où leur utilisation à tous les niveaux du processus de développement. Charité bien ordonnée commence par soi-même… N.AKADIRI Page 8
  • 10. Partie 2 : Gestion de projet et démarche d’ingénierie A- Cycle de vie Choisir un cycle de vie pour son projet n’est pas chose aisée. Le cas du projet se présentant à nous ainsi que le cumul des expériences passées sont, en majeur partie, la base sur laquelle se décide tout chef de projet dans le choix d’une démarche appropriée. Comme disait l’autre c’est le terrain qui commande. Il faut savoir donc être flexible quitte à changer de démarche de gestion de projet en plein projet ! Lorsqu’il m’a été confié de réaliser cette application mobile qui puisse permettre des interactions avec Open ERP, je ne savais pas trop dans quoi je m’embourbais. Je connaissais certes les bases nécessaires pour le développement d’application mobile sous Android - notamment Java. Mais de l’autre côté, c’était la première fois que j’étais réellement confronté à travailler avec de l’existant plus particulièrement avec un ERP qui vient avec sa propre architecture, son propre formalisme…Outre le fait que mon travail se basait sur une architecture existante, j’étais aussi confronté au fait que Nextma attendait des résultats palpables très rapidement – normal c’est une SSLL. Il m’est donc venu à l’esprit de faire ou plutôt d’utiliser un cycle de vie basé sur les méthodes agiles. Mais qui parle de méthodes agiles suppose une maitrise d’ouvrage disponible entièrement. Or je n’ai pas eu l’occasion de voir tout au long du projet le client final – prévu. Raison pour laquelle je n’ai pas opté pour une démarche de gestion de projet basée sur de telles méthodes. Même si l’on considère comme maître d’ouvrage mon directeur technique, la mise en place des méthodes précédemment citées aurait été un échec cuisant en raison de la charge de travail de mon encadrant. Vu mon environnement de travail, j’ai préféré au tout début utiliser un cycle en V. Il faut dire d’ailleurs que j’étais parti sur cette base car elle me permettait dès les premières semaines d’éditer tout une série de documents afin de rassurer l’entreprise - cahier de charges, plan de test. Mais après mûre réflexion, j’ai préféré opter pour une méthode en spirale qui reprend certaines caractéristiques du V mais avec la notion de prise en charge de risque. La méthode en spirale a été défini en 1988 par Barry Boehm dans son article "A Spiral Model of Software Development and Enhancement". Nous savons qu’elle est basée sur un cycle itératif. Ainsi on itère sur l’ensemble des phases d’un projet. L’itération de toutes les phases aurait pu sembler longue à l’entreprise. J’ai donc décidé d’itérer uniquement sur les phases de conception et de développement afin d’effectuer des validations par prototypage. N.AKADIRI Page 9
  • 11. En résumé, bien que les méthodes agiles m’aient semblé plus appropriées, elle n’aurait pas pu marcher en raison des motifs précités. J’ai donc débuté mon projet sur un cycle en V mais très tôt j’ai compris qu’il y avait assez de risques – notamment dû au Framework utilisé. Alors pour remédier à cela, au niveau de la phase de développement, l’approche a été itératif et incrémental – notamment en adoptant la méthode en spirale. Ce qui m’a permis de me rapprocher au mieux des besoins des utilisateurs. B- Planification 1- Planification La planification a consisté essentiellement à découper le projet en tâches puis à les hiérarchiser. Après avoir hiérarchisé les différentes tâches, j’ai établi deux diagrammes que sont : - Le diagramme de Gant - Le diagramme de Pert Le diagramme de Gant m’a permis de contrôler l’état d’avancement du projet et le Pert quant à lui m’a permis de gérer au mieux la ressource temps. Planning prévisionnel Figure 1 : Diagramme de Gant prévisionnel N.AKADIRI Page 10
  • 12. Figure 2 : Diagramme de Pert Planning réel Figure 3 : Diagramme de Gant réel N.AKADIRI Page 11
  • 13. 2- Analyse des écarts Entre le prévisionnel et la réalité, il y a souvent des écarts. C’est d’ailleurs pour cela que l’on parle de prévisions. Car personne ne sait de quoi sera fait l’avenir. Il faut avouer tout de même que pour la plupart des projets – que ce soit un projet d’école ou de stage – auxquels j’ai participé, j’ai le souvenir d’avoir un tant soit peu réussi à tenir dans les délais ou à accuser un léger retard sur les prévisions. Mais durant ce stage, ce fût tout une autre affaire ! En effet, j’ai accusé un retard global de près de 2 semaines sur l’ensemble du projet. Enorme ! Je le concède. Nonobstant cet aveu, à l’instant où j’écris ces lignes, je ne pense pas que j’aurai pu mieux faire. Car les désagréments qui sont survenus sont vraiment uniques en leur genre. Ce sont notamment : les problèmes au niveau du réseau internet lors de l’accès au serveur ERP de l’entreprise et l’indisponibilité récurrente du portable Android. A vrai dire, ce dernier point je l’avais prévu et j’avais pour objectif dans ma feuille de route de livrer le produit à Nextma quand bien même je n’aurais pas pu faire le déploiement. Promesse qui a donc été tenue. C- UML Mon travail principal a été de comprendre les différentes interactions entre les modèles entrant en jeu dans ma conception. Notamment les relations entre les modèles Open ERP - sales, partner….Après avoir saisi cela, une modélisation basique a été faite pour la base de données en locale sur le portable afin de ne récupérer du modèle original que les éléments qui m’ont été utiles dans mon travail. Raison pour laquelle, je ne mentionnerai que le diagramme des cas d’utilisations et quelques diagrammes de séquences car représenter le diagramme de classe sur lequel je me suis basé (celui de l’ERP) serait trop volumineux et représenter celui qui a été fait en local ne représenterait aucun intérêt. Notons aussi que représenter tous les diagrammes UML n’est pas une fin en soi mais c’est l’usage qui en est fait des diagrammes mis à notre disposition qui fait toute la différence. N.AKADIRI Page 12
  • 14. 1- Diagramme de cas d’utilisation Figure 4 : Diagramme de cas d'utilisation 2- Diagramme de séquence N.AKADIRI Page 13
  • 15. Figure 5 : Diagramme de séquence - connexion au serveur Commentaires : Le commercial qui souhaite passer une commande doit tout d’abord se connecter. Après avoir saisi les informations utiles à l’authentification au niveau de son mobile. Ces informations sont alors parsées sous forme XML pour l’envoi via XML RPC au serveur. Après vérification, le serveur renvoi la réponse qui est alors déparsée… Ceci donne alors au commercial la possibilité de pouvoir effectuer une transaction – via l’affichage de l’écran d’accueil. N.AKADIRI Page 14
  • 16. Figure 6 : Diagramme de séquence - commande Commentaires : Avant de passer toute commande, le commercial se doit bien sûr de se connecter. Après s’être connecté, il synchronise les données – clients et produits – présents sur son portable avec ceux du serveur. Une fois la synchronisation effectuée, une série de formulaires – notamment celui du choix du partenaire et celui où il choisit les produits à vendre – lui sont affichées afin qu’il puisse effectuer une transaction. Dès qu’il finit, et s’il le souhaite, il peut passer à la synchronisation des ventes avec le serveur distant d’Open ERP. N.AKADIRI Page 15
  • 17. Partie 3 : Environnement technique A- Open ERP 1- Architecture générale Open ERP En 2004, Fabien Pickaers s’appuie sur la grande diffusion qu’offre le logiciel libre pour lancer Open ERP. Ce dernier comme son nom l’indique est un ERP open-source conçu à l’origine par un belge et qui au fil du temps a pu se faire une place sur le marché grâce à la motivation de la communauté qui la supporte. Comme la plupart de ses concurrents, il adopte un système modulaire comme le montre la figure 7. Figure 7 : Architecture modulaire - Open ERP Afin de communiquer avec l’ERP, l’éditeur a mis en place plusieurs protocoles de communication que sont Net-RPC et XML-RPC. 2- Web services (XML-RPC) L’hétérogénéité des langages de programmation et des systèmes à pousser la communauté, il y a de cela quelques années à développer une technologie à même de permettre une communication aisée entre eux. Ainsi est donc né XML-RPC. Comme nous pouvons le constater, cette technologie date de près d’une dizaine d’années. N.AKADIRI Page 16
  • 18. Pour assurer cette communication, il fallait trouver un langage flexible tout en tirant parti d’internet qui offrait déjà à l’époque un service d’interconnexion mondial. Le choix fût porté sur XML, dont l’interopérabilité a fait ses preuves, couplé au protocole RPC. Ainsi, et ce de façon brève, le client RPC demande l’exécution d’une méthode distante en prenant le soin de formaliser cet appel dans un n fichier XML. La méthode distante traite la requête puis la renvoie au client, toujours sous le format XML, qui se charge de parser ou de formater le résultat XML en données utilisables. Dest technologies un tant soit peu meilleures ont vu le jour - Net-RPC. Mais le manque de librairie – à ma connaissance – au niveau d’Android m’ont donc motivé à utiliser XML-RPC B- PostgreSQL Système de gestion de base de données relationnelles et objet, PostgreSQL comme la plupart de ses concurrents permet d’exécuter des requêtes SQL de base. Aussi, il assure des traitements plus complexes tels que les transactions, la réplication, la gestion des droits… Ce système de gestion de base de données, en raison de sécurité, n’autorise que les connexions locales. Or la technologie XML-RPC précédemment citée n’a toute son utilité que lorsque la connexion se fait à distance. Pour cela, Il a fallu modifier quelques fichiers de configuration notamment les fichiers postgres.conf et pg_hba.conf. C- Titanium 1- Architecture générale Titanium est un Framework permettant d’écrire son code une seule fois, et ce en JavaScript, et de le générer pour diverses plateformes mobiles - notamment iPhone et Androïd. En effet, cet outil génère du code natif à destination des plateformes mobiles supportées. Le programmeur écrit son code en JavaScript - langage apparemment simple d’utilisation - et le code est généré en Java (pour Androïd) et Objective-C (pour iPhone). Cela peut paraître plaisant car il permet de se départir des contraintes d’apprentissage d’un nouvel langage. Bien sûr si l’on part du principe que JavaScript est bien plus facile d’apprentissage que les langages précités – Java et Objective-C. Aussi, il permet au programmeur de travailler à un haut niveau d’abstraction laissant ainsi la tâche au Framework de faire la « sale besogne ». Vu ainsi, cet outil a tout pour séduire. Mais, il y a un « mais» ! N.AKADIRI Page 17
  • 19. 2- Limites Lorsqu’on passe à la pratique, la couche supplémentaire du Framework permettant la génération de code rend lourde et lente la phase de développement. Sans compter les fuites de mémoire au niveau du mobile en raison à la quantité importante de données rapatriées du serveur. Tout ceci mis en communion avec le fait de vouloir un prototype fonctionnel dans les meilleurs délais ont fait, qu’en accord avec l’entreprise, nous avions décidé d’utiliser le langage natif d’Androïd à savoir Java pour mener à bien le développement. D- Androïd 1- Architecture Androïd Android est un système d’exploitation basé sur la distribution Linux. Il est destiné à des appareils mobiles. Pour concevoir des applications sur cet OS, il faut posséder les bases nécessaires en Java. Une imbrication et/ou une superposition de cinq couches, tel que le montre la figure 8, définisse l’architecture d’Android. De la couche relative au noyau Linux à la plus haute qu’est la couche application, tous les composants de l’OS s’évertuent à fournir des applications de qualité exploitant au mieux les ressources du mobile. Figure 8 : Architecture Android N.AKADIRI Page 18
  • 20. C’est ainsi que : - La couche Linux permet de gérer les traitements de base tels que la gestion de fichiers, la sécurité … - Les couches Librairies ou Bibliothèques & Application Framework sont des couches destinées aux programmeurs. - La couche Android Runtime quant à elle reprend les principales caractéristiques des librairies de base de Java en y ajoutant quelques spécificités telles que : la machine virtuelle Dalvik. 2- Limites La notoriété du célèbre OS n’a pas laissé indifférent les pirates informatiques de tout bord. Ce qui s’est traduit dans les faits par une augmentation exponentielle du nombre d’attaques enregistrées. Pour s’en convaincre, il suffit de citer l’étude de Juniper Networks prenant en compte les technologies mobiles les plus en vogue - à l’exclusion d’Apple en raison de la politique très fermée de cette dernière - qui estime que les attaques sur Android entre 2010 et 2011 sont passées de 0,5 % à 46,7% ! De plus, uniquement sur les sept derniers mois de l’année 2011, les logiciels malveillants ciblant cette plateforme ont augmenté de 3325 % ! [w1] L’année 2012 a été marquée aussi par de nombreux soubresauts. Dernier en date, et pas des moindres, la présentation d’un Framework modulaire – open source - d’exploit permettant à tout un chacun de disposer d’une application Android malveillante faite sur mesure ! [w2] Google prend cependant ces menaces très au sérieux. Notamment avec Bouncer, son système de détection de comportements malveillants qui malheureusement s’est révélé très vite inefficace. De quoi s’interroger sur l’adjonction de technologies mobiles, en particulier celles basées sur Android, au système d’information. Une brèche évidente de plus qui n’empêche cependant pas la Nasa de mener actuellement des recherches qui à terme permettront d’équiper un nano satellite d’un ordinateur de bord Android …[w3] N.AKADIRI Page 19
  • 21. Partie 4 : Réalisation & mise en œuvre A- Interfaces La section suivante présente quelques interfaces de l’application : Figure 9 : Ecran de connexion N.AKADIRI Page 20
  • 22. Figure 10 : Ecran Partenaire Figure 11 : Ecran commande de produit N.AKADIRI Page 21
  • 23. Figure 12 : Paramétrage Figure 13 : Bon de commande Open ERP N.AKADIRI Page 22
  • 24. B- Extrait de code L’utilité des commentaires n’est plus à démontrer. Cependant je ne peux pas dire que j’en ai mis à tous les «coins de rue». En effet, j’en ai mis uniquement là où je l’ai jugé utile, comme le montre les figures 14 et 15. Mais cela peut dépendre de chacun. De plus, la nature même du langage est assez explicite : des si, sinon …. Parfois j’ai préféré ne carrément pas en mettre pour éviter de polluer le code qui était déjà assez complexe à lire avec l’utilisation de librairies externes. En toute chose le juste milieu ! Figure 14 : Extrait code 1 N.AKADIRI Page 23
  • 25. Figure 15: Extrait code 2 C- Jeu d’essai Lors de l’installation d’Open ERP, la possibilité nous est offerte lors de la création d’une base de données de la charger avec des données de test. Il me semble que cette base de données couvre la majorité si ce n’est la quasi-totalité des cas de figure. Je me suis aussi aidé d’un certain nombre de tests que j’ai établi dans un document remis à l’entreprise afin de m’assurer de la conformité entre le résultat obtenu et les besoins du client. Les figures 18 et 19 montrent notamment les jeux d’essai établis respectivement pour la connexion à l’application et la prise de commande. Figure 16 : Jeu d'essai - connexion N.AKADIRI Page 24
  • 26. Figure 17 : Jeu d'essai - prise de commande D- Synthèse des travaux Ce stage a été une fois de plus l’occasion de me confronter au monde de l’entreprise. A entreprises différentes, réalités différentes. Quoi de plus normal ! Car chaque entreprise à son vécu. Mais aussi un ensemble de personnes différentes qui gravitent autour d’elle. Le tout a été donc de pouvoir s’imprégner du mieux que possible de mon nouvel environnement. Il m’a été confié un projet de conception d’application mobile spécialement sous Android. Ce fût une expérience nouvelle de concevoir autour d’une plateforme mobile. Le choix de l’outil de développement – Framework Titanium – qui était, dès le départ, imposé par l’entreprise s’est vite révélé problématique - notamment en raison des performances obtenues. Ce qui a nécessité de suivre la procédure courante de développement des applications Android – utilisation du langage Java. Il en a résulté de tout ce processus, une application qui pourra permettre à tout commercial en déplacement de prendre des commandes sur son mobile et de les synchroniser à distance avec Open ERP. Ce dernier se chargeant ensuite d’établir un bon de commande par client – sous forme de devis – à valider ultérieurement. N.AKADIRI Page 25
  • 27. Par ailleurs, j’ai voulu comprendre un tant soit peu le principe de fonctionnement des modules d’Open ERP. Ceci dans le but principal d’acquérir ne serait-ce que des connaissances basiques pour de tel développement afin de mener à bien mon sujet de réflexion. Quoi de mieux que d’en développer un module assez simpliste – en comparaison de ce qui se fait d’ordinaire. Chose que j’ai faite en développant un module qui intègre les champs de géolocalisation au niveau du module de vente d’Open ERP. La période de test a été la plus pénible. En effet, Android dispose d’un outil permettant d’émuler le fonctionnement de l’OS sur son ordinateur. Seulement entre le virtuel et la réalité, l’écart est tel que, la stupéfaction est bien souvent, au rendez-vous. La période de test n’a cessé de s’allonger car le réseau de l’entreprise pour une raison qui, à ce jour, demeure toujours inconnue, ne facilitait pas l’accès au serveur Open ERP quand on y tentait d’y accéder via un portable physique – malgré l’ouverture des ports adéquats. Tantôt ça marchait, tantôt non ! Il a fallu bon nombre d’essai en particulier sur un réseau externe pour déceler le problème qui était lié non seulement à la connexion mais aussi à la quantité de données importées. Par ailleurs, les modifications de dernières minutes et l’indisponibilité récurrente du portable – car appartenant à une personne souvent en déplacement - n’ont fait que rallonger cette période de test. Quant à la rencontre avec le client – prévu -, elle n’a cessé d’être repoussée aux calendes grecques pour des raisons multiples. Ce sont notamment la répercussion du retard accusé pour la phase de test mais aussi du fait du programme chargé de l’encadrant. Cependant le développement de l’application étant à présent terminée, elle sera de toute façon livrée au client, que ce soit durant la période de mon stage ou en dehors. Voyons à présent tout un autre aspect de mon stage qui relate l’ensemble des réflexions faites – suite à des discussions et des recherches personnelles - sur le fonctionnement de l’entreprise dans une thématique donnée. N.AKADIRI Page 26
  • 28. Partie 5 : Sujet de réflexion Titre : Nextma développe souvent des modules complémentaires pour Open ERP dans les entreprises marocaines. On pourrait s’interroger sur la démarche de gestion de projet actuelle pour le développement de tel module et penser à une amélioration de cette démarche pour produire des modules hautement adaptatifs (en fonction de la configuration d’Open ERP au niveau de l’entreprise commanditaire) et facilement évolutifs (avec les versions futures d’Open ERP). A- Contexte 1- Les ERP et le monde de l’entreprise Dans les années 70, du côté des systèmes d’information, l’entreprise faisait en quelque sorte « carrière solo ». Pour être plus explicite, disons que ses différentes cellules aussi bien internes, qu’externes menaient une vie en autarcie du moins en ce qui concerne la gestion de leurs ressources – notamment la ressource information. Que ce soit donc au niveau des échanges qui la liaient aux autres entreprises ou des échanges entre les différents services, on assistait à un cloisonnement de l’information. Ceci a entraîné une barrière virtuelle entre les différentes entités en jeu dans l’environnement de l’entreprise. Barrière qui s’est traduite bien évidemment par l’isolement de l’information, la redondance et l’incohérence des données, la difficulté de mise à jour de ces informations. .. Dans les années 80, l’ERP dont les prémisses remontent aux années 1960 devient petit à petit un élément indispensable dans les entreprises qui sont désormais à la recherche d’information de qualité. Et pour cause, les différents processus internes de l’entreprise qui autrefois étaient isolés commencent à s’unifier et s’imbriquer dans un souci pour les décideurs d’avoir une vision homogène et globale de leur système d’information. L’avènement d’internet dans les années 90 a donc donné aux ERP une importance plus accrue. En effet internet a permis d’étendre le système d’information de ces entreprises. Cette révolution a donc ajouté à l’unification des processus internes déjà entamée dans les années 80, l’unification des processus externes. De plus avec la concurrence sans cesse croissante, l’entreprise a dû ainsi subir de profondes mutations tant sur le plan organisationnel que technique. Au nombre de ces mutations technologiques, l’utilisation - plus intensive - des ERP. Ces outils ont fait et font leur preuve car ils permettent d’homogénéiser l’ensemble des informations de l’entreprise tout en permettant à ses différents acteurs de disposer de l’information appropriée : que ce soit pour une vision synthétique de l’information pour le décideur ou pour le traitement d’une transaction pour un opérateur. Comme dans la plupart des innovations dans le domaine technologique en particulier N.AKADIRI Page 27
  • 29. informatique, il existe des solutions dites propriétaires et des solutions open-source. La principale différence entre ces deux types de solutions se trouvent dans le business-model qui est mis en place. Pour la plupart des solutions dites propriétaires, la licence est vendue puis la maintenance est assurée de facto. Tandis que pour les solutions dites open-source, la licence est gratuite et la maintenance et/ou les services sont facturées. Nous ne nous attarderons pas sur ces points, tel n’est pas notre sujet. Comme vu brièvement dans la partie 3, quel que soit le type d’ERP pour lequel on opte, l’architecture est souvent la même. Il s’agit d’une architecture modulaire qui permet à l’entreprise de développer des modules spécifiques pour enrichir les fonctionnalités de l’ERP si le besoin s’en faire sentir. Bien que ce type d’architecture ait fait ses preuves dans bien d’autres domaines, elle pose un problème majeur dans le cas des ERP. En effet, à chaque nouvelle version de l’ERP, les modules précédents doivent être adaptés à la nouvelle version mais encore à la configuration de l’entreprise cible ! L’entreprise dans laquelle je me trouve est justement spécialisée dans les questions relatives à tout ce qui touche de près ou de loin aux ERP en particulier à Open ERP. C’est à ce titre, qu’elle intervient dans l’intégration d’Open ERP au niveau des entreprises marocaines - PME en particulier. La question que nous nous sommes posé était de savoir s’il n’y aurait pas une démarche de gestion de projet adaptée pour produire des modules hautement adaptatifs (en fonction de la configuration d’Open ERP au niveau de l’entreprise commanditaire) et facilement évolutifs (avec les versions futures d’Open ERP). Il s’agit bel et bien d’adopter une démarche de gestion de projet pouvant faciliter la compatibilité ascendante des modules. Question insoluble me diriez-vous ? Possible ! Mais peut être que la question n’a jamais été posée ou n’a pas été formulée comme il se devait. Avant de résoudre notre problème, tel un médecin, commençons tout d’abord à faire un diagnostic plus détaillé. Ce qui reviendrait dans notre cas à mieux expliciter la modularité de l’architecture d’Open ERP puis à décrire le processus d’intégration des modules. 2- La modularité Un module Open ERP est une brique logicielle qui permet de personnaliser l’ERP selon ses besoins. Le module est construit selon une architecture prédéfinie. Cette dernière se compose généralement de dossiers imbriqués contenant des scripts python et des documents XML (tel que le montre la figure 18) permettant de définir l’interaction entre les différents objets Open ERP. N.AKADIRI Page 28
  • 30. Figure 18 : Structure d'un module L’ERP est composé de plus de 300 modules et est continuellement en évolution. Selon le secteur d’activité de l’entreprise, on peut trouver un ou plusieurs modules qui permettent à l’ERP de s’adapter au mieux à ses besoins. On peut donc classer ces modules en fonction des services qu’ils rendent. Cependant, dans le cadre de mon sujet de réflexion, une telle classification ne représentera aucun intérêt. Raison pour laquelle l’ensemble de ces modules disponibles au niveau d’Open ERP sera plutôt classé en deux catégories principales : - Les modules de base : regroupe tous les modules indispensables au fonctionnement d’Open ERP. - Les modules spécifiques : ce sont des modules que l’on a ajouté à Open ERP. Ces modules sont développés soit par l’éditeur ou soit par des tiers. Ainsi, les modules spécifiques sont développés par deux entités que sont l’éditeur et les partenaires. Nous verrons par la suite que c’est la deuxième catégorie de modules – lorsqu’elle est développée par les partenaires - qui posent le plus de problème. N.AKADIRI Page 29
  • 31. 3- Intégration Nous avons donc vu qu’un module Open ERP est un élément qui respecte certains critères qui lui permettent de s’intégrer aisément dans Open ERP afin d’apporter une plus-value en terme de fonctionnalités. Le développement de tels modules n’est pas si différent de celui qui est d’ordinaire connu en développement informatique. En d’autres termes, nous avons trois phases principales à savoir la phase d’analyse, de conception et d’implantation. De l’analyse effectuée, on en tire les différents flux d’information de l’entreprise à implanter au niveau de l’ERP sous forme de modules. Après le recueil des besoins du client par l’intégrateur - via la phase d’analyse - vient un benchmark. Ce dernier sert à répertorier les solutions existantes en termes de modules. Ceci permettra de savoir si l’on doit concevoir un nouveau module de bout en bout ou faire une extension ou encore une spécialisation d’un composant métier existant. Suite à cette étape de benchmarking - analyse comparative -, l’intégrateur entame la phase de spécification fonctionnelle par un premier découpage fonctionnel en dégageant les dépendances existantes. Par exemple pour une application – un module - de gestion complète de stock, il pourra tout d’abord s’intéresser à la gestion de produits qui est une fonctionnalité en créant un premier module. Puis passer à la gestion du flux comptable – qui est associé à la gestion du stock – qu’il intégrera dans un autre module. Après le découpage susmentionné, l’intégrateur peut maintenir établir pour chaque découpage, une conception ordonnée avec un périmètre fonctionnel défini. Ceci s’avère utile pour assurer l’engrenage des composants. Analyse comparative assurée puis découpages effectués, l’intégrateur débute la conception des maquettes pour chaque module dégagé. Maquettes qui seront validées par le client. Pour le reste, il s’agit d’établir les diagrammes UML dont on a besoin puis de penser à la liste de rapports à concevoir. En somme, l’intégrateur recueille donc les besoins de l’entreprise puis les modélise le tout en utilisant différents modèles. Le plus coutant est UML car les relations entre les différents modules sont souvent à préciser mais plus encore du fait que l’ensemble de l’architecture Open ERP est basée sur des objets. A tout ceci, un diagramme de processus peut être établi afin d’avoir une vision plus claire et synthétique des différents flux présents au niveau de l’activité analysée dans l’entreprise. N.AKADIRI Page 30
  • 32. Lorsque l’on fait un tour sur le net, moult documentation font l’apologie d’Open ERP en vantant sa flexibilité car permettant la « construction de bâtiment sur mesure »…Ces écrits peuvent t’ils être qualifiés d’écrits partisans ou les mérites tant vantées le sont-ils véritablement ? Comme évoqué plus haut, Open ERP est modulable de bout en bout. Le principe de modularité des fonctionnalités de l’ERP, qu’elles soient minimes ou complexes, est un atout indéniable qui accroît son potentiel. Là où le bât blesse, c’est lorsque l’entreprise doit migrer de version de l’ERP entraînant quelques fois, si ce n’est la quasi-totalité du temps, une obsolescence du module qui autrefois faisait la joie des utilisateurs. Ainsi, la modularité d’Open ERP tant vantée par certains est à l’origine d’un autre puzzle - pas celui de l’enrichissement du logiciel - mais plutôt celui de garantir une cohésion pérenne des modules. Cette modularité ne présenterait donc pas que des avantages. En d’autres termes, les modules c’est bien, mais ça ne résout pas tous les problèmes ! Des lignes qui précèdent, on comprend aisément que quel que soit l’entreprise, qu’elle se nomme Nextma ou autre, la problématique reste la même ! Comment véritablement améliorer l’intégration de ces modules ? Ma démarche consiste donc à penser à une amélioration de cette intégration, précisément au niveau des modules développés par Nextma. Pour ce faire, je me propose de travailler, non pas sur le côté technique - python & compagnie - mais plutôt sur le côté gestion de projet. En effet, il est connu que pour réussir la phase de maintenance d’un produit informatique, il faut faire une bonne analyse mais surtout bien gérer son projet. Ce qui m’amène à penser que l’adoption d’une bonne démarche de gestion de projet dans la création de modules est un gage de production de modules plus facilement maintenables, hautement adaptatifs et évolutifs. Mais avant tout, existe t’il actuellement au niveau de Nextma, une démarche de gestion de projet qui permette le développement de tels modules ? Comment faudrait-il améliorer cette démarche, si démarche il y a, ou quelle démarche de gestion de projet adoptée pour résoudre notre problème d’intégration ? B- Démarche actuelle de gestion de projet 1- Qu’attendre d’une gestion de projet ? Un projet peut être défini comme une série d’actions orchestrées dans le temps, en fonction des ressources disponibles, afin d’atteindre un objectif prédéfini. Objectif qui ne saurait être atteindre qu’en gérant le projet. N.AKADIRI Page 31
  • 33. Gérer un projet équivaudrait donc à mener des troupes au combat. Bien entendu, l’on ne va pas au combat sans mission et sans stratégie. De même dans un projet, la (les) mission(s) doivent être clairement définie(s), les moyens pour y parvenir doivent être répertoriés et une démarche doit être mise en place .Les démarches existantes pour mener à bien une gestion de projet sont assez nombreuses. Elles ont pour point commun d’optimiser les ressources disponibles afin de converger, autant que peut se faire, vers le but voulu. Pour mener à bien cette orchestration, il s’agit de façon générale d’initialiser le projet, de le planifier, de le mettre en œuvre, de le contrôler puis de le clôturer. Ainsi, il en découle les grandes étapes suivantes : - Initialisation du projet - Planification du projet : Etablissement d’un plan de travail - Mise en œuvre du projet : Il s’agit ici, de gérer les différentes ressources entrant en jeu dans le cadre du projet afin d’atteindre ses objectifs. - Contrôle du projet : A ce niveau, on effectue des suivis par rapport à la planification et à la coordination des ressources afin de détecter les éventuels écarts et d’y remédier le plus tôt possible. - Clôture du projet : Finalisation du projet et bilan global afin d’en tirer des leçons et d’améliorer la qualité des projets futurs. 2- La réalité du terrain Tout d’abord, mentionnons un point important qui sans lequel, la description actuelle de la gestion de projet - pour le développement de modules - faite par Nextma risque d’être criblée de critiques. Or, mon travail de réflexion ne vise pas un tel but. Jusqu’à tout récemment, Nextma développait un partenariat avec une société de la place. Mais ce contrat, pour des raisons qui me sont inconnues a été rompu. Raison pour laquelle Nextma se reconstitue une équipe. Elle mise donc sur l’apport des stages pour rénover son personnel. C’est donc dans un tel climat de restructuration que j’ai débuté mon stage, ce qui fait que ma description de la gestion de projet - pour le développement de modules - qui est pratiquée au niveau de l’entreprise ne peut être qu’incomplète voire biaisée. En raison des points susmentionnés, il m’est donc impossible de décrire objectivement la gestion de projet pratiquée dans le cadre du développement de modules par Nextma. Cependant, j’ai pu constater au cours de ces cinq mois, quelques entaches notamment au niveau de l’initialisation du N.AKADIRI Page 32
  • 34. projet où les besoins ne sont pas forcément bien définis dès le départ ce qui par la suite, bien évidemment, créé tout un imbroglio ou des projets à rallonge. N’allez surtout pas croire que Nextma peine à rattraper le train de la concurrence - du moins de mon point de vue - car cela à l’air d’être chose courante dans le domaine. Selon Journal du Net qui publiait, en s’appuyant sur une enquête en ligne réalisée entre février 2006 et mai 2012 auprès de 2000 répondants (dans 61 pays) qui ont mis en place l'ERP Oracle, Microsoft Dynamics ou SAP, un dossier datant 23/07/2012 sur les projets ERP en général, le constat est alarmant : « En tout cas, en 2010, les entreprises interrogées par Panorama Consulting étaient 35,5% à affirmer dépasser le temps de déploiement prévu initialement. Elles sont plus de 60% dans ce cas en 2012. » [w4] Est-ce une raison pour ne pas aller de l’avant et s’améliorer ? Bien sûr que non ! C- Démarche améliorée de gestion de projet Après avoir donné un aperçu, qui je l’avoue est assez bref, de la démarche actuelle de gestion de projet adoptée au niveau de l’entreprise, voyons à présent en quoi pourrait consister une démarche de gestion de projet efficace à même de résoudre ma problématique. Il est un fait que les risques sont inhérents à tout projet, le développement de modules n’en fait pas exception, bien au contraire. Il ne serait pas faux de dire que gérer ce genre de projet, comme tout autre projet, revient à limiter au maximum les risques. On s’évertuera donc dans la suite de cet exposé, autant que faire se peut à limiter les risques liés à l’intégration de modules Open ERP dans l’entreprise. 1- Gestion du changement & Formation Toute nouveauté, tout changement, au sein d’un groupe d’individus génère frustrations, réticences. Ces sentiments générés sont le propre de l’homme qui préfère « ménager sa zone de confort ». Pour cela il développe une série de mécanismes psychologiques et/ou physiques qui lui permettent de faire écran avec ce qu’il juge intrusif. Dans de telles situations, il ne sert à rien d’imposer manu-militari le changement. Bien au contraire, il faut ménager les individus en gérant au mieux ce changement. Gérer le changement reviendrait donc, de façon globale, à les convaincre que la nouveauté voulue cadre bien avec leur zone de confort. Cet exercice s’avère assez complexe car les individus d’un groupe ont des natures et ambitions diverses. L’installation de nouveaux modules au sein d’une entreprise est dans ce sens perçu par les utilisateurs comme un changement. Il convient donc d’intégrer dans sa gestion du projet - de façon N.AKADIRI Page 33
  • 35. parallèle - une politique de gestion du changement. Le développement de tels modules, bien souvent complexes, se révèle être une tâche astreignante. Quoi donc de plus frustrant que d’avoir des utilisateurs «capricieux» en face. Ce fait mentionné a été vécu par un membre de mon équipe où lors de la phase de recette, tous les utilisateurs avaient adopté bon gré, mal gré le nouveau module à l’exception d’un seul qui pour un rien faisait retarder la phase réelle d’exploitation du module. Lorsqu’on prend un tout petit peu de recul, on n’en vient à se dire que la faute ne revient pas seulement à l’employé car elle est partagée. Il a dû développer des réticences du fait que le projet n’ait pas été suffisamment, si l’on peut dire « marketé » comme il se devait auprès des employés. En d’autres termes, il n’y a pas eu de gestion de changement qui suive. Pour être plus précis, disons plutôt qu’il n’y a pas eu de gestion de changement en parallèle ; car si elle vient après le projet, il est déjà trop tard ! Structurer sa politique de gestion de changement s’avère donc utile. Mais nous sommes en droit de nous poser la question légitime de savoir si une bonne de gestion de changement peut réellement aider dans la résolution de notre thématique. Nous répondons, oui, du moins, elle résout une partie du problème, notamment la facilité d’adaptation des modules dans les entreprises, mais pas l’évolutivité des modules suite aux évolutions dictées par les versions nouvelles de l’ERP. Cet aspect sera traité plus bas. Notons que cette gestion de changement peut être aussi pris en charge par l’entreprise elle-même mais nous nous mettons ici dans l’optique qu’elle est confiée à l’équipe en charge de gérer le projet. Côté formation, le chef de projet devra prendre aussi le soin de mobiliser le personnel nécessaire pour leur donner une formation adéquate. La formation dont nous parlons comprend deux volets : - La formation en interne (au projet) - La formation des utilisateurs La formation en interne regroupe toutes les formations que le chef de projet jugera nécessaire de fournir à son équipe pour améliorer la qualité de leur développement. Quant à la formation des utilisateurs elle s’avère d’autant plus utile car il ne sert à rien de dépenser de ses ressources à former son équipe et à certifier son module si en amont on ne pense pas à la formation de ceux pour qui le module est destiné. N.AKADIRI Page 34
  • 36. Il convient donc d’intégrer l’axe formation à la politique de gestion de changement. Plus particulièrement le deuxième volet de la formation à savoir la formation des utilisateurs. Ainsi, la formation des utilisateurs et la gestion de changement interviendrait dans la résolution de l’adaptabilité des modules en fonction de l’entreprise commanditaire. Tandis que la formation en interne - notamment sur les règles de certification – permettra quant à elle d’assurer l’évolutivité des modules. Nous parlerons plus bas de la certification au niveau de la démarche qualité. 2- Planning de travail Dans cette section, nous nous efforcerons de dénombrer les étapes courantes, telles que perçues durant mon stage, d’une planification de modules tout en mettant l’accent sur les endroits que l’on juge important de réussir si l’on souhaite produire des modules plus évolutifs et/ou adaptatifs. - Formations fonctionnelles : Vu qu’Open ERP est une grande forteresse, il est prétentieux de penser la maitriser de bout en bout. Raison pour laquelle, l’équipe qui intervient sur le projet a parfois besoin de mieux comprendre le fonctionnement de certains aspects de l’ERP. Il faut donc prévoir ce fait au début en évaluant les compétences fonctionnelles de son équipe dans le domaine d’action du projet. - Analyse de l'existant : Développer un module, n’est pas une tâche en aparté. Elle fait partie intégrante d’une logique globale. On peut la comparer à la construction d’une brique dans l’édification d’un immeuble. En effet, la brique ne saurait être construite à la volée. Une étude préalable s’avère donc nécessaire pour déterminer le type de brique, son contour, l’agencement avec la structure de l’immeuble… Il en est de même pour l’analyse qui précède le développement d’un module. Comme toute phase d’analyse, elle permettra de capturer les besoins des utilisateurs mais plus encore de s’assurer de la faisabilité de ceux-ci car ici, on est limité à l’architecture de l’ERP. Aussi, dans cette phase d’analyse, il faudra répertorier et décortiquer les différentes interactions - workflow – et les dépendances existantes entre les modules déjà présents et ceux qui seront utiles au nouveau module à concevoir. - Développement : C’est à ce niveau qu’on « converti » l’analyse précédemment effectuée en lignes de code. On s’appuie donc sur un langage. Mais pas n’importe lequel ! Celui sur lequel est basé Open ERP à savoir python mais aussi sur un langage de balisage - précisément XML - qui apporte une certaine souplesse au développement des modules. - Migration des données : Cette phase peut s’avérer utile dans certains cas. - Tests : Pas si différente des phases de tests connues du développement informatique. Cette phase permet de s’assurer de l’adéquation des besoins des clients avec le module final. N.AKADIRI Page 35
  • 37. - Capture des remarques et maintenance : Les remarques du client se prennent en majorité – du moins selon ce que j’ai vu durant mon stage – vers la fin du projet quand le module est déjà fonctionnel à près de 90 %. L’ensemble des trois phases (Tests, Capture des remarques et maintenance) peut s’étaler sur une très longue période tant certains modules sont complexes. En plus de cela, la prise des remarques vers la fin du projet ne fait que rallonger le délai de maintenance et par ailleurs celui de la fin du projet. - Déploiement du module : Permet de mettre en production le module développé. Elle intervient après de nombreux va-et-vient entre les trois phases précédemment citées. Nous venons donc de voir que les phases citées ci-dessus (allant de la formation fonctionnelle au déploiement du module) sont, de façon générale, celles qui sont pratiquées par Nextma pour le développement de modules. A présent posons-nous la question de savoir quelles sont les améliorations que l’on puisse apporter dans le cadre de la résolution de notre problématique ? De façon générale, les phases appliquées par Nextma sont assez intéressantes en soi. Cependant, il convient d’intégrer deux éléments à cette planification. Le premier élément est en fait une amélioration d’une phase déjà existante et le second est l’intégration d’une phase qui n’est pas encore existante. Tout d’abord, il y a une chose qui nous interpelle. La phase « Capture des remarques » se retrouve entre les tests et la maintenance. Il n’y a pas de mal en tant que tel mais pour ce genre de projet, il convient de prendre les remarques du client le plus fréquemment possible afin d’éviter les déconvenues. En effet, le développement de module n’étant pas une sinécure, il convient d’associer le client au maximum tout au long du projet. Deuxième point à intégrer, ce sont les bilans en fin de projet. Il convient en effet d’établir une base de connaissances d’ordre diverses – théoriques, managériales, organisationnelles – répertoriant l’ensemble des problèmes rencontrés tout au long du projet et comment ils ont été résolus. Ainsi, à chaque nouveau projet on améliorera les zones d’ombre. 3- Budgétisation Dans cette partie, nous verrons comment faire pour établir un budget qui permette d’atteindre notre objectif de développer des modules facilement évolutifs. Mais avant tout, rappelons brièvement ce que c’est que la notion de budgétisation et quelle relation étroite se tisse entre budgétisation et projet. N.AKADIRI Page 36
  • 38. La budgétisation est l’ensemble des procédés qui permettent de s’assurer que les ressources – financières entre autres – dont nous disposons (ou disposeront) nous permettent(ou permettront) de couvrir l’ensemble des dépenses auxquelles on est censé faire face. Cet exercice financier sensible doit être mené avec rigueur. Bien évidemment, la budgétisation n’est pas faite en aparté, elle fait partie intégrante de la gestion d’un projet. Ainsi, la budgétisation intervient dans la phase de planification, aussi bien prévisionnelle que réelle. Elle permettra donc au chef de projet de s’assurer qu’il n’a pas les yeux plus gros que le ventre mais surtout de rentabiliser le projet. Cette phase comme la quasi-totalité des phases d’un projet nécessitera aussi l’aval de la direction. Des lignes qui précèdent nous avons pu saisir que l’établissement du budget est une étape délicate, qui bien qu’à elle seule ne puisse faire la réussite d’un projet, y contribue significativement. Le développement de modules évolutifs étant - avant tout - un projet, il est tout fait normal qu’une bonne gestion du budget puisse produire des résultats probants. Mais, affirmer à l’emporte-pièce qu’une bonne gestion du budget puisse permettre le développement de modules plus évolutifs serait trop prosaïque. En effet, il conviendrait d’expliciter un peu plus cette assertion. Pour que la budgétisation nous soit profitable dans la résolution de notre problématique, il nous faudra prendre en compte aussi bien les coûts directs que les coûts indirects. Ce sont notamment : - Coût des salaires des employés travaillant sur le projet - Coût des intervenants externes (consultant, formateur…) - Coût de la qualité (certification, formation…) - … 4- Recherche et développement (R&D) Bien que dans le modèle économique de la firme Open ERP, le faible coût d’investissement R&D est un atout vanté du fait qu’actuellement la R&D autour de l’ERP est assurée à 80 % par l’ éditeur et à 18% par les éditeurs propriétaires, il me semble opportun d’inverser la tendance…. D’autant plus que la communauté fait partie intégrante de la stratégie de développement l’éditeur. Pour cela le chef de projet devra constituer une équipe dédiée à plein temps à la R&D. Cette technique d’investissement R&D commence à voir le jour mais lentement. C’est le cas de la société Axelor en France qui est une société de services spécialisée dans l'intégration d'ERP Open Source. Cette société possède son propre centre de R&D et est l’auteur de nombreuses innovations permettant d’améliorer dans la continuité Open ERP. Au nombre de ces innovations, nous pouvons citer notamment : les plug-ins MS office, la nouvelle version web d’Open ERP … L’investissement N.AKADIRI Page 37
  • 39. dans la R&D permettrait d’aboutir à une innovation. Encore faut-il savoir quels types d’innovation faire. Nextma étant une PME voire une TPE, les meilleurs types d’innovation qu’elle pourrait mettre en place sont des innovations de marché ou de valeur. Or, de mon point de vue, la meilleure innovation dont on a besoin dans notre cas de figure est une innovation de processus. En effet, il convient de mettre en place de nouveaux procédés permettant d’améliorer l’adaptabilité et l’évolution des modules. Les moyens étant limités, Nextma pourrait penser à mettre en place un consortium d’entreprises qui uniront leurs ressources pour imposer de nouveaux processus, de nouveaux standards au niveau du développement des modules Open ERP - et dans une plus large mesure au niveau de la gestion de projet de tels modules. Détail important ; pour mener à bien cette stratégie d’investissement R&D, le chef de projet devra pouvoir convaincre sa direction du bien-fondé de ces investissements à haut risque. 5- Démarche qualité La qualité est un vaste domaine abordé dans presque tous les aspects de notre vie quotidienne. Elle se révèle d’une grande utilité lorsqu’on sait l’utiliser à bon escient et ce dans un cadre bien déterminé. Pour permettre une meilleure intégration des modules, il faudra donc adopter une démarche qualité. Mais laquelle ? Comme il a été dit, le terme qualité regroupe plusieurs définitions. Il faudrait, par soucis de clarté, préciser l’aspect qualité que pourrait adopté le chef de projet lors d’une gestion de projet impliquant le développement de modules Open ERP. Je restreindrai donc volontairement la qualité à la notion de certification. Le chef de projet soucieux de pouvoir mener à bien son projet de développement de module, et ce par la même occasion permettre la production de modules hautement évolutifs, se doit de les certifier. Encore faut-il qu’il en soit convaincu du bien-fondé de cette certification. Chose que je m’évertuerai à prouver dans les lignes qui suivent. La certification désigne un processus qui permet d’attester de la conformité d’un produit ou d’un service par rapport à des standards prédéfinis. Elle se fait généralement par un organisme accrédité. Ainsi, la certification d’un module Open ERP est un processus qui vise à valider la conformité du nouveau module par rapport à des standards définis par Open ERP. Elle permet donc aux modules spécifiques d’être inclus dans l’ERP. Pour certifier son module Open ERP, cinq étapes principales sont nécessaires : N.AKADIRI Page 38
  • 40. - L’analyse technique : Il s’agit de faire une analyse approfondie du code afin de détecter les erreurs éventuelles, la conformité des bonnes pratiques, la robustesse des modules…. - L’analyse fonctionnelle : Ici, l’éditeur essaye de déterminer la pertinence de l’approche adoptée par l’équipe projet. - Validation/Non validation : Si le module est validé, un certificat est délivré dans le cas contraire, des propositions d’amélioration sont faites en vue d’améliorer la qualité du module. - Insertion du module dans la suite logicielle - Diffusion à la communauté La certification, comme le montre la figure 19, prône donc un apport des partenaires à la communauté mais surtout un contrôle qualité effectuée par Open ERP. Figure 19 : Certification N.AKADIRI Page 39
  • 41. Jusque-là nous venons de découvrir le processus de certification mis en place par Open ERP. Mais une question subsiste en quoi ce processus est-il gage d’une meilleure intégration des modules ou d’une maintenance évolutive réussie sans lourdeur ? La certification de modules que se propose de faire l’éditeur moyennant rétribution financière est une aubaine. En ce sens qu’après la certification, les modules comme nous l’avions vu précédemment sont inclus dans les versions futures d’Open ERP. Gâteau sur la cerise, le module certifié bénéficie du contrat de maintenance Open ERP. Ce contrat qui stipule entre autres conditions, qu’Open ERP se charge d’assurer la correction d’éventuels bugs , de migrer et d’adapter ce module à chaque nouvelle sortie d’Open ERP. Comme disait l’autre, que veut le peuple ? Nous y voilà ! « Migrer et adapter ce module » En effet si, à chaque nouvelle version d’Open ERP, les modules nous sont livrés avec leur évolution ceci éviterait des coûts supplémentaires de développement interne nécessaire pour garantir la conformité du module précédemment développé avec la nouvelle version. Ceci permettrait donc à l’entreprise dans le futur, d’avoir l’assurance complète – puisque stipulé contractuellement via le contrat de maintenance - que les modules développés auparavant évolueront de manière transparente. Par le biais de ce contrat de maintenance, outre la correction et l’évolution du noyau interne d’Open ERP, l’éditeur assure donc une évolution des modules – plus particulièrement les modules spécifiques. L’évolution des modules spécifiques étant assurée en grande partie par le processus de certification. Ainsi, la certification apporterait des profits aussi bien à l’équipe projet qu’au client. Bien que la majorité des recommandations faites pour mener à bien le projet se font au niveau de la maîtrise d’œuvre, il est opportun de présenter les avantages qu’ont les deux parties à penser à la certification Du côté de l’équipe projet ce sont notamment : - L’économie en temps et en argent : cherté de la découverte de bugs tardifs, migration complexe de version… - Le fait de pouvoir gagner la confiance du client - Notoriété accrue : Via la certification, l’entreprise peut redorer son blason. En effet, c’est l’occasion idéale et rêvée pour l’équipe projet de (re)donner de la visibilité à leur entreprise en participant à l’enrichissement des fonctionnalités d’Open ERP – qui est d’ailleurs distribué dans plusieurs pays. N.AKADIRI Page 40
  • 42. Les avantages que tire le client à exiger auprès de la maîtrise d’œuvre la production de modules certifiés sont les suivants : - Pouvoir migrer facilement son module vers les nouvelles versions de l’ERP tout en conservant la cohérence d’ensemble - S’affranchir de passer différents contrats de maintenance avec différents éditeurs de modules. D’autant plus qu’Open ERP dispose de plusieurs modules mais plus encore d’une centaine de modules étroitement imbriqués ! Cependant il y a toujours des possibilités que l’entreprise fasse une modification ultérieure sur le module certifié. Il revient donc au chef de projet d’interdire, dans une clause contractuelle - entre lui et la maîtrise d’ouvrage - l’ajout de modules non certifiés aux modules que son équipe aurait développé. Ceci afin de s’assurer que les évolutions fonctionnelles et/ou techniques des modules livrés suivront la même courbe qualité que leur développement initial. Plus encore, il lui revient aussi d’exiger avant tout développement que l’ensemble des modules dont pourraient dépendre son module soient certifiés ! Agissant ainsi tel un conducteur qui conduit avec prudence sur la route en prenant tout d’abord soin de son véhicule puis en respectant le code de la route mais surtout en étant vigilant. En effet, ce conducteur, même s’il prend toutes ses précautions, n’est pas sûr qu’un automobiliste tierce ne vienne le mettre en danger. On comprend à travers cette métaphore du conducteur et de la voiture l’importance d’exiger des modules certifiés de bout en bout. En somme, le processus de certification ne résout pas totalement le problème d’intégration des modules mais en limite nettement les effets néfastes. Nextma pourrait donc penser à certifier ses modules. Ceci pourrait lui permettre, par ailleurs, de supplanter les différentes sociétés opérant dans le même secteur à l’échelle nationale mais aussi de contribuer à sa notoriété sur le plan international. Ceci à travers la visibilité qu’elle pourrait acquérir par la certification de modules et l’intégration de ces derniers à la suite logicielle. La certification serait donc un élément important à ne pas négliger dans tous les aspects de son projet. Cependant, il y a un hic: “The only limitation is that if a bug or a problem in the migrations results from changes which happened after the certification, they will not be covered by the bugfix guarantee.” [w5] Autrement dit, après le processus de certification, si un bug survient malgré tout, Open ERP ne le prend pas en charge. Ce qui nous ramènerait au problème de départ ! N.AKADIRI Page 41
  • 43. Enfin, de façon plus générale, n’oublions pas que parler d’une démarche qualité revient à parler d’une application de la qualité à tous les processus entrant en jeu au niveau de Nextma - établissement du cahier des charges, recrutement des développeurs…Ainsi, mettre en place une démarche qualité reviendrait, outre l’aspect certification, à favoriser au niveau de l’équipe projet – et de façon plus globale au niveau de l’entreprise – l’émergence de nouvelles méthodes organisationnelles, techniques, managériales et autres permettant d’améliorer la qualité des développements de modules. Ceci entrainera inéluctablement une maintenance des modules moins « lourde » et donc pourra résoudre le problème d’intégration des modules – principalement dans leur aspect évolutif. 6- Cycle de vie préconisé Bien que cette partie aurait bien pu être mise en tête de la section « Démarche améliorée de gestion de projet », je l’ai volontairement mise à la fin car quoique l’on puisse dire, le cycle de vie s’adopte non seulement en fonction de certains paramètres (risques, maturité de l’équipe…) mais surtout en fonction du terrain. Le choix est donc laissé au chef de projet de faire jouer son ingéniosité ou son expérience sur son projet qui devra conduire à une meilleure intégration des modules. Nonobstant ce constat, je me permets de préconiser un cycle que je trouve plus adéquat. De mon point de vue, l’adoption de méthodes agiles pourrait permettre de produire des modules plus adaptatifs. Soyons clair ; je ne viens pas ici faire l’apologie des méthodes agiles, non pas que je les dénigre mais je reste pragmatique. En effet, les méthodes adoptées en général pour les projets ne sont pas forcément mauvaises en soit mais c’est l’usage qui en est fait qui pose généralement problème. Il en est de même pour les méthodes agiles. Voyons à présent, quels ont été les principes fondateurs de ces méthodes dites agiles. Suite à des constats récurrents de mauvaise définition de besoins, de manque de communication entre les différentes entités d’un projet, de l’augmentation du nombre de projet à effet tunnel, des experts se sont regroupés afin de proposer des solutions adéquates. Ainsi, sont nées les méthodes agiles. Ces dernières s’axent autour de 4 valeurs principales qui privilégient, comme le mentionne le manifeste agile [w6] : - Les individus et leurs interactions plus que les processus et les outils. - Des logiciels opérationnels plus qu’une documentation exhaustive. - La collaboration avec les clients plus que la négociation contractuelle. - L’adaptation au changement plus que le suivi d’un plan. N.AKADIRI Page 42
  • 44. L’utilisation d’une méthode en particulier des méthodes agiles pourrait augmenter la qualité – au sens large - du contrôle des modules. Nous avons donc vu que les quatre valeurs fondatrices des méthodes agiles donnent priorité aux individus et aux interactions, aux logiciels opérationnels, à la collaboration étroite avec le client et à une adaptation face au changement. Dans notre cas, la deuxième et la quatrième valeur créent plus de problèmes qu’ils n’en résolvent. En effet, faut-il effectivement privilégier des modules fonctionnels à une documentation exhaustive ? Si le but est de produire des modules sans les rendre au maximum évolutifs – comme à l’accoutumée - alors oui ! Car la documentation minimale peut être appréciée dans ce cas. Or, nous sommes dans une perspective où nous souhaitons produire des modules plus évolutifs. On comprend donc aisément que la documentation dans une telle situation est de rigueur. Bien plus encore, elle se soit d’être la plus exhaustive que possible. Quant à la quatrième valeur qui préconise une réactivité face aux éventuels changements - en cours de projet - du client, nous sommes réticents à cette idée. Car, selon les dires d’un collègue, il y aurait un projet de développement de module en cours actuellement à Nextma qui aurait dû prendre fin il y a de cela bien longtemps mais qui ne cesse d’être repousser aux calendes grecques. Pour cause, les besoins sans cesse renouvelés du client lors de la phase de recette. Il est donc plus judicieux d’établir un PV explicite des besoins pour éviter de rallonger les délais qui sont déjà assez durs à tenir. Ainsi chaque nouvelle demande fera l’ajout d’une prestation individuelle. En résumé, pour développer des modules hautement évolutifs, on peut faire de l’agile tout en restant lucide ! D- Synthèse 1- Que retenir ? Que de choses ont été dites. Si vous vous sentez perdu et ne savez plus où donner de la tête, c’est le moment de faire le point. Il a été tout d’abord exposé le concept d’ERP puis celui de la relation étroite qu’entretiennent les entreprises avec ce genre d’outils. Dans le même ordre d’idée, nous avons vu qu’Open ERP comme ses confrères d’ERP est un véritable joyau d’entreprise, car d’une utilité évidente pour les acteurs - N.AKADIRI Page 43
  • 45. aussi bien interne qu’externes - de l’entreprise. Son paramétrage sur mesure permet d’adapter son ERP à chaque entreprise. Cependant, ce paramétrage n’est pas infini. Et lorsque les limites sont atteintes, on tire profit d’un autre aspect de l’ERP qui est son architecture modulaire. Mais là encore les déconvenues surviennent relativement tôt. En effet lors de la migration de version, certains modules deviennent désuets. Alors, entre besoin de migrer et besoin de maintenir la cohérence d’ensemble de ses modules, l’entreprise fait face à un dilemme qui n’est toutefois pas totalement insolvable. Une solution toute simple serait d’apprendre à ne migrer qu’en cas d’extrêmes besoins et non pour une propension à « être à la page ». Si malgré tout le besoin s’en fait sentir et qu’on a plus le choix alors il faut prendre des précautions. Précautions qui débutent depuis la phase de gestion du projet. Ce sont ces précautions que j’ai tenté d’énumérer dans les pages précédentes. Elles s’axent principalement autour de deux points : - le choix de la méthode de gestion de projet - la certification de modules (important) La certification, comme nous avons pu le voir, ne résout pas totalement le problème mais permet de délocaliser la charge de travail en un seul endroit : Au niveau de l’éditeur – qui à priori connaît mieux son logiciel - et non plus au niveau de l’équipe projet. Ceci permet donc de masquer la problématique d’évolutivité des modules. Figure 20 : Synthèse Réflexion N.AKADIRI Page 44
  • 46. Ces aspects d’ordre managériaux et techniques à mettre en place au niveau de Nextma doivent s’accompagner d’autres aspects tout aussi importants – car servant de pilier à la démarche - que sont : les aspects juridictionnels (interdiction d’ajout de modules non certifié, définition formelle et définitive des besoins…). Ces clauses contractuelles établies de façon appropriée aideront le chef de projet à garantir la pérennité de ses modules dans le temps. Enfin, il a été préconisé qu’un cycle de vie reposant sur les méthodes dites agiles soit adopté. En effet, nous avons vu plus haut que le choix du cycle de vie est dicté par tout un ensemble de critères notamment sur le critère expérience du chef de projet. Des recommandations ont cependant été faites pour l’adoption de méthodes agiles par Nextma lors de leur gestion de projet de développement de modules. Choix qui semble plus opportun en raison de la forte réactivité qu’exige ce genre de méthodes avec le client. 2- Limites de ma réflexion On a donc essayé dans les lignes qui ont précédé de faire une synthèse des points clés à cibler pour améliorer l’efficacité de la démarche de gestion de projet au niveau de Nextma en vue de conduire à des modules adaptatifs et évolutifs. Cependant l’honnêteté intellectuelle exige de moi que je vous fasse à présent part des problèmes que peuvent soulever tout ce que j’ai eu à dire. En tout premier lieu, Cette démarche ne s’applique qu’au développement de modules complexes et plus encore aux sociétés possédant un effectif élevé pouvant être affecté à un projet de développement de modules. Inutile de faire une usine à gaz pour développer un module basique ! Je pense donc que les points énoncés plus haut pour améliorer la démarche de gestion de projet ne pourront être réellement appliqués par Nextma que lorsqu’elle disposera d’un effectif bien plus conséquent. Pour s’en convaincre il suffit de se rappeler de ma proposition d’investir dans la R&D. Demander à une entreprise telle que Nextma ne disposant pas de ressources – humaines, financières…- colossales de prendre ce risque est un pari osé. Par ailleurs, la certification de modules qui représente indéniablement un atout peut très vite être synonyme de baisse de revenus pour certains. En effet, il est indéniable qu’une telle certification puisse faire grincer des dents bon nombre d’entreprises – dont probablement Nextma - qui « vivent » de cette adaptation constante de ces modules. Car une telle affaire, bien qu’utile, risque de sonner le glas de leur commerce prolifique. Alors entre la théorie et la pratique, le fossé risque d’être abyssal. N’oublions pas non plus que, demander au chef de projet de s’assurer que l’ensemble des modules dont pourrait dépendre son projet soit certifié, quitte à ne pas s’engager sur un projet N.AKADIRI Page 45
  • 47. « juteux », risque de ne pas être toujours chose facile à faire…Et quand bien même les entreprises – en particulier Nextma - trouveront l’importance de certifier, la limitation dans le contrat de maintenance d’Open ERP poserait encore un problème. En effet, le processus de certification du module peut ne pas déceler des problèmes qui se révèleront bien plus tard. Scénario qui nous conduirait inéluctablement à dépenser à nouveau en coût et en argent… Concernant le cycle de vie, bien que la réactivité soit un point essentielle dans l’application des méthodes agiles, j’ai voulu restreindre un tant soit peu cette réactivité qui donne par exemple au client la possibilité de changer au besoin le contenu du cahier des charges. En effet, laisser le client donner libre cours à ses désirs ou plutôt à ses caprices, c’est aussi lui donner la possibilité de mettre en péril la budgétisation d’un projet qui prend en compte la certification des modules et par conséquent annihiler tous les efforts qui auront pu être mis en place pour permettre une meilleure adaptabilité et évolutivité des modules. Ce n’est donc plus une méthode agile a proprement parlé qui a été recommandé à Nextma mais plutôt une méthode pseudo-agile car ne prenant pas en compte tous les principes fondateurs des méthodes agiles. Notons enfin qu’étant resté dans la logique que Nextma ne soustraite pas une partie de ses développements, l’ensemble des six recommandations formulées – Gestion de changement, démarche qualité…- est encore un tant soit peu faisable. Mais si Nextma se décide, dans un avenir proche ou lointain, pour une raison ou pour une autre à sous-traiter une partie de ses développements, un niveau de complexité supérieure s’ajoutera car il faudra effectuer le suivi des recommandations susmentionnées chez tous le ou le(s) sous-traitant(s)… N.AKADIRI Page 46
  • 48. Partie 6 : Bilan Si c’était à refaire, qu’aurai-je fais, quelles sont les leçons que j’ai pu en tirer ? En ce sens, Nick Nolte disait : «J'ai commis bon nombre d'erreurs mais je n'ai aucun regret. Parfois c'est le seul moyen d'apprendre.». Cette pensée résume bien le contenu auquel on peut s’attendre dans cette dernière partie. A- Bilan technique Tous mes stages au cours de ces trois dernières années m’ont permis de m’imprégner du processus courant de développement d’un logiciel : de l’analyse des besoins à l’implantation du logiciel en passant par la phase de modélisation. Durant ce stage, bien qu’ayant étudié d’une façon ou d’une autre des modèles (analyse des interactions des modèles de l’ERP) ou fait de la modélisation (base de données en local sur le portable), j’ai pu noter une petite différence. Dans le sens où j’ai été amené à comprendre une architecture déjà existante (celle d’Open ERP) afin de m’y conformer. Je pense que cela est plus proche de la réalité des projets informatiques dans les entreprises où l’on n’a pas toujours la possibilité de concevoir une solution à partir de « zéro» tel qu’on le fait souvent lors des travaux pratiques à l’école. Aussi, à travers ce stage, j’ai pu me refaire une idée sur les Framework. En effet, ces outils de rêve qui sont de véritables bijoux de programmation impressionnent de par leurs prestations. Cependant, quand on se met à les utiliser allègrement, sans s’être imprégné de toute la mécanique qui se cache derrière - ce qui est le cas de la majorité des développeurs - cela peut causer à la longue un problème - dans la formation des développeurs. Ces derniers perdront ainsi progressivement les connaissances de base de la programmation et/ou de certains langages car voilées par le Framework. Dans le même ordre d’idée, les API, du genre Google Maps Api, mises souvent à la disposition des développeurs sont utiles mais dès qu’elles subissent une restructuration profonde de l’éditeur, on peut être contraint à revoir toute son application ! Par ailleurs, comme je le mentionnais dans ma lettre de motivation lors de la recherche du stage, au cours des deux stages précédents - l’un en DUT Informatique et l’autre en licence Miage - j’ai eu à développer respectivement un client léger (utilise un navigateur internet) et un client lourd (application de bureau). Je souhaitais donc m’investir dans le développement d’une application N.AKADIRI Page 47