Les entreprises disposent d’un patrimoine documentaire considérable : procédures, contrats, comptes rendus, bases de connaissance, tickets support, contenus CRM, fiches produits, documents RH, normes internes, politiques de sécurité. Pourtant, ces connaissances restent souvent difficiles à trouver, à interpréter et à réutiliser.

Le RAG, pour Retrieval-Augmented Generation, permet de connecter l’IA générative aux données internes de l’entreprise afin de produire des réponses plus contextualisées, plus vérifiables et mieux adaptées aux usages métier.

Ce guide explique ce qu’est une architecture RAG, quand l’utiliser, comment la concevoir, combien elle peut coûter, quels risques anticiper et comment aborder les enjeux de sécurité, de confidentialité et de conformité.

L’IA générative a rendu visible une nouvelle manière d’interagir avec l’information : poser une question en langage naturel et obtenir une réponse structurée. Pour les entreprises, la promesse est forte : gagner du temps, réduire la dépendance à quelques experts internes, fluidifier l’accès à la connaissance et améliorer la qualité des décisions opérationnelles.

Mais un modèle généraliste, utilisé seul, ne connaît pas les documents internes de l’entreprise. Il peut aider à rédiger, reformuler ou structurer, mais il ne sait pas spontanément répondre à partir de vos contrats, de vos procédures, de votre base qualité ou de votre documentation technique. C’est précisément le rôle du RAG : fournir au modèle les bons extraits documentaires au bon moment, afin qu’il réponde à partir d’un contexte métier contrôlé.

Le RAG ne consiste donc pas simplement à “brancher ChatGPT sur des fichiers”. C’est une architecture complète qui combine données, recherche documentaire, sécurité, gouvernance, expérience utilisateur, évaluation et maintenance. Les sources récentes confirment que les implémentations RAG en entreprise doivent traiter des sujets complexes : compréhension des requêtes, accès multi-sources, contraintes de tokens, temps de réponse, droits d’accès et gouvernance des contenus.

Dans ce livre blanc, vous allez comprendre :

• ce qu’est le RAG, simplement ;
• dans quels cas il est pertinent ;
• quand il ne faut pas l’utiliser ;
• quelles briques techniques composent une architecture RAG ;
• quelles décisions structurantes prendre ;
• quels coûts anticiper ;
• comment aborder sécurité, RGPD, AI Act et confidentialité ;
• comment lancer un projet RAG de manière progressive et réaliste.

À retenir
Le RAG est une réponse pragmatique à un problème très courant : les entreprises ont beaucoup de connaissances, mais elles sont dispersées, peu accessibles et rarement exploitables en langage naturel.

Le principe est simple :

1. l’utilisateur pose une question ;
2. le système recherche dans les documents internes les passages les plus pertinents ;
3. ces passages sont ajoutés au contexte envoyé au modèle de langage ;
4. le modèle génère une réponse en s’appuyant sur ces extraits ;
5. la réponse peut citer les sources utilisées.

AWS décrit le RAG comme une technique qui augmente un grand modèle de langage avec des données externes, par exemple des documents internes, afin de fournir au modèle le contexte nécessaire pour produire une réponse utile dans un cas d’usage spécifique.

Une analogie simple

Imaginez un expert qui doit répondre à une question complexe. Sans documents, il s’appuie sur sa mémoire. Avec un RAG, on lui apporte automatiquement les bons dossiers ouverts aux bonnes pages avant qu’il ne réponde.

Le modèle de langage joue le rôle du rédacteur qui formule la réponse. Le moteur de recherche joue le rôle du documentaliste qui retrouve les sources. L’architecture RAG organise la collaboration entre les deux.

RAG vs chatbot classique

Un chatbot classique répond à partir de ce qu’il a appris lors de son entraînement ou de son prompt initial. Il peut être fluide, mais il risque de produire des réponses trop générales ou non alignées avec vos règles internes.

Un chatbot RAG, lui, recherche d’abord dans vos sources internes : politiques RH, documentation produit, procédures qualité, contrats, FAQ, tickets support, documents commerciaux. La réponse est donc plus ancrée dans votre réalité opérationnelle.

RAG vs fine-tuning

Le fine-tuning consiste à réentraîner ou spécialiser un modèle à partir d’exemples. Il peut être pertinent pour apprendre un style, une structure de réponse, une classification ou un comportement spécifique.

Mais pour exploiter des documents internes qui changent régulièrement, le RAG est souvent plus adapté. Il permet de mettre à jour les connaissances en réindexant ou synchronisant les sources, sans réentraîner le modèle. Il facilite aussi la citation des sources, la traçabilité et la gestion des droits.

ApprocheUtile pourLimites

Prompt simple

Tâches ponctuelles, rédaction, reformulation

Pas connecté aux données internes

Fine-tuning

Style, classification, comportements récurrents

Moins adapté aux connaissances changeantes

RAG

Recherche documentaire, réponses sourcées, connaissances internes

Dépend fortement de la qualité des données et du retrieval

À retenir
Le RAG est généralement plus pertinent que le fine-tuning lorsque l’enjeu principal est d’exploiter une base documentaire interne évolutive, avec des réponses sourcées.

Problème : les collaborateurs posent régulièrement les mêmes questions sur les congés, le télétravail, les notes de frais, les avantages, les processus d’onboarding.

