Les hallucinations de l'IA : et si on se trompait de combat ?

Premier article d'une série sur les angles morts du développement avec l'IA.

L'API qui n'existait pas

La semaine dernière, j'ai utilisé une propriété entry.imageHtml pour personnaliser une palette dans une librairie open source. Le code compilait. L'interface s'affichait. Pas d'erreur. Juste un placeholder vide à la place de mon élément.

J'ai cherché le bug un moment. Puis j'ai fini par ouvrir le code source. Verdict : entry.imageHtml n'existe pas. L'IA qui m'a généré ce code avait inventé une variante crédible d'une propriété qui aurait pu exister, par cohérence avec le reste de l'API. Une hallucination dans toute sa banalité : plausible, indétectable à la lecture, létale à l'exécution.

Cette anecdote, je pourrais la multiplier par dix dans mes carnets des derniers mois. Et c'est précisément ce qui m'amène à écrire cet article.

Le débat mal posé

Les hallucinations de l'IA sont devenues le marronnier du discours tech. On en parle partout. On les redoute. On attend le prochain modèle qui les fera disparaître. On compare les benchmarks de factualité.

Je propose une autre lecture. Architecte d'entreprise depuis plus de 35 ans, je conçois des solutions de développement assisté par IA. J'ai notamment créé un framework de dev IA et je suis l'architecte de Steppium, une solution de développement de parcours. Je code suffisamment moi-même pour voir où les choses se cassent vraiment. Et j'en suis arrivé à une conviction qui dérange : traiter les hallucinations comme un défaut à corriger côté modèle est une erreur stratégique. Il faut les traiter comme une caractéristique structurelle — et concevoir tout ce qu'il y a autour.

Oui, les hallucinations sont aussi un problème de modèle. Les éditeurs y travaillent, et c'est tant mieux. Mais ce n'est pas là qu'il faut investir, quand on est architecte ou décideur dans une entreprise qui intègre l'IA. Ce n'est pas votre levier. Votre levier, c'est l'humain autour.

Trois patterns que j'ai documentés

Soyons concrets. Voici quelques hallucinations rencontrées sur des projets réels — pas en théorie, sur du code parti en production ou qui aurait pu y partir.

La surconfiance après inspection superficielle. J'ai un jour validé un fork open source comme "viable" après un test rapide : je chargeais un fichier vide, l'interface s'affichait, donc le fork tenait debout. Décision actée, architecture commitée. Puis on a fait l'intégration réelle : cinq bugs critiques bloquants sur les chemins critiques. Le projet upstream n'était pas "à finir" — il était "à moitié développé avec des fonctions essentielles cassées". Coût : deux à trois sessions de développement perdues. L'IA avait confirmé ma première impression au lieu de me contredire.

Le fix inventé. J'ai mis en place un audit où une IA examinait des parcours utilisateurs et proposait des corrections. Ses recommandations étaient extrêmement détaillées : regex de validation, formats précis, codes pays. En métacognition — quand j'ai demandé à l'IA d'auditer son propre output — elle a fini par admettre, je cite : "Mes recommandations de fix sont très détaillées, mais cette précision est souvent inventée plutôt que déduite des données disponibles." La précision donne l'illusion de l'expertise. Elle est en réalité l'empreinte du biais.

Le quota qui se remplit tout seul. Toujours dans ce même audit, sans contrainte explicite, l'IA produisait systématiquement le même nombre d'issues, quel que soit le parcours analysé. Un parcours trivial à deux étapes ? Sept issues. Un parcours complexe à vingt étapes ? Sept issues aussi. Le modèle ne mesurait pas la complexité réelle ; il remplissait un format implicite.

Ce qui fait la différence

Dans chaque cas, ce qui a séparé la régression en production du bug rattrapé, c'est un dispositif humain : un protocole de spike plus exigeant qui aurait imposé d'éprouver les chemins critiques avant de commiter ; une instruction de prompt qui interdit au modèle de proposer des corrections qu'il ne peut pas tracer dans les données ; une limite de volume imposée explicitement.

Ces dispositifs ne dépendent pas de la version du modèle. Ils survivent à GPT-5, à Claude 6, à ce qui viendra après. Ils relèvent de choix d'architecture, de gouvernance, de discipline d'équipe. Ce sont des choses qu'on construit, qu'on documente, qu'on transmet.

