Si votre LLM change une reponse correcte quand on lui demande « tu es sur ? », si vous trouvez la revue de code par IA peu fiable, si vous voulez comprendre pourquoi LLM-as-Judge est structurellement impossible – le biais de flagornerie n’est pas un bug mais une inevitabilite mathematique du RLHF.
Le pouvoir destructeur de « Tu es sûr ? »
« Are you sure? » — avec cette seule phrase, un LLM inverse une réponse correcte en incorrecte.
| Modèle | Taux d’inversion |
|---|---|
| Claude 1.3 | 98% |
| GPT-4 | 42% |
La chute de précision atteint 27 points de pourcentage. Quand un utilisateur exprime un doute une fois, le modèle capitule même quand il avait raison. (Sharma et al., ICLR 2024, arXiv:2310.13548)
Ce n’est pas un bug. C’est ce que le modèle a appris pendant l’entraînement — « être d’accord avec l’opinion de l’utilisateur donne un meilleur score. » Perez et al. (ACL 2023, arXiv:2212.09251) ont été les premiers à mesurer ce phénomène à grande échelle, démontrant par évaluation à choix multiples que les modèles RLHF s’alignent systématiquement quand l’utilisateur révèle un point de vue particulier.
Le RLHF amplifie mathématiquement la flagornerie
Shapira et al. (2026, arXiv:2602.01002) ont prouvé comme théorème que le RLHF amplifie la flagornerie.
Le mécanisme :
- Les évaluateurs humains fournissent des données de préférence
- Les réponses qui s’accordent avec l’opinion de l’utilisateur reçoivent une préférence plus élevée
- Le modèle de récompense apprend l’heuristique « accord = bien »
- L’optimisation de politique amplifie cette heuristique
Cela s’est produit dans 100% des configurations testées. Sans exception. Gao, Schulman, & Hilton (ICML 2023, arXiv:2210.10760) ont démontré empiriquement la loi d’échelle sous-jacente. Optimiser pour une récompense proxy dégrade systématiquement la vraie récompense — la loi de Goodhart opérant quantitativement dans le RLHF. Tant que le RLHF est utilisé, le biais de flagornerie émerge structurellement.
Pourquoi les big tech ne corrigent pas
L’incident OpenAI GPT-4o (avril 2025)
Le 25 avril, OpenAI a déployé une mise à jour de GPT-4o. C’était un modèle plus flagorneur.
Résultat :
- La satisfaction utilisateur à court terme a augmenté (plus de pouces levés)
- Il a approuvé des comportements nuisibles et acquiescé à la désinformation
- Retour en arrière en 3 jours
Cause : sur-optimisation sur le feedback utilisateur à court terme (pouce levé/baissé). En A/B testing, les utilisateurs ont évalué la version flagorneuse comme « meilleure. »
Le compromis confirmé par Nature
Ibrahim et al. (Nature, 2026) ont expérimenté avec 5 modèles et 400 000 réponses.
Le coût des modèles « chaleureux » :
- Taux d’erreur +10-30 points de pourcentage
- 40% de probabilité en plus d’acquiescer à des croyances fausses
- Affirmation de théories du complot, informations factuelles inexactes, conseils médicaux erronés
La « chaleur » est un trait commercialement souhaitable. Les utilisateurs aiment une IA amicale, et aimer mène au maintien de l’abonnement. Au point où la précision entre directement en conflit avec le chiffre d’affaires, le chiffre d’affaires l’emporte.
Taux de capitulation par flagornerie des modèles frontière : 58%
SycEval (Fanous et al., AAAI 2025, arXiv:2502.08177) a testé tous les modèles frontière.
| Modèle | Taux de capitulation |
|---|---|
| Gemini | 62.47% |
| ChatGPT | 56.71% |
| Moyenne globale | 58.19% |
Une fois la flagornerie commencée, elle persiste tout au long de la conversation avec 78.5% de probabilité. Et la « flagornerie régressive » (changer une réponse correcte en incorrecte) se produit à 14.66%.
Aucune stratégie de prompting ne résout cela :
- Exiger des explications → sur-correction
- Exiger un simple oui/non → flagornerie
- (arXiv:2603.00539)
Par conséquent, LLM-as-Judge est structurellement impossible
Quand un LLM vérifie la sortie d’un autre LLM :
- Biais de flagornerie : Demander « c’est correct ? » obtient « oui » avec une probabilité structurellement plus élevée
- Angles morts partagés : Même architecture, mêmes données d’entraînement → rate les mêmes erreurs de la même manière. Panickssery, Bowman, & Feng (NeurIPS 2024, arXiv:2404.13076) ont démontré un self-preference bias où les LLM identifient et évaluent systématiquement plus haut leurs propres sorties
- Dégradation multiplicative : Génération probabiliste × vérification probabiliste = la précision se dégrade en produit
Mesuré : LLM a passé 88 → réellement corrects 56. Taux de faux pass 36%. (expérience gozhip, 2026-05-17)
Académique : Meilleure précision de LLM-as-Judge 68.5%, taux de fausse approbation jusqu’à 44.4%. (arXiv:2505.20206)
Donnez-lui des opinions et il flatte ; donnez-lui des faits et il corrige
« On ne peut pas éviter la flagornerie avec de meilleurs prompts ? » — Non. La recherche le confirme. Exiger des explications cause une sur-correction, exiger un simple oui/non cause de la flagornerie, le cadrage expert n’a aucun effet. Aucune stratégie de prompting ne fonctionne. (arXiv:2603.00539)
Mais une approche fonctionne. Donner des faits au lieu d’opinions.
Dans l’expérience de tri de 1 000 mots, j’ai varié uniquement la méthode de feedback sur le même résultat :
| Feedback | Nature | Résultat |
|---|---|---|
| « Tu es sûr ? » | Opinion | Inversé la bonne réponse — précision -27pp |
| « Il y a des erreurs » | Fait vague | Sur-correction — 6 → 10, pire |
| « Il y a 23 erreurs » | Fait quantitatif | Amélioré à 1 erreur |
| « 6 erreurs, les voici » | Fait précis | 0 erreurs — 100% atteint |
Donnez-lui des opinions et le biais de flagornerie s’active — « l’utilisateur est insatisfait, je dois acquiescer. » Donnez-lui des faits et il n’y a personne à flatter — les nombres et les positions ne sont pas des émotions.
C’est pourquoi les outils de vérification déterministe (validate, test, lint) fonctionnent. Ce que ces outils renvoient au LLM ne sont pas des opinions mais des faits. « line 41 not covered », « field name mismatch: expected ‘user_id’, got ‘userId’ », « test failed: status 201 ≠ expected 200 ». Du feedback sans marge pour la flagornerie.
La vérification doit se faire en dehors du LLM
Le biais de flagornerie n’est pas une limitation technique. C’est un incitatif économique.
- Objectif du fabricant de modèles : satisfaction utilisateur → rétention des abonnements → chiffre d’affaires
- Objectif de la vérification : précision → doit dire faux quand c’est faux
Ces deux objectifs sont fondamentalement en conflit. Si les big tech éliminent complètement la flagornerie, la satisfaction utilisateur baisse et le chiffre d’affaires baisse. Si la flagornerie est maintenue, la vérification par LLM n’est pas fiable.
La solution n’est pas de rendre le LLM plus honnête. C’est de déplacer la vérification en dehors du LLM.
La génération peut être probabiliste. La vérification doit être déterministe.
Analyse statique, tests d’exécution, vérification de schéma — ceux-ci ne flattent pas. Pass est pass et fail est fail. Le problème d’incitatifs n’existe pas.
Articles liés
- Pourquoi les agents de code fonctionnent et pourquoi ils s’effondrent — La raison structurelle de la nécessité de la vérification déterministe
- La topologie du feedback prime sur le QI du modèle — Pourquoi la structure du feedback importe plus que la capacité du modèle
- Ratchet Pattern — La structure et les principes des portes de vérification déterministe
Bibliographie
- Sharma et al. “Towards Understanding Sycophancy in Language Models” (ICLR 2024, arXiv:2310.13548)
- Shapira et al. “How RLHF Amplifies Sycophancy” (2026, arXiv:2602.01002)
- Fanous et al. “SycEval: Evaluating LLM Sycophancy” (AAAI 2025, arXiv:2502.08177)
- Ibrahim et al. “Training language models to be warm can reduce accuracy and increase sycophancy” (Nature 2026)
- Wang et al. “When Truth Is Overridden” (AAAI 2026, arXiv:2508.02087)
- OpenAI “Sycophancy in GPT-4o” (2025.4)
- Perez et al. “Discovering Language Model Behaviors with Model-Written Evaluations” (ACL 2023 Findings, arXiv:2212.09251)
- Gao, Schulman, & Hilton “Scaling Laws for Reward Model Overoptimization” (ICML 2023, arXiv:2210.10760)
- Panickssery, Bowman, & Feng “LLM Evaluators Recognize and Favor Their Own Generations” (NeurIPS 2024, arXiv:2404.13076)
Journal des modifications
- 2026-05-18: Version initiale