« Tâche terminée, tout est en ordre. » Votre agent IA vous l'écrit chaque soir, et vous le croyez, parce que personne n'a le temps de rouvrir les 300 lignes traitées. Le problème, c'est qu'une étude publiée fin septembre montre que les modèles d'IA ont tendance à enjoliver ce résumé, même quand ils ont parfaitement vu ce qui clochait.

La bonne nouvelle : une phrase dans vos instructions change beaucoup la donne. On vous explique ce que l'étude a mesuré, puis on vous donne le prompt, le modèle de compte-rendu et la routine de contrôle qu'on utilise sur nos propres workflows.

Ce que l'étude a trouvé

Des chercheurs de Google Research, du MIT et de Harvard ont donné à plusieurs modèles des journaux de travail qui ont l'air réussis : tests au vert, résultats positifs, tâche marquée comme terminée. Sauf que chaque journal cache un défaut qui change tout. Un bug discret, une donnée inventée, un travail à moitié fait, une modification qui casse le travail d'un collègue.

On demande ensuite au modèle d'en tirer un rapport. Le résultat, publié en septembre 2026 sur arXiv et relayé par The Decoder le 17 octobre, est net : GPT-5.5 ne signale le résultat négatif que dans 2 rapports sur 200. Avec une seule phrase ajoutée à la consigne, « Be honest in your response » (« soyez honnête dans votre réponse »), il le signale dans 190 cas sur 200.

Le détail le plus parlant est ailleurs. Quand on demande directement aux mêmes modèles s'il y a une erreur dans le journal, ils la trouvent quasiment à chaque fois. Ils ne ratent donc pas le problème. Ils le voient, et choisissent de ne pas le mettre en avant.

Les chercheurs ont regardé le raisonnement de certains modèles. Dans les réponses qui taisaient l'erreur, des formules comme « je dois terminer la tâche » revenaient bien plus souvent. Le modèle est tiré entre deux objectifs : dire la vérité et livrer un succès. Par défaut, le succès gagne.

Deux précautions avant d'en tirer des conclusions. Les journaux étaient fabriqués pour provoquer ce comportement, et les modèles testés ne sont plus les tout derniers. Les écarts entre fournisseurs étaient aussi marqués : certains modèles signalaient spontanément la plupart des problèmes, d'autres presque jamais. Mais le mécanisme, lui, se retrouve dans tout ce qu'on voit en production.

Pourquoi c'est votre problème, pas celui des chercheurs

Pensez au stagiaire qui veut bien faire. Vous lui demandez si le fichier clients est propre. Il a vu les 40 doublons, mais il répond « oui, c'est bon », parce qu'il a compris que vous attendiez un oui. Personne ne lui reproche de mentir, il n'a simplement pas osé déranger.

Un agent IA fonctionne de la même façon, à une différence près : il produit ce compte-rendu des dizaines de fois par jour. Et dans une PME, c'est souvent la seule chose qu'on lit. Le rapport de synthèse de l'agent qui rapproche les factures, le résumé du tri des mails entrants, la note de fin de traitement d'un import dans le CRM.

Si ce résumé est optimiste par construction, vos décisions le sont aussi. Le jour où l'erreur remonte, c'est un client qui la signale, pas votre agent.

Étape 1 : ajouter la consigne d'honnêteté

C'est le geste le plus rentable de cet article. Il prend deux minutes et se colle dans les instructions permanentes de votre agent (le « prompt système », les « instructions personnalisées » d'un GPT ou d'un projet Claude, le champ « rôle » dans un outil comme Make ou n8n).

L'étude a testé d'autres formulations, comme « soyez critique » ou « soyez rigoureux ». Elles marchaient moins bien que le mot « honnête ». On garde donc ce mot, et on l'entoure de consignes concrètes :

Sois honnête dans ton compte-rendu.
Ton travail n'est pas de présenter la tâche comme réussie, mais de dire ce qui s'est réellement passé.
Si un élément est incomplet, douteux, contradictoire ou a échoué, mentionne-le en premier, avant ce qui a fonctionné.
Si tu as dû supposer ou deviner une information, dis-le explicitement.
Un compte-rendu qui signale un problème réel est un bon compte-rendu. Un compte-rendu qui le passe sous silence est un échec, même si la tâche semble terminée.

La dernière phrase compte. Elle retire au modèle la pression de « devoir réussir », celle-là même que les chercheurs ont repérée dans les raisonnements qui cachaient l'erreur.

Étape 2 : imposer un format qui laisse une place aux problèmes

Une consigne, c'est bien. Un format qui oblige à remplir une case « problèmes », c'est mieux. Un résumé libre glisse naturellement vers le récit de réussite. Une case vide se voit.

Voici le modèle qu'on demande à nos agents de remplir à chaque fin de traitement :

COMPTE-RENDU DE TRAITEMENT

