Comprendre la dette : Pourquoi un code AI propre est plus dangereux qu'un mauvais code
TL;DR :La sortie la plus effrayante de l'IA n'est pas un code bogué. C'est un code propre, correct et bien testé qui résout le mauvais problème.J'appelle cela la compréhension de la dette—l'écart entre ce que l'IA produit et ce que vous comprenez réellement. La dette technique traditionnelle était visible : code désordonné, tests échoués, odeurs évidentes. La compréhension de la dette est invisible : architecture élégante, tests réussis et un système que personne ne peut déboguer lorsqu'il finit par exploser. Après un développement intensif avec Fable et GPT-5.6, j'ai convergé vers un nouveau flux de travail : Objectif → Spécification → Diagramme d'architecture → Exécution de l'agent.La spécification est le nouveau code source. La valeur de l'ingénieur n'est plus dans la saisie. Elle réside dans la capacité à penser clairement pour savoir ce que devrait être construit.
James ici, PDG de Mercury Technology Solutions. Depuis mon bureau à Tokyo — Juillet 2026
J'ai passé la dernière semaine en développement intensif avec deux modèles de pointe : Fable et GPT-5.6. Pas de simples incitations. Des sessions profondes de plusieurs heures à construire de véritables systèmes, à déboguer de réels cas limites, à expédier de vraies fonctionnalités.
La conclusion ? Il ne s'agit pas de savoir quel modèle est "meilleur". Les deux sont extraordinaires. Les deux sont terrifiants. Et les deux ont révélé quelque chose que je n'avais pas pleinement compris jusqu'à cette semaine : la nature de l'erreur de l'IA a fondamentalement changé.
L'Ancienne Erreur vs. La Nouvelle Erreur
À l'ère de GPT-3.5 et des débuts de GPT-4, les erreurs de l'IA étaient évidentes. Le code était désordonné. La logique était défaillante. Les tests échouaient. Vous lisiez la sortie et saviez, en quelques secondes, que quelque chose n'allait pas. L'IA avait généré des spaghettis, et vous étiez l'humain capable de voir l'enchevêtrement.
Votre rôle était simple : juger la sortie, rejeter les déchets, demander une réécriture. Humain en tant qu'arbitre. Humain en tant que porte de qualité. L'IA produisait ; vous curiez.
Cette époque est révolue.
Avec Fable et GPT-5.6, le code est propre. La logique est solide. Les tests passent. La documentation est présente. L'architecture suit des schémas que vous attendez d'un ingénieur senior. Tout semble... correct.
Mais c'est faux. Fondamentalement, directionnellement faux. Le système fait exactement ce qui a été demandé, mais ce qui a été demandé ne résout pas le véritable problème. L'IA n'a pas mal compris la syntaxe. Elle n'a pas halluciné une API. Elle a suivi vos instructions à la lettre—et vos instructions étaient subtilement, catastrophiquement désalignées avec la réalité.
Les anciennes erreurs étaient vulgaires. Les nouvelles erreurs sont élégantes. Les anciennes erreurs étaient visibles. Les nouvelles erreurs sont invisibles. Les anciennes erreurs étaient des bugs. Les nouvelles erreurs sont du design.
C'est ce que j'appelle la dette de compréhension.
Dette technique vs. Dette de compréhension
La dette technique est un concept familier. Vous écrivez du code rapide et sale pour expédier rapidement. Le code fonctionne mais est difficile à maintenir. Un jour, vous ferez une refonte. Tout le monde sait où sont enterrés les corps parce que le code sent mauvais.
Comprendre la dette est différent. Le code ne sent pas. Ça sent super. Il a été nettoyé, formaté et documenté. Mais voici la distinction critique : personne ne sait pourquoi il a été conçu de cette manière.
Ni l'IA qui l'a écrit—l'IA n'a pas de mémoire d'intention au-delà du contexte de la demande. Ni l'humain qui l'a commandé—parce que l'humain ne l'a pas écrit, et l'écart entre "J'ai décrit ce que je voulais" et "Je comprends ce qui a été construit" s'élargit d'heure en heure. Ni l'ingénieur qui rejoint le projet six mois plus tard—parce qu'il n'y a pas de fil de raisonnement, pas d'historique de décisions, pas de chemin évolutif montrant pourquoi cette architecture a été choisie plutôt que d'autres.
Quand ça casse—et ça va casser, parce que tous les systèmes se cassent—personne ne sait par où commencer. Le code est propre, donc il n'y a pas de point d'infection évident. La logique est solide, donc il n'y a pas de fausse idée claire. Le problème est plus profond : le design lui-même était subtilement erroné pour un contexte qui n'était pas entièrement compris au moment de la génération.
Et voici la partie brutale : La vitesse de production de l'IA dépasse désormais largement la vitesse de compréhension humaine.Cet écart n'est pas statique. Il s'élargit chaque jour. Plus vous laissez l'IA construire, moins vous comprenez ce que vous possédez. Moins vous comprenez, plus votre système devient fragile. Plus il devient fragile, plus vous avez besoin de l'IA pour le réparer—accélérant la spirale de la dette.
C'est le changement de modèle en V que j'ai présenté à l'INCOSE le mois dernier. Le modèle en V traditionnel supposait que la compréhension était un sous-produit de l'implémentation. Vous concevez, vous codez, vous testez, et à travers ce processus, vous apprenez le système. Le code était l'artefact, mais la compréhension était l'effet secondaire.
L'IA brise cette hypothèse. Lorsque l'IA écrit le code, la compréhension n'est plus un effet secondaire. Elle doit être un entrée explicite. Si vous ne construisez pas délibérément votre compréhension avant que l'IA ne construise, vous ne l'obtenez pas par la suite. Le code existe sans la compréhension. Et c'est une dette de compréhension.
Le Nouveau Flux de Travail : Objectif → Spécification → Architecture → Exécution
Comment combattez-vous cela ? J'ai convergé vers un flux de travail en quatre phases après des dizaines d'itérations avec Fable et GPT-5.6. Sauter une phase, et la dette de compréhension s'accumule.
Phase 1 : Définir l'Objectif
Quel problème résolvez-vous ? Quel est le critère de succès ? Plus important encore : qu'est-ce qui ne peut absolument pas se briser ?Quels sont les invariants, les contraintes, les éléments non négociables ?
La plupart des prompts d'IA passent cela sous silence. Ils sautent à "construisez-moi une fonctionnalité". Mais sans l'objectif, l'IA n'a pas d'étoile polaire. Elle va optimiser pour la justesse locale tout en dérivant de l'intention globale. Vous avez demandé un cheval plus rapide ; elle a construit un cheval magnifique. Vous aviez besoin d'une voiture.
Phase 2 : Rédiger le cahier des charges
C'est la phase la plus importante. Le cahier des charges n'est pas une liste de souhaits. C'est un contrat. Il définit ce que le système fait, ce qu'il ne fait pas, à quoi ressemble le travail terminé et quelles sont les limites.
Je considère maintenant le cahier des charges comme le nouveau code source.Pas au sens métaphorique. Littéralement. Le cahier des charges est l'artefact qui entre en premier dans le contrôle de version. Le cahier des charges est ce qui est examiné. Le cahier des charges est ce sur quoi l'équipe débat. Le cahier des charges est la seule source de vérité à laquelle se réfèrent à la fois les humains et l'IA.
Sans spécification, donner des instructions à un agent IA revient à dire "va vers le nord." L'agent courra vers le nord aussi vite que possible. Plus il court, plus il s'écarte de votre destination réelle—car vous ne lui avez jamais donné d'adresse, seulement une direction.
La spécification est l'adresse. Ce sont les coordonnées GPS. Elle indique à l'IA non seulement quoi construire, mais dans quel contexte la chose construite doit opérer.
Phase 3 : Diagramme d'architecture
Avant qu'une seule ligne de code ne soit générée, je fais produire à l'IA un diagramme d'architecture basé sur la spécification. Pas un croquis vague. Un diagramme de composants détaillé montrant les flux de données, les interfaces, les dépendances et les points de décision.
Pourquoi ? Parce que un diagramme est le moyen le moins cher de vérifier l'alignement directionnel.
Vous pouvez examiner un diagramme en quelques minutes. Vous pouvez repérer une mauvaise abstraction en quelques secondes. Vous pouvez voir que l'IA a mal compris la relation entre deux domaines avant qu'elle ne passe une heure à générer du code qui met en œuvre ce malentendu. Le diagramme est le dernier point de contrôle humain avant que l'IA n'accélère au-delà de la vitesse de compréhension humaine.
C'est le sommet du V. La partie la plus large. Le point où la compréhension humaine doit être maximisée avant que l'implémentation ne descende.
Phase 4 : Exécution de l'agent
Ce n'est qu'après que l'objectif est clair, que la spécification est écrite et que l'architecture est examinée que je laisse l'agent IA exécuter. Et même alors, je structure l'exécution en incréments limités—assez petits pour que je puisse examiner la sortie par rapport à la spécification avant que le prochain incrément ne commence.
Ce n'est pas lent. C'est durable. L'alternative—laisser l'IA générer des milliers de lignes de code propre, élégant et erroné—est ce qui crée la dette de compréhension qui paralyse les équipes pendant des semaines.
La nouvelle valeur de l'ingénieur
Voici le recadrage qui compte : la valeur d'un ingénieur ne réside plus dans l'écriture d'un bon code. Elle réside dans la capacité à penser clairement pour savoir ce que devrait faire un bon code.
L'IA peut écrire du code. Elle peut écrire un meilleur code, plus rapidement, que 95 % des ingénieurs. Ce que l'IA ne peut pas faire, c'est décider quel code devrait exister. Elle ne peut pas tenir compte du contexte commercial. Elle ne peut pas évaluer les compromis qui ne figurent pas dans les données d'entraînement. Elle ne peut pas demander "devrions-nous même construire cela ?"—car la question suppose un niveau de compréhension stratégique qui se situe en dehors de la base de code.
Dans l'ancien monde, la compétence en codage était le goulot d'étranglement. Les ingénieurs capables d'écrire un code élégant et efficace étaient la ressource rare. Dans le nouveau monde, la clarté de pensée est le goulot d'étranglement.Les ingénieurs capables de définir des objectifs clairement, d'écrire des spécifications précisément et de revoir des diagrammes d'architecture de manière critique sont la ressource rare. Tout le reste peut être externalisé.
C'est le changement du modèle en V dont j'ai parlé à INCOSE. Le côté gauche du V—exigences, spécifications, architecture—est devenu le chemin critique. Le côté droit—mise en œuvre, intégration, test—est de plus en plus automatisé. Le centre de gravité a changé de "comment le construisons-nous ?" à "comment savons-nous quoi construire ?"
Et "savoir quoi construire" n'est pas une compétence technique. C'est une compétence de synthèse. Cela nécessite des connaissances dans le domaine, un contexte commercial, un jugement stratégique et la capacité de communiquer des contraintes d'une manière qu'une IA peut exécuter fidèlement.
L'asymétrie de la vitesse
Le dernier danger à intégrer : L'IA produit à la vitesse de la machine. Les humains comprennent à la vitesse humaine. Ces vitesses divergent.
Chaque jour, les modèles de pointe deviennent plus rapides et plus capables. Chaque jour, le volume de production qu'un seul ingénieur peut commander augmente. Mais la compréhension humaine ne se développe pas. Lire du code, comprendre l'architecture, tracer les flux de données—ce sont des tâches cognitivement coûteuses qui ne bénéficient pas de la loi de Moore.
Le résultat est une asymétrie : l'IA peut générer un système en une heure que l'humain mettrait une semaine à comprendre complètement. Et au moment où l'humain l'a compris, l'IA a déjà généré trois itérations supplémentaires. L'humain est toujours en retard. L'humain est toujours en dette.
Le seul moyen de gérer cette asymétrie est de privilégier la compréhension dès le départ. Investir du temps humain au début du processus—objectifs, spécifications, architecture—afin que l'exécution de l'IA soit limitée par la compréhension humaine. Vous ne pouvez pas rattraper l'IA après coup. Vous devez contraindre l'IA avant le fait.
La spécification est la contrainte. La spécification est la compréhension. La spécification est le nouveau code source.
Le Bilan
Je suis revenu de ma semaine avec Fable et GPT-5.6 avec une conviction forte : le goulot d'étranglement dans le développement piloté par l'IA n'est plus l'IA. C'est la capacité de l'humain à spécifier, examiner et comprendre. Le danger n'est plus que l'IA écrive un mauvais code. C'est que l'IA écrive un excellent code pour le mauvais problème—et personne ne le saura avant qu'il ne soit trop tard.
Comprendre la dette est la nouvelle dette technique. Elle est plus difficile à détecter, plus difficile à mesurer et plus difficile à rembourser. Et elle s'accumule silencieusement, dans l'écart entre ce que vous avez demandé et ce dont vous aviez réellement besoin.
La solution n'est pas d'utiliser moins l'IA. C'est de réfléchir davantage avant d'utiliser l'IA. D'écrire le cahier des charges. De dessiner le diagramme. De connaître l'objectif. D'accepter qu'à l'ère du code généré par l'IA, l'artisanat de l'ingénieur n'est pas de taper—c'est la clarté.
Mercury Technology Solutions: Accélérer la digitalité.
Publié par Mercury Technology Solutions | mtsoln.com | Architecture de croissance systémique
