M365 Copilot & Agents

Copilot lit ce que tu as le droit de lire. Pas toujours une bonne idée.

Ce que Copilot et les agents trouvent dans ton tenant n'est pas écrit dans la documentation Microsoft. C'est écrit dans tes permissions. Nous faisons en sorte que les deux soient en règle.

Se faire conseiller

Réserver via Azure Marketplace

Déployer M365 Copilot et les agents en toute sécurité : configuration, oversharing et la bonne architecture

Avant Copilot, l'oversharing n'avait pas de conséquences tangibles, parce que personne n'avait le temps de parcourir tous les documents d'une entreprise moyenne. Copilot a ce temps. Il lui faut quelques secondes, et il ne cherche pas les problèmes, il les trouve tout simplement, parce qu'il accède à tout ce que l'utilisateur concerné a le droit de lire via Microsoft Graph, et dans la plupart des tenants, un collaborateur moyen peut statistiquement lire environ 130 000 fichiers qui ne lui étaient jamais destinés. Le premier effet d'un rollout de Copilot n'est donc le plus souvent pas un gain de productivité, mais une transparence involontaire.

Ce n'est pas un argument contre Copilot. C'est un argument pour l'ordre des choses. Les permissions, les sensitivity labels, les politiques DLP, la configuration du Copilot Control System et la question des admin centers à examiner avant le premier rollout : ces devoirs existaient avant Copilot comme après, mais l'occasion de s'y attaquer systématiquement n'a jamais été aussi concrète qu'aujourd'hui. En ce sens, Copilot n'est pas un problème, c'est une occasion de mettre le tenant dans l'état où il aurait toujours dû être.

16 %

de l'ensemble des données d'entreprise sont statistiquement dotées de permissions excessives (Microsoft)

130 000

fichiers auxquels les collaborateurs ont accès en moyenne alors qu'ils ne leur étaient jamais destinés

70 %

des collaborateurs ont transmis des données critiques pour l'entreprise à des IA non autorisées (Microsoft)

23 %

ne savent même pas si leur entreprise propose des outils d'IA (Microsoft)

Ce qu'est Copilot, ce qu'est un agent et pourquoi la différence compte

La distinction que Microsoft établit entre Copilot et les agents est techniquement précise, mais souvent floue dans la communication, ce qui conduit les entreprises soit à en attendre trop, soit à commencer par le mauvais bout. La ligne de partage la plus simple passe par la question de l'autonomie.

M365 Copilot et Copilot Chat sont des assistants interactifs qui répondent aux questions, résument des contenus et rédigent des ébauches de texte, toujours sur la base de ce que l'utilisateur a le droit de lire via Microsoft Graph. Ils n'agissent pas, ils assistent. Les Declarative Agents, c'est-à-dire les agents SharePoint ou les agents issus de l'Agent Builder, étendent cette approche à un périmètre de connaissances restreint et prédéfini, mais ne prennent pas de décisions autonomes et n'exécutent pas d'actions système.

Les agents ne deviennent réellement autonomes qu'en tant que Custom Engine Agents, construits dans Copilot Studio, Power Platform ou Azure AI Foundry : ils peuvent être déclenchés par des événements, communiquent avec des services externes et exécutent des actions sans qu'un humain doive valider chaque étape. Sans cette distinction, on construit soit des agents pour des tâches qu'un simple prompt Copilot accomplit tout aussi bien, soit on attend d'un Declarative Agent une autonomie que l'architecture ne prévoit pas.

Copilot et les agents présupposent une plateforme conçue pour cela

Copilot accède via Microsoft Graph aux données que l'utilisateur est autorisé à lire, et les agents opèrent dans les limites système définies par leur plateforme. Si ces limites n'ont jamais été posées explicitement, parce que le tenant a grandi au fil des années sans jamais avoir été conçu pour un accès par l'IA, Copilot et les agents fonctionnent certes sur le plan technique, mais dans un environnement optimisé ni pour la performance ni pour la gouvernance.

Notre Cloud Workplace Foundation pose la base M365 dont Copilot a besoin : structure des autorisations, Sensitivity Labels, DLP, règles de gouvernance, non pas ajoutées après coup, mais intégrées dès le départ. La même logique vaut pour les agents qui opèrent dans Azure : l'Azure Foundation et l'Azure Container Foundation garantissent que le terrain est solide avant de construire. Déployer des agents dans un environnement qui n'a pas cette base, c'est construire sur du sable.