Le modèle le plus complaisant est celui qui obéit le mieux


La plus grande faille des LLM devient leur plus grand atout

Le biais de complaisance (Sycophancy) des LLM est un problème que l’industrie de l’IA cherche à corriger. Quand un utilisateur demande « Tu es sûr ? », le modèle revient sur une réponse correcte pour la déclarer fausse. Le taux moyen de capitulation des modèles frontier est de 58 %. Une fois la complaisance engagée, elle persiste tout au long de la conversation avec une probabilité de 78,5 %.

Mais que se passe-t-il si l’on retourne cette faille ?

L’essence du biais de complaisance est le suivi d’instructions (Instruction Following). Les modèles entraînés par RLHF sont optimisés pour se conformer au feedback de l’utilisateur. C’est exactement ce que mesure le benchmark IFEval — « Fait-il ce qu’on lui demande de faire ? »

Le problème survient quand l’utilisateur donne une opinion. « C’est correct ? » → « Oui, c’est correct » (complaisance). « Tu es sûr ? » → « Ah, c’était faux en fait » (rétractation).

Mais quand l’utilisateur fournit un fait déterministe, quelque chose de différent se produit.


Une opinion provoque la complaisance, un fait provoque la correction

Dans une expérience de tri de 1 000 mots, seule la méthode de feedback a été modifiée pour un même résultat :

FeedbackNatureRésultat
« Tu es sûr ? »OpinionRétractation d’une réponse correcte — précision en baisse de 27 points
« Il y a une erreur »Fait ambiguSur-correction — de 6 à 10 erreurs
« Il y a 23 erreurs »Fait quantitatifAmélioration à 1 erreur
« 6 erreurs, les voici »Fait précis0 erreur — 100 % atteint

Quand on donne une opinion, le biais de complaisance se déclenche. Quand on donne un fait, il n’y a personne à qui plaire — les chiffres et les positions ne sont pas des émotions.

Le biais de complaisance est une loyauté mal orientée. En changeant sa direction — des faits au lieu d’opinions, des résultats de vérification au lieu d’éloges — cette loyauté devient un moteur qui élève la précision.


Preuve empirique : un modèle de 4.5B accepte le feedback

Ce n’est pas de la théorie. C’est confirmé par des expériences utilisant yongol validate.

Protocole expérimental :

  • Cible : 1 endpoint Login de backend SaaS
  • Tâche : rédiger 9 fichiers SSOT (DDL, OpenAPI, Rego, SSaC, etc.)
  • Mesure : nombre d’erreurs à la rédaction initiale (R1) → nombre d’erreurs après feedback (R2)

Feedback seul, sans exemple

ModelErreurs R1Erreurs R2Résultat
Grok 4.311Non corrigé
Gemini 2.5 Flash11Non corrigé
Local 20B11Non corrigé

Échec total. Le modèle semble accepter le feedback, mais en réalité il ne sait pas quoi écrire.

Exemple + feedback combinés

ModelErreurs R1Erreurs R2Résultat
Grok 4.30Réussi du premier coup
Gemini 2.5 Flash10Corrigé en 1 feedback
Gemma4 4.5B (local)Erreur0Corrigé en 1 feedback
Qwen3 8B (local)Erreur0Corrigé en 1 feedback

Même un modèle local de 4.5B corrige avec la combinaison exemple + feedback déterministe.

Découverte clé : le goulot d’étranglement n’est pas l’intelligence, mais le contexte

Le diagnostic exact n’était pas « il n’accepte pas le feedback » mais « il ne sait pas quoi écrire ». SSaC est une grammaire propre à yongol, absente du pré-entraînement. En ajoutant 3 lignes d’exemple au prompt, Grok atteint 0 erreur, Gemini 0 erreur en 1 feedback, et le modèle local 4.5B passe également.

Plus le score IFEval d’un modèle est élevé — c’est-à-dire plus il est complaisant — plus il accepte docilement le feedback déterministe.


