Dette cognitive : la facture cachée du code généré par l'IA
L'IA génère vite, le code marche, rien ne clignote. La dette cognitive arrive plus tard : le jour où il faut faire évoluer un système que personne n'a vraiment compris.
- Dette cognitive
- Agents IA
- Qualité logicielle
- Organisation des équipes
En bref. La dette cognitive désigne l’écart qui se creuse entre ce que fait un logiciel et ce qu’en comprend l’équipe qui le maintient, parce que l’IA génère du code plus vite que les humains ne l’assimilent. Contrairement à la dette technique, elle ne se voit pas dans le code : elle vit dans les têtes, et n’apparaît qu’au jour de l’incident. Le Technology Radar de Thoughtworks (avril 2026) en fait un sujet central et prescrit un remède sans outil miracle : revenir aux fondamentaux de l’ingénierie et protéger les compétences que l’IA semble rendre inutiles, relire, diagnostiquer, maintenir.
Sans prérequis technique. Le texte principal se lit de bout en bout sans bagage particulier ; les encadrés « Pour aller plus loin » ajoutent le vocabulaire précis pour qui veut creuser.
Imaginez une carte de crédit invisible. Chaque fois que l’IA écrit du code à votre place, elle vous prête quelque chose de précieux : de la vitesse. Vous livrez plus vite, aujourd’hui. Ce prêt se rembourse pourtant plus tard, en compréhension, et avec intérêts. Comme pour toute carte de crédit, le relevé n’arrive pas le jour de l’achat. Il arrive le jour où il faut faire évoluer, réparer ou reprendre en main un système que la machine a écrit plus vite que votre équipe n’a eu le temps de le comprendre.
Ce prêt caché a un nom, que le Technology Radar Volume 34 de Thoughtworks a placé au cœur de son édition d’avril 2026 : la dette cognitive.
Qu’est-ce que la dette cognitive ?
C’est l’écart entre ce que le logiciel fait et ce que les humains en comprennent. Pendant deux ans, on a jugé l’IA sur ce qu’elle produit : des lignes de code, des tickets fermés, des demandes livrées. Personne ne comptait ce qu’elle use en silence : la compréhension.
Dette cognitive : l’écart qui se creuse entre ce que le logiciel fait et ce que les humains en comprennent, parce que l’IA génère du code plus vite que le cerveau ne l’assimile.
Le symptôme est déroutant : le code marche, les tests sont verts, tout a l’air sain. Et pourtant, personne dans l’équipe ne saurait expliquer avec certitude pourquoi le système se comporte comme il le fait. Rien ne clignote, et c’est précisément le piège.
Quelle différence entre dette cognitive et dette technique ?
La dette technique est un choix assumé, visible dans le code ; la dette cognitive est un effet de bord de la vitesse, que personne n’a décidé et qui ne se lit nulle part. Les confondre conduit à chercher le problème au mauvais endroit.
| Dette technique | Dette cognitive | |
|---|---|---|
| D’où elle vient | Un choix assumé (« on livre, on nettoiera après ») | Un effet de bord de la vitesse : personne ne l’a décidée |
| Se voit-elle ? | Oui : TODO, tickets, alertes | Non : le code est propre, testé… et pourtant incompris |
| Où elle vit | Dans le code | Dans la tête de l’équipe, ou dans son absence |
| Ce qu’elle coûte | Du refactoring plus tard | La capacité à diagnostiquer, faire évoluer, reprendre en main |
La dette technique, on peut la lire dans le code. La dette cognitive, non : elle se définit par ce qui n’est pas dans une tête humaine. Voilà pourquoi elle est si dangereuse. Elle ne déclenche aucune alarme, jusqu’au jour où un incident force quelqu’un à comprendre un système que plus personne ne comprend.
Le défi est-il technologique ou humain ?
Humain. Pour Thoughtworks, les outils d’IA sont mûrs ; ce qui ne l’est pas encore, c’est la discipline d’ingénierie qui les entoure. Le remède ne s’achète donc pas : il se cultive, et il demande un vrai travail d’ingénierie plutôt qu’un abonnement de plus.
Le message central du Radar Vol. 34 tient dans une formule de Rachel Laycock, directrice technique de Thoughtworks : le vrai défi n’est plus de faire progresser les machines, mais la discipline humaine qui les entoure.
Pour aller plus loin : la citation de Laycock et les quatre thèmes du Radar Vol. 34 La phrase exacte : « The inflection point we’re at isn’t so much about technology, it’s about technique. » (Rachel Laycock, CTO de Thoughtworks) Le Volume 34 s’organise en quatre thèmes, et trois sur quatre parlent de contenir l’IA plutôt que de l’accélérer :
- Retaining principles, relinquishing patterns : garder les principes d’ingénierie (zero trust, métriques DORA, testabilité) même quand les patterns d’implémentation changent.
- Securing permission-hungry agents : les agents réclament un accès maximal, d’où zero trust, moindre privilège et défense en profondeur.
- Putting coding agents on a leash : deux contrôles, cadrer en amont (Agent Skills, specs) et vérifier en aval (mutation testing).
- The challenge of evaluating technology in an agentic world : la profusion de nouveaux termes, lancés avant que leur sens ne se stabilise, brouille l’évaluation des outils. Signal concret : Claude Code est passé dans l’anneau Adopt du Vol. 34, car les équipes s’en servent au quotidien en production. L’outil est mûr ; c’est la technique autour qui ne l’est pas.
Pourquoi ajouter des développeurs ne résorbe-t-il pas la dette cognitive ?
Parce qu’on ne peut pas répartir une compréhension que personne ne détient. La compréhension perdue ne se distribue pas : elle se reconstruit, par une lecture patiente du système. C’est ce qui distingue la dette cognitive d’un risque plus familier, le facteur d’autobus.
L’analogie qui suit est personnelle : le Radar ne la formule pas ainsi.
Vous connaissez peut-être le facteur d’autobus : le nombre de personnes qui devraient être renversées par un bus pour qu’un projet s’arrête. Il mesure un risque individuel, celui d’une personne qui détient seule un savoir critique. Le remède est simple : répartir ce savoir entre plusieurs têtes (documentation, revue à deux, transmission).
La dette cognitive pose le même risque, mais à l’échelle collective, et elle résiste au remède habituel. Même avec toute l’équipe présente, personne ne comprend plus vraiment un système généré trop vite. Le facteur d’autobus disait qui manquerait ; la dette cognitive dit ce que plus personne ne possède. D’où un remède qui n’est pas un outil, mais un retour aux fondamentaux.
Comment réduire la dette cognitive ?
En revenant aux fondamentaux de l’ingénierie. On pourrait attendre du Radar qu’il recommande un outil « anti-dette cognitive » ; il fait l’inverse. Son mot d’ordre : on abandonne des façons de faire, on ne lâche jamais les principes.
| Fondamental | En clair |
|---|---|
| Zero trust | Ne jamais croire le code généré sur parole : on vérifie tout, agent compris. |
| Mesurer (DORA) | Se fier à des chiffres, pas à une impression d’aller plus vite. |
| Testabilité | Un système qu’on peut vérifier sans avoir à le tenir entièrement dans sa tête. |
| Comprendre ce qu’on livre | S’assurer que quelqu’un, dans l’équipe, sait vraiment pourquoi ça marche. |
Le dernier point est le plus exigeant, parce qu’il va à contre-courant de la promesse de l’IA : il demande de ralentir pour comprendre, là précisément où la machine propose d’accélérer sans comprendre.
L’IA accélère-t-elle les équipes ou les amplifie-t-elle ?
Elle les amplifie. Le rapport DORA 2025 montre que l’IA magnifie les équipes solides et expose les équipes désorganisées, avec une hausse simultanée de la vitesse et de l’instabilité. La dette cognitive est le fil qui relie les deux.
Une équipe sans fondamentaux (tests, revue, compréhension partagée) voit l’IA creuser l’écart de compréhension plus vite qu’elle ne le comble. Le problème n’est pas la vitesse, mais la vitesse privée de l’infrastructure de compréhension qui la rend soutenable.
Pour aller plus loin : le lien avec DORA 2025 Le cadre vient du rapport DORA 2025 : l’IA est un amplificateur, qui magnifie les forces des équipes matures et expose les failles des autres. DORA observe une hausse simultanée du débit et de l’instabilité de livraison. Le diagnostic rejoint celui du harnais (harness) des agents de code, à une autre échelle : le harnais contient le risque le temps d’une session d’agent ; les fondamentaux mesurés par DORA le contiennent à l’échelle de l’organisation.
Quelles compétences ne faut-il pas déléguer à l’IA ?
Celles qui permettent de juger ce que l’IA produit : relire et évaluer la qualité, trouver la cause racine d’un bug, penser la maintenabilité à long terme, connaître la base de code, clarifier le besoin et avancer par petits pas. Ce sont elles qui contiennent la dette cognitive.
Dès mars 2025, Birgitta Böckeler (Thoughtworks) les a identifiées en observant les erreurs qu’un agent de code commettait et qu’il fallait rattraper : rustines à la place d’un vrai diagnostic, besoins mal compris, trop de travail d’un coup, composants recréés alors qu’ils existaient déjà, code et tests inutilement verbeux.
| Ce que l’humain doit continuer de savoir faire | L’erreur d’agent qu’il permet de rattraper |
|---|---|
| Relire et juger la qualité | Un code ou des tests trop complexes, trop verbeux |
| Trouver la cause racine d’un bug | Une rustine à la place d’un vrai diagnostic |
| Penser la maintenabilité à long terme | Un système qui devient difficile à faire évoluer |
| Connaître la base de code | Un composant recréé alors qu’il existait déjà |
| Clarifier le besoin, planifier par petits pas | Un besoin mal compris, trop de travail d’un coup |
À l’inverse, écrire de la syntaxe, du code répétitif (boilerplate), des tests basiques ou des refactorings simples se délègue plus volontiers.
Le piège est générationnel. Ce sont exactement les compétences que l’IA semble rendre inutiles au quotidien (lire du code, diagnostiquer, réviser) qui deviennent le seul rempart contre la dette cognitive. Une équipe qui délègue trop tôt atrophie le muscle dont elle aura besoin le jour de l’incident. Sans un humain dans la boucle, on accepte des rustines à la place d’un vrai diagnostic, et chaque rustine creuse un peu plus la dette.
« Those are the skills we have to preserve and train for. » (Birgitta Böckeler)
Ce piège porte désormais un nom : la crise de l’apprentissage. Les juniors apprenaient en écrivant du code simple et en se faisant relire, soit exactement les tâches que l’on confie en premier à l’IA.
Pour aller plus loin : crise de l’apprentissage et revue par exception Le rapport Thoughtworks relayé par Martin Fowler le 21 juillet 2026 parle d’apprenticeship crisis. Alasdair Allan, cité par InfoQ le 13 août 2026, résume : « The career pipeline was built for people who write code. We haven’t rebuilt it for people who supervise systems. » Nuance sur la revue : Rachel Laycock (2 septembre 2026) propose une revue humaine par exception, déclenchée par un changement d’architecture, le franchissement d’une frontière de sécurité, un fort rayon d’impact, une zone mal connue d’un système critique ou le doute de l’équipe. Ce qu’il ne faut pas déléguer, ce n’est pas la relecture de chaque ligne, c’est le jugement, qu’elle déplace en amont.
Comment tenir un agent de code en laisse ?
En deux gestes symétriques, que le Radar résume par la formule putting coding agents on a leash, mettre l’agent en laisse. En amont, on cadre l’agent avant qu’il agisse, avec des consignes claires et des spécifications. En aval, on le laisse se corriger, grâce à des tests qui lui renvoient un signal fiable.
Rien de magique : cela demande de l’ingénierie, pas un prompt de plus.
Pour aller plus loin : feedforward et feedback En vocabulaire précis, cadrer en amont relève du feedforward (Agent Skills, spec-driven development) ; vérifier en aval relève du feedback (mutation testing, capteurs déterministes). C’est le prolongement direct du couple guides et capteurs du harnais : la dette cognitive est le risque systémique, la laisse en est le contre-feu à l’échelle de la session d’agent.
La vitesse a un prix : continuer à comprendre
La vitesse que l’IA vous offre n’est pas gratuite : c’est un prêt. Vous le remboursez en compréhension, avec intérêts, et le relevé n’est pas daté. Il n’apparaît ni dans le sprint où vous l’avez contracté, ni dans les tests verts, ni dans le tableau de bord de vélocité. Il arrive le jour où il faut faire évoluer, diagnostiquer ou reprendre un système que la machine a écrit plus vite que l’équipe ne l’a compris.
Le vrai luxe, cette année, n’est pas de coder plus vite. C’est de continuer à comprendre ce que l’on livre, et d’en faire une discipline plutôt qu’une bonne intention.
Sources
- Thoughtworks, Technology Radar Vol. 34, communiqué de presse sur la dette cognitive (15 avril 2026) : https://www.thoughtworks.com/about-us/news/2026/combat-ai-cognitive-debt-radar-v34
- Thoughtworks, Technology Radar, version interactive : https://www.thoughtworks.com/radar
- Thoughtworks, Technology Radar, fiche Claude Code (anneau Adopt) : https://www.thoughtworks.com/radar/tools/claude-code
- Birgitta Böckeler, The role of developer skills in agentic coding, martinfowler.com (mars 2025) : https://martinfowler.com/articles/exploring-gen-ai/13-role-of-developer-skills.html
- Martin Fowler, Fragments: July 21 (2026) : https://martinfowler.com/fragments/2026-07-21.html
- Ben Linders, How Artificial Intelligence Disrupts Engineering Progression, InfoQ (13 août 2026) : https://www.infoq.com/news/2026/08/AI-disrupts-engineering-progress/
- Rachel Laycock, Maybe We Shouldn’t Be Reviewing All This Code, martinfowler.com (2 septembre 2026) : https://martinfowler.com/rachels-ramblings/code-review.html
Et chez vous ?
Vos équipes utilisent déjà l’IA pour développer. La question n’est plus de savoir si, mais avec quel cadre : quelles consignes en amont, quels capteurs en aval, et qui les fait évoluer.
Chez Ease by Atecna, nous accompagnons les équipes de développement sur ce terrain : diagnostic de maturité, mise en place des guides et des capteurs, industrialisation multi-projets avec notre offre de développement IA, et montée en compétence des équipes.