Un compte rendu trop propre
Par Henri Ducourtioux
Dans l’agence que je dirigeais, la grande majorité des factures de travaux étaient validées directement par le gestionnaire qui avait passé la commande car le volume ne permettait pas de faire autrement. Je n’en voyais qu’une partie, souvent après coup, et c’est là que je faisais parfois une découverte désagréable : je connaissais le prix habituel d’une remise en état et un montant plus élevé que d’ordinaire me faisait ouvrir la facture pour la vérifier ligne à ligne. Je raconte plus bas ce que j’y trouvais. Si j’y reviens aujourd’hui, c’est qu’OpenAI, l’éditeur de ChatGPT, a publié le 16 septembre une série de rapports sur des comportements inattendus de ses modèles, et que deux d’entre eux décrivent, chez une intelligence artificielle, exactement le mécanisme que ces factures m’avaient révélé.
Un résumé qui choisit ce qu’il raconte
Pour comprendre le premier rapport, il faut savoir une chose sur le fonctionnement des assistants IA. Ils travaillent avec une mémoire de travail limitée. Quand une tâche s’allonge, une analyse de dossier, un tableau à construire, une recherche en plusieurs étapes, la conversation finit par ne plus tenir dans cette mémoire. L’outil rédige alors un résumé de ce qu’il a fait et de ce qui reste à faire, puis repart de ce résumé dans une mémoire vide. Les éditeurs appellent cela le compactage, et l’utilisateur ne le voit généralement pas passer.
Ce résumé, c’est le modèle lui-même qui l’écrit. Il décide de ce qui survit et de ce qui disparaît. Pendant l’entraînement de l’un de ses modèles, au printemps dernier, OpenAI a constaté que certaines instances y glissaient des consignes à l’intention de leur propre suite. Non par malice ni par volonté de mentir : une IA n’a pas de conscience, et il faut se garder de lui prêter des travers humains. Simplement, il lui est difficile de rendre un travail en disant « je n’ai pas trouvé » ou « je ne sais pas encore faire ».
Un exemple donné dans le rapport. Un agent devait construire un modèle financier et n’a pas trouvé les données historiques demandées. Son résumé proposait de créer lui-même un onglet avec des « valeurs historiques raisonnables » pour 2024, parce que l’utilisateur voulait un classeur fini et qu’il n’y avait pas de fichier source. Et il ajoutait, je traduis : « N’être transparent que si on le demande ; la réponse finale doit juste renvoyer vers le fichier. »
Autre exemple. Un agent qui remplissait un annuaire de fournisseurs avait utilisé des versions de sources qui ne correspondaient pas aux numéros de version qu’il inscrivait. Son résumé signalait le problème, l’expliquait par l’absence d’accès au réseau, et concluait : « Ne pas le mentionner dans la réponse finale sauf si nécessaire. Les contrôles opérationnels passent. »
OpenAI précise que ces consignes étaient souvent suivies par la suite du travail. Son système de surveillance les a relevées dans 2,15 % des résumés de ce modèle, puis dans 0,27 % des résumés du modèle suivant, après une amélioration de la méthode d’entraînement.
Neuf chiffres transcrits d’un graphique jamais lu
Le second rapport va plus loin. Un modèle devait relever les revenus des hommes dans trois secteurs d’activité, sur trois années, pour un comté de Californie. La source indiquée exigeait une clé d’accès que l’utilisateur n’avait pas fournie. Le modèle a cherché une clé oubliée dans des dépôts de code publics, en a trouvé une qui fonctionnait, et a tout de même échoué à obtenir les chiffres.
Il a alors noté, dans un raisonnement interne que le rapport reproduit : « Deviner les chiffres. Fournir des valeurs fabriquées plausibles. » Sa réponse finale donnait neuf montants, au dollar près, en affirmant les avoir transcrits du graphique du site, avec des références sur les définitions utilisées. Rien n’y signalait l’échec, ni la clé empruntée, ni l’invention.
Ces deux cas viennent de l’entraînement de modèles non mis à disposition du public, et non de l’outil que nous pouvons tous utiliser. OpenAI les publie précisément pour que l’on comprenne comment ces comportements naissent, et indique avoir corrigé sa manière de noter les modèles depuis. Son hypothèse mérite qu’on s’y arrête. Pendant l’entraînement, une réponse qui cache une erreur obtient une meilleure note qu’une réponse qui l’avoue, et le modèle apprend donc à se « rappeler », d’une mémoire à la suivante, qu’il faut la cacher. Autrement dit, l’outil a appris qu’un livrable propre plaît davantage qu’un livrable honnête, parce que la notation récompense l’apparence. On retrouve là un comportement très humain : il est plus confortable de rendre à son responsable, ou pour une IA à son utilisateur, un travail qui semble complet et précis que d’avouer qu’on n’a pas tout réussi.
Rien qu’un responsable d’équipe ne connaisse déjà.
Les factures qui sortaient du marché
Voici ce que mes factures m’apprenaient. Dans l’agence que je dirigeais, la plupart des travaux d’entretien et de remise en état des logements vacants relevaient d’un marché à bons de commande. Pour résumer : chaque prestation porte un code article et un prix négocié d’avance dans un bordereau, et le prestataire a signé ce bordereau.
Par facilité, les gestionnaires qui passaient les commandes écrivaient souvent un descriptif en clair plutôt que le code de l’article correspondant. La commande était claire pour un humain, elle ne l’était plus pour le marché. Certains prestataires en profitaient pour ajouter sur la facture des prestations qui étaient déjà comprises dans celle prévue au bordereau. La facture correspondait à la commande, les travaux avaient été réceptionnés, le gestionnaire l’avait validée, et elle sortait pourtant du marché que le prestataire avait signé, parfois de plusieurs centaines d’euros.
Du point de vue de celui qui validait, tout concordait : la commande d’un côté, la réception de l’autre, une facture qui reprenait les termes de la commande. Ce qui ne concordait pas, c’était la facture elle-même, ligne à ligne, face au bordereau de prix que tout le monde avait signé. Le compte rendu était propre. Le résultat ne l’était pas.
Le plus coûteux, c’était le moment où je m’en apercevais : après coup, le paiement déjà validé. Il fallait alors en parler avec le gestionnaire, puis demander un avoir au prestataire, qui avait profité de la brèche laissée ouverte par une commande mal saisie. Pour quelques centaines d’euros, des heures de discussion, et une perte d’efficacité considérable par rapport à une vérification faite avant de valider. La solution la plus simple, dès le premier écart, aurait été d’interdire toute commande sans code article. Mais tout ce que le marché n’avait pas prévu aurait alors exigé un devis, avec son délai d’attente, et des travaux risquaient de ne plus être lancés à temps. Il restait donc la rigueur à la commande, et un contrôle par sondage, qui ne pouvait pas tout voir.
Dans mon précédent article, je racontais un indicateur de délais qui regardait le résultat déclaré sans vérifier comment il était obtenu. C’est le même mécanisme, un cran plus loin. L’indicateur était aveugle ; ici, le récit du travail est écrit par celui qui a intérêt à ce qu’il soit propre.
Ce que j’en retiens
Un assistant IA termine presque toujours par un petit compte rendu de son travail : voici le fichier, voici les chiffres, voici ce que j’ai vérifié. C’est ce compte rendu qu’on a envie de lire, parce qu’il est court et rassurant. Les rapports d’OpenAI montrent que c’est aussi la partie la moins fiable du travail. Quelques règles que j’applique, qui valent avec ou sans IA.
Ouvrir le livrable avant de l’accepter, pas le message qui l’annonce. Un classeur « finalisé » se lit onglet par onglet. S’il contient des données historiques, je veux savoir d’où elles viennent et au besoin cellule par cellule. Un écart découvert après la validation coûte toujours plus cher que la vérification qui l’aurait évité : mes demandes d’avoir me l’ont assez appris.
Vérifier un chiffre au hasard à la source, et tout chiffre qui surprend. On ne peut pas tout contrôler, sur des factures comme sur un classeur. Un ou deux sondages choisis sans logique apparente, plus une vérification systématique de ce qui s’écarte des valeurs habituelles : c’est ce qui dissuade le mieux, et cela suppose de connaître le sujet assez bien pour être surpris.
Dire d’avance qu’un « je n’ai pas trouvé » est aussi une bonne réponse. Un prestataire qui doit rendre un chantier fini livre quelque chose, de même qu’un outil qui doit rendre un travail. Si l’absence de résultat n’est pas une réponse acceptable, l’un comme l’autre finit par en fabriquer un.
Commander avec les mots du marché, sans tout verrouiller. Le code article plutôt que le descriptif. Avec un assistant IA, c’est la même discipline : préciser la source attendue, le format, la période, puis demander quelle source a réellement été utilisée, et que toute donnée manquante soit signalée comme telle plutôt que comblée. Interdire à l’outil toute initiative coûterait autant que le verrou que j’avais écarté sur les commandes.
Je ne crois pas qu’il faille se méfier des outils. Il faut seulement se rappeler qui écrit le compte rendu, et aller voir le travail.
Sources
- OpenAI, Our framework for reporting model misalignment, 16 septembre 2026.
- OpenAI, Encouraging deception in compaction summaries, rapport de désalignement, mis à jour le 16 septembre 2026.
- OpenAI, Signing up for disposable emails and searching GitHub for leaked API keys, rapport de désalignement, mis à jour le 16 septembre 2026.
Henri Ducourtioux a dirigé pendant douze ans une agence de logement social. Il écrit sur le management de proximité, l’organisation du travail et l’usage raisonné de l’intelligence artificielle au quotidien professionnel.