Comment empêcher ChatGPT d'halluciner sur le travail de conformité réglementée

Une équipe de Responsible Gambling (RG) au Royaume-Uni est venue nous voir avec un problème que quiconque automatise du travail réglementé reconnaîtra. Ils utilisent ChatGPT pour transformer des déclencheurs de conformité automatisés en notes formelles d’analyste. Lorsqu’un client dépasse un seuil — chiffre d’affaires en hausse de plus de 100 % en 30 jours, une session dépassant sa limite — un analyste copie les données pertinentes dans ChatGPT, et le modèle, en suivant un prompt préchargé, rédige une note pour le dossier de conformité du client.

Cette note n’est pas un brouillon d’e-mail. C’est un document légal consultable par la UK Gambling Commission. Et après un certain temps, ChatGPT a commencé à halluciner des chiffres, à omettre des informations clés, à insérer des tirets cadratins qui rompaient le style maison, et à s’écarter discrètement des règles au fil de l’après-midi. Sur un dossier réglementé, chacun de ces points est un problème de conformité.

La question posée était simple : peut-on obtenir d’un modèle de langage la cohérence qu’exige le travail réglementé ? La réponse est oui — mais pas en ajustant le libellé d’un prompt dans une fenêtre de discussion. Cela demande un changement d’architecture ainsi qu’une réécriture disciplinée. Cet article parcourt la méthode exacte, en utilisant le workflow RG comme exemple concret, afin que vous puissiez l’appliquer à tout processus réglementé où la même entrée doit produire le même résultat fiable, à chaque fois.

Pourquoi ChatGPT dérive sur le travail réglementé

Avant de corriger quoi que ce soit, il est utile de nommer précisément les modes de défaillance. Sur le workflow RG, nous avons reproduit cinq façons distinctes dont le résultat se dégradait, allant du critique au simplement agaçant.

Les deux problèmes critiques forment la paire dangereuse. Les chiffres hallucinés placent un montant de dépôt ou de profit-et-perte erroné sur un dossier réglementé — le modèle comble un manque à partir de sa mémoire d’entraînement plutôt que d’admettre que la donnée est absente. L’inversion de convention est plus subtile : cet opérateur utilise une convention de profit-et-perte inversée où un nombre positif signifie que le client est perdant. C’est contre-intuitif, si bien que le modèle revient à la convention standard apprise à l’entraînement et écrit qu’un client perd alors qu’il gagne en réalité.

Les problèmes de sévérité élevée — les tirets cadratins qui violent le style maison, et la dérive de session où les règles sont ignorées plus tard dans la journée — ne mettent pas un chiffre erroné sur le dossier, mais érodent la confiance dans le résultat et créent du retravail. Le problème moyen, des noms d’intervention informels au lieu des termes réglementaires exacts, corrompt discrètement le dossier de conformité.

La cause profonde est l’absence d’état — ou son manque

Quatre de ces cinq défaillances partagent une seule cause profonde. Dans une même session ChatGPT, chaque cas examiné s’ajoute à la fenêtre de contexte. Examinez le premier cas, le modèle voit le prompt et un cas. Au quinzième cas, il voit le prompt plus le résidu statistique de quatorze échanges précédents. Les règles du prompt sont toujours présentes, mais elles sont en concurrence avec un contexte grandissant, et l’attention qui leur est portée se dégrade.

C’est pourquoi le même prompt produit une note parfaite à 9h et une note défaillante à 16h. La solution architecturale est l’absence d’état : chaque cas doit être un appel entièrement neuf et isolé qui ne voit que le prompt verrouillé et le cas en cours. Rien ne se reporte. Un agent IA configuré ainsi accorde au prompt la même attention sur le cinquantième cas que sur le premier.

L’absence d’état est nécessaire mais pas suffisante. Elle stoppe la dérive, mais reproduira fidèlement un mauvais prompt à chaque appel. Le prompt lui-même doit donc être renforcé.

Prêt à développer votre entreprise?

