Claude Opus 4.7 et les hallucinations : où le modèle invente encore et comment s'en prémunir

Opus 4.7 est sorti hier jeudi 16 avril 2026. La release améliore plusieurs aspects (raisonnement, rétention de contexte, niveaux d’effort), mais un problème reste : les hallucinations. Le modèle invente encore des choses qui n’existent pas, dans des proportions certes réduites mais pas nulles. Voici ce qu’on voit en pratique et comment s’en prémunir.

Ce qu’est une hallucination concrètement

Hallucination : le modèle produit une affirmation qui sonne plausible mais qui est fausse. Pas une erreur de raisonnement, une production fabriquée.

Les types les plus fréquents :

Fonctions de librairie inventées. Le modèle “se souvient” d’une fonction lodash.mapObjectToArray() qui n’existe pas. Le code compile si tu ne l’exécutes pas, et plante à l’exécution.

Propriétés de config qui n’existent pas. Le modèle écrit un nginx.conf avec une directive rate_limit_by_user_agent qui n’a jamais existé. Nginx refuse la config.

Chiffres et stats inventés. “Selon une étude récente, 73 % des devs…”. L’étude n’existe pas, le chiffre sort du néant.

Citations d’auteurs inventées. “Martin Fowler recommande de…”. Fowler n’a peut-être jamais rien dit de tel.

Noms de versions imaginaires. “La version 2.4.1 de Redis supporte X”. La version exacte et le feature peuvent être inventés.

Les domaines où 4.7 hallucine plus

Les librairies et frameworks récents. Si la librairie a sorti une version majeure après la date de coupure d’entraînement du modèle, 4.7 peut inventer des APIs qui “semblent logiques” mais n’existent pas.

Les APIs de services cloud. AWS, GCP, Azure changent régulièrement leurs APIs. Le modèle peut référencer une syntaxe obsolète ou inventer des propriétés.

Les citations précises et les chiffres. Dès qu’on demande “quelle proportion de…”, “selon quelle source…”, “dans quel article…”, le risque d’hallucination monte.

Les détails historiques précis. Dates exactes, séquences d’événements, noms propres de gens impliqués dans des discussions techniques historiques.

Les domaines où 4.7 hallucine moins que 4.6

Le code idiomatique standard. Sur Python, JavaScript, Go, Rust, les idiomes de base sont solides. 4.7 hallucine nettement moins que 4.6 sur les patterns de programmation courants.

Les architectures logicielles courantes. Patterns classiques (MVC, hexagonal, event-driven) sont correctement restitués sans invention.

Les réponses à “je ne sais pas”. 4.7 est légèrement plus disposé à dire “je n’ai pas cette info” que 4.6. Marginal mais notable.

Les parades qui marchent en pratique

Vérifier systématiquement les références à des APIs externes

Si le modèle référence une fonction, une API, un endpoint, vérifie dans la doc officielle avant d’utiliser. C’est un réflexe à avoir sur les librairies et les services cloud.

Une minute de vérif évite deux heures de debug.

Préciser la version dans le prompt

“Je travaille avec Python 3.12 et FastAPI 0.110. Utilise uniquement les features compatibles avec ces versions.” Ce cadrage réduit les hallucinations de versions.

Si tu travailles avec un outil spécifique (terraform 1.10, kubernetes 1.31), indique-le. Le modèle calibre ses réponses.

Demander des sources pour toute stat citée

“Cite tes sources pour chaque chiffre ou statistique que tu avances, ou indique clairement que la donnée n’est pas disponible.”

Cette instruction dans le prompt système réduit significativement les chiffres inventés. Le modèle devient plus prudent.

Utiliser /ultrareview pour attraper les inventions

La commande /ultrareview dans Claude Code vérifie notamment que le code produit référence bien des fonctions réelles. Sur les fichiers produits par IA, elle attrape souvent les quelques hallucinations persistantes.

Tester le code avant de le committer

Règle simple : tout code produit par IA passe par un test d’exécution avant merge. Test unitaire, smoke test, run manuel. Une fonction inventée qui plante à l’exécution se détecte en 30 secondes.

Demander des tests couvrant les cas que tu nommes

Si tu demandes “implémente fonction X”, ajoute “et génère 3 tests qui vérifient : (1) le happy path, (2) les entrées invalides, (3) le cas limite Y”. L’obligation d’écrire les tests réduit la marge d’hallucination dans l’implémentation.

Les hallucinations dangereuses à surveiller

Les hallucinations plausibles qui passent en code review. Un reviewer fatigué peut laisser passer une fonction inventée si le nom sonne juste. D’où l’importance de /ultrareview ou d’un outil d’analyse statique en second filtre.

Les fausses citations qui se propagent. Si tu reprends un chiffre inventé dans un article, puis quelqu’un reprend ton article, le chiffre circule comme vrai. Les hallucinations “publicisées” sont un problème éthique autant que technique.

Les hallucinations dans les tests eux-mêmes. Un test écrit avec une expectation inventée passe toujours (pour les mauvaises raisons). C’est pire qu’un test qui échoue à cause d’une hallucination.

L’aveu de ne pas savoir

Un progrès discret de 4.7 : le modèle est plus enclin à dire “je ne suis pas sûr” que son prédécesseur. Sur 4.6, face à une question limite, le modèle produisait une réponse plausible. Sur 4.7, il répond plus souvent “je n’ai pas d’info fiable sur ce point”.

Ce changement est subtil mais important. Ça réduit les hallucinations les plus insidieuses.

Le coût cognitif des hallucinations

Pour un dev, le coût principal des hallucinations n’est pas le debug direct. C’est la méfiance permanente. Savoir que le modèle peut inventer oblige à vérifier systématiquement, ce qui use l’attention et la confiance.

Plus les hallucinations se raréfient (comme sur 4.7 vs 4.6), plus cette méfiance peut se relâcher. Mais elle ne doit pas disparaître complètement : le “vibe coding” sans vérification reste risqué.

FAQ

Les hallucinations disparaîtront-elles un jour ? Pas complètement. C’est une propriété structurelle des LLMs. Elles se raréfient avec chaque release, mais un taux résiduel persistera. Les outils de vérification restent indispensables.

Peut-on entraîner un modèle à ne jamais halluciner ? Non, la limite est théorique autant que pratique. Les techniques (RLHF, constitution AI, instruction tuning) réduisent mais ne suppriment pas.

Comment reporter une hallucination à Anthropic ? Via le feedback interface sur claude.ai ou Claude Code. Ça nourrit les données d’entraînement futures.

---

Je dirige Linkuma, plateforme de netlinking low cost avec 40 000 sites au catalogue et 15 000 clients. On produit beaucoup de contenu IA et on a structuré des workflows anti-hallucination. Retours terrain sur linkuma.com, promos hebdo sur deals.linkuma.com.