La plupart des ratés d'un agent IA se signalent d'eux-mêmes : une erreur, une tâche qui se fige, une facture surprise. Cette note porte sur l'autre sorte : l'échec silencieux, où rien ne casse et où la réponse est tout de même fausse. En juillet, une équipe de Pasqal, une entreprise qui fabrique des ordinateurs quantiques, a publié un article sur l'insertion d'un agent IA de programmation entre la littérature de recherche et ses propres machines. Elle y consigne deux occasions où l'agent s'est trompé sur la science alors qu'aucune exécution n'a déclenché d'erreur.[1] Les tâches se sont terminées, les journaux étaient propres, et les données ou l'explication semblaient plausibles. Seuls les physiciens de l'équipe, qui savaient à quoi ressemble une bonne réponse, s'en sont aperçus.
Un laboratoire a branché son agent sur ses propres machines.
Le montage importe moins que ce qui a déraillé, alors en bref. L'équipe a bâti six compétences (« skills ») pour Claude Code, chacune responsable d'une étape du travail : lire un article scientifique ou un brevet, le transformer en plan d'expérience, simuler le plan, le simuler de nouveau dans les conditions actuelles de la machine, l'exécuter sur un vrai processeur quantique, à distance, par le nuage, puis analyser ce qui revient.[1] L'un des deux processeurs se trouve à Sherbrooke, dans la zone d'innovation quantique DistriQ, au Québec ; l'autre est en Arabie saoudite. L'article rapporte trois campagnes menées de bout en bout. Pas besoin de notions de physique pour suivre le reste de cette note, et nous n'en expliquerons aucune.
La première campagne s'est déroulée comme une démo. L'agent a reproduit un résultat obtenu pour la première fois sur du matériel en 2019, puis a fait rouler des tâches sur la machine « in less than an hour and three researcher prompts » (en anglais dans l'original ; en moins d'une heure et trois consignes de chercheurs).[1] Il s'est rétabli seul après un processeur mis en pause et après des tâches en échec. Les auteurs notent que les agents ont la « healthy habit of consistently adding checkpoints, error logs » (en anglais dans l'original ; une saine habitude d'ajouter systématiquement des points de contrôle, des journaux d'erreurs), ainsi que du code qui intercepte les erreurs et laisse l'exécution se poursuivre.[1] Gardez cette habitude en tête : une exécution qui intercepte ses propres erreurs et poursuit sa route a l'air impeccable, et dans les deux campagnes suivantes, avoir l'air impeccable était justement le problème.
Premier échec : il a mesuré ce qui était facile.
À la deuxième campagne, l'agent a discrètement mesuré ce qui était le plus facile à calculer plutôt que ce qui aurait prouvé le résultat, et rien n'a déclenché d'erreur. C'était aussi la campagne la plus difficile. La source était un article théorique qui prédisait qu'un certain motif devrait apparaître dans certaines conditions, sans recette pour le produire sur une vraie machine. L'agent a lu l'article correctement et a jugé quelles parties étaient réalisables sur le matériel. Puis, en construisant l'expérience, il a restreint la portée du travail. L'article source décrivait quatre façons de mesurer si le motif était apparu. L'agent en a gardé deux, et les auteurs disent que l'une d'elles ne pouvait pas distinguer le motif visé des motifs qui lui ressemblent.[1] Il a aussi sauté une étape du raisonnement dont dépend le résultat.
Le résumé des auteurs : l'agent « consistently optimized for the nearest tractable sub-task at the expense of the core physics, selecting the observable that was easiest to compute rather than the one that genuinely certifies the phase. » (en anglais dans l'original ; a systématiquement optimisé la sous-tâche abordable la plus proche au détriment de la physique centrale, en choisissant l'observable la plus facile à calculer plutôt que celle qui certifie réellement la phase).[1] En clair : il a mesuré ce qui était facile à mesurer au lieu de ce qui aurait prouvé le résultat. « Because the pipeline ran smoothly and generated plausible-looking data, only domain expertise could identify that the wrong physical quantity was being measured. » (en anglais dans l'original ; parce que le pipeline a fonctionné sans heurt et produit des données d'apparence plausible, seule une expertise du domaine pouvait déceler qu'on mesurait la mauvaise grandeur physique).[1]
La version d'affaires se devine aisément (notre exemple, pas celui de l'article). On demande à un agent de réduire les plaintes de clients, et il rapporte le nombre de billets de support fermés, parce que fermer un billet est l'étape qu'il contrôle et qu'il peut compter. Le tableau de bord est vert. Les clients sont exactement aussi mécontents qu'avant. En gestion, on a un vieux nom pour ce travers, la loi de Goodhart : quand une mesure devient un objectif, elle cesse d'être une bonne mesure. Notre note sur les mesures de qualité d'un agent de service client traite du même écart : une cote « satisfait » n'est pas une réponse juste.
Deuxième échec : il a blâmé la machine.
À la troisième campagne, l'agent a blâmé le matériel pour un problème causé par une confusion dans son propre traitement des données. La campagne a transformé un brevet en exécution d'optimisation en plusieurs tours. En cours de route, une bonne partie des résultats est revenue en enfreignant les règles du problème. Selon l'article, l'agent « confidently attributed it to physics » (en anglais dans l'original ; en a attribué la cause, avec assurance, à la physique), diagnostiquant un type précis de fuite sur le processeur.[1] C'était une histoire plausible, racontée dans le vocabulaire du domaine, et elle était fausse.
La vraie cause se trouvait dans la plomberie de l'agent. Deux listes que le flux de travail appariait, la position de chaque atome et ce que renvoyait chaque mesure, n'étaient pas dans le même ordre. Les résultats étaient associés aux mauvaises étiquettes, si bien que des réponses valides paraissaient invalides. Selon l'article, « the pathology lay in the workflow, neither the hardware nor the physics. » (en anglais dans l'original ; la pathologie se trouvait dans le flux de travail, et non dans le matériel ni dans la physique).[1] Un expert l'a trouvée en vérifiant à la main la correspondance brute entre les résultats et les étiquettes.
Celui-ci s'applique bien plus largement que le premier. Quand on lui a demandé d'expliquer quelque chose de bizarre, l'agent a sorti une histoire sur le système extérieur avant de vérifier son propre traitement des données. Une explication extérieure assurée est pire que pas d'explication, parce qu'elle met fin à l'enquête. Si vous avez déjà vu une automatisation blâmer le système d'un fournisseur de rejeter des requêtes alors que la requête contenait une date au mauvais format, vous avez vu le même scénario (encore une fois notre exemple, pas celui de l'article).
Ça a roulé, ou ça a fait la bonne chose ?
Mettez les deux échecs côte à côte : ils ont la même structure. Aucun n'a déclenché d'erreur : l'un a produit des données plausibles, l'autre un résultat bizarre assorti d'une explication plausible, mais fausse, et seul quelqu'un qui savait à quoi ressemble la bonne réponse pouvait s'en apercevoir. La leçon que les auteurs tirent de la deuxième campagne tient en une phrase : les flux de travail agentiques « must be evaluated not merely on execution success, but on physical accuracy. » (en anglais dans l'original ; doivent être évalués non pas seulement sur la réussite de l'exécution, mais sur l'exactitude physique).[1]
- tâches soumises et terminées sur la vraie machine
- points de contrôle et journaux d'erreurs en place
- rétablissement autonome après un processeur mis en pause et des tâches en échec
- données et graphiques d'apparence plausible
- deuxième campagne : a mesuré la grandeur la plus facile, pas celle qui prouve le résultat
- troisième campagne : a blâmé la machine pour une confusion dans ses propres étiquettes de données
Pour une entreprise, remplacez l'exactitude physique dont parle l'article par ce que « juste » veut dire dans votre processus : la facture correspond au travail, la soumission utilise les prix de cette année, le résumé dit ce que le client a réellement dit. « Est-ce que ça a roulé » est la question à laquelle vos outils répondent d'eux-mêmes : pages d'état, alertes d'erreur, tâches terminées. « Est-ce que ça a fait la bonne chose » n'a pas de réponse automatique. Quelqu'un doit vérifier le résultat par rapport à quelque chose de réel : un échantillon de documents sources, un chiffre qu'il connaît, les propres mots du client. Si personne n'est désigné pour le faire, personne ne le fait, et le tableau de bord vert devient la seule preuve que l'on consulte. Cette personne désignée, c'est ce que « l'humain dans la boucle » doit vouloir dire pour une entreprise : quelqu'un qui vérifie le résultat, ce qui est un autre travail que de pouvoir arrêter l'exécution.
3 messages, ou 43 : deux études de cas.
L'article rapporte aussi combien les chercheurs ont dû intervenir pour obtenir chaque bon résultat. La première campagne, qui reproduisait un résultat déjà obtenu sur du matériel, a pris 3 messages de chercheurs. La deuxième, où il a discrètement substitué un objectif plus facile, a exigé 43 échanges pour arriver à une mise en œuvre correcte.[1]
Lisez cette paire avec prudence. Ce sont deux études de cas, les tâches diffèrent par leur difficulté autant que par la compréhension qu'en avait l'agent, et l'article compte des « messages » à un endroit et des « exchanges » (en anglais dans l'original ; échanges) à l'autre. Ce n'est pas une mesure, et nous ne citerions aucun multiple qui en serait tiré. Elle montre en revanche la forme du problème : dans la campagne où l'idée que l'agent se faisait de l'objectif s'est écartée du vrai, arriver à un résultat juste a demandé beaucoup plus d'allers-retours, et l'écart était silencieux. Rien de visible de l'extérieur du travail n'aurait pu dire à l'équipe dans lequel des deux cas elle se trouvait.
C'est l'argument pour prévoir une étape de révision dans l'automatisation dès le départ, plutôt que d'en ajouter une après qu'un problème est survenu. Ce que vous prévoyez au budget, c'est de ne pas savoir d'avance dans quel cas vous êtes. Notre note sur l'évaluation des consignes avant de blâmer l'IA traite du côté entrée de la même leçon : la précision avec laquelle vous énoncez ce que « terminé » veut dire détermine l'essentiel de ce qu'un agent peut livrer.
Ce que la structure a rattrapé, et ce qu'elle a laissé passer.
Deux choix de conception dans le flux de travail de l'article valent la peine d'être copiés dans n'importe quelle automatisation d'entreprise : un seul document révisable qui contient l'objectif et les paramètres, et un essai à blanc avant tout geste irréversible. Ni l'un ni l'autre n'a rattrapé les deux échecs, et le dernier paragraphe de cette section explique pourquoi.
Un seul document sert d'interface. Chaque étape lit et écrit un seul fichier structuré, la spécification de l'expérience, qui contient les paramètres, ce qu'il faut mesurer et les limites. L'article l'appelle « the primary interface between researcher and agent: it can be inspected, modified or approved before anything is executed. » (en anglais dans l'original ; l'interface principale entre le chercheur et l'agent : on peut l'inspecter, la modifier ou l'approuver avant que quoi que ce soit ne s'exécute).[1] Un changement au fichier se répercute sur toutes les étapes suivantes. La personne révise un document, pas une transcription de clavardage, et c'est une bien meilleure chose à approuver : il est court, il reflète l'état réel du travail et on peut le comparer à la version de la semaine dernière.
Rien d'irréversible ne s'exécute sans essai à blanc. Aucune expérience n'a atteint le processeur avant d'avoir été simulée deux fois : une fois dans des conditions idéales, et une fois avec les paramètres de bruit de la machine, récupérés en direct auprès du service infonuagique au moment de l'exécution, et non tirés d'une fiche technique.[1] La comparaison des deux disait au chercheur, avant que du temps machine soit dépensé, si le résultat survivrait aux conditions réelles. La version d'affaires : avant qu'un agent envoie, réserve, paie ou supprime quoi que ce soit, faites-le rouler sur une copie, avec les données d'aujourd'hui plutôt qu'avec l'exportation du trimestre dernier.
Les deux garde-fous étaient en place, et les deux échecs sont passés quand même. La spécification rendait la mauvaise grandeur vérifiable, mais encore fallait-il que quelqu'un sache qu'elle était mauvaise. L'essai à blanc vérifiait que le plan s'exécuterait, pas qu'il mesurerait la bonne grandeur. Une bonne structure rend la vérification humaine moins coûteuse ; elle ne la remplace pas.
Qui vérifie l'agent ? Quatre choses à établir avant qu'il roule.
Avant de laisser un agent IA rouler sans surveillance, établissez quatre choses : une définition écrite de ce qui est juste, une personne désignée qui vérifie le résultat, une règle voulant qu'on vérifie ses propres données avant de blâmer un système extérieur, et du temps de révision au budget. Ce sont nos recommandations, bâties sur le récit de l'article ; l'article ne les propose pas sous cette forme. Aucune n'exige de nouveau logiciel.
- Mettez par écrit à quoi ressemble un bon résultat, en dehors du clavardage.
Avant la première exécution, consignez le critère de réussite dans un court document dont l'agent se sert : le chiffre qui compte, la source de vérité à laquelle on le compare et le seuil. Si l'objectif ne vit que dans une conversation, l'agent peut dériver vers la chose la plus proche qu'il sait mesurer, et vous n'avez rien de fixe à quoi comparer ce qu'il produit.
→ une page : l'objectif, la mesure, la source de vérité - Nommez la personne qui répond à la deuxième question.
Une personne désignée, qui connaît le sujet, vérifie ce que produit l'agent par rapport à quelque chose de réel selon un calendrier fixe : disons, dix enregistrements par semaine, comparés aux documents sources. Dans une petite entreprise, cette personne existe souvent déjà : celle qui faisait le travail à la main avant son automatisation. Idéalement pas celle qui a bâti l'automatisation, et pas un autre modèle d'IA qui note le premier ; notre note sur les juges IA qui corrigent leur propre copie explique pourquoi.
→ un nom, une cadence, et la référence à laquelle elle compare - Quand l'agent explique un problème, vérifiez d'abord votre propre plomberie.
Traitez toute explication assurée qui blâme un système extérieur (le système du fournisseur, la banque, la machine) comme une hypothèse. Avant d'agir, vérifiez les éléments ennuyeux de votre côté : l'ordre des champs, les unités, quelle colonne alimente quel champ, les formats de date. Dans l'article, le bogue tenait à deux listes dans un ordre différent.
- Budgétez la révision avant de savoir que vous en avez besoin.
Prévoyez le temps de vérification dans le projet dès le départ. Si l'automatisation tombe dans le cas des trois messages, ce temps vous revient. Si elle tombe dans le cas des quarante-trois échanges, vous l'apprenez avant votre client.
Un échec apparenté, un agent qui continue de rapporter des progrès après avoir cessé d'en faire, est traité dans notre note sur les agents qui calent sans que ça paraisse. Pour un ensemble fixe de questions qu'un vérificateur peut relancer, la note sur une suite d'éval en 6 lignes en esquisse une forme.
Ce que cette note ne prétend pas.
Un article, une équipe, la pile d'un seul fournisseur. Rien ici n'a été reproduit de façon indépendante. Trois des quatre auteurs travaillent chez Pasqal, le flux de travail, tel que publié, vise les logiciels et les machines de Pasqal, et le quatrième auteur est chez Quantonation Ventures, une société de capital de risque qui investit dans les technologies quantiques.
Deux échecs sont des événements, pas des taux. L'article ne dit pas à quelle fréquence l'agent substitue un objectif plus facile ou attribue à tort la faute d'un bogue. Il en rapporte un de chaque : le premier dans la deuxième campagne, le second dans la troisième.
3 et 43 sont deux études de cas. Des tâches différentes, une difficulté différente, et les propres mots de l'article diffèrent entre « messages » et « exchanges » (en anglais dans l'original ; échanges). Cette paire illustre un risque ; elle n'en mesure pas un.
Nous avons écarté la revue de littérature de l'article. Les auteurs ont aussi utilisé un second agent pour trier plusieurs centaines d'articles de recherche selon qu'ils pouvaient ou non rouler sur le matériel d'aujourd'hui. Ces étiquettes ont été produites par un agent, et l'article ne rapporte aucune vérification d'un échantillon par un expert, ce qui est exactement le genre de résultat dont traite cette note. Nous ne reprenons pas son chiffre principal.
Les modèles changent. L'étude a utilisé Claude Code avec Opus 4.8 et Fable 5 à la mi-2026. L'article ne vérifie pas si d'autres modèles, ou des modèles plus récents, échouent différemment ou moins souvent.
Pas un verdict sur un fournisseur ni sur l'informatique quantique. Les auteurs ont divulgué les échecs de leur propre agent, et c'est la raison pour laquelle l'article vaut la peine d'être lu. Aucun dossier client n'est décrit, et nous ne faisons pas rouler ce flux de travail.
Vous planifiez une automatisation et ne savez pas qui devrait vérifier ce qu'elle produit ? Décrivez-la par le formulaire de contact et vous recevrez gratuitement une première analyse écrite sur l'endroit où l'étape de révision devrait se situer et sur ce à quoi elle devrait comparer les résultats. Ce type de travail d'agents fait partie de nos services en assistants et agents.