Limites et hallucinations

Les défaillances d’un LLM sont des propriétés du système, pas des bugs en attente de correctif : chacune est la conséquence directe d’un mécanisme que les Étapes précédentes ont posé.

On ne les supprime donc pas, on les reconnaît. Et il faut les reconnaître vite, parce que leurs remèdes ne sont pas interchangeables — c’est la leçon qui m’a coûté le plus de temps perdu. Cinq familles, et pour chacune la même paire : à quoi je la repère, et ce que je vérifie.

C’est quoi une hallucination ?

Le fonctionnement nominal, observé dans le cas où plausible et vrai divergent. Rien de cassé, rien à corriger.

« Ce qu’est un LLM » l’a posé : c’est la vraisemblance de la continuation qui est optimisée, jamais sa véracité. Et « Ce que le modèle sait » dit où le cas se produit — partout où la régularité manque au corpus.

En pratique de développement, ça prend des formes très reconnaissables : une méthode qui n’existe pas mais devrait exister vu le reste de l’API ; une option de configuration issue d’une autre version ; un package au nom parfaitement crédible et jamais publié ; une explication de bug cohérente, argumentée, et fausse.

Le point commun de toutes : la forme est irréprochable. C’est exactement pour ça que la relecture « au feeling » ne suffit pas.

Pourquoi le modèle est toujours d’accord avec vous ?

Parce que c’est ce qui a été optimisé dans ses poids. Le mécanisme n’est pas ici : « Ce qui se règle, et ce qui ne se règle pas » montre d’où ça vient, et pourquoi aucune consigne ajoutée à votre prompt ne le défait. Ce qui suit, c’est l’autre moitié — comment ça se reconnaît en session.

Le modèle tend à aller dans votre sens. Suggérez que le bug vient du cache, et l’explication impliquera le cache. Demandez « c’est bien ça le problème, non ? », et vous récolterez une confirmation. Présentez votre code avec fierté, la revue sera plus douce.

Le signal se lit dans votre propre question, pas dans la réponse : plus votre hypothèse y est affirmée, moins le modèle la contestera. Les questions fermées et orientées produisent de l’écho, pas de l’analyse.

Pour un développeur expérimenté, c’est la défaillance la plus insidieuse des cinq, parce qu’elle exploite votre confiance et non votre ignorance. Et parce qu’elle ne laisse rien derrière elle : un accord n’a pas l’air d’une erreur.

LE CRAFTOMANCER

Ne demandez jamais une validation, demandez une attaque. « Vérifie mon hypothèse » produit un oui poli ; « liste ce qui contredirait cette hypothèse » produit de l’information. Et si vous voulez un second avis honnête, présentez le problème sans votre conclusion, dans une session vierge, où votre historique ne penche pas déjà de votre côté.

Pourquoi l’agent oublie vos conventions en cours de session ?

Parce que la fenêtre elle-même défaille, indépendamment du savoir et de la complaisance. Cette troisième famille est déjà outillée par « Tokens, fenêtres et attention » et « Le contexte est la seule réalité du modèle ».

Une consigne noyée au milieu d’un long historique cesse d’être suivie (lost in the middle). Une information contredite plus loin dans le contexte produit un comportement instable. Une session interminable accumule des directives périmées qui continuent de peser sur chaque réponse.

Le symptôme typique, c’est la dérive : l’agent qui suivait vos conventions au début de la session et les oublie une heure plus tard. Le bon réflexe, c’est de déplacer la consigne là où elle ne sort jamais de la fenêtre — le fichier d’instructions — ou de repartir d’une session propre. Surtout pas de la répéter une troisième fois dans le chat.

Une longue délibération est-elle une vérification ?

Non, et c’est la famille la plus coûteuse à repérer. Les modèles qui déroulent une longue délibération avant de répondre produisent cette délibération token par token, comme le reste — donc elle hérite de ce que la boucle impose à toute sortie longue. (Ce qu’elle coûte, et comment se règle l’effort qu’on y met, c’est le sujet du coût et de la latence.)

Une prémisse fausse posée au troisième paragraphe est respectée par les quarante suivants, et la conclusion est cohérente — cohérente avec la faute. Une déduction ne valide jamais ce dont elle part.

