Architecture Copilot M365 : Fonctionnement Technique & Flux de Données (2026)

Pour un utilisateur final, Microsoft Copilot tient de la magie : une question posée dans Teams, une réponse instantanée.

Mais pour un DSI ou un RSSI responsable de la souveraineté des données, la "magie" n'est pas une explication acceptable. C'est même une source d'angoisse.

Vous avez besoin de comprendre le flux exact des données. Où transitent-elles ? Comment le modèle accède-t-il à vos fichiers sans les exposer publiquement ? Qu'est-ce que le "Grounding" dont parle Microsoft ?

Cet article technique décortique l'architecture sous-jacente de Copilot.

Note : Si vous cherchez plutôt une vision globale des enjeux business, des coûts et des cas d'usage métiers, commencez par consulter notre Guide complet Copilot pour les entreprises. Ici, nous allons ouvrir le capot et mettre les mains dans le moteur.

Au programme de cet article :

• L'architecture Copilot : bien plus qu'un simple LLM
• Le workflow technique : traitement d'un prompt étape par étape
• Résidence des données et "Trust Boundary"
• La talon d'Achille de vos architectures : les permissions
• Limites techniques à connaître pour les architectes (2026)

L'architecture Copilot : bien plus qu'un simple LLM

L'erreur commune est de penser que Copilot connecte simplement Word ou Excel à un modèle de langage. C'est techniquement faux. Si c'était le cas, l'IA hallucinerait constamment sur vos données internes qu'elle ne connaît pas.

L'architecture repose sur un moteur d'orchestration interne qui coordonne trois composants distincts :

Le Frontend (Apps M365) : l'interface utilisateur dans Word, Teams, Outlook, PowerPoint. Le Contexte (Microsoft Graph et Semantic Index) : vos données d'entreprise (emails, fichiers, réunions, chats) accessibles via API. L'Intelligence (le LLM) : un grand modèle de langage hébergé sur le service Azure OpenAI, isolé de l'Internet public. La version exacte du modèle évolue régulièrement selon les mises à jour Microsoft et n'est pas rendue publique.

Le concept clé à retenir : le LLM n'a jamais accès direct et complet à votre base de données. Il ne "voit" que les micro-fragments d'information que l'orchestrateur décide de lui envoyer pour une requête précise.

Le workflow technique : traitement d'un prompt étape par étape

Pour valider la sécurité de l'outil, suivons le cheminement exact d'une requête utilisateur à la milliseconde près.

Etape 1 : réception et pré-traitement (Grounding)

L'utilisateur tape dans Teams : "Synthétise le projet Alpha basé sur les mails de la semaine dernière."

Copilot n'envoie pas cette phrase directement au LLM. Ce serait inutile, car le modèle ne sait pas ce qu'est le "Projet Alpha".

L'orchestrateur intercepte la requête pour la contextualiser. C'est l'étape cruciale de Grounding (Ancrage). L'objectif est de transformer une question vague en une requête précise et documentée.

Etape 2 : interrogation du Graph (RAG Pattern)

L'orchestrateur utilise une technique appelée RAG (Retrieval Augmented Generation). Il interroge le Microsoft Graph pour trouver les données pertinentes.

C'est ici que se joue la sécurité de votre entreprise.

Point critique : le Security Trimming

Lors de cette requête au Graph, Microsoft applique le Security Trimming en temps réel. L'API Graph agit avec l'identité de l'utilisateur (on-behalf-of). Elle ne retourne que les documents pour lesquels l'utilisateur possède des permissions valides dans le tenant.

Si l'utilisateur n'a pas les permissions SharePoint/OneDrive appropriées sur ce contenu, Microsoft Graph applique le Security Trimming et ne retourne aucun résultat. Copilot répondra : "Je n'ai pas trouvé d'informations sur ce projet."

A noter : Copilot respecte également les politiques de Conditional Access et le MFA configurés dans votre tenant. L'accès aux données est toujours limité aux permissions de l'utilisateur connecté au moment de la requête.

Etape 3 : le Semantic Index

L'indexation de M365 repose historiquement sur la correspondance de mots-clés et la personnalisation (social matching via Microsoft Graph). Le Semantic Index, déployé progressivement depuis 2023 pour les licences E3/E5, vient enrichir cette base en ajoutant une couche de compréhension sémantique.

Au lieu de chercher uniquement la chaîne de caractères "Projet Alpha", il crée une carte vectorielle de vos données. Il convertit le texte en vecteurs numériques (embeddings).