J'ai vu, sur des projets clients, deux équipes accéder au même modèle sur des cas d'usage proches. La première a livré en quelques semaines une fonctionnalité adoptée par ses utilisateurs. La seconde a accumulé six mois de POC et fini par "perdre confiance dans l'IA". La différence ? Un référentiel partagé des erreurs rencontrées, une règle écrite que rien n'est livré tant qu'un humain ne l'a pas validé sur un scénario réel, et des prompts cadrés par des contraintes explicites.

Aucune de ces compétences n'est purement technique. Toutes sont profondément humaines.

La présomption d'erreur

S'il faut retenir un seul principe directeur, c'est celui-là : adopter une discipline de relecture qui considère par défaut que l'IA s'est trompée, charge à l'humain de prouver le contraire.

C'est l'inverse exact du réflexe naturel. Spontanément, on lit la sortie d'un LLM, ça paraît cohérent, on valide. La présomption d'erreur renverse la charge : tant que l'humain n'a pas vérifié, la sortie est suspecte. Pas par défiance, par méthode. C'est inconfortable, c'est plus lent — et c'est ce qui sépare une équipe qui livre d'une équipe qui empile les régressions.

Ce que ces dispositifs n'éliminent pas

Une réserve, cependant : ces dispositifs ne sont pas une garantie. Ils sont une réduction de surface.

Quand une IA invente une propriété entry.imageHtml, je peux la détecter parce que la palette s'affiche vide à l'écran. C'est une hallucination bruyante. Mais l'hallucination la plus dangereuse n'est pas celle-là. C'est celle qui invente une condition silencieuse dans une logique métier, qui passe les tests parce qu'elle est cohérente avec les cas imaginés, et qui ne pète qu'en production sur un cas rare. Là, ni la lecture du source ni la validation utilisateur ne suffisent.

Cela ne contredit pas la thèse — cela la complète. Les dispositifs humains réduisent la surface ; ils ne l'éliminent pas. Il faut donc accepter un coût résiduel et concevoir pour qu'il soit rattrapable en aval : observabilité en production, alertes sur les comportements inattendus, capacité de rollback rapide, ségrégation des périmètres où l'erreur est tolérable et de ceux où elle ne l'est pas.

Le piège de la vitesse

Une nuance à intégrer dans la culture d'équipe : ces dispositifs coûtent du temps. Et le réflexe classique, quand la pression de livraison monte, c'est de les sacrifier en premier. On arrête de lire le source. On accepte la sortie de l'IA sans la challenger. On annonce "ça marche" parce que la démo passe.

Or, c'est précisément quand le temps manque que ces dispositifs protègent le mieux. La discipline doit augmenter sous la pression, pas diminuer.

Ce que cela change

Pour la majorité des entreprises qui intègrent l'IA dans leurs produits — pas pour les laboratoires qui repoussent la frontière, mais pour vous, lecteurs, qui intégrez —, le différenciateur compétitif n'est plus le modèle. Tout le monde a accès aux mêmes, à quelques semaines près. Ce qui distingue une entreprise qui livre de la valeur d'une entreprise qui empile les POC ratés, c'est la qualité humaine autour de la machine.

Concrètement : arrêter d'attendre du prochain modèle qu'il résolve un problème qui ne se résoudra pas entièrement côté modèle. Investir dans ce que j'appellerais l'ingénierie de la collaboration humain-IA. Les prochains articles de cette série en exploreront les briques une par une : protocoles, capitalisations, observabilité, défense en profondeur.

J'ai par ailleurs documenté neuf biais récurrents en demandant à un modèle d'auditer ses propres sorties — la "précision inventée" citée plus haut n'en est qu'un. J'y reviendrai dans un article dédié.

Cet article ouvre une série sur les angles morts du développement avec l'IA. Dans les prochains, j'aborderai d'autres problèmes qu'on accepte par fatalité — et pour chacun, je proposerai des dispositifs concrets, éprouvés sur mes propres projets.

Si vous y reconnaissez vos propres erreurs : tant mieux. La maturité, en IA comme ailleurs, commence par savoir nommer ce qu'on rate.