Un agent Copilot ne vaut que ce que votre
socle de données IA agentique lui permet
de voir. C’est la réalité que beaucoup de DSI découvrent
après le déploiement — et pas avant. En effet, un agent
connecté à un tenant Microsoft 365 mal gouverné ne produit
pas de mauvaises réponses parce qu’il est mal conçu.
Il en produit parce que les données qu’il indexe sont
désorganisées, sur-partagées ou mal classifiées.
Ainsi, avant de construire vos agents Copilot Studio,
avant d’activer la licence E7 et avant de promettre
un ROI à votre COMEX, une question s’impose :
votre architecture données Copilot
est-elle réellement prête ? Nos experts en Sécurité Cloud & Gouvernance M365
accompagnent les DSI sur ce diagnostic.
Socle de données IA agentique :
pourquoi l’architecture SI est le vrai sujet
La promesse des agents IA est séduisante.
Un agent peut résumer des documents, répondre
à des questions métiers, déclencher des workflows
et interagir avec des systèmes externes.
Toutefois, derrière cette promesse se cache
une réalité technique : un agent Copilot
accède aux données via Microsoft Graph.
Il remonte exactement ce que l’utilisateur
qui l’interroge est autorisé à voir —
ni plus, ni moins.
Or, dans la majorité des tenants Microsoft 365,
les droits d’accès SharePoint sont trop larges.
Des sites créés il y a cinq ans sont encore
accessibles à « Tout le monde ». Des bibliothèques
de documents sensibles héritent de permissions
de sites ouverts. Par conséquent, un agent Copilot
déployé sur ce tenant ne divulgue pas des données
confidentielles parce qu’il est mal configuré.
Il le fait parce que votre architecture de données
le lui permet.
Un document mal partagé autrefois invisible,
aujourd’hui instantanément accessible
Avant Copilot, un document sensible mal rangé
dans un site SharePoint ouvert passait souvent
inaperçu. Personne ne le cherchait activement.
En revanche, un agent Copilot basé sur Microsoft Graph
le trouve immédiatement — et l’incorpore dans
ses réponses si la requête de l’utilisateur
le justifie. Ce qui était
invisible car personne ne le cherchait activement
devient instantanément accessible dès que Copilot
peut l’indexer sémantiquement.
C’est une rupture fondamentale dans le modèle
de risque du SI.
Microsoft Graph : la couche d’accès
que tout DSI doit comprendre
Microsoft Graph est la couche API centrale
de Microsoft 365. C’est elle qui connecte
Copilot à vos données : emails, calendriers,
fichiers SharePoint, conversations Teams,
profils utilisateurs. Concrètement, quand
un agent Copilot cherche une information,
il interroge Microsoft Graph. Graph lui retourne
les données auxquelles l’utilisateur a accès.
Le principe d’héritage de permissions
Quand un utilisateur
interagit avec un agent, il accède aux sites,
pages et documents inclus dans les sources
de l’agent auxquels il a déjà des permissions.
Si l’utilisateur n’a pas accès à un contenu
spécifique, même si ce contenu est inclus
dans les sources de l’agent, il ne verra pas
cette information dans sa conversation.
Ce principe est protecteur — mais il ne corrige
pas les mauvaises configurations existantes.
En d’autres termes, si vos permissions sont
trop larges, l’agent restitue tout ce qu’il
peut voir légitimement.
Graph comme amplificateur du bien et du mal
Graph est neutre. Il amplifie ce que votre
gouvernance des données a construit. Un tenant
bien structuré — droits affinés, métadonnées
cohérentes, sources authoritative identifiées
— produit des agents pertinents et précis.
Un tenant désorganisé produit des agents
qui hallucinent, sur-partagent ou répondent
avec des informations obsolètes.
Par conséquent, l’architecture données
Copilot n’est pas un prérequis
secondaire. C’est le facteur déterminant
de la qualité de vos agents.
Sensitivity Labels Purview Copilot :
le mécanisme de contrôle que vous devez activer
Les Sensitivity Labels sont le premier mécanisme
de contrôle natif entre Purview et Copilot.
Leur rôle est précis : Copilot
travaille avec les Sensitivity Labels et le chiffrement
Microsoft Purview pour appliquer les contrôles d’accès
et les paramètres de protection pendant le grounding
et la génération de contenu. En d’autres
termes, un label bien configuré décide ce que
Copilot peut ou ne peut pas restituer.
Comment les Sensitivity Labels agissent sur les agents
Quand un document porte un Sensitivity Label
« Confidentiel » avec un droit EXTRACT restreint,
Copilot ne peut pas en extraire le contenu.
Purview applique les labels
avec les droits d’utilisation EXTRACT — si un document
est labellisé Confidentiel sans permission EXTRACT,
la tentative de l’agent est bloquée et un événement
d’audit est enregistré avec le contexte complet.
C’est donc un mécanisme de protection qui s’applique
en temps réel, indépendamment des permissions SharePoint.
Le risque quand les labels ne sont pas déployés
Quand les Sensitivity Labels
ne sont pas activés pour SharePoint et OneDrive,
les fichiers chiffrés auxquels Copilot et les agents
peuvent accéder se limitent aux données en cours
d’utilisation depuis les applications Office
sur Windows. Autrement dit, sans labels,
vous perdez la couche de contrôle la plus fine
sur ce que vos agents peuvent restituer.
C’est pourquoi le déploiement des
Sensitivity Labels Purview Copilot
doit précéder toute activation d’agents en production.
Purview DLP for Copilot :
bloquer en temps réel dans les prompts
Microsoft Purview DLP for Copilot est une capacité
qui change la donne pour les DSI. Elle
empêche Copilot de répondre à des prompts contenant
des données sensibles, de se connecter à des sources
de données internes ou d’effectuer des recherches web
si le prompt d’un utilisateur contient des données
sensibles. Cette protection s’applique
à Copilot Chat, Microsoft 365 Copilot et aux agents
construits dans Copilot Studio.
Ce que Purview DLP intercepte concrètement
Purview DLP peut détecter en temps réel un numéro
de carte bancaire tapé dans un prompt, un IBAN,
un numéro de sécurité sociale ou tout type
d’information sensible défini dans vos politiques.
En conséquence, même si l’utilisateur envoie
involontairement une donnée personnelle dans
son prompt, Copilot est bloqué avant de traiter
la requête. C’est la première fois que le DLP
s’applique au contenu des prompts — et pas
seulement aux emails et aux fichiers.
Purview Adaptive DLP : gouverner à l’échelle
Purview Adaptive DLP
pour SharePoint permet désormais de créer des politiques
adaptatives qui évaluent en continu les attributs
des sites SharePoint — noms, métadonnées, labels —
et incluent ou excluent automatiquement des sites
du périmètre de Copilot. Ainsi, vous n’avez
plus à gérer des listes statiques de sites exclus.
La gouvernance devient dynamique et s’adapte
à mesure que votre tenant évolue. Pour les
projets Microsoft 365 à grande échelle,
c’est un changement de paradigme opérationnel.
Les données ROT : le risque silencieux
que Copilot va révéler
Le terme ROT désigne les données Redondantes,
Obsolètes et Triviales. Dans la majorité des tenants
Microsoft 365, ces données représentent entre 30
et 60 % du contenu SharePoint. Ce sont des procédures
de 2018, des présentations d’anciens projets,
des fichiers en double stockés dans plusieurs
bibliothèques. Avant Copilot, elles étaient
simplement inactives. Après Copilot, elles deviennent
actives — et dangereuses.
Quand Copilot répond avec des données obsolètes
Un agent Copilot qui se base sur une procédure RH
de 2018 pour répondre à une question de 2026
va produire une erreur — parfois qualifiée
d' »hallucination », alors qu’il s’agit en réalité
d’une réponse fidèle à une source obsolète.
En d’autres termes, la qualité des réponses
de vos agents est directement proportionnelle
à la qualité du contenu qu’ils indexent.
Par conséquent, le nettoyage des données ROT
n’est plus un chantier optionnel.
C’est un prérequis au socle de données
IA agentique.
Comment identifier et traiter les données ROT
SharePoint Advanced Management permet d’identifier
les sites inactifs, les fichiers non consultés
depuis plus de 12 mois et les bibliothèques
avec des partages excessifs. Purview Content
Explorer donne une vue complète de la distribution
des données par label et par localisation.
Ces deux outils forment le kit de base
d’un audit de contenu avant déploiement Copilot.
Notre équipe vous accompagne dans cette démarche
via notre offre
gouvernance M365.
Architecture données Copilot :
les cinq prérequis non négociables
Un socle de données IA agentique
solide repose sur cinq piliers techniques.
Voici comment les aborder dans l’ordre logique
avant tout déploiement d’agents en production.
Prérequis 1 — Audit des droits d’accès SharePoint
Cartographiez vos sites SharePoint par niveau
d’exposition. Identifiez les sites accessibles
à « Tout le monde », les liens de partage anonymes
actifs et les groupes obsolètes avec des membres
inactifs. SharePoint Advanced
Management identifie les sites sur-partagés ou inactifs.
Les contrôles au niveau du site remplacent
les permissions larges tout en préservant
la collaboration. Cet audit est le point
de départ absolu.
Prérequis 2 — Déploiement des Sensitivity Labels
Définissez votre taxonomie de labels en partant
des données les plus sensibles : données personnelles,
données financières, données stratégiques, données
publiques. Déployez les labels sur SharePoint,
OneDrive et Exchange. Activez le labellisage
automatique pour les types de données identifiables
par Purview. Sans cette étape, Purview DLP
ne peut pas distinguer ce que Copilot peut
ou ne peut pas restituer.
Prérequis 3 — Nettoyage des données ROT
Définissez un seuil de rétention opérationnel
par type de contenu. Archivez ou supprimez
les données au-delà de ce seuil. Mettez en place
des politiques de rétention Purview pour automatiser
ce cycle dans le temps. En effet, le nettoyage
ponctuel ne suffit pas — il faut un processus
continu pour que le socle reste propre
à mesure que vos agents évoluent.
Prérequis 4 — Identification des sources authoritative
Tous les contenus de votre tenant ne doivent pas
alimenter vos agents de la même manière.
Identifiez les sources authoritative par domaine :
quelle bibliothèque SharePoint contient les procédures
RH officielles ? Quelle liste contient le catalogue
produit à jour ? Ces sources doivent être désignées
explicitement dans la configuration de vos agents
Copilot Studio. Ainsi, l’agent répond depuis
les bonnes sources plutôt que depuis l’ensemble
du tenant.
Prérequis 5 — Activation de l’audit Purview
sur les interactions agents
Quand un agent accède
à des fichiers SharePoint, lit des emails ou interroge
des données structurées, Purview capture des événements
d’audit détaillés incluant l’identité de l’agent,
le contexte utilisateur, les labels de classification
des données et les résultats d’application des politiques.
Ces événements sont accessibles via le portail
de conformité, Microsoft Graph et les intégrations SIEM.
Activer cet audit est non négociable pour
la conformité AI Act et pour votre capacité
à répondre à un incident.
Ce que l’architecture SI conditionne réellement
La question que les DSI posent souvent est :
« Nos agents Copilot sont-ils bien configurés ? »
Ce n’est pas la bonne question. La bonne question
est : « Notre SI est-il organisé de manière à ce
que nos agents produisent des réponses pertinentes
et sécurisées ? » La nuance est fondamentale.
Pertinence et sécurité sont les deux faces
d’une même architecture
Un agent pertinent répond juste parce qu’il
accède à des sources authoritative, récentes
et bien structurées. Un agent sécurisé répond
dans le périmètre autorisé parce que les droits
sont affinés, les labels déployés et les politiques
DLP actives. Or, ces deux objectifs reposent
exactement sur les mêmes fondations techniques.
Par conséquent, investir dans le socle de données
n’est pas un coût de mise en conformité.
C’est un investissement en qualité d’IA.
Ce que votre COMEX va vous demander
Quand votre COMEX demande un ROI sur les agents
Copilot, il ne questionne pas la technologie.
Il questionne la fiabilité des réponses produites
et la sécurité des données traitées.
Vous ne pouvez répondre à ces deux questions
qu’avec un socle de données IA agentique
documenté et auditable. Sans ce socle, vos agents
produisent des réponses que personne ne peut
garantir — et que personne ne peut défendre
en cas d’incident. Nos équipes peuvent vous
accompagner sur ce chantier dans le cadre
de notre offre
conduite du changement et de nos projets
de gouvernance M365.
Conclusion — Architecture données Copilot :
le socle avant les agents
Déployer des agents Copilot sans
architecture données Copilot
solide, c’est construire sur du sable.
Les agents vont fonctionner — mais ils vont
produire des réponses approximatives, exposer
des données qui ne devraient pas l’être
et générer des incidents que personne n’avait
anticipés. Tout cela se corrige. Mais le coût
de la correction est toujours supérieur
au coût de la prévention.
En conséquence, le bon ordre est simple :
d’abord le socle, ensuite les agents.
