Comment évaluer sa dette technique et la maîtriser ?

Plusieurs outils et logiciels permettent d’estimer automatiquement sa dette technique. Sonarqube, par exemple, l’évalue en jours à mobiliser pour la correction des problèmes. Il détecte entres autres le code dupliqué ou inutilisé, le respect des guidelines et des conventions de nommage, les vulnérabilités potentielles… Mais attention, ce type d’outils donne des informations intéressantes (notamment sur la sécurité) mais ne permet pas de chiffrer précisément la dette technique : il sert à informer sur les améliorations ou dégradations de la situation. Quels sont alors, les différents outils et les différentes approches pour réellement évaluer sa dette technique ? C’est ce que nous vous proposons de découvrir dans cet article.

Les différentes approches pour évaluer sa dette technique

Il existe de nombreuses méthodes pour évaluer sa dette ; développer des indices de motivation des équipes, évaluer la vélocité des livraisons ou l’indice de confiance des sponsors…

Pourquoi évaluer sa dette technique ?

Que vous le vouliez ou non, la dette technique est présente et indissociable de tout projet. Vous avez donc tout intérêt à apprendre à la gérer et à mesurer son évolution dans le temps.

Retenons que toute application contient de la dette technique. Celle-ci est donc un mal nécessaire, mais pas forcément négative, car elle accompagne toute prise de risque. En revanche, la dette technique ne doit pas être ignorée : étant incontournable et génératrice de coûts, l’objectif est de pouvoir la gérer et la maîtriser, afin d’éviter le Game Over.

Comment gérer sa dette technique ?

La représentation par itérations peut être complétée d’une catégorie de gestion de la dette : elle consiste à accepter de réduire le volume de fonctionnalités au profit d’une part de « remboursement ». Or, dans le digital, la création de valeur passe par le développement de nouvelles fonctionnalités. Le remboursement de la dette consiste donc à refactorer le code, améliorer les tests et optimiser les performances. Rembourser la dette consiste à récupérer de la valeur perdue : la dette ne s’oppose pas à la création de valeur, mais redonne une valeur. Par exemple, refactorer, optimiser l’architecture ou écrire des tests régénère des revenus qui ne seront « pas perdus » pour cause de malfaçons, de bugs ou de lenteurs imposés aux utilisateurs.

Anticiper la gestion de la dette technique dans son projet

Dette volontaire vs dette involontaire : comment la détecter ?

Le cadran de Martin Fowler aide à définir des tâches à intégrer au backlog, telles que du refactoring. Les tâches sont placées sur un cadran à deux axes orthogonaux : prudent/imprudent (axe horizontal) et volontaire/involontaire (axe vertical). L’intensité s’accroît en s’éloignant. Des couleurs illustrent la désirabilité (bleu/vert pour satisfaisant, orange/rouge pour dangereux). Ce cadran permet d’évaluer une prise de position sur les fonctionnalités proposées, passées ou futures.

Quatre combinaisons sont possibles :

• Exemple d’une position délibérée et prudente : « nous devons livrer maintenant et faire face aux conséquences ». La position est prudente car elle prend conscience des risques, des conséquences possibles, et les rend visibles. De plus, elle est délibérée car elle permettra d’intégrer au backlog des actions de refactoring.
• Exemple d’une position involontaire et imprudente : « nous n’avons pas besoin de tests automatisés ». Elle révèle un manque de lucidité et de savoir-faire sur le projet.

Comment rembourser une dette technique ?

Plusieurs leviers permettent le remboursement de la dette technique. Le travail sur le code permet d’optimiser les performances, nettoyer, écrire des tests et débugger. Le remboursement de la dette commence aussi par sa détection et son évaluation, en utilisant les outils adaptés. Il faut garder à l’esprit que la dette technique génère aussi des intérêts. En priorisant les tâches, on réduit le coût global du développement tout en récupérant la valeur perdue : finalement, on crée de la valeur.

Quels outils utiliser pour gérer sa dette technique ?

Le backlog

La finalité des actions d’identification et de priorisation est de construire un backlog pour suivre les évolutions, ou le ratio entre les anomalies et les stories (fonctionnalités) et les tâches techniques, aussi bien celles de la roadmap que celles de réduction de la dette (les montées de version par exemple).

JIRA ou tout autre outil de gestion de backlog