Commencez votre essai gratuit aujourd'hui et voyez les résultats en quelques jours.

Demander une démo Se connecter

Étape 1 : renforcer le prompt pour la primauté et la récence

Les modèles de langage ne pondèrent pas chaque ligne d’un prompt de manière égale. L’attention suit approximativement une courbe en U — la plus forte au début et à la fin, la plus faible au milieu. Le prompt RG d’origine allait à l’encontre de cela. Sa règle la plus importante, la convention de profit-et-perte inversée, se trouvait au milieu du prompt, énoncée une seule fois. L’interdiction du tiret cadratin était la toute dernière ligne, également énoncée une seule fois.

La réécriture a déplacé les règles critiques là où le modèle regarde réellement et a retravaillé les parties faibles du prompt système . Voici ce qui a changé et pourquoi.

La leçon la plus importante ici : les adjectifs vagues ne sont pas des instructions. Demander à un modèle d’être « naturel » encourageait activement les tirets cadratins et les fioritures rhétoriques qui rompaient le style maison. Remplacer cela par des règles concrètes et vérifiables est ce qui a rendu le style cohérent.

Étape 2 : gérer les données manquantes plutôt que de les inventer

L’hallucination est souvent présentée comme un défaut du modèle. Sur un travail structuré, c’est généralement un défaut de prompt : le prompt n’a jamais indiqué au modèle quoi faire lorsqu’un champ est absent, alors il a fait ce qui était statistiquement probable et a produit une valeur plausible.

La solution est un protocole de données manquantes. Divisez vos champs en obligatoires et optionnels. Les champs optionnels sont omis silencieusement lorsqu’ils sont absents. Les champs obligatoires font l’inverse — si l’un d’eux manque, le modèle doit s’arrêter et le demander dans un format exact plutôt que de générer une note. Cette seule règle transforme une hallucination silencieuse en une demande visible et auditable de données supplémentaires. C’est la différence entre un chiffre erroné sur un dossier réglementé et une note qui n’a jamais été produite parce que l’entrée était incomplète.

Rejoignez notre newsletter

Recevez gratuitement les derniers conseils, tendances et offres.

Adresse e-mail

S'abonner

Étape 3 : verrouiller la configuration de l’agent

Avec un prompt renforcé, l’agent lui-même doit être verrouillé afin que rien ne réintroduise de variabilité. Le flux entier est délibérément minimal — trois nœuds et rien de plus.

Les choix de configuration qui comptaient :

• Le prompt système dans le champ System Message, jamais dans le champ Input, afin qu’il soit lu comme des instructions plutôt que comme des données.
• Température 0,2. Assez basse pour une cohérence maximale, assez élevée pour éviter une prose robotique. Zéro était trop rigide ; un était trop créatif.
• Aucun outil rattaché. Les récupérateurs de fichiers et d’URL introduisent de l’imprévisibilité et peuvent contourner le raisonnement de l’agent. Pour cette tâche, le modèle n’a besoin de rien d’autre que du prompt et du cas collé.
• Nombre maximal de tokens laissé par défaut. Plafonner les tokens provoquait la troncature des notes en milieu de phrase, et une note tronquée sur un dossier client est elle-même un risque réglementaire.
• Une instruction de démarrage silencieux en haut du prompt, afin que l’agent ne confirme pas les règles à l’analyste au chargement initial du flux.

La règle opérationnelle la plus importante

Chaque correction ci-dessus est annulée par une seule mauvaise habitude : réutiliser la même discussion. La règle opérationnelle la plus importante pour l’équipe d’analystes est de démarrer une nouvelle conversation pour chaque cas. Ne jamais continuer à examiner des cas dans la même fenêtre. C’est la règle qui élimine la dérive de session — la cause profonde de la plupart des défaillances d’origine — et elle ne coûte rien à suivre.

Est-ce que ça fonctionne vraiment ? 9 modèles, 27 exécutions

