Sécuriser les flux de connaissances : architectures hybrides pour assistants internes

Un assistant interne devient un risque dès qu’il répond à partir d’un document que son utilisateur ne devrait pas voir, ou qu’il contourne les règles appliquées aux espaces documentaires existants. Pour éviter ce décalage, les architectures hybrides pour assistants internes doivent rapprocher le modèle de langage des sources de connaissance sans dissocier la recherche, les droits d’accès, la conformité et la traçabilité.

Le sujet n’est donc pas seulement de connecter un LLM à SharePoint, à un intranet ou à des outils tiers. Il consiste à concevoir un système où chaque réponse est fondée sur un contenu pertinent, accessible à la personne qui interroge l’assistant, protégé selon sa sensibilité et auditable. Le modèle hybride, combinant l’environnement Microsoft 365 et des référentiels externes, fournit un cadre concret à condition de traiter la gouvernance comme un composant d’architecture, et non comme une étape de validation finale.

Ce que recouvrent les architectures hybrides pour assistants internes

Une architecture hybride relie un assistant conversationnel à plusieurs domaines de connaissance : les contenus Microsoft 365, tels que SharePoint et OneDrive, mais aussi des référentiels non-Microsoft via des connecteurs. L’assistant ne devrait pas répondre uniquement à partir de ses connaissances générales : il doit récupérer des éléments de contexte dans le patrimoine informationnel de l’entreprise, puis les utiliser pour formuler une réponse adaptée.

Dans les documents d’architecture Microsoft, Copilot est décrit comme un orchestrateur associé à un LLM, qui exploite les contenus organisationnels disponibles dans Microsoft Graph afin de produire des réponses contextualisées. Cette vision est utile au-delà d’un produit particulier : l’orchestrateur coordonne l’identité de l’utilisateur, l’intention de sa demande, la recherche documentaire, les règles de sécurité et la génération. Le LLM est important, mais il ne doit pas devenir le point de contrôle unique.

Réponse courte : une architecture hybride sécurisée permet à un assistant de rechercher dans Microsoft 365 et dans des sources externes, tout en appliquant les droits du demandeur au moment de la récupération. La réponse ne doit être générée qu’à partir de contenus auxquels cet utilisateur est autorisé à accéder, avec des contrôles de conformité, de protection et d’audit sur l’ensemble du flux.

Cette approche diffère d’un chatbot documentaire élémentaire. Dans un montage simplifié, une équipe exporte des fichiers, les découpe en fragments, les vectorise et les charge dans une base externe. Cette chaîne peut être pertinente dans certains cas, mais elle crée une nouvelle copie à protéger et à synchroniser. Elle oblige également à reproduire, dans cet index secondaire, les permissions, les règles de rétention, les changements de sensibilité et les suppressions.

Le modèle de hybrid index présenté par Microsoft vise précisément à réduire cette duplication. L’API Retrieval peut retourner des fragments de texte issus de l’index hybride qui alimente Microsoft 365 Copilot, afin d’ancrer une application d’IA générative dans des connaissances Microsoft 365 et non-Microsoft, sans maintenir un index RAG répliqué séparé. « Sans index dupliqué » ne signifie pas « sans conception » : cela déplace le travail vers l’intégration, les connecteurs, les droits et l’exploitation, là où se situent les véritables risques d’un assistant interne.

Pourquoi la sécurité doit commencer à la récupération RAG

Un contrôle appliqué après la rédaction de la réponse est insuffisant. Si un fragment confidentiel a déjà été transmis au contexte du modèle, le problème de divulgation existe, même si une couche ultérieure tente de filtrer une phrase ou de masquer un nom. La bonne frontière de sécurité se situe avant la génération : lors de la recherche et de la sélection des contenus qui alimentent le contexte.

Microsoft indique que Copilot ne peut résumer ou référencer que les contenus auxquels l’utilisateur est autorisé à accéder. L’API Retrieval applique également un security trimming au contenu pour l’utilisateur appelant et respecte les contrôles d’accès du tenant. Pour une équipe projet, ce principe se traduit par une règle claire : l’identité transmise à la recherche doit être celle de l’utilisateur final, ou une identité déléguée dont les droits sont strictement équivalents et vérifiables.

Le chemin d’une requête à sécuriser

1. Authentifier le demandeur.

   L’assistant doit connaître une identité fiable, son tenant et, lorsque c’est pertinent, son contexte d’organisation ou de rôle.

2. Interpréter l’intention.

   L’orchestrateur détermine si la demande nécessite une recherche, quelles sources sont pertinentes et si une action est envisagée.