Cela lui permet de comprendre les concepts et les relations : si vous cherchez "Projet Alpha", il trouvera aussi les documents parlant de "l'initiative de restructuration Q3" si le contexte sémantique est proche, même sans mot-clé commun.

Le Semantic Index respecte intégralement les droits d'accès configurés dans le tenant : il ne surface un résultat à un utilisateur que si celui-ci y a déjà accès via les contrôles RBAC existants.

Etape 4 : construction du méta-prompt

Une fois les données récupérées, l'orchestrateur construit un méta-prompt. Ce paquet contient :

• La question originale de l'utilisateur.
• Les extraits de données (le "Grounding") récupérés du Graph.
• Les directives de sécurité (System Prompt) incluant les principes Responsible AI de Microsoft : filtrage des contenus, respect de la confidentialité, prévention des hallucinations et des injections de prompt malveillantes.

C'est ce paquet complet qui est envoyé à l'instance LLM sur Azure pour traitement.

Etape 5 : génération et post-traitement (Safety)

Le LLM génère une réponse en langage naturel.

Avant affichage, la réponse passe par des filtres de sécurité intégrés vérifiant les injections de prompt, les contenus haineux ou biaisés, et la conformité aux règles de propriété intellectuelle.

Enfin, la réponse apparaît dans l'application. Tout ce cycle dure quelques secondes.

Résidence des données et "Trust Boundary"

C'est la question n°1 des RSSI : "Mes données partent-elles aux US ? Servent-elles à entraîner les modèles ?"

Le Data Boundary de l'UE

Pour les tenants basés en Union Européenne, Microsoft applique le EU Data Boundary. Le traitement se fait sur des instances Azure situées en Europe. Le trafic ne transite pas par l'Internet public mais reste dans le backbone mondial de Microsoft.

Ce périmètre comporte toutefois des exceptions documentées pour certains sous-services. Le EU Data Boundary n'est pas une garantie absolue et uniforme sur l'ensemble des composants.

Isolation contractuelle (Stateless)

Contrairement à la version grand public de ChatGPT, M365 Copilot est "stateless" concernant vos données :

Pas d'entraînement sur vos données : conformément au Data Protection Addendum de Microsoft, les données client ne sont pas utilisées pour entraîner les modèles de fondation. Votre propriété intellectuelle ne bénéficiera pas à vos concurrents.

Ephémère : une fois la session terminée, le contexte est purgé des systèmes de traitement, sans persistance dans les modèles.

Le talon d'Achille de l'architecture : vos permissions

L'architecture technique est robuste. Le chiffrement est solide. L'isolation est réelle.

Pourtant, Copilot reste un risque majeur. Pourquoi ?

Parce que l'architecture repose sur une hypothèse dangereuse : le système suppose que les permissions configurées dans votre environnement sont légitimes.

Comme nous l'avons vu à l'étape 2, le Security Trimming se fie à vos ACL (Access Control Lists). L'architecture technique est incapable de distinguer :

• Un accès techniquement valide : Michel est dans le groupe "Tout le monde" qui a accès aux RH.
• D'un accès métier légitime : Michel n'est pas RH, il ne devrait pas voir ce dossier.

C'est l'effet amplificateur : l'outil fonctionne parfaitement techniquement, mais il transforme vos erreurs de configuration passées (groupes publics, liens de partage oubliés, héritages brisés) en vecteur de fuites de données.

Diagnostic : si votre gouvernance M365 est une passoire, Copilot sera une pompe à haute pression branchée à cette passoire.

Si vous souhaitez en savoir plus, découvrez nos 5 conseils pour sécuriser vos accès avec Copilot. Vous pouvez également consulter notre article sur les risques de sécurité Copilot pour une analyse complète des vecteurs d'exposition.

Limites techniques à connaître pour les architectes (2026)

Pour planifier votre déploiement, vous devez connaître les contraintes actuelles du système.

La fenêtre de contexte (Context Window)

Les LLMs modernes gèrent des contextes étendus, mais l'orchestrateur Copilot limite le volume de données injecté dans le prompt pour garantir une faible latence. Il ne lira pas l'intégralité de vos 5 000 fichiers SharePoint pour une seule question. Il priorise les documents les plus récents et les plus consultés.

La fraîcheur du Semantic Index

L'indexation n'est pas toujours instantanée. Un fichier créé ou modifié récemment peut ne pas apparaître immédiatement dans une requête complexe nécessitant une vectorisation.

Extensibilité et connecteurs