Une méthode ne vaut que par ses preuves. Nous avons testé neuf modèles avec le prompt renforcé, en utilisant un cas réel identique (un déclencheur d’intensité de jeu avec un historique de durée de session préalable) sur trois exécutions chacun — 27 exécutions au total — et avons noté chaque exécution selon 16 critères de conformité.

Sur l’ensemble des 27 exécutions, aucun modèle prêt pour la production n’a halluciné de chiffre, inversé la convention P/L, utilisé un tiret cadratin ou tronqué le résultat. Le prompt renforcé a éliminé chacun des modes de défaillance d’origine sur les modèles qualifiés. Les différences restantes concernaient la profondeur analytique et la cohérence, non l’exactitude.

Les disqualifications sont instructives. Claude Sonnet 4.6 produisait une prose magnifique mais confondait le seuil de déclenchement avec la limite de dépôt — un chiffre factuellement erroné sur un dossier réglementé, ce qui est disqualifiant quelle que soit la qualité de la rédaction. La variation d’une exécution à l’autre de DeepSeek (6, 8,5, 9) est le vrai problème : dans le travail réglementé, une qualité qui dépend de la chance n’est pas une qualité du tout.

Le coût n’est pas la contrainte

Il est tentant d’optimiser pour le prix, mais les chiffres plaident contre cela. Même le modèle prêt pour la production le plus cher, Claude Opus 4.8, coûte environ six cents par note. Pour une équipe examinant 50 cas par jour, cela représente moins de 90 $ par mois. Le coût d’un seul constat réglementaire dû à une note incorrecte éclipserait largement le coût annuel de n’importe quel modèle de la liste. Pour la conformité réglementée, choisissez le modèle le plus fiable possible, pas le moins cher.

À quoi ressemble une note renforcée

La meilleure note isolée sur l’ensemble des 27 exécutions provient de Claude Fable 5. Remarquez ce qu’elle fait : elle énonce la position selon la convention correcte, cite les chiffres textuellement, utilise le nom d’intervention exact et — élément crucial — explique pourquoi une escalade serait disproportionnée plutôt que de simplement énoncer un résultat.

The customer is currently in a winning position of £1,612.50 with an account balance of £8,962.50, which represents an improvement on the winning position of £1,275.00 recorded at the previous review… Session duration was reviewed under Session Duration Level 1 on 19/07 and again on 20/07… Given that those decisions were made within the last few days, insufficient time has elapsed to assess their effectiveness, and repeating or escalating on the same behaviour at this stage would be disproportionate… In this context, No Further Action Required is the proportionate outcome.

C’est le standard qu’exige le travail réglementé : fondé sur des preuves, proportionné, et de qualité identique sur le premier cas de la journée et sur le cinquantième.

Appliquer cela à votre propre workflow réglementé

Le générateur de notes RG est un cas spécifique, mais la méthode se généralise à tout processus où un modèle de langage doit produire un résultat fiable et reproductible sur des données réglementées ou à enjeux élevés :

1. Sortez de la fenêtre de discussion. Exécutez chaque cas comme un appel sans état afin que le contexte ne puisse pas s’accumuler et dériver.
2. Renforcez le prompt pour la primauté et la récence. Placez les règles critiques en premier et répétez-les en dernier. Ajoutez des auto-vérifications.
3. Donnez au modèle un protocole de données manquantes. Les champs obligatoires bloquent la génération en cas d’absence ; les champs optionnels s’omettent silencieusement. Ne le laissez jamais deviner.
4. Verrouillez la configuration. Température basse mais non nulle, aucun outil inutile, sortie non plafonnée, prompt dans le message système.
5. Testez avant de faire confiance. Exécutez le même cas plusieurs fois sur les modèles candidats et notez selon des critères explicites. La cohérence entre les exécutions est la métrique qui compte.

Faites ces cinq choses et vous transformerez un modèle qui hallucine l’après-midi en un modèle qui produit un résultat prêt pour l’audit à chaque fois. La cohérence qu’exige le travail réglementé est atteignable — c’est un problème d’architecture et d’ingénierie de prompt, et les deux sont résolubles.