AI RAG : fiabiliser l’IA générative dans le SI 

Un LLM qui répond avec assurance à côté du sujet, cite une source inventée ou fabrique une clause de contrat : vous avez probablement déjà vu ça. Ce n’est pas un bug passager : les hallucinations sont une propriété structurelle des grands modèles de langage, mathématiquement démontrée. Le RAG (Retrieval-Augmented Generation) est la réponse architecturale la plus adoptée pour y remédier. En effet, avant de générer une réponse, le modèle va chercher dans vos documents. Mais le déploiement du RAG nécessite une certaine expertise, que nous allons vous livrer dans cet article. Retour sur les enseignements de plusieurs années de terrain, dont un cas concret chez Unéo. 

AI RAG : le principe en bref 

RAG définition : rechercher dans le corpus avant de générer une réponse 

Un grand modèle de langage encode son savoir dans ses paramètres lors de l’entraînement. Cette connaissance est figée à la date de coupure du modèle et ne peut pas intégrer les données internes de votre organisation comme les réglementations propres, les politiques tarifaires ou encore les bases de connaissances métier. Par ailleurs, la capacité des LLM à restituer fidèlement des faits précis décroît avec la rareté de ces faits dans le corpus d’entraînement. 

Le Retrieval-Augmented Generation répond à ces limites en découplant la mémoire factuelle (des documents externes) de la capacité de synthèse (le LLM). Formalisé par Lewis et al. en 2020 (NeurIPS), le principe est le suivant : avant de générer une réponse, le modèle consulte une base documentaire, puis en extrait les passages pertinents et les intègre au prompt. La réponse produite est ancrée dans des sources vérifiables et actualisables sans réentraînement. 

Le pipeline RAG se décompose en trois phases distinctes, chacune appelant des choix d’architecture indépendants : 

1. En amont (offline), les documents sont découpés en segments, transformés en vecteurs numériques par un modèle d’embedding, puis stockés dans une base vectorielle.  

2. Au moment de la requête (online), la question de l’utilisateur est elle-même vectorisée et comparée aux vecteurs du corpus par similarité cosinus : les passages sémantiquement les plus proches sont sélectionnés.  

3. Enfin, ces passages enrichissent le prompt envoyé au LLM, qui génère une réponse guidée par ce contexte.

Pourquoi la qualité d’un AI RAG dépend d’abord du corpus documentaire 

Qualité métier des sources : éviter les règles contradictoires 

Avant toute décision technique, voici la question que vous devez vous poser : vos documents disent-ils tous la même chose ? 

Chez Unéo, mutuelle de santé des militaires français, Mind7 Technologie a identifié ce problème dès les premières semaines du projet. Le corpus contenait plusieurs documents traitant des mêmes garanties de remboursement avec des montants et des conditions contradictoires, parfois au sein d’un même fichier. Dans un système non déterministe comme un LLM, cette ambiguïté produit des effets difficilement prévisibles. Par exemple la probabilité que le retrieval remonte le mauvais document n’est pas nulle, et la réponse générée sera factuellement fausse, formulée avec une confiance totale. 

La mise en qualité du corpus est donc un prérequis métier autant que technique. Elle implique un dialogue avec les équipes opérationnelles pour identifier les doublons, les règles périmées, les contradictions entre politiques internes. Ce travail ne peut pas être délégué au LLM.

Structuration documentaire : donner du contexte au modèle 

Un document mal structuré, c’est de l’information sans adresse. Le modèle d’embedding encode le contenu d’un passage, mais pas son contexte d’appartenance (à quel document il appartient, quelle section ou encore quel type de destinataire). Ce contexte conditionne pourtant le sens. Une règle de remboursement formulée dans un guide assuré et la même règle dans une note interne à un chargé de clientèle n’ont pas la même portée opérationnelle. 

Sur le projet Unéo, chaque chunk a été enrichi de métadonnées structurées : identifiant du document parent, titre de section, type de document, version, audience cible. Ces métadonnées ont été indexées conjointement au vecteur sémantique, permettant au retrieval d’appliquer des filtres en plus de la similarité vectorielle. Cette technique, dite de filtered retrieval, améliore la précision des résultats sans alourdir le modèle lui-même. 

Chunking : découper sans perdre le sens métier 

Le chunking est l’une des variables les plus sous-estimées d’un pipeline AI RAG. Un chunk trop grand introduit du bruit dans le contexte transmis au LLM. Un chunk trop petit perd sa cohérence sémantique et peut être remonté hors contexte. Un passage sur les délais de remboursement dentaire, sorti de son environnement logique, peut théoriquement répondre à une question sur l’optique. Le résultat n’est pas faux au sens strict, mais il n’est pas pertinent. 

