Dette technique du vibe coding : pourquoi les apps IA deviennent difficiles à changer

En bref : Le goulot d’étranglement du code généré par l’IA, ce n’est pas la vitesse d’écriture — c’est que six mois plus tard, plus personne ne sait le lire et il n’y a aucun auteur à qui demander. Faites générer des métadonnées à l’IA plutôt que du code libre, et la dette devient plus visible, plus petite et plus facile à revoir.

L’histoire commence au septième mois.

Mingxiang est une chaîne de distribution, plusieurs centaines de points de vente. L’an dernier, son équipe finance (une cinquantaine de personnes) en a eu assez d’attendre les créneaux de l’IT et a monté un système de notes de frais « d’une seule phrase » avec l’IA. Formulaires, validations, raccordement au grand livre : tout tournait en deux jours, applaudissements généraux. Et pendant plus de six mois, tout s’est bien passé.

Au septième mois, une règle fiscale a changé : le taux de déductibilité d’une certaine catégorie de factures a été ajusté, et la logique de remboursement devait suivre. Une broutille.

Puis l’équipe a découvert que personne n’osait y toucher. Derrière cette « seule phrase » se cachaient plus de douze mille lignes de code généré par l’IA, qu’aucune personne n’avait jamais lues en entier. Dans quels fichiers la logique de déductibilité était-elle disséminée ? Une modification allait-elle se répercuter sur les validations et la réconciliation de fin de mois ? Personne ne savait le dire. Plus embarrassant encore : même l’IA qui avait écrit ce code était impuissante. Elle est sans état ; les jugements, les arbitrages, les raisons d’avoir codé ainsi qui occupaient son « esprit » lors de cette génération n’ont laissé aucune trace. Vous ne pouvez que réinjecter les douze mille lignes dans une nouvelle session et lui faire « deviner » qui elle était à l’époque.

Cette broutille a finalement pris trois semaines. Et le vrai coût ne s’arrête pas à trois semaines : lors de la revue avant mise en production, quelqu’un a découvert que l’IA avait, au passage, modifié une logique de réconciliation sans rapport avec la déductibilité — il s’en est fallu de peu qu’un lot de remboursements ne fasse remonter des montants erronés dans le grand livre. Cette fois, on l’a intercepté par chance, mais cela illustre une chose : plus personne, dans ce système, ne peut garantir que « modifier A ne touchera pas B ».

C’est cela que beaucoup ont baptisé d’avance « l’année de la dette technique » pour 2026, vu de l’intérieur d’une équipe ordinaire.

Une dette particulière : contractée, mais sans créancier identifiable

La dette technique n’est pas un mot nouveau. Mais le code généré par l’IA contracte une dette qui n’existait pas auparavant.

Le code écrit par des humains peut aussi être mauvais, aussi être sans documentation. Mais au moins l’auteur est encore là — vous pouvez convoquer celui qui l’a écrit et lui demander « pourquoi avoir traité ça comme ça à l’époque ». Aussi mauvais soit-il, il y a toujours derrière le code un cerveau humain capable de l’expliquer.

Le code généré par l’IA retire aussi ce dernier filet. Son « auteur » est un modèle sans état, qui n’existe plus à l’instant même où la génération s’achève. Il n’a pas conservé son raisonnement, parce qu’il n’a tout simplement pas de « processus » à conserver. Vous vous retrouvez donc avec un magma qui tourne, mais que personne ne peut expliquer, et que personne ne peut interroger. Les douze mille lignes de Mingxiang sont exactement cette dette — elle n’est pas due à la qualité du code, mais au fait que « plus personne ne le comprend vraiment ».

Les chiffres précis changent selon les études, mais le mécanisme est déjà visible dans beaucoup d’équipes : l’IA augmente le volume de code produit, tandis que la capacité humaine de le lire, de le relier au métier et d’en assumer les effets ne progresse pas au même rythme. La vitesse est réelle, la dette aussi — sauf que cette dette ne se solde pas le jour de la livraison : elle frappe à votre porte au septième mois.

Mais la génération de code ne progresse-t-elle pas à toute vitesse ?

Il faut ici prendre au sérieux une objection, sinon ce serait injuste : les modèles ne cessent de se renforcer, ils lisent du code de plus en plus long, il y a désormais la revue de code par IA, les pipelines « auto-réparateurs » — d’ici un an, ces dettes ne seront-elles pas automatiquement remboursées par des outils plus puissants ?

Cette attente a sa logique, mais elle se trompe de goulot d’étranglement.

