Une heure de code généré, 63 heures de relecture humaine

Le fait

L’essai s’intitule « Understanding is the new bottleneck ». Il est daté du 2 juillet 2026 et signé Geoffrey Litt, design engineer chez Notion. Son texte défend une idée simple : la compréhension humaine reste nécessaire, non pour vérifier le travail de l’agent, mais pour rester partie prenante des itérations d’un projet. « It’s never just one loop! A project is many, many loops with the agent », écrit-il. Il propose trois parades : des documents d’explication assortis de quiz, des environnements où l’on manipule le système pour le comprendre, des espaces partagés entre humains et agents.

Le fait neuf n’est pas l’essai, c’est son rebond. Le texte a été soumis sur Hacker News le 13 août 2026 à 18 h 47 UTC et cumulait 291 points et 154 commentaires le lendemain. Ce fil vaut comme mesure de réception, pas comme source de fait : on y lit surtout des développeurs qui décrivent la même charge de relecture.

Notre regard

L’essai ne contient aucun chiffre. Nous en avons produit un, à partir de trois grandeurs documentées séparément.

Première grandeur, la vitesse de sortie d’un modèle : Artificial Analysis mesure 146,2 tokens par seconde sur GPT-5.5 Instant, pour une médiane de marché de 68,6 tokens par seconde. Deuxième grandeur, la conversion en lignes : nous l’avons mesurée au tokenizer o200k_base sur 159 fichiers de la bibliothèque standard de Python 3.11, soit 113 922 lignes non vides, et nous obtenons 9,84 tokens par ligne. Troisième grandeur, le rythme de relecture : la synthèse de SmartBear, tirée d’une étude menée dans une équipe de Cisco Systems, pose deux bornes, « review fewer than 400 lines of code at a time » et « inspection rates should [be] under 500 LOC per hour ». Entre 200 et 400 lignes examinées en 60 à 90 minutes, 70 à 90 % des défauts sont trouvés.

Le calcul tient en deux opérations. 68,6 tokens par seconde font 246 960 tokens dans l’heure, soit 25 100 lignes une fois divisés par 9,84. Nous avons rapporté ces 25 100 lignes aux 400 lignes qu’un relecteur traite dans le même temps : une heure de code généré par un modèle représente 63 heures de relecture humaine. Avec le modèle le plus rapide mesuré, le rapport monte à 134. Le graphique ci-dessous met les deux rythmes sur la même échelle.

Les deux barres de relecture sont presque invisibles à côté des barres de génération : c’est tout l’objet du calcul. Le tableau reprend les mêmes valeurs, avec la conversion en heures de relecture.

Ce rapport déborde le code. Un compte rendu, un devis, un dossier médical ou une conclusion juridique se produisent désormais à la même vitesse et se relisent toujours à la vitesse d’un humain qui lit. En France, l’Insee mesure que 18 % des entreprises de 10 salariés ou plus déclaraient utiliser au moins une technologie d’IA en 2025, contre 10 % un an plus tôt, et 58 % chez celles de 250 salariés ou plus. Parmi les entreprises qui mobilisent l’IA, 43 % emploient des outils de génération de texte ou de parole. La production de textes à relire est donc déjà une réalité de bureau, pas une hypothèse de laboratoire. Nous avions déjà décrit ce que fait cette facilité à qui apprend : l’illusion de maîtrise.

La nuance

Premier avertissement : le texte de départ est un essai d’opinion, pas une étude. Il n’avance aucune donnée quantitative et ne doit pas s’en voir prêter. Notre chiffre ne vient pas de lui.

Deuxième avertissement : 63 heures est une borne haute, et elle se lit comme un écart de rythme, pas comme une charge de travail réelle. Personne ne fait tourner un modèle une heure d’affilée, tout le code produit n’est pas relu ligne à ligne, et les 400 lignes par heure viennent d’une pratique d’inspection formelle, plus lente que la revue de demande de fusion telle qu’elle se pratique aujourd’hui. Le rapport de 1 à 63 dit une chose et une seule : les deux vitesses ne sont pas du même ordre de grandeur.

Troisième avertissement : la question n’est pas neuve, et une réponse ancienne existe. En 2015, Dan McKinley publiait « Choose Boring Technology », où il attribue à chaque entreprise « about three innovation tokens » à dépenser avec parcimonie. Limiter ce qu’il faut comprendre était déjà une stratégie il y a onze ans. Sur un terrain voisin, nous avons documenté ce que contient le raisonnement caché des modèles : l’opacité de la machine et la charge de relecture humaine sont deux problèmes distincts.

À surveiller

Le signal à guetter tient en un changement d’instrument : les organisations qui se mettent à mesurer le temps de relecture plutôt que le temps de production. Tant que le seul indicateur reste le volume livré, le goulot demeure invisible dans les tableaux de bord, puisqu’il se loge chez celui qui valide.

Concrètement, trois repères. Une équipe qui découpe ses livraisons en lots de moins de 400 lignes applique déjà la borne documentée par SmartBear. Un service juridique ou administratif qui plafonne le nombre de pages générées par jour fait le même geste avec un autre matériau. Une direction qui inscrit la relecture dans une fiche de poste reconnaît un travail que personne ne facture aujourd’hui.

Nous avons regardé hier l’autre versant de ce dossier, celui de l’emploi, dans « Le développeur “moyen” disparaît-il ? Ce que l’emploi français mesure vraiment », publié le 13 août 2026. La question posée ici est différente : elle ne porte pas sur le nombre de postes, mais sur l’heure de travail humaine que chaque heure de machine engendre.