Gestion de projet : premier échec.

Ça fait un an, presque jour pour jour que j’ai commencé un projet OpenERP pour une boulangerie. Le but était d’approfondir ma connaissance d’OpenERP tout en travaillant au contact d’une petite entreprise de proximité.

Actuellement trois logiciels sont utilisés : un logiciel de gestion de commandes qui n’est plus maintenu, un logiciel de caisse et son pendant back-office. L’idée était de retrouver dans un seul environnement toutes les fonctionnalités (et les données !) utilisées jusqu’alors en y ajoutant quelques fonctions. Le point important étant d’étendre l’informatisation de l’entreprise, jusque là cantonnée à la caisse et la prise de commandes clients, à la gestion des stocks et de la production(avec prédiction des quantités à produire selon l’historique).

La première réunion a permis de dresser les grandes lignes du cahier des charges et de préciser que pour éviter tout problème(dérive du projet, difficulté de maintenance par un tiers…) on limiterait les développements spécifiques. Quelle belle intention…

Avant de toucher à la partie « production », il fallait ré-implémenter les deux grosses fonctionnalités de caisse déjà présentes sur le logiciel historique et absentes sur OpenERP :

• synchronisation de la vente en cours des vendeurs d’une caisse à l’autre
• la gestion des titres restaurants et des tickets d’avoir correspondants

J’ai donc commencé par prendre en mains l’API javascript d’OpenERP pour surcharger le module de point de vente. Consciencieux, je multiplie les modules afin d’obtenir un ensemble de fonctionnalités réutilisables par la communauté. Au bout de quelques semaines de développements, les tests sur le matériel cible sont très inquiétants : les machines sont âgées et le processeur ne suit pas. Après l’achat d’un serveur, d’un onduleur et d’équipements réseaux il m’était difficile de demander à changer ces PC tactiles (monoblocs !). C’est la panique : en trois jours, je suis obligé de re-développer un front-end de caisse complet avec une libraire graphique python (WXPython). Heureusement, tous est publié en XMLRPC nativement dans OpenERP(même les rapports) donc l’interopérabilité est maximale. Le temps pressant, mon code OpenERP est de moins en moins modulaire… De l’ultra spécifique donc. Impossible à réutiliser ailleurs, beaucoup moins propre et difficile à maintenir par quelqu’un d’autre que moi. Tout ce que je voulais éviter.

Il est maintenant évident que le projet va se prolonger au delà de l’été comme c’était prévu, d’autant plus que le cahier des charge à tendance à augmenter au fur et à mesure que les développements avancent. Je me retrouve à poursuivre le développement à distance, en parallèle de mes études. En octobre premier coup de théâtre : l’entreprise à été démarchée par un entrepreneur du coin qui propose un logiciel dédié à la production en boulangerie… mais qui ne fait pas de caisse. Il est proposé de créer une interface avec le logiciel de caisse historique. Vu le prix demandé et l’incertitude de cette interface, la patronne m’assure que l’on continue le projet : on démarrera les tests en janvier afin d’éviter d’essuyer les plâtres avant Noël.

J’ai donc continué à intégrer toujours plus de fonctionnalités selon le temps dont je disposais. Les fonctions de caisse terminées je pouvais enfin attaquer la prévision des ventes pour l’interface de production. Nous faisons un point fin décembre : l’interface de production possède les fonctions voulues mais le design est trop sobre : les listes ne seront jamais remplies par les  employés. Le design de l’écran de caisse est aussi à reprendre. Il faudrait également que je fasse de la saisie car c’est trop chronophage pour la patronne.

Je commence donc à m’atteler à la tâche en début d’année. Subitement, en février, je n’ai plus de réponse à mes emails. La raison : des employés en arrêts de travail  ralentissent le projet. Mais oui, le projet continue bien.

Tout ça pour apprendre aujourd’hui que le projet s’arrête car un consultant de la chambre des métier leur a fait découvrir de nombreuses possibilités … cachées dans le logiciel de gestion historique. Je suppose que d’autre part, ne pas pouvoir m’engager sur des prestations de maintenance sur le long terme effraie.

Bilan : j’ai passé beaucoup de temps à développer quelque chose qui n’est pas réutilisable et ne servira jamais. Je ne regrette pas d’avoir accepté le projet car j’ai beaucoup appris, techniquement et humainement mais ça n’en est pas moins frustrant. Ce qui m’a le plus plu c’est cette interaction avec l’entreprise : il faut se mettre dans leur peau pour comprendre leur méthode de travail et leurs besoins. On apprend beaucoup de chose sur le métier. C’est bien plus intéressant que de développer dans son coin un programme purement technique, comme j’ai pu l’expérimenter lors de mon stage au ministère de la défense.