Voici ce qui peut être l’extrait d’un dialogue entre un client et le directeur de projet d’un fournisseur de services informatiques

Le client: Ma direction métier me demande de rendre mon SI adaptable à une nouvelle fonctionnalité « X ». En combien de jours pensez-vous pouvoir me la rendre disponible ?
Le directeur de Projet : Euh je ne sais pas, mais çeci ne m’a pas l’air du tout simple comme fonctionnalité, cela risque d’être cher…
Le client : Comment çà cher, vous m’aviez pourtant vendu que la SOA permettait justement de s’adapter facilement à un contexte économique changeant. Je peux vous ressortir votre réponse à mon appel d’offres si vous voulez.
Le directeur de Projet (sentant monter la nécessité d’une argumentation plus convaincante mais qu’il sait par avance hasardeuse) : Enfin oui, mais il faut compter le coût des différents tests (unitaires, intégration, non-régression, etc ..). En plus il existe un coût d’entrée incompressible dû à la « courbe de corrélation de l’apprentissage et des charges implicites et systémiques induites… »
Le client (essayant difficilement de refaire le fil de l’argument précédent) : Vous m’aviez dit quelque chose de similaire la dernière fois et bien qu’ayant mis le prix, mon SI n’est toujours pas aligné avec mon besoin métier.
Le directeur de Projet (forcé d’écourter la discussion): Vous ne préféreriez pas qu’on discute de tous ces points en réunion, nous aurons plus d’éléments concrets ….

Ce type de dialogue est symptômatique d’un système d’information sclérosé, très peu enclin à évoluer et dont le coût de la moindre modification devient prohibitif.

En d’autres termes, le système d’information a encaissé tout au long de sa vie, une entropie (au sens thermodynamique du terme signifiant « désordre ») croissante ayant paralysé son évolutivité et son adaptabilité. Cette entropie est le fruit du renoncement de la qualité de code au profit de la productivité. Or la qualité devra de toute façon être payée un jour, et certainement avec des intérêts, d’où le terme de « dette technique ».
Autant, tout développeur ayant écrit au moins une ligne de code dans sa vie concevra certainement très facilement cette notion, autant celle-ci reste complètement ignorée des directions de systèmes d’information qui en sont cependant les principales victimes.

Pour bien saisir le sens profond de cette métaphore, il est utile d’établir le parallèle avec l’endettement financier.

Qu’est ce qu’on emprunte et à quel taux?

Comme toute dette, celle-ci découle d’un emprunt préalablement contracté auprès d’un organisme de crédit plus ou moins accommodant.
Le développeur dispose alors d’une carte de crédit débitée immédiatement lorsque le code manque de qualité. Autrement dit, il emprunte le temps nécessaire à produire du code de bonne qualité, temps qui sera remboursé en tant que dette technique avec un taux d’intérêt jamais fixe. Celui-ci dépendra d’ailleurs de plusieurs paramètres.

1. Le plus palpable, étant bien évidemment la quantité du produit emprunté, ici le temps.
Ainsi plus court sera le raccourci technique (plus grand sera le temps emprunté) et plus lourde sera la dette technique. On remarquera que la dette technique n’est pas seulement la conséquence d’un raccourci technique, elle peut résulter de l’inverse, à savoir une complexification inutile et non maitrisée du code. Dans ce cas, le produit emprunté reste le même (le temps), mais il s’agit plutôt du temps nécessaire à la simplification et au refactoring du code.

2. L’environnement technique. Lorsque celui-ci est hautement inflationniste, c’est-à-dire qu’il héberge une multitude de composants (services, classes, etc …) ayant des liens d’interactions forts (pas forcément justifiés) les uns avec les autres, l’effet de la dette technique sera d’autant multiplié.

3. La réactivité des acteurs applicatifs à déceler les effets de cette dette et effectuer les actions correctrices correspondantes.

4. Le volume de fonctionnalités nouvelles et surtout interdépendantes de chaque nouvelle version du SI

Quels sont ses effets ?

La dette technique paralyse d’abord le système d’information, à plusieurs niveaux (performance, robustesse, évolutivité, maintenabilité, etc ..), mais agit aussi sur certains facteurs macroéconomiques du projet tel que son coût total ainsi que le ressenti global de l’utilisateur final.
En supposant constant le volume de fonctionnalités livrées à chaque version d’une application, superposons sur un même graphique les métriques suivantes :

  • Le coût total du projet
  • le taux de satisfaction (avec et sans dette technique)
  • le montant empirique de la dette technique

On obtient alors le graphique suivant.

image

Premier élément d’analyse, le coût total du projet n’est plus linéaire (devenant même erratique) lorsque la dette technique atteint son seuil critique (itération 5). Ceci est dû au fait que les rouages de l’application s’abîment ce qui augmente le coût intrinsèque d’une fonctionnalité supplémentaire. L’intégration d’une nouvelle fonctionnalité avec le reste du SI étant rendue difficile par un socle applicatif devenu peu robuste, ce qui multiplie le nombre d’anomalies et in fine le nombre de cycles de livraisons.

