Le code a cliquet qui retourne IFEval a son avantage

Image : generee par IA

Si votre LLM suit bien les instructions mais produit des resultats mediocres, si vous voulez exploiter le biais de flagornerie au lieu de l’eliminer, si vous voulez generer du code correct avec un modele local de 4.5B – la combinaison d’IFEval et du cliquet est la reponse.

Le modele le plus flagorneur est le plus obeissant

Le plus grand defaut devient le plus grand atout

Le biais de flagornerie (sycophancy) des LLM est un probleme que l’industrie de l’IA veut corriger. Quand un utilisateur demande “Tu es sur ?”, le modele change une reponse correcte en reponse incorrecte. Le taux moyen de capitulation des modeles de pointe est de 58%. Une fois la flagornerie engagee, elle persiste tout au long de la conversation avec une probabilite de 78,5%.

Mais que se passe-t-il si on retourne ce defaut ?

L’essence du biais de flagornerie est le suivi d’instructions (Instruction Following). Les modeles entraines par RLHF sont optimises pour se conformer au retour de l’utilisateur (Ouyang et al., 2022). Le benchmark IFEval mesure exactement cela – “Fait-il ce qu’on lui demande ?” (Zhou et al., 2023)

Le probleme survient quand l’utilisateur fournit des opinions. “C’est correct ?” -> “Oui, c’est correct” (flagornerie). “Tu es sur ?” -> “Ah, je me suis trompe” (capitulation).

Mais quand l’utilisateur fournit des faits deterministes, quelque chose de different se produit.

Donnez une opinion, obtenez de la flagornerie. Donnez un fait, obtenez une correction

Dans une experience de tri de 1 000 mots, seul le style de retour a ete varie pour le meme resultat :

Donnez une opinion et le biais de flagornerie s’active. Donnez un fait et il n’y a rien a flagorner – les chiffres et les positions ne sont pas des emotions.

Le biais de flagornerie est une loyaute mal dirigee. Changez la direction – des faits au lieu d’opinions, des resultats de verification au lieu d’eloges – et cette loyaute devient un moteur de precision.

Preuve : un modele 4.5B accepte le retour

Ce n’est pas de la theorie. Cela a ete confirme par des experiences avec yongol validate.

Conception de l’experience :

• Cible : un seul endpoint Login d’un backend SaaS
• Tache : ecrire 9 fichiers SSOT (DDL, OpenAPI, Rego, SSaC, etc.)
• Metrique : nombre d’erreurs a la generation initiale (R1) -> nombre d’erreurs apres retour (R2)

Retour seul, sans exemples

Echec total. Les modeles semblaient accepter le retour, mais en realite ne savaient pas quoi ecrire.

Exemples + retour ensemble

Meme un modele local de 4.5B se corrige avec la combinaison exemples + retour deterministe.

Decouverte cle : le goulot d’etranglement n’est pas l’intelligence, c’est le contexte

Le diagnostic exact n’etait pas “il ne peut pas integrer le retour” mais “il ne sait pas quoi ecrire”. SSaC est une grammaire specifique a yongol, absente des donnees de pre-entrainement. L’ajout de 3 lignes d’exemples au prompt a donne 0 erreur pour Grok, 0 erreur pour Gemini apres 1 cycle, et un passage pour le modele local 4.5B.

Plus un modele obtient un score eleve a IFEval – c’est-a-dire plus il est doue pour la flagornerie – plus il accepte facilement le retour deterministe.

Code a cliquet : une methode de generation de code qui exploite le biais de flagornerie

Transformez cette decouverte en systeme et vous obtenez le code a cliquet.

┌──────────────────────────────────────────────────┐
│  LLM : Genere du code (probabiliste, flagorneur) │
│       ↓                                          │
│  Validator : Verification deterministe           │
│       ↓                                          │
│  Erreurs ? → Erreurs + exemples au LLM          │
│       ↓                                          │
│  LLM : "Oui, je corrige" (flagornerie =         │
│         acceptation)                             │
│       ↓                                          │
│  Validator : Verifie a nouveau                   │
│       ↓                                          │
│  Reussi ? → Cliquet verrouille. Fichier suivant. │
└──────────────────────────────────────────────────┘

