Dette technique : quelles solutions pour mieux la gérer ?

Qu’est-ce que la dette technique et d’où provient-elle ?

Ce terme de « dette technique » ou « technical debt » en anglais, a été créé en 1992 par Ward Cunningham. C'est une métaphore inspirée du concept de dette financière, appliquée au contexte de développement logiciel. Elle découle d'un grand nombre de décisions prises pour privilégier la rapidité de production et de livraison avant tout.

C’est un concept clé dans l'informatique et le développement logiciel qui s'apparente à une sorte de "dette" que les équipes techniques contractent lorsqu'elles prennent des raccourcis dans le code ou dans les processus de développement pour atteindre des objectifs à court terme. Bien que cela puisse permettre d'accélérer la livraison d'un produit ou d'une fonctionnalité, ces choix peuvent entraîner des coûts cachés sous forme de complexité accrue, de mauvaise qualité, de bugs, ou de difficultés de maintenance à long terme.

Vous pouvez considérer que vous avez de la dette technique si vous répondez positivement à une ou plusieurs des questions suivantes :

• Les projets prennent-ils de plus en plus de temps à être livrés ?
• Le système de production rencontre-t-il fréquemment des bugs, des erreurs ou des pannes en production ?
• Les développeurs se plaignent-ils de difficultés à travailler avec le code existant ?
• Les retours utilisateurs mentionnent-ils des problèmes récurrents ou des lenteurs ?
• Dans le cas de réponses positives, vous avez donc de la dette technique.

Pour comprendre les causes réelles de sa dette technique et les catégoriser, il existe les « quadrants de la dette technique » inventés par Martin Fowler.

Ces quadrants sont divisés en plusieurs axes :

La méthode des quadrants de la dette technique de Martin Fowler va permettre d'évaluer l'intention (accidentelle ou intentionnelle), le type de dette et le contexte des problèmes liés au code. Si certaines dettes peuvent être volontaires et classées dans la catégorie des bonnes dettes, d'autres éléments peuvent être involontaires et classés dans la catégorie des mauvaises dettes.

Voici un exemple détaillé :

Maintenant que nous avons une meilleure compréhension de la dette technique, rentrons dans le détail de ses impacts et des solutions possibles pour mieux gérer et réduire la dette technique dans ses projets !

Comment reconnaître de la dette technique sur un projet ?

Charles-Éric : Il existe plusieurs cas de figures. Ce qui arrive assez souvent, c'est des développeurs juniors qui sont réticents à faire de la refacto par peur de casser le code. Ils vont faire la modification la plus petite possible pour ne pas impacter l'existant. Souvent, ils sont dans cet état d'esprit parce qu'ils ne savent pas comment ça marche, ils ne connaissent pas le code et la technologie utilisée. Du coup, ils vont simplement faire un « if » pour ajouter la règle et ne pas toucher au reste. C'est clairement une mauvaise pratique car cela empire la dette technique. Généralement, c'est dû à un manque de maturité et de confiance.

Le deuxième cas classique, c'est un client, potentiellement accompagné d'un Product Owner, qui met la pression pour livrer rapidement. Il veut que ça aille vite, que l'équipe ne touche pas au code, qu'elle ajoute simplement la fonctionnalité sans s'attarder sur le reste. Alors même, que toute l'équipe a conscience qu'en faisant ça, ils alimentent la dette technique, ils le font quand même. Dans ce cas de figure, c'est un peu malgré eux. Ils rentrent un peu dans une phase de « panique » et se font embarquer par la pression client. 

Marianne : Plus un projet va produire lentement et avec peu de confiance lors de la mise en production, plus la dette technique est présente. Dans la majorité des cas, l'équipe expliquera que le code est obsolète, qu'ils manquent de temps pour faire de la refacto, qu'il n'y a pas suffisamment de temps accordé aux tests, que les processus DevOps mis en place et l'infrastructure ne suit pas… Il existe une multitude de causes mais ce sont souvent les mêmes : de la dette intentionnelle qui a des conséquences désastreuses à long terme.

Peut-on considérer qu’il y a une bonne et mauvaise dette technique ?

Jérémy : Je pense que oui. On peut considérer que la bonne dette technique est celle qui existe, dont on a conscience qu'elle est là et qu'elle doit être résolue sur le long terme mais qui n'a pas d'impact à l'instant T sur la productivité. C'est agaçant, surtout quand on est perfectionniste. Mais c'est de la dette technique contrôlée, qui ne ralentit pas les développements et qui ne pose pas de vrais problèmes. L'idéal c'est d'avoir un plan sur le long terme pour la résoudre au fil de l'eau.

