Jérémy Jeanson's blog
chasseur de bugs depuis .net 1.0

La dette technique est un sujet difficile à traiter. Nombre d’éléments peuvent compliquer les choses :

• Technologies.
• Dépendances.
• Domaines fonctionnels traités.
• Criticité de l’application pour les utilisateurs.
• Coût.
• Temps.
• …

Il peut y avoir aussi quelques soucis d’ordre "culturel" (autre manière de ne pas dire "politique") :

• Désintérêt pour les aspects techniques.
• Manque de motivation.
• Peur des régressions.
• …

Même si ce n’est pas facile, tout le monde peut surmonter ces problèmes, et résorber sa dette technique. Cela ne se fera peut-être pas rapidement. Il est préférable de l’accepter. Le jeu en vaut la chandelle.

Mais il est des situations qui peuvent compliquer les choses de manière irrémédiable. Je me propose de vous présenter ici trois cas réels, et vécus en ESN (à l’époque, on disait SSII, mais je m’adapte). Soyons claires tout de suite. Aucune des situations présentées ici n’est liée à mon emploi actuel, et j’en suis fort heureux. Travaillant aujourd’hui pour un éditeur, je crois que j’aurai beaucoup de mal à les vivre à nouveau. Contrairement aux éditeurs, les ESN ne sont souvent que "de passage" sur une application. Les développeurs / consultants qui assurent une mission à un instant T vivent donc "différemment" la dette technique. Personnellement, je n’ai jamais bien vécu cette expérience, et encore moins le fait que l’on me demande de la faire passe sous le tapis. C’est tabou. Il ne faut pas en parler au risque de déplaire au client. Bêtement, j’ai toujours pensé que le client adorerait qu’on lui remette un rapport sur celle-ci. Une ESN plus futée se rendrait peut-être compte que le sujet peut apporter d’autres prestations.

Premier cas

Il est une situation qui conduira systématiquement une entreprise ou une équipe à échouer. Une technique imparable qui conduit inévitablement dans le mur. Une sorte de botte secrète. Le saint Graal de l’échec.

La plupart des entreprises qui l’appliquent ne s’en rendent même pas compte :

Pour échouer à résorber sa dette technique, il suffit de ne pas admettre qu’elle existe.

Cette affirmation peut sembler grossière, mais elle résume ce que j’ai pu constater en un peu plus de 20 ans de métier. Une entreprise qui admet qu’elle a un problème finira toujours à un moment ou à un autre par le résoudre (même si cela n’est que partiellement).

Second cas

La dette technique est chronophage. Chaque évolution, ou correction prend plus de temps qu’il ne faudrait. Elle peut aussi être démotivante ou décourageante.

Malheureusement, il est des personnes que cela peut arranger. Il s’agit de personnes devenues dépendantes de cette même dette technique. Il peut s’agir de développeurs, ou d’une ESN. Ceux-ci ne feront pas en sorte de résorber la dette technique, car ce n'est pas dans leur intérêt. Ils préfèreront la faire passer sous le tapis. Bien évidemment, pour y arriver, il n’est pas question de parler de dette technique. Les termes préférés seront certainement liés à :

Une architecture trop complexe.

Une application impossible à documenter.

Un besoin d’expertise.

…

Ce qui est le plus risible, c’est que ces mêmes personnes pourront aussi dire "Trop peu intéressant. Autant le donner à une petite main".

Troisième cas

Le dernier cas est peut-être le plus traitre. Vous faites intervenir un "expert autoproclamé". Il s’agit d’un Consultant d’une ESN, souvent affublé d'un titre pompeux. Titre utilisé uniquement lors des présentations, car ce même consultant n’a pas forcément droit à autant d’éloges lors de son entretien annuel. L’usage de l’adjectif "autoproclamé" est un peu "décalé", je l’admets. Il s’agit pourtant de la terminologie employée par certains développeurs pour rire de la situation (rire jaune, bien évidemment). Dans certaines ESN, ces consultants peuvent être mieux considérés. Ce n’est malheureusement pas pour autant qu’ils échapperont à la description qui suit.

Ce pauvre consultant a l’habitude de conseiller une architecture technique "très évoluée". Il a une grande expérience dans la mise en place de celle-ci. Cependant, il n’a jamais été amené à la maintenir.

Après son départ, vous avez une nouvelle dette technique.

J’ai connu une ESN qui y avait trouvé son intérêt. Les travaux réalisés par le développeur étaient tellement compliqués qu’ils étaient certains de gonfler l’enveloppe allouée au projet. Suite à la mise en production, le client faisait évoluer l'application, et finissait par galérer. Après quelque temps, il revenait systématiquement vers l’ESN. Bien évidemment, les modifications apportées par le client "compliquaient" les choses. Le pauvre développeur / consultant devait prendre encore plus de temps pour ne pas perdre le travail vital réalisé par le client.

Cela ressemble à une blague. Pourtant, il s’agit d’un cas réel.

Conclusion

Pour éviter de vous retrouver dans une telle situation. Ouvrez les yeux. Observez. Dites les choses. À force de réflexion, d’échanges, et de travail, vous arriverez à résorber votre dette technique.

Si on veut vous vendre une architecture technique "novatrice", posez-vous des questions au sujet de son avenir, et de sa maintenabilité. Une bonne architecture est une architecture que l’on peut comprendre, maintenir, faire évoluer, et dont on peut parler facilement entre développeurs.