La dette d'intention est la compréhension différée qui s'accumule quand le logiciel est généré plus vite que quiconque ne peut expliquer pourquoi il fonctionne. C'est l'écart grandissant entre ce qu'un système était censé faire, ce qu'il fait réellement, et ce qu'un mainteneur peut encore reconstruire à la demande. Là où la dette technique classique est un nettoyage différé, la dette d'intention est une compréhension différée — et elle échoit la première fois que quelque chose casse et que personne dans la pièce ne peut dire pourquoi le code a été façonné ainsi.
La génération a retiré une contrainte qui faisait silencieusement un travail important : le rythme lent de l'écriture forçait la compréhension comme effet secondaire. Retirez la friction et la compréhension n'arrive plus gratuitement.
- Le code généré arrive propre et passe chaque contrôle, pourtant aucun humain n'en a jamais tenu la forme entière.
- La dette technique vit dans l'artefact ; la dette d'intention vit dans l'écart entre les gens et l'artefact.
- On peut refactoriser un code désordonné, mais pas revenir à une intention jamais enregistrée.
- L'écart de compréhension grandit le plus vite quand le code se lit assez bien pour étouffer le soupçon.
- Couverture, latence et build vert peuvent tenir tandis que la capacité d'expliquer le système se dégrade.
- La rembourser n'est pas un nettoyage ; c'est une re-dérivation capturée comme attente exécutable.
En quoi la dette d'intention diffère-t-elle de la dette technique ?
La dette d'intention désigne le coût de porter un logiciel dont personne ne peut produire le raisonnement sans le re-dériver du comportement. C'est une propriété de la relation entre une équipe et son code, non du code seul. Deux systèmes peuvent être identiques octet pour octet et porter des dettes d'intention différentes, car la dette se mesure à qui peut encore expliquer l'artefact, non à la façon dont il se lit.
La distinction compte parce que les deux dettes se comportent différemment sous intérêts. La dette technique siège dans l'artefact ; la dette d'intention siège dans l'écart entre les gens et l'artefact. On peut rembourser un code désordonné en le refactorisant. On ne peut pas refactoriser son chemin vers une intention jamais enregistrée, seulement la reconstruire — lentement, en lisant, en devinant et en testant contre le comportement.
Une équipe peut livrer une fonctionnalité qui passe chaque contrôle, scale proprement et se lit bien, et porter pourtant une dette d'intention énorme — parce qu'aucun auteur humain n'a jamais tenu toute la forme dans sa tête. L'artefact est propre. La compréhension derrière manque. Cette absence ne s'annonce pas tant qu'une demande de changement n'arrive que le code ne peut résoudre seul.
La dette technique classique était toujours en partie visible. Elle apparaissait comme duplication, comme un enchevêtrement qu'un relecteur pouvait pointer, comme une fonction qui avait clairement dépassé son nom. La dette d'intention se cache mieux, parce que la surface qui signale d'habitude la négligence — le code laid — est exactement celle que la génération polit en premier.
| Propriété | Dette technique classique | Dette d'intention |
|---|---|---|
| Où elle vit | Dans l'artefact | Dans l'écart entre les gens et l'artefact |
| Comment elle se montre | Désordre visible, enchevêtrements, duplication | Invisible jusqu'à un changement ou un défaut |
| Comment elle se rembourse | En refactorisant le code | En re-dérivant et enregistrant le raisonnement |
| Ce que fait un code propre | La réduit | La cache |
Qu'est-ce que l'écart de compréhension ?
L'écart de compréhension est la distance mesurable entre le volume de code dont une équipe est responsable et le volume qu'un de ses membres pourrait dériver, défendre ou modifier en sécurité à partir des premiers principes. Il tend à être invisible pendant le build et indéniable pendant la réparation. Une équipe remarque rarement l'écart tant que les fonctionnalités arrivent à l'heure ; elle le remarque au moment où un défaut tombe dans une région que personne n'a lue.
Ce qui distingue l'écart de la simple unfamiliarité, c'est qu'il ne rétrécit plus avec l'ancienneté comme autrefois. Sur des systèmes écrits à la main, ceux qui avaient bâti une région la comprenaient, et cette compréhension vieillissait lentement. Sur des systèmes générés, autorship et compréhension se séparent à la création, si bien que la séniorité ne garantit plus que quelqu'un tienne le modèle.
- Écart de compréhension
- La distance entre le code qu'une équipe possède et le code que ses membres pourraient reconstruire à partir des premiers principes.
- Compréhension différée
- Raisonnement jamais capturé à la création et qui doit être reconstruit plus tard, souvent sous pression.
- Code tenu versus code hébergé
- Le code qu'une personne peut expliquer à la demande est tenu ; le code qui tourne seulement dans le dépôt de l'équipe n'est qu'hébergé.
Pourquoi la dette d'intention compose-t-elle au lieu de rester plate ?
La dette d'intention compose selon trois axes, et chacun élargit un peu l'écart avant que quiconque ne le remarque. La composition est la part dangereuse. Un seul module inexpliqué est une dette gérable ; le même schéma répété sur un trimestre de livraison devient un système dont le comportement est collectivement possédé et individuellement non tenu.
Le volume est l'axe évident. Les systèmes générés arrivent en unités plus larges — modules entiers, flux entiers — si bien que la surface non lue croît plus vite que la capacité de lecture. Le deuxième est la plausibilité. Le code généré est fluide ; il se lit comme si un auteur soigneux l'avait écrit, ce qui étouffe le soupçon qui déclencherait normalement un regard plus attentif. Le troisième est le renouvellement. Chaque régénération jette le modèle mental bâti par la précédente ; la compréhension se réinitialise tandis que le code continue d'avancer.
Le piège est qu'aucun de ces signaux n'apparaît sur les tableaux de bord qu'une équipe suit d'habitude. La couverture tient. La latence tient. Le build est vert. Ce qui s'érode est la propriété plus discrète : la chance qu'un mainteneur compétent, face à un cas qui échoue à une heure gênante, localise la cause sans re-dériver le système depuis zéro.
Qui maintient le code qu'aucun humain n'a écrit ?
La ligne de faille traverse une question — qui maintient ceci quand ça casse — et un système généré tend à y répondre mal. La maintenance a toujours supposé un auteur quelque part en amont qui savait pourquoi une décision avait été prise. Quand l'auteur est un processus plutôt qu'une personne, cette hypothèse échoue en silence, et l'obligation tombe sur celui qui est d'astreinte.
C'est là que la dette d'intention cesse d'être abstraite. Le coût est payé par une personne précise à un moment précis : le mainteneur face à un code inconnu sous la pression du temps, sans auteur original à consulter et sans justification enregistrée sur laquelle s'appuyer. Son seul recours est la reconstruction, menée au pire moment possible, contre les enjeux les plus élevés.
Le coût se redistribue aussi injustement dans le temps. L'équipe qui génère un système capture la vitesse ; une équipe ultérieure, souvent composée d'autres personnes, hérite de l'écart de compréhension. Parce que le bénéfice et la facture tombent sur des épaules différentes, la dette est facile à contracter et difficile à refuser.
Peut-on mesurer combien d'intention une équipe détient réellement ?
Un test utile est le test d'explication. Choisissez un chemin non trivial dans un système et demandez si quelqu'un de l'équipe peut raconter, sans relire le code, pourquoi il fait ce qu'il fait et ce qui casserait s'il changeait. La fraction des chemins qui passent est une jauge approximative de combien d'intention l'équipe détient vraiment face à ce qu'elle se contente d'héberger.
Notez ce que le test d'explication ne mesure pas. Il ne dit rien de la qualité, du style ou de la correction du moment. Un chemin peut être impeccable et échouer quand même, car réussir exige qu'une personne porte le raisonnement, pas seulement le résultat. C'est précisément la propriété que le code généré tend à sauter.
Exécutez le test périodiquement plutôt qu'une seule fois. La compréhension est périssable ; un chemin qui a passé le trimestre dernier peut échouer celui-ci s'il a été régénéré entre-temps, même si son comportement n'a pas changé. Suivre le taux de réussite dans le temps transforme une dette invisible en un chiffre qu'une équipe peut surveiller à côté de ceux auxquels elle fait déjà confiance.
Qu'est-ce qui rembourse vraiment la dette d'intention ?
Rembourser la dette d'intention n'est pas du refactoring ; c'est de la re-dérivation capturée. L'ordre des opérations la rend traitable, car une compréhension restaurée à la mauvaise altitude s'évapore avant d'être nécessaire, et un effort étalé uniformément sur un système se perd surtout sur des chemins que personne ne touchera.
- Localisez les chemins à plus fort trafic — ceux qu'un mainteneur rencontrera sous pression — et bornez le travail à ceux-là.
- Reconstruisez l'intention derrière chacun en lisant le comportement, non les commentaires, et en énonçant le pourquoi en prose claire à côté du code.
- Encodez l'intention récupérée en assertions et tests nommés, pour que la compréhension survive à la prochaine génération comme attente exécutable plutôt que comme mémoire.
- Marquez les régions encore inexpliquées, pour que l'écart reste visible plutôt que supposé refermé.
- Revenez à un rythme régulier, car chaque régénération peut rouvrir en silence un chemin que vous aviez fermé.
Cet ordre fonctionne parce qu'il convertit la compréhension d'un état privé en artefact durable. La compréhension tenue seulement dans une tête est elle-même une forme de dette — elle part quand la personne part. La compréhension écrite comme test reste, et échoue bruyamment quand une régénération ultérieure viole l'intention qu'elle devait protéger. Le but n'est pas de tout comprendre. C'est de savoir, précisément, ce qui reste incompris.
Où le goulot se déplace ensuite
Ce qui se durcit à partir d'ici est la même chose qui a rendu la génération précieuse : la vitesse découplée de la compréhension. À mesure qu'une plus grande part d'un système arrive déjà écrite, la compétence rare cesse d'être la production et devient la reconstruction — la capacité de se tenir devant un code qu'aucun humain n'a écrit et de rebâtir le raisonnement assez vite pour le changer en sécurité.
Les équipes qui s'en sortent bien tendent à traiter la compréhension comme un actif avec son propre coût de maintenance, budgété à côté du code. Elles mesurent non seulement ce qui est livré mais ce qui peut encore être expliqué. Elles traitent une baisse du taux de réussite au test d'explication comme un signal digne d'agir, comme une ère antérieure traitait une hausse du nombre de défauts.
L'écart de compréhension ne se refermera pas tout seul, car les forces qui l'élargissent sont celles sur lesquelles une équipe s'appuie pour avancer. Le travail à venir est d'apprendre à avancer à cette vitesse tout en gardant la distance entre intention et artefact assez courte pour la franchir quand cela compte. Le champ découvre lentement que le goulot n'a jamais été d'écrire du logiciel. C'était, et demeure, de le comprendre assez bien pour le changer sans peur.
FAQ