Du côté de la mauvaise dette technique, pour moi, il n'y a pas plus dangereux qu'une dette technique dont on ignore l'existence. Soit tu en ignores l'existence parce que tu viens d'arriver sur le projet ou que la dette technique n'est pas encore complètement évidente, soit tu fais l'autruche. Et on en parle pas assez mais c'est un vrai sujet. Il y a des développeurs qui voient la dette technique mais qui ferment les yeux consciemment.

Alors que tous les développeurs savent très bien que la notion d'obsolescence s'applique à toutes les briques de l'ingénierie logicielle, et qu'à la seconde où tu as développé quelque chose et commit, le compte à rebours vers l'obsolescence et la dette technique à commencé.

Tu as aussi de la mauvaise dette technique, liée à des évolutions n'ayant pas été anticipées au départ. Sur un projet qui évolue en permanence, on peut se retrouver initialement avec quelque chose qui marchait très bien, dont on était très contents. Puis un mois plus tard, c'est notre pire ennemi. Tout ça, parce qu'on nous demande de mettre en place une fonctionnalité sur un élément non-adapté et non-adaptable. C'est clairement une forme de mauvaise dette technique.

Puis tu as la mauvaise dette technique évidente, celle dont tout le monde a conscience, qui bloque les choses ou qui les ralentit tellement que ça devient un vrai sujet d'un point de vue fonctionnel à hauteur du produit. Cette forme de dette technique a un impact psychologique sur les développeurs.

Pour l'avoir vécu, quand tu passes 3 jours à chercher un bug à cause d'un code spaghetti de plus de 1000 lignes ou à cause d'une architecture qui a très mal vieilli, pour finalement trouver le bug en question et le résoudre en 30 secondes. Il y a de quoi péter les plombs.

Clairement ça, c'est de la mauvaise dette technique.

Quelles solutions existent pour gérer la dette technique ?

Marianne : Un axe pour améliorer l'existant, ce serait d'y dédier du temps à cette résolution de la dette technique. Parmi les difficultés, il y a celle de convaincre les sponsors de l'intérêt sur le long terme de cet investissement en temps, mais qui est indispensable pour éviter d'alimenter la dette. Ensuite il est possible de mettre en place des actions correctives :

Charles-Éric : Côté management, Il faut faire gagner en maturité les plus juniors qui peuvent avoir peur de toucher au code, mais il faut aussi parfois réussir à canaliser des développeurs seniors ultra perfectionnistes. Parce que ça arrive d'être face à un développeur qui veut que le code soit ultra clean, tout le temps, ne bosser que sur des aspects techniques au détriment des objectifs business. Dans la réalité des choses, ce n'est pas faisable. Il faut donc savoir trouver des terrains d'entente et accompagner, suivre les équipes dans la mise en pratique du plan défini.

Il y a le concept de ‘The Boy Scout Rule' de Robert C. Martin (Uncle Bob) que j'aime bien. C'est le fait de toujours laisser le code plus clean que quand tu l'as trouvé au départ. Donc au moment où tu ajoutes une fonctionnalité sur une base de code existante, tu dois obligatoirement faire en sorte que cette base de code soit au moins un peu mieux qu'avant. Cela ne veut pas dire que tu dois refaire toute l'application et te lancer dans une refacto énorme mais qu'à minima le fichier que tu as touché doit, après ton passage, être plus clean.

C'est cet état d'esprit que je partage avec mon équipe du Studio Eleven Labs pour les embarquer dans la résolution de la dette technique en continue.

Comment gérer un sprint en réduisant la dette technique ?

Charles-Éric : Premièrement, la chose à faire, c'est de réaliser le constat tous ensemble de l'existence de cette dette technique. Pour évaluer sa dette, tu passes par une phase d'audit du code source et de la qualité du code et d'analyse des métriques de qualité. Cela permet d'identifier et de mesurer le niveau de dette technique de ton projet. Après avoir réalisé cette phase d'analyse, tu présentes des alertes concrètes aux stakeholders qui peuvent être de différentes natures :

À partir de ce constat, il faut créer un plan qui va permettre de rembourser la dette technique en parallèle des fonctionnalités à livrer pour satisfaire les objectifs business du client. L'objectif ce n'est pas d'arrêter le projet, de ne plus rien livrer et de ne faire que du remboursement de la dette. Il faut prendre en compte les intérêts et besoins tant des développeurs, que du client.

On définit donc une roadmap et une architecture cible sur le moyen et long terme. Ça peut être sur 1, 2, ou même 3 ans. Il faut être pragmatique et définir différentes étapes et jalons qui vont permettre d'arriver à la cible fixée.

Ce qui est pas mal, je trouve, c'est d'avoir une approche où la résolution de la dette technique et la livraison des fonctionnalités sont corrélées et traitées en simultané. Par exemple, si tu sais que tu as une fonctionnalité à ajouter sur un module où il y a de la dette technique existante, il me semble cohérent de travailler sur le paiement de la dette. Tu vas donc te concentrer à cleaner le code, à faire du refactoring sur l'existant, tout en ajoutant des fonctionnalités sur quelque chose qui sera clean. Cela te permet d'avancer sur les différents chantiers en parallèle et donc de ne pas impacter les besoins business.

