Dette technique informatique : Comment mesurer et réduire la dette technique des projets & portefeuille projets

Échapper au trou noir de la dette technique… Votre réflexe est-il de grogner lorsque vous voyez cela ? Oui, nous aussi. Entre fatalité et désespoir, des solutions existes ! La dette technique est un concept du développement logiciel inventé par Ward Cunningham en 1992. Le terme vient d’une métaphore, inspirée du concept existant de dette dans le domaine des finances et des entreprises, appliquée au domaine du développement logiciel. Au-delà de ce que l’entreprise a déjà derrière elle, le stock, elle crée du legacy dès qu’elle développe. C’est un flux permanent. C’est quand on se laisse dépasser que l’on crée une dette technique qui devient contraignante…

Découvrez dans cet article :

• Les grandes catégories de dettes techniques
• Comment chiffrer la dette technique ?
• Comment conduire un projet en percevant sa dette technique ?
• Comment mesurer la dette technique ?
• Quels sont les leviers à activer par la DSI pour mieux maîtriser la dette technique ?

Le fond de la pensée du créateur du concept de dette technique, Ward Cunningham

Il y a déjà 30 ans, Ward Cunningham faisait la comparaison entre la complexité technique et la dette dans un retour d’expérience.

La livraison du premier code ressemble assez au fait de s’endetter. Une petite dette accélère le développement à condition qu’elle soit remboursée rapidement par une réécriture…

Le danger se manifeste lorsque la dette n’est pas remboursée rapidement. Chaque minute passée sur du code pas tout à fait exact ajoute aux intérêts dus sur cette dette. Chaque semaine qui passe fait oublier aux développeurs quoi faire pour rembourser la dette qu’ils avaient acceptée.

Une DSI peut atteindre un blocage total parce qu’elle croule sous le poids des dettes de développements non remboursées.

Il convient qu’une équipe de développement de projet informatique se saisisse des opportunités de rembourser (ou régler) cette dette technique. Si vous managez l’un de ces projets de développement logiciel, réservez un pourcentage de votre cycle de développement à payer votre dette. Ou mieux, dédiez un cycle entier de développement. Un Sprint 0 par exemple avec Scrum. Afin de compléter ce travail. Si vous ne le faites pas, ce code non optimal sinon défectueux ne manquera pas de revenir vous hanter. Soit votre équipe projet soit le « help desk », l’équipe de support, ou quelqu’un d’autre en aval de vos livrables. Sans compter la difficulté accrue à terme pour les évolutions de votre application.

C’est une vraie dette, et comme pour toute autre dette, vous vous trouverez devant l’obligation de la rembourser tôt ou tard.

Vous acceptez parfois des développements quick & dirty (vite et mal). Parce que cela vous fait gagner du temps et justifie les risques et le coût total. Mais vous adoptez alors un processus de pensée à très court terme. Vous ne savez pas réellement estimer les coûts à long terme et les risques pris par ce choix. Si vous n’êtes pas absolument obligés de prendre ce risque, ne le prenez pas. Livrer un travail de qualité est votre priorité !

Les grandes catégories de dettes techniques

1. La dette accumulée au fil du temps en raison de changements ou d’évolutions de framework de développement

Il est presque inévitable que votre framework évolue et s’améliore au point que vous vouliez en adopter les versions plus récentes. Si vous ne surveillez pas ces changements et ne faites pas évoluer votre code de base en conséquence, il vous sera de plus en plus difficile d’adopter des versions récentes. Peut-être quelqu’un ajoutera-t-il un nouveau module ou intégrera un nouveau service dont vous aurez prochainement besoin. Cette catégorie de dette est la moins destructrice et peut être évitée en adoptant une bonne stratégie de mise à jour du framework.

2. La dette liée aux obsolescences

Les projets dépendent d’éléments externes (librairies, API, modèles, architectures, etc.). Ils génèrent également une dette technique, car les éléments externes évoluent en parallèle, ce qui provoque l’obsolescence de certaines parties du code, donc la nécessité de créer des mises à jour. La dette technique est inévitable dans le développement logiciel et perdure tout au long de la vie du produit.

3. La dette pragmatique

La réalité du développement logiciel est qu’il n’y a jamais assez de temps pour faire un travail parfait. Tôt ou tard, vous devrez réaliser quelque chose de façon moins idéale afin de tenir les délais et le budget. Souvent vous pouvez vous permettre d’accepter un compromis sur la qualité, mais comment savoir quand ? La règle de base est que le coût d’implémenter la fonctionnalité de cette manière sous-optimale est égal au coût de faire de ceci 2 fois ! Une fois pour la terminer dans les délais et une fois pour la reprendre de façon plus optimale et durable.

