Limites et hallucinations

Les défaillances d’un LLM sont des propriétés du système, pas des bugs en attente de correctif. Ce sont des conséquences directes de la mécanique vue dans les guides précédents. On ne les supprime pas : on les connaît, et on construit autour.

Je dresse ici la typologie des défaillances que vous rencontrerez réellement en travaillant, et les réflexes qui les neutralisent.

L’hallucination : la plausibilité sans la vérité

Le guide 01 l’a posé : le modèle optimise la vraisemblance de la continuation, pas sa véracité. L’hallucination n’est donc pas un dysfonctionnement. C’est le fonctionnement nominal, observé dans le cas où plausible et vrai divergent.

En pratique de développement, elle prend des formes récurrentes : 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 jamais publié ; une explication de bug cohérente, argumentée et fausse. Le point commun : la forme est irréprochable. La syntaxe de l’aplomb est la même que celle de l’exactitude. C’est exactement pour ça que la relecture « au feeling » ne suffit pas.

La sycophantie : le modèle vous suit

Le post-entraînement qui rend les modèles serviables a un effet secondaire : ils tendent à aller dans votre sens. Suggérez que le bug vient du cache, et le modèle trouvera une explication impliquant 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.

Pour un développeur expérimenté, c’est la défaillance la plus insidieuse, parce qu’elle exploite votre propre confiance. Plus votre hypothèse est affirmée, moins le modèle la contestera. Les questions fermées et orientées produisent de l’écho, pas de l’analyse.

Le tips 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é.

Les défaillances de contexte

Troisième famille, déjà outillée par les guides 02 et 03 : les échecs qui ne viennent ni du savoir ni de la complaisance, mais de la fenêtre elle-même. 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 : déplacer la consigne là où elle ne sort jamais de la fenêtre (fichier d’instructions), ou repartir d’une session propre. Pas la répéter une troisième fois dans le chat.

Le biais de plausibilité — le vôtre

La dernière limite 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. 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. 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.

Les réflexes du praticien

La synthèse de la section tient en une posture : faire confiance au processus de vérification, jamais à la sortie.

Classez avant de corriger : savoir manquant (fournir la doc dans le contexte), sycophantie (reposer la question à froid), contexte dégradé (nettoyer ou redémarrer la session). Chaque famille a son remède, et les confondre fait perdre du temps.
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’aplomb n’est pas un signal : 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.
Construisez des vérifications qui ne fatiguent pas (types, tests, exécution), parce que votre relecture, elle, fatigue.

Avec ce guide se clôt le socle des Fondamentaux. La suite logique : la section « Coder avec un agent », où cette mécanique devient un workflow quotidien.

Vérifiez votre modèle

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

Auto-évaluation 0 / 4

01 Une hallucination, c’est avant tout…

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

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

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