Le vrai coût de la dette technique générée par IA

La dette technique a toujours été un arbitrage raisonnable. Vous prenez un raccourci, vous livrez plus tôt, vous payez des intérêts ensuite. L'élément essentiel de cet arrangement est que quelqu'un l'a choisi — et peut vous dire quoi, pourquoi, et ce qu'il faudrait pour revenir en arrière.

La dette générée par IA rompt cet arrangement d'une manière que la plupart des discussions sur les coûts ignorent. Le problème n'est généralement pas que le code soit mauvais. Il est souvent correct. Le problème, c'est que personne n'a pris de décision, donc personne n'a de modèle mental du système.

C'est là que se trouve le coût, et il n'apparaît dans aucun score de qualité de code.

Une dette sans débiteur

Demandez à un ingénieur de parler d'un raccourci qu'il a pris : vous obtenez une réponse en dix secondes. « Ça ne gère qu'une seule devise, on le savait, il y a un ticket. » C'est cette connaissance qui rend la dette normale gérable — on peut la localiser, la chiffrer, la planifier.

Posez la même question sur une base de code générée. Personne ne s'en souvient, parce que personne n'a décidé. Pas de ticket, pas de commentaire, pas de justification. Savoir ce que le système suppose exige de le lire et de le déduire.

Le premier coût réel est donc l'archéologie : chaque modification commence par une enquête qui n'aurait pas été nécessaire si une personne avait écrit le code. Sur une petite base, c'est une heure. Sur une base d'un an, c'est l'essentiel de l'estimation.

Comment cela apparaît sur votre facture

Pas sous la forme d'une ligne « dette ». Cela arrive déguisé en travail ordinaire qui ralentit :

• Les estimations gonflent sans raison visible. Une modification qui semble tenir en deux jours revient à une semaine, parce qu'il faut d'abord établir ce qui va casser.
• De petits changements provoquent des pannes lointaines. La logique dupliquée fait qu'une correction à un endroit laisse le même bug vivant à deux autres.
• L'intégration des nouveaux ralentit. Un développeur normalement productif en une semaine met un mois, faute de quelqu'un à qui demander.
• Tout devient une conversation sur la réécriture. Quand personne ne comprend le système, « tout refaire » commence à paraître moins cher que ce ne l'est.

Le signal : un écart croissant entre la difficulté apparente d'une fonctionnalité et son coût réel. Si cet écart s'est creusé en six mois à équipe constante, vous payez des intérêts.

Le mesurer sans grand audit

Trois questions, auxquelles on peut répondre cette semaine :

1. Combien de temps pour répondre à « où se passe X ? » Prenez un comportement central — l'émission d'un remboursement, par exemple. Si personne ne peut pointer le code en quelques minutes, le système n'est pas compris.
2. Quelle part des modifications provoque une régression ? Au-delà d'environ une correction sur cinq qui casse autre chose, le couplage est réel et coûteux.
3. Combien de temps avant qu'un nouveau développeur livre quelque chose d'utile ? Des semaines au lieu de jours signifie que la connaissance n'est pas dans le code.

Aucune ne demande d'outillage. Toutes trois sont de meilleurs indicateurs que n'importe quel chiffre d'analyse statique.

Le taux d'intérêt varie énormément

C'est là que la plupart des conseils se trompent : ils traitent toute dette comme également urgente. Elle ne l'est pas. L'intérêt dépend de la fréquence à laquelle vous touchez le code.

• Du code modifié chaque semaine, avec de la dette dedans, vous facture chaque semaine.
• Du code que vous n'avez pas ouvert depuis huit mois ne vous facture rien. Laissez-le tranquille.

La question n'est donc jamais « cette base est-elle propre ? » mais quelles parties revenons-nous sans cesse toucher, et que nous coûtent-elles à chaque fois ? Remboursez l'intersection du très fréquenté et du très pénible. Ignorez le reste, aussi désordonné soit-il.

Deux exceptions priment sur cette règle, car leur coût n'est pas proportionnel à la fréquence :

• Les failles de sécurité — évaluées au pire cas, pas à la fréquence. Elles méritent un audit en règle quoi qu'il arrive.
• Les problèmes de modèle de données — ils coûtent plus cher chaque jour où vous ajoutez des lignes, et contrairement à la plupart des dettes, ils s'aggravent même si vous ne touchez pas au code.

Quand rembourser est le mauvais choix

Porter sciemment de la dette est parfois correct :

• Le produit pourrait ne pas survivre. Refactoriser le code d'une fonctionnalité supprimée dans deux mois est du gaspillage pur. Avant l'adéquation produit-marché, brouillon et instructif vaut mieux que propre et lent.
• La zone va être remplacée. On ne rénove pas une pièce qu'on va démolir.
• Cela ne coûte réellement rien. Du code laid qui fonctionne, que personne ne touche, et qui ne pose ni problème de sécurité ni problème de données, n'est pas une priorité. C'est une remarque esthétique.

L'objectif n'a jamais été une base de code élégante. C'est une base qui ne taxe pas le travail que vous faites réellement.

Réécrire ou réparer ?

Le réflexe, après avoir constaté tout cela, est de tout reprendre. C'est généralement l'erreur coûteuse : une réécriture, ce sont des mois sans nouvelle fonctionnalité, et vous reproduirez des bugs déjà corrigés.

Réécrivez quand le modèle de données est fondamentalement inadapté à ce qu'est devenu le produit, ou quand les parcours centraux sont dupliqués avec une logique différente dans chaque copie. Sinon, réparez progressivement, en commençant par ce que vous touchez le plus. Nous détaillons cette décision dans du prototype IA à la production.

La question la plus utile n'est pas « à quel point ce code est-il mauvais ? » mais « qu'avons-nous omis d'écrire ? » L'essentiel de la dette IA est un savoir manquant déguisé en qualité manquante.

Le remède concret passe souvent par de la documentation et des tests plutôt que par une réécriture : consigner ce que le système suppose, pour que la prochaine modification parte d'une compréhension plutôt que d'une fouille. C'est moins cher qu'un refactoring et cela règle une plus grande part du vrai problème.

Si vous voulez une lecture honnête de ce que votre base de code vous coûte — et de ce qui mérite vraiment d'être remboursé — c'est un travail que fait notre agence. Découvrez notre approche des applications propulsées par l'IA, ou envoyez-nous le dépôt.