Le biais de flagornerie devient la force qui ferme la boucle. La boucle converge parce que le LLM ne resiste pas avec “Non, j’ai raison” mais obeit avec “Oui, je corrige”. L’approche de correction iterative du code LLM par retour de compilateur et de tests a egalement ete demontree dans Self-Debug (Chen et al., 2024), completant le debogage en 3 tours – le code a cliquet va plus loin en eliminant entierement le jugement propre du LLM et ne laissant que les faits deterministes.

Trois conditions de convergence

1. Le retour doit etre un fait deterministe. Pas “ca a l’air bizarre” mais “line 41: field name mismatch, expected ‘user_id’, got ‘userId’”. Un retour qui ne laisse aucune place a la flagornerie.

2. Des exemples doivent etre dans le contexte. Le retour seul ne suffit pas. Le modele a besoin d’exemples montrant “le code doit ressembler a ceci” pour s’orienter. C’est une question de contexte, pas d’intelligence.

3. Une fois la verification passee, pas de retour en arriere. La dent du cliquet. Un fichier qui a passe est verrouille et on passe au suivant. Ce n’est pas l’agent qui declare “j’ai fini” – c’est le validateur qui tranche “ce fichier passe”.

Pourquoi les modeles de pointe sont inutiles

Dans cette architecture, le role du modele n’est pas le jugement creatif mais l’execution d’instructions.

95% d’un backend SaaS est CRUD + authentification + autorisation + machines a etats. Les nouveaux algorithmes sont rarement necessaires. Si la specification SSOT definit deja “quoi construire”, le modele remplit simplement les blancs.

Couts mesures :

Un modele local de 4.5B peut generer un backend de 200 endpoints en 3 minutes pour $0. Pas besoin de modele de pointe. Un petit modele doue pour la flagornerie suffit.

Le biais de flagornerie n’est pas un defaut

L’industrie de l’IA tente de corriger le biais de flagornerie. Nous l’exploitons.

La difference reside dans la nature du retour. Donnez des opinions et la flagornerie devient poison ; donnez des faits et la flagornerie devient remede.

Validateur deterministe + LLM flagorneur = boucle de generation de code a convergence garantie.

Ne changez pas le modele. Changez le retour.

Reins : harnais avec renes

Ces trois conditions – retour deterministe, contexte d’exemples et verrouillage par cliquet – reunies en un seul systeme de controle, c’est ce que nous appelons Reins.

Ce qu’on appelle “harnais” aujourd’hui est une cloture. Il empeche l’agent de sortir, mais ne garantit pas qu’il atteigne sa destination. Les Reins sont les renes. Elles fixent la direction, corrigent par les faits et verrouillent au passage. Un harnais sans renes n’est qu’une cloture.

References

• Zhou, J., Lu, T., Mishra, S., Brahma, S., Basu, S., Luan, Y., Zhou, D., & Hou, L. (2023). “Instruction-Following Evaluation for Large Language Models.” arXiv:2311.07911
• Ouyang, L., Wu, J., Jiang, X., et al. (2022). “Training Language Models to Follow Instructions with Human Feedback.” NeurIPS 2022. arXiv:2203.02155
• Chen, X., Lin, M., Scharli, N., & Zhou, D. (2024). “Teaching Large Language Models to Self-Debug.” ICLR 2024. arXiv:2304.05128
• Sharma, M., Tong, M., Korbak, T., et al. (2024). “Towards Understanding Sycophancy in Language Models.” ICLR 2024. arXiv:2310.13548
• Fanous, A., Goldberg, J., Agarwal, A., et al. (2025). “SycEval: Evaluating LLM Sycophancy.” AAAI/ACM AIES 2025. arXiv:2502.08177
• Shapira, I., Benade, G., & Procaccia, A. D. (2026). “How RLHF Amplifies Sycophancy.” arXiv:2602.01002
• Ibrahim, L., Hafner, F. S., & Rocher, L. (2026). “Training Language Models to Be Warm Can Reduce Accuracy and Increase Sycophancy.” Nature, 652, 1159-1165

Journal des modifications

• 2026-05-20: Version initiale