La dette technique que personne ne voit

Quand un développeur dit “on a de la dette technique”, tout le monde hoche la tête. Il y a une classe de trois mille lignes que plus personne ne veut ouvrir, un test désactivé depuis deux ans, un TODO daté de 2019. C’est moche, mais c’est visible. Ça vit dans un dépôt, ça passe en revue de code, ça finit dans un ticket.

Maintenant essayez la même phrase côté infrastructure. “On a de la dette technique sur la plateforme.” Silence poli. Personne ne sait de quoi vous parlez, parce que personne ne peut la regarder.

Et c’est exactement pour ça qu’elle coûte plus cher que l’autre. Je vous explique.

Pourquoi est-ce qu’on ne la voit pas ?

La dette applicative a une adresse. Vous pouvez l’ouvrir dans un éditeur, la pointer du doigt en réunion, la compter en lignes.

La dette d’infra, elle, n’est nulle part. Elle est dans ce qui n’a pas été fait. Vous allez reconnaître :

• le serveur sous une distribution en fin de support, que plus personne ne redémarre par superstition ;
• le module Terraform copié depuis un autre projet, avec deux variables qui ne servent à rien mais qu’on n’ose pas retirer ;
• le pipeline de déploiement qui marche, oui, mais qui embarque trois étapes manuelles que le collègue parti l’an dernier était le seul à savoir enchaîner ;
• le groupe de sécurité ouvert “temporairement” pour un test en 2022.

Rien de tout ça ne produit d’erreur. Rien ne casse le build, aucun outil ne remonte d’alerte. Le système fonctionne. Il fonctionne juste de plus en plus mal, et de plus en plus lentement.

Et puis il y a un détail qui change tout. Vous avez déjà vu quelqu’un faire une revue de code sur un dimensionnement de cluster ? Une relecture à deux d’une politique de rétention, d’un choix d’instance, d’une topologie réseau ? Moi non plus. On relit le code d’un développeur avant de le fusionner, c’est devenu un réflexe. Ces décisions-là sont prises seules, souvent dans l’urgence d’une mise en production, et elles ne repassent jamais devant personne.

Une décision qu’on ne relit jamais, c’est une décision qui ne sera jamais corrigée.

Où est-ce qu’on la paie, alors ?

Le plus pervers, c’est qu’elle est facturée en permanence, mais jamais sur une ligne qui porte son nom.

Sur la facture cloud, d’abord. Tout le monde regarde le total, personne ne regarde le delta. Ce n’est pas la même chose. Le total, on le compare au mois dernier, et comme il monte doucement, on met ça sur le compte de la croissance. Le delta, c’est l’écart entre ce que vous payez et ce que vous paieriez si l’infrastructure était propre. Cet écart-là, personne ne le calcule, parce qu’il faudrait déjà savoir à quoi ressemblerait une infrastructure propre. C’est du travail d’ingénieur, pas un rapport de billing. Du coup on paie. Posez la question autour de vous : combien vous coûte votre dette d’infra ce mois-ci ? Personne ne saura répondre, et pourtant c’est prélevé tous les mois.

Sur les délais, ensuite. Une équipe qui met trois semaines à sortir un correctif ne dit jamais “c’est à cause de la dette d’infra”. Elle dit que la recette est longue, que la préproduction n’est pas iso, qu’il faut coordonner deux équipes. C’est vrai. Mais si la préproduction n’est pas iso, c’est parce qu’elle a été montée à la main il y a quatre ans et que plus personne ne sait la reconstruire. La dette ne se présente jamais sous son vrai nom, elle se présente sous le nom de vos délais.

Sur les gens, enfin. Et c’est de très loin le poste le plus cher. Une plateforme où chaque intervention demande un rituel et une bénédiction épuise ceux qui la tiennent, et empêche les nouveaux d’y entrer. Vous vous retrouvez avec une astreinte que tout le monde fuit et un turnover que le DRH mettra sur le compte du marché.

C’est là-dessus que je veux m’arrêter, parce que c’est le seul endroit où je peux vous parler de ce que j’ai vu plutôt que de ce que je déduis.

Ce qui n’est pas automatisé finit dans une tête

Commençons par le plus banal : tout ce qui n’a pas été automatisé.

Chaque geste manuel qui reste dans une chaîne de production est une dette à part entière. Il ne coûte rien la première fois, quinze minutes la vingtième, et surtout il finit par se ranger quelque part. Cet endroit n’est presque jamais un dépôt Git. C’est la tête de quelqu’un.

La bascule de trafic à faire “dans le bon ordre”, et le bon ordre n’est écrit nulle part. Le certificat renouvelé à la main tous les ans, avec la commande retrouvée dans l’historique du shell. Le script qui traîne dans le répertoire personnel d’un serveur et qu’il faut penser à lancer après la mise en production. Vous en avez sûrement deux ou trois en tête à la lecture, et c’est bien le problème : la connaissance qui fait tourner la plateforme n’est plus dans la plateforme. Elle est répartie dans trois ou quatre cerveaux, et ces cerveaux prennent des vacances.

