Comment figer un projet en mutualisant son code

Note : pour le contexte général, voir cet article.

Corentin a démarré un développement pour un projet de recherche. Quelques collègues l'ont ensuite rejoint. Il s'agissait de réaliser un démonstrateur, dans un domaine bien spécifique de la gestion de données. Le contexte était celui que l'on retrouve souvent dans un projet de recherche : définition des besoins assez floue, mouvante tout au long de la vie du projet, et intégration de sous-ensembles pas forcément très stables. Par ailleurs, le projet ne devant pas être mis dans les mains de véritables utilisateurs, il était possible de faire l'impasse sur un certain nombre de fonctions, comme la gestion des utilisateurs, la sécurité, etc.

Une fois le projet bien avancé, Alain, le responsable de l'équipe de développeurs dans laquelle travaille Corentin, vient le voir pour discuter d'un nouveau projet qui doit démarrer. Fonctionnellement parlant, l'application devant être développée dans le cadre de ce nouveau projet a un certain nombre de similarités fonctionnelles avec le démonstrateur du projet de recherche. Cependant, différence importante, il s'agit d'une application devant potentiellement être mise en exploitation.

L'idée d'Alain est de mutualiser le code des deux projets. D'abord en reprenant le code existant pour démarrer le nouveau projet, puis en ne gérant qu'un seul code source pour les deux projets. Corentin trouve l'idée très étrange. Les cycles de vie et les contraintes des deux projets ne sont pas du tout les mêmes. Pour le projet de recherche, un changement du modèle de données doit être possible à tout moment, l'architecture doit pouvoir évoluer de façon imprévue pour valider une nouvelle piste, etc. Et au niveau fonctionnel, même s'il y a des similarités, les différences sont loin d'être négligeables. L'effort nécessaire à l'intégration de ces contraintes serait disproportionné par rapport au gain espéré. Et les tailles des deux équipes de développement sont trop réduites.

Corentin conseille à Alain de ne pas retenir l'idée de la mutualisation du code source, mais plutôt de reprendre ce qui peut être repris du projet de recherche, et ensuite de laisser diverger les deux codes.

Il s'avère qu'Alain a en tête de faire un "coup" de communication : il désire montrer que les efforts déployés sur un projet de recherche auront permis la mise en exploitation d'une application. Corentin lui conseille de simplement communiquer sur la réutilisation du code existant. Alain, malgré une expérience bien inférieure à celle de Corentin, s'entête et impose sa décision. Il faut dire que chez GTF, les compétences techniques ont peu de poids par rapport aux rôles d'encadrement. Corentin, déjà échaudé sur ce point[1], décide de ne pas lutter. D'autant plus qu'un collègue de l'équipe annonce qu'il se fait fort de réécrire une grosse partie du code existant, de façon à obtenir le code mutualisé voulu. Et ceci en moins de deux mois. Corentin sait que ce ne sera pas possible. Ce collègue fait partie de la catégorie des débutants experts. Il ne mesure pas l'étendue de ce qu'il ne connait pas, et n'a pas assez d'expérience en réalisation d'applications logicielles, bien qu'il croie le contraire.

Le nouveau développement démarre. Corentin, de son côté, se retrouve bloqué dans le développement d'une des demandes du projet de recherche, car il a besoin des fonctions fournies par le code qui va être réécrit. Il met donc en attente son travail en cours, et passe à autre chose.

Six mois plus tard, Corentin attend toujours. Le nouveau code ne répond quasiment qu'aux besoins du nouveau projet. Cependant, Alain communique avec enthousiasme sur le succés de la mutualisation du code... Corentin est obligé de reprendre ses développements sur l'ancien code, seul moyen pour lui d'avancer. Il y a donc toujours deux codes...

Que conclure ?

Dans ce que nous venons de voir, deux éléments sont à souligner :

• le responsable de l'équipe de développeurs n'est pas assez expérimenté pour comprendre l'impact de sa décision
• un membre de l'équipe le conforte dans son idée, en sous-estimant très fortement la quantité de travail nécessaire

Comment en arrive-t-on à ce genre de situation ? Une explication, déjà évoquée en partie : le peu d'importance accordée par GTF aux personnes ayant décidé de progresser dans la technique. Même un ingénieur ayant plusieurs dizaines d'années d'expérience a moins de poids dans la prise de décisions techniques qu'un responsable d'équipe avec une expérience technique bien inférieure. Il semblerait que la source principale du problème soit la forte incompréhension par l'entreprise du nombre d'années et des efforts nécessaires à l'acquisition de compétences[2] avancées. Par ailleurs, cette acquisition de compétences est perçue comme étant un coût, plutôt qu'un investissement.

Bien entendu, les conséquences sont plutôt négatives : démotivation ou départ des meilleurs, applications logicielles développées peu fiables, parfois éloignées des besoins des utilisateurs, et développements longs et coûteux.

A noter que le retard pris par le développement pour le projet de recherche ne semble avoir choqué ni le responsable d'équipe, ni le développeur qui s'était engagé à mettre en place la mutualisation du code, ni le chef du projet de recherche (il n'a pas été fait allusion à ce dernier dans la présentation ci-dessus, pour ne pas la compliquer. Nous aurons l'occasion de nous intéresser, dans un article à venir, à l'organisation en mode projet de l'entreprise.)

Mise à jour

Un peu plus de deux ans après la décision de mutualiser, le collègue qui pensait pouvoir écrire une souche commune est revenu voir Corentin, entre-temps parti sur d'autres projets, pour lui dire qu'il reconnaissait avoir eu tort...

Notes

[1] Nous aurons l'occasion d'aborder dans d'autres articles la problématique de non-reconnaissance des compétences techniques

[2] Compétence : connaissance approfondie, reconnue, qui confère le droit de juger ou de décider en certaines matières (Petit Robert)