Cadrer un projet RAG d'entreprise : 7 décisions à documenter avant le prototype

Un projet RAG se cadre avant de choisir un modèle, une base vectorielle ou une interface. Le livrable utile n'est pas une liste de composants. C'est un dossier de décision qui permet de répondre, preuves à l'appui : quel problème résoudre, quelles données peuvent être utilisées, qui peut voir quoi, comment mesurer la qualité et dans quelles conditions arrêter ou poursuivre.

En bref

• Commencez par une décision métier et un périmètre d'utilisateurs, pas par la technologie.
• Exigez sept éléments documentés avant le prototype : cas d'usage, sources, droits, réponse attendue, évaluation, exploitation et critères de passage.
• Traitez le prototype comme un test de décision. S'il ne peut pas échouer sur des critères écrits à l'avance, il ne réduit pas réellement le risque.

Ce guide propose un cadre de travail pour un CTO ou un Head of Data/AI. Il ne remplace ni l'analyse de sécurité, ni l'analyse juridique propre à votre contexte.

Quel résultat le cadrage doit-il produire ?

Le cadrage doit rendre une décision possible. À l'issue de cette phase, l'équipe doit pouvoir écrire l'une de ces trois conclusions :

1. Poursuivre vers un prototype, avec un périmètre, des données et des critères d'évaluation connus.
2. Réduire ou modifier le cas d'usage, parce qu'une contrainte de données, d'accès ou d'exploitation rend la première hypothèse trop risquée.
3. Ne pas construire de RAG, parce que le problème serait mieux résolu par la recherche existante, une amélioration documentaire ou un workflow non génératif.

C'est l'angle qui évite le faux départ le plus coûteux : produire une démonstration convaincante, puis découvrir que personne ne peut la déployer avec les permissions, les données ou les responsabilités réelles.

Le NIST AI Risk Management Framework, publié en 2023, propose un cadre volontaire pour intégrer des considérations de fiabilité dans la conception, le développement, l'usage et l'évaluation des systèmes d'IA. Son playbook organise les actions autour de quatre fonctions : gouverner, cartographier, mesurer et gérer. Pour un RAG, ces quatre verbes constituent une bonne grille de lecture du cadrage, sans en faire une conformité automatique.

Lorsque le cadrage sert aussi à comparer des approches ou des prestataires, notre scoreur de sélection d'un partenaire RAG aide à préparer les preuves et les questions à examiner. Il ne remplace pas la revue du périmètre, des pièces techniques ou des tests.

Quelle est la décision métier que le RAG doit améliorer ?

Un cas d'usage formulé comme « faire un chatbot sur nos documents » est trop large. Commencez par une décision ou une tâche observable : par exemple, retrouver une procédure de maintenance, préparer une réponse support à partir de la documentation autorisée, ou aider une équipe à localiser la version applicable d'une politique interne.

Pour chaque cas, consignez :

• l'utilisateur concerné et son contexte de travail ;
• la question ou la tâche qu'il doit accomplir ;
• le coût du fonctionnement actuel ;
• la réponse attendue et ce que le système ne doit pas faire ;
• la conséquence d'une réponse erronée, incomplète ou hors périmètre.

Cette dernière ligne est importante. Un assistant qui aide à orienter vers une procédure et un assistant qui propose une décision opérationnelle n'ont pas le même niveau d'exigence, ni le même protocole de validation humaine.

Quelles sources de données entrent réellement dans le périmètre ?

Une liste d'outils connectables ne constitue pas un périmètre de données. Pour chaque source candidate, créez une fiche courte : propriétaire, type de contenu, fraîcheur, qualité, droits d'accès, versionnement et procédure de suppression.

La question utile n'est pas seulement « peut-on extraire ces documents ? ». C'est aussi :

• Quelle version fait autorité en cas de contradiction ?
• Comment détecter une mise à jour ou une suppression ?
• Quels documents doivent être exclus dès l'ingestion ?
• La source contient-elle déjà les éléments nécessaires pour citer une réponse ?

Un prototype crédible n'indexe pas tout. Il sélectionne un corpus représentatif, avec ses problèmes réels : documents dupliqués, versions contradictoires, tableaux mal extraits, droits hétérogènes ou contenu obsolète. Sinon, le test mesure surtout la propreté artificielle du jeu de démonstration.

Pour transformer cette sélection en décision exploitable, documentez aussi le périmètre de données d’un RAG sur documents sensibles : sources admises ou exclues, transformations, droits, sorties et mécanisme de retrait. Lorsque le corpus évolue, notre méthode pour versionner, mettre à jour et retirer un document source aide à relier cette décision aux chunks, index, caches et tests qui doivent suivre le changement.

Comment définir les droits d'accès avant l'indexation ?

Le contrôle d'accès ne doit pas être ajouté après la première démonstration. Il conditionne les métadonnées à conserver, le mode de récupération des passages et les tests à exécuter.

Documentez au minimum :

Décision	Question à trancher	Preuve attendue dans le cadrage
Identité	Comment le système identifie-t-il l'utilisateur ?	Flux d'authentification et attributs disponibles
Autorisation	Quelle règle détermine l'accès à un document ?	Mapping entre droits métier et données indexées
Révocation	Que se passe-t-il lorsqu'un droit est retiré ?	Délai, mécanisme de synchronisation et scénario de test
Traçabilité	Que faut-il pouvoir expliquer après une réponse ?	Événements journalisés et durée de conservation validée

Notre article sur le contrôle d'accès dans un RAG d'entreprise détaille les architectures possibles. Pour préparer la décision avant le choix d'un mécanisme, utilisez aussi notre méthode pour documenter les choix d'architecture de contrôle d'accès. Ici, le point de cadrage est plus simple : aucun jeu de test ne doit être déclaré représentatif tant qu'il n'inclut pas des utilisateurs aux droits différents et des tentatives d'accès refusées.

Quelle réponse le système est-il autorisé à produire ?

Définissez un contrat de réponse avant de parler de prompt. Il précise notamment :

• si chaque réponse doit citer les documents utilisés ;
• quand le système doit répondre qu'il ne sait pas ;
• quelles actions exigent une validation humaine ;
• quels types d'information ne doivent pas être reformulés, agrégés ou exportés ;
• quel comportement adopter si les sources sont absentes, contradictoires ou trop anciennes.

Cette règle sépare la qualité linguistique de la qualité opérationnelle. Une réponse fluide sans source ne permet pas à l'utilisateur de vérifier l'information. Une réponse qui cite une source non autorisée est tout aussi inacceptable. Le contrat de réponse doit donc être testé avec les permissions et le corpus retenus, pas seulement avec des questions faciles.

Comment préparer une évaluation qui peut invalider le prototype ?

Le prototype doit répondre à des cas représentatifs, préparés avant son évaluation. Constituez un jeu de tests avec des questions réelles ou revues par les équipes métier. Pour chacune, stockez la réponse attendue, les sources autorisées, les sources interdites et une règle de notation.

Une grille minimale sépare cinq dimensions :

Dimension	Question de test
Exactitude	La réponse est-elle soutenue par le bon document ?
Ancrage	Les citations permettent-elles de vérifier la réponse ?
Autorisation	Le système n'expose-t-il que les passages autorisés ?
Utilité	La réponse aide-t-elle à accomplir la tâche sans reformulation excessive ?
Robustesse	Le système reconnaît-il ses limites face à une question hors corpus ou ambiguë ?

Mesurez aussi les cas négatifs : question hors périmètre, document supprimé, source contradictoire, utilisateur sans droit et instruction malveillante placée dans un document. Ces cas ne sont pas des détails de sécurité à reporter. Ils déterminent si le comportement est exploitable.

Pour approfondir la construction d'un corpus de test, consultez notre guide pour construire un jeu de tests RAG représentatif. Le principe reste le même : le jeu de tests appartient au cas d'usage, pas au fournisseur du modèle.

Quelles conditions d'exploitation faut-il connaître avant le build ?

Un RAG est un système vivant. Le cadrage doit préciser qui met à jour les sources, qui surveille les incidents et qui arbitre une baisse de qualité. Écrivez dès le départ :

1. le propriétaire métier du contenu et le responsable technique du système ;
2. la fréquence et le mécanisme de mise à jour des sources ;
3. les événements à tracer pour enquêter sur une réponse ;
4. les seuils qui déclenchent une revue, une limitation ou un arrêt ;
5. le chemin de retour utilisateur lorsqu'une réponse est erronée.

Cette préparation fait le lien avec les décisions de production : ingestion, recherche, observabilité et permissions. Le détail des arbitrages techniques est présenté dans les cinq décisions critiques d'un RAG en production.

Quels risques devez-vous traiter comme des hypothèses de conception ?

Le cadrage ne consiste pas à déclarer un système « conforme » ou « sécurisé ». Il rend les risques explicites et attribue un responsable à chaque décision. Le profil GenAI du NIST, publié en 2024, complète l'AI RMF avec des considérations propres à l'IA générative. Il peut servir de source de travail pour qualifier les risques, mais son usage reste volontaire et doit être adapté au contexte de l'organisation.

Pour un RAG d'entreprise, examinez au moins :

• l'accès indu aux données par une mauvaise propagation des permissions ;
• la réponse non fondée ou la citation d'une source obsolète ;
• l'instruction hostile contenue dans une source indexée ;
• la divulgation de données dans les traces ou les outils d'observabilité ;
• la dépendance à un fournisseur, à un modèle ou à une source critique ;
• l'absence de propriétaire chargé de corriger le corpus et les évaluations.

Le résultat attendu est une liste de risques liée au périmètre du prototype, avec une mesure de réduction, un propriétaire et un test. Ce n'est pas un registre générique réutilisé sans lecture.

Quels critères de passage devez-vous fixer avant de lancer le prototype ?

Terminez le cadrage par une page de décision. Elle doit contenir des seuils adaptés au cas d'usage, sans seuil universel inventé. Par exemple :

• le corpus de test couvre les rôles et les documents critiques retenus ;
• les réponses évaluées sont traçables vers des sources autorisées ;
• les tests d'accès refusé sont exécutés et documentés ;
• le propriétaire métier accepte les critères de réponse et les cas de refus ;
• l'équipe technique dispose d'un plan d'ingestion, d'exploitation et de retour arrière ;
• les risques ouverts sont connus, attribués et acceptés au niveau approprié.

À ce stade, la technologie devient un moyen de vérifier les hypothèses. Le prototype peut alors produire une décision : poursuivre, modifier le périmètre ou arrêter. C'est une sortie plus utile qu'une simple démonstration.

Quelle checklist utiliser pour votre prochaine réunion de cadrage ?

Apportez ces sept preuves à la réunion de décision :

1. un cas d'usage formulé comme une tâche et une décision métier ;
2. un corpus représentatif, avec son cycle de vie et ses exclusions ;
3. une règle d'accès testable, y compris pour les refus ;
4. un contrat de réponse et de citation ;
5. un jeu d'évaluation qui peut révéler un échec ;
6. un modèle d'exploitation avec des responsabilités nommées ;
7. des critères écrits pour poursuivre, réduire ou arrêter.

Si l'un de ces éléments manque, le prototype peut encore être utile pour apprendre. Il ne doit simplement pas être présenté comme une preuve de faisabilité de production.

FAQ

• Faut-il construire un prototype avant de cadrer un projet RAG ?

  Non. Le cadrage précède le prototype et définit ce que le prototype doit démontrer. Il peut inclure une exploration technique limitée, mais celle-ci doit servir une hypothèse de décision écrite.

• Combien de documents faut-il pour cadrer un RAG d'entreprise ?

  Il n'existe pas de nombre universel. Le corpus doit surtout représenter les types de documents, les cas difficiles et les droits d'accès du périmètre retenu. Un petit corpus varié et réaliste est plus utile qu'un volume important mais artificiellement propre.

• Quels sont les critères de réussite d'un prototype RAG ?

  Ils dépendent du cas d'usage. Fixez-les avant le test : exactitude vérifiable, citations vers des sources autorisées, respect des permissions, utilité métier et comportement sûr hors périmètre.

• Le NIST AI RMF rend-il un projet RAG conforme ?

  Non. Le NIST présente l'AI RMF comme un cadre volontaire de gestion des risques. Il aide à structurer les décisions, mais ne remplace pas l'analyse réglementaire, contractuelle, sécurité ou protection des données applicable à votre organisation.

Méthodologie et sources

• NIST AI Risk Management Framework, version 1.0 publiée le 26 janvier 2023. Consulté le 10 septembre 2026. Le NIST décrit un cadre volontaire pour mieux gérer les risques liés aux systèmes d'IA.
• NIST AI RMF Playbook, consulté le 10 septembre 2026. Il organise des actions proposées selon les fonctions Govern, Map, Measure et Manage et précise qu'il ne s'agit pas d'une checklist à appliquer intégralement.
• NIST AI RMF: Generative Artificial Intelligence Profile, publié le 26 juillet 2024, consulté le 10 septembre 2026.

La méthode présentée dans cet article est une grille de cadrage éditoriale pour des systèmes RAG d'entreprise. Elle ne contient ni données clients, ni métriques de mission, ni promesse de résultat. Les seuils de passage doivent être définis avec les équipes métier, sécurité et conformité concernées.

---

Vous devez décider si un cas RAG mérite un prototype et sur quel périmètre ? Décrivez votre contexte à IgnitionAI. L'objectif d'un premier échange est de clarifier les décisions, les dépendances et les preuves à réunir avant d'engager le build.