Solution RAG : connecter un assistant aux politiques RH, accords internes, FAQ et procédures.

Valeur métier : réduction des sollicitations répétitives, meilleure autonomie des collaborateurs, réponses homogènes et traçables.

Support client augmenté

Problème : les équipes support doivent chercher dans des tickets passés, fiches produits, procédures d’escalade et bases de connaissance.

Solution RAG : proposer des réponses suggérées à partir des sources internes, avec citation des documents utilisés.

Valeur métier : temps de traitement réduit, meilleure qualité de réponse, capitalisation sur les incidents passés.

Moteur de recherche documentaire intelligent

Problème : les documents sont dispersés dans SharePoint, Google Drive, Notion, Confluence, ERP, CRM ou fichiers PDF.

Solution RAG : indexer les sources prioritaires et permettre aux utilisateurs de poser des questions en langage naturel.

Valeur métier : accès plus rapide à l’information, réduction de la dépendance aux experts, meilleure réutilisation des connaissances.

Assistant juridique ou conformité

Problème : les équipes doivent retrouver rapidement des clauses, obligations, procédures ou décisions internes.

Solution RAG : interroger contrats, politiques, référentiels, notes internes et archives validées.

Valeur métier : recherche accélérée, préparation plus efficace des analyses, meilleure traçabilité.

Point d’attention : ce type d’assistant doit être cadré avec prudence. Il peut aider à retrouver et synthétiser l’information, mais ne doit pas être présenté comme un conseil juridique automatisé.

Assistant commercial

Problème : les commerciaux perdent du temps à retrouver les bons argumentaires, cas clients, fiches offres, réponses aux objections ou éléments de proposition.

Solution RAG : créer un assistant connecté à la documentation commerciale et aux contenus validés.

Valeur métier : réponses plus rapides aux prospects, cohérence des messages, montée en compétence des nouveaux arrivants.

Base de connaissance technique

Problème : la documentation technique est volumineuse, partiellement obsolète et difficile à parcourir.

Solution RAG : interroger manuels, tickets, changelogs, schémas, procédures de maintenance et guides internes.

Valeur métier : diagnostic plus rapide, réduction des erreurs, support aux équipes terrain.

Onboarding collaborateur

Problème : un nouveau collaborateur doit assimiler rapidement de nombreux documents.

Solution RAG : assistant d’onboarding capable de répondre à partir des documents internes validés.

Valeur métier : intégration plus fluide, diminution du temps passé par les managers à répondre aux questions répétitives.

À retenir
Les meilleurs cas d’usage RAG sont ceux où les réponses existent déjà dans les documents, mais sont difficiles à retrouver, synthétiser ou contextualiser.

5. Quand le RAG n’est pas la bonne solution

Le RAG n’est pas une solution universelle.

Données trop pauvres ou mal structurées

Si les documents sont incomplets, contradictoires, obsolètes ou dispersés sans logique, le RAG risque de produire des réponses médiocres. Un assistant RAG ne corrige pas magiquement une base documentaire faible.

Besoin de raisonnement métier complexe

Le RAG excelle pour retrouver et synthétiser de l’information. Il est moins adapté lorsqu’il faut appliquer des règles métier complexes, calculer des scénarios, arbitrer entre plusieurs contraintes ou exécuter des processus transactionnels.

Dans ces cas, une application métier, un moteur de règles ou un workflow structuré peut être plus approprié.

Données non fiables

Si personne ne sait quel document fait foi, l’IA ne le saura pas non plus. Le projet doit commencer par clarifier les sources autorisées, les documents obsolètes et les responsables de la mise à jour.

Automatisation plutôt que recherche documentaire

Si le problème consiste surtout à envoyer des relances, remplir un formulaire, router un ticket ou mettre à jour un CRM, une automatisation classique peut suffire.

Besoin de garanties absolues

Un RAG peut réduire les hallucinations, améliorer la traçabilité et fournir des sources. Il ne garantit pas que chaque réponse sera parfaite. Pour des décisions critiques, il faut prévoir validation humaine, règles déterministes ou processus de contrôle.

À retenir
Un bon cadrage consiste aussi à savoir dire non au RAG. Si le besoin relève d’un workflow, d’un moteur de règles ou d’une application métier classique, il faut le reconnaître.

Données trop pauvres ou mal structurées

Si les documents sont incomplets, contradictoires, obsolètes ou dispersés sans logique, le RAG risque de produire des réponses médiocres. Un assistant RAG ne corrige pas magiquement une base documentaire faible.

Besoin de raisonnement métier complexe

Le RAG excelle pour retrouver et synthétiser de l’information. Il est moins adapté lorsqu’il faut appliquer des règles métier complexes, calculer des scénarios, arbitrer entre plusieurs contraintes ou exécuter des processus transactionnels.

Dans ces cas, une application métier, un moteur de règles ou un workflow structuré peut être plus approprié.

Données non fiables

Si personne ne sait quel document fait foi, l’IA ne le saura pas non plus. Le projet doit commencer par clarifier les sources autorisées, les documents obsolètes et les responsables de la mise à jour.

Automatisation plutôt que recherche documentaire

Si le problème consiste surtout à envoyer des relances, remplir un formulaire, router un ticket ou mettre à jour un CRM, une automatisation classique peut suffire.