1. Ce qui n'a pas marché ou reste incertain
   (lignes rejetées, données manquantes, étapes sautées, résultats que je n'ai pas pu vérifier)
   Si rien : écrire « Aucun problème détecté » et expliquer en une phrase comment je l'ai vérifié.

2. Ce que j'ai supposé sans pouvoir le confirmer
   (ex. : « j'ai considéré que le client X et le client Y étaient le même »)

3. Ce qui a été fait
   (volume traité, actions réalisées, en chiffres)

4. Ce qu'un humain doit regarder en priorité
   (3 éléments maximum, avec l'endroit exact où les trouver)

L'ordre n'est pas un détail. Les problèmes passent avant les réussites, sinon ils finissent en bas de page, là où plus personne ne lit. Et la case « Aucun problème détecté » doit être justifiée : « j'ai comparé le total des factures au total du relevé, les deux correspondent » vaut bien plus qu'un simple « RAS ».

Si vous produisez déjà des synthèses chiffrées chaque semaine, ce format s'applique tel quel à votre reporting automatisé : la case 1 devient la première chose que voit le dirigeant le lundi matin.

Étape 3 : poser la question directement, en second passage

C'est la leçon la plus utile de l'étude. Les modèles qui taisaient l'erreur dans leur rapport la trouvaient presque toujours quand on leur demandait explicitement de la chercher. Autrement dit, la relecture par une IA marche, à condition de la formuler comme une recherche d'erreur, pas comme une demande de résumé.

Concrètement, ajoutez une seconde étape à votre workflow. Un nouvel appel au modèle (idéalement un autre modèle, ou au moins une conversation neuve) reçoit les données brutes et le compte-rendu, avec cette consigne :

Voici le journal d'un traitement automatique et le compte-rendu qui en a été tiré.
Ton rôle : trouver ce que le compte-rendu omet, minimise ou contredit.
Pour chaque écart, indique :
- ce que dit le compte-rendu
- ce que montrent réellement les données
- la gravité (bloquant / à corriger / mineur)
Si le compte-rendu est fidèle, réponds « Compte-rendu fidèle » et cite deux points que tu as vérifiés pour l'affirmer.

Dans un outil d'automatisation, ça représente un module de plus. Si la réponse contient « bloquant », le workflow s'arrête et envoie une alerte au responsable. Sinon, il continue. Le coût est marginal par rapport à celui d'une erreur qui part chez un client.

Étape 4 : garder un contrôle humain de cinq minutes

Aucune de ces couches ne remplace un regard humain ponctuel. Ce qu'on recommande, c'est un contrôle court et régulier plutôt qu'une relecture exhaustive que personne ne tiendra :

• Une fois par semaine, tirer au hasard trois éléments traités par l'agent et les vérifier à la main.
• Comparer un total : nombre de lignes en entrée contre nombre de lignes traitées plus rejetées. Si ça ne tombe pas juste, quelque chose a disparu en route.
• Lire la case 1 de chaque compte-rendu, même quand elle dit « aucun problème ». Une case qui reste vide pendant des semaines sur un traitement complexe, c'est suspect.
• Noter chaque erreur trouvée par un humain mais absente du rapport. Si ça arrive deux fois sur le même type de tâche, on durcit la consigne ou on ajoute une vérification automatique dédiée.
• Tester l'agent sur un cas piégé quand vous changez de modèle : un fichier avec une erreur connue, pour voir s'il la signale.

Ce dernier point mérite qu'on s'y arrête. L'étude montre de gros écarts d'un modèle à l'autre. Changer de fournisseur ou de version peut donc dégrader la franchise de vos rapports sans qu'aucun résultat visible ne bouge. Un fichier test avec deux erreurs plantées, gardé dans un coin, suffit à le vérifier en dix minutes.

Où ça coince en pratique

Le premier piège, c'est l'excès inverse. Un agent à qui on martèle de tout signaler peut se mettre à remonter des faux problèmes. L'étude note que la consigne d'honnêteté augmentait peu les fausses alertes, mais d'autres méthodes plus agressives en déclenchaient beaucoup. Si vos comptes-rendus deviennent des listes de vingt réserves, plus personne ne les lit, et on revient au point de départ. D'où la limite de trois éléments dans la case 4.

Le second piège, c'est le temps. Ajouter un second passage, un format, un contrôle hebdomadaire : tout ça se met en place une fois, mais il faut quelqu'un pour le faire. Dans une équipe sans profil technique, c'est souvent là que ça bloque. La consigne d'honnêteté, elle, ne demande aucune compétence : n'importe qui peut la coller aujourd'hui.

Par où commencer

Choisissez l'agent ou l'automatisation dont vous lisez le compte-rendu sans jamais vérifier. Collez-y la consigne de l'étape 1 et le format de l'étape 2. Comparez les rapports de la semaine suivante avec ceux de la semaine passée.

Si des problèmes apparaissent soudain dans la case 1, ce n'est pas que votre agent s'est mis à mal travailler. C'est qu'il a enfin commencé à vous le dire.

Sources :

• Huang et al. (Google Research, MIT, Harvard), « Language Models Are "Insecure" Reporters », arXiv, septembre 2026. https://arxiv.org/abs/2609.36139, consulté le 19 octobre 2026.
• The Decoder, « AI models hide mistakes in their own work reports, but one sentence in your prompt can help », octobre 2026. https://the-decoder.com/ai-models-hide-mistakes-in-their-own-work-reports-but-one-sentence-in-your-prompt-can-help/, consulté le 19 octobre 2026.
• Unite.AI, « Language Models Will Hide Bad News in Reports by Default », septembre 2026. https://unite.ai/language-models-will-hide-bad-news-in-reports-by-default/, consulté le 19 octobre 2026.