- Définir le périmètre autorisé à partir d’une identité vérifiée côté serveur.
- Conserver les liens entre sources, versions, extraits et réponses.
- Évaluer l’autorisation, l’actualité, la traçabilité et les cas de rupture séparément.
Définir le contrat de connaissance
Avant de choisir une base vectorielle, décrivez l’objet que le système manipule. Un document possède une origine, une version, un propriétaire, une période de validité et des règles d’accès. Un extrait dérivé doit rester rattaché à cet objet. Une synthèse doit permettre de remonter aux extraits qui la soutiennent.
Un schéma minimal peut comporter les champs suivants : organization_id, source_id, source_version, chunk_id, classification, allowed_principals, effective_from, effective_until, ingested_at et content_hash. Ce schéma est une proposition de conception ; sa pertinence dépend du modèle d’identité, des sources et de la politique de conservation de l’organisation.
Il faut ensuite définir les transitions. Que devient un extrait lorsque son document est corrigé ? Comment la suppression est-elle propagée ? À quel moment une modification des droits devient-elle effective dans la recherche et les caches ? Ces réponses appartiennent au contrat du service.
Appliquer l’autorisation avant la génération
Le périmètre d’une requête doit provenir d’une identité vérifiée côté serveur. Un identifiant d’organisation fourni par le navigateur ne suffit pas à établir l’appartenance. La recherche opère ensuite dans le périmètre autorisé, avec des règles qui restent indépendantes du texte produit par le modèle.
La documentation Azure AI Search distingue plusieurs mécanismes de contrôle au niveau du document, dont les filtres de sécurité. Certaines capacités natives y sont signalées en préversion : leur disponibilité et leur statut doivent être vérifiés pour le service retenu. Source : Microsoft Learn.
Pour la conception d’un RAG, OWASP recommande de conserver les métadonnées d’accès sur les extraits et de vérifier les permissions lors de la recherche. La révocation doit aussi concerner les données dérivées et les réponses mises en cache. Source : OWASP, RAG Security.
Un test utile consiste à retirer l’accès d’un utilisateur après l’indexation, puis à rejouer la même requête. Le résultat attendu doit être défini à l’avance, y compris pour une conversation déjà ouverte et pour un cache auparavant alimenté.
Cadre technique indépendant des produits. Les références et limites sont détaillées dans l’article.
Télécharger l’infographie (SVG) ↓Rendre les versions et la provenance exploitables
La date de modification d’un fichier et la date d’effet d’une décision répondent à deux questions différentes. Une politique peut être publiée aujourd’hui et entrer en vigueur plus tard. Une décision ancienne peut rester applicable malgré la mise à jour d’une présentation.
Le modèle de données gagne donc à distinguer ces temporalités. La réponse peut alors préciser le périmètre retenu : « règle applicable à cette date », « version actuellement validée » ou « document historique ». Lorsqu’une source est remplacée, la relation entre les versions doit rester explicite.
Le modèle de provenance PROV du W3C fournit des concepts pour relier entités, activités et agents. Il peut inspirer la traçabilité d’un traitement ; il n’impose pas à lui seul l’architecture d’un Company Brain. Source : W3C, PROV-O.
Conserver une frontière entre contenu et instruction
Un document retrouvé peut contenir une instruction malveillante. OWASP identifie ce risque d’injection indirecte et recommande de traiter le contenu récupéré comme des données, avec des frontières explicites. Le modèle ne doit pas être chargé de faire respecter les permissions. Source : OWASP, RAG Security.
Dans notre cadre de conception, une réponse documentaire et une action sur un système métier suivent deux contrats distincts. L’action précise son périmètre, l’identité utilisée, les paramètres acceptés et les validations requises. Une phrase dans une pièce jointe ne peut pas modifier ces règles.
Évaluer des parcours complets
Le jeu d’évaluation peut associer des questions ordinaires et des cas de rupture : source absente, versions contradictoires, accès révoqué, document empoisonné, organisation incorrecte ou index momentanément indisponible. Pour chaque cas, on définit le comportement attendu et les pièces permettant de l’observer.
| Dimension | Question de recette |
|---|---|
| Autorisation | Des éléments hors périmètre atteignent-ils le contexte du modèle ? |
| Actualité | La version utilisée correspond-elle à la période demandée ? |
| Traçabilité | Chaque affirmation vérifiable peut-elle être reliée à sa source ? |
| Incertitude | L’absence de preuve est-elle visible dans le résultat ? |
| Continuité | Une mise à jour ou une révocation produit-elle l’effet attendu ? |
Ces dimensions doivent être examinées séparément. Un résultat moyen peut masquer une rupture d’autorisation. Les seuils, les conditions bloquantes et la procédure de reprise relèvent de la gouvernance du service, selon les conséquences de son usage.
La question d’architecture devient alors très concrète : pour cette personne, dans ce contexte et à cet instant, quelles connaissances le système peut-il utiliser, et comment peut-il le démontrer ?
Portée de cet article : cadre technique proposé par Khaleo. Il ne décrit ni ne certifie l’implémentation interne de Heeplab ou de Hack&Show.
Une perspective, avec ses appuis.
Analyse originale Khaleo, publiée le 30 octobre 2026. Les sources externes soutiennent les constats explicitement cités ; les propositions et cadres Khaleo relèvent de notre analyse. Les dates et limites des observations sont conservées. Les exemples fictifs sont identifiés comme tels.
Les éléments chiffrés ne constituent pas une prévision de résultat pour une autre organisation. Les cadres sont à adapter au contexte et aux expertises nécessaires.
Appliquons cette réflexion à votre contexte