Arrêtons-nous quelques instants sur le deuxième élément, à savoir le taux de satisfaction utilisateur. Cet indicateur reflète l’utilité marginale de votre application. Cette utilité marginale atteindra de toute façon une valeur maximale à partir de laquelle toute nouvelle fonctionnalité ajoutée ne modifiera pas le ressenti global de l’utilisateur final. Vous n’avez qu’à remarquer le nombre de fonctionnalités « Google » dont vous vous servez par rapport au nombre sans cesse croissant de fonctionnalités proposées pour vous en rendre compte. Ainsi le taux de satisfaction atteint plus vite sa valeur maximale lorsque votre système est exempt de cette dette technique (itération 3 vs itération 4).

Troisièment, le taux de satisfaction utilisateur lorsque votre SI est endetté commencera à décroître (itération 5) pour atteindre des valeurs inférieures à sa valeur initiale (et se détacher fortement de sa valeur sans cette dette) lorsque le seuil critique de la dette technique sera atteint. En d’autres termes, bien que proposant plus de fonctionnalités qu’au démarrage , le ressenti utilisateur au regard du SI se dégradera car la dette technique (ayant dépassé son
seuil critique) aura annihilé l’effet de ces nouvelles fonctionnalités.

Peut-on éviter la dette technique et peut-on la solder totalement ?

Dans les contextes projets traditionnellement pilotés par les coûts et les délais, une dette technique nulle semble difficilement atteignable car un code est toujours perfectible. En revanche celle-ci peut-être maitrisée en gardant un oeil avisé et permanent sur la qualité du code produit.

Certains outils comme Sonar s’intègre facilement dans les outils d’intégration continue et permettent de:

  • Déterminer, durant la chaine de compilation, le respect des normes de codage, le taux de couverture des tests unitaires, etc … Ces indicateurs sont produit par des outils comme Cobertura, Surefire, PMD, CheckStyle, etc ..
  • Déterminer en fonction de ces différents indicateurs, un taux « empirique » de dette technique estimé en nombre de jours/homme nécessaire pour la résorber.
  • Enregistrer, agréger et archiver l’ensemble des données produites dans une base
  • Afficher un Reporting clair et concis sur les zones sensibles du code

Cependant, la dette technique ne reste réellement maîtrisable que lorsque l’on garde une visibilité permanente sur la structure et la conception même du code. Ainsi un projet s’inspirant des méthodes agiles pour effectuer des itérations régulières aura plus de chances de maîtriser sa dette technique que celui qui rentre dans des cycles longs de livraison accentuant ainsi l’effet tunnel. Ceci pour la simple raison que le manque de visibilité peut cacher la croissance exponentielle de la dette technique au delà de son seuil critique, ce qui rendra trop tardive les actions correctrices engendrées.

Pour ce qui est de la structure du code, il faut éviter les nids d’endettements dont voici rapidement quelques germes :

  • Le code dispose de plusieurs façons de faire la même chose, via des patterns et/ou frameworks différents.
  • Les liens de dépendances entre composants/classes ne sont pas issus de la spécification fonctionnelle mais plutôt de l’analyse technique.
  • Une architecture logicielle et technique utilisant des différents composants du SI à mauvais escient.
  • Une méthode (ou une classe) mettant en oeuvre une quantité non négligeable de branches conditionnelles, augmentant ainsi la complexité cyclomatique du code.

Par ailleurs, il est illusoire de penser solder totalement la dette technique en une livraison.
Premièrement, il est difficile de justifier auprès des directions métier un budget dédié à la résorption totale de la dette, il suffit de considérer les réactions suscitées par les plans de rigueur établis dans certains pays surendettés et vous pourrez aisément vous en convaincre.

Deuxièmement, comme toute mesure « entropique », elle est issue du mouvement et des forces. Ainsi s’atteler à résoudre en une fois l’ensemble de la dette technique d’un SI, créera du mouvement sur l’ensemble du code, ce qui risque de générer à nouveau de la dette technique et aller à l’encontre des objectifs initiaux.

Une dette technique n’est résorbable que par itérations successives, ceci requiert de prévoir dans le budget et dans le backlog technique, un capital financier et humain de désendettement progressif par refactoring du code.

Il faut donc ajouter à chaque fonctionnalité supplémentaire du SI une ligne budgétaire de désendettement, c’est la seule façon d’éviter un surendettement chronique.

Pour ceux qui veulent plus d’information sur ce point.

Le concept initial de dette technique (Ward Cunningham)
L’article de Martin Fowler
L’article complet sur la taxonomie de la dette de Steve Mc Connell

Print Friendly