Trois stratégies coexistent :  

• le chunking fixe (par seuil de tokens, simple mais sémantiquement aveugle),  

• le chunking sémantique (découpe aux ruptures de sens, plus précis, plus coûteux), 

• le chunking hiérarchique (arbre document/section/paragraphe, permettant de remonter à différents niveaux de granularité selon la requête).  

Sur le projet Unéo, une approche hybride a été retenue : seuils de tokens avec respect des frontières logiques de la structure documentaire, enrichie des métadonnées de filiation décrites ci-dessus. 

Data ready for generative AI : préparer les données avant le projet 

Avant d’écrire la première ligne de code, un audit du corpus s’impose : inventorier les sources candidates, estimer leur volume, identifier leur format (PDF, Word, HTML, base structurée), repérer les doublons fonctionnels et les documents périmés. Un document abrogé dans le corpus est une source d’hallucination structurelle. La date de validité doit être une métadonnée obligatoire, pas optionnelle. 

L’extraction de texte depuis des PDFs produit rarement un texte propre : coupures de mots en fin de ligne, en-têtes répétés dans chaque chunk, tableaux extraits en séquence linéaire sans structure relationnelle. Ces opérations de nettoyage relèvent d’un pipeline de pré-traitement reproductible, car il sera réexécuté à chaque mise à jour du corpus. 

Comment réduire les hallucinations dans une architecture AI RAG 

Reformulation des questions : enrichir la demande utilisateur 

Un utilisateur formule sa question en langage naturel, souvent imprécis du point de vue du retrieval. « Je veux rembourser des lunettes » n’est pas la même requête vectorielle que « conditions de prise en charge des équipements optiques pour un assuré du régime militaire », même si l’intention est identique. 

Sur le projet Unéo, l’équipe a mis en place une stratégie de reformulation automatique : la question initiale est réécrite sous plusieurs formes enrichies du contexte métier, et les résultats de retrieval sont fusionnés. Cette technique, parfois appelée query expansion ou HyDE (Hypothetical Document Embeddings) dans des variantes plus avancées, augmente le rappel sans dégrader la précision. Ce que l’utilisateur perçoit comme une requête simple génère en réalité plusieurs recherches simultanées dans le corpus. 

Recherche sémantique et base vectorielle : retrouver les bons passages 

La recherche vectorielle opère sur la similarité sémantique dans un espace de haute dimension. Deux phrases sémantiquement proches (« prise en charge des soins » et « remboursement des consultations médicales ») produiront des vecteurs proches, même sans mot commun. C’est l’avantage fondamental sur la recherche par mots-clés. 

La recherche dense a cependant une faiblesse connue : elle peut manquer des termes rares ou techniques dont la précision est critique (numéros de contrats, codes de garantie, identifiants réglementaires). La meilleure pratique actuelle est la recherche hybride : combinaison d’une recherche dense (vectorielle) et d’une recherche sparse (BM25), avec fusion des scores par Reciprocal Rank Fusion. Cette approche capture à la fois la proximité sémantique et la précision lexicale. 

Sur le projet Unéo, une base vectorielle dédiée a été retenue. Les bases vectorielles spécialisées sont optimisées pour ce type de requête de similarité à grande échelle, avec une latence compatible avec une expérience utilisateur en temps réel. 

Seuil de confiance : savoir ne pas répondre 

L’une des décisions architecturales les plus contre-intuitives est d’apprendre au système à ne pas répondre. Quand le contexte documentaire récupéré est insuffisant, score de similarité faible ou volume de chunks pertinents trop limité, le système émet un message d’incertitude explicite plutôt qu’une réponse plausible mais non étayée. La littérature désigne ce comportement par « selective prediction » ou « abstention ». 

Chez Unéo, un seuil de confiance composite a été mis en place : si le score de similarité moyen des chunks retenus et leur densité sémantique cumulée n’atteignaient pas un niveau minimum, le système refusait de générer et renvoyait un message d’incertitude. Ce mécanisme a éliminé une fraction significative des hallucinations, sans dégrader le taux de réponse sur les questions bien couvertes par le corpus. 

Explicabilité : comprendre pourquoi une réponse a été produite 

Sur un SI d’entreprise soumis à des exigences de traçabilité, savoir qu’une réponse est correcte ne suffit pas. Il faut pouvoir expliquer d’où elle vient : quels passages ont été récupérés, quel document les contient, pourquoi le retrieval a favorisé tel chunk plutôt qu’un autre. 

