Le rôle crucial de la veille
Dans un ouvrage publié en 2015 (La Dette Technique, Ed. Les Contrôleurs du train de 13h37), Bastien Jaillot, cofondateur de l’ESN JoliCode, définit la dette technique comme « l’accumulation des risques pris lors des différentes phases techniques tout au long de la vie d’un projet ». Selon lui, le phénomène se divise en quatre catégories : la dette involontaire, due à de mauvaises pratiques et un manque de communication, la « dette par négligence volontaire » ou fonctionnement « à la rustine », la dette assumée, souvent créée pour répondre à des contraintes de temps, avec l’intention de rapidement corriger ce qui peut l’être, et la dette inévitable, qui résulte de la « sédimentation naturelle du code ». Sur ce dernier point, une veille assidue sur le marché jouera un rôle crucial. Développeur indépendant basé dans la région lyonnaise, Valentin Jeudy donne un exemple : « Pour le typage en JavaScript, jusqu’à très récemment, il y avait deux solutions : TypeScript, un outil développé par Microsoft, et Flow, créé par Facebook. Il se trouve que le premier a gagné la guerre entre les deux et il y a de fortes chances qu’à terme, Flow ne soit plus supporté. Ce n’est pourtant pas une technologie spécialement vieille. Cela illustre bien à quel point il est parfois compliqué pour les développeurs de faire des choix, car il faut penser en termes de tendances. » Un constat qui paraît évident aujourd’hui, mais qui l’était beaucoup moins il y a 10, 15 ou 20 ans.
Régis Massé, DSI de l’Afnic
Tabula rasa
Récemment partie à la conquête de sa dette technique, l’Association française pour le nommage Internet en coopération (Afnic) est une parfaite illustration de cette problématique. Avec l’entrée en vigueur du RGPD, ainsi que l’accession à des normes de sécurité de plus en plus exigeantes, il devenait urgent pour l’organisation de revoir de fond en comble son SI. Problème, celui-ci était en place depuis deux décennies, avec toutes les contraintes que cela implique. « Même si le système fonctionnait bien, il été bâti sur des fondations qui avaient plus de vingt ans et sur lesquelles on avait rajouté plusieurs couches supplémentaires au fur et à mesure, détaille Régis Massé, DSI de l’Afnic; On s’est retrouvés avec des besoins de compétences plus présentes dans l’entreprise, des langages vieillissants, avec notamment une grande partie de l’architecture écrite en Perl, et d’autres éléments techniques qui freinaient notre volonté de pouvoir livrer plus rapidement de nouveaux services à nos clients. » Après une étude menée en profondeur sur l’état du SI, la direction opte pour une refonte complète en repartant de zéro. En 2016, un programme de trois ans est initié à cet effet, avec une équipe d’une trentaine de personnes dédiée au projet dont la moitié travaille sur le développement logiciel, et l’autre sur l’infrastructure, elle aussi refondue. Là où la dette technique complexifie le processus, c’est dans la recherche dans le code des corner cases, ces fonctions propres à un client spécifique qu’il faut pouvoir reproduire dans le nouveau système pour ne pénaliser personne. « On se retrouve à faire de l’archéologie dans la documentation d’un vieux logiciel maison pour en comprendre certains points précis », s’agace M. Massé.Une dette contextuelle
Qui dit refonte totale ne dit bien évidemment pas anéantissement de la dette technique. « On sait que notre système va continuer à vivre en récupérant au passage un peu de dette technique année après année, confirme le DSI de l’Afnic. Mais la nouveauté après cette refonte, c’est qu’on a mis en place une véritable usine logicielle faite de principes, de processus et d’outils d’intégration continue qui nous permettent de générer de la documentation, de faire des contrôles sur le code pour être sûr de bien respecter l’évolution des normes, de réécrire plus facilement… Ça a demandé de l’appropriation par les équipes au départ. Il fallait monter en compétence aussi bien sur la technique que la méthode agile. On a eu un peu de retard au début, le temps de mettre tout ça en place, mais on sent maintenant toute la valeur ajoutée amenée par cette décision. » Bien entendu, si l’idée d’une refonte complète est réaliste pour une entreprise comme l’Afnic, avec des moyens financiers et humains, et une large majorité de logiciels internes, elle le sera beaucoup moins pour une entreprise modeste, qui plus est connectée à de nombreux services externalisés. Le contexte est un élément central du concept de dette technique. De même, si l’obsolescence des langages et autres outils de développement est inévitable, la dette technique n’est pas toujours mesurable comme une donnée objective. Selon sa formation, son expérience ou ses habitudes de travail, une équipe de développeurs débarquant sur un nouveau projet peut tout à fait fustiger l’approche des anciens employés en désignant telle ou telle partie du code comme de la dette technique.
Quentin Adam, fondateur et directeur de Clever Cloud.
La technique, seule coupable ?
Dans ce cas-là, le concept est-il vraiment adapté à toutes les situations ? Pour Quentin Adam, fondateur et directeur de Clever Cloud, une ESN spécialisée dans l’automatisation des infrastructures, la réponse est catégoriquement négative. Il réfute d’une part le mot dette, puisqu’il n’y a pas de créancier. D’autre part, le terme reflète selon lui très mal la réalité du marché. « Le code peut avoir vieilli, ne plus être à jour, ne plus correspondre aux besoins de l’entreprise. Mais il n’existe pas de bon code, qui sera bon pour toujours, et de mauvais code qui serait déjà mauvais au moment où on l’écrit, uniquement des investissements contextuels. » La dette technique serait par ailleurs un moyen de fustiger les développeurs sur des décisions devant de toutes façons être prises. « On a des scènes surréalistes où le directeur technique va voir la direction en s’auto-flagellant à l’avance pour avoir accumulé de la dette technique comme si c’était une faute. Il se retrouve dans la position d’un consommateur de ressources qui doit négocier chaque décision, alors que logiquement, la prod devrait être le centre de profits. » Une critique que partage Bastien Jaillot, qui note que ce phénomène fait un choix « impliquant le risque de voir apparaître des erreurs plus tard, ce qui existe dans tous les domaines, mais chez nous il a un nom et il est mal vu ». Dans son livre, il dénonce d’ailleurs des situations « invivables » menant au surmenage, parfois même à la démission de l’équipe technique. Pas surprenant, donc, de voir le mouvement DevOps s’emparer de la question. Dernièrement, c’est d’ailleurs chez Microsoft que le sujet a resurgi, au détour d’un billet de blog. Silviano Blea, responsable du développement d’applications à Mountain View, y affirmait que la vision classique de la dette technique pouvait nuire à l’adoption et la transformation d’une entreprise qui suivrait la méthode DevOps. Dans cette « culture Anti-DevOps », la dette technique « s’insère dans un projet ou un environnement au fil du temps sans tenir compte de la conception, de l’architecture ou de la mise en œuvre globale », écrit-il, ajoutant qu’il faut « courir vers elle plutôt que s’en éloigner ». Plus d’anticipation, une meilleure conciliation entre la prise de décision et la technique pure, voilà les ingrédients permettant non pas d’éliminer la dette technique, mais plutôt de cohabiter avec elle.