Si vous échouez à rembourser les dettes 1 et 3 dans une période raisonnable, c’est comme avoir signé un prêt hypothécaire à haut risque. Vous constatez qu’avec cette accumulation de dettes techniques, il devient presque impossible d’ajouter dans les temps de nouvelles fonctionnalités au système existant. Vous avez probablement beaucoup plus d’anomalies dans votre système qu’il est acceptable. Vous dépensez inévitablement davantage sur la maintenance opérationnelle. Vos utilisateurs ont déjà commencé à remarquer des erreurs, des failles de sécurité ou des problèmes de performance… Ceux-ci représentent le coût d’entretien de la dette un peu comme les intérêts que vous payez sur votre crédit immobilier alors que vous devez encore trouver une façon de rembourser le capital.

La discipline est sa propre récompense à long terme. Vous pourrez vous permettre de dépenser plus d’argent sur de nouvelles fonctionnalités au fil du temps si vous réglez vos dettes dans des délais raisonnables. Mieux vaut créer un plan structuré pour rembourser la dette avec un calendrier acceptable.

Comment chiffrer la dette technique ?

Avant même de contracter cette dette, une bonne pratique est de déterminer combien va devoir être investit pour y remédier. Faites chiffrer en euros la dette qui vous est proposée en cumulant :

• les jours de développement qui seront nécessaire pour corriger le code
• les efforts additionnels du support qui seront nécessaires pendant la période où le client du projet exploitera une solution non optimale
• les délais de règlement du client du projet qui ne sera pas 100% satisfait…

Ce chiffrage financier de la moindre qualité structurelle de l’application vous permet de comparer les coûts informatiques aux pertes potentielles coté business en raison d’un échec qui n’était pas envisageable avant d’accepter cette dette.

Au minimum, le fait de chiffrer votre dette technique va vous aider à réduire le nombre de violations de la qualité structurelle. La clé est de garder un œil vigilant sur ce compteur des violations.

Comme avec une dette dans le monde réel, le truc avec la dette technique est de suivre vos dettes de près et de vous assurer que vous avez un plan d’action pour les rembourser. Autoriser vos dettes à croître sans réfléchir à ce que vous faites est une façon inacceptable de diriger vos finances personnelles…
… comme votre projet de développement logiciel.

Pour ce faire, tenez un registre de vos dettes dans un format simple comme celui d’un suivi de compte et facilement compréhensible de tous. L’équipe y détaille les conséquences techniques de ces décisions qui vont négativement impacter la qualité de mise en œuvre du produit (probabilité, impact et remédiations envisagées). Assurez-vous que chaque développeur de l’équipe connaît et comprend ce registre. Chaque fois que vous ajoutez de la dette, ajoutez une ligne dans votre registre dans le même temps que vous livrez le code en cause.

Quand vous remboursez de la dette, rayez l’entrée correspondante du registre.

Faites une routine à chaque fin de Sprint de conduire une revue du registre de vos dettes. Comme pour un registre de risques, assurez-vous que vous avez un plan d’action pour adresser chaque ligne.

Partagez le registre avec votre équipe. Vérifiez qu’ils comprennent bien la raison pour envisager une nouvelle dette et la magnitude du remboursement à venir.

…Tout n’est pas de la dette technique

Tous les défauts et les bugs ne constituent de la dette technique. Ce sont souvent juste des erreurs, même si vous les jugez irresponsables ou indignes. En réalité, ces erreurs ne reflètent pas souvent de décision de conception. Si cela ne met pas directement en péril la qualité de produit, ce n’est pas de la dette technique.

En Scrum, une bonne définition de DONE doit être suffisamment robuste pour que des niveaux déraisonnables de dette ne puissent pas être atteints. Si on constate que malgré cela la dette technique continue d’augmenter, la définition de DONE devra probablement être revisitée.

Comment conduire un projet en percevant sa dette technique ?

Détaillez les conséquences techniques

Pour un management de projet efficace, tenez un registre de vos dettes dans un format simple. Détaillez-y les conséquences techniques : probabilité, impact et remédiations envisagées. Chaque fois que vous ajoutez de la dette, ajoutez une ligne dans votre registre quand vous livrez ce code. Et quand vous remboursez de la dette, rayez l’entrée correspondante du registre ! Et, à chaque fin de Sprint, menez une revue du registre de vos dettes.
Si vous souhaitez aller plus loin, vous pouvez définir des indicateurs de risque. Et les appliquer aux projets au sein d’un logiciel de portefeuille projets.

