Vous êtes ici

Comment figer un projet en mutualisant son code

Antoine est ingénieur logiciel dans une grande entreprise. Il a plus de 30 ans d'expérience dans son domaine. Il y a quelque temps, il 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 très 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 Antoine, 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. Antoine 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. Et au niveau fonctionnel, même s'il y a des similarités, les différences sont loin d'être négligeables.

Antoine 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. Les différences fonctionnelles entre les deux projets pourraient être gérables, en définissant une architecture convenable. Mais le cycle de vie du projet de recherche impose des contraintes très importantes : 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. 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.

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. Antoine lui conseille de simplement communiquer sur la réutilisation du code existant. Alain, malgré une expérience bien inférieure à celle d'Antoine, s'entête et impose sa décision. Il faut dire que dans l'entreprise, les compétences techniques ont peu de poids par rapport aux rôles d'encadrement. Antoine, 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. Antoine 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. Antoine, 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, Antoine attend toujours. Le nouveau code ne répond qu'aux besoins du nouveau projet, et aucune fonction du projet de recherche n'est portable directement sur ce nouveau code. Cependant, Alain communique avec enthousiasme sur le succés de la mutualisation du code... Antoine reprend 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

La conséquence principale en est un retard de six mois pris par le développement pour le projet de recherche. Une conséquence secondaire en est la démotivation de plusieurs développeurs de l'équipe.

Comment en arrive-t-on à ce genre de situation ? Une explication, déjà évoquée en partie : le peu d'importance accordée par l'entreprise aux personnes ayant décidé de progresser dans la technique. Même un développeur 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.

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)

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.)