Ce qui est neuf, c’est la façon dont ça se lit. Une trace qui pèse le pour et le contre, envisage une autre piste et revient sur ses pas ressemble à une vérification. Elle n’en est pas une : c’est la même machine à continuer du texte, appliquée cette fois au texte d’un raisonnement. La longueur mesure des tokens dépensés, elle ne mesure aucune solidité.

D’où un réflexe que les trois familles précédentes ne donnent pas : quand la conclusion est fausse, ne cherchez pas la faute de logique dans la délibération — elle n’y est presque jamais. Remontez à ce dont elle est partie, et vérifiez-le à part, sans la trace sous les yeux. Une réponse qui arrive avec sa propre justification se vérifie exactement comme une réponse qui arrive nue.

Et si le problème, c’était vous ?

C’est la cinquième limite, et elle n’est pas dans le modèle : elle est dans le lecteur.

Le code généré est fluide, idiomatique, bien commenté. Il ressemble à du code de qualité, et cette ressemblance désarme la vigilance. J’aime bien l’image du CV impeccablement mis en page : la typographie ne vous dit rien du candidat, mais elle vous rend nettement moins regardant.

C’est le biais d’automatisation appliqué à la revue : plus la sortie est propre, moins on la conteste, alors que la propreté de surface ne dit rien de la correction.

S’ajoute l’asymétrie de fatigue, et celle-là est implacable. L’agent peut produire en quelques minutes plus de code que vous ne pouvez en relire sérieusement dans l’heure. Si votre processus de vérification repose sur « je relis tout attentivement », il ne tiendra pas la cadence. Il faut des vérifications qui ne fatiguent pas : types, tests, lint, exécution.

Quel remède pour quelle famille ?

Chaque famille a le sien, et les confondre coûte cher. Toute la Section tient d’ailleurs dans une posture : faire confiance au processus de vérification, jamais à la sortie.

Savoir manquant → fournir la doc dans le contexte.
Sycophantie → reposer la question à froid, sans votre conclusion dedans.
Contexte dégradé → nettoyer ou redémarrer la session.
Délibération partie de travers → vérifier la prémisse, jamais la démonstration.

Trois réflexes complètent le classement :

Toute affirmation vérifiable mécaniquement doit l’être : une API citée se vérifie dans la doc, un bug « corrigé » se vérifie par un test qui échouait avant.
Formulez vos questions en aveugle : décrivez les symptômes, pas votre suspect favori.
Calibrez la vérification sur le coût de l’erreur, pas sur l’apparence de la sortie. Du code de migration de données mérite plus de défiance qu’un composant d’interface, à fluidité égale.

En pratique

L’assurance d’une réponse ne se lit pas : traitez la sortie comme une proposition à vérifier, jamais comme une réponse.
Demandez des attaques, pas des validations. Un second avis se prend dans une session vierge, sans votre conclusion dedans.
Quand l’agent dérive, soignez le contexte (fichier d’instructions, session fraîche) plutôt que de répéter dans le chat.
Une délibération n’est pas une vérification, quelle que soit sa longueur. Conclusion fausse : remontez à la prémisse, pas à la démonstration.
Construisez des vérifications qui ne fatiguent pas (types, tests, exécution), parce que votre relecture, elle, fatigue.

La machine s’arrête ici

Huit Étapes, et le contrat est rempli : vous pouvez prédire ce que l’agent va faire, et nommer ce qu’il faut vérifier quand il se trompe. Ce qui reste n’est plus de la mécanique, c’est un métier — organiser une session, un dépôt, une équipe autour de cette machine-là. C’est « La pratique », qui ouvre sur l’anatomie d’un agent : la même boucle, avec le harnais et l’outillage construits autour, et vous qui tenez la barre.

Vérifiez votre modèle

Cinq questions pour voir si la typologie tient. Cliquez une réponse : le verdict s’affiche.

RUN · VIII 0 / 5

jack in — choisissez votre réponse

Une hallucination, c’est avant tout…

Vous soupçonnez le cache et demandez à l’agent « c’est bien le cache, non ? ». Vous obtenez surtout…

L’agent respectait vos conventions en début de session et les oublie une heure plus tard. Le bon réflexe…

L’agent délibère trente lignes, puis conclut faux. Vous cherchez la faute…

Du code généré fluide, idiomatique et bien commenté mérite…