Autre méthode pour créer un backlog : la catégorisation des classes sous JIRA, une plateforme de suivi de ticket et des projets qui permet l’évaluation et la gestion du nombre de stories, bugs… Les tâches techniques (visibles des développeurs) sont, par exemple, la mise en place de la CI/CD (intégration et déploiement continus) ou l’écriture de tests. Le remboursement de la dette est parfois juxtaposé, mais on peut considérer qu’elle fait partie intégrante de la story technique du projet IT : on pourra l’intégrer à la roadmap courante du projet digital.

Les ateliers

Lors d’un atelier, les problèmes ou les tâches peuvent être classées (par exemple avec des post-its) sur un cadran de Martin Fowler matérialisé sur tableau blanc. Les tâches sont évaluées en effort par rapport au prix. Une autre représentation est de classer les tâches sur un diagramme effort/risque : ceci permet de hiérarchiser les tâches de refactoring sur un listing. Il est alors possible de prioriser les tâches permettant de racheter le plus de dette technique.

⚠️Bien définir la Definition of Done

Attention aux ambiguïtés sur la Definition of Done (DoD) : pour une spécification dans une user story, la DoD dépend de ce qu’on entend par « fini ». Listez tout ce qui doit être réalisé en prenant en compte l’aspect qualitatif : écriture de tests, critères d’acceptance, environnements de déploiement, documentation, etc. Une étape cruciale pour définir une tâche « finie » est la vélocité du projet.

Gestion de la dette technique : bonnes pratiques

Le management par le visuel

Rendre visible la progression permet d’objectiver et de mesurer les problèmes, même en situation alarmante. Visualiser un graphique permet une prise de conscience, par exemple sur le nombre de bugs, et augmente la motivation.

Quelques outils :

• Sentry donne la métrique et les emplacements des bugs.
• New Relic permet de tracker les bugs frontend (JavaScript), difficiles à détecter dans le tunnel de vente. Une fois ces bugs détectés, de nouveaux tests peuvent être conçus. New Relic détecte aussi les ralentissements (augmentation du trafic) : configurez un indice de satisfaction Apdex fixant le seuil de temps de réponse pour ne pas perdre d’utilisateurs. La vérification automatique de la qualité du code (Sonarqube) permet de respecter les conventions de code.

Onboarding intelligent

La règle du boy scout digital favorise l’onboarding des collaborateurs. En respectant le principe de « toujours laisser un endroit dans un état meilleur que celui où vous l’avez trouvé », veillez à bien nettoyer et ranger le code existant. En architecture Open Source, le How to contribute est important, car les contributeurs sont extérieurs. La documentation doit être précise pour intégrer les nouveaux développeurs (chartes, guidelines, boîte à outils, sécurité, guideflow…).

CI/CD : intégration et déploiement continus

Pour lancer des opérations sur des merge requests (l’ajout de code), quelques outils comme Sonarqube permettent la détection de bugs, des problèmes de sécurité, du code inutile… Cyexpress.io permet de lancer des tests end-to-end, et Ansible offre une aide au déploiement sur différents environnements. La modération de code est également une bonne solution. Les tests end-to-end simulent des utilisateurs qui parcourent le frontend (ou back office), et permettent de rejouer ces scénarios avec des critères de validité : cette méthode est relativement coûteuse mais hautement efficace pour prévenir la dette technique.

Monétisation des actions / Webperf

Il s’agit d’apporter de la valeur financière au refactoring. Des actions sont possibles notamment sur l’hébergement, en optimisant la performance de l’application. Ce critère intéresse également les sponsors.

Audits ponctuels et Analytics

Certains sujets nécessitent une expertise externe et ponctuelle. Cette intervention apportera également un regard neuf et neutre sur l’architecture du projet, pouvant déboucher sur de nouvelles idées.

Conclusion

La dette technique est inhérente à tout projet digital. Elle impacte les équipes, le management et son DSI, augmente les coûts et diminue la vélocité des itérations. Pour autant, le but n’est pas de la supprimer mais de la maîtriser. Pour ce faire, plusieurs outils d’évaluation sont disponibles : mobilisés dans le cadre d’une méthode agile, ils permettront de prendre les bonnes décisions dès le début du projet. De plus, l’optimisation des performances du code renforce la motivation des équipes, entraîne la satisfaction des sponsors et permet de s’ouvrir à des marchés porteurs tels le Green IT.