Les progrès de la génération de code résolvent l’« écrire plus vite ». Or le problème de Mingxiang n’a jamais été d’écrire trop lentement — au contraire, c’était d’écrire trop vite : un système en deux jours, puis des modifications arrivant plus vite que les personnes ne pouvaient les comprendre. Le goulot est du côté « comprendre et assumer », et il ne s’améliore pas linéairement avec la capacité de génération. Un modèle plus puissant génère plus de code, plus vite — donc peut aussi accumuler plus vite des implémentations que personne n’a lues. La revue par IA peut aider à passer un coup de balai, mais « ce que cette logique métier devrait être », elle ne peut en donner de réponse certaine, car le juste et le faux n’existent que dans le contexte métier, pas dans le code.

Autrement dit : miser sur « un modèle un peu plus puissant », c’est soigner un frein défaillant en appuyant sur l’accélérateur.

Les intérêts composés : à chaque modification, on comprend un peu moins

Pourquoi le septième mois, et pas le premier ? Parce que cette dette porte des intérêts composés.

À la première modification, l’IA, sans avoir compris l’ancien code, « ajoute un bloc à côté » ; à la deuxième, elle fait face à « l’ancien code + le nouveau code qu’elle n’a pas compris la dernière fois », et ajoute donc encore un bloc. Chaque couche s’empile sur une couche précédente que personne ne comprend, et le coût de compréhension croît exponentiellement. La courbe de risque n’est donc pas une droite qui monte doucement, mais une courbe exponentielle : calme au début, puis brutalement abrupte — assez calme pour vous faire croire que tout va bien, jusqu’à ce qu’une modification des plus banales y mette le feu.

Voici un auto-diagnostic simple, pour voir d’avance à quel segment de la courbe vous vous trouvez. Sur les cinq points ci-dessous, si trois s’appliquent, vous êtes déjà en train de contracter une dette technique IA :

1. Il y a dans le système un bloc de code que personne dans l’équipe ne peut expliquer « pourquoi c’est écrit ainsi ».
2. Pour modifier un point, le premier réflexe est « est-ce que ça va casser ailleurs » plutôt que de modifier directement.
3. Le nombre d’alertes de sécurité augmente chaque mois, et provient majoritairement du nouveau code.
4. À chaque modification, il faut réinjecter tout le bloc de code dans l’IA pour qu’elle le « relise ».
5. Les PR sont de plus en plus grosses, au point que personne ne les relit vraiment ligne à ligne : on se contente de regarder « les tests passent-ils ».

Cette dette, qui la paie au final

La courbe des intérêts composés se transforme en fin de compte en une facture concrète, payée à quatre :

• Le métier paie en vitesse : cette « petite modification » de Mingxiang a pris trois semaines. Quand chaque modification fait craindre de casser ailleurs, la vitesse d’itération s’effondre à vue d’œil — vous croyiez que l’IA vous rendait plus rapide, six mois plus tard vous l’êtes moins.
• La gestion des risques paie en incidents : ce calcul erroné qui a failli remonter au grand livre a été intercepté, mais pas forcément le suivant. Plus le volume de code non relu augmente, plus les alertes et les angles morts s’accumulent.
• L’équipe paie en hommes : personne ne veut maintenir durablement un magma qu’il ne comprend pas et qui tremble dès qu’on le touche. Quand celui qui le connaît le mieux s’en va, le système devient une boîte noire totale — et le code généré par IA n’a de toute façon jamais eu de « personne qui le connaît le mieux ».
• L’entreprise paie en réécriture : passé un certain point, la dette de compréhension rend « modifier » plus cher et plus risqué que « réécrire », et le projet est rasé pour être recommencé. Le peu de temps économisé sur la première version est remboursé, capital et intérêts.

Aucune de ces quatre factures n’apparaît dans l’enthousiasme du « système monté en deux jours ». Elles sont toutes inscrites au compte d’après le septième mois.

Disons-le franchement : passer aux métadonnées n’est pas sans coût

Il faut s’arrêter ici honnêtement, sinon cela redevient une vente de potion miracle.

Faire générer à l’IA des définitions plutôt que du code implique des arbitrages. Les métadonnées déclaratives couvrent les 90 % qui reviennent sans cesse dans les applications d’entreprise — objets, champs, relations, vues, permissions, processus, validations. La contrôlabilité qu’elles offrent a pour prix l’abandon d’une part de la liberté de « coder exactement comme on veut ». Si ce que vous devez bâtir est un tout nouveau moteur de collaboration en temps réel, un algorithme graphique inédit, alors il vous faut bel et bien du vrai code ; les métadonnées ne vous aideront pas, et les y forcer ferait plus de mal que de bien — ObjectStack résout les systèmes métier que l’entreprise reconstruit encore et encore, pas le prochain Figma.

