« L’endettement est comme n’importe quel autre piège, il est assez facile d’y entrer et difficile d’en sortir » - Josh Billings, humoriste américain. La dette ! Dans l’univers de l’informatique, c’est l’un des mots les plus obscènes. Comme dans la vie courante, la seule mention de la dette provoque un sentiment d’accablement et de stress. Et se désendetter est une véritable corvée. Dans le domaine de l’ingénierie logicielle, la dette technique fait généralement référence à un système qui vieillit et qui consomme un temps précieux des développeurs IT. La dette technique doit être gérée, maintenue, réduite. C’est souvent ce qui figure en bout de liste des tâches à faire et qui finira par vous faire couler. Mais faut-il qu’il en soit ainsi ? Une école de pensée qui fait son chemin au sein des équipes d’ingénierie progressistes affirme que la dette technique devrait faire partie intégrante du travail de tous les développeurs de logiciels. Gérer cette dette de manière proactive éviterait non seulement de se retrouver la tête sous l’eau mais contribuerait aussi à prendre le pas sur la concurrence.

Qu’est-ce que la dette technique ?

La métaphore de la dette technique a été formulée en 1992 par l’informaticien Ward Cunningham qui l'explique dans une vidéo. Elle exprime l’idée que le développement de solutions à court terme pour les systèmes informatiques entraîne un ensemble d’arbitrages qui exposeront par la suite à des contraintes qui devront être « remboursées » sous la forme de tâches d’ingénierie. Le développeur Martin Fowler l’expose ainsi en 2003 : « Dans cette métaphore, faire les choses rapidement, de façon bâclée, crée une dette technique similaire à une dette financière. Tout comme une dette financière, la dette technique implique le paiement d’intérêts qui se présentent sous la forme de tâches supplémentaires à fournir pour les développements futurs ». 

En moyenne, un développeur est mobilisé plus de 13 heures par semaine par cette dette technique, selon le rapport Developer Coefficient, publié par Stripe en 2018. Aujourd’hui, alors que les applications deviennent de plus en plus complexes, la gestion de cette dette n’a jamais été aussi critique. « tout code que vous considérez comme un passif est une dette technique », a indiqué Alexandre Omeyer, CEO de Stepsize, une société de services IT spécialisée sur la question.

La dette technique revêt une grande variété de formes. « Dans sa moindre apparence, il peut s’agir d’une petite portion de code qui nécessite un remaniement, de bibliothèques qui doivent être mises à niveau ou de tests unitaires qui doivent être corrigés », a énuméré il y a quelques mois Isaac Sacolick dans une chronique sur InfoWorld. « Dans sa forme la plus importante, la dette technique couvre la réingénierie d’applications monolithiques complexes, le portage de protocoles de services web obsolètes, la consolidation de différentes plateformes sur un seul standard, le nettoyage des problèmes résultant de dettes de données, la modernisation de l’insfrastructure, l’introduction de pratiques d’observabilité ou l’automatisation d’un backlog de tests manuels. Le pire type de dette technique, c’est de se retrouver face à une plateforme exigeant un changement radical urgent parce que les pannes et incidents récurrents qu’elle génère ont un impact sur l’activité de l’entreprise [NDLR : on parle en anglais de ‘burning platform’] ».

Bien que le fait de travailler sur ce qui est décrit comme une « burning platform » puisse sembler moins attrayant que de livrer de nouvelles fonctionnalités brillantes, ce n’est qu’en s’attaquant en équipe à la dette technique, de façon proactive et continue, que les développeurs peuvent s’épargner un fardeau plus lourd à long terme. « On néglige souvent de s’occuper de la dette technique car cela répond rarement à un besoin métier urgent et, surtout pour les cas non urgents, le retour sur investissement n’est pas clair et c’est par conséquent perçu comme pouvant être reporté », décrit Isaac Sacolick. « C’est un problème classique pour tout ce qui concerne les questions de maintenance, qu’il s’agisse de code informatique ou de maisons. »

