Le Zero Trust est parfois présenté comme une architecture complexe réservée aux spécialistes de la cybersécurité. Son principe de départ est pourtant simple : un accès ne doit jamais être considéré comme légitime une fois pour toutes.
Une identité, un appareil ou une application doit être vérifié en fonction du contexte. Les autorisations doivent répondre à un besoin réel. L’organisation doit aussi pouvoir détecter un comportement inhabituel et limiter les conséquences d’un incident.
Cette approche concernait déjà les utilisateurs, les appareils, les applications et les données. Avec l’arrivée de Microsoft 365 Copilot et des agents capables d’utiliser des outils ou d’exécuter des actions, elle prend une importance nouvelle.
L’intelligence artificielle ne remet pas en cause le Zero Trust. Elle rend son application encore plus indispensable.
Pourquoi le modèle de sécurité traditionnel ne suffit-il plus ?
Pendant longtemps, les entreprises ont surtout cherché à protéger un périmètre : leurs bureaux, leurs serveurs et leur réseau interne. Ce modèle correspond de moins en moins à la façon dont elles fonctionnent aujourd’hui.
Les collaborateurs utilisent plusieurs appareils et accèdent aux ressources depuis différents lieux. Les données circulent entre Microsoft 365, les applications métier, les espaces collaboratifs et les services cloud. Des partenaires ou des prestataires peuvent également avoir besoin d’accéder à certaines informations.
Dans cet environnement, être connecté au système d’information ne suffit plus pour être considéré comme digne de confiance.
Un collaborateur peut changer de fonction tout en conservant les accès liés à son ancien poste. Un appareil peut ne plus respecter les règles de sécurité. Un mot de passe peut être compromis. Une permission accordée pour un projet temporaire peut rester active après sa clôture.
Le Zero Trust part donc d’un constat pragmatique : une identité ou un appareil peut être légitime à un moment donné sans devoir bénéficier d’une confiance permanente.
Chaque demande d’accès doit être examinée selon son contexte :
- qui demande l’accès ;
- depuis quel appareil ;
- à quelle ressource ;
- dans quelles conditions ;
- avec quel niveau de risque ;
- pour effectuer quelle action.
Les trois principes du Zero Trust
Microsoft structure son approche Zero Trust autour de trois principes : vérifier explicitement, appliquer le moindre privilège et considérer qu’un incident peut se produire afin d’en limiter l’impact.
Vérifier explicitement
Une décision d’accès ne doit pas reposer sur un seul signal. Un mot de passe correct ne suffit pas toujours à démontrer qu’une demande est légitime.
L’organisation peut également prendre en compte l’identité de l’utilisateur, la méthode d’authentification, l’état de l’appareil, l’application utilisée, la ressource demandée et le niveau de risque détecté.
L’objectif n’est pas de multiplier les obstacles pour l’utilisateur. Il s’agit d’adapter le niveau de vérification à la sensibilité de la situation.
Accéder à une information générale et consulter un document confidentiel ne présentent pas le même risque. Les conditions d’accès peuvent donc être différentes.
Accorder uniquement les droits nécessaires
Le principe du moindre privilège consiste à donner à une personne, une application ou un service uniquement les autorisations nécessaires à sa mission.
Prenons un exemple simple. Une collaboratrice participe à un projet et reçoit l’accès à un espace contenant des propositions commerciales, des contrats et des informations sur plusieurs clients. À la fin du projet, elle change de fonction, mais ses permissions ne sont pas réévaluées.
Son compte n’est pas compromis et aucune action malveillante n’est commise. Pourtant, cet accès n’est plus justifié.
L’entreprise doit donc revoir régulièrement ses permissions :
- cet accès est-il toujours nécessaire ?
- correspond-il encore à la fonction de la personne ?
- doit-il être permanent ?
- donne-t-il accès à plus de ressources que nécessaire ?
- doit-il faire l’objet d’une révision périodique ?
Cette réflexion doit également s’appliquer aux agents IA, qui peuvent disposer de leurs propres identités et autorisations.
Limiter les conséquences d’un incident
Adopter le Zero Trust ne signifie pas considérer chaque collaborateur comme une menace. Cela signifie se préparer à la possibilité qu’un compte soit compromis, qu’une erreur survienne ou qu’un contrôle soit contourné.
Si une identité est compromise, jusqu’où une personne malveillante peut-elle aller ? Peut-elle consulter des informations sensibles ou utiliser des droits administratifs ? L’organisation peut-elle détecter rapidement un comportement inhabituel ?
Limiter les permissions, séparer les accès sensibles et surveiller les événements permet de réduire l’impact potentiel d’un incident.
Le Zero Trust ne repose donc pas sur une protection unique censée tout résoudre. Il combine plusieurs contrôles pour vérifier les accès, protéger les données, détecter les anomalies et contenir les incidents.
Utiliser Microsoft 365 signifie-t-il que l’on applique déjà le Zero Trust ?
Microsoft 365 fournit des capacités qui peuvent contribuer à une stratégie de sécurité. Utiliser la plateforme ne signifie toutefois pas que tous les principes du Zero Trust sont automatiquement appliqués.
Plusieurs niveaux doivent être distingués :
- une capacité de sécurité existe ;
- elle est disponible pour l’organisation ;
- elle est configurée selon les besoins identifiés ;
- elle est réellement utilisée et surveillée ;
- son efficacité est réévaluée dans le temps.
Une entreprise peut avoir activé l’authentification multifacteur sans disposer d’une vision claire de ses comptes sensibles. Elle peut protéger efficacement les connexions tout en conservant des partages trop larges sur certains documents.
Elle peut également recevoir des alertes sans avoir défini qui doit les examiner, comment les prioriser et quelles actions engager.
La question ne peut donc pas se limiter à :
Quelles solutions avons-nous achetées ?
Elle doit aussi devenir :
Savons-nous comment nos identités, nos accès, nos appareils et nos données sont réellement protégés ?
Cette nuance ne remet pas Microsoft 365 en question. Elle distingue la présence de capacités de sécurité de leur application réelle dans l’organisation.
Le Zero Trust n’est pas un produit supplémentaire à installer. C’est une manière d’organiser les décisions de sécurité et de vérifier que les accès restent cohérents avec les besoins réels de l’entreprise.
Le Zero Trust n’est pas uniquement un sujet informatique
Les outils techniques sont indispensables, mais ils ne peuvent pas décider seuls :
- quelles informations sont les plus importantes ;
- quels collaborateurs doivent y accéder ;
- quels usages présentent un risque acceptable ;
- qui est responsable d’un espace documentaire ;
- pendant combien de temps un accès doit être conservé ;
- quelles actions doivent être validées par une personne ;
- quels usages de l’intelligence artificielle peuvent être autorisés.
Ces décisions nécessitent une collaboration entre la direction, les métiers, l’IT et les responsables de la sécurité.
La sécurité ne sert pas uniquement à empêcher une attaque. Elle crée aussi les conditions nécessaires pour collaborer, ouvrir de nouveaux services et adopter l’intelligence artificielle avec davantage de maîtrise.
Pour une direction, l’enjeu consiste à relier les investissements de sécurité à des besoins concrets : protéger les informations importantes, maintenir la continuité de l’activité et permettre de nouveaux usages avec un niveau de risque acceptable.
Protéger les accès ne suffit pas : il faut comprendre les données
Une fois connecté, un utilisateur peut consulter les ressources auxquelles ses permissions lui donnent accès.
Or ces permissions ne reflètent pas toujours la situation actuelle. Elles peuvent provenir d’un ancien projet, d’un changement de fonction, d’une équipe créée plusieurs années auparavant, d’un partage externe jamais réévalué ou d’un groupe donnant accès à un périmètre trop large. Il arrive aussi que le propriétaire d’un espace collaboratif ne soit plus clairement identifié.
Le risque ne vient donc pas nécessairement d’une attaque sophistiquée. Une information confidentielle peut simplement se trouver dans un emplacement accessible à trop de personnes.
La documentation Microsoft consacrée à l’application du Zero Trust à Copilot présente plusieurs couches complémentaires : protection des données, identités et accès, applications, appareils, protection contre les menaces, collaboration sécurisée et permissions minimales sur les données.
Cette approche rappelle une règle importante : la sécurité d’un environnement ne dépend jamais d’un seul contrôle.
Pourquoi l’IA rend-elle cette démarche plus urgente ?
L’intelligence artificielle n’invente pas nécessairement les permissions qu’elle utilise. Elle s’appuie sur les identités, les applications, les données et les autorisations déjà présentes dans l’environnement.
En revanche, elle peut rendre les informations plus faciles à rechercher, à regrouper et à résumer. Une permission trop large, auparavant peu visible, peut ainsi prendre une nouvelle importance lorsque l’IA facilite l’accès aux contenus concernés.
Dans ses publications consacrées à l’IA générative, Seyfallah Tagrerout met notamment en avant les enjeux liés au partage excessif dans Microsoft 365 Copilot, à l’identité des agents et aux sources de connaissances utilisées par les systèmes d’IA.
Les protections existantes ne deviennent pas inutiles avec l’IA. Elles doivent cependant couvrir un périmètre plus large :
- les données qu’un assistant peut consulter ;
- les sources qu’il peut utiliser ;
- les contenus externes qu’il traite ;
- les outils accessibles à un agent ;
- les actions que cet agent peut exécuter ;
- les décisions qui doivent rester soumises à une validation humaine.
Un assistant uniquement autorisé à préparer une synthèse ne présente pas le même niveau de risque qu’un agent capable d’envoyer un message, de partager un document ou de modifier une information.
La question ne doit donc pas être uniquement :
L’IA est-elle capable de réaliser cette action ?
Elle doit aussi devenir :
Cette autorisation est-elle réellement nécessaire, et quel contrôle voulons-nous conserver ?
Microsoft recommande de construire une base de sécurité solide avant d’introduire Copilot. Cette préparation comprend notamment la protection des données, les politiques d’identité et d’accès, la sécurité des applications et des appareils, la protection contre les menaces et la maîtrise des permissions sur les données.
Pour approfondir ces différents points, consultez la documentation Microsoft sur l’application du Zero Trust à Microsoft Copilot (s’ouvre dans un nouvel onglet).
Cela ne signifie pas qu’une entreprise doit atteindre une sécurité parfaite avant d’expérimenter. Elle doit toutefois comprendre ses accès, identifier ses principaux écarts et adapter les contrôles aux usages envisagés.
Par où commencer ?
Le Zero Trust concerne les identités, les appareils, les applications, les données, le cloud et les opérations de sécurité. L’entreprise n’a pourtant pas besoin de tout transformer en même temps.
Elle peut commencer par quatre étapes.
1. Identifier les comptes et les accès sensibles
L’entreprise doit savoir quels comptes disposent de droits importants et comment ils sont protégés.
Il peut s’agir d’administrateurs, mais aussi de comptes techniques, d’identités applicatives ou de collaborateurs ayant accès à des données sensibles.
Il faut ensuite repérer les droits qui ne répondent plus à un besoin actuel : anciens projets, permissions héritées, comptes inutilisés, changements de fonction ou groupes trop larges.
2. Comprendre les données importantes
Toutes les informations ne nécessitent pas le même niveau de protection.
La première étape consiste à localiser les données commerciales, financières, contractuelles, personnelles ou stratégiques. L’organisation doit ensuite comprendre qui peut y accéder, comment elles sont partagées et qui en est responsable.
Cette analyse devient particulièrement importante avant de connecter un assistant ou un agent à des sources internes.
3. Vérifier la capacité de détection et de réaction
Recevoir une alerte ne suffit pas si personne ne sait quoi en faire.
L’organisation doit définir :
- qui examine les alertes ;
- quelles situations sont prioritaires ;
- quelles informations sont disponibles pour enquêter ;
- qui peut suspendre un accès ;
- comment les responsabilités sont réparties en cas d’incident.
Les capacités de protection, de détection et d’investigation proposées par Microsoft Defender et Microsoft Sentinel peuvent contribuer à cette démarche lorsqu’elles sont configurées et exploitées selon les besoins de l’organisation.
4. Construire une trajectoire réaliste
L’évaluation initiale doit servir à hiérarchiser les actions, pas à produire une liste interminable de corrections.
Une entreprise qui ne maîtrise pas encore ses comptes sensibles n’aura pas les mêmes priorités qu’une organisation cherchant à renforcer sa capacité de détection.
De même, une entreprise qui prépare l’adoption de Microsoft 365 Copilot devra porter une attention particulière aux données et aux permissions auxquelles Copilot pourra accéder.
Une évaluation et sécurisation Microsoft 365 menée par MC3 Cloud peut aider à examiner l’environnement existant, à identifier les principaux écarts et à organiser les actions par ordre de priorité.
Huit questions pour évaluer votre point de départ
Avant de lancer un programme plus important, votre organisation peut commencer par répondre à huit questions :
- Savons-nous quels comptes disposent des droits les plus sensibles ?
- Les accès sont-ils révisés lorsqu’une personne change de fonction ou quitte un projet ?
- Les utilisateurs disposent-ils uniquement des droits nécessaires à leur activité ?
- Savons-nous où sont stockées nos informations confidentielles ?
- Comprenons-nous les partages internes et externes appliqués à ces informations ?
- Savons-nous qui doit examiner une alerte et prendre une décision ?
- Les métiers, l’IT et la sécurité connaissent-ils leurs responsabilités respectives ?
- Savons-nous quelles informations seraient accessibles à Copilot ou à un futur agent IA ?
Ne pas disposer de réponses précises ne signifie pas qu’un incident est imminent. Cela indique en revanche qu’un travail de visibilité et de priorisation doit être engagé.
ZeroTrust Days Copilot 2026 dans l’océan Indien
Pour approfondir ces enjeux, MC3 Cloud organise les ZeroTrust Days Copilot 2026 dans deux territoires :
- le mercredi 9 décembre 2026, de 13 h 30 à 17 h, à l’Amphithéâtre SFR au Port, à La Réunion ;
- le jeudi 10 décembre 2026, de 14 h 30 à 18 h, au Hennessy Park Hotel, à Cybercity Trianon, à Maurice.
Seyfallah Tagrerout, Microsoft MVP Security et Microsoft Regional Director, interviendra notamment sur :
- l’évolution du Zero Trust face à l’intelligence artificielle ;
- les risques propres à l’IA générative ;
- la protection des données sensibles ;
- les identités et les permissions des agents ;
- le rôle de Microsoft Entra ID ;
- les approches permettant de passer des principes à la mise en œuvre.
La participation est gratuite, sur inscription et dans la limite des places disponibles.
- Inscrivez-vous aux ZeroTrust Days Copilot 2026 à La Réunion (s’ouvre dans un nouvel onglet)
- Inscrivez-vous aux ZeroTrust Days Copilot 2026 à Maurice (s’ouvre dans un nouvel onglet)
Le 22 décembre 2026, MC3 Cloud organisera une table ronde stratégique sur la sécurité au Labourdonnais Waterfront Hotel à Maurice, également accessible via Microsoft Teams.
Patrick Beeharry (s’ouvre dans un nouvel onglet), Vice President of Strategy & Operations for the Microsoft Security Division, partagera la vision de Microsoft sur la sécurité, l’IA et la gouvernance des données. Cette session non technique s’adresse aux dirigeants, CIO, CISO et décideurs IT. Les places seront limitées afin de privilégier les échanges.
Vous souhaitez participer ? Contactez votre interlocuteur commercial chez MC3 Cloud afin qu’il vous réserve une place.
Dans le prochain article : lorsque l’IA peut agir
Comprendre le Zero Trust permet de poser les fondations. L’arrivée des agents soulève toutefois une question supplémentaire.
Un assistant peut rechercher, résumer ou produire une information. Un agent peut aller plus loin. Selon sa conception et ses autorisations, il peut accéder à des ressources, utiliser des outils et exécuter certaines actions.
Le prochain article de cette série examinera :
- la différence entre un assistant et un agent ;
- ce que l’IA peut voir dans l’environnement ;
- ce qu’un agent peut être autorisé à faire ;
- les risques liés aux permissions et aux sources de connaissances ;
- l’identité et le cycle de vie des agents ;
- les contrôles à mettre en place avant d’étendre les usages.
Le sujet ne sera plus uniquement de vérifier l’accès d’une personne à une donnée. Il faudra également savoir quelle identité utilise l’agent, quelles ressources il peut consulter, quels outils il peut mobiliser et quelles actions lui sont permises.
Avec les agents IA, le Zero Trust s’étend désormais à une nouvelle question : comment conserver la maîtrise des systèmes capables d’accéder aux ressources de l’entreprise et d’agir aux côtés des utilisateurs ?