3. Récupérer avec les droits effectifs.

   La recherche applique les autorisations sur les éléments, espaces et fichiers au moment de la requête.

4. Construire un contexte borné.

   Seuls les fragments nécessaires, issus de résultats autorisés, sont fournis au modèle avec des instructions de comportement.

5. Générer et tracer.

   La réponse est produite, puis l’interaction, les références et les événements utiles à la conformité peuvent être conservés selon les politiques en vigueur.

Cette séquence évite un anti-pattern fréquent : un compte de service surpuissant qui indexe tout, puis un filtrage applicatif approximatif au moment de l’affichage. Ce choix paraît pratique au début, car il simplifie les appels techniques. Il est pourtant fragile : il sépare l’assistant des permissions réelles, multiplie les règles maison et complique les investigations lors d’un incident.

Le principe du moindre privilège vaut aussi pour les fichiers chiffrés. Microsoft précise que les éléments chiffrés nécessitent les droits EXTRACT ou VIEW appropriés, et que des contenus protégés par Microsoft Purview Information Protection peuvent ne pas être retournés si l’utilisateur ne dispose pas de droits suffisants. Ce comportement n’est pas une limitation à contourner : c’est une propriété attendue d’un assistant fiable. Une réponse qui indique ne pas pouvoir accéder à une source peut être plus sûre et plus honnête qu’une réponse apparemment complète mais bâtie sur une exposition excessive.

Choisir entre index hybride et index RAG répliqué

Le choix n’oppose pas un RAG « moderne » à une solution « ancienne ». Il oppose deux responsabilités opérationnelles. Avec un index RAG répliqué, l’organisation contrôle finement le schéma d’indexation, les embeddings, le classement et parfois le déploiement du moteur de recherche. En contrepartie, elle devient responsable de la copie de données et de l’alignement durable entre cette copie et les systèmes de référence.

L’index hybride de Microsoft 365 Copilot cherche à offrir un chemin plus direct pour les connaissances déjà gérées dans Microsoft 365 et pour des sources connectées. L’API Retrieval est explicitement positionnée pour simplifier le RAG sans répliquer, réindexer, découper et sécuriser les données dans un index séparé. Pour une organisation fortement outillée autour de Microsoft 365, cette option peut réduire le nombre de mécanismes à maintenir.

• Privilégier un index hybride

  lorsque les sources clés sont déjà gouvernées dans Microsoft 365, que les connecteurs couvrent les référentiels externes nécessaires et que la réutilisation des contrôles existants est prioritaire.

• Envisager un index répliqué

  lorsqu’un besoin métier impose un pipeline de recherche très spécifique, des transformations documentaires particulières ou des sources qui ne peuvent pas être intégrées au modèle de connecteurs retenu.

• Éviter le choix par défaut

  consistant à tout copier dans une base vectorielle parce que c’est le premier tutoriel disponible. L’index est une surface de sécurité et de conformité, pas seulement une optimisation de pertinence.

Un index séparé n’est pas automatiquement non conforme ou dangereux. Il doit cependant répondre à des questions précises : où résident les fragments ? qui peut les lire ? comment les ACL d’origine sont-elles transposées ? à quel délai une révocation est-elle répercutée ? comment gère-t-on une étiquette de sensibilité modifiée, un document supprimé ou une règle de rétention ? Si les réponses restent théoriques, l’architecture n’est pas prête pour des connaissances internes sensibles.

À l’inverse, l’index hybride n’élimine pas toute responsabilité. Il faut qualifier les connecteurs, évaluer la qualité des sources, définir les périmètres accessibles et tester les résultats avec des identités représentatives. Son intérêt est de conserver un lien plus étroit entre la récupération et les contrôles du système de contenu, plutôt que d’exiger une reproduction parfaite de ces contrôles dans une couche supplémentaire.

Unifier Microsoft 365 et les sources externes sans banaliser les droits

Les connaissances opérationnelles sont rarement concentrées dans un seul outil. Un chef de projet peut avoir besoin d’une procédure dans SharePoint, d’une décision stockée dans OneDrive et d’une information de référence située dans un dépôt tiers. Une architecture hybride utile doit donc fournir une expérience de recherche cohérente, sans donner l’impression trompeuse que tous les contenus relèvent d’un même niveau de confiance.