Affronter l’abîme de la dette technique

Pour Mik Kersten, auteur du livre « Project to Product » et fondateur de Tasktop, « la dette technique doit être considérée comme un domaine de premier ordre, à aborder de manière proactive. Malheureusement, bien souvent, cette façon de l’aborder est un nouveau concept ». De nombreuses équipes d’ingénierie, en particulier dans les organisations qui connaissent une croissance rapide, la dette technique est en concurrence avec la charge importante que représente la livraison de nouvelles fonctionnalités. Mais pour Charity Majors, la fondatrice et CTO d’Honeycomb, la dette technique elle-même est « un signe de succès, cela signifie que vous êtes toujours en vie ». Bien que cela soit plus facile à dire qu’à faire, il faut opérer un changement cultural dans toute l’entreprise pour que la dette technique soit vraiment prise au sérieux. « Etre capable d’avoir un véritable backlog prioritisé est un défi pour beaucoup d’entreprises. Particulièrement pour celles qui sont arrivées à un stade où elles incitent à livrer de nouvelles choses, alors que dans le même temps elles n’accompagnent la réduction de la dette technique d’aucun encouragement ou incitation basés sur la performance », a confié Rachel Stephens, analyste du cabinet RedMonk, à InfoWorld. Ce que confirme Mik Kersten de Tasktop : « Ce n’est qu’à travers des mesures d’incitation motivantes que l’on entre dans une spirale vertueuse de destruction de la dette technique ».

Comment prendre en charge sa dette technique

Il y a quelques semaines, John Kodumal, CTO et co-fondateur de LaunchDarkly, a expliqué à InfoWorld que « si la dette technique est inévitable dans le développement logiciel », être proactif pour la réduire dans le temps « est beaucoup plus sain que d’arrêter d’autres tâches pour essayer de se sortir d’une montagne de dette accumulée ». Cette approche proactive pour y faire face implique de traiter tout ce qui pourrait être considéré comme une dette technique à l’instar d’une autre tâche à inclure dans son processus agile normal. « Le secret pour maintenir les applications et éviter, ou du moins retarder, le statut de système hérité, réside dans la façon dont les organisations et les équipes gèrent cette dette », avance Isaac Sacolick. La clé est d’être proactif, ce qui revient à « établir une politique, une convention et des processus pour amortir le coût de la rédaction de la dette dans le temps ».

De nombreuses équipes seront tentées de consacrer un certain volume de capacités au traitement de la dette, par exemple 20% de chaque sprint. Cependant, Mik Kersten conseille d’adopter une approche plus dynamique qui tient compte du contexte des échéances à venir ou des disponibilités de l’équipe. « Vous devriez mesurer le résultat commercial et l’investissement dans la dette technique et vous assurer qu’ils s’équilibrent », précise le fondateur de Tasktop. « Rendez la dette technique visible afin de toujours savoir ce que vous gérez. Une fois qu’elle est visible, fixez un pourcentage cible pour le livré, celui-ci devant être dynamique dans le temps. »

Pour Ben Kus, CTO du fournisseur de stockage cloud Box, le remboursement de la dette technique est un élément que toutes les équipes d’ingénierie doivent inclure dans leur backlog de tâches à exécuter. « Bien sûr, c’est repoussé, mais il devrait y avoir un sentiment permanent que l’on s’en préoccupe de façon constante », estime-t-il. Le CTO de Box ne recommande cependant pas de confier à certains ingénieurs la tâche de se concentrer sur la dette technique. « Ne l’appelez pas ainsi, c’est de là que viendra le désintérêt », souligne-t-il. « Personne ne veut travailler sur la dette technique, ou sur le réusinage de code [en anglais refactoring], ou sur tout autre tâche de cette nature ». Au lieu de cela, chez Box, on cherche à diviser le travail de manière égale entre les équipes d’ingénierie et à faire remonter les problèmes pendant le processus de sprint, dans les postmortems et lors des appels. « Nous avons un processus postmortem rigide et nous identifions les choses à corriger pour éviter que les mêmes problèmes ne se reproduisent », explique Ben Kus. « Nous ne sommes pas assez présomptueux pour dire « laissez tout tomber pour réparer cela », mais nous disons clairement que si un problème se reproduit, cela devient une question de responsabilité. C’est extrêmement désagréable si quelque chose se produit pour la deuxième fois ».

