Voici une phrase qui aurait ressemblé à un coup de publicité il y a quelques années. Selon Anthropic, Claude écrit désormais environ 90 pour cent du code de Claude Code, l’outil de programmation de l’entreprise. Ce chiffre vient d’un récit publié le 16 octobre 2026 par des membres de l’équipe Claude Code – Osmani, Lunt et Wang – qui décrivent leur manière de construire le produit au quotidien. Simon Willison a signalé ce texte le même jour. L’outil, en grande partie, se construit lui-même.
Le chiffre de tête attire l’attention. Le changement plus discret en dessous compte davantage. La relecture du code, explique l’équipe, ne se situe plus à la fin du processus, comme un professeur qui corrige des copies après le cours. Elle se déroule en continu, pendant que le code s’écrit, plus proche d’un correcteur orthographique que d’une inspection formelle. La plupart des modifications, rapporte l’équipe, sont relues et corrigées par Claude avant qu’un humain les voie. Relisez cela. L’humain n’est plus le premier lecteur. Il est le deuxième.
Les chiffres derrière l’affirmation
Le récit de l’équipe d’Anthropic donne deux chiffres qui donnent forme à l’histoire. Les demandes de fusion acceptées – les morceaux de code qui arrivent réellement dans le produit – ont plus que doublé entre juin et septembre 2026. Dans le même temps, la part des modifications qui ont dû être annulées, c’est-à-dire du travail défait après sa livraison, a chuté de plus de 40 pour cent.
Ces deux chiffres vont ensemble. Faire arriver plus de code n’a rien d’impressionnant en soi ; n’importe qui peut livrer plus vite en abaissant l’exigence. Ce que l’équipe affirme, c’est la vitesse et un taux d’erreur plus faible en même temps, ce qui est le tour le plus difficile. Si deux fois plus de modifications arrivent et qu’une part plus petite revient en arrière, quelque chose dans le processus lui-même a changé, pas seulement le rythme.
La relecture entrée dans l’écriture
La relecture classique a un rythme que la plupart des programmeurs connaissent par coeur. On écrit pendant des heures, parfois des jours. On ouvre une demande de fusion. Un collègue la lit plus tard, fatigué, occupé, en passant d’une tâche à l’autre, et laisse des commentaires. On corrige, on attend, on corrige encore. La boucle peut s’étirer sur une semaine, et quand un vrai problème apparaît, l’auteur a à moitié oublié pourquoi il avait fait le choix que l’on questionne.
La relecture continue brise ce rythme. Si Claude lit chaque modification au moment où elle apparaît, signale sur-le-champ une hypothèse fragile et propose une correction pendant que le raisonnement est encore frais, la relecture cesse d’être une porte pour devenir une partie de l’acte d’écrire. La comparaison avec le correcteur orthographique, dans le récit de l’équipe, est juste. Personne n’envoie une lettre pour demander ensuite à un ami d’en vérifier l’orthographe. Le soulignement rouge apparaît pendant que les mains sont encore sur le clavier. C’est ce modèle qui s’applique désormais au logiciel, sauf que le soulignement peut aussi s’expliquer et proposer la correction. Cette recherche de fiabilité dès la conception rappelle, dans un autre registre, les vingt ans de travail méthodique pour la planète célébrés à Monte-Carlo, où la constance du contrôle fait la crédibilité du résultat.
Ce que l’humain fait toujours
Rien de tout cela ne retire les personnes de la boucle, et le récit de l’équipe ne le prétend pas. Un humain décide toujours de ce que le produit doit faire, regarde toujours après le passage de Claude et porte toujours la responsabilité de ce qui part en production. Le goût, le jugement, le sens du produit : appelez cela comme vous voulez, cela n’a pas été automatisé. Ce qui a changé, c’est l’ordre des opérations. Le premier passage, infatigable, ligne par ligne, appartient à la machine. Le passage humain devient une question d’intention. Est-ce que cela fait la bonne chose, et pas seulement une chose correcte ?
Cette distinction compte. Vérifier la syntaxe et repérer un cas limite oublié est un travail qu’un relecteur patient fait bien un bon jour et mal un mauvais jour. Décider si une fonction doit exister demande un contexte qu’aucun modèle ne détient seul : la feuille de route, la plainte d’un client au printemps dernier, la promesse faite à un partenaire.
Pourquoi cela compte au-delà d’Anthropic
Anthropic dispose ici d’un avantage évident. L’entreprise construit le modèle et l’outil de programmation sous le même toit, donc Claude est testé chaque jour sur un code réel et exigeant. La plupart des équipes n’ont pas ce luxe.
Le schéma, pourtant, voyage. Toute équipe peut se poser la question soulevée par ce récit : où se fait la vérification dans notre processus, et à quel moment devient-elle trop tardive ? Le même déplacement s’observe dans les logiciels grand public, où les assistants se rapprochent du moment de l’action. L’aide qui arrive pendant la tâche vaut mieux que l’aide qui arrive après. La programmation est l’endroit où la preuve est la plus claire, parce que le code fonctionne ou ne fonctionne pas, et que les chiffres – demandes acceptées en hausse, annulations en baisse – peuvent se compter.
Quelques réserves honnêtes
Ces chiffres viennent de la propre équipe d’Anthropic, qui écrit sur son propre produit. Cela ne les rend pas faux, mais ils doivent être lus comme un rapport venu de l’intérieur, pas comme un audit indépendant. D’autres équipes, sur des systèmes plus anciens et plus désordonnés, doivent s’attendre à des résultats plus désordonnés.
Il y a aussi une vraie question de compétence. Si les jeunes ingénieurs ne font jamais eux-mêmes le lent travail de première relecture, comment développent-ils l’oeil sur lequel les ingénieurs expérimentés s’appuient ? Les équipes auront ce débat, et elles ont raison de l’avoir.
La leçon pour les équipes qui travaillent
Retirez le chiffre de tête et une leçon pratique demeure. Déplacez la vérification plus tôt. Rendez le premier passage de relecture rapide, automatique et continu, afin que les relecteurs humains consacrent leur attention à la conception, à l’intention et au risque. Mesurez deux choses à la fois : ce qui part en production, et ce qui revient. La vitesse seule n’est qu’une manière plus rapide de faire du désordre.
Quatre-vingt-dix pour cent est un chiffre frappant, et il sera cité toute la semaine. Mais le doublement des demandes de fusion acceptées, accompagné d’une baisse de plus de 40 pour cent des annulations, est la partie sur laquelle il faut s’attarder. L’histoire n’est pas qu’une machine a appris à taper du code. L’histoire est que la relecture, la plus ancienne habitude de qualité du logiciel, est entrée dans l’écriture elle-même, et que le travail est devenu meilleur en devenant plus rapide.
À lire aussi sur Le Miroir Français : la princesse héritière Victoria sur la Haute Côte suédoise, un littoral en pleine transformation, un autre récit récent qui prolonge, à sa manière, le plaisir de cette lecture.