La dette technique : une supercherie mythologique pour galériens de l’IT
Ou : “Ben-Hur au COMEX” © Yoann Grange
*Slotch*
Le claquement du martinet sur l’épaule du développeur emplit la salle de réunion de son bruit mou et glaçant. Le Senior Java serre les dents. Il le sait, il doit en passer par là, c’est l’unique chemin de la Délivrance des Crédits, pour pouvoir enfin virer cette daube de micro-service d’authentification utilisant TLS 1.1, dont les carences de sécurité ont dépassé le stade de l’imposture, pour rejoindre sur le banc des accusés de supercherie Charles Pasqua et Houdini. Il gémit : “il est sans doute temps de payer enfin notre Dette Technique”. Les filaments de cuir noir, trempés de son sang, s’élèvent à nouveau pour amorcer leur course douloureuse vers le dos flétri que le Directeur Administratif et Financier contemple d’un œil las… Cette réunion accouchera-t-elle des trois jours-homme dont l’équipe a besoin pour virer la verrue qui infecte leur système ?
Une sensation de déjà-vu ? Des souvenirs de scènes d’auto-flagellation d’équipe technique en Comité Exécutif, avouant le péché de dette technique pour obtenir du temps ?
Causons de ce qui pêche souvent dans une conversation structurée sur la finance des métiers tech :
le logiciel a besoin d’un retour sur investissement complet.
Les comptables ont fait beaucoup de mal à ce sujet [1]. Notamment, en permettant que s’impose cette idée de “dette technique”, qui ne correspond pour moi à aucune réalité. Parlons donc à la place sérieusement des caractéristiques et des conséquences de l’investissement technique. Tordons le coup une bonne fois pour toute à cette légende urbaine :
la dette technique n’existe pas.
Bon, d’abord elle n’existe pas, parce qu’une dette se contracte auprès de quelqu’un, un créditeur, et que dans le cas présent, on n’emprunte à personne. Si pas de créditeur et de débiteur, alors le nom même de dette perd de son sens.
Supprimer du code, c’est investir
Le code n’est pas un bien matériel, ce n’est pas un immeuble comptable à amortir. Oui, je sais, c’est pas cool de bosser sur des objets un peu exotiques, mais c’est comme ça.
Écrire une ligne de code, c’est prendre un risque pour tenter de rendre un service, idéalement plus vite, mieux, et moins cher. On s’intéresse par ailleurs rarement dans ce contexte à l’esthétique de la chose : un bout de tuyau utile et vite raccordé sera toujours préféré à une longue réflexion contemplative devant le dégât des eaux (potentiel) en cours.
La meilleure chose qui puisse arriver à un ingénieur logiciel et à un projet, c’est le moment béni où on SUPPRIME du code. Parce qu’il ne devrait plus servir, parce qu’on vient de le remplacer par beaucoup mieux (par beaucoup moins de code).
Par ailleurs, chaque ligne de moins à maintenir vous fait gagner de l’argent, et des bazillions d’efficacité.
L’approche comptable de l’amortissement sur trois ans est donc complètement inadaptée quand on parle de code. Jeter du code qui ne devrait plus servir, parce qu’il a été écrit il y a un moment pour répondre à un contexte précis, qu’il faut réécrire parce qu’il ne correspond plus au besoin, est un bon investissement.
Il y a plusieurs expressions que l’on entend régulièrement, que j’aimerais aider à bannir de la bouche et des oreilles de tous les ingénieurs logiciel et de leurs supérieurs hiérarchiques. Par exemple : “on est en train de créer de la dette technique (soupir)”, ou : “il va être temps de rembourser notre dette technique !”. La plupart du temps, en réponse à une pression du management pour arbitrer entre différentes priorités.
Cette charge mentale d’une mythique dette technique n’a aucune utilité business, au contraire, elle est extrêmement nocive.
S’en vouloir d’avoir créé une dette technique et de vivre dans le péché ne sert absolument à rien, à part stresser des équipes qui ont déjà tout ce qu’il leur faut à ce sujet. Il est plus sain d’avancer en assumant un risque maîtrisé d’investissement technique.
Une autre façon de considérer l’investissement technique réside en effet dans la connaissance métier de l’équipe technique, qui est longue à acquérir. On investit sur le potentiel futur de l’équipe à mieux résoudre le problème, une fois qu’elle aura acquis la connaissance métier spécifique au problème à résoudre.
Un bon dev dans l’écosystème bancaire va d’abord passer son temps à apprendre le métier, et donc à devenir un banquier qui sait coder. Ça va lui prendre 2 ans, et sa valeur sera bien différente alors, pas seulement liée au code qu’il aura produit. Code qu’il ré-écrira d’ailleurs probablement de zéro, bien plus efficacement, produisant par itération une bien meilleure solution, mieux adaptée au métier bancaire. Si en plus il devient un expert métier capable d’expliquer le dit métier rapidement et efficacement, on touche au sublime.
C’est arrivé chez Clever Cloud, plusieurs fois : pour notre système de monitoring, qui a abouti à Clever Cloud Metrics, ou le gestionnaire de load balancing, qui a été réécrit en deux jours après une v1 écrite en huit mois (et qui était buggy, mais on avait mal posé le problème à la base). Tous ces exemples me confortent dans l’assurance que la vraie valeur est dans l’équipe.
C’est aussi ce qu’apporte plus fortement qu’avant le design, notamment l’UX (User eXperience), dans les projets tech, en informant plus efficacement en amont la décision d’investissement, et en favorisant le prototypage rapide et les itérations, pour limiter les risques.
Une approche morale de la dette technique pousserait logiquement à virer une équipe échouant une première fois face à un problème de métier client. Or, l’expérience acquise par cette même équipe poussera plus probablement un décideur chaussant les lunettes de l’investissement technique à jouer quitte ou double : le risque qu’un deuxième échec ne survienne est bien plus faible avec cette même équipe, qui a beaucoup appris, sur elle-même et sur le métier qu’elle essaie d’aider, pendant ce premier échec. Ils et elles feront mieux et réussiront probablement, puisque connaissant désormais tous les écueils liés à l’activité à améliorer.
On investit (presque) dans le code comme dans l’immobilier
Il n’y a en réalité pas de dette technique, mais des décisions d’investissement, répondant à des objectifs de court, moyen ou long terme. Simplifions tout ça à dessein.
Être CTO, c’est prendre des décisions qui permettent de répondre à 3 types de questions simples : “comment on passe la nuit ce soir ?”, “où dormirons-nous dans 5 ans ?”, ou “quelle valeur (lourdeur) patrimoniale vais-je laisser à mes enfants ?”.
Une petite tente Quechua(™) des familles premier prix montée à la va-vite, cela peut être très utile, surtout quand il est 22h passées. C’est par exemple ce prototype bien crade qui permet de faire une preuve de concept voire d’obtenir un financement, bref, de générer le cash initial qui change un vague “projet de dormir” en truc concret que l’on met face à des clients, le plus rustique des abris (MVP de startup, POC en grand groupe, Startup Weekend…).
Un investissement sûr et de long terme, comme par exemple l’immeuble haussmannien parisien, prend du temps à se réaliser : il ne se construit pas dans la nuit. Pour résoudre le problème de court terme “dormir ce soir”, tu achètes une petite tente, que tu revendras à perte et à court terme également, ou même que tu jetteras quand elle sera usée à la corde (ou devenue inutile).
Tu ne construiras pas ton immeuble sur les fondations de ta tente : certains ont essayé, ça s’appelle un bidonville et ça merdouille assez allègrement (on ne recommande pas, 1 sur 5).
L’évolution naturelle de ton investissement sera de construire un Algeco, le temps que l’immeuble se monte à côté.
Il est aisé d’identifier des logiciels ou morceaux de logiciels à valeur patrimoniale forte : GCC, Linux, GlibC (bref tout GNU par exemple), la JVM, ffmepg… Dans un autre genre, on se doute que Photoshop comprend encore quelques éléments de code du début. DHH parlait récemment d’un script vieux de plus de 10 ans toujours en production chez Basecamp, sur un petit élément mineur du genre “facturer les clients”.
À notre humble niveau, je peux facilement retrouver des morceaux de la console de Clever Cloud codés il y a 9 ans en Italie au bord d’une piscine, et certains autres qui, hormis les mises à jours de dépendances, n’ont pas bougé depuis longtemps (à 400 micro-services c’est normal), mais ce n’est pas pour autant qu’il vont rester là : ils sont quasiment tous en plan de décommissionnement, ce qui ne passe pas par une évolution, mais bien par une réécriture complète.
NB: On notera ici que je parle de ne faire aucune évolution dans un soft SAUF les mises à jour de dépendances. Pour filer la métaphore, tout comme votre immeuble haussmannien, votre tente ou votre Algeco a besoin qu’on fasse le ménage ; il faut se respecter et s’assurer que les lieux restent propres, sinon ça tourne au squat lugubre, et la valeur patrimoniale s’effondre en plus de l’utilisabilité des lieux, au point qu’il ne reste plus rien à en tirer. Votre code c’est pareil : on fait le ménage et on met à jour les dépendances, au moins sur la sécurité et les évolutions majeures, à un rythme minimum mensuel dans tous les projets.
Il existe également un cas particulier : le cas du logiciel de “la migration”, écrit en quelques jours mais exécuté une seule fois lors de La Migration. Souvent considéré comme un investissement à perte, il est négligé, sous-financé et méprisé dans la décision d’attribution de ressources, alors qu’il est clé. Une migration qui se passe mal, perdant de la donnée ou générant du churn (par exemple 10 à 15% des clients qui se barrent), ou encore s’étalant avec des correctifs pendant des semaines ou des mois (en plombant le temps de l’équipe de développeurs), c’est une kyrielle de coûts cachés. Si dans une migration, le coût par nombre d’exécution du soft est effectivement élevé, c’est une mauvaise métrique.
L’heure de développement rapportée au revenu qu’elle sécurise, génère ou économise est bien plus pertinente comme métrique. C’est une ligne d’investissement courte, mais rentable.
Le CTO, ce gestionnaire de portfolio immobilier
Tout comme l’immeuble de maître parisien perdra de la valeur si des investissements réguliers ne sont pas effectués pour l’entretenir, il faudra maintenir les dépendances d’un produit technologique pour qu’il reste à un niveau de standing satisfaisant ou gagne encore en qualité.
Solder une ligne d’investissement, c’est-à-dire supprimer du code doit être un choix d’investissement réalisé l’esprit léger car extrêmement rentable.
Parfois on perd, il sera d’autant plus important de solder rapidement : un investissement qui part en cacahuètes, c’est de plus en plus dur à rattraper. S’il est acceptable de faire des erreurs d’investissement, ça ne l’est pas de s’entêter parce qu’on ne veut pas être la personne qui clôture en perte. Notre première base de données primaire pour Clever Cloud était une Riak. Assez rapidement, on a constaté que PostgreSQL c’était mieux (pour notre cas d’usage, on ne compare pas les techno dans l’absolu) : on a tout jeté sans sourciller pour réécrire de zéro.
C’était une saine décision d’investissement technique. Ce n’est pas en achetant plus d’actions Eurotunnel que tu règles ton problème de valeur d’action descendant dans des fonds abyssaux et de déséquilibre de ton portfolio.
Il est à noter que la décision technique n’est pas obligatoirement une décision d’architecture ou de code, mais peut également concerner l’infrastructure. En effet, beaucoup, beaucoup, de technologies de so-called devops se basent sur une vision par scripting, de “binaire” face à une approche “sémantique” (je vous ferais bien un article là-dessus d’ailleurs, note pour moi-même), qui sont donc toujours des investissements hyper court terme, même s’ils ont l’apparence de l’investissement raisonnable, parce qu’on a utilisé des noms compliqués. C’est un peu comme comme si on avait scellé le lit avec des fondations pour un immeuble de trois étages dans notre tente, et que du coup on ne peut pas l’embarquer quand on emménage dans notre immeuble.
C’est un atavisme assez courant d’empoisonner le code développeurs avec des contraintes plus ou moins pertinentes issues de la production : limitation de technologie, obligation de déployer avec chef/puppet/docker/capistrano/jenkins, un système de secret abscons ou de réglages réseaux improbables rendant l’application totalement inopérante en dehors d’une topologie spécifique… Il est important de comprendre que tout ce qui concerne l’infrastructure et le run sont des lignes d’investissement importantes mais souvent de court terme, à moins d’en faire son coeur de métier. Attention, je parle ici du tooling de la prod et non de l’achat d’infrastructure, qui est souvent un choix judicieux financièrement (vous savez, on vend aussi Clever Cloud on premise).
Bref (si, si),
La dette technique me parait une modélisation impropre des besoins de financement de l’IT, car elle laisse penser que tout logiciel porterait en lui une dette contractée étourdiment par l’équipe. Il n’en est rien, et chaque investissement logiciel, comme tous les autres investissements industriels dans des machines-outils, doit être regardé comme une ligne d’investissement dont on calcule en temps réel le retour sur investissement (ROI pour les intimes), ce qui inclut le coût d’acquisition (ou d’achat initial, de conception, d’écriture initiale interne ; il est amorti dans le temps, plus ou moins vite) et le coût d’entretien (qui est incompressible, sinon on dévalue son investissement).
On parle d’un bon investissement quand les profits (cumulés) surpassent les coûts (cumulés), et il n’est pas indécent de penser à la décommission quand l’amortissement est abouti.
Passons sous le voile pudique du silence les cas où l’absence de toute mesure des coûts et profits empêche de saines décisions d’investissement technique.
Toute négligence dans les coûts d’entretien entraînera des frais de remise en état ultérieurs (souvent décrits comme dette technique) et c’est pourquoi il faut toujours les provisionner, en langages technique on dit “chaque ligne de code en prod est une ligne de code qu’il faut maintenir”.
Enfin, comme dans tous les investissements, parfois on en fait un mauvais, mais il faut l’accepter et solder la ligne déficitaire. Ça ne sert à rien de garder vos actions Thomas Cook, mobilisez votre attention et votre énergie sur un dossier (plus) pertinent.
Pourquoi est ce important ? Parce que cela change totalement la vision de la technique, et arrête de consacrer une approche patrimoniale gravée dans la roche pour chaque ligne de code produite, comme devant rapporter pour l’éternité ou être marquée du sceau infamant de “dette technique”. Parce que si on exige une folie pareil, on demande à chaque décisionnaire technique de prédire le futur de façon certaine au lieu de faire des investissement plus ou moins risqués en connaissance de cause.
Parce que c’est nier le fait absolu que nous faisons de l’industrie, que notre travail est de concevoir des machines outils se substituant à un cerveau humain, en y incluant son entretien, son évolutivité, son décommissionnement et son recyclage.
Ne nous quittons pas comme ça : je vous laisse avec cette discussion en quatre parties enregistrée il y a peu au DOJO, notre maison nantaise, avec Damien Cavaillès. On aborde notamment ce sujet et d’autres dans l’épisode ci-dessous :
Y’en a un peu plus j’vous l’mets quand même: épisodes 1, 3 & 4.
Je remercie chaleureusement Yann Heurtaux pour sa collaboration dans l’écriture du billet et Yoann Grange pour ses idées et participation graphique.
[1] J’ai souvent abordé ce sujet sur scène. Je vous propose par exemple cette capture des Voxxed Days Luxembourg 2016, à partager d’urgence avec tous nos amis à tableurs : “Les comptables ont fucked-up la gestion de mon IT” — YouTube
Quentin ADAM est le CEO de Clever Cloud.
Vous Développez.
Nous Déployons.
Clever Cloud est un service d’automatisation de votre usine logicielle : toutes les opérations d’infrastructure ne sont plus à votre charge, au profit de votre cœur de métier.