Et une autre vérité : choisir un runtime de métadonnées, c’est confier une partie de l’implémentation à ce runtime ; vous misez sur sa qualité et sa disponibilité à long terme. C’est une dépendance bien réelle — sauf que, comparé à « miser sur douze mille lignes de code que personne ne lit », miser sur un runtime audité en boucle, versionné et migrable est un bien meilleur pari.

Remplacer ce que l’on génère : non pas l’implémentation, mais la définition

Retour au système de notes de frais de Mingxiang. Pour le même besoin, si l’IA avait généré non pas douze mille lignes d’implémentation, mais une définition de ce genre :

export const ExpenseReport = ObjectSchema.create({
  name: 'fin_expense_report',
  label: 'Note de frais',
  fields: {
    amount: Field.currency({ label: 'Montant', min: 0 }),
    invoice_type: Field.select({ label: 'Type de facture', options: ['Facture simple', 'Facture spéciale'] }),
    deductible_rate: Field.percent({ label: 'Taux de déductibilité' }),
  },
});

Ces quelques dizaines de lignes ne sont pas « une interface qu’il reste à implémenter », elles sont le système même. Le runtime (ObjectOS) la lit et en dérive automatiquement les tables de données, les API, l’interface, ainsi que les outils gouvernés appelables par l’agent ; les permissions et les flux de validation sont eux aussi des déclarations rattachées à elle, pas des jugements écrits à la main.

Alors, à quoi ressemble ce changement de règle fiscale du septième mois ? Plus une fouille archéologique, mais une modification compréhensible d’une ligne :

- deductible_rate: Field.percent({ label: 'Taux de déductibilité' }),
+ deductible_rate: Field.percent({ label: 'Taux de déductibilité', defaultValue: 70 }),
+ // les factures spéciales sont déductibles à 70 % selon la nouvelle règle ; la règle descend dans la définition, validation et réconciliation suivent automatiquement

C’est un diff revisible en cinq minutes et réversible d’un clic, et non une PR de quatre cents lignes que personne n’ose « fusionner » ; et il n’y aura pas non plus de « réconciliation cassée au passage », car la logique de réconciliation n’est pas dans cette définition : elle n’y a tout simplement pas accès. La différence n’est pas dans ce qui est plus « avancé », mais dans qui, six mois plus tard, le comprendra encore, pourra encore le modifier, et pourra remonter à la cause en cas d’erreur.

Pourquoi le mécanisme des intérêts composés est coupé

Une fois passé aux définitions, pourquoi cette courbe peut-elle s’aplatir ? Trois points, qui visent tous droit l’histoire de Mingxiang :

1. Plus d’« implémentation que personne n’a lue ». L’implémentation appartient au même runtime, audité en boucle et partagé par toutes les applications, et non générée en un exemplaire par application. Dans votre application, il ne reste que des définitions — et les définitions sont faites pour être lues par des humains.
2. Plus de « personne à interroger ». La définition est déclarative, elle affiche son intention sur son visage — ce qu’est deductible_rate, qui en a la charge, quels processus une modification affecte : tout est limpide, sans avoir à interroger cette session de génération disparue depuis longtemps.
3. La surface de vulnérabilité s’effondre. Ces 45 % qui tombent dans l’OWASP proviennent en grande majorité de l’authentification, de la concaténation de requêtes, du traitement des entrées écrits à la main. Une fois tout cela pris en charge par le runtime unifié, les catégories de vulnérabilités que la couche applicative peut introduire diminuent de plus de moitié.

Conclusion

2026 sera l’année de la dette technique, non parce que faire écrire du code par l’IA est une erreur, mais parce que trop d’équipes ont pris un outil de « génération rapide de prototype » pour une méthode de « construction de système durable ». Un prototype peut bien être un tas de code que personne ne lit ; un système utilisé pendant trois ans ne le devrait pas.

La prochaine fois que vous voudrez monter avec l’IA un système métier vraiment destiné à durer, ne demandez pas d’abord « à quelle vitesse il génère », mais posez la question que Mingxiang n’a affrontée que de force au septième mois : quand la règle changera dans six mois, oserai-je encore le modifier, pourrai-je encore remonter à la cause ? Faire générer à l’IA des définitions plutôt que du code est aujourd’hui la seule voie pour que cette réponse soit « oui ».

npm i -g @objectstack/cli && os start

Définissez un objet, modifiez un champ une fois, et regardez à quel point cette modification est propre dans le git diff — voilà une dette qui ne porte pas d’intérêts composés.