Marie Minasyan : Pour éviter d’alimenter la dette technique au quotidien, on peut mettre en place plusieurs actions fil rouge de résolution dans nos sprints :

Toutes ces bonnes pratiques permettent d'éviter d'alimenter la dette technique. On en a toujours, c'est évident. Un projet avec 0 dette technique, ça n'existe pas. Mais on a une dette technique limitée, qu'on peut qualifier de « bonne dette technique ». Elle est présente mais n'impacte pas la productivité.

Quel est le rôle du Product Owner dans la gestion de la dette technique ?

Jérémy : En tant que Product Owner, il est important d'accepter qu'il faut s'en occuper et laisser le temps aux équipes de développement de le faire. C'est très important que le Product Owner soit dans la compréhension et dans l'écoute. Si le Lead Développeur ou le Tech Lead du projet dit que pour le développement d'une feature, il a besoin au préalable de temps de refacto ou de corriger tel ou tel bug, c'est qu'il faut le faire. Combattre cela, c'est perdre du temps, de l'énergie et rentrer dans une confrontation avec les développeurs qu'on ne peut pas gagner. Et qu'il n'est pas souhaitable de gagner de toute façon.

Je ne dis pas qu'il faut tout accepter. Par contre, il faut être capable de prendre du recul sur le moment et de voir comment inclure ce besoin de résolution de la dette technique dans le backlog et la prochaine user story. Qu'est-ce que cela représente en terme d'effort ? De temps ? Quel est le besoin in fine ? L'objectif c'est vraiment de comprendre le principe, le besoin, et pas du tout les détails : chacun son métier.

Il faut impérativement expliquer le besoin pour négocier avec les développeurs sur la manière dont on va y répondre. La finalité est que la demande des développeurs soit prise en compte, quitte à décaler d'un sprint par exemple.

Puis d'autre part, la compréhension à minima des contraintes techniques est impérative pour pouvoir négocier, cette fois-ci, avec les sponsors et / ou les managers.

Le Product Owner est le porte-parole des équipes de développement dans ces moments-là. Pour pouvoir négocier du temps ou des concessions, il faut comprendre le besoin technique un minimum et avoir les bons arguments.

Comment embarquer les décideurs à la résolution de la dette ?

Charles-Éric : Pour les convaincre, il faut leur partager le constat et présenter des indicateurs et KPI chiffrés pour leur faire prendre du recul. Il faut être factuel et quantitatif. On va présenter les indicateurs de qualité du produit mettant en avant le nombre de bugs, le nombre de régressions, le temps alloué à la résolution de ces bugs, la vélocité de l'équipe, le budget par sprint vs le nombre de fonctionnalités livrées… Ceci afin de leur faire prendre conscience que finalement ils payent trop. Parce que ce qui fonctionne souvent le mieux avec les décideurs, c'est l'aspect financier, et l'accumulation de la dette technique impacte forcément les coûts.

Puis ce qu'il faut aussi leur montrer c'est que la vision actuelle de « livrer avant tout », sur le moyen / long terme ne va faire qu'empirer la situation, jusqu'à atteindre un point de non-retour.

Donc après avoir partagé ce constat, en mettant en avant des indicateurs chiffrés parlant pour le business, la deuxième étape, c'est de les inclure dans le plan de résolution de la dette technique. Il faut présenter le plan, les objectifs, la cible, la roadmap et les différentes étapes. Puis, les impliquer tout du long, en leur présentant les avancées, les réussites et les gains pour eux.

Par exemple, dans le cas d'une brique qui a été refacto en même temps que le développement d'une fonctionnalité, c'est important de leur montrer que le code est clean, et que grâce à ça, lorsqu'une modification a été faite sur cette brique plus tard, ça a pris deux fois moins de temps que la première fois. C'est donc un gain pour eux. 

L'important c'est de donner de la visibilité et surtout de leur montrer l'apport du plan proposé en termes financiers, de productivité ou encore de gain de temps.

 Pour conclure : la dette technique 0 n’existe pas mais elle peut être maîtrisée

Marianne : Il est impossible de rembourser 100% de sa dette technique. Le code d'aujourd'hui est le legacy de demain. C'est inévitable d'en avoir toujours un peu et c'est même le fonctionnement normal d'un projet.

L'objectif c'est d'éviter d'en faire trop. Pour ça il faut faire attention à ne pas prendre des décisions incohérentes et évangéliser les notions de dette technique auprès de ses équipes, diffuser une culture de la qualité. Sensibiliser le management et les sponsors sur le fait que vitesse et précipitation n'ont jamais fait bon ménage. Il faut la rembourser petit à petit, en continu, en fonction du besoin.