Toute application contient des raccourcis. Un écran copié plutôt que factorisé, un test remis à plus tard, une règle écrite pour la démo. Chacun fait gagner du temps sur le moment. La dette technique, c'est la somme de ces gains de temps qu'il faudra rendre, avec intérêts, chaque fois que l'on voudra modifier le logiciel.
D'où vient l'expression
Ward Cunningham, développeur et futur coauteur du Manifeste agile, a proposé la métaphore en 1992 pour expliquer à sa direction pourquoi un logiciel financier devait être retravaillé. Il écrivait que livrer du code pour la première fois revient à s'endetter, et que chaque minute passée sur du code pas tout à fait juste compte comme un intérêt sur cette dette.
La métaphore a tenu parce qu'elle parle aux décideurs. Une dette n'est ni bonne ni mauvaise. Elle finance une avance. Elle devient un problème quand ses intérêts absorbent la capacité à avancer.
À quoi ressemble la dette dans une app construite avec l'IA
Le vibe coding produit de la dette d'une façon particulière. Chaque demande à l'outil ajoute ou modifie du code pour satisfaire la demande du moment, sans toujours tenir compte de l'ensemble. Après quelques centaines d'itérations, on retrouve souvent les mêmes signes :
- Des composants dupliqués avec de petites variations, qu'il faut corriger à plusieurs endroits
- Une logique métier éparpillée entre l'interface, la base et des fonctions serveur, sans endroit unique où lire une règle
- Peu ou pas de tests automatisés, donc aucune alerte quand une modification casse autre chose
- Du code mort : des fichiers et des fonctions qui ne servent plus mais que personne n'ose supprimer
- Des dépendances ajoutées puis oubliées, parfois en double ou obsolètes
- Aucune documentation de l'architecture ou des choix faits
Le symptôme le plus parlant est connu de beaucoup de porteurs de projet : chaque nouvelle demande à l'IA casse quelque chose qui marchait. C'est le moment où les intérêts de la dette dépassent le gain de vitesse.
Comment la mesurer
La dette technique se mesure par des signes observables dans le dépôt :
- La structure : les fichiers sont-ils rangés par responsabilité ? Une règle métier se trouve-t-elle à un seul endroit ?
- La lisibilité : un développeur extérieur comprend-il un module sans l'expliquer ligne par ligne ?
- Les vérifications : existe-t-il des tests, un contrôle de typage, une analyse automatique à chaque modification ?
- La reprise : le projet démarre-t-il sur un autre poste avec une documentation simple ?
- L'évolution : les dépendances sont-elles à jour et la base de données versionnée ?
C'est exactement la grille de l'Indice de reprise de vibebusters : dix critères notés 0, 1 ou 2, regroupés en cinq axes, pour un total sur 20. Chaque note s'appuie sur une preuve dans le code, ce qui permet de suivre l'évolution d'un dépôt dans le temps.
Un exemple concret
Une plateforme de formation construite avec Lovable compte quarante écrans. Le fondateur demande l'ajout d'un abonnement annuel. L'outil modifie le tarif à trois endroits, mais le calcul de la facture existe en cinq exemplaires légèrement différents. Deux sont oubliés. Des clients reçoivent une facture mensuelle pour un abonnement annuel.
L'analyse montre que la dette se concentre dans quatre zones : facturation, droits d'accès, notifications et tableaux de bord. Rembourser les deux premières, avec des tests sur les calculs, prend deux semaines. Les deux autres peuvent attendre. Le projet repart sans reconstruction.
Rembourser, et dans quel ordre
La dette ne se rembourse pas en bloc. Une priorité raisonnable :
- D'abord ce qui touche la sécurité et les données : accès, secrets, sauvegardes
- Ensuite ce qui freine les prochaines évolutions du produit
- Puis ce qui coûte à chaque modification : duplications, absence de tests sur les calculs critiques
- Enfin le confort : nommage, rangement, documentation détaillée
Notre article sur le coût d'une mise en production donne des ordres de grandeur. Lorsque la dette est trop diffuse pour être remboursée par morceaux, la Reconstruction par étapes reprend les fonctionnalités et les données utiles sur une base saine.
Ce qu'il faut retenir
La dette technique est un outil de financement du produit. Elle permet de lancer vite, et le vibe coding la rend particulièrement rentable au départ. Elle demande ensuite d'être mesurée et remboursée par priorité, avant que ses intérêts ne bloquent l'évolution. Le Scan et l'Indice de reprise donnent cette mesure, preuves à l'appui.