L'essentiel
- La règle la plus répétée, selon laquelle un agent qui se relit se dégrade, a été établie en 2023 sur les modèles de 2023. En 2026, sur sept modèles testés, trois ne perdent plus rien. Un conseil qui dépend de la génération de modèle n'est pas une méthode.
- Ce qui n'a pas bougé : une suite verte n'a jamais été une preuve. À ICSE 2026, sur trois agents réels, 11,0 % des correctifs qui passaient les tests sont certainement incorrects.
- Ce qui a rendu votre agent méthodique n'est pas sa version, c'est ce qu'on lui écrit avant qu'il agisse. Trois mesures de 2026 l'établissent à poids constants.
- Donc ce que vous facturez n'est pas l'accès au modèle, qui se loue et qui baisse, c'est la méthode écrite, qui vous appartient et qui passe au modèle suivant.
Les règles que vous appliquez ont été mesurées sur des modèles retirés du service
En 2023, une équipe de Google DeepMind et de l'université de l'Illinois a défini la notion d'autocorrection intrinsèque : un modèle qui révise sa réponse avec ses seules capacités, sans rien de l'extérieur. Leur résultat, publié à ICLR 2024, est que la performance baisse après révision sur les tâches de raisonnement testées. Une équipe de Cambridge a précisé l'année suivante que la panne était dans la localisation de l'erreur plus que dans sa correction.
Ces deux résultats sont devenus la règle que tout le monde répète. Ils ont été obtenus sur des modèles que personne ne fait plus tourner.
En avril 2026, deux chercheurs ont repris la question en traitant la relecture comme une boucle d'asservissement, et l'ont mesurée sur sept modèles et trois jeux de données. La dégradation n'est plus générale. Trois modèles ne perdent plus rien quand ils se relisent : l'un gagne 3,4 points d'exactitude, un autre 0,6 point, un troisième reste à l'équilibre. Quatre en perdent encore, dont un modèle récent. Cette publication n'est pas évaluée par des pairs, et elle est signée de deux auteurs : prenez ses chiffres comme une indication, pas comme un acquis.
Appliquer en 2026 une règle de 2023 a donc deux coûts simultanés. Vous bridez un agent qui n'a plus le défaut qu'on lui prête, et vous vous croyez protégé par une précaution qui ne couvre pas le risque réel.
Le critère utile est l'objet du résultat, non sa date. Un résultat qui mesure un modèle meurt avec la génération qu'il a mesurée. Un résultat qui mesure un instrument ou le jugement humain traverse les générations, parce que ni l'un ni l'autre n'est mis à jour tous les six mois.
Ce qui n'a pas bougé : une suite verte n'a jamais été une preuve
Le résultat le plus utile de l'année ne parle pas d'intelligence. Il parle de l'instrument qui déclare le travail fini. Présenté à ICSE 2026, à Rio de Janeiro, par une équipe de l'université du Zhejiang et du centre CISPA, il porte sur les correctifs produits par trois agents de résolution de tickets réels, évalués sur le jeu de référence du domaine. Les auteurs ne se contentent pas de relancer les tests : ils comparent le comportement de chaque correctif à celui du correctif écrit par un humain.
- 7,8 % des correctifs comptés comme corrects échouent en réalité à la suite de tests écrite par les développeurs du projet.
- 29,6 % des correctifs plausibles se comportent autrement que le correctif humain.
- Sur ces divergences, l'inspection manuelle en déclare 28,6 % certainement incorrectes, soit 11,0 % de tous les correctifs plausibles.
- Au total, les taux de réussite publiés sont gonflés de 6,4 points.
Relisez cette liste en cherchant une phrase sur la capacité du modèle. Il n'y en a pas. Les tests passaient. Les tests étaient faibles. C'est la seule chose qui s'est produite, et aucune amélioration de modèle ne la corrige, parce qu'un agent plus fort produit simplement plus de code que ces tests continuent de ne pas vérifier.
C'est aussi pourquoi deux résultats de 2014 restent exacts douze ans plus tard. Inozemtseva et Holmes ont montré que la corrélation entre la couverture de code et la capacité d'une suite à trouver des défauts disparaît largement dès qu'on contrôle le nombre de tests : un test qui exécute une ligne sans rien vérifier la compte comme couverte. Just et ses coauteurs ont établi la même année que le test de mutation, lui, prédit la détection de vrais défauts. Ces deux énoncés portent sur des suites de tests, pas sur des modèles. Rien dans l'évolution de l'IA ne les menace.
Pourquoi votre agent est devenu méthodique, et ce n'est pas sa version
Un agent de 2026 travaille de façon visiblement plus ordonnée qu'un agent de 2023. La tentation est de l'attribuer au modèle. Trois mesures de 2026 disent autre chose, et elles ont en commun de faire varier la méthode en gardant les poids identiques.
La première est la plus nette. Une équipe a pris des affirmations fausses et les a soumises à des modèles en gardant le texte identique au caractère près. Seule change l'étiquette qui dit d'où vient l'affirmation : le bloc de réflexion de l'agent, un message d'utilisateur, un retour d'outil, un bloc de mémoire. Le taux auquel le modèle signale explicitement l'erreur monte de 23 à 93 points selon les cas, avec un effet significatif sur dix combinaisons de modèle et de domaine sur douze. Le meilleur emplacement dépend du domaine.
Ce que cela signifie mérite d'être posé lentement. L'agent savait corriger l'erreur. Ce qui l'en empêchait était l'endroit où elle se trouvait : dans son propre fil de pensée. Sortez la même phrase de ce fil, et il la conteste.
La deuxième mesure porte sur la forme du raisonnement. Une équipe de onze auteurs a montré en février 2026 qu'une consigne imposant des étapes distinctes et complètes rend l'erreur nettement plus localisable qu'un raisonnement libre, et qu'en désignant l'étape fautive on obtient de 20 à 40 % de correction en plus. Imposer une structure n'est donc pas une coquetterie de présentation. C'est ce qui rend l'erreur trouvable.
La troisième est la plus directe. Sur un modèle qui se dégradait en se relisant, l'ajout d'une simple consigne de vérification préalable a ramené son taux d'introduction d'erreurs de 2 % à zéro, et transformé une perte de 6,2 points en un gain de 0,2 point. Même modèle, même semaine. Une phrase écrite.
Trois équipes indépendantes, trois protocoles, une seule conclusion : ce qui a changé le comportement de l'agent est ce qu'on écrit pour lui, pas ce qu'il y a dedans. Et c'est exactement ce qui rend cette conclusion durable. Les poids sont remplacés tous les six mois. Un fichier de méthode se recharge tel quel sur le modèle suivant.
Peu importe le nom que votre outil lui donne, fichier de règles, consignes de projet, compétence chargée au démarrage. Ce qui compte est qu'il s'agisse d'un fichier, qu'il soit à vous, et qu'il grossisse chaque fois qu'un défaut passe. C'est le seul élément de votre chaîne que la prochaine génération de modèles ne rendra pas obsolète.
Une réserve va avec, et elle vient aussi de 2026. Une étude de mars portant sur quatre jeux de données de code et d'usage d'outils mesure qu'un relecteur automatique laisse passer davantage d'actions risquées ou incorrectes quand il juge le tour qui vient de les produire. Demander une vérification ne suffit donc pas : la méthode doit envoyer le contrôle dehors.
Ce que vous louez, et ce que vous possédez
Ce raisonnement a une conséquence directe sur votre tarif, et elle est plus favorable qu'elle n'en a l'air.
Le modèle, vous le louez. Il change tous les six mois, son prix baisse, et votre client peut souscrire au même abonnement que vous dans l'après midi. Rien de ce qui fait sa force ne vous appartient, et facturer l'accès à un outil que l'acheteur peut obtenir seul est la position la plus fragile du marché.
Vous appartiennent en revanche la méthode écrite que vous rechargez sur chaque nouvelle version, les instruments que vous avez branchés pour que les erreurs se montrent au lieu de se raconter, et la trace de ce que ces instruments ont attrapé, qui est la seule preuve vérifiable que votre chaîne fonctionne.
Ces trois actifs ont une propriété que l'abonnement n'a pas : chaque amélioration du modèle les rend plus rentables, pas moins. Un agent plus rapide produit plus de travail à faire passer dans votre chaîne, donc plus de valeur sortie d'un même temps de contrôle. C'est là que se situe votre marge, et c'est ce qu'il faut écrire dans une proposition commerciale, à la place du nombre de lignes.
Que le gain de production soit réel n'est pas en discussion ici, et nous ne cherchons pas à le nuancer : ce qui se discute est son ampleur, pas son existence. Ce qui ne bouge pas, en revanche, c'est l'endroit où ce gain vient buter, et cet endroit est humain. Un agent lève la contrainte de production. Il ne lève ni la formulation du besoin, ni la validation de ce qui sort, et ces deux étapes deviennent mécaniquement le goulot dès que la troisième s'accélère.
Reste la question que tout le monde pose : de combien un agent bien instrumenté augmente t il réellement ce qu'un développeur livre ? Aucun chiffre crédible ne répond aujourd'hui. Les multiplicateurs qui circulent, de deux à dix, ne reposent sur aucun protocole publié, et nous n'en publions pas non plus, faute de l'avoir mesuré.
Ce que nous pouvons donner est un volume daté. Sur un de nos deux projets, quatre mois et demi d'activité représentent 202 150 lignes ajoutées ; sur l'autre, environ 3 000 tests automatisés tournent à chaque livraison. Un volume n'est pas une productivité, et nous insistons sur la nuance parce qu'elle nous a déjà coûté un démenti : un de nos compteurs présentait des imports de données comme des contributeurs humains, ce qui gonflait un chiffre de plusieurs ordres de grandeur sans que personne l'ait voulu.
Le multiplicateur qui vous concerne est le vôtre, et il se mesure sur vos tâches par la même méthode que celle décrite plus haut. Il vaudra toujours mieux qu'une moyenne publiée : celle là décrit des dépôts, des modèles et des méthodes qui ne sont pas les vôtres.
Une précision sur la façon de le mesurer, et elle vaut pour tout le reste de cet article : ne comptez pas sur votre impression du résultat. L'étude ICSE 2026 citée plus haut porte précisément sur des correctifs dont tout le monde pensait qu'ils fonctionnaient, tests à l'appui. Sur un de nos deux projets, le document fautif était parti chez le client après relecture, et c'est une capture d'écran qui a vu ce que la relecture n'avait pas vu.
Instrument 1 : lui donner des yeux
Un agent qui écrit une interface ne la voit pas. Il tient un modèle de ce qu'il croit avoir produit, et c'est ce modèle qu'il vérifie quand vous lui demandez si c'est bon. Le correctif est mécanique : lui faire rendre la page dans un navigateur sans interface, prendre une capture, et lire sa propre sortie avant de déclarer le travail fini.
La capture ne corrige rien par elle même. Elle déplace le constat hors du fil de pensée de l'agent, ce qui est exactement le mécanisme mesuré plus haut. Sur un de nos deux projets, c'est ainsi qu'a été vu un document déjà livré au client : deux publicités de la même campagne y affichaient des répartitions identiques alors que l'une avait reçu 983 clics et l'autre 2 996.
Trois règles vont avec, et chacune a été payée. La capture est une sortie explicite que l'agent doit relire, pas un coup d'oeil au passage. Le nombre d'itérations est plafonné, sinon l'agent tourne sur des différences qu'il est seul à voir. Et on compare des mesures, pas des impressions : la largeur d'un bloc, la présence d'un libellé, la valeur d'un champ, jamais « est ce que ça rend bien ».
Instrument 2 : la contre-épreuve
Un test qui passe du premier coup ne vous apprend rien, parce que vous ne savez pas s'il pouvait échouer. La contre-épreuve consiste à exiger de l'agent qu'il montre son test en train de tomber avant de montrer le correctif qui le fait passer.
Cette exigence coûte une ligne dans votre méthode écrite et elle élimine une famille entière de défauts : le test qui vérifie une constante, celui qui attrape son propre bouchon, celui qui a été réécrit pour correspondre au bogue. C'est également la seule parade au défaut mesuré à ICSE 2026, puisque le problème y est précisément que les tests ne pouvaient pas distinguer un correctif juste d'un correctif plausible.
Formulez la demande dans cet ordre, qui n'est pas négociable : le test d'abord, son échec ensuite, le correctif en dernier. Inversé, l'agent écrit le correctif puis un test taillé pour lui.
Instrument 3 : mesurer la valeur de vos tests, pas leur nombre
Le test de mutation introduit volontairement des défauts dans votre code et compte combien votre suite en attrape. C'est la mesure que la couverture ne donne pas, et c'est celle qui prédit la détection de vrais défauts.
Sur un de nos deux projets, le relevé est net. Deux cent quatre vingt quatre tests unitaires, des portes de couverture à 100 % sur la logique pure, une suite entièrement verte, et 23 % des mutations détectées au premier passage. Après renfort des assertions, sans qu'une seule ligne de code de production change, le score est monté à 98 %.
L'ordre importe. Faites mesurer le score avant de demander des tests supplémentaires, sinon l'agent produit du volume. Un score de mutation faible sur une suite verte vous dit où les assertions manquent, et c'est une liste d'adresses, pas un jugement.
Instrument 4 : un second lecteur, et surtout pas le même
Le dernier instrument est un second agent, et ses trois conditions comptent autant que son existence.
- Un autre outil et un autre modèle. C'est devenu la condition principale : la mesure de mars 2026 citée plus haut montre qu'un relecteur est plus indulgent avec ce qui vient d'être produit devant lui.
- En lecture seule. Un auditeur autorisé à corriger détruit la mesure, parce qu'on ne sait plus ce qui était faux ni ce qui a été changé.
- Les faits sans la conclusion. Donnez lui le code, les tests et le comportement observé. Ne lui donnez pas votre hypothèse, qu'il vous renverra validée.
Imposez un format de sortie, sinon vous recevrez un essai. Les deux lignes les plus utiles de ce format sont celles où le second agent dit ce qu'il n'a pas pu vérifier et où vous devriez aller voir vous même. Un travail présenté à NeurIPS 2026 va dans le même sens en montrant l'intérêt de grilles explicites plutôt que d'un avis libre.
Le rendement est à annoncer honnêtement. Sur une contre expertise de nos deux projets, neuf constats sont remontés, dont un seul défaut réel. Ce défaut n'était détectable par aucun autre instrument de la chaîne, et c'est ce qui justifie l'étape. Attendez vous à trier.
Comment savoir ce mois ci si votre agent se relit utilement
C'est la partie de cet article qui ne périmera pas, parce qu'elle ne contient pas de verdict. La mesure d'avril 2026 donne la bonne grandeur à surveiller : ce qui sépare une relecture utile d'une relecture nuisible est le taux auquel le modèle introduit de nouvelles erreurs pendant qu'il corrige. Vous ne pouvez pas lire ce taux de l'intérieur. Vous pouvez le mesurer sur vos tâches, en une demi journée.
- Rassemblez une vingtaine de tâches que votre agent a terminées et que vous avez vérifiées comme justes.
- Soumettez les à la relecture dans la forme où vous demandez habituellement une relecture, sans dire qu'elles sont justes.
- Comptez deux nombres : combien l'agent modifie, et parmi celles là, combien il casse.
Le second nombre divisé par vingt est votre taux d'introduction d'erreurs, sur votre modèle, ce mois ci. S'il est proche de zéro, laissez l'agent se relire et vous gagnerez du temps. S'il est élevé, votre demande de relecture vous coûte de l'argent, et c'est aux instruments extérieurs qu'il faut confier le contrôle.
Deux réserves, pour que vous sachiez ce que vaut votre chiffre. Vingt tâches donnent une grandeur, pas une statistique : c'est assez pour décider chez vous, pas pour être publié. Et le résultat ne vaut que pour votre type de tâche, ce qui est précisément l'information que vous cherchez. Refaites la mesure à chaque changement de modèle. Un quart d'heure deux fois par an remplace toute la littérature citée dans cet article.
Faut-il relire tout le code qu'il produit ?
La question se pose dès que les volumes montent, et la réponse honnête est non. Sur un de nos deux projets, quatre mois et demi d'activité représentent 202 150 lignes ajoutées. Tout relire fait disparaître le gain qui justifiait l'agent. Ne rien relire vous laisse le résultat mesuré à ICSE 2026, où les tests verts couvraient 11 % de correctifs certainement faux.
La sortie n'est pas de lire plus vite. Elle est de ne plus lire le code, mais ce qui dit si le code est juste. Cinq lectures suffisent, dans cet ordre.
- Ce que l'agent déclare ne pas avoir vérifié. C'est la lecture la plus rentable de la liste, et elle n'existe que si votre méthode écrite impose cette déclaration.
- Les assertions, pas le code. Un test dit ce qui est garanti. Lire dix assertions renseigne mieux que lire mille lignes.
- Le diff de ce qui est irréversible. Migrations, droits, suppressions, argent. Ces quatre familles se relisent intégralement, toujours, quel que soit le modèle.
- Le rendu, jamais le gabarit. Une chaîne présente dans le HTML ne dit rien de son affichage.
- Le cas réel, rejoué par vous. Sur l'environnement déployé, avec vos mains, une fois.
Rien de cette liste ne dépend de la génération de modèle, et c'est voulu. Les instruments ne remplacent pas votre relecture : ils lui donnent une adresse, ce qui est la seule chose qui manque quand il y a deux cent mille lignes à ne pas lire.
Le verrou : rien n'est fait tant qu'un humain n'a pas dit oui
Sur l'autre de nos deux projets, environ 3 000 tests automatisés tournent, et les quatre défauts de la période ont tous été trouvés par un humain qui cliquait. Ce n'est pas un argument contre les tests, qui ont empêché tout le reste. C'est la raison pour laquelle la dernière étape de la chaîne ne s'automatise pas.
L'agent peut tout faire sauf déclarer que c'est fini. Cette règle ralentit, et c'est voulu, puisqu'elle impose un déploiement entre le correctif et la clôture. En échange, sur le projet qui l'applique, aucun point fermé n'a eu à être rouvert pour validation hâtive.
La grille à passer sur votre prochaine mission
Les six questions suivantes se posent avant la première ligne de code, et aucune ne dépend du modèle que vous utiliserez.
- Ma méthode est elle écrite dans un fichier, ou seulement dans ma tête et dans mes messages ?
- Mon agent a t il un moyen de voir ce qu'il produit, ou seulement de le décrire ?
- Chaque test est il passé par un échec observé avant d'être accepté ?
- Connais je le score de mutation de la suite, et pas seulement sa couleur ?
- La relecture critique est elle faite par un autre modèle, en lecture seule ?
- Ai je mesuré, ce mois ci, ce que l'agent casse quand il se relit ?
Une réponse négative désigne une ligne à ajouter à votre fichier de méthode, pas une faute. C'est d'ailleurs comme cela que ce fichier devient un actif : il ne se rédige pas d'avance, il s'écrit à chaque fois qu'un défaut est passé.
Keobiz
Expert-comptable en ligne
Cabinet d'expertise comptable en ligne pour SASU et EURL : tenue, bilan validé et déclarations pris en charge, avec un chargé de mission dédié.
Demander un devis KeobizQuestions fréquentes
Les conseils sur le contrôle d'un agent IA deviennent-ils obsolètes ?
Oui, et c'est vérifiable. La règle la plus citée, selon laquelle un agent qui se relit dégrade son travail, a été établie en 2023 sur les modèles de 2023. Une mesure d'avril 2026 portant sur sept modèles et trois jeux de données constate que la dégradation n'est plus générale : trois modèles ne perdent plus rien, quatre en perdent encore. Un conseil dont la validité dépend de la génération de modèle n'est pas une méthode. Le critère de solidité d'un résultat n'est pas sa date mais son objet : ce qui mesure un modèle périme, ce qui mesure un instrument de test ou le jugement humain reste vrai.
Un agent IA peut-il relire son propre code ?
Cela dépend du modèle, et cela se mesure. Ce qui sépare une relecture utile d'une relecture nuisible est le taux auquel le modèle introduit de nouvelles erreurs pendant qu'il corrige. En dessous d'environ un demi pour cent, la relecture améliore ; au dessus, elle détruit. Vous ne pouvez pas lire ce taux de l'intérieur, mais vous pouvez le mesurer sur vos propres tâches en une demi-journée : reprenez vingt tâches que vous avez vérifiées comme justes, soumettez les à la relecture sans dire qu'elles sont justes, et comptez combien l'agent casse.
Qu'est-ce qui rend un agent IA méthodique ?
Ce qu'on lui écrit avant qu'il agisse, et non sa version. Trois mesures de 2026 le montrent à poids constants. Une étude de juin 2026 garde une affirmation fausse au caractère près et ne change que l'étiquette disant d'où elle vient : le taux de correction explicite monte de 23 à 93 points, sur dix combinaisons sur douze. Une étude de février 2026 montre qu'une méthode qui impose des étapes distinctes et complètes rend l'erreur beaucoup plus localisable qu'un raisonnement libre. Une troisième, en avril 2026, inverse la dégradation d'un modèle avec une simple consigne de vérification préalable. La méthode écrite est donc un actif qui passe au modèle suivant, alors que les poids sont remplacés.
Faut-il relire tout le code produit par une IA ?
Non : c'est hors de portée et c'est la mauvaise cible. Sur un projet de quatre mois et demi, 202 150 lignes ont été ajoutées. La méthode consiste à ne plus lire le code mais ce qui dit si le code est juste, dans cet ordre : ce que l'agent déclare ne pas avoir vérifié, les assertions des tests plutôt que le code, le diff de ce qui est irréversible (migrations, droits, suppressions, argent), le rendu plutôt que le gabarit, et le cas réel rejoué soi même sur l'environnement déployé.
Une couverture de tests à 100 % suffit-elle à valider du code écrit par une IA ?
Non, et c'est le résultat le plus stable du domaine. Inozemtseva et Holmes (ICSE 2014) montrent que la corrélation entre couverture et efficacité disparaît largement dès qu'on contrôle la taille de la suite : un test qui exécute du code sans rien vérifier compte pour 100 %. Une étude présentée à ICSE 2026 sur trois agents réels mesure la conséquence directe : 11,0 % des correctifs qui passent les tests sont certainement incorrects, et les taux de réussite publiés sont gonflés de 6,4 points. Le test de mutation donne la mesure manquante. Sur un de nos deux projets, le premier passage détectait 23 % des mutations alors que toute la suite était verte.
Faut-il faire relire son code par un second agent IA ?
Oui, à trois conditions, et la première est devenue la plus importante. Un autre outil et un autre modèle : une étude de mars 2026 portant sur quatre jeux de données de code et d'outils mesure qu'un relecteur laisse passer davantage d'actions risquées ou incorrectes quand il juge le tour qui vient de les produire. La lecture seule, parce qu'un auditeur qui corrige détruit la mesure. Les faits sans la conclusion, parce qu'un modèle à qui l'on soumet une hypothèse tend à la renvoyer validée. Rendement mesuré sur une contre-expertise : neuf constats, dont un seul défaut réel, mais invisible par tout autre moyen.
Pour aller plus loin sur ce site
- Outils IA pour freelances : quels outils pour quel métier, et ce qu'ils ne remplacent pas.
- L'IA comme levier de TJM : quelles compétences font réellement monter un tarif, chiffres à l'appui.
- Ce que l'IA supprime vraiment : les protections cèdent avant les métiers.
- Baromètre IA et Data : nos relevés de TJM sur les créneaux concernés.
Sources
Les publications sont classées par ce qu'elles mesurent, puisque c'est le critère retenu dans cet article. La date de consultation est celle de la dernière vérification à la source primaire.
Ce qui mesure un instrument ou un humain
- You Wang, Michael Pradel, Zhongxin Liu, « Are “Solved Issues” in SWE-bench Really Solved Correctly ? An Empirical Study », université du Zhejiang et CISPA Helmholtz Center, ICSE 2026, Rio de Janeiro. Consulté le 31/10/2026.
- Boxi Yu, Yuxuan Zhu, Pinjia He, « UTBoost: Rigorous Evaluation of Coding Agents on SWE-Bench », ACL 2025 : 345 correctifs comptés à tort comme réussis. Consulté le 31/10/2026.
- Laura Inozemtseva, Reid Holmes, « Coverage Is Not Strongly Correlated with Test Suite Effectiveness », université de Waterloo, ICSE 2014, p. 435-445. Consulté le 31/10/2026.
- René Just et al., « Are Mutants a Valid Substitute for Real Faults in Software Testing ? », FSE 2014, p. 654-665. Consulté le 31/10/2026.
Ce qui mesure l'effet de la méthode, à modèle constant
- Kuan-Yen Chen et al., « The Self-Correction Illusion: Role Relabeling Gates Explicit Error Flagging in Large Language Models », juin 2026, révisé le 31/07/2026 : affirmation identique au caractère près, 23 à 93 points d'écart selon l'étiquette de provenance. Consulté le 31/10/2026.
- Ankur Samanta et al., « Structure Enables Effective Self-Localization of Errors in LLMs », février 2026, révisé le 30/05/2026 : 20 à 40 % de correction en plus quand l'étape fautive est désignée. Consulté le 31/10/2026.
- Dipika Khullar, Jack Hopkins, Rowan Wang, Fabien Roger, « Self-Attribution Bias: When AI Monitors Go Easy on Themselves », mars 2026, quatre jeux de données de code et d'usage d'outils. Consulté le 31/10/2026.
- Xiong et al., « Rubrics as Contextual Verifiers », NeurIPS 2026, publié le 25/08/2026. Consulté le 31/10/2026.
- Aofan Liu, Jingxiang Meng, « Self-Correction as Feedback Control: Error Dynamics, Stability Thresholds, and Prompt Interventions in LLMs », avril 2026, révisé le 04/05/2026. Sept modèles, trois jeux de données. Prépublication non évaluée par des pairs, signalée comme telle dans le texte. Consulté le 31/10/2026.
Ce qui mesurait une génération de modèles, et qui est cité ici comme tel
- Jie Huang et al., « Large Language Models Cannot Self-Correct Reasoning Yet », Google DeepMind et université de l'Illinois à Urbana-Champaign, ICLR 2024. Mesuré sur les modèles de 2023. Consulté le 31/10/2026.
- « Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity », METR, juillet 2025. Essai randomisé sur 16 développeurs et 246 tâches : mesure conduite sur des modèles remplacés depuis, dans des dépôts connus des participants et sans méthode écrite. Aucun de ses chiffres n'est repris dans cet article. Consulté le 31/10/2026.
- Neil Perry et al., « Do Users Write More Insecure Code with AI Assistants ? », université Stanford, ACM CCS 2023. Mesuré sur un assistant de 2022, hors service depuis ; cité ici uniquement comme exemple de résultat périmé. Consulté le 31/10/2026.
- Gladys Tyen et al., « LLMs cannot find reasoning errors, but can correct them given the error location », université de Cambridge et Google Research, Findings of ACL 2024, 2 186 chaînes annotées. Consulté le 31/10/2026.