Le canard de Vaucanson ne digérait rien : Copilot et la dette cognitive du développeur

Le développeur qui ne comprenait plus son propre code

En mission chez une ETI l'an dernier, je demande à un développeur junior d'expliquer un bloc qu'il avait « écrit » la veille. Une fonction de trente lignes, mergée, testée, en production.

Il la relit. Silence. Il finit par lâcher : « En fait, Copilot me l'a proposée et ça marchait. » Le code compilait, les tests passaient, la pull request avait été validée. Tout allait bien — sauf que personne, dans l'équation, n'avait rien compris.

Je n'ai pas pensé « faute professionnelle ». J'ai pensé à un canard. Un canard de cuivre doré, fabriqué en 1738, qui n'a jamais rien digéré de sa vie.

Le canard qui faisait semblant de digérer

En 1738, l'ingénieur Jacques de Vaucanson présente à Paris trois automates. Le plus célèbre est un canard mécanique en cuivre doré, composé de centaines de pièces mobiles.

La bête battait des ailes, buvait, picorait du grain — et le digérait. Quelques instants après avoir avalé, elle déféquait sous les yeux ébahis d'une Europe des Lumières fascinée par les machines vivantes. Voltaire lui-même salua l'exploit.

Sauf que le canard ne digérait rien. On découvrit bien plus tard que les excréments étaient préchargés dans un compartiment caché, sans aucun lien avec le grain avalé. L'apparence parfaite du processus masquait l'absence totale du processus.

Le miroir inversé existe : le Turc mécanique de Wolfgang von Kempelen (1770), automate joueur d'échecs qui battait des adversaires prestigieux. Il cachait un humain accroupi dans le meuble.

Hier, on dissimulait l'humain dans la machine. Aujourd'hui, avec les assistants de code, on dissimule la machine dans le travail de l'humain. Dans les deux cas, la question est la même : qui pense réellement ?

Le pont : quand le code compile, qui a digéré ?

Voilà l'homologie exacte. Un développeur qui accepte du code généré sans le comprendre produit une digestion préchargée.

Le résultat est là, propre, fonctionnel. Mais la compréhension — cette transformation intérieure qui fait qu'on saura déboguer demain, adapter au contexte, expliquer à un collègue — n'a pas eu lieu. Elle a été simulée, comme les fientes du canard.

La métaphore n'est pas gratuite. Elle donne une grille de lecture racontable, à poser sur chaque commit : ton code assisté par IA, il digère ou il précharge ?

Ce que disent les données de 2026

Le débat n'est pas idéologique, il est mesurable. Trois études récentes cadrent le phénomène sans catastrophisme.

En janvier 2026, Anthropic a publié une étude expérimentale, How AI assistance impacts the formation of coding skills. Des participants codent avec ou sans assistant, puis passent un quiz sur les concepts qu'ils viennent d'utiliser.

Résultat : l'assistant IA réduit la maîtrise conceptuelle de 17 % par rapport au groupe qui code à la main, sur des notions employées quelques minutes plus tôt. Les gains de vitesse, eux, sont faibles et non significatifs statistiquement.

Surtout, l'étude documente une détérioration des capacités de lecture de code et de débogage chez les utilisateurs d'IA. C'est exactement la dette cognitive : on livre sans savoir digérer ce qu'on livre.

Anthropic distingue deux usages. L'un préserve la compréhension — interaction active, questions ciblées, relecture. L'autre la détruit — copier-coller passif, délégation totale.

La brique quantitative vient de Communications of the ACM (mai 2024), Measuring GitHub Copilot's Impact on Productivity. Elle confirme des gains de productivité perçue de 12 à 25 %, avec les juniors comme premiers bénéficiaires en vitesse.

Mais son constat le plus troublant tient en une phrase : le meilleur prédicteur du sentiment de productivité est le taux d'acceptation des suggestions. Plus on accepte de code, plus on se sent productif — sans garantie de compréhension.

Le troisième signal vient de France. Une étude relayée par Développez.com en juillet 2025 montre que des développeurs expérimentés ont mis 19 % de temps en plus avec assistant IA — alors qu'ils anticipaient 24 % de gain.

L'illusion de vitesse est donc mesurée, et l'écart avec le réel est béant. Sur les tâches complexes, le coût de compréhension, de correction et de réintégration du code généré dépasse le gain sur la frappe.

La distinction qui change tout : exécuter n'est pas comprendre

Je ne suis pas technophobe. Je déploie moi-même des agents, des systèmes RAG, des pipelines. L'outillage est l'histoire même du progrès technique — la fonderie n'a pas atrophié le forgeron, elle l'a déplacé.

La ligne de partage est ailleurs. Déléguer l'exécution est sain : générer un boilerplate, écrire des tests répétitifs, reformater. Déléguer la compréhension est la digestion préchargée.

La calculatrice offre le bon protocole culturel. On l'autorise à l'école après avoir appris à poser une division, jamais avant. L'ordre importe : l'outil amplifie une compétence acquise, il ne la remplace pas.

Il y a une raison théorique plus profonde, que j'explore dans cet essai sur l'esprit de finesse et l'esprit de géométrie chez Pascal : un LLM produit un code d'apparence parfaite tout en trébuchant sur la rigueur logique. La relecture humaine reste donc non négociable.

Pour qui veut le mode d'emploi raisonné de l'outil lui-même, notre guide complet de Claude Code traite le comment. Ici, je traite le à quel prix.

Cinq pratiques pour un CTO de PME ou d'ETI

Voici ce que je mets en place en mission, sans dogmatisme et sans interdire l'outil.

1. La revue « sans IA » orale. L'auteur d'une pull request explique chaque bloc de vive voix, sans assistant ouvert. S'il ne sait pas dire ce que fait son code, il ne le comprend pas — le canard est démasqué en trente secondes.

2. Un ratio junior/senior sur le code généré. Plus un développeur est junior, plus le code assisté doit passer par une relecture humaine senior. C'est là que la compétence se transmet, pas dans l'acceptation silencieuse d'une suggestion.

3. Des « journées sans copilote » pour les équipes en formation. Une journée par sprint où l'on code à la main. Non par nostalgie, mais pour maintenir vivants les muscles du débogage et de la lecture de code.

4. Mesurer la dette cognitive, pas seulement la vélocité. Suivez le temps moyen de résolution des bugs et la capacité des développeurs à expliquer le code livré. Un taux d'acceptation élevé n'est pas un indicateur de santé, c'est un signal à surveiller.

5. Savoir refuser l'IA. Sur un module critique, sur du code qu'une équipe doit maintenir dix ans, l'assistant peut être un mauvais calcul. Dire quand l'IA n'est pas la bonne réponse fait partie du métier — c'est le socle de notre façon de conseiller.

Ce qui a survécu de Vaucanson n'était pas le canard

Le canard digérateur a fini dans un incendie au XIXe siècle, quelque part en Allemagne. De cette prouesse d'illusion, il ne reste presque rien — quelques gravures, des récits.

Ce qui a survécu de Jacques de Vaucanson, ce sont ses métiers à tisser automatisés. Ces machines-là ne simulaient rien : elles transformaient réellement le travail. Elles ont préparé le métier Jacquard, et par lui, l'idée même de programme mécanique.

La leçon tient dans ce contraste. L'outil qui simule le processus ne laisse rien derrière lui ; l'outil qui outille réellement transforme une industrie. La dette cognitive du développeur naît précisément de la confusion entre les deux.

Alors avant de merger, posez la question du canard : ton code assisté par IA, il digère ou il précharge ? La réponse décide de ce qui restera de vous dans dix ans — une compétence, ou un compartiment caché.