Le chronomètre raconte une histoire incomplète
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é.
Les mêmes 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.
Ce que METR mesure dans des dépôts déjà bien connus
Dans une expérience menée sur des outils du début de 2025, 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. Il rappelle en revanche la nécessité de distinguer le sentiment d’aller vite du temps réellement gagné.
L’enquête d’IBM Research auprès de 57 développeurs, comparée à 35 enquêtes existantes, complète cette lecture. 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 compréhension du code se vérifie aussi pendant la reprise
Le vert d’un diff signale généralement des lignes ajoutées, pas des tests réussis. Un pipeline CI au vert indique que les contrôles configurés ont passé ; il ne prouve pas que l’équipe comprend toutes les hypothèses de la modification.
Le code transporte une connaissance qui n’est pas toujours 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.
Cette dette peut devenir visible pendant un incident, une migration ou le départ d’un collaborateur. La capacité de l’outil à produire une réponse ne garantit pas que l’équipe dispose des connaissances nécessaires pour vérifier cette réponse et intervenir. Les études citées ne mesurent toutefois pas à elles seules les effets de cette dépendance sur plusieurs années de maintenance.
Évaluer le temps gagné et la capacité de maintenance
Les assistants peuvent être utiles 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 ?