Le test, vous n’avez même pas besoin de le provoquer, il arrive tout seul en août. Regardez ce que l’équipe n’ose plus faire quand une personne est absente deux semaines. Ce qu’on repousse à son retour, c’est la liste exacte de ce qui n’a pas été automatisé, et vous n’avez pas à la rédiger : elle s’écrit toute seule dans le canal de l’équipe, un message à la fois, “on attend qu’il rentre”.

Personnellement, ce qui me gêne le plus là-dedans, ce n’est même pas le risque. C’est que la personne indispensable est en réalité une personne coincée. On ne fait pas évoluer quelqu’un qu’on ne peut pas remplacer sur son poste actuel. J’ai vu des gens rester bloqués trois ans à cause de ça, et le vivre comme une punition, pendant qu’on leur répétait que c’était une marque de confiance.

Et le jour où vous arrivez dans l’équipe ?

Là, on arrive à ce qui m’a fait écrire ce billet.

Reconstruire une plateforme de zéro, franchement, ça ne me fait pas peur. C’est long, c’est du travail, mais c’est un travail qui avance. Chaque heure passée produit quelque chose : une ressource de plus, un bout de code qui existe, une brique qui tient. Le soir, vous savez ce que vous avez fait.

Arriver dans une équipe où l’information est éparpillée, c’est autre chose. Vous avez déjà compté ce qu’un nouveau passe à chercher plutôt qu’à produire, sur ses trois premiers mois ? Vous passez vos journées à chercher. Vous demandez à quelqu’un, il vous répond de voir avec un autre, l’autre est en réunion. Vous trouvez une procédure, elle date de deux ans, vous ne savez pas si elle est encore bonne, donc vous allez vérifier. Vous ouvrez trois wikis pour comprendre lequel fait foi. Et le soir, vous êtes vidé, sans avoir rien produit du tout.

C’est ça que personne ne compte. Reconstruire, c’est fatigant. Chercher, c’est usant. Ce n’est pas la même énergie, et ce n’est pas le même moral. Un ingénieur à qui vous demandez de tout refaire proprement va y aller ; le même, à qui vous demandez pendant six mois de deviner comment ça marche, va commencer à regarder ses mails de recruteurs.

Ceux de ma génération voient tout de suite de quoi je parle : c’est la maison qui rend fou des Douze Travaux d’Astérix. Le laissez-passer A38 existe, il est quelque part, personne ne vous ment. C’est juste que chaque guichet vous renvoie vers un autre étage, et qu’au bout de trois jours vous avez oublié pourquoi vous étiez venu.

Et voilà pourquoi j’insiste : une personne qui arrive est le meilleur instrument de mesure que vous aurez jamais. Elle voit tout ce que vous ne voyez plus. Le hic, c’est que vous n’avez qu’un seul essai. Au bout de trois mois, elle aura intégré les contournements comme tout le monde, elle saura à qui demander, et elle arrêtera de trouver ça anormal. À ce moment-là, elle ne mesure plus rien, elle fait partie du problème. Comme nous.

“Il suffit de documenter”

C’est en général la réponse qu’on me fait à ce stade. Sur le principe, oui. En pratique, ça bloque à trois endroits.

Le plus souvent, la documentation n’est pas écrite du tout. Elle est prévue pour la fin du projet, sauf que la fin du projet n’existe pas : il y a la mise en production, puis les correctifs, puis le projet suivant. C’est la seule tâche qu’on peut reporter indéfiniment sans que personne ne s’en aperçoive avant qu’il soit trop tard.

Quand elle est écrite, on ne la retrouve pas. Et celle-là me rend fou, parce que le travail a été fait, quelqu’un y a passé du temps. Sauf que c’est la page d’un ancien wiki, l’espace Confluence d’une équipe dissoute, un fichier Markdown dans un dépôt d’outillage que personne n’ouvre, un message épinglé dans un canal archivé. Trois versions de la même procédure existent, aucune n’est datée, et personne ne sait laquelle fait foi. Une documentation qu’on ne trouve pas en deux minutes n’existe pas — pire, elle coûte plus cher que rien, parce qu’on perd du temps à la chercher avant de renoncer.

Et quand on la retrouve, elle ment. Une procédure écrite il y a dix-huit mois décrit une plateforme qui n’existe plus. Ce cas-là est le plus dangereux des trois, parce qu’on la suit : on ne se méfie pas d’un document qui a l’air propre.

Ma conviction, à force, c’est que la documentation ne remplace jamais l’automatisation, elle la reporte. Écrire une procédure en douze étapes, c’est reconnaître que ces douze étapes existent et choisir de les garder. Un script, même moche, même sans tests, a un avantage définitif sur la plus belle page de wiki jamais rédigée : il est toujours à jour, sinon il échoue. C’est d’ailleurs tout l’objet de ce que j’écrivais sur les mises en production sans intervention humaine.

Donc quand vous hésitez entre documenter un enchaînement de commandes et l’automatiser, automatisez. Gardez l’écrit pour ce qu’un script ne dira jamais : pourquoi c’est comme ça, et ce qu’on a écarté en chemin. Et mettez-le à côté du code, dans le même dépôt, versionné avec lui. Pas dans un outil tiers où il mourra de sa belle mort à la prochaine réorganisation.

