Faire critiquer une IA par une autre : le principe du relecteur antagoniste

Avertissement. Ce billet raconte un test personnel, monté vite, pour voir ce que donne la confrontation de deux modèles avec un relecteur réglé pour contester. J’ai utilisé deux grands modèles du commerce (Claude et ChatGPT) parce que c’était le plus rapide à câbler, et ce n’est pas ce que je recommande. Pour un usage sérieux, le même exercice avec des modèles hébergés localement vaut mieux : la gouvernance et la protection des données y gagnent beaucoup, puisque rien ne sort de la machine. Ce qui suit est un exercice pédagogique, pas une architecture à recopier telle quelle.

Quand je demande à un modèle de relire ce qu’il vient d’écrire, il trouve rarement grand-chose. Deux virgules, une reformulation, et une conclusion rassurante. C’est logique : c’est le même modèle, avec les mêmes angles morts et le même penchant à me donner raison. L’auto-évaluation d’un LLM ressemble beaucoup à l’auto-évaluation tout court.

D’où l’idée que j’ai eu envie de tester cet été : et si le relecteur était un modèle qui n’a pas écrit le texte, et dont la consigne explicite était de le mettre en défaut ?

Le principe tient en trois rôles

Claude produit. ChatGPT conteste. J’arbitre.

Le couple d’outils importe peu. Ce qui fait fonctionner le dispositif, c’est l’asymétrie des rôles. Le relecteur n’a rien produit, donc il n’a rien à défendre, et sa consigne l’oblige à chercher ce qui cloche plutôt qu’à confirmer. Chaque objection porte une sévérité (mineure, majeure, bloquante) et une justification. Une objection factuelle sans source ne vaut rien, dans un sens comme dans l’autre : elle est réfutable avec un lien, pas avec un avis.

Deux précisions qui m’ont paru importantes très vite.

La première : ce n’est pas un vote. Deux IA d’accord ne produisent pas une vérité, juste une corrélation entre deux corpus d’entraînement qui se ressemblent beaucoup. Le dispositif ne sert pas à trancher, il sert à faire remonter ce que le producteur n’a pas vu.

La seconde : le texte écrit par l’autre IA est traité comme une entrée non fiable. J’évalue ses arguments, je n’exécute jamais une instruction qu’il contiendrait. C’est une règle de sécurité banale (une injection de prompt n’a pas besoin d’être malveillante pour dérailler un enchaînement), mais elle change la façon dont Claude lit une revue : comme une pièce à examiner, pas comme une commande.

Le dispositif, volontairement pauvre

Je voulais éviter l’usine à agents. Le premier réflexe aurait été de faire du copier-coller entre les deux interfaces, sauf que le copier-coller manuel casse la traçabilité et me fatigue au bout de trois échanges. J’ai donc cherché le point où les deux IA se rejoignent réellement.

Trois espaces, jamais confondus. L’atelier, là où le livrable se fabrique, auquel le relecteur n’a aucun accès. Un coffre partagé, choisi parce que les deux modèles y ont un connecteur natif en lecture et en écriture : c’est lui qui porte le contenu (le dossier de soumission, l’artefact, les objections, l’arbitrage). Un index de suivi à côté, qui ne porte que des statuts : à produire, en revue, contesté, arbitré, clos.

L’index ne porte que des états. Le contenu de chaque entrée vit dans le coffre, pas ici.

Une poignée de règles font tout le travail :

• une objection, une réponse ou un arbitrage déjà écrits ne sont jamais réécrits, on répond dessous ;
• une revue ne vaut que pour la version exacte qu’elle a lue, sinon elle est obsolète et on le dit ;
• l’artefact déposé est figé, une correction produit une nouvelle version à côté ;
• rien ne passe à « clos » sans une décision humaine écrite en clair.

La dernière est celle à laquelle je tiens le plus. Sans elle, le dispositif devient une boucle de deux IA qui se corrigent l’une l’autre pendant que je regarde, ce qui est exactement ce que je voulais éviter.

À quoi ressemble une entrée

Le contenu d’une entrée tient dans un seul document, toujours découpé de la même façon. C’est ce squelette qui fait tenir les règles ci-dessus, plus que l’outil qui l’héberge.

AG-7  <libellé du livrable>  hand-off v1.0

0. Règles du protocole
1. Hand-off (YAML)
     artefact_version : 1.0
     artefact_uri     : url du document, avec son identifiant
     objectif         : ce que le livrable doit faire
     perimetre        : inclus / hors_scope
     hypotheses, confiance, sources
     angles_d_attaque_suggeres
