Lorsque l’on parle de dette technique, on utilise une analogie du monde de la finance pour désigner les poids qu’un projet ou un produit informatique traîne pendant parfois toute sa durée de vie. Cette dette est souvent connue ou au moins simple à détecter, mais il existe un autre type de dette dit « Dette obscure » qui est plus complexe et non détectable par les différentes techniques d’analyse de code, c’est le côté obscur de la dette.

La dette technique

Le terme Technical debt a été évoqué par Ward Cunningham (connu pour le concept de wiki) pendant la conférence OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) de 1992.

Il en donne la définition suivante :

Livrer du nouveau code est comme de l’endettement; une petite dette accélère le développement à condition d’être remboursée plus tard par une réécriture. Le danger vient lorsque ce n’est pas remboursé. Chaque minute passée sur du code partiellement correct est similaire à des intérêts sur la dette initiale. Des organisations entières peuvent être bloquées sous le poids de la dette générée par une implémentation non consolidée.

Cette analogie est très intéressante, car elle permet de souligner le sérieux de cet aspect lors des conduites de projets informatiques et des développements.

En pratique, il existe deux types de dettes : volontaire et involontaire.

Dans la définition ci-dessus, il est plutôt question du premier type. Dans ce cas, la dette est identifiée et plus facilement maîtrisable. Par contre, pour le deuxième type, la dette accumulée est inconnue et elle peut resurgir à tout moment sous forme de bogue ou de difficulté extrême de maintenabilité ou d’évolutivité du code historique menant à d’énormes retards voire à un blocage total.

Ce dernier type de dette technique nous amène à envisager des moyens pour pouvoir se ramener le plus possible au cycle de traitement des dettes volontaires. Ceci peut être réalisé en lançant des grandes campagnes de qualité du code pour essentiellement identifier les dettes involontairement générées, cela inclut :

• Étoffer les tests unitaires pour améliorer la couverture du code,
• Étoffer les tests fonctionnels pour améliorer la couverture des cas d’utilisation,
• Le cas échéant, utiliser des outils de détection de fuites mémoires, d’analyse syntaxique de code (en configurant bien l’outil pour ne pas être spammé),
• Selon les cas effectuer des tests de performance avec le code existant.

 

Pousser la réflexion …

Posons nous une deuxième fois la question : y a t-il d’autres dettes involontaires n’ayant pas été identifiées voire remboursées ?

La réponse est probablement oui. Car il faut savoir que même en mettant tous les moyens pour assurer la robustesse et la qualité du code, il subsiste un type de dette plus difficile à identifier : les Dark Debts.

 

Dark debt : le côté obscur de la dette

Le terme Dark Debts (ou dette obscure en français dans le texte) a été mentionné la première fois pendant la conférence STELLA de 2017.
La dette obscure est un produit de l’augmentation de la complexité et de l’hétérogénéité d’un système, il s’agit d’une dette qui ne se manifeste en général qu’en production par de larges et complexes pannes. Elles sont non décelables à la création mais sont une conséquence d’interactions entre composants logiciels ou matériels.

Contrairement à la dette technique traditionnelle, la dette obscure ne peut pas être remboursée par simple refactoring, ni complètement évitée par des bonnes pratiques de design ou autre.
Des exemples d’événements illustrant les effets spectaculaires de ce type de dettes, montrent que même dans des S.I. considérés de « bonne qualité » cela peut arriver :

• Amazon Web Services en 2012 : https://arstechnica.com/information-technology/2012/10/amazon-web-services-outage-once-again-shows-reality-behind-the-cloud/
• Facebook en 2015 : https://www.facebook.com/notes/facebook-engineering/more-details-on-todays-outage/431441338919/
• GitHub en 2016 : https://github.com/blog/2101-update-on-1-28-service-outage

 

Conclusion

A vrai dire, il n’y a pas de solution miracle, à part une boucle d’asservissement à base de post-mortem et d’amélioration continue.
Je finirais en citant le théorème de Woods :

As the complexity of a system increases, the accuracy of any single agent’s own model of that system decreases rapidly.

Ce théorème simple de formule mais riche en enseignements, nous montre qu’il faut essayer d’améliorer le modèle que l’on se fait de nos systèmes (d’autant plus lorsqu’il s’agit de S.I. complexes) régulièrement, en impliquant le plus de points de vue possibles, et de l’inclure pourquoi pas dans les stratégies de modernisation des S.I. lorsqu’il s’agit de grandes entreprises.