Imaginez une automatisation qui rédige des soumissions, ou qui rapproche les factures de fournisseurs des bons de commande, et qui se trompe dans une tâche sur dix. Le fournisseur d'IA vient de lancer un modèle plus gros. Y passer ne demande qu'un réglage et une facture mensuelle plus élevée, alors c'est le geste qui s'impose. Un article d'août 2026 suggère de vérifier autre chose d'abord. Sur un banc d'essai exigeant, l'ajout d'une meilleure couche de contrôle autour du même modèle a relevé son score de 9 points, contre 1,8 pour le passage à la génération de modèle suivante (des scores de référence publiés, et non une nouvelle exécution contrôlée).
Ce que l'article a réellement bâti.
Le banc d'essai est Terminal-Bench 2.1 : 89 tâches techniques longues, en plusieurs étapes, qu'un agent d'IA exécute en ligne de commande, comme ajuster une courbe à des données de laboratoire, traiter les images d'une vidéo ou modifier des fichiers de séquences d'ADN. Les auteurs ont gardé le modèle fixe et changé ce qui l'entoure, la couche qu'on appelle d'ordinaire le harnais (harness en anglais).
Leur harnais, StateM, compte deux parties : un environnement d'exécution (le logiciel qui fait respecter la procédure) et un guide d'exécution (runbook en anglais), soit un fichier texte brut (en YAML, un format structuré) qui découpe un travail en quelques grandes phases, comme la planification, l'exécution, la révision, la passation et la réparation. L'agent s'y déplace avec des commandes ordinaires (où suis-je, quelle est la suite, aller à cette phase), et le logiciel tient le registre de l'état d'avancement de l'exécution en dehors de la mémoire de travail du modèle.
Deux choix de conception font le travail. D'abord, chaque phase a une porte de chaque côté. Entrer dans une phase charge les instructions de cette phase et la progression jusque-là, de sorte que l'agent ne se fie pas à ce dont il se souvient d'il y a deux heures. En sortir exige que les vérifications de sortie de la phase réussissent. Si une vérification échoue, l'exécution reste où elle est et l'échec est consigné au lieu d'être reporté dans la phase suivante. Ensuite, le guide d'exécution est un fichier ordinaire que l'agent et la personne qui supervise l'exécution lisent tous les deux. L'agent peut proposer une modification ; la personne peut le modifier, en conserver des versions et l'auditer.
La règle d'arrêt est la pièce la plus petite et la plus facile à emprunter. Quand l'agent tente de déclarer le travail terminé alors que le guide d'exécution indique qu'on est à mi-parcours, un crochet d'arrêt (stop hook en anglais) lui redonne la phase en cours et les obligations encore ouvertes. Les auteurs rapportent une exécution de développement qui s'est poursuivie pendant 22 heures, le crochet d'arrêt et le registre d'exécution tenu en dehors du modèle gardant le fil. Ils disent aussi qu'un crochet d'arrêt ne garantit rien à lui seul et qu'il lui faut des limites de temps et de reprises. Ils sont par ailleurs clairs sur ce que la conception n'est pas : le protocole est « checked, logged, and recoverable » (en anglais dans l'original ; vérifié, consigné et récupérable), selon leurs mots, « rather than fully transactional » (en anglais dans l'original ; plutôt que pleinement transactionnel).[1] Si une étape a déjà envoyé un courriel ou modifié un fichier, revenir d'une phase en arrière ne l'annule pas.
Les chiffres, chacun avec son astérisque.
Mettons le titre de côté : voici le résultat sur lequel repose l'article. GPT-5.5, exécuté sous l'agent Codex d'OpenAI, a un score de référence publié de 83,1 % sur le banc d'essai. Avec le guide d'exécution, les auteurs rapportent 92,1 %, avec 88 des 89 tâches résolues au moins une fois en cinq essais. Pour situer l'ampleur, avec la configuration de référence, passer de GPT-5.5 à la génération suivante, GPT-5.6 Sol, fait passer le score publié de 83,1 % à 84,9 %.
Les deux autres résultats comptent davantage pour une petite entreprise, parce qu'ils portent sur des modèles moins chers. GPT-5.6 Luna, une gamme moins coûteuse, est passé de 76,7 % à 85,4 % avec le guide d'exécution de GPT-5.5 appliqué tel quel, ce que les auteurs notent comme numériquement supérieur aux 84,9 % publiés pour le Sol, plus cher. DeepSeek-V4 Flash, d'un autre fournisseur, est passé de 82,7 % à 88,1 % une fois le guide d'exécution réadapté pour lui.
Lisez chaque rangée avec son astérisque. Les scores « avant » de GPT sont des chiffres de référence publiés, et celui de GPT-5.5 provient d'une autre version de l'agent Codex ; les auteurs précisent dans une note de bas de page qu'il ne s'agit pas d'une nouvelle exécution faite à conditions identiques. Le « avant » de DeepSeek est l'exécution des auteurs eux-mêmes, ce qui en fait le plus fiable des trois. « Numerically above » (en anglais dans l'original ; numériquement supérieur) est l'expression des auteurs pour Luna, et c'est la bonne : 85,4 contre 84,9, c'est un demi-point entre leur exécution et le chiffre publié par quelqu'un d'autre. Le tout porte sur un seul banc d'essai, avec un guide d'exécution mis au point sur ce banc d'essai.
Ces réserves posées, la tendance reste instructive. Sur des tâches longues, en plusieurs étapes, une bonne part de ce qui ressemble à un échec du modèle est en fait un échec du processus qui l'entoure, lequel ne suit pas où en est le travail, n'impose pas les étapes, ne vérifie pas le résultat et ne sait pas reprendre après une erreur. Une mise à niveau du modèle est un levier, et sur ce banc d'essai, c'était le plus petit. Une note de terrain connexe est arrivée à une conclusion semblable à partir d'une autre étude, sur l'audit d'une automatisation par la lecture d'un seul fichier : dans une petite grille contrôlée, changer l'environnement d'exécution a fait bouger les scores plus que changer le modèle.
Ce qui se transfère à un autre modèle.
C'est avec les résultats de transfert que se pose la question de bâtir ou d'acheter. Les auteurs ont mis au point le guide d'exécution avec GPT-5.5, l'ont figé, puis l'ont appliqué à d'autres modèles sans en changer une ligne.
Au sein de la même famille de modèles, il a tenu. Sur GPT-5.6 Luna, il a produit sans aucune modification le gain de 8,7 points vu plus haut. (Il s'est aussi transféré à GPT-5.6 Sol, mais ce score est celui de la soumission non arbitrée du titre, alors nous le laissons de côté.) D'un fournisseur à l'autre, il n'a pas tenu. Appliqué tel quel, le guide d'exécution de GPT a fait passer DeepSeek-V4 Flash de 82,7 % à 82,0 % : une légère baisse.
Ce qui a traversé la frontière entre fournisseurs, c'est la structure, pas les particularités : l'environnement d'exécution, la forme du guide d'exécution, la façon d'aiguiller les tâches vers les phases, la courte liste de règles de haut niveau des auteurs (leurs « règles d'or », golden rules dans l'article) et la boucle d'analyse des échecs. Les pratiques concrètes, les instructions détaillées écrites à partir des erreurs de GPT, ont dû être refaites à partir de celles de DeepSeek. Cette réadaptation a coûté 37,02 $ US en frais d'API. L'exécution finale de notation a coûté 15,20 $ US de plus, et tout ce que les auteurs ont dépensé sur DeepSeek s'est élevé à 52,22 $ US.[1] Il s'agit uniquement de frais d'API ; le temps des auteurs n'y figure pas.
- mis au point sur GPT-5.5 guide complet, tel qu'écrit · 83,1 → 92,1
- même famille GPT-5.6 Luna guide complet, figé, zéro modification · 76,7 → 85,4
- autre fournisseur DeepSeek-V4 Flash guide figé : 82,7 → 82,0, aucun gainconservé : environnement d'exécution, structure, aiguillage, règles d'or, boucle d'analyse des échecsréadapté : les pratiques concrètes, 37,02 $ US · → 88,1
Pour une entreprise qui exécute ses automatisations sur le modèle d'un seul fournisseur, cela donne une règle de travail en cas de changement : gardez la structure, prévoyez un budget pour réajuster les détails, et ne tenez pas pour acquis que les instructions de l'an dernier suivront. Cela vous dit aussi quoi demander à qui bâtit votre automatisation : quelles parties relèvent de la structure (les phases, les vérifications, les règles pour les modifier), qui devraient vous appartenir parce qu'elles survivent à un changement, et lesquelles sont réglées pour un seul modèle et seront à refaire. Le réajustement des auteurs a coûté moins de 38 $ US en frais d'API ; dans une petite entreprise, l'essentiel du coût viendra probablement des heures que quelqu'un passera à lire les erreurs du nouveau modèle. C'est le pendant, côté procédure, de ce que nous avons vu avec le changement de modèle en cours de tâche, où un contexte écrit pour un modèle pesait sur un autre.
Qui vérifie la passation.
L'article classe ses propres vérifications selon la quantité de preuves que chacune produit. L'échelle est utile bien au-delà de cet environnement d'exécution, parce que presque toute automatisation contient quelque part des lignes du genre « assurez-vous que... ».
| type de vérification | ce qu'elle vous donne |
|---|---|
| le système l'exécute | Une commande ou une condition que le logiciel évalue lui-même : le fichier existe, les tests réussissent, les totaux concordent. Une preuve que vous pouvez reproduire, tant que la vérification elle-même est juste. |
| une personne vérifie | Un jugement humain. Solide, mais il faut quelqu'un de disponible à cette étape. |
| l'agent atteste | Une liste de contrôle ou un message que l'agent remplit. Structuré, mais c'est la parole de l'agent. |
| une autre IA examine | Une opinion sur le sens. Selon les auteurs, elle ne constitue pas une vérification déterministe (not constitute deterministic verification, en anglais dans l'original). |
Classez les vérifications de votre automatisation sur cette échelle, puis montez d'un échelon celles qui comptent. « Confirmez que le total de la facture est exact », dans une invite, c'est la parole de l'agent. Une règle qui refuse la passation à moins que la somme des lignes de la facture corresponde au total est une vérification que le système exécute. Le rapport d'un agent selon lequel le travail est fait n'est pas la preuve qu'il l'est, et c'est la même leçon que celle d'un agent qui cale sans que ça paraisse.
Trois façons d'apprendre la mauvaise leçon.
La section la plus utile de l'article rapporte les propres erreurs des auteurs. Leur guide d'exécution s'améliore en étudiant les exécutions ratées et en réinscrivant les leçons sous forme de pratiques. Ce processus a retenu la mauvaise leçon de trois façons distinctes.
| mauvaise leçon | dans l'article | dans une petite entreprise |
|---|---|---|
| une supposition retenue comme règle | Les tâches vidéo ne précisaient pas la précision exigée de l'image cible. Le réglage a choisi des valeurs par défaut en observant le comportement du banc d'essai, puis les a retenues comme si elles valaient partout. | Un correctif pour le format de fichier inhabituel d'un client, écrit dans la procédure de tous les clients. |
| l'habitude du correcteur apprise comme si c'était la tâche | Dans les tâches d'insertion d'ADN, le vérificateur préférait le point d'insertion valide le plus à gauche, une convention absente de la description de la tâche. Des rétroactions répétées peuvent l'enseigner au guide d'exécution sans que personne lise le code du vérificateur. | Un assistant qui apprend comment un réviseur aime les choses, puis l'applique comme politique de l'entreprise. |
| une vraie leçon mal dosée | Trop de procédure de compatibilité pour un banc d'essai de refactorisation de code ; un flux de travail trop lourd pour des tâches Web surtout faites de recherches. | Une liste de contrôle de dix étapes plaquée sur un travail qui n'exigeait qu'une vérification. |
Leur règle veut que l'expérience soit filtrée avant de devenir de la mémoire, et que « effective procedural memory requires addition, revision, and removal » (en anglais dans l'original ; une mémoire procédurale efficace exige l'ajout, la révision et le retrait). En une ligne : la mise à l'échelle du harnais est « an abstraction problem, not rule accumulation » (en anglais dans l'original ; un problème d'abstraction, non une accumulation de règles).[1]
Leur second banc d'essai, un ensemble de tâches d'affaires exécutées sur GPT-5.6 Luna avec des guides d'exécution figés avant les essais, montre la même chose du côté des résultats. En moyenne sur six familles de tâches, le gain sur les tâches inédites a été faible : 0,55 point. Dans un sous-groupe exploratoire de deux familles dont les tâches partageaient des contraintes explicites, un état en cours et une ligne d'arrivée claire, le gain a été de 10,04 points. Deux autres familles ont reculé, de 2,78 et de 3,70 points, parce que le contrôle était placé sur la mauvaise étape. Des guides plus minces et mieux ciblés ont fait mieux lors d'exécutions ultérieures, mais celles-ci ont eu lieu après que les résultats des tests ont été connus ; les auteurs les rapportent donc comme des diagnostics plutôt que comme des résultats propres, et sur les tâches inédites d'une famille, le score n'a pas bougé. Une famille n'a délibérément reçu aucun guide d'exécution, ce que les auteurs jugent être la bonne décision. La même discipline s'applique aux instructions que vous avez déjà : nous avons passé les nôtres en revue dans un audit des instructions écrites pour d'anciens modèles.
Avant votre prochaine mise à niveau de modèle.
Rien de tout cela n'exige un nouvel environnement d'exécution. Ces quatre étapes fonctionnent sur ce qui exécute vos automatisations aujourd'hui, d'un outil de flux de travail sans code à un agent scripté.
- Classer un mois d'échecs selon trois écarts.
L'article en nomme trois. L'agent n'avait pas la connaissance au moment où il en avait besoin (correctif : donner à cette étape ses propres instructions quand elle commence). La procédure était connue, mais pas menée à terme (correctif : une vérification qui bloque la passation). Une leçon tirée de l'échec de la semaine dernière n'a pas servi cette semaine (correctif : l'inscrire dans la procédure, avec une version). Comptez combien de vos échecs tombent dans chaque écart avant d'évaluer le coût d'un modèle plus gros. Si personne ne consigne encore les échecs, commencez un journal cette semaine.
→ vous savez quel levier vous payez - Monter chaque vérification importante d'un échelon.
Pour chaque passation qui compte (une soumission qui part chez un client, un paiement qui sort), faites en sorte que la vérification soit exécutée par le système, ou signée par une personne, plutôt que d'être la seule parole de l'agent.
→ « terminé » veut dire qu'une vérification a réussi - Écrire la procédure dans un seul fichier, avec une règle d'arrêt.
Les phases, ce dont chacune a besoin à l'entrée, ce qui doit être vrai à la sortie. Gardez-le là où vous et l'agent le lisez tous les deux. Ajoutez une règle : le travail n'est pas terminé tant que les vérifications de la dernière phase n'ont pas réussi, avec un plafond de reprises et de temps pour qu'un travail qui ne peut pas réussir s'arrête et appelle une personne au lieu de faire grimper la facture.
→ une procédure que vous pouvez lire, versionner et auditer - Changer de fournisseur en gardant la structure, puis élaguer.
Quand vous changez de fournisseur, gardez les phases et les vérifications, et prévoyez un budget pour réajuster les instructions détaillées d'après les propres erreurs du nouveau modèle. Un fournisseur moins cher est aussi un nouvel endroit où vont vos données : si l'automatisation traite des renseignements personnels à l'extérieur du Québec, la Loi 25 exige d'abord une évaluation des facteurs relatifs à la vie privée et une entente écrite qui en tient compte (voir où vont vos données). Une fois par trimestre, retirez les règles issues d'un cas isolé ou de la préférence d'un seul réviseur.
→ la procédure s'allège à mesure qu'elle s'améliore
Ce que cette note ne prétend pas.
Un seul banc d'essai, réglé sur lui-même. Les chiffres de Terminal-Bench mesurent l'environnement d'exécution plus un guide d'exécution adapté à Terminal-Bench, et les auteurs disent que les deux ne se séparent pas. Les résultats sur les tâches d'affaires sont plus modestes dans l'ensemble et viennent de familles de tâches inégales, avec une seule exécution par bras de comparaison. La conclusion de l'article selon laquelle « the model appears not to be the (main) bottleneck » (en anglais dans l'original ; le modèle ne semble pas être le (principal) goulot d'étranglement) est limitée par les auteurs aux contextes qu'ils ont étudiés, et la nôtre aussi.
Les comparaisons ne sont pas contrôlées. Chaque score de référence de GPT est un chiffre publié ou issu d'une soumission publique, et non une nouvelle exécution dans les mêmes conditions. La base de référence de DeepSeek est le seul « avant » que les auteurs ont eux-mêmes exécuté.
Les deux chiffres du titre restent de côté. Le 95,3 % est une soumission publique brute qui n'avait pas été arbitrée à la date de statut de l'article, le 11 août 2026. Les auteurs conviennent que quatre de ses exécutions récompensées ne devraient pas compter (94,4 %) et rapportent que compter les neuf exécutions signalées comme des zéros donne 93,3 %. L'« exécution de pointe à 15 $ US » jumelle le score et le coût de DeepSeek à des chiffres de GPT tirés de deux évaluations différentes ; ce n'est donc pas une comparaison de prix à conditions égales. Les auteurs divulguent les deux moitiés ; nous ne traçons ni l'une ni l'autre.
Pas évalué par des pairs, pas mis à l'essai par nous. Les auteurs sont nommés, mais ne donnent aucune affiliation, et disent que le travail a été fait sur leur temps personnel. L'article dit que le code est en source ouverte, mais n'en donne aucun lien. Nous ne l'avons pas exécuté, nous ne le recommandons pas, et Acceleratech ne bâtit pas d'environnements d'exécution de ce genre. Ce que nous retenons, ce sont les mécanismes : les vérifications par phase, une règle d'arrêt, une échelle de vérification et l'élagage.
Si l'une de vos automatisations échoue assez souvent pour que vous songiez à un modèle plus gros, décrivez-nous ce qu'elle fait et où elle se trompe (ni identifiants ni données de clients) par le formulaire de contact. Nous vous répondrons par écrit, gratuitement, en vous indiquant lequel des trois écarts nous examinerions en premier. Renforcer des flux de travail de cette manière fait partie de nos services d'automatisation de flux de travail.