Comprendre la dette technique

Selon Wikipédia : “La dette technique (également appelée dette de conception ou dette de code) est “un concept de la programmation qui reflète le surcroît de travail de développement engendré lorsqu'on retient un code facile à mettre en œuvre à court terme plutôt que d'appliquer la meilleure solution globale”.

La dette technique peut être comparée à une dette financière. Si la dette technique n'est pas remboursée, elle peut accumuler des ‘intérêts’, rendant plus difficile la mise en œuvre de modifications ultérieures. Une dette technique non traitée accroît l'entropie logicielle. La dette technique n'est pas nécessairement une mauvaise chose, et parfois (par exemple dans le cadre d'une preuve de concept) elle est nécessaire pour faire avancer les projets. En revanche, certains experts affirment que la métaphore de la “dette technique” tend à en minimiser l'impact, ce qui se traduit par une priorisation insuffisante du travail nécessaire pour la corriger.”

Le concept de dette technique vient du monde du génie logiciel, mais il s'applique tout autant au monde de l'informatique et de l'infrastructure d'entreprise. Comme en génie logiciel, nous concevons nos systèmes et nos réseaux, et prendre des raccourcis dans nos conceptions — ce qui inclut le fait de travailler avec des conceptions loin d'être idéales, d'intégrer du matériel existant et d'autres mauvaises pratiques de conception — engendre de la dette technique. L'une de ses formes les plus marquantes provient du fait d'investir dans le “passé” plutôt que dans l'“avenir”, et elle est bien souvent déclenchée par le biais des coûts irrécupérables (autrement dit, jeter de l'argent par les fenêtres pour en sauver une dépense déjà perdue).

Il est facile de constater ce phénomène dans les entreprises au quotidien. De nouveaux plans sont élaborés pour l'avenir, mais avant leur mise en œuvre, on investit pour faire perdurer la conception d'un ancien système, la rendre plus performante, l'étendre ou autre. Cet investissement se transforme alors soit en une perte financière quasi immédiate, soit, plus souvent, en une incitation à ne pas investir dans les conceptions futures aussi rapidement, aussi complètement, voire pas du tout. Dans les pires cas, l'investissement dans le passé peut devenir paralysant.

Cela se produit de multiples façons et est généralement involontaire. Souvent, des investissements sont nécessaires pour maintenir un système existant en bon état de fonctionnement et, dans des conditions normales, ils seraient simplement réalisés. Mais dans une situation où une évolution future est nécessaire ou potentiellement planifiée, cet investissement peut poser problème. Dans bien des cas, une meilleure analyse des coûts et une meilleure planification du tri des priorités peuvent toutefois y remédier.

Pour prendre un exemple non technique, imaginez que vous possédez une voiture ancienne qui vous a bien servi mais qui doit être mise au rebut dans trois mois. D'ici trois mois, vous prévoyez d'investir dans une voiture neuve, car l'ancienne n'est plus rentable en raison de besoins d'entretien continuels, d'un rendement moindre, et ainsi de suite. Mais avant l'échéance de votre plan d'achat à trois mois, la vieille voiture subit une panne mineure et nécessite désormais un investissement conséquent pour continuer à rouler. Injecter de l'argent dans la vieille voiture constituerait un nouvel investissement dans la dette technique. Plutôt que de dépenser une somme importante pour faire rouler une vieille voiture pendant quelques mois, avancer le calendrier d'achat de la nouvelle est de toute évidence radicalement plus sain sur le plan financier. Avec les voitures, nous le percevons aisément (dans la plupart des cas). Nous économisons de l'argent, potentiellement beaucoup, en achetant rapidement une voiture neuve. Si nous investissions massivement dans l'ancienne, soit nous perdons cet investissement dans quelques mois, soit nous risquons de remettre en cause notre planification financière solide pour l'achat de la voiture neuve, déjà arrêtée. Dans les deux cas, c'est mauvais financièrement.

L'informatique fonctionne de la même manière. Dépenser une somme importante pour entretenir un ancien système de messagerie six mois avant une migration planifiée vers un système de messagerie hébergé serait probablement très imprudent. L'investissement est soit perdu presque immédiatement lorsque l'ancien système est mis hors service, soit il compromet nos bons processus de planification et nous conduit à ne pas migrer comme prévu et à fournir un travail médiocre à nos entreprises, parce que nous avons laissé la dette technique guider nos décisions plutôt qu'une planification appropriée.

Souvent, une mauvaise opération de tri des priorités ou une délégation inappropriée du pouvoir de trancher à des acteurs peut être le facteur qui provoque des investissements d'urgence dans la dette technique plutôt que des investissements rapides et tournés vers l'avenir. Ce n'est là qu'un des domaines où des améliorations majeures peuvent répondre aux problèmes, mais c'en est un de taille. Cela peut aussi être atténué, dans certains cas, par une planification du type « et si » consistant à préparer des plans d'investissement contingents aux urgences courantes ou prévisibles susceptibles de survenir, ce qui peut être aussi simple que des besoins d'extension de capacité dus à la croissance, survenant avant que la planification des systèmes n'entre en jeu.

Un autre excellent exemple de dette technique courante est l'extension de la capacité de stockage des serveurs. C'est un scénario que je rencontre assez fréquemment et qui illustre bien la dette technique. Il est courant qu'une entreprise achète des serveurs dépourvus d'une grande capacité de stockage interne. Soit immédiatement, soit plus tard, davantage de capacité s'avère nécessaire. Si cela se produit immédiatement, on constate que le serveur acheté constituait une forme de dette technique due à une conception inadaptée et représente manifestement une faille dans le processus de planification et d'achat.

Mais un exemple plus courant est le besoin d'étendre le stockage deux ou trois ans après l'achat d'un serveur. Les options d'extension habituelles consistent à ajouter une baie de stockage externe à raccorder au serveur ou à modifier le serveur pour qu'il accepte davantage de stockage local. Ces deux approches tendent à représenter d'importants investissements dans un serveur déjà ancien, un serveur qui a aisément franchi quarante pour cent ou plus de sa durée de vie utile. Dans bien des cas, un investissement identique ou à peine supérieur dans un serveur entièrement neuf peut se traduire par du matériel neuf, des processeurs plus rapides, davantage de mémoire vive, le stockage requis, conçu et construit sur mesure, une durée de support alignée et renouvelée, une empreinte réduite au centre de données, une consommation électrique moindre, des technologies et fonctionnalités plus récentes, de meilleures relations avec les fournisseurs, et plus encore, tout en conservant le serveur d'origine pour le réutiliser, le mettre au rebut ou le revendre. D'un côté, on dépense de l'argent pour soutenir le passé ; de l'autre, on peut souvent dépenser une somme comparable pour l'avenir.

La dette technique est un facteur paralysant pour de nombreuses entreprises. Elle accroît le coût de l'informatique, parfois de manière significative, et peut conduire à des niveaux de risque élevés du fait d'un manque de planification et d'une dépense reposant majoritairement sur l'urgence.