Besoin de garanties absolues

Un RAG peut réduire les hallucinations, améliorer la traçabilité et fournir des sources. Il ne garantit pas que chaque réponse sera parfaite. Pour des décisions critiques, il faut prévoir validation humaine, règles déterministes ou processus de contrôle.

À retenir
Un bon cadrage consiste aussi à savoir dire non au RAG. Si le besoin relève d’un workflow, d’un moteur de règles ou d’une application métier classique, il faut le reconnaître.

Sources internes
├─ PDF, Word, PowerPoint
├─ SharePoint / Google Drive / Notion / Confluence
├─ CRM / ERP / tickets support
└─ bases métiers

↓

Ingestion documentaire
├─ extraction texte
├─ OCR si nécessaire
├─ nettoyage
├─ structuration
└─ détection métadonnées

↓

Découpage en chunks
├─ par sections
├─ par titres
├─ par paragraphes
└─ avec chevauchement contrôlé

↓

Embeddings + indexation
├─ modèle d’embeddings
├─ base vectorielle
├─ index lexical éventuel
└─ métadonnées et permissions

↓

Question utilisateur
↓

Retrieval
├─ recherche vectorielle
├─ recherche keyword / BM25
├─ recherche hybride
├─ filtres droits d’accès
└─ reranking

↓

Prompt enrichi
├─ question
├─ extraits pertinents
├─ consignes de réponse
└─ règles de citation

↓

LLM
↓

Réponse utilisateur
├─ synthèse
├─ citations
├─ limites
└─ actions éventuelles

↓

Logs, feedback, évaluation, monitoring

Sources de données

Les sources peuvent être simples, comme un dossier de PDF, ou complexes, comme un ensemble de systèmes internes. La priorité n’est pas de tout connecter, mais de connecter les bonnes sources.

Ingestion documentaire

L’ingestion consiste à extraire, nettoyer et transformer les documents pour les rendre exploitables. Les PDF scannés, tableaux, images, schémas et documents mal formatés peuvent nécessiter OCR, parsing avancé ou retraitement manuel.

AWS Bedrock Knowledge Bases, par exemple, décrit des workflows gérés qui vont de l’ingestion à la récupération, avec conversion en blocs de texte, embeddings et stockage dans des bases vectorielles compatibles.

Chunking

Le chunking consiste à découper les documents en morceaux. Des chunks trop longs diluent l’information. Des chunks trop courts perdent le contexte. La stratégie dépend du type de document : procédure, contrat, FAQ, documentation technique, ticket support.

LlamaIndex rappelle que modifier la taille des chunks et le chevauchement change les embeddings calculés, et qu’un chunk plus petit peut être plus précis tandis qu’un chunk plus grand peut être plus général.

Embeddings et base vectorielle

Les embeddings transforment les textes en vecteurs numériques qui permettent de mesurer la proximité sémantique entre une question et des passages documentaires.

La base vectorielle stocke ces vecteurs et permet de retrouver les passages les plus proches d’une requête.

Recherche hybride et reranking

La recherche vectorielle est utile, mais elle ne suffit pas toujours. Les architectures modernes combinent souvent :

• recherche vectorielle ;
• recherche keyword ;
• filtres par métadonnées ;
• reranking ;
• citations ;
• contrôle des droits.

Microsoft décrit les techniques courantes du pipeline RAG : recherche full-text, recherche vectorielle, chunking, recherche hybride, réécriture de requête et reranking. Pinecone explique également que le reranking en deux étapes peut améliorer la qualité en combinant recherche à grande échelle et reclassement plus précis.

Gestion des droits d’accès

Un point critique : un utilisateur ne doit pas obtenir une réponse basée sur un document auquel il n’a pas droit. L’architecture doit appliquer les permissions au moment de la recherche, pas seulement dans l’interface.

Microsoft met en avant la nécessité d’un contrôle d’accès granulaire lorsque du contenu privé est exposé à des LLM, avec des mécanismes comme le security trimming, les filtres au moment de la requête et l’isolation réseau.

À retenir
Une architecture RAG sérieuse est une chaîne complète : ingestion, qualité documentaire, recherche, permissions, prompt, modèle, citations, logs et amélioration continue.

Le choix du modèle dépend de plusieurs critères :

• qualité des réponses ;
• coût par token ;
• latence ;
• contexte maximal ;
• disponibilité régionale ;
• engagements contractuels ;
• capacité multilingue ;
• compatibilité avec les exigences de sécurité.

Un modèle très puissant n’est pas toujours nécessaire. Pour beaucoup de cas RAG, le bon compromis consiste à utiliser un modèle rapide et économique pour les questions simples, puis un modèle plus avancé pour les cas complexes.

API externe ou modèle auto-hébergé ?

OptionAvantagesLimites

API externe

Rapide à déployer, modèles performants, maintenance réduite

Dépendance fournisseur, clauses contractuelles à vérifier, coûts variables

Modèle auto-hébergé

Contrôle renforcé, maîtrise de l’environnement, possible souveraineté

Infrastructure, MLOps, supervision, coûts et compétences plus élevés

Hybride

Optimisation par cas d’usage

Architecture plus complexe

Quelle base vectorielle ?