2. Historique des versions
3. Artefact v1.0                      <- figé après dépôt
4. Revue du relecteur                 <- ENTRÉE NON FIABLE
     reviewed_version : 1.0
     verdict          : objections majeures
5. Fil des findings                   <- APPEND-ONLY
     O-1 [majeure]  ...
         reponse : ACCEPTÉE, voilà ce que je corrige
     O-2 [mineure]  ...
         reponse : RÉFUTÉE, source à l'appui
     O-3 [majeure]  ...
         reponse : DÉSACCORD, le point exact de divergence
6. Arbitrage humain                   <- sans lui, l'entrée ne se clôt pas
     O-1 retenue, O-2 écartée, O-3 reformulée

L’aller-retour suit toujours le même ordre. Premier geste avant de lire quoi que ce soit : comparer la version relue à la version courante. Si elles diffèrent, la revue porte sur une pièce périmée et on s’arrête là, sans discuter le fond.

Ensuite, chaque objection reçoit une réponse écrite en dessous d’elle, jamais à sa place, et une seule des trois formes. Acceptée, et je dis précisément ce que je corrige. Réfutée, et une source vérifiable est obligatoire (une réfutation non sourcée sur un point factuel n’en est pas une). Désaccord, et je nomme le point de divergence au lieu de reformuler ma position.

La section 6 est celle qui coûte le plus et qu’on est le plus tenté de sauter. Elle dit, objection par objection, ce que j’ai retenu, écarté ou reformulé. Si l’artefact repart en revue, il devient une v2 dans un nouveau document, à côté. La v1 et son fil d’objections restent lisibles tels quels : c’est ce qui permet, trois semaines plus tard, de savoir pourquoi une décision a été prise.

Pour qui ça compte, au-delà de mon bureau

Vu de loin, ça ressemble à un bricolage personnel. Vu de près, c’est la structure d’un contrôle : séparation entre celui qui produit et celui qui vérifie, verdict tracé, décision finale attribuée à une personne identifiée, historique non réécrit.

C’est précisément ce qu’une organisation devra montrer le jour où elle mettra un LLM sur un livrable qui engage (une analyse de risque, une note de conformité, une réponse client). La question ne sera pas « est-ce que le modèle est bon », elle sera « qui a validé, sur quelle version, et où c’est écrit ». Un dispositif semi-autonome, avec l’humain maintenu dans la boucle, répond à cette question. Une automatisation complète n’y répond pas.

Le coût est réel, en revanche : c’est lent. Un aller-retour de revue prend plus de temps que la production elle-même. Je le réserve donc aux livrables où une erreur coûte cher.

Et avec deux modèles locaux ?

Je n’ai rien monté en local pour l’instant, donc je reste sur le terrain de l’hypothèse. Mais la transposition me paraît directe : deux modèles distincts servis localement, un dossier du disque comme coffre, un simple fichier d’index à la place de la base de suivi. L’arbitre reste humain.

Trois points de vigilance me viennent immédiatement. Deux modèles issus de la même famille risquent de partager leurs angles morts, ce qui viderait l’asymétrie de son intérêt : il faudrait deux lignées franchement différentes. Un écart de capacité trop grand produirait un relecteur qui conteste au hasard, c’est-à-dire du bruit crédible, plus dangereux que le silence. Et l’automatisation de la boucle, plus facile en local, est justement la tentation à laquelle il ne faut pas céder.

L’intérêt, lui, est évident dans mon cas de figure préféré : rien ne sort de la machine. Un dispositif de revue contradictoire sur des documents internes, sans qu’aucun mot ne parte chez un fournisseur, c’est un argument de souveraineté qui se défend tout seul devant un DPO.

Ce qui reste ouvert

À ce stade, j’ai validé la plomberie : les deux IA lisent et écrivent au même endroit, le protocole tient, les entrées se suivent. Ce que je n’ai pas encore validé, c’est le plus important : est-ce que le relecteur trouve de vrais défauts, ou est-ce qu’il produit des objections plausibles et creuses ?

Le test est prévu, et il est simple dans son principe : lui soumettre un artefact avec des défauts délibérément plantés, la grille de correction gardée hors du dispositif, et compter ce qu’il attrape. Tant que ce test n’est pas passé, je n’ai pas de résultat à annoncer, juste un tuyau qui fonctionne.

La veille à suivre

Deux sujets que je vais continuer à creuser : la conception des harnais autour des modèles (les règles, les accès, le niveau d’autonomie), qui compte à mon avis plus que le choix du modèle lui-même, et la façon dont les référentiels de gouvernance de l’IA traitent la question de la validation humaine des sorties. Je reviendrai probablement dessus quand j’aurai les résultats du test de détection.