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

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