Votre assistant IA vient de vous rédiger une note interne. Elle est bien tournée, le ton est professionnel, les chiffres semblent justes. Sauf qu’ils sont malheureusement faussés. Ce scénario, ce n’est pas une hypothèse de travail : c’est ce qu’on appelle des hallucinations IA, et ça arrive tous les jours dans des organisations qui pensaient avoir pris les bonnes précautions. En 2024, même GPT-4 se trompait dans un cas sur cinq sur des sujets techniques pointus. Pour les DSI et RSI qui déploient des chatbots ou des systèmes RAG sur des données critiques, comprendre ce phénomène n’est plus optionnel.
Qu’est-ce qu’une hallucination IA ?
Une réponse convaincante n’est pas forcément une réponse fiable
La compagnie aérienne Air Canada en a fait l’expérience à ses dépens. Son chatbot avait promis à un passager une réduction tarifaire en cas de deuil. Le problème ? Cette réduction n’existait pas. Le tribunal a pourtant condamné la compagnie à l’honorer. C’est ça, une hallucination IA : une information fausse, présentée avec une assurance totale, qui produit des effets bien réels.
La définition d’une hallucination IA est, en apparence, simple. Il s’agit d’un résultat produit par un modèle de langage qui s’écarte des faits, invente des données ou cite des sources inexistantes, tout en adoptant le ton et la forme d’une réponse parfaitement légitime. Le problème ne vient pas d’un bug visible. Il vient précisément du fait que la réponse paraît cohérente.
Source : IBM Think – Qu’est-ce que les hallucinations d’IA ?
L’hallucination IA ne se manifeste pas comme une erreur évidente. Elle se glisse dans des réponses bien construites, avec un vocabulaire adapté et une syntaxe irréprochable. C’est ce qui la rend particulièrement difficile à détecter sans supervision humaine ou mécanisme de validation automatisée.
Pour un DSI ou un RSI qui déploie un assistant IA sur des données métier sensibles, que ce soient des montants de remboursement, des clauses contractuelles ou des réglementations internes, cette caractéristique change radicalement l’approche du risque.
Pourquoi les modèles d’IA répondent même quand ils ne savent pas
Comprendre pourquoi les LLM hallucinent, c’est d’abord comprendre comment ils fonctionnent. Un modèle de langage ne « connaît » rien au sens strict. Il prédit, à chaque étape, quel mot ou groupe de mots a la probabilité la plus élevée de suivre ce qui précède, en s’appuyant sur les patterns statistiques absorbés lors de son entraînement. Il ne vérifie pas. Il ne consulte pas de source en temps réel. Il génère.
Cette architecture est performante pour de nombreuses tâches : reformuler un texte, synthétiser un document, répondre à des questions de culture générale. Elle atteint ses limites dès qu’on lui soumet des questions précises sur des données propriétaires, des réglementations récentes ou des informations absentes de ses données d’apprentissage. Faute de réponse certaine, le modèle en construit une vraisemblable. C’est là qu’on entre dans le territoire de l’hallucination.
Source : Algos AI – IA d’entreprise sans hallucination
Selon une étude relayée par le Stanford Institute for Human-Centered AI, les modèles de langage commettent des erreurs juridiques graves dans une très grande proportion des cas complexes. Certains chatbots juridiques inventent des lois dans près de 30 % des requêtes difficiles.
Ce comportement est d’autant plus problématique que le modèle ne sait pas qu’il hallucine. Contrairement à un expert humain qui peut reconnaître les limites de ses connaissances, un LLM sans garde-fou répond systématiquement, avec la même fluidité, qu’il soit sur un terrain solide ou en train de fabriquer.
Où apparaissent les hallucinations IA dans les projets d’entreprise ?
Corpus documentaire incomplet, obsolète ou contradictoire
Dans les projets d’entreprise fondés sur une architecture RAG (Retrieval-Augmented Generation), c’est souvent le corpus documentaire qui est en cause, bien plus que le modèle lui-même. Quand les documents source contiennent des informations contradictoires, par exemple deux versions d’une même règle de remboursement qui se contredisent, le modèle ne tranche pas : il puise dans les deux selon sa prédiction du moment. La réponse peut être cohérente en surface et fausse sur le fond.
Ce phénomène est courant dans les organisations où la documentation a été produite sur plusieurs années, par différentes équipes, sans gouvernance éditoriale stricte. Un guide opérationnel à destination des gestionnaires peut contredire un document de référence plus ancien encore présent dans le corpus. Le modèle, lui, indexe.
Source : Rubrik – Hallucinations de l’IA : le guide complet
Avant d’optimiser le modèle, auditez votre corpus. Un document contradictoire ou obsolète est une source d’hallucinations quasi certaine dans un système RAG. La qualité de la réponse ne peut jamais dépasser la qualité de ce qu’on lui soumet en entrée.
Mauvais découpage des documents et perte de contexte
Le chunking consiste à fragmenter les documents source en segments stockés dans une base vectorielle pour permettre la recherche sémantique. Ce découpage a un impact direct sur la pertinence des réponses. Un segment trop court perd son contexte d’origine. Un segment mal délimité peut fusionner deux règles distinctes et faire croire au modèle qu’elles s’appliquent simultanément.
Ce qui compte, c’est que chaque fragment « sache d’où il vient ». Une clause extraite d’un guide à destination des assurés n’a pas la même portée opérationnelle qu’une clause issue d’un référentiel interne à destination des gestionnaires de dossiers. Sans cette information contextuelle intégrée dans le chunk, le modèle traite les deux sources avec le même poids.
Questions utilisateurs ambiguës ou hors périmètre
Une question vague ou formulée sans contexte suffit à déstabiliser un système RAG. Si un utilisateur soumet une requête sur un sujet que le corpus ne couvre pas, le modèle tentera quand même de répondre. C’est exactement ce type de situation que les équipes Mind7 ont rencontré en phase de test chez Unéo : un utilisateur avait posé une question sur le vainqueur de la Coupe du monde de rugby. Sans document de référence pertinent, le système aurait pu produire une réponse inventée de toutes pièces, formulée avec la même assurance que s’il avait répondu à une vraie demande de remboursement.
Les questions hors périmètre sont inévitables en production. Ce n’est pas une hypothèse d’école, c’est le quotidien de tout déploiement de chatbot en environnement réel. La question n’est donc pas de les anticiper toutes, mais d’avoir un mécanisme pour s’y refuser sans générer d’hallucination.
Comment réduire les hallucinations IA dans un chatbot ou un RAG ?
Améliorer la qualité du corpus avant d’optimiser le modèle
La tentation, dans un projet IA, est de chercher d’abord à améliorer le modèle : changer de LLM, affiner les paramètres, tester une nouvelle version. Ce n’est pas là que se gagne la fiabilité. Les retours d’expérience terrain, y compris ceux de Mind7 sur le projet Unéo, le montrent clairement : la qualité du corpus documentaire est le facteur dominant dans la qualité des réponses.
Cela implique un travail amont avec les équipes métier qui n’est ni automatisable ni délégable à la technique : repérer les documents contradictoires, dater les sources, exclure les versions obsolètes, harmoniser le vocabulaire sur les termes à fort enjeu. Ce travail prend du temps. Il conditionne tout le reste.
Reformuler les questions pour enrichir le contexte
Plutôt que de transmettre telle quelle la question d’un utilisateur à la base vectorielle, il est possible de l’enrichir avant la recherche. Cette étape, appelée query reformulation, consiste à réécrire la question en ajoutant du contexte : quel est le cadre de la demande, quel périmètre fonctionnel est concerné, quel rôle occupe l’utilisateur.
Des stratégies plus avancées consistent à générer plusieurs formulations distinctes d’une même question, à interroger le corpus avec chacune d’elles, puis à sélectionner ou combiner les réponses les plus pertinentes selon des critères de score. Cette approche réduit la dépendance à une formulation unique, souvent imprécise dans les interfaces de chat.
Mettre en place un seuil de confiance avant d’afficher une réponse
Un système RAG bien calibré ne répond pas à chaque requête. Quand les documents récupérés ne correspondent pas suffisamment à la question posée, afficher une réponse construite sur des bases fragiles est plus dangereux que de ne rien afficher.
Ce mécanisme repose sur un score de pertinence : si les fragments récupérés n’atteignent pas un certain poids dans la réponse générée, le système renvoie un message indiquant qu’il ne dispose pas d’éléments suffisants. C’est inconfortable pour l’utilisateur au premier abord. C’est pourtant la seule façon d’éviter qu’une réponse plausible mais fausse soit prise pour acquise.
Source : Génération IA – Hallucinations, peut-on faire confiance à ChatGPT ?
Avec une architecture RAG correctement configurée, le taux d’erreurs factuelles tombe généralement entre 1 % et 3 %, contre des niveaux bien plus élevés sur les mêmes questions posées à un LLM sans ancrage documentaire.
Afficher les sources pour rendre la réponse vérifiable
Afficher les sources utilisées pour générer une réponse est une pratique simple qui renforce la confiance des utilisateurs et rend les hallucinations détectables. Quand un utilisateur peut remonter au document original, il peut vérifier, corriger, et signaler l’écart. Ce simple mécanisme crée une boucle de vérification humaine qui complète, utilement, les garde-fous techniques.
Cas concret Unéo : comment Mind7 a travaillé sur la réduction des hallucinations IA
Le point de départ : un assistant RAG confronté à la qualité du corpus
Unéo, mutuelle du ministère des Armées, a engagé Mind7 dans le déploiement d’un assistant conversationnel fondé sur une architecture RAG. L’ambition était d’automatiser le traitement de questions des assurés et des gestionnaires sur les garanties, les remboursements et les procédures internes.
Très tôt dans le projet, les équipes ont constaté que la qualité des réponses dépendait moins du modèle que de ce qu’on lui donnait à lire. Le corpus documentaire d’Unéo, constitué au fil des années, contenait des formulations contradictoires sur certains montants de remboursement : un document stipulait une règle dans un sens, un autre la formulait différemment. Résultat : le système produisait des réponses variables sur des questions identiques, selon le document que la base vectorielle remontait en premier.
Le travail sur le découpage et le contexte documentaire
L’une des interventions les plus déterminantes a porté sur le découpage des documents. Les fichiers ont été fragmentés en segments structurés, enrichis d’informations contextuelles : nom du document, chapitre, section, destination, si le contenu s’adressait à un gestionnaire ou à un assuré. Cette métadonnée contextuelle, intégrée dans chaque chunk, permettait au système de savoir non seulement ce qu’il citait, mais dans quel cadre cela s’inscrivait.
L’impact a été direct sur la pertinence des réponses. Une information sur un plafond de remboursement n’a pas la même valeur opérationnelle selon qu’elle provient d’une note interne ou d’un document contractuel. Avec ce contexte disponible, le modèle pouvait mieux pondérer ses sources avant de générer une réponse.
La reformulation des questions pour améliorer la pertinence
Pour chaque question soumise par un utilisateur, l’équipe technique a mis en place une stratégie de reformulation multiple. La question était réécrite en trois formulations distinctes, chacune enrichie du contexte opérationnel : type de demande, profil de l’utilisateur, périmètre fonctionnel concerné. Ces trois formulations étaient ensuite soumises à la base vectorielle, et les réponses obtenues comparées ou combinées selon des critères de score.
Cette mécanique est invisible pour l’utilisateur final. Une seule question en entrée, une seule réponse en sortie. Mais entre les deux, le système opère plusieurs cycles de recherche simultanés pour maximiser la pertinence du passage documentaire sélectionné. Ce travail itératif a produit des améliorations mesurables sur les questions formulées de façon imprécise ou trop générale.
Le seuil de confiance : savoir ne pas répondre
L’un des choix les plus structurants du projet a été d’introduire ce que Stéphane Hugot, architecte du projet chez Mind7, appelle un « rupteur ». Concrètement, avant d’afficher une réponse, le système évalue le poids des éléments documentaires dans la réponse construite. Si ce poids est inférieur à un seuil déterminé, le chatbot n’affiche rien. Il indique simplement qu’il ne dispose pas d’informations suffisantes pour traiter la demande.
Ce choix va à l’encontre du comportement naturel d’un LLM, qui est de toujours produire quelque chose. Il demande un calibrage fin : un seuil trop élevé, et le système refuse de répondre à des questions légitimes ; trop bas, et les hallucinations passent. Ce travail d’ajustement a mobilisé plusieurs semaines d’itération, avec à la clé une réduction significative des réponses erronées en production.
La boucle de feedback utilisateur pour améliorer le système
Dès la mise en production partielle, Mind7 a institué une boucle de feedback hebdomadaire. Chaque réponse pouvait être notée comme satisfaisante ou non. En cas d’insatisfaction, l’utilisateur était invité à saisir la réponse attendue, ce qui permettait une analyse des causes réelles d’échec.
Au fil des semaines, les équipes ont identifié les root causes récurrentes : sources manquantes dans le corpus, découpage insuffisant, questions hors périmètre, problème de logique dans la réponse générée. Environ 45 % des retours négatifs initiaux étaient inexploitables, faute de contexte fourni par l’utilisateur, ce qui a conduit à revoir l’interface pour mieux guider les contributions. Ce cycle itératif a également permis d’embarquer progressivement les équipes métier d’Unéo dans la co-construction de la solution, transformant un projet technique en démarche collaborative.
Industrialiser une IA fiable : les points clés pour DSI et RSI
Concevoir une architecture modulaire dès le départ
L’IA générative évolue à un rythme qui rend caduc, en quelques mois, un choix technologique qui semblait solide. La seule façon d’absorber cette obsolescence sans tout reconstruire est de concevoir l’architecture par blocs découplés, chaque composant pouvant être retiré et remplacé indépendamment.
Chez Mind7, cette approche a permis de changer de LLM sur un projet sans toucher à la base vectorielle ni à la couche de reformulation. Le passage de Mistral à OpenAI a été opéré comme on change une pièce dans un système : sans tout démonter. Cette modularité n’est pas un détail d’architecture. C’est une condition de pérennité dans un écosystème qui se reconfigure tous les six mois.
Source : Smartpoint – Industrialisation RAG, piloter l’IA générative en production
Exiger une architecture modulaire dès le cadrage du POC, c’est se prémunir contre l’obsolescence technologique. Un LLM remplacé demain ne doit pas remettre en cause six mois de travail sur la qualité des données et du découpage.
Préparer le passage du POC à la production
Entre 80 % et 90 % des POC IA n’atteignent jamais la production. Les raisons sont souvent les mêmes : architecture non scalable, qualité des données sous-estimée, absence de gouvernance, coûts d’exploitation mal anticipés.
Chez Unéo, le POC a été traité dès le départ comme un prototype industrialisable, pas comme un démonstrateur jetable. En six à huit semaines, l’équipe a livré une version testable, avec des tests de charge réalisés pour s’assurer que l’architecture tiendrait sous des volumétries réelles. Ce rythme a été possible grâce à un portage fort de la direction générale : quand un blocage métier ou technique survenait, une décision était prise rapidement, sans laisser le projet s’enliser. La solution a finalement été ouverte aux assurés, ce qui représente un passage en production à part entière, pas une extension de démo.
Garder l’explicabilité au cœur du dispositif
L’explicabilité n’est pas un débat philosophique sur l’IA. Pour un DSI ou un RSI, c’est une exigence opérationnelle concrète : quand une réponse est mauvaise, vous devez pouvoir comprendre pourquoi. Quel document a été utilisé ? Quel score a-t-il obtenu lors de la recherche ? La reformulation de la question a-t-elle fonctionné ? Le seuil de confiance a-t-il été franchi ?
Sans visibilité sur ces mécanismes internes, vous vous retrouvez à observer l’entrée et la sortie du système sans pouvoir agir sur ce qui se passe entre les deux. L’IA générative est par nature non déterministe, ce qui renforce encore davantage la nécessité de construire des outils d’observation et de traçabilité dès la conception. Ce n’est pas un ajout après coup : c’est un prérequis pour exploiter un système IA en production dans la durée, et pour rendre des comptes à vos métiers, vos équipes de conformité et vos utilisateurs.
