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 :
| Feedback | Nature | Résultat |
|---|---|---|
| « Tu es sûr ? » | Opinion | Rétractation d’une réponse correcte — précision en baisse de 27 points |
| « Il y a une erreur » | Fait ambigu | Sur-correction — de 6 à 10 erreurs |
| « Il y a 23 erreurs » | Fait quantitatif | Amélioration à 1 erreur |
| « 6 erreurs, les voici » | Fait précis | 0 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
| Model | Erreurs R1 | Erreurs R2 | Résultat |
|---|---|---|---|
| Grok 4.3 | 1 | 1 | Non corrigé |
| Gemini 2.5 Flash | 1 | 1 | Non corrigé |
| Local 20B | 1 | 1 | Non corrigé |
Échec total. Le modèle semble accepter le feedback, mais en réalité il ne sait pas quoi écrire.
Exemple + feedback combinés
| Model | Erreurs R1 | Erreurs R2 | Résultat |
|---|---|---|---|
| Grok 4.3 | 0 | — | Réussi du premier coup |
| Gemini 2.5 Flash | 1 | 0 | Corrigé en 1 feedback |
| Gemma4 4.5B (local) | Erreur | 0 | Corrigé en 1 feedback |
| Qwen3 8B (local) | Erreur | 0 | Corrigé 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
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.
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.
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 :
| Model | Environnement | 1 Login | Estimation pour 200 endpoints |
|---|---|---|---|
| Gemma4 4.5B | Local (16 Go VRAM) | Gratuit, ~1 s | Gratuit, ~3 min |
| Gemini 2.5 Flash | API (tier gratuit) | Gratuit, ~10 s | Gratuit, ~30 min |
| Grok 4.3 | API ($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.
| Perspective | Rôle du biais de complaisance |
|---|---|
| Interface de chat | Défaut — approuve des informations erronées |
| LLM-as-Judge | Fatal — 36 % de faux pass |
| Code ratchet | Atout — 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.