Le cloud n’a rien arrangé, il a accéléré

On nous a vendu l’inverse. Le cloud devait supprimer la corvée d’infrastructure, l’infrastructure as code devait rendre tout reproductible, le DevOps devait casser les silos. Sur le papier, très bien. En pratique, on a surtout retiré les freins.

Avant, monter un serveur coûtait un bon de commande, trois semaines de délai et une discussion avec quelqu’un dont c’était le métier. Cette lenteur était pénible, mais elle servait à quelque chose : elle obligeait à réfléchir avant. Aujourd’hui une ressource se crée en quarante secondes. Qui a validé ce type d’instance, cette taille de disque, cette ouverture ? Personne, et personne ne le saura jamais. Ce qui prenait trois semaines à naître prend maintenant trois ans à mourir.

L’infrastructure as code n’a pas arrangé les choses autant qu’on l’espérait, parce qu’on l’a traitée comme de la configuration et pas comme du code. Pas de tests, pas de revue, pas de refactoring. On a juste écrit la dette dans un fichier au lieu de la cliquer dans une console. Vous connaissez le symptôme. Un matin, vous lancez un plan pour ajouter trois lignes, et vous tombez sur ça :

Terraform will perform the following actions:

  # aws_security_group.legacy_api will be destroyed
  # (because aws_security_group.legacy_api is not in configuration)
  - resource "aws_security_group" "legacy_api" {
      - description = "temporaire - ticket OPS-4412" -> null
      - name        = "legacy-api-sg"
    }

  # aws_instance.batch_nightly must be replaced
-/+ resource "aws_instance" "batch_nightly" {
      ~ ami = "ami-0c1b4dff" -> "ami-09f7a2e1" # forces replacement
    }

Plan: 1 to add, 0 to change, 2 to destroy.

Vous n’avez touché à aucune de ces ressources. Quelqu’un les a modifiées à la main dans la console, il y a des mois, et l’état n’a jamais été réconcilié. Et là, ce qui se passe dans quatre-vingt-dix pour cent des cas, c’est qu’on ne corrige pas l’écart : on arrête de lancer terraform plan.

Quant au DevOps, dans beaucoup d’endroits, il a surtout consisté à donner les clés du cloud à des équipes de développement sans leur donner le métier qui va avec. Ce n’est pas un reproche et je l’ai déjà écrit ici même : ce n’est pas leur métier. Mais le résultat est mécanique. On crée de la dette d’infra à la vitesse du développement, et on la rembourse à la vitesse de personne.

Une dette qu’on ne mesure pas, on la paie cash

Une dette financière a au moins la décence de figurer sur un bilan. On connaît le capital, on connaît le taux, on peut décider de rembourser ou pas. C’est un choix.

La dette d’infrastructure, elle, n’apparaît nulle part. Donc personne ne décide de la rembourser, et on ne rembourse jamais volontairement ce qui n’existe pas dans les chiffres. Ce qui veut dire qu’elle est toujours remboursée de la même façon : d’un coup, en urgence, un mardi soir, quand une version en fin de vie rencontre une faille critique, ou quand le seul serveur monté à la main tombe. Vous ne payez pas les intérêts au fil de l’eau, vous payez le capital entier au pire moment, avec la direction dans le dos.

C’est là que se joue la vraie différence avec la dette applicative. Une classe illisible vous ralentit. Une infrastructure endettée vous arrête.

En conclusion

Je n’ai pas de méthode miracle, mais tout revient à la même idée : rendre la dette visible, parce que le reste en découle.

Automatisez tout ce qui est un enchaînement de commandes, et n’écrivez que ce qui reste, dans le dépôt, à côté du code. Mettez la dette dans le même tableau que les fonctionnalités, pas dans un “chantier technique” annexe qui sera arbitré en dernier à chaque fois — avec un coût et une conséquence formulés en français, pas en jargon. “Cette base est en fin de support en mars, après quoi nous n’avons plus de correctif de sécurité” est un argument que tout le monde comprend ; “il faut migrer PostgreSQL” n’en est pas un.

Et si vous ne devez retenir qu’une seule mesure, prenez la prochaine arrivée dans l’équipe. Demandez à la personne de noter, pendant trois semaines, chaque fois qu’elle a dû poser une question dont la réponse aurait dû être écrite, et chaque fois qu’elle a dû taper une commande à la main. Ne lui demandez pas de corriger quoi que ce soit, juste de noter. Cette liste, c’est votre dette, à la ligne près, et c’est la seule mesure honnête que je connaisse. Elle est désagréable à lire et elle vaut tous les audits que vous pourriez acheter.

Après, l’arbitrage n’est pas votre métier. Le vôtre, c’est de poser le chiffre sur la table. Une entreprise a parfaitement le droit de décider de vivre avec sa dette technique, ça se défend très bien. Elle n’a simplement pas le droit de l’ignorer.

Parce qu'une dette qu'on ignore ne s'efface pas. Elle attend.