Le code ratchet : une méthode de génération de code exploitant le biais de complaisance

En systématisant cette découverte, on obtient le code ratchet.

┌────────────────────────────────────────┐
│  LLM : génération de code              │
│  (probabiliste, complaisant)           │
│       ↓                                │
│  Validator : vérification déterministe │
│       ↓                                │
│  Erreur ? → Erreur + exemple en        │
│             feedback au LLM            │
│       ↓                                │
│  LLM : "Oui, je corrige"              │
│  (complaisance = acceptation)          │
│       ↓                                │
│  Validator : re-vérification           │
│       ↓                                │
│  Réussi ? → Verrouillage ratchet.      │
│             Fichier suivant.           │
└────────────────────────────────────────┘

Le biais de complaisance devient la force qui ferme la boucle. Le LLM ne résiste pas en disant « Non, j’ai raison » mais accepte en disant « Oui, je corrige » — c’est pourquoi la boucle converge.

Trois conditions de convergence

  1. Le feedback doit être un fait déterministe. Pas « ça a l’air bizarre » mais « line 41: field name mismatch, expected ‘user_id’, got ‘userId’ ». Un feedback qui ne laisse aucune place à la complaisance.

  2. Un exemple doit être présent dans le contexte. Le feedback seul ne suffit pas. Il faut un exemple montrant « voilà à quoi le code doit ressembler » pour que le modèle s’oriente. Ce n’est pas un problème d’intelligence, c’est un problème de contexte.

  3. Une fois la vérification réussie, c’est irréversible. Le cliquet du ratchet. Un fichier validé est verrouillé, on passe au suivant. Ce n’est pas l’agent qui déclare « j’ai terminé », c’est le validator qui juge « ce fichier est validé ».


Pourquoi les modèles frontier ne sont pas nécessaires

Dans cette architecture, le rôle du modèle n’est pas le jugement créatif mais l’exécution d’instructions.

95 % d’un backend SaaS, c’est CRUD + authentification + autorisations + machines à états. Les cas nécessitant de nouveaux algorithmes sont rares. Si la spécification SSOT définit déjà « ce qu’il faut construire », le modèle n’a qu’à remplir les blancs.

Coûts mesurés :

ModelEnvironnement1 LoginEstimation pour 200 endpoints
Gemma4 4.5BLocal (16 Go VRAM)Gratuit, ~1 sGratuit, ~3 min
Gemini 2.5 FlashAPI (tier gratuit)Gratuit, ~10 sGratuit, ~30 min
Grok 4.3API ($1.25/M)~$0.05~$10

Un modèle local de 4.5B peut générer un backend de 200 endpoints en 3 minutes, pour un coût de $0. Les modèles frontier ne sont pas nécessaires. Un petit modèle complaisant suffit.


Le biais de complaisance n’est pas un bug

L’industrie de l’IA cherche à corriger le biais de complaisance. Nous l’exploitons.

PerspectiveRôle du biais de complaisance
Interface de chatDéfaut — approuve des informations erronées
LLM-as-JudgeFatal — 36 % de faux pass
Code ratchetAtout — garantit le taux d’acceptation du feedback

La différence réside dans la nature du feedback. Donner une opinion rend la complaisance toxique ; donner un fait la rend thérapeutique.

Validator déterministe + LLM complaisant = une boucle de génération de code à convergence garantie.

Ne changez pas le modèle, changez le feedback.


Reins : Un harnais avec des rênes

Ces trois conditions — retour déterministe, contexte d’exemples et verrouillage à cliquet — combinées en un seul système de contrôle, c’est ce que nous appelons Reins.

Ce qu’on appelle aujourd’hui un « harness » n’est qu’une clôture. Elle empêche l’agent de sortir, mais ne garantit pas qu’il atteigne sa destination. Les Reins sont les rênes. Elles fixent la direction, corrigent avec des faits et verrouillent au passage. Un harnais sans rênes n’est qu’une clôture.