Sans surprise, pour maîtriser la dette technique, il s’agit de minimiser le capital emprunté, puis de rembourser régulièrement. Comme pour un emprunt immobilier…

Comment maîtriser la dette technique (5/5)

Commencer par minimiser le capital emprunté

Après avoir présenté le concept de dette technique, son interprétation ainsi que ses origines et ses conséquences, nous arrivons au bout de cette série avec les solutions pour maîtriser son endettement. Il est tout d’abord préférable d’éviter une situation dans laquelle le remboursement du capital et des intérêts de la dette technique devient trop lourd. Il est ainsi souhaitable d’en anticiper les effets les plus néfastes. Pour cela, il faut prendre des décisions argumentées dès la phase de conception (et en en conservant la trace !). Plusieurs principes permettent de juguler la dette :

• Documenter au fur et à mesure les choix faits, pour revenir dessus plus tard et y remédier le cas échéant (toutefois, cela va à l’encontre des motivations initiales de contraction de la dette technique : aller le plus vite possible en production ; la pression mise sur les équipes se traduira souvent par l’ajournement de tâches telles que la documentation…).
• Adopter des méthodes de développement hybrides Agile/Cascade afin de bénéficier plus vite du retour d’expérience de la mise en production.
• Mettre en pratique les principes DevOps  : recourir à des équipes réduites^[1] et multidisciplinaires, mettre à disposition des plateformes partagées en self-service, mettre en place le maximum d’automatisation (au sens large du terme), utiliser la containerisation, construire un modèle centré sur les API.
• S’assurer du respect des principes précédents chez le prestataire en cas de développement externalisé.
• Analyser régulièrement l’architecture fonctionnelle et mettre en place un processus itératif d’amélioration de la qualité logicielle structurelle tout au long des versions afin de procéder à des réorganisations (plus l’environnement architectural fonctionnel est complexe, plus il sera difficile et coûteux de le réorganiser).

Puis rembourser le cas échéant

Une fois la dette contractée, il faut en rembourser les « intérêts » ainsi que le capital. Comme pour tout, cela passe par les étapes classiques : identification, estimation, plan d’action !

Identifier la dette technique

Pas de baguette magique, il faut se relever les manches. Si les décisions n’ont pas été documentées au fur et à mesure, il est nécessaire de se plonger dans le SI et inventorier les points d’amélioration. Cet inventaire pourra passer par le recours aux équipes techniques et à leur mémoire des projets, des revues de code, l’examen des documents de conception, l’analyse systématique des opérations et des infrastructures en place. Des logiciels d’analyse sont également disponibles, sachant qu’ils ne seront pas forcément exhaustifs et ne couvriront pas tous les types de dettes techniques.

Estimer le coût de la dette

Afin d’étayer les décisions de remboursement (ou pas) du capital de la dette, il est essentiel de pouvoir comparer le coût des intérêts et celui du capital. Mesurer ou même estimer le montant de la dette technique demeure cependant difficile. En interne, l’organisation a la possibilité de demander aux équipes qui doivent développer une fonctionnalité d’estimer le temps nécessaire au développement de cette fonctionnalité et le temps qui serait nécessaire si le système était nettoyé correctement. La différence entre les deux peut être considérée comme une évaluation des intérêts de la dette technique.

Cette technique n’est certes pas parfaite. L’appréciation du temps estimé dans un environnement propre est basée sur un état hypothétique – donc assez peu objective. Il est également possible de procéder à une estimation des intérêts payés lors des rétrospectives devant être effectuées à la fin de chaque itération de la phase de développement. Il s’agit alors de se baser sur le temps réellement passé par rapport au temps prévu, ce qui peut être plus facile que l’estimation d’une charge future.

Quelle que soit la méthode employée, le résultat aidera à dresser un tableau de la situation intelligible par les équipes non techniques afin de rationaliser la discussion.

Un exemple de valorisation de la dette (de code)

De manière plus générale et afin d’offrir des possibilités de benchmark, différentes études ont estimé l’impact financier de la dette technique. Celles menées par le CRL (CAST Research Labs) s’attachent à déterminer la « densité de la dette technique (de code) » (le nombre de violations par lignes de code) et à estimer le degré de sévérité de ces violations (violations de sévérité élevée, violations de sévérité moyenne et violations de sévérité faible). On remarquera qu’il s’agit ici plus particulièrement d’une « dette de code ».