Le choix dépend du volume, de la latence, des filtres, du modèle de sécurité, de l’environnement cloud et des compétences internes. Une PME avec quelques milliers de documents n’a pas les mêmes besoins qu’un groupe international avec plusieurs millions de chunks.

Quelle stratégie de chunking ?

Il faut tester. Le bon découpage dépend des documents. Une FAQ peut être découpée question par question. Un contrat doit conserver les clauses et sous-clauses. Une procédure doit garder les étapes ensemble.

Comment gérer les métadonnées ?

Les métadonnées sont essentielles :

• type de document ;
• date ;
• version ;
• auteur ;
• département ;
• confidentialité ;
• langue ;
• client ou projet concerné ;
• droits d’accès ;
• statut : brouillon, validé, obsolète.

Elles permettent de filtrer, prioriser et expliquer les réponses.

Comment limiter les hallucinations ?

Aucune méthode ne les supprime totalement. On peut cependant les réduire :

• retrieval de qualité ;
• citations obligatoires ;
• consigne de ne pas répondre sans source ;
• seuil de confiance ;
• affichage des limites ;
• évaluation régulière ;
• feedback utilisateur ;
• tests adversariaux ;
• validation humaine pour les cas sensibles.

Comment évaluer la qualité ?

Un RAG doit être évalué avec des questions réelles. Les critères peuvent inclure :

• exactitude ;
• complétude ;
• fidélité aux sources ;
• capacité à dire “je ne sais pas” ;
• pertinence des citations ;
• latence ;
• taux de satisfaction ;
• réduction du temps de recherche ;
• absence de fuite d’information.

À retenir
Les décisions techniques ne sont pas seulement techniques. Elles influencent le coût, la sécurité, la qualité des réponses, la maintenance et l’adoption par les utilisateurs.

Les principaux postes de coût

PosteDescriptionImpact

Cadrage

ateliers métier, objectifs, critères de succès

indispensable pour éviter un POC inutile

Audit documentaire

sources, qualité, droits, obsolescence

souvent sous-estimé

Préparation des données

nettoyage, structuration, OCR, métadonnées

peut devenir majeur

Développement

ingestion, retrieval, interface, orchestration

cœur du projet

Intégrations

SSO, SharePoint, CRM, ERP, ticketing

dépend du SI

LLM

coût des appels API ou infrastructure modèle

dépend du volume

Embeddings

indexation initiale et mises à jour

dépend du volume documentaire

Base vectorielle

stockage, requêtes, disponibilité

dépend de l’échelle

Sécurité

IAM, logs, chiffrement, tests

non négociable

Monitoring

suivi coûts, erreurs, qualité

essentiel en production

Maintenance

corrections, réindexation, amélioration

coût récurrent

Coûts indicatifs des principaux fournisseurs LLM

Les tarifs changent souvent. Les montants ci-dessous doivent être lus comme des ordres de grandeur observés au 27 mai 2026 et vérifiés avant tout engagement contractuel.

FournisseurExemples de modèlesPrix indicatifs publics

OpenAI

GPT-5.5, GPT-5.4, GPT-5.4 mini

GPT-5.5 : 5 $ / 1M tokens input et 30 $ / 1M tokens output ; GPT-5.4 : 2,50 $ / 1M input et 15 $ / 1M output ; GPT-5.4 mini : 0,75 $ / 1M input et 4,50 $ / 1M output.

Anthropic

Claude Opus 4.7, Sonnet 4.6, Haiku 4.5

Opus 4.7 : 5 $ / MTok input et 25 $ / MTok output ; Sonnet 4.6 : 3 $ / MTok input et 15 $ / MTok output ; Haiku 4.5 : 1 $ / MTok input et 5 $ / MTok output.

Google

Gemini 3.5 Flash, Gemini 2.5 Pro, Gemini 2.5 Flash, Flash-Lite

Gemini 3.5 Flash standard : 1,50 $ / 1M input et 9 $ / 1M output ; Gemini 2.5 Pro : 1,25 $ / 1M input jusqu’à 200k tokens et 10 $ / 1M output ; Gemini 2.5 Flash : 0,30 $ / 1M input texte/image/vidéo et 2,50 $ / 1M output ; Flash-Lite : 0,10 $ / 1M input et 0,40 $ / 1M output.

Mistral AI

Mistral Small 4, Large 3, Medium 3.5

Small 4 : 0,15 $ / M tokens input et 0,60 $ / M tokens output ; Large 3 : 0,50 $ / M input et 1,50 $ / M output ; Medium 3.5 : 1,50 $ / M input et 7,50 $ / M output.

Exemple simplifié de calcul

Supposons :

• 200 utilisateurs ;
• 20 questions par jour ouvré par utilisateur ;
• 22 jours par mois ;
• 1 500 tokens d’entrée par question, contexte inclus ;
• 500 tokens de sortie par réponse.

Cela représente environ :

• 132 millions de tokens d’entrée par mois ;
• 44 millions de tokens de sortie par mois.

Le coût mensuel dépendra fortement du modèle choisi. Sur un modèle économique, il peut rester contenu. Sur un modèle premium, il peut devenir significatif. Le point clé est donc de piloter le coût par usage réel, pas uniquement par prix affiché.

Ce qui fait exploser les coûts