L’importance des astreintes par roulement

La mise en place d’astreinte est un élément de plus en plus important dans la mesure où les équipes d’ingénierie cherchent de façon effective à déceler et à mesurer la dette technique qui les ralentit. Les responsables de l’ingénierie comme Charity Majors d’Honeycomb sont partisans de demander régulièrement à certains développeurs d’arrêter de travailler sur les fonctionnalités pour se mettre d’astreinte et se concentrer sur la correction, le refactoring et l’automatisation de la réduction de la dette. « Il est important d’avoir un ingénieur qui est principalement responsable des petites choses. Et lorsque l’on est d’astreinte, il faudrait absolument être dissuadé de travailler sur les produits. Cela introduit de la souplesse dans un système qui en a généralement très peu », estime Charity Majors.

Chris Evans est le fondateur de Incident.io, une start-up spécialisée dans les logiciels de réponse aux incidents. « L’objectif du suivi est d’éliminer les connaissances implicites », a-t-il expliqué à InfoWorld. « Vous serez contacté pour des choses que vous n’êtes pas le mieux placé pour traiter ». Bien que cela puisse faire peur au début, les problèmes seront résolus, et ensuite, en soulignant ce qui n'a pas fonctionné pendant les débriefs post-incident ou les post-mortems, l'importance de s'attaquer à cette dette pourra devenir plus évident. « En assumant la responsabilité opérationnelle du travail que nous faisons, nous resserrons les boucles de rétroaction entre la livraison et l'exécution. Cela nous aide à prendre des décisions d'ingénierie pragmatiques et à créer une tension saine entre la livraison de nouveau code et le support et l'amélioration de ce que nous avons », explique Chris Evans dans un billet de blog publié en décembre. 

Par exemple, les équipes d’Incident.io ont récemment été ralenti par des interactions avec l’une de leurs bases de données. « Avec une semaine d’investissement, nous pensons pouvoir construire une meilleure façon d'interagir avec la base de données, ce qui pourra avoir un effet sur la façon dont nous construisons chaque fonctionnalité à l’avenir », indique M. Evans. Et ces succès doivent être célébrés de manière aussi significative qu’un incident majeur résolu ou qu’une nouvelle fonctionnalité intéressante, que ce soit sous la forme de la « tiare de la dette technique » que Charity Majors présente sur Twitter ou, comme le suggère Mik Kersten, en célébrant « l'élimination d'une grande partie de la dette technique comme la conquête d'un nouveau client ».

Repenser la dette technique au Financial Times 

Le Financial Times a passé les six dernières années à remodeler son approche de la dette technique. En 2015, le site web du journal britannique était alimenté par une application monolithique appelée Falcon. En 2016, les développeurs de l'entreprise ont converti Falcon en un ensemble de microservices, désormais appelé Next dans son intégralité. Les 332 référentiels de code qui en ont résulté sont gérés par un ensemble d'équipes solides avec des responsabilités définies, allant des applications, de la découverte de contenu et des publicités, aux plateformes centrales, qui sont responsables de 72 référentiels à elles seules. « En l'espace d’un an environ, les choses avaient commencé à ne plus aller aussi bien », a relaté Anna Shipman, directrice technique des produits clients au Financial Times, lors de la conférence QCon à Londres en avril.