L’explicabilité conditionne l’auditabilité des réponses, la capacité à contester une décision appuyée sur le système, et l’acceptabilité de l’outil par les équipes métier et les instances de gouvernance. 

Sur le projet Unéo, chaque réponse produite exposait les sources documentaires utilisées, leur score de similarité, et la section d’appartenance du chunk remonté. Ce n’était pas une fonctionnalité ajoutée après coup : c’était une contrainte inscrite dans les premiers choix de conception. 

Industrialiser un projet AI RAG dans un SI d’entreprise 

Architecture modulaire : pouvoir changer de LLM ou de base vectorielle

Le marché des LLM évolue à une vitesse qui rend tout choix de modèle potentiellement sous-optimal en quelques mois. L’architecture AI RAG doit donc être découplée du modèle qu’elle utilise, via des couches d’abstraction stables sur le retriever, le générateur et la base vectorielle. 

Chez Unéo, cette décision a eu un impact concret : le projet avait démarré avec Mistral comme modèle de génération et a migré vers OpenAI sans nécessiter de refonte. La base vectorielle, le pipeline de retrieval, les interfaces utilisateur : rien n’a été reconstruit. « On pouvait retirer une brique comme un système de légo et en mettre une autre », résume Stéphane Hugot. Cette modularité n’est pas un bonus de conception : c’est une exigence de résilience dans un marché qui se réinvente tous les six mois. 

Sécurité et droits d’accès : maîtriser les données exposées au LLM

Un RAG d’entreprise expose des documents internes à un LLM. Le filtrage des droits d’accès doit intervenir au niveau du retrieval, pas au niveau de la génération. Un utilisateur ne doit pouvoir récupérer que les documents auxquels son rôle lui donne accès. Traiter cette contrainte après coup revient à construire un système dont la sécurité est contournable par conception. 

Cela implique que les métadonnées de droits soient indexées dans la base vectorielle et que les requêtes de retrieval intègrent systématiquement un filtre de contrôle d’accès. L’architecture doit prévoir ce filtrage dès le premier sprint. 

Observabilité : suivre la qualité des réponses et du retrieval 

Un RAG en production sans monitoring est une boîte noire. Les métriques à instrumenter incluent la distribution des scores de similarité, le taux de refus (requêtes sous le seuil de confiance), le volume de feedbacks négatifs et leur classification par catégorie d’erreur. 

Le framework RAGAS propose quatre métriques complémentaires pour évaluer un système RAG : la faithfulness (la réponse est-elle fidèle aux chunks récupérés ?), l’answer relevancy (répond-elle à la question ?), la context precision (les chunks récupérés sont-ils tous pertinents ?) et le context recall (les chunks pertinents ont-ils bien été remontés ?). Ces quatre indicateurs permettent de distinguer un problème de retrieval d’un problème de génération et d’orienter les actions correctives vers le bon composant. 

DevOps et CI/CD : opérer le RAG comme un produit logiciel 

Un pipeline AI RAG n’est pas un artefact statique. Le corpus évolue : de nouveaux documents entrent, des règles changent, des sources deviennent obsolètes. Il faut donc traiter le RAG comme un produit logiciel : versionning des documents, tests de régression sur les cas d’usage critiques, pipeline d’intégration continue pour les mises à jour du corpus. 

La gestion du corpus doit intégrer une politique de dépréciation : un document retiré ne doit plus être accessible au retrieval, sous peine de produire des réponses basées sur des règles caduques. Les organisations structurées autour d’exigences réglementaires reconnaîtront ces processus : ils s’apparentent à ceux d’un référentiel documentaire maîtrisé. 

Tests de charge : anticiper le passage à plusieurs centaines d’utilisateurs 

Une base vectorielle qui répond en 200 ms pour dix utilisateurs simultanés peut plafonner à plusieurs secondes pour deux cents. Les goulots d’étranglement sont rarement là où on les attend : la vectorisation des requêtes, la latence du retrieval sous charge et le temps d’inférence du LLM s’additionnent, et leurs comportements sous charge sont non linéaires. 

Sur le projet Unéo, des tests de sollicitation ont été conduits avant l’ouverture aux assurés. L’architecture scalable retenue dès la conception a rendu ces tests concluants sans nécessiter de refonte. C’est précisément cet ordre (anticiper les contraintes de production dans les choix initiaux) qui distingue un POC industrialisable d’un démonstrateur qu’on jette à la fin de la présentation. 

Retour d’expérience Mind7 chez Unéo : du POC AI RAG au pilote industrialisable 

Cadrer le cas d’usage avec la direction et le métier 

Le projet AI RAG chez Unéo visait à permettre aux conseillers, puis aux assurés, d’obtenir des réponses précises sur les garanties de remboursement à partir d’un corpus documentaire interne dense et hétérogène. Avant d’écrire la première ligne de code, Mind7 Technologie a conduit plusieurs ateliers de cadrage avec la direction générale pour identifier les cas d’usage à fort potentiel et fixer des critères de succès mesurables. 

Le sponsorship de haut niveau a été l’un des facteurs les plus déterminants. Un directeur général adjoint a joué un rôle de catalyseur en levant les blocages organisationnels entre IT, métier et sécurité. Sans décision ferme à chaque point de friction, un POC de six semaines se transforme en chantier de dix-huit mois. 

Lancer un POC court sans construire un démonstrateur jetable 

Six à huit semaines : c’est le délai que Mind7 Technologie s’impose sur un POC AI RAG. Assez court pour maintenir l’engagement des parties prenantes, assez long pour produire un résultat représentatif. La contrainte de durée impose une discipline de périmètre : refuser les extensions de scope en cours de sprint, même quand le client cherche naturellement à en ajouter. 

La particularité de ce POC est d’avoir été conçu pour ne pas être jetable. L’architecture modulaire, les choix de base vectorielle, la conception des interfaces ont tous été pensés pour que le passage au pilote soit une continuité, pas une réécriture. 

Collecter les feedbacks utilisateurs pour identifier les causes de non-qualité 

Dès les premières semaines, un dispositif de feedback binaire a été mis en place : réponse satisfaisante ou non, avec obligation de préciser la réponse attendue en cas de retour négatif. Ce dispositif a alimenté un suivi hebdomadaire restitué à l’équipe Unéo. 

L’anecdote la plus parlante : l’une des premières questions posées au chatbot par le sponsor portait sur le vainqueur de la Coupe du monde de rugby. Information absente du corpus d’une mutuelle de santé, évidemment. Mais cet incident a conduit à une conversation productive sur la nécessité de définir précisément le périmètre métier du système et de former les utilisateurs en conséquence. Le feedback hors-sujet est une donnée, lui aussi. 

Classer les erreurs : sources manquantes, mauvais retrieval, confusion de contexte 

Le travail de classification des feedbacks négatifs a révélé plusieurs familles d’erreurs bien distinctes : sources absentes du corpus, documents pertinents non remontés par le retrieval, confusion de contexte documentaire, réponse correcte mais trop longue ou mal formulée. Chaque famille appelait un levier différent, et la majorité relevait de la qualité du corpus, pas du modèle. 

Ce travail de qualification a été décisif dans l’adhésion des équipes Unéo. En montrant que les erreurs provenaient majoritairement des sources documentaires plutôt que d’une limitation de la technologie, Mind7 a transformé un constat d’échec partiel en programme d’amélioration concret, piloté conjointement avec le métier. 

Ajuster le pipeline RAG par itérations successives 

Chaque semaine apportait de nouvelles données de feedback, et chaque lot permettait d’ajuster un paramètre du pipeline : seuil de confiance du retrieval, stratégies de reformulation des questions, enrichissement contextuel des chunks. Ces itérations courtes ont permis de mesurer l’impact de chaque réglage de manière isolée. 

Ce mode de fonctionnement confirme une réalité que les équipes IT connaissent dans d’autres domaines : on ne conçoit pas un système de retrieval optimal du premier coup. On le calibre, on le teste, on l’ajuste. Les premières semaines de production réelle apportent souvent plus d’enseignements que les six semaines de POC qui les précèdent. 

Préparer le passage en production dès les premiers choix d’architecture 

Le projet Unéo ne s’est pas achevé à la fin du POC. La vraie épreuve a été l’ouverture aux assurés : volumétrie de requêtes, exigences de disponibilité, diversité des profils utilisateurs. Cette trajectoire n’a été possible que parce que les choix d’architecture initiaux avaient intégré les exigences de la production dès le premier sprint : modularité pour absorber les changements de modèle, scalabilité pour tenir la charge, observabilité pour piloter la qualité, contrôle d’accès pour respecter les contraintes de gouvernance. 

La question à se poser dès le premier atelier de cadrage n’est pas « est-ce que le POC va fonctionner ? » mais « est-ce que ce que nous construisons aujourd’hui pourra tenir en production dans six mois ? ». Ces deux questions ne mènent pas aux mêmes choix d’architecture.

Le principal enseignement du projet Unéo est que la qualité d’un RAG se joue avant tout en amont de la technologie : dans la qualité des sources documentaires, la rigueur de leur structuration, et la précision du cadrage des cas d’usage. La technologie (LLM, base vectorielle, pipeline) n’amplifie que ce qu’on lui donne.