• envoyer trop de contexte au modèle ;
• utiliser un modèle premium pour toutes les questions ;
• réindexer inutilement toute la base documentaire ;
• multiplier les appels LLM dans un workflow agentique ;
• ne pas mettre de cache ;
• ne pas limiter les documents récupérés ;
• ne pas monitorer les usages ;
• connecter des sources non prioritaires ;
• traiter massivement des PDF scannés sans stratégie.

Comment maîtriser les coûts

• choisir le modèle le moins cher qui atteint le niveau de qualité attendu ;
• limiter le contexte envoyé ;
• utiliser du reranking pour envoyer moins de chunks mais plus pertinents ;
• mettre en cache les réponses ou les contextes récurrents ;
• séparer questions simples et complexes ;
• suivre les coûts par équipe, usage, source et type de requête ;
• définir des quotas ;
• commencer par un périmètre documentaire restreint.

À retenir
Le coût d’un RAG dépend moins du “prix du modèle” que de l’architecture complète : volume documentaire, nombre d’utilisateurs, longueur du contexte, fréquence d’usage, qualité du retrieval et niveau d’intégration.

Dès qu’un système RAG traite des données personnelles, le RGPD doit être pris en compte : finalité, base légale, minimisation, durée de conservation, droits des personnes, sécurité, sous-traitance et documentation.

La CNIL rappelle que le RGPD n’empêche pas l’innovation en IA, mais impose de prendre en compte les risques pour les personnes lorsque des données personnelles sont utilisées. Elle insiste notamment sur la nécessité d’une base légale, sur la minimisation et sur la documentation des traitements.

Dans un projet RAG, les questions à se poser sont concrètes :

• les documents contiennent-ils des données personnelles ?
• des données sensibles ?
• des données RH ?
• des données clients ?
• des données de santé ?
• des informations contractuelles confidentielles ?
• des informations couvertes par un secret professionnel ?
• les utilisateurs ont-ils tous le droit de consulter ces informations ?

AIPD

Une analyse d’impact sur la protection des données peut être nécessaire ou fortement recommandée lorsque le traitement présente des risques élevés. La CNIL recommande notamment de réaliser une AIPD pour le développement de systèmes d’IA dans plusieurs situations, par exemple lorsque des données sensibles sont collectées, que des données personnelles sont traitées à grande échelle, que des données de personnes vulnérables sont utilisées ou que des ensembles de données sont croisés.

AI Act

L’AI Act introduit une approche par niveau de risque. Les obligations varient selon que le système est interdit, à haut risque, soumis à transparence, ou à risque minimal. La Commission européenne indique que les pratiques interdites et les obligations de littératie IA sont applicables depuis le 2 février 2025, que les règles relatives aux modèles d’IA à usage général sont applicables depuis le 2 août 2025, et que le calendrier des systèmes à haut risque a été ajusté dans le cadre du Digital Omnibus, avec certaines règles prévues au 2 décembre 2027 et d’autres au 2 août 2028 selon les catégories.

Pour une entreprise qui déploie un assistant RAG interne, l’enjeu principal est de qualifier le cas d’usage : simple assistant documentaire, outil RH, aide à la décision, outil utilisé dans le recrutement, la formation, la conformité, le crédit, la santé, la sécurité ou d’autres domaines sensibles. Les lignes directrices européennes sur la classification des systèmes à haut risque faisaient encore l’objet de consultations et d’ajustements en mai 2026.

Sécurité des systèmes RAG

Les risques principaux sont :

• fuite de données sensibles ;
• mauvaise application des droits d’accès ;
• prompt injection ;
• indirect prompt injection via documents ;
• exposition du prompt système ;
• empoisonnement documentaire ;
• réponses non sourcées ;
• logs contenant des données sensibles ;
• sur-permission des agents ;
• dépendance fournisseur ;
• absence d’auditabilité.

L’OWASP Top 10 for LLM Applications 2025 classe notamment le prompt injection, la divulgation d’informations sensibles, la supply chain, le data/model poisoning, l’excessive agency, la fuite de prompt système, les faiblesses vectorielles et embeddings, la désinformation et la consommation non bornée parmi les risques majeurs des applications LLM.

Le NCSC britannique souligne que le prompt injection n’est pas comparable à une simple injection SQL : les LLM ne séparent pas intrinsèquement données et instructions. Il recommande de traiter les LLM comme des composants “inherently confusable” et de réduire les impacts par le design, la limitation des privilèges, la surveillance et des garde-fous déterministes.

Mesures recommandées

• SSO et authentification forte ;
• contrôle d’accès par utilisateur ;
• filtrage des documents au moment de la requête ;
• chiffrement en transit et au repos ;
• segmentation des environnements ;
• séparation dev, test, prod ;
• journalisation maîtrisée ;
• politique de rétention des logs ;
• masquage ou pseudonymisation si pertinent ;
• tests de sécurité ;
• red teaming IA ;
• politique interne d’usage ;
• revue contractuelle des fournisseurs ;
• clauses de sous-traitance ;
• suivi des transferts hors UE ;
• documentation des choix.

