Maker ≠ checker : pourquoi mes agents ont un sceptique

Un LLM qui rédige un dossier scientifique produit un texte fluide, structuré, convaincant. Et une partie de ses références n’existe pas. Ce n’est pas un bug ponctuel : c’est le comportement par défaut d’un modèle qui optimise la vraisemblance, pas la vérité.

J’ai rencontré le problème sur un cas concret : préparer des dossiers d’approche de leaders d’opinion scientifiques (KOL). Le travail est chronophage à la main. Automatisé naïvement, il devient dangereux : une citation inventée dans un dossier envoyé à un médecin, et la crédibilité de l’équipe est perdue.

Le principe : celui qui écrit ne vérifie pas

En finance ou en industrie, la règle « maker ≠ checker » est vieille comme les audits : la personne qui produit un livrable n’est jamais celle qui le valide. J’applique la même règle aux agents.

Le système est un pipeline multi-agents construit avec Google ADK sur Vertex AI, qui combine trois types d’orchestration :

• Sequential pour enchaîner les étapes : collecte, rédaction, vérification, restitution.
• Parallel pour traiter plusieurs KOL ou plusieurs sections en même temps.
• LoopAgent pour faire tourner la boucle rédaction ↔ vérification jusqu’à ce qu’elle converge.

Au cœur de la boucle, deux rôles séparés :

1. Le writer rédige le dossier et cite ses sources.
2. Le skeptic relit avec une seule consigne : trouver ce qui ne tient pas. Il ne réécrit rien, il conteste.

Le writer reçoit les objections et corrige. Le LoopAgent recommence jusqu’à ce que le skeptic n’ait plus rien à dire, ou qu’un nombre maximal d’itérations soit atteint.

Un sceptique LLM ne suffit pas

Un second modèle qui relit un premier réduit les erreurs, mais il peut lui aussi se laisser convaincre par une référence plausible. Le sceptique fait baisser le risque. Il ne l’annule pas.

La dernière étape n’est donc pas un LLM. Chaque citation est vérifiée programmatiquement contre Europe PMC : la référence existe, ou elle n’existe pas. Pas d’interprétation. Une citation introuvable est rejetée et renvoyée au writer avec l’identifiant en cause.

Résultat mesuré sur les dossiers produits : zéro citation hallucinée.

Ce que ça change pour une équipe

Trois conséquences pratiques, que je retrouve sur tous les agents que je mets en production :

• Le garde-fou est bloquant, pas informatif. Un avertissement en bas de page est ignoré. Une révision refusée ne sort pas.
• La vérification déterministe prime sur le jugement du modèle. Quand une source de vérité existe (une API, un référentiel, une règle métier), c’est elle qui tranche.
• Le rôle du sceptique est explicite dans l’architecture. Ce n’est pas une instruction ajoutée au prompt du rédacteur, c’est un agent distinct avec son propre objectif.

Le même pattern tourne aujourd’hui sur d’autres cas : un juge LLM supervise la boucle de revue manager ↔ agent sur des Statements of Work, et des garde-fous bloquants empêchent un agent juridique de proposer une révision sans passage source.

Ce que je regarde en premier chez vous

Quand j’audite un agent existant, la première question est simple : qui vérifie ? Si la réponse est « le même modèle, dans le même prompt », le risque d’hallucination n’est pas maîtrisé, quelle que soit la qualité de la démo.

Séparer le maker du checker, puis ajouter une vérification programmatique quand une source de vérité existe, est le changement au meilleur rapport effort / risque que je connaisse. C’est par là que je commence.