Microsoft indique que l’API Retrieval peut combiner SharePoint et OneDrive avec des connecteurs Microsoft 365 Copilot afin de créer une base de connaissances unifiée couvrant des dépôts Microsoft et tiers, avec des contrôles de sécurité et de conformité cohérents. Le mot important est « cohérents », non « identiques ». Chaque source possède ses propres modèles de droits, métadonnées, cycles de vie et contraintes ; l’intégration doit préserver ce qui est significatif pour la sécurité.

Cartographier les sources avant de les connecter

Avant d’ouvrir un nouveau périmètre à l’assistant, l’équipe doit identifier le propriétaire de la source, sa population d’utilisateurs, le type de contenus qu’elle contient, ses règles de partage et son niveau de maturité documentaire. Cette étape est particulièrement importante pour les espaces collaboratifs ouverts, les sites historiques et les zones où les liens de partage ont été multipliés au fil des projets.

La question n’est pas uniquement « l’assistant peut-il lire cette source ? ». Il faut aussi demander : « est-ce que les droits actuels représentent réellement ce que l’organisation souhaite exposer par recherche conversationnelle ? » Un document oublié dans un espace trop largement accessible peut devenir bien plus visible lorsqu’un assistant sait le retrouver en quelques mots. L’IA ne crée pas nécessairement le surpartage ; elle le rend plus facile à exploiter.

• Classer les référentiels selon leur criticité, leur propriétaire et leur audience normale.

• Repérer les espaces partagés de manière large, les liens anonymes ou les groupes obsolètes selon les règles de l’organisation.

• Vérifier que les connecteurs ne font pas perdre les signaux de sécurité nécessaires à l’application des droits.

• Définir les sources exclues du périmètre initial, notamment lorsque leur gouvernance ou leur qualité documentaire n’est pas suffisante.

• Prévoir un mécanisme de désactivation ou de retrait rapide d’une source en cas de problème.

La gouvernance unifiée ne signifie pas que chaque équipe doit abandonner ses outils. Elle signifie que l’assistant respecte les frontières de ces outils et que l’entreprise dispose d’une vue de pilotage cohérente sur les données utilisées. Pour un responsable web ou IT, c’est également un enjeu de produit : un périmètre réduit, compréhensible et bien gouverné produit souvent des réponses plus fiables qu’un assistant connecté trop tôt à l’ensemble du SI.

Faire des labels de sensibilité et du chiffrement des contrôles actifs

La sécurité d’un assistant ne repose pas seulement sur des listes d’accès. Les labels de sensibilité, le chiffrement et les politiques de protection de l’information permettent de distinguer les contenus par leur niveau de traitement attendu. Microsoft documente que Copilot fonctionne avec les labels de sensibilité et le chiffrement Microsoft Purview pendant les phases de grounding et de génération.

Cette continuité est essentielle, car l’information risque de changer de forme. Un fichier peut devenir un résumé, une synthèse de réunion, une note de préparation ou une série de recommandations. Si la protection s’arrête au document source, l’assistant peut créer une nouvelle sortie qui échappe aux règles applicables au contenu d’origine. Lorsque cette capacité est prise en charge, le contenu généré peut hériter du label de sensibilité ayant la priorité la plus élevée parmi les contenus utilisés.

Concevoir les sorties comme des objets informationnels

Dans un projet d’assistant, une réponse ne doit pas être considérée comme du texte temporaire sans statut. Elle peut être copiée dans un e-mail, ajoutée à un compte rendu, réutilisée dans une présentation ou transformée en décision. Les équipes sécurité, conformité et produit doivent donc définir ce qui est attendu pour les réponses portant sur des données protégées : affichage, export, partage, conservation et étiquetage.

Le chiffrement constitue une limite volontaire de l’assistant. Lorsqu’un contenu ne peut pas être récupéré faute de droits, il n’est pas souhaitable de créer une voie de contournement par une copie non chiffrée ou une identité technique plus puissante. Une architecture saine accepte que certaines questions restent sans réponse complète, ou renvoie l’utilisateur vers la procédure d’accès appropriée.

Il faut également éviter de promettre une propagation universelle dans tous les scénarios. Les capacités de protection dépendent des configurations, des fonctionnalités prises en charge et des applications concernées. Le bon réflexe est de valider, par des tests contrôlés, le comportement de chaque parcours important : recherche d’un document labellisé, synthèse multi-sources, réponse contenant un extrait protégé, puis partage ou export de cette réponse.

Réduire le surpartage avant le déploiement de l’assistant