Il est possible de tenter de valoriser la dette technique en multipliant le temps de remédiation nécessaire par le coût horaire d’un développeur. Pour cela, on peut estimer que :

• le taux de correction attendu pour les violations de sévérité élevée est de 100 % et que celles-ci nécessitent chacune 3 heures de correction ;
• le taux de correction attendu pour les violations de sévérité moyenne est de 50 % et celles-ci nécessitent chacune 1 heure de correction ;
• qu’il est inutile de corriger les violations de sévérité faible, il est possible de valoriser la dette technique en multipliant le temps de remédiation nécessaire par le coût horaire d’un développeur.

On obtient :

Coût de la dette de code =
(τ de correction des violations de sévérité moyenne x Nombre d’heures de correction
+ τ de correction des violations de sévérité élevée x Nombre d’heures de correction) x Coût horaire

Le CRL a pu ainsi pu estimer que la dette d’une application de taille moyenne (300 000 lignes de code) est de 1 083 000 USD, ce qui représente une dette de 3,61 USD par ligne de code…

Caractériser la dette technique selon les qualités applicatives, afin de décider

Par ailleurs, plusieurs caractéristiques des applications permettent de définir le niveau de dette technique :

• Transférabilité : facilité pour un développeur de comprendre et de s’approprier de façon productive le code développé par un autre.
• Évolutivité : possibilité de modifier une application, d’y adjoindre de nouvelles fonctionnalités, de corriger des erreurs ou de modifier l’environnement applicatif.
• Sécurité : nombre de violations des pratiques de codage sécurisé permettant des accès non-autorisés, des échanges trompeurs, le vol de données ou des violations de confidentialité.
• Performance : probabilité de dégradation potentielle de la performance ou d’utilisation inefficace de ressources telles que les processeurs, la mémoire et les réseaux, dégradation due à de mauvaises pratiques de codage.
• Robustesse : probabilité d’interruption d’exploitation, difficulté de reprise et possibilité de corruption de données, du fait de mauvaises pratiques de codage.

Il faut souligner que le manque de transférabilité et d’évolutivité (et donc le manque de maintenabilité) impacte les coûts informatiques (et représentent en moyenne respectivement 40 % et 30 % de la dette technique selon le CRASH Report 2011/2012 de CAST). La sécurité (7 %), la performance (5 %) et la robustesse (18 %) concernent les risques Métier. Ces chiffres sont bien évidemment des moyennes, ils diffèrent selon les technologies employées, l’âge du SI, le secteur d’activité de l’organisation.

En notant chaque application selon les cinq caractéristiques listées ci-dessus, et en couplant cette notation à l’estimation de leur impact potentiel, il est possible de mettre en place rapidement un plan de réduction des risques. Toutefois, l’absence de dimension financière rend difficile l’arbitrage. Il est ainsi essentiel de pondérer ces risques en y ajoutant la charge de remboursement. Ceci permet d’optimiser le remboursement de la dette en prenant les décisions les plus éclairées.

La dette technique, un mal nécessaire donc

La contraction de la dette technique est donc un « mal nécessaire » qui peut se révéler un accélérateur de livraison redoutable : impossible de livrer à temps sans petits arrangements. Le problème, c’est son côté pernicieux : elle est invisible (le système fonctionne… pour l’instant) et son effet néfaste n’est que potentiel et ultérieur (peut-être le système continuera à fonctionner ? Ou pas). Elle peut s’accroître à bas bruit, rendant insidieusement la maintenance et l’évolutivité de plus en plus lourdes et compliquées.

Si en tant que métaphore, elle constitue un outil de communication efficace et parlant, elle s’avère difficile à manipuler en tant que concept, en particulier en termes de chiffrage. Il faut donc l’utiliser comme Ward Cunningham : comme rappel de la nécessité de procéder à un état des lieux initial, de construire un plan d’action, et surtout de s’astreindre à une revue régulière. Comme chacun l’a expérimenté, l’entropie des SI (et donc sa désorganisation) est comme celle de l’Univers : inévitable et en croissance constante.

[1] Éviter les équipes de plus de 20 développeurs (des équipes de moins de 10 développeurs étant optimales).