Développez la gestion du cycle de vie de l’infrastructure pour inclure des interfaces de gestion de portefeuille stratégique

Les entreprises numériques exigent une infrastructure résiliente et adaptable; toutefois, une dette technique incontrôlée empêche les responsables de l’infrastructure et des opérations de satisfaire à cette exigence. Les leaders SI devraient renforcer la gestion de portefeuille en adoptant des pratiques qui maintiennent leurs infrastructures agiles et à jour.

Une pratique de gestion du portefeuille d’infrastructures fournit le soutien et les ressources nécessaires à l’évaluation continue, à la gestion du cycle de vie et à la gouvernance.

Choisissez une composante d’infrastructure à piloter pour la planification stratégique de la gestion de portefeuille qui est de grande valeur et qui n’a pas d’obstacles évidents à la mise en œuvre.
Affectez le propriétaire approprié pour rédiger un plan d’interface de gestion de portefeuille stratégique pour le composant d’infrastructure.

Une fois que les parties prenantes sont à l’aise avec la procédure, augmentez le nombre de composants d’infrastructure soumis à cette procédure. Et ce jusqu’à ce que tous les composants identifiés par d’autres portefeuilles comme nécessitant des niveaux de performance plus élevés en termes d’avantages, de risques et de coûts, disposent d’un plan stratégique d’interface de gestion de portefeuille.

Quels outils pour mesurer la dette technique ?

• Les outils de mesure automatique : c’est une solution intéressante pour commencer à mesurer sans effort le niveau de la dette technique notamment grâce à des outils qui décèlent des violations des bonnes pratiques. Par exemple l’outil Sonar permet de s’assurer que les développeurs suivent des métriques concernant les classes et les méthodes.
• Les outils de mesure de couverture de tests : ce type de solution permet de connaître la quantité de code couverte par les tests automatiques. Par exemple, une couverture inférieure à 75% peut indiquer d’importants problèmes dans le code.
• Les outils de mesure manuelle : Vous pouvez vous constituer des rapports pour mesurer l’impact de la dette technique avec certains indicateurs. Tels que le nombre de bugs sur une période donnée et par application, la durée des investigations sur un produit, un composant ou un code hérités, le taux d’insatisfaction lors des livraisons, etc.

Quels sont les leviers à activer par la DSI pour mieux maîtriser la dette technique ?

1. Dette technique agile : améliorez globalement la qualité du code 

Le développement Agile repose sur la rapidité. Lorsque les équipes se bousculent pour respecter les délais d’un sprint, cela se traduit généralement par des méthodes fastidieuses, des routines inefficaces ou un code de mauvaise qualité.

Les peer reviews restent une approche certes coûteuse mais efficace de vérifier le suivi de bonnes pratiques de programmation. Surveillez les problèmes de code et corrigez-les le plus rapidement possible. Il faut que vous les partagiez avec l’équipe et ainsi apprenez à chaque fois des erreurs commises. Profitez-en pour enrichir votre document sur les normes et meilleures pratiques à suivre par les développeurs. Pour une amélioration plus notable, impliquez votre architecte technique avec l’équipe de développement. Afin d’effectuer régulièrement (pas à chaque Sprint mais à chaque Release par exemple) une refactorisation du code. Ce sera l’occasion pour l’équipe d’analyser et réécrire une partie du code à intervalles réguliers pour réduire la dette technique.

2. Testez, en manuel mais aussi de façon automatique

Les tests manuels ne sont pas hyper efficaces. L’une des manières les plus efficaces de réduire la dette technique est que vous automatisiez le plus possible les tests. Focalisez-vous pour commencer sur les tests de non-régression qui sont particulièrement chronophages et trop souvent délaissés ou bâclés pour cette raison. Puis, focalisez votre attention sur les tests de bout en bout qui garantissent l’utilisabilité de votre solution. Ceux-ci seront probablement manuels et réalisés par des experts du métier du moins dans un premier temps.

3. Limitez les risques en rationalisant vos choix de technologies

Plus il y a de diversité dans les technologies utilisées, plus la qualité sera à risque et la maintenance de l’application complexe. Plus les technologies sont « jeunes » et moins elles ont fait leurs preuves. Sélectionnez des composants stables, supportés et mis régulièrement à jour. Il est important de limiter le nombre de technologies qui vont entrer en jeu dans la construction de l’application. Plus elles seront nombreuses, et plus les sources de dette (et donc le nombre de créanciers) seront compliquées à mettre sous contrôle.