Le succès technique d’un pilote peut masquer un problème structurel : l’assistant trouve rapidement les documents parce qu’ils sont déjà accessibles trop largement. La guidance Microsoft « Secure & Governed Data Foundation for Microsoft Copilot », mise à jour le 18/08/2026, est explicitement présentée comme un plan pour remédier au surpartage, appliquer des garde-fous et répondre aux exigences de réglementation de l’IA. Elle met l’accent sur l’identification des données surpartagées et l’application de contrôles avant un déploiement large.

Cette priorité doit influencer la feuille de route. L’objectif initial ne devrait pas être de connecter le maximum de contenus, mais d’établir un socle de données fiable. Dans la pratique, cela associe des chantiers de gouvernance qui existent souvent déjà : clarification des propriétaires, nettoyage des permissions, usage discipliné des espaces de partage et définition de politiques de classification.

1. Délimiter un cas d’usage.

   Par exemple, l’assistance à une équipe support interne ou la recherche de procédures validées, plutôt qu’un assistant généraliste couvrant toute l’entreprise.

2. Évaluer l’exposition documentaire.

   Examiner les espaces inclus, les audiences larges et les contenus à forte sensibilité susceptibles d’être découverts.

3. Corriger avant d’augmenter la visibilité.

   Ajuster les accès, déplacer les documents ou appliquer les protections nécessaires avant l’ouverture au pilote.

4. Configurer les garde-fous.

   Associer les exigences de conformité, les labels, la rétention et les politiques de sécurité aux parcours retenus.

5. Tester avec de vraies identités métier.

   Vérifier non seulement ce qu’un utilisateur autorisé peut obtenir, mais aussi ce qu’un utilisateur non autorisé ne doit jamais voir.

6. Étendre par paliers.

   Ajouter sources, équipes et fonctions après analyse des résultats, des retours et des événements de sécurité.

Cette démarche peut sembler plus lente qu’un déploiement massif, mais elle réduit les reprises coûteuses. Elle donne aussi aux métiers une occasion de réviser leurs contenus : une procédure obsolète, même parfaitement protégée, reste une mauvaise source de grounding. La qualité de la connaissance, son actualisation et sa propriété éditoriale font partie de la sécurité fonctionnelle d’un assistant.

Traiter l’injection de prompt comme un risque de la chaîne complète

Les attaques par injection de prompt ne concernent pas uniquement la boîte de dialogue. Une instruction malveillante peut être saisie par l’utilisateur, mais aussi être contenue dans une page, un ticket, une note ou un document récupéré par le système. Si l’assistant traite cette instruction comme une consigne prioritaire, elle peut tenter de détourner la recherche, de pousser à divulguer des informations ou d’influencer un outil connecté.

Microsoft identifie les injections de prompt parmi les risques spécifiques à l’IA que ses protections de données d’entreprise cherchent à prendre en compte. Pour les architectes, le message est simple : il faut protéger à la fois la couche de prompt et la couche de retrieval. Les documents récupérés sont des données de référence, pas des autorités capables de modifier les règles de l’assistant.

Mesures d’architecture et d’exploitation

• Séparer les instructions système des contenus récupérés.

  Le contexte documentaire doit être clairement délimité afin que les textes sources ne soient pas interprétés comme des consignes de contrôle.

• Limiter les capacités de l’agent.

  Un assistant qui peut rechercher n’a pas nécessairement besoin d’envoyer des messages, de modifier des droits ou d’exécuter des actions sur un système tiers.

• Exiger une validation pour les actions à impact.

  Une proposition générée ne doit pas devenir une action irréversible sans confirmation adaptée au risque.

• Réduire le contexte au strict utile.

  Moins de contenu non pertinent est injecté dans la requête, moins la surface d’influence est large.

• Tester des scénarios adverses.

  Les essais doivent inclure des documents contenant des instructions trompeuses et des utilisateurs tentant d’obtenir un élargissement de périmètre.

Aucune mesure isolée ne rend un système invulnérable. Les défenses sont plus solides lorsqu’elles combinent la récupération fondée sur les droits, le cloisonnement des instructions, des actions à privilèges minimaux et une supervision active. Ce point justifie que la conception soit portée conjointement par les équipes IA, sécurité, identité, conformité et propriétaires de contenus.

Rendre les réponses auditables et exploitables par la conformité

Pour un assistant interne, la question à poser après « la réponse est-elle pertinente ? » est « pouvons-nous comprendre comment elle a été produite ? ». Les équipes doivent pouvoir investiguer un signalement, vérifier la portée d’un usage, appliquer une conservation lorsque cela est requis et démontrer que les contrôles prévus fonctionnent dans la durée.