Copilot ne voit par défaut que M365. Pour interroger Salesforce, Jira ou un SQL on-premise, vous devez configurer des Graph Connectors. Ces données externes sont alors indexées via Microsoft Search et rendues accessibles au grounding, selon les permissions mappées depuis la source externe.

Attention : vous devez mapper scrupuleusement les permissions de la source externe vers les utilisateurs M365, sinon vous créez une brèche de sécurité. Une gouvernance des droits d'accès sur M365 est un prérequis indispensable, comme l'illustre notre guide sur la revue des droits d'accès M365.

FAQ Technique (DSI/RSSI)

Copilot garde-t-il un cache des réponses ?

Non. Les réponses ne sont pas mises en cache pour d'autres utilisateurs. Chaque interaction est unique et régénérée pour garantir le respect des droits d'accès à l'instant T.

Peut-on auditer ce que Copilot a "lu" pour générer une réponse ?

Partiellement. Les interactions sont journalisées dans Microsoft Purview Audit sous le type d'enregistrement CopilotInteraction. Ces logs permettent de savoir quand un utilisateur a interagi avec Copilot, dans quelle application, et quels fichiers ont été référencés (identifiant, URL, label de sensibilité éventuel).

En revanche, le texte des prompts et des réponses n'est pas capturé dans les logs d'audit standards : les logs enregistrent la métadonnée de l'interaction, pas son contenu. Pour accéder au contenu des échanges dans le cadre d'une investigation, il faut recourir aux outils eDiscovery de Microsoft Purview, distincts des logs d'audit.

L'indexation sémantique consomme-t-elle des crédits Azure ?

Non. Le coût de l'indexation et du compute est inclus dans la licence Microsoft 365 Copilot par utilisateur.

Si Copilot génère un document à partir de fichiers classifiés "Confidentiel", le document produit hérite-t-il automatiquement du label ?

Oui, dans le cas général : lorsque Copilot génère du nouveau contenu à partir de sources labellisées, le label de priorité la plus élevée parmi les sources est hérité par le contenu produit, quand cette fonctionnalité est supportée. Les paramètres de protection restent appliqués même si les fichiers sources sont stockés en dehors du tenant Microsoft 365.

La réponse est cependant plus complexe selon le contexte. Pour que Copilot puisse interagir avec un fichier chiffré, l'utilisateur doit disposer des droits d'utilisation EXTRACT et VIEW. Des permissions de label définies par l'utilisateur (user-defined permissions) peuvent bloquer Copilot dans l'extraction et l'interaction avec le contenu : les agents Copilot, par exemple, ne peuvent pas lire les fichiers portant ce type de permissions.

En pratique : l'héritage automatique fonctionne dans le flux standard, mais il dépend du type de label, des droits d'utilisation configurés et de l'application Copilot concernée. Ce mécanisme ne remplace pas une stratégie Microsoft Purview Information Protection correctement configurée en amont. Il en est le complément.

Les politiques DLP s'appliquent-elles aux réponses générées par Copilot ?

Oui. Les politiques DLP (Data Loss Prevention) configurées dans Microsoft Purview s'appliquent à Copilot. Concrètement, une politique DLP peut empêcher Copilot d'utiliser un fichier sensible comme source de grounding, et donc d'en exposer le contenu dans une réponse.

Avec une licence E5 ou un add-on Compliance, il est possible de configurer des règles DLP ciblant explicitement Microsoft 365 Copilot et les agents, pour bloquer le traitement de certains fichiers ou types de données sensibles. Cette protection est conditionnelle au niveau de licence et à la configuration explicite des règles : elle n'est pas active par défaut. La combinaison labels de sensibilité + DLP + revue des droits constitue le socle de gouvernance recommandé avant tout déploiement Copilot à grande échelle. Consultez notre comparatif des licences M365 E3 vs E5 pour évaluer les options disponibles selon votre niveau de licence.

Conclusion : l'architecture de Microsoft 365 Copilot

L'architecture de Microsoft 365 Copilot est une prouesse d'intégration qui respecte strictement vos frontières de données (Data Boundary), à une condition non négociable : que vos fondations (l'annuaire et les permissions) soient saines.

Le flux de données est sécurisé "by design", mais il est aussi transparent qu'une vitre : si vos permissions sont ouvertes, Copilot verra tout et dira tout.

Votre prochaine action technique : maintenant que vous maîtrisez l'architecture, il est temps de vérifier ce que le Graph va réellement servir à vos utilisateurs.