21 juillet 2026
Construire un assistant documentaire fiable avec citations, provenance et contrôle des accès
Une architecture RAG où chaque réponse peut être contestée, reliée à ses sources et limitée aux droits réels de l’utilisateur.
Dossier d’architecture appliquée — sources vérifiées le 21 juillet 2026
Résumé exécutif
Un assistant documentaire professionnel doit faire davantage que répondre avec assurance. Il doit montrer les sources utilisées, permettre de retrouver le passage exact, respecter les droits de l’utilisateur, signaler la fraîcheur et refuser lorsque les preuves sont insuffisantes. La fiabilité ne repose donc pas uniquement sur le modèle de langage. Elle se construit dans l’ingestion, la version des documents, le retrieval, les citations, l’observabilité et les procédures de mise à jour. Knowledge Base sert ici de projet de référence pour une architecture où la réponse reste contestable.
Le problème à résoudre
Les assistants documentaires échouent souvent de manière silencieuse : un fichier n’a pas été extrait, une URL est obsolète, un chunk perd son contexte, une citation pointe vers la bonne source mais pas vers le bon passage, ou un filtre d’accès est appliqué trop tard. L’utilisateur voit une réponse fluide sans pouvoir distinguer une preuve d’une reconstruction plausible.
Cette question doit être traitée comme une décision d’architecture et d’exploitation. Un composant impressionnant en démonstration peut rester inutilisable si les droits, la reprise, les coûts et les preuves sont implicites. À l’inverse, une première version bornée peut produire de la valeur si son périmètre est clair et si ses résultats sont mesurés.
Pour qui et pour quelle décision ?
- PME et associations avec documentation dispersée
- collectivités et équipes support
- équipes qualité ou conformité
- développeurs de portails de connaissances
Le lecteur ne doit pas seulement comprendre la technologie. Il doit pouvoir décider s’il faut lancer un audit, établir une baseline, construire une preuve de concept, organiser un pilote ou écarter l’approche lorsque les prérequis ne sont pas réunis.
Architecture de référence
Ingestion
Source, propriétaire, version, droits, date et statut du job sont conservés.
Extraction
Texte, structure, tableaux et erreurs sont observables avant indexation.
Indexation
Chunks stables, métadonnées, embeddings et index lexical restent reliés au document.
Retrieval
Les ACL filtrent les candidats avant la recherche et le reranking.
Réponse
Le modèle reçoit un contexte borné et doit citer les passages utilisés.
Preuve
L’interface expose source, extrait, date, version et limites de confiance.
L’intérêt de cette décomposition est de rendre les responsabilités remplaçables et testables. Le domaine métier ne doit pas dépendre d’un fournisseur, d’un modèle ou d’une interface unique. Les adaptateurs peuvent évoluer, tandis que les règles de données, de preuve et de décision restent stables.
Fonctionnement opérationnel
- Refuser l’indexation silencieuse : toute erreur produit un statut visible.
- Conserver une identité stable du document et des chunks à travers les mises à jour.
- Appliquer les droits avant retrieval et tester les accès négatifs.
- Générer des citations ancrées sur les passages réellement fournis au modèle.
- Afficher la fraîcheur et distinguer source interne, source publique et résultat web.
- Prévoir resynchronisation ciblée, déduplication et rollback d’index.
Chaque étape doit produire un état observable. Une décision sans version de politique, un appel sans identifiant de trace ou une mise à jour sans rollback ne peut pas être considérée comme une capacité maîtrisée.
Sécurité et gouvernance
Les contrôles prioritaires sont les suivants :
- ACL jusqu’au niveau document ou chunk selon le besoin
- séparation des espaces et des exports
- désactivation des outils non nécessaires
- provenance des contenus récupérés sur le web
- détection d’instructions injectées dans les documents
- rétention et suppression cohérentes entre source, index et logs
La sécurité ne doit pas être résumée à une liste de fonctionnalités. Elle doit être vérifiée par des scénarios négatifs : permission absente, donnée interdite, outil indisponible, secret expiré, résultat ambigu, interruption et reprise.
Ce qui existe, ce qui reste à prouver
Disponible
- architecture Next.js/FastAPI et stockage PostgreSQL/PGVector documentés
- Tika, SearXNG, MongoDB et Ollama prévus dans le pipeline
- comptes, bases de connaissances et ingestion décrits
Expérimental
- citations inspectables de bout en bout
- resynchronisation ciblée
- graphe source-chunk-réponse
Planifié
- streaming FastAPI réel selon l’état documenté
- tests d’accès multi-utilisateurs
- dashboard qualité et fraîcheur
Non couvert
- preuve de charge publique
- couverture de tous les formats
- garantie juridique des réponses
Registre de preuves
| Élément | Statut | Interprétation |
|---|---|---|
| Architecture | prouvé | Le dépôt privé confirme comptes, multi-KB, ingestion asynchrone, Next.js/FastAPI et les principaux services ; citations end-to-end et streaming restent à consolider. |
| Citations | cible | La chaîne réponse-chunk-source doit être démontrée sur un scénario end-to-end. |
| Fraîcheur | à mesurer | La resynchronisation d’URL doit prouver l’absence de doublons et le remplacement ciblé. |
| ACL | à mesurer | Des fixtures sentinelles doivent vérifier qu’aucun chunk interdit n’entre dans le contexte. |
Cas d’usage pertinents
- assistant de procédures internes
- recherche dans des dossiers de projet
- support client fondé sur documentation validée
- assistant de ressources publiques avec provenance
- capitalisation R&D interrogeable
Ces cas d’usage ne constituent pas des promesses de résultat. Ils indiquent où un atelier ou un pilote peut produire une preuve utile sans engager immédiatement une transformation globale.
Protocole d’évaluation proposé
- ingérer plusieurs formats avec erreurs contrôlées
- vérifier la trace source-document-chunk-index
- poser des questions avec et sans réponse
- inspecter citations, extraits et versions
- tester deux utilisateurs aux droits différents
- modifier une source puis vérifier la resynchronisation
- mesurer latence, fidélité et taux de refus
Les résultats doivent inclure les échecs et les régressions. Une configuration ne doit pas être promue parce qu’elle améliore une moyenne si elle dégrade un scénario critique ou contourne une contrainte de données.
De la preuve au pilote
Le passage à un pilote ne devrait intervenir qu’après la production d’une baseline et d’un registre des hypothèses encore ouvertes. Le premier périmètre doit rester assez petit pour que chaque entrée, décision et sortie puisse être inspectée. Il est préférable de couvrir un cas d’usage réel avec quelques utilisateurs et des critères d’acceptation explicites plutôt que d’ouvrir immédiatement la solution à toute l’organisation.
Le pilote doit produire des actifs réutilisables : jeu de tests, architecture observée, matrice de permissions, dictionnaire de métriques, runbook d’incident et procédure de retour arrière. Ces livrables permettent de décider si le système doit être étendu, corrigé, suspendu ou abandonné. Ils évitent aussi de dépendre d’une démonstration ponctuelle difficile à reproduire.
La valeur commerciale se construit donc autour d’un engagement progressif : audit, atelier, benchmark, preuve de concept puis pilote borné. Les prestations proposées dans cet article ne supposent pas que toutes les capacités sont déjà industrialisées ; elles organisent précisément le travail nécessaire pour transformer une architecture en résultat vérifiable.
Limites et risques résiduels
- Une citation correcte ne garantit pas que l’interprétation est correcte.
- Les documents eux-mêmes peuvent contenir des erreurs ou être obsolètes.
- L’OCR et les tableaux complexes nécessitent des traitements spécifiques.
- Les droits doivent être répercutés dans les caches, exports et sauvegardes.
- L’assistant ne remplace pas un professionnel pour une décision réglementée.
Cette transparence protège le lecteur et le projet. Elle évite de confondre une architecture cible, un composant disponible et une capacité démontrée dans des conditions reproductibles.
Questions fréquentes
Qu’est-ce qu’une citation utile ?
Une citation qui ramène au passage exact, à la version et à la source accessible à l’utilisateur.
Pourquoi garder la provenance après indexation ?
Pour expliquer, corriger, supprimer et réévaluer une réponse lorsque la source évolue.
Peut-on mélanger web et documents internes ?
Oui, mais l’interface doit distinguer origine, fraîcheur et niveau de confiance.
Comment gérer une réponse absente ?
Le système doit détecter l’insuffisance de preuves et refuser ou demander une précision.
Sources et méthode
Les sources ci-dessous sont officielles ou primaires. Elles soutiennent le cadre d’architecture et d’évaluation ; elles ne prouvent pas à elles seules la maturité des projets présentés.
- Langfuse — trace d’une ingestion
- Microsoft GraphRAG — inputs et métadonnées
- OWASP Agentic Top 10 2026
Le dépôt privé GitHub TheWatcher01/knowledge_base_v2, branche main, a été vérifié le 21 juillet 2026. Son README et son arborescence confirment l’architecture Next.js/FastAPI, PostgreSQL/PGVector, MongoDB, Tika, SearXNG, Ollama et Docker Compose. Les métriques de qualité, l’isolation et les flux end-to-end restent soumis aux protocoles décrits.