Microsoft indique que les données d’interaction Copilot peuvent être découvertes, auditées et conservées via Microsoft Purview, y compris les enregistrements de prompts, de réponses et de contenus référencés. Microsoft Purview propose aussi des contrôles de sécurité et de conformité pour Microsoft 365 Copilot et d’autres applications d’IA générative, avec notamment des capacités liées à la gestion des risques internes et à la posture de sécurité des données pour l’IA.

L’audit ne doit toutefois pas devenir une collecte indifférenciée. Les journaux eux-mêmes peuvent contenir des demandes sensibles, des extraits de documents ou des éléments de contexte. Le projet doit déterminer qui accède aux traces, pour quelles finalités, selon quelles politiques de conservation, et comment les personnes concernées sont informées dans le cadre applicable à l’organisation.

Un tableau de bord de projet utile suit d’abord des signaux actionnables : sources les plus interrogées, erreurs d’accès récurrentes, réponses signalées, requêtes sans résultat, tentatives d’action refusées et évolution du périmètre connecté. Ces éléments permettent d’améliorer l’expérience sans sacrifier les contrôles. Ils aident aussi à distinguer une difficulté de pertinence d’un problème de droits, de qualité documentaire ou de gouvernance.

Mettre en production une architecture hybride avec un pilotage réaliste

Microsoft indique que Microsoft 365 Copilot opère dans la frontière de service Microsoft 365 et respecte les mêmes capacités de protection des données, de contrôle d’accès et de conformité que Microsoft 365. Sa documentation de confidentialité et de sécurité le positionne également dans le cadre des engagements commerciaux de Microsoft 365, notamment en matière de RGPD et de limite de données de l’Union européenne. Ces garanties de plateforme sont importantes, mais elles ne remplacent pas les décisions propres à chaque tenant : permissions, contenus connectés, politiques de Purview et configuration des usages.

De même, l’usage de modèles de fondation fournis par OpenAI dans Copilot pour Microsoft 365 ne signifie pas que les données client servent à entraîner ces modèles dans ce contexte de service : Microsoft indique que les données client ne sont pas utilisées à cette fin. Cette clarification répond à une inquiétude fréquente, mais elle ne dispense pas de gouverner les données envoyées au service ni de vérifier les options effectives du déploiement retenu.

Les responsabilités à clarifier dès le lancement

• Direction métier :

  priorise les cas d’usage, désigne les propriétaires de connaissance et définit ce qu’est une réponse utile.

• Équipe identité et sécurité :

  contrôle l’authentification, les permissions, le moindre privilège et les scénarios de test d’accès.

• Conformité et protection des données :

  encadre les labels, la rétention, l’audit et les obligations applicables.

• Équipe plateforme ou produit :

  conçoit l’orchestration, les connecteurs, l’expérience utilisateur, les limites fonctionnelles et l’observabilité.

• Propriétaires de référentiels :

  garantissent la qualité, la mise à jour et le bon classement des sources exposées.

Un pilote bien conçu doit accepter les retours négatifs. Une réponse refusée par les droits, un contenu absent parce qu’il est chiffré ou une source exclue du périmètre peuvent être des résultats corrects. L’enjeu est d’expliquer ce comportement de manière utile, sans révéler l’existence d’informations que l’utilisateur n’est pas autorisé à connaître. L’expérience utilisateur doit rendre la sécurité compréhensible plutôt que silencieuse et mystérieuse.

La meilleure trajectoire est souvent progressive : commencer par une population et des sources maîtrisées, valider le retrieval sécurisé, mesurer la valeur métier, corriger le surpartage puis élargir. L’assistant gagne ainsi en utilité en même temps que l’organisation améliore sa gouvernance documentaire. Ce cycle est plus durable qu’une promesse de recherche universelle dès le premier jour.

Sécuriser les flux de connaissances ne revient pas à ajouter un filtre devant un modèle de langage. Cela demande une chaîne cohérente : identité fiable, récupération filtrée par les droits, connecteurs gouvernés, protections de l’information, défenses contre l’injection, journalisation et amélioration continue. Le modèle d’index hybride offre une voie concrète pour exploiter les connaissances Microsoft 365 et externes sans multiplier inutilement les copies et les surfaces de contrôle.

Pour cadrer un projet, commencez par cartographier les sources et leurs propriétaires, vérifiez le surpartage, puis pilotez un cas d’usage à valeur claire avec des identités métier réelles. Une architecture d’assistant interne est solide lorsqu’elle sait répondre avec contexte aux bonnes personnes, refuser proprement les accès non autorisés et laisser des preuves suffisantes pour être exploitée avec confiance.