Les équipes avaient perdu de vue la stratégie technique globale et la répartition des services. Cela a conduit à une accumulation croissante de dettes techniques, à des « forêts hantées », c'est-à-dire des bases de code orphelines auxquelles personne ne voulait toucher, et à une diminution du nombre d'ingénieurs disposés à être disponibles en dehors des heures de travail. Comme l’un des collègues d’Anna Shipman lui a dit : « Nous n’avons pas l’impression de posséder ou de guider le système. Nous nous contentons de rafistoler ». Lutter contre cette situation exigeait un effort conscient pour aller vers l'ordre, en éliminant ces forêts hantées et en acceptant la complexité afin de pouvoir la gérer plus efficacement. Ce n'est que lorsque les équipes se sont clairement approprié leurs piles technologiques que l'organisation a pu commencer à s'attaquer plus consciemment à ces dettes techniques et à ces forêts hantées.

« Ce n'est pas quelque chose à faire en parallèle à la livraison régulière de fonctionnalités, c'est une tâche pour laquelle il faut correctement réserver du temps et à planifier », a déclaré Anna Shipman. « Il ne s'agit pas d'une opération ponctuelle. Il ne suffit pas de faire un peu de nettoyage pour que tout rentre dans l'ordre. » Bien qu'il n'y ait pas de mandat central pour affecter, disons, 20% de tout le temps d'ingénierie à la suppression des forêts hantées et à la gestion de la dette technique, Anna Shipman pense que les équipes sont maintenant mieux habilitées à équilibrer la livraison de fonctionnalités par rapport à la dette technique.

Convaincre la direction

Une fois que l’on a pu réévaluer la relation avec la dette technique dans l'ensemble de l'ingénierie et que les développeurs ont compris l'intérêt de « ralentir » pour traiter la dette technique de manière continue, le défi ne s'arrête pas là. Il faut encore communiquer cette valeur à la direction générale. Le traitement de la dette technique est peut-être la première chose que l’on enlève des priorités dans la poursuite des objectifs métiers, mais il est impératif que les responsables de l'ingénierie changent ce discours.

« L’une des plaintes les plus courantes que j'entends lorsque je discute avec des ingénieurs est qu'ils ont l'impression de devoir continuellement travailler sur des fonctionnalités, alors que les logiciels et les outils avec lesquels ils travaillent deviennent plus fragiles, incohérents et frustrants, et qu'il leur est de plus en plus difficile de faire leur travail », a écrit David Van Couvering, architecte principal senior chez eBay, dans un billet de blog publié en février. 

Pour faire comprendre aux entreprises les risques que représente ces systèmes fragiles, il faut souvent parler leur langage. Il faut souligner comment le fait de s'attaquer à la dette technique maintenant peut permettre à l'ingénierie d'aller plus vite à l'avenir, garantir que le logiciel est plus sûr et garder les ingénieurs heureux ou les empêcher de partir. « Les autres ingénieurs comprendront l’importance de ce travail », assure Anna Shipman du Financial Times. « Racontez une histoire dont votre partenaire métier est le héros et dans laquelle vous êtes le guide de confiance. Vous devez vraiment établir un lien avec les métriques métiers, tels que les délais d’exécution, les performances et la qualité », conseille-t-elle.

Ne prenez pas le risque

Pour réussir à gérer la dette technique, il faudra déployer beaucoup d'efforts pour changer des cultures et des méthodes de travail bien ancrées, ainsi que pour améliorer la communication entre l'ingénierie et l'entreprise au sens large. Les motivations des développeurs devront peut-être changer, mais les risques d'ignorer les piles croissantes de dette technique sont potentiellement existentiels.

« Votre argument contre la dette technique sera renforcé si vous vous attachez à aider votre homologue métier à comprendre comment les décisions prises aujourd'hui augmentent les risques futurs. Parlez de la perte de prévisibilité du projet. Montrez comment les compromis actuels entraînent une dégradation des performances plus tard », écrivait Rachel Stephens, analyste chez RedMonk, en 2017. Oui, les nouvelles fonctionnalités brillantes rendent les clients et les dirigeants heureux, mais les systèmes chargés de dettes peuvent tout arrêter de manière brutale, et se sortir de ce très mauvais pas n’a rien d'une partie de plaisir.