Le NIST AI RMF Generative AI Profile fournit un cadre volontaire pour intégrer les considérations de confiance, de gouvernance, de mesure et de gestion des risques dans les systèmes d’IA générative. Le Cloud Security Alliance recommande également d’appliquer les principes Zero Trust aux environnements LLM : moindre privilège, micro-segmentation, monitoring continu, gestion des identités humaines et non humaines, et gouvernance.

À retenir
La sécurité d’un RAG ne repose pas sur un prompt magique. Elle repose sur l’architecture : droits d’accès, cloisonnement, logs, chiffrement, supervision, tests et gouvernance.

Choisir une base vectorielle ou un modèle avant d’avoir clarifié le besoin métier conduit souvent à un POC séduisant mais inutile.

Connecter toutes les données

Plus il y a de sources, plus les risques augmentent : bruit documentaire, obsolescence, droits flous, coûts, latence. Il vaut mieux commencer par un corpus restreint et fiable.

Négliger la qualité documentaire

Un RAG performant repose sur des documents fiables, à jour et bien structurés. La qualité du corpus est souvent plus importante que le choix du modèle.

Oublier les droits d’accès

C’est l’une des erreurs les plus dangereuses. Un assistant ne doit jamais devenir un moyen détourné d’accéder à des documents confidentiels.

Ne pas prévoir de citations

Sans sources, l’utilisateur ne peut pas vérifier. Les citations améliorent la confiance et facilitent la correction.

Ne pas tester les réponses

Il faut créer un jeu de questions réelles, avec réponses attendues et critères d’évaluation. Sinon, la qualité restera subjective.

Sous-estimer la maintenance

Documents qui changent, sources qui bougent, modèles qui évoluent, tarifs qui varient, utilisateurs qui découvrent de nouveaux usages : un RAG doit être maintenu.

Confondre prototype et produit

Un prototype peut ignorer certains sujets : sécurité fine, monitoring, UX, reprise d’erreur, coûts. Un produit ne le peut pas.

Lancer un POC sans critères de réussite

Un POC doit répondre à des questions claires : gagne-t-on du temps ? Les réponses sont-elles fiables ? Les utilisateurs l’adoptent-ils ? Le coût est-il acceptable ?

À retenir
La majorité des échecs RAG ne viennent pas du modèle, mais d’un mauvais cadrage, d’un corpus faible, d’une sécurité oubliée ou d’une absence d’évaluation.

1. Identifier le besoin métier

Formuler le problème sans parler d’IA : “les équipes support perdent 20 minutes à retrouver une procédure”, “les nouveaux collaborateurs posent toujours les mêmes questions”, “les commerciaux ne savent pas quel document utiliser”.

2. Prioriser les cas d’usage

Tous les cas ne se valent pas. Il faut privilégier ceux qui combinent valeur métier, faisabilité documentaire et risque maîtrisable.

3. Auditer les données disponibles

Lister les sources, leur qualité, leur fraîcheur, leur format, leur propriétaire, leur niveau de confidentialité.

4. Vérifier les contraintes sécurité/RGPD

Identifier les données personnelles, sensibles ou confidentielles. Déterminer les droits, les rôles et les obligations de documentation.

5. Concevoir une architecture cible

Choisir les briques : ingestion, embeddings, base vectorielle, modèle, interface, logs, monitoring, authentification.

6. Développer un prototype limité

Limiter le périmètre : une équipe, un corpus, un cas d’usage, une interface simple.

7. Tester sur des cas réels

Utiliser de vraies questions utilisateurs, pas seulement des démonstrations idéales.

8. Mesurer la qualité

Suivre exactitude, citations, taux de non-réponse justifié, satisfaction, temps gagné, erreurs, coûts.

9. Déployer progressivement

Élargir par vagues : plus d’utilisateurs, plus de sources, plus de fonctionnalités.

10. Maintenir et améliorer

Réindexer, corriger, surveiller, former, ajuster les prompts, revoir les coûts, améliorer les sources.

À retenir
Un projet RAG réussi ressemble davantage à un produit métier qu’à une expérimentation technique isolée.

Problème métier

• Qui perd du temps aujourd’hui ?
• Quel problème veut-on résoudre ?
• Quelle décision ou tâche sera améliorée ?
• Quel serait un résultat utile à 3 mois ?

Utilisateurs

• Qui utilisera l’outil ?
• Combien d’utilisateurs ?
• Quels profils ?
• Quels droits différents ?
• Quel niveau de formation ?

Données

• Quelles sources seront utilisées ?
• Les documents sont-ils fiables ?
• Sont-ils à jour ?
• Qui les maintient ?
• Y a-t-il des doublons ?
• Y a-t-il des documents obsolètes ?
• Les formats sont-ils exploitables ?

Sécurité et conformité

• Les documents contiennent-ils des données personnelles ?
• Des données sensibles ?
• Des informations confidentielles ?
• Les droits d’accès sont-ils clairs ?
• Faut-il réaliser une AIPD ?
• Quels fournisseurs auront accès aux données ?
• Où les données seront-elles hébergées ?
• Quelle durée de conservation pour les logs ?

Réponse et qualité

• Le modèle doit-il citer ses sources ?
• Doit-il refuser de répondre sans source ?
• Quel niveau de précision est attendu ?
• Qui valide les réponses ?
• Comment corrige-t-on une mauvaise réponse ?
• Comment mesure-t-on la qualité ?

Coûts

• Quel budget initial ?
• Quel budget récurrent ?
• Combien de requêtes attendues ?
• Quel modèle utiliser ?
• Quels seuils d’usage ?
• Quel monitoring ?

Déploiement

• Prototype ou produit ?
• Quelle équipe pilote ?
• Quel calendrier ?
• Quel support utilisateur ?
• Quel plan de maintenance ?

À retenir
Si vous ne pouvez pas répondre à cette checklist, le projet n’est probablement pas prêt à être développé.

Une entreprise de services B2B de 600 collaborateurs possède :

• 1 200 procédures internes ;
• 300 modèles de contrats ;
• 450 FAQ support ;
• 20 000 tickets historiques ;
• des comptes rendus de comités projet ;
• une base SharePoint peu structurée ;
• plusieurs documents obsolètes mais encore accessibles.

Les équipes support, commerciales et opérations passent beaucoup de temps à chercher l’information. Les réponses varient selon les interlocuteurs. Les nouveaux collaborateurs dépendent fortement des experts internes.

Problème initial

L’entreprise veut permettre à ses équipes de poser des questions en langage naturel :

• “Quelle est la procédure d’escalade pour un incident critique ?”
• “Quel modèle de clause utiliser pour un client public ?”
• “Comment traiter une demande de remboursement hors délai ?”
• “Quels sont les prérequis avant une mise en production ?”

Elle veut des réponses sourcées, limitées aux documents validés, avec respect des droits d’accès.

Approche retenue

Le projet commence par un périmètre limité : procédures support et FAQ validées. Les contrats et tickets historiques sont exclus du premier lot car ils contiennent davantage de données sensibles et de bruit documentaire.

Architecture

• SSO via l’identité interne ;
• ingestion des documents validés depuis SharePoint ;
• extraction texte et nettoyage ;
• métadonnées : service, date, version, propriétaire, statut ;
• chunking par titre et section ;
• embeddings ;
• base vectorielle avec filtres par droits ;
• recherche hybride ;
• reranking ;
• réponse avec citations ;
• logs anonymisés autant que possible ;
• feedback utilisateur ;
• tableau de bord qualité/coûts.

Risques identifiés

• documents obsolètes encore présents ;
• droits SharePoint incohérents ;
• procédures contradictoires ;
• questions hors périmètre ;
• risque de copier-coller de données clients dans les prompts ;
• attentes irréalistes des utilisateurs.

Mesures prises

• corpus validé manuellement ;
• exclusion des documents non approuvés ;
• refus de répondre sans source ;
• affichage des documents utilisés ;
• politique d’usage ;
• formation courte des utilisateurs ;
• seuils de coût ;
• revue hebdomadaire des feedbacks au démarrage.

Gains attendus

• réduction du temps de recherche ;
• meilleure homogénéité des réponses ;
• onboarding plus rapide ;
• réduction des sollicitations aux experts ;
• identification des lacunes documentaires.

Limites

• l’assistant ne remplace pas les experts ;
• il ne traite pas encore les contrats ;
• les réponses complexes nécessitent validation ;
• la qualité dépend de la mise à jour documentaire.

Prochaines étapes

Après 8 semaines de pilote :

1. mesurer la qualité ;
2. identifier les questions sans réponse ;
3. corriger le corpus ;
4. intégrer progressivement les modèles de contrats non sensibles ;
5. ajouter des workflows simples, par exemple ouvrir un ticket ou proposer une procédure.

À retenir
Un projet RAG réaliste commence petit, prouve sa valeur, corrige ses données, puis s’étend progressivement.

Le RAG est l’une des architectures les plus utiles pour appliquer l’IA générative aux données internes de l’entreprise. Il permet de transformer une base documentaire difficile à exploiter en interface conversationnelle capable de rechercher, synthétiser et citer ses sources.

Mais un bon projet RAG ne se résume pas à connecter un chatbot à des documents. Sa réussite dépend de plusieurs facteurs :

• un besoin métier clair ;
• un corpus fiable ;
• une architecture de retrieval solide ;
• une gestion stricte des droits ;
• une approche sécurité dès la conception ;
• une attention au RGPD et à l’AI Act ;
• un pilotage des coûts ;
• une expérience utilisateur simple ;
• une évaluation continue ;
• une maintenance réelle.

Le RAG n’est pas magique. Mais bien conçu, il peut devenir un outil très concret pour réduire le temps de recherche, capitaliser la connaissance interne, fluidifier les opérations et améliorer la qualité des réponses métier.

À retenir
La valeur du RAG ne vient pas seulement du modèle. Elle vient de l’ensemble : données, architecture, sécurité, usage, gouvernance et adoption.

Scroll vous aide à cadrer le besoin, évaluer la faisabilité, concevoir l’architecture et développer une solution adaptée à vos contraintes métier, techniques et réglementaires.

Notre approche est pragmatique :

• partir du besoin métier ;
• auditer les données disponibles ;
• identifier les risques ;
• choisir une architecture adaptée ;
• développer un prototype utile ;
• mesurer la qualité ;
• préparer un déploiement sécurisé.

Échangeons sur votre projet RAG

Avant de développer, faites cadrer votre projet IA : cas d’usage, données, architecture, coûts, sécurité, conformité et trajectoire de déploiement.

Sources utilisées

Cahier des charges

Brief fourni par l’utilisateur pour le positionnement, la structure, la cible, le ton et les contraintes du livre blanc.

RAG et architectures modernes

Microsoft Learn, “Retrieval-augmented generation in Azure AI Search”, consulté le 27 mai 2026. Source utilisée pour les enjeux RAG en entreprise : compréhension des requêtes, accès multi-sources, contraintes de tokens, gouvernance, sécurité, RAG classique et agentic retrieval.

Microsoft Cloud Blog, “Common retrieval augmented generation techniques explained”, 4 février 2025. Source utilisée pour les techniques RAG : recherche full-text, vector search, chunking, hybrid search, query rewriting et reranking.

AWS Prescriptive Guidance, “Understanding Retrieval Augmented Generation”. Source utilisée pour la définition du RAG, les étapes de base et le rôle des embeddings, de la base vectorielle et de l’orchestrateur.

AWS, “Amazon Bedrock Knowledge Bases”. Source utilisée pour les workflows RAG managés, l’ingestion, les vector stores, le chunking avancé, GraphRAG, le reranking et l’attribution des sources.

LlamaIndex, “Basic Strategies”. Source utilisée pour les considérations sur chunk size, chunk overlap, embeddings et hybrid search.

Pinecone, “Rerankers and Two-Stage Retrieval”. Source utilisée pour expliquer l’intérêt du reranking et de la récupération en deux étapes.

RGPD, CNIL et données personnelles

CNIL, “Développement des systèmes d’IA : les recommandations de la CNIL pour respecter le RGPD”, 22 juillet 2025. Source utilisée pour les principes RGPD applicables à l’IA : base légale, minimisation, sécurité, données sensibles, AIPD et documentation.

CNIL, passages sur la base légale, la minimisation et les responsabilités responsable de traitement / sous-traitant.

CNIL, passages sur l’AIPD et les critères de risque.

European Data Protection Board, page thématique “Artificial intelligence”, incluant l’avis 28/2024 sur certains aspects de protection des données liés aux modèles d’IA.

AI Act

Commission européenne, “AI Act | Shaping Europe’s digital future”. Source utilisée pour l’approche par les risques, les obligations GPAI, les obligations de transparence, le calendrier d’application et les ajustements liés au Digital Omnibus.

AI Act Service Desk, “Timeline for the Implementation of the EU AI Act”. Source utilisée pour le calendrier d’application progressif et les étapes 2025-2027, avec mention du contexte Digital Omnibus.

Commission européenne, consultation du 19 mai 2026 sur les lignes directrices de classification des systèmes d’IA à haut risque. Source utilisée pour rappeler que la qualification des systèmes à haut risque reste un point à vérifier au cas par cas.

Commission européenne, “Standardisation of the AI Act”. Source utilisée pour le lien entre règles haut risque, standards harmonisés et calendrier ajusté.

Sécurité IA, LLM et RAG

OWASP GenAI Security Project, “2025 Top 10 Risk & Mitigations for LLMs and Gen AI Apps”. Source utilisée pour les principaux risques LLM : prompt injection, divulgation d’informations sensibles, supply chain, poisoning, excessive agency, fuite de prompt système, faiblesses vectorielles et embeddings, misinformation et unbounded consumption.

OWASP, “LLM01:2025 Prompt Injection”. Source utilisée pour préciser que le RAG et le fine-tuning ne suppriment pas entièrement les risques de prompt injection.

NIST, “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile”, publié le 26 juillet 2024. Source utilisée pour le cadre de gestion des risques de l’IA générative.

NCSC, “Prompt injection is not SQL injection (it may be worse)”, 8 décembre 2025. Source utilisée pour expliquer pourquoi le prompt injection est un risque structurel des LLM et pourquoi il doit être géré par architecture, limitation d’impact et monitoring.

Cloud Security Alliance, “Using Zero Trust to Secure Enterprise Information in LLM Environments”, 3 février 2026. Source utilisée pour les recommandations Zero Trust appliquées aux environnements LLM : moindre privilège, micro-segmentation, monitoring continu, IAM et gouvernance.

CISA, “New Best Practices Guide for Securing AI Data Released”, 22 mai 2025. Source utilisée pour les bonnes pratiques de sécurisation des données utilisées pour entraîner et opérer des systèmes IA.

Tarifs LLM et coûts API

OpenAI, “API Pricing”, consulté le 27 mai 2026. Source utilisée pour les tarifs GPT-5.5, GPT-5.4, GPT-5.4 mini, batch API et options liées aux coûts.

Anthropic, “Claude API Pricing”, consulté le 27 mai 2026. Source utilisée pour les tarifs Claude Opus 4.7, Sonnet 4.6 et Haiku 4.5.

Google AI for Developers, “Gemini Developer API pricing”, consulté le 27 mai 2026. Source utilisée pour les tarifs Gemini 3.5 Flash, Gemini 2.5 Pro, Gemini 2.5 Flash, Gemini 2.5 Flash-Lite et embeddings Gemini.

Mistral AI Docs, fiches modèles Mistral Small 4, Mistral Large 3 et Mistral Medium 3.5, consultées le 27 mai 2026. Sources utilisées pour les tarifs indicatifs par million de tokens et les caractéristiques de contexte.