Detected promise
Framework complet — Monter une “mémoire d’entreprise” (RAG) : architecture type, prérequis, gouvernance des accès
Reconstructed contract
framework
Voici une ressource clé en main pour construire une mémoire d’entreprise interrogeable (RAG) à partir de vos documents (PDF, mails exportés, SharePoint/Drive, wikis). Elle couvre : (1) une architecture de référence, (2) les prérequis data et sécurité, (3) la gouvernance des accès et la qualité, (4) un plan de déploiement en 30 jours avec checklists et modèles. Aucun DM nécessaire : le “doc” est ici, généré à partir du contexte fourni (sans web research).
Resource without ritual
The promised resource, no comment required
1) Le framework en 7 briques (vue d’ensemble)
Objectif : répondre à des questions métier en citant des extraits de documents internes, avec contrôle d’accès.
Brique A — Cas d’usage & périmètre
Définir 3 à 5 cas d’usage prioritaires (ex. réponses AO, support interne, réglementaire, onboarding).
Définir ce qui est hors scope (ex. données RH sensibles, secrets industriels non nécessaires).
Brique B — Inventaire & préparation des données (la moitié du succès)
Cartographier les sources : SharePoint/Drive, GED, Slack/Teams export, CRM notes, wiki, emails (export PST/mbox si besoin), dossiers réseau.
Qualité : dédupliquer, gérer versions, dater, identifier propriétaires.
Brique C — Ingestion & normalisation
Convertir en texte : PDF → texte/OCR, docx/pptx/html/markdown, emails.
Enrichir : métadonnées (équipe, confidentialité, date, statut, client/projet, type doc).
Brique D — Indexation (recherche)
Chunking (découpage) : taille 300–1 000 tokens selon type, avec chevauchement.
Embeddings + index vectoriel (recherche sémantique) + index lexical (BM25) idéalement en hybride.
Brique E — Récupération (retrieval) & orchestration
Filtrer d’abord par permissions (ABAC/RBAC), puis chercher.
Récupération hybride, reranking (facultatif) et sélection des passages.
Brique F — Génération de réponse “assistée par sources”
LLM rédige à partir des passages récupérés.
Exiger : citations (liens, titres, pages/sections), et “je ne sais pas” si insuffisant.
Brique G — Observabilité & amélioration continue
Logs (requêtes, docs utilisés, taux ‘no answer’, feedback).
Évaluation : précision, couverture, hallucinations, temps de réponse.
Règle d’or : RAG ≠ magie. C’est un produit data + sécurité + UX, pas juste un prompt.
2) Architecture type (référence) — du document à la réponse
Architecture logique (agnostique des outils) :
1) Sources
GED/Drive/SharePoint
Wiki/Confluence/Notion
CRM (notes, comptes-rendus)
Emails exportés
Tickets support
2) Pipeline d’ingestion (ETL)
Connecteurs + planification
Extraction texte + OCR
Normalisation (UTF-8, nettoyage)
Détection langue
Déduplication (hash contenu + similarité)
Gestion des versions (doc_id stable + version_id)
3) Enrichissement
Métadonnées obligatoires : owner, team, access_policy, created_at, updated_at, doc_type, system_of_record, retention_class
Métadonnées métier : client, produit, pays, norme, statut (brouillon/validé/obsolète)
4) Index(s)
Index vectoriel (embeddings)
Index lexical (BM25) (recommandé)
Stockage passages (chunks) + pointeur vers document original
5) Couches de sécurité
AuthN : SSO (OIDC/SAML)
AuthZ : RBAC (rôles) + ABAC (attributs : équipe, projet, client, classification)
Filtrage au niveau du chunk (pas seulement doc) si nécessaire
6) Retrieval & orchestration
Query understanding (facultatif : expansion, reformulation)
Permission filter → hybrid search → rerank → top-K passages
7) LLM + réponse
Prompt système (règles) + contexte (passages)
Réponse structurée + citations
Options : mode “brouillon” vs “réponse finale validée”
8) Feedback & monitoring
Boutons : utile/pas utile, “source manquante”, “info périmée”
Dashboards : adoption, taux de refus, temps moyen, top queries, docs les plus cités
Diagramme texte (à copier dans un doc interne) :
[Sources] → [Ingestion/OCR] → [Nettoyage + Métadonnées + Dédup/Versioning] → [Chunks] → [Index Vectoriel + Index Lexical] → (User Query + SSO) → [Filtre Permissions] → [Recherche Hybride + Rerank] → [Passages cités] → [LLM] → [Réponse + Sources] → [Feedback/Logs] → [Amélioration pipeline]
3) Prérequis data : le “tri en amont” (checklist + règles)
A. Politique de qualité minimale (sinon “bouillie”)
Un document doit avoir : un propriétaire (owner), une date (created/updated), une classification (public interne/confidentiel…), une source de vérité.
Marquer explicitement : VALIDE / OBSOLÈTE / BROUILLON.
Règle : si deux documents se contredisent, un seul peut être “VALIDE”.
B. Déduplication & versions (pratique)
Dédup exacte : hash du texte normalisé.
Dédup quasi : similarité (ex. MinHash/SimHash) + seuil 90–95%.
Conserver : la version la plus récente + l’historique si utile (AO gagnés : oui ; procédures : plutôt dernière version).
C. Taxonomie simple (ne pas surdesigner)
doc_type : AO, procédure, fiche produit, mail client, CR réunion, note support, contrat, FAQ, réglementation.
domain : commercial, juridique, tech, qualité, RH.
entity : client/projet/produit (si applicable).
D. Rétention & conformité
Définir ce qui ne doit pas entrer : données personnelles inutiles, secrets non nécessaires, documents sans droits.
Appliquer une rétention (ex. 2/5/10 ans) selon type.
E. “Gold set” pour démarrer
Créer un corpus pilote : 200–2 000 documents max, mais propres et pertinents.
C’est mieux qu’un data lake sale de 2 millions de pages.
4) Gouvernance des accès : “consultable” ≠ “tout le monde voit tout”
Modèle recommandé : RBAC + ABAC + héritage des permissions des systèmes sources.
A. Rôles (RBAC) — exemple
Admin plateforme (tech) : gère connecteurs, index, monitoring.
Data steward (métier) : valide taxonomie, règles de qualité, statut VALIDE/OBSOLÈTE.
Contributeur : ajoute/étiquette des docs.
Lecteur : interroge uniquement.
B. Attributs (ABAC) — exemple
team = {Sales, Legal, Engineering, QA}
project/client = {ClientA, ClientB}
classification = {Interne, Confidentiel, Secret}
geography = {FR, EU, US} (si contraintes)
Règles :
Un utilisateur ne peut récupérer que des chunks pour lesquels il a “read”.
Filtrer avant la recherche (pré-filtre) pour éviter fuites via le ranking.
C. “Document security trimming” : décision importante
Niveau document : plus simple, mais risque d’exposer un extrait sensible dans un doc globalement accessible.
Niveau chunk : plus fin, plus coûteux (métadonnées et maintenance). Utile si vos docs mélangent souvent sensible/non sensible.
D. Workflow de validation
Nouveau doc → statut BROUILLON
Revue steward → VALIDE (ou rejet)
Revue périodique (trimestrielle/semestre) : passer en OBSOLÈTE
E. Journalisation (audit)
Conserver : qui a cherché quoi, quels docs ont été consultés (sans stocker le contenu de la question si sensible, ou avec anonymisation).
5) Design produit : comment éviter l’assistant “perroquet”
A. Contrat de réponse (à afficher)
Répondre uniquement à partir des sources internes fournies.
Citer au moins 2 extraits quand possible.
Si sources insuffisantes : dire “Je ne trouve pas dans la base” + proposer où chercher / qui contacter.
B. Formats utiles (au lieu d’un paragraphe vague)
Mode “Synthèse” : 5 bullets + citations.
Mode “Procédure” : étapes numérotées + prérequis + risques.
Mode “Réponse AO” : plan + arguments + preuves + références de cas gagnants.
Mode “Regulatory check” : contrainte + champ d’application + exceptions + source.
C. Anti-hallucination (pragmatique)
Limiter la fenêtre : top 5–12 passages, pas 50.
Reranker si vous avez beaucoup de bruit.
Forcer la citation : toute affirmation factuelle = une source.
D. Feedback utilisateur (indispensable)
“Utile / pas utile” + raison : (info périmée / manque de source / mauvaise interprétation / accès manquant).
Bouton “Signaler obsolète” : crée une tâche pour le steward.
6) Plan de déploiement en 30 jours (MVP sérieux)
Semaine 1 — Cadrage & sécurité
Choisir 3 cas d’usage mesurables.
Définir corpus pilote + owners.
Définir RBAC/ABAC + classification.
Décider : niveau doc vs chunk pour permissions.
Semaine 2 — Données & ingestion
Connecteurs (ou export manuel) vers 2–3 sources.
Nettoyage, OCR, dédup, versioning.
Mise en place métadonnées obligatoires.
Semaine 3 — Index & retrieval
Chunking + embeddings + index lexical.
Retrieval hybride + pré-filtre permissions.
Tests sur 50 questions réelles (gold questions).
Semaine 4 — Produit & mesure
UI simple (search/chat) + citations + liens vers doc.
Feedback in-app.
Dashboard : adoption, taux no-answer, top sources.
Go/No-go + backlog (qualité docs, nouveaux connecteurs, reranking, chunk-level security).
Livrables MVP attendus
Corpus pilote propre
Règles de gouvernance (1 page)
Assistant avec citations
50 questions tests + résultats
Une personne “steward” identifiée
7) Templates copy-paste (gouvernance, dataset, évaluation, prompts)
A. Template — Charte de gouvernance (1 page)
Objectif : …
Périmètre : …
Corpus inclus/exclus : …
Rôles : Admin / Steward / Contributeur / Lecteur
Classification : Interne / Confidentiel / Secret
Règles qualité : owner obligatoire, statut doc, date, version
Revue : fréquence + responsable
Audit : logs conservés X jours/mois
B. Template — Fiche document (métadonnées)
doc_id :
titre :
owner :
équipe :
doc_type :
classification :
client/projet :
pays :
statut : BROUILLON / VALIDE / OBSOLÈTE
source_system :
url_emplacement :
created_at / updated_at :
valid_until (optionnel) :
C. Template — Jeu de test (50 questions)
Colonnes :
question
persona (sales/legal/tech)
réponse attendue (bref)
docs de référence (liens)
critères (doit citer, doit refuser si pas de source)
résultat (OK/KO)
notes
D. Prompt système (exemple)
“Tu es un assistant interne. Tu réponds uniquement à partir des EXTRATS fournis dans CONTEXTE. Pour chaque affirmation factuelle, cite une source (titre + section/page). Si le CONTEXTE ne permet pas de répondre, dis-le explicitement et propose 2 questions de clarification ou où trouver l’info. Ne devine pas. Structure la réponse selon le mode demandé (Synthèse/Procédure/AO/Regulatory).”
E. Prompt de requête (exemple utilisateur)
“Mode: Réponse AO. Contexte: Client X, lot Y, contrainte Z. Question: propose un plan + arguments + preuves à partir des AO gagnés. Cite les sources.”
F. Rubrique de décision “chunk size” (règle simple)
FAQ/procédures courtes : chunks plus petits (300–600 tokens)
AO/contrats longs : chunks plus grands (600–1 000) + découpage par sections
Tableaux : extraire en CSV/texte structuré si possible, sinon augmenter overlap