Pourquoi l'IA invente du code (et comment l'en empêcher)

Tu demandes à une IA de coder une fonctionnalité. Elle te répond avec assurance, le code est propre, bien commenté, convaincant. Tu le lances : erreur. La bibliothèque qu'elle importe n'existe pas. Ou la fonction qu'elle appelle a disparu il y a deux ans. Ou l'API qu'elle utilise n'a jamais eu ce paramètre.

Ce n'est pas un bug de ton outil, et ce n'est pas de la malchance. C'est un comportement structurel des modèles de langage, et il se comprend très bien. Mieux : une fois compris, il se contient. Chez nous, ces parades font partie du quotidien, et elles transforment l'IA d'un stagiaire imprévisible en un collègue fiable.

D'où viennent les hallucinations, vraiment

Un modèle de langage ne « sait » pas ce qu'est une bibliothèque. Il a appris, sur des milliards de lignes de code, à prédire la suite la plus plausible d'un texte. Quand tu lui demandes d'envoyer un e-mail en Node, il produit ce qui ressemble le plus à ce qu'il a vu : un import, un nom de paquet crédible, des fonctions aux noms logiques.

Le problème : plausible et vrai, ce n'est pas la même chose. Trois mécanismes précis fabriquent du code faux.

1. L'interpolation : le paquet qui devrait exister

Le modèle a vu stripe, stripe-node, des centaines de wrappers. Quand tu lui demandes quelque chose d'un peu rare, il génère un nom dans le même moule : stripe-invoice-helper, par exemple. Ce paquet n'existe pas, mais il aurait pu exister, et c'est exactement ce que le modèle optimise. C'est le même mécanisme qui invente des fonctions : user.getFullProfile() sur une bibliothèque qui n'a que user.get().

Ce mécanisme a même créé un risque de sécurité documenté : des attaquants publient de vrais paquets malveillants sous les noms que les IA inventent souvent. Ça s'appelle le slopsquatting. Installer aveuglément ce que l'IA suggère, c'est ouvrir cette porte.

2. La coupure de connaissance : le monde a bougé depuis

Tout modèle a une date de coupure d'entraînement. L'écosystème JavaScript, lui, bouge tous les mois. Résultat classique en 2026 : l'IA te propose la syntaxe de React Navigation d'il y a trois versions, un app.json d'Expo périmé, ou une API Firebase remplacée depuis dix-huit mois. Le code était juste, un jour. Plus maintenant.

C'est la source d'hallucination la plus sournoise, parce que le code a vraiment existé : les forums en sont pleins, la recherche Google le confirme presque, et l'erreur ne se révèle qu'à l'exécution.

3. Le contexte manquant : elle remplit les trous avec de la fiction

Quand l'IA ne voit pas ton projet, elle invente le décor. Elle suppose une structure de fichiers, des noms de variables, une version de framework. Dans une conversation de navigateur où tu colles des extraits, elle finit par mélanger ce que tu lui as montré et ce qu'elle a imaginé, avec un aplomb constant : les modèles sont entraînés à répondre, pas à dire « je ne sais pas ».

Les 5 parades concrètes

Voici ce qui marche vraiment, classé du plus simple au plus structurant. Les deux premières se mettent en place en cinq minutes.

Parade 1 : verrouille les versions dans ta demande

Ne demande jamais « fais-moi X avec React Native ». Demande « fais-moi X avec React Native 0.81, Expo SDK 54, React Navigation 7 ». Encore mieux : colle ton package.json dans le contexte. Le modèle cesse de piocher dans dix ans de syntaxes contradictoires et se cale sur la tienne.

# Le réflexe avant toute session de code avec une IA :
# donne-lui la réalité de ton projet, pas une idée générale.
cat package.json
npx expo --version

Cette parade élimine à elle seule la majorité des erreurs de version, qui sont la première cause de code faux en mobile.

Parade 2 : exige la source, vérifie l'existence

Deux habitudes courtes :

• Pour toute bibliothèque qu'une IA te propose d'installer, 30 secondes de vérification : la page npm existe, le dépôt est actif, les téléchargements sont réels. Un paquet inventé ne passe pas ce filtre.
• Dans ta demande, ajoute une consigne du type : « n'utilise que des API dont tu es certain, et si tu n'es pas sûr d'une signature, dis-le explicitement au lieu de deviner ». Ce n'est pas magique, mais ça réduit mesurablement l'aplomb injustifié, et ça t'indique où regarder.

Parade 3 : donne-lui les vrais fichiers, pas des extraits

La moitié des hallucinations de contexte disparaissent quand l'IA travaille dans ton projet au lieu d'en imaginer un. C'est toute la différence entre un chat de navigateur et un outil comme Claude Code, qui vit dans ton terminal : il lit tes vrais fichiers, ta vraie structure, tes vraies dépendances avant d'écrire une ligne.

Si tu restes dans le navigateur, applique le principe manuellement : colle le fichier entier plutôt que le bout qui te semble pertinent, et redonne le contexte quand la conversation devient longue. Une conversation qui a accumulé trop d'allers-retours contradictoires ne se répare pas : repars de zéro avec un contexte propre.

Parade 4 : fais exécuter, pas seulement écrire

Le test le plus fiable contre une hallucination reste l'exécution. Un import inventé explose à la première seconde. Organise donc ta boucle de travail autour de ça :

1. Demande une petite unité de code, pas une fonctionnalité entière.
2. Lance immédiatement : compilation, test, écran.
3. Si ça casse, colle le message d'erreur brut : les IA sont excellentes pour corriger une erreur réelle, bien meilleures que pour éviter une erreur hypothétique.
4. Commit quand c'est vert, puis unité suivante.

Les outils en terminal ferment cette boucle tout seuls : ils lancent les tests, lisent l'erreur, corrigent, relancent. L'hallucination ne survit pas à ce cycle, parce qu'elle se fait attraper au premier tour au lieu de s'empiler sur dix fichiers.

Parade 5 : le fichier de contexte, ta mémoire de projet

La parade la plus structurante : un fichier de consignes à la racine du projet (un CLAUDE.md, un AGENTS.md, peu importe le nom) que ton outil lit à chaque session. Tu y écris une fois pour toutes :

• Les versions exactes de tes frameworks et les syntaxes à utiliser
• Les bibliothèques autorisées, et celles que tu refuses
• Les conventions de ton projet : structure, nommage, gestion d'erreurs
• Les pièges déjà rencontrés : « ne jamais utiliser telle API dépréciée »

Chaque erreur corrigée devient une ligne de ce fichier, et ne se reproduit plus. Au bout d'un mois, ton IA fait dix fois moins d'erreurs que celle de ton voisin, non parce que le modèle est meilleur, mais parce que tu as capitalisé.

Ce que ça change, au fond

Il faut être honnête sur un point : les hallucinations ne disparaîtront jamais complètement. Elles sont le revers du mécanisme même qui rend ces modèles capables d'écrire du code. Les modèles récents hallucinent nettement moins que ceux d'il y a deux ans, et les outils qui exécutent le code ont changé la donne, mais le risque résiduel existe et existera.

La conclusion pratique n'est pas « méfie-toi de l'IA » ni « fais-lui confiance » : c'est « travaille avec une méthode qui attrape les erreurs tôt ». Verrouille les versions, vérifie les paquets, donne le vrai contexte, exécute tout de suite, capitalise dans un fichier. Avec cette méthode, l'IA écrit l'essentiel de ton code et tu gardes l'essentiel du contrôle.

C'est exactement la différence entre les gens qui « ont essayé l'IA, ça marche pas » et ceux qui livrent des applications entières avec. L'outil est le même. La méthode, non.