Un diff vert n’est pas une preuve de maîtrise. Il indique que le code a franchi les contrôles prévus ; il ne dit pas si l’équipe saura expliquer ce code dans six mois, repérer l’hypothèse métier oubliée ou intervenir quand le comportement sortira du scénario nominal.
C’est là que se loge la dette cognitive liée aux assistants de code. Elle ne se voit pas forcément dans la qualité immédiate du livrable. Elle apparaît lorsque la vitesse de production dépasse la vitesse d’appropriation.
Le chronomètre raconte une histoire incomplète
Les gains existent. Une étude longitudinale publiée en mai 2026 a interrogé 158 ingénieurs lors d’une première mesure, puis 101 six mois plus tard ; 95 personnes ont participé aux deux vagues. Parmi les répondants, 82 % déclaraient consacrer moins de temps à l’écriture de code et 84 % percevaient un gain global de productivité.
Pris isolément, ces chiffres semblent clore le débat. La suite de l’étude est plus intéressante. Les auteurs observent un déplacement du travail vers la direction de l’outil, la vérification et la correction de ses sorties — le supervisory engineering work. Dans le groupe suivi, la proportion de personnes signalant la dégradation d’au moins une dimension de leur expérience est passée de 14 % à 27 %. La concentration et la charge cognitive figurent parmi les points affectés.
Il s’agit de déclarations, pas d’une mesure universelle de la qualité logicielle. Elles révèlent néanmoins un phénomène que les tableaux de vélocité enregistrent mal : gagner du temps sur la saisie peut en déplacer vers la supervision, parfois sous une forme plus fragmentée.
L’expérience METR dérange parce qu’elle mesure
METR a soumis seize développeurs expérimentés à 246 tâches issues de projets open source matures qu’ils connaissaient depuis cinq ans en moyenne. Avant l’expérience, ils anticipaient un gain de 24 % grâce à l’IA. Après l’avoir utilisée, ils estimaient encore avoir gagné environ 20 %.
Le temps observé racontait l’inverse : dans ce contexte précis, l’autorisation d’utiliser l’IA a allongé la réalisation de 19 %.
Ce résultat n’autorise pas à conclure que les assistants ralentissent le développement. L’échantillon est petit, les dépôts complexes, les participants très familiers de leur code et les outils datent du début de 2025. En revanche, il interdit une facilité : confondre le sentiment d’aller vite avec le temps réellement gagné.
L’enquête d’IBM Research auprès de 57 développeurs, comparée à 35 enquêtes existantes, conduit à une lecture moins spectaculaire et probablement plus utile. L’efficacité dépend de la tâche, du niveau d’exigence, du contexte fourni et de l’intégration de l’assistant dans le processus d’ingénierie. Il n’existe pas un effet « IA » homogène que l’on pourrait appliquer à toutes les équipes.
La dette apparaît le jour où il faut reprendre
Le code transporte une connaissance qui n’est jamais entièrement consignée dans les tickets. Pourquoi cette contrainte existe-t-elle ? Quel compromis a été rejeté ? Quelle donnée apparemment secondaire déclenche un comportement métier particulier ? Une équipe acquiert ces repères en concevant, en relisant et en réparant.
Si l’assistant explore le dépôt, propose l’architecture et écrit l’essentiel de la modification, le développeur peut valider un résultat plausible sans construire le même modèle mental. La documentation aide, mais elle ne remplace pas cette appropriation. Une spécification volumineuse peut même aggraver le problème lorsqu’elle accumule des règles contradictoires que personne ne relit vraiment.
La dette devient visible pendant un incident, une migration ou le départ d’un collaborateur. On découvre alors que la connaissance semblait présente parce que l’outil savait produire une réponse. Elle n’était plus disponible dans l’équipe sous une forme mobilisable.
Garder la main sans revenir au code à la bougie
Refuser les assistants serait une mauvaise réponse. Ils sont précieux pour parcourir une base inconnue, produire une première série de tests, comparer des stratégies ou éliminer un travail répétitif. La discipline consiste à décider ce qui peut être délégué et ce qui doit rester compris.
Avant une fusion importante, quelqu’un doit pouvoir défendre la modification sans réciter la conversation avec l’agent. Les choix d’architecture et les invariants métier méritent une trace courte, relue et attribuée. Les revues croisées doivent porter sur les hypothèses, pas seulement sur la forme du code. Enfin, quelques exercices de reprise sans l’outil — diagnostic d’incident, reconstruction d’un composant, changement de fournisseur — donnent une mesure concrète de l’autonomie restante.
Les métriques doivent suivre ce déplacement. Le nombre de lignes ou de tickets fermés renseigne sur le débit. Le temps de revue, les défauts réouverts, la durée d’un diagnostic et le délai de prise en main renseignent sur la maîtrise. Sans cette seconde famille d’indicateurs, une organisation peut célébrer sa productivité au moment même où elle fragilise sa capacité à maintenir ce qu’elle produit.
L’enjeu n’est donc pas de savoir qui, de l’humain ou de la machine, a frappé les touches. Il est beaucoup plus exigeant : lorsque le système se comportera mal, restera-t-il dans l’équipe quelqu’un capable de comprendre pourquoi ?