Vos collaborateurs utilisent déjà l’IA. ChatGPT, Copilot, Gemini, Claude : ces outils tournent déjà dans votre organisation, souvent depuis un mobile personnel ou un onglet de navigateur que personne ne supervise. Vous n’avez donc pas vraiment à décider si vous « lancez » l’IA puisque c’est déjà fait. En revanche, vous pouvez reprendre la main avant qu’un incident ne le fasse à votre place.
C’est tout l’enjeu de sécuriser l’IA en entreprise : encadrer des usages existants sans casser ce qui fait gagner du temps aux équipes.
Voici comment vous y prendre, concrètement, dans un environnement Microsoft 365.
Avant même que votre organisation ait défini une politique IA, vos collaborateurs utilisent déjà des outils comme ChatGPT, Copilot, Gemini ou Claude en dehors de tout cadre officiel. Ce phénomène, le « Shadow AI », est le pendant moderne du Shadow IT des années 2000, avec une surface d’exposition bien plus large.
Soyons directs : si vous travaillez en Modern Workplace depuis plus de six mois, vous avez déjà rencontré au moins un de ces scénarios.
Ces situations ont un point commun : l’IA est déjà là, que vous ayez un framework de gouvernance ou non. Reprendre le contrôle est désormais l’enjeu, pas le déploiement lui-même.
Microsoft 365 Copilot s’appuie sur le Microsoft Graph pour accéder aux données de l’utilisateur. Concrètement, il peut voir tout ce que l’utilisateur peut voir : ses emails, ses fichiers OneDrive, les SharePoint auxquels il a accès, ses conversations Teams, ses calendriers.
Le problème n’est pas l’IA elle-même : c’est que le Graph expose la réalité de vos droits d’accès. Et dans la majorité des tenants M365 qui ont quelques années d’existence, cette réalité est souvent chaotique :
Copilot ne crée pas ces problèmes. Il les amplifie et les rend visibles, parfois de la pire manière possible : directement dans une réponse adressée à un collaborateur.
Plusieurs élements sont à prendre en compte lors de la mise en place de Copilot :
Ce travail est ingrat, mais sans lui, le déploiement de Copilot est une bombe à retardement.
Vos politiques DLP Microsoft Purview actuelles sont probablement configurées pour détecter des numéros de carte bancaire, des données de santé ou des identifiants nationaux dans des emails et des fichiers. Ce qu’elles ne font pas encore bien : inspecter le contenu des prompts envoyés à des services LLM externes.
Prenez le cas d’un utilisateur qui copie-colle un contrat client dans ChatGPT depuis son navigateur Chrome, sur un poste Intune-managé. Est-ce que votre stack DLP le détecte ? Peut-être, si vous avez configuré des politiques de contrôle des applications web dans Defender for Endpoint. Probablement pas si l’utilisateur est sur son mobile personnel, hors réseau corporate.
C’est là qu’intervient la notion de Shadow AI : une étude Cyberhaven de 2025 estime qu’environ 11 % des données copiées dans des outils IA publics par les employés sont classifiées comme sensibles selon les politiques de leur propre entreprise. Et ce chiffre ne couvre que les cas détectables.
Côté Intune et Defender, trois actions concrètes :
A lire aussi >> Hallucinations LLM : quelle est cette dérive de l’IA générative ?
Si vous n’avez pas encore déployé les étiquettes de sensibilité Microsoft Purview, c’est votre point de départ absolu. Elles vous permettent de classifier vos données et de conditionner leur usage, y compris leur accès par Copilot.
La configuration minimale recommandée : au moins quatre niveaux (Public, Interne, Confidentiel, Hautement Confidentiel), avec des politiques d’auto-classification basées sur le contenu pour les données les plus sensibles. Les documents étiquetés « Hautement Confidentiel » peuvent être exclus de l’indexation Copilot via les paramètres de recherche SharePoint et Graph.
Attention : l’étiquetage automatique ne remplace pas l’étiquetage manuel. Commencez par un pilote de classification manuelle avec un groupe d’utilisateurs ambassadeurs, puis déployez l’auto-classification pour rattraper l’existant.
Un vecteur de fuite souvent négligé : les Copilot Pages. Quand un utilisateur génère un résumé ou une analyse avec Copilot, il peut le sauvegarder comme une Copilot Page dans Loop, un espace de collaboration qui a ses propres droits de partage.
Assurez-vous que les politiques de partage de Loop sont alignées avec vos politiques SharePoint générales, et que les Copilot Pages héritent bien des étiquettes de sensibilité des documents sources.
Microsoft 365 Copilot supporte des plugins qui étendent ses capacités : connecteurs vers des CRM, des ITSM ou des services métier. Chaque plugin est un connecteur potentiel entre tes données M365 et un service externe.
Gouvernez les plugins exactement comme vous gouvernez les applications OAuth : liste blanche explicite, revue des scopes demandés, approbation admin obligatoire. Dans le portail Microsoft 365 Admin Center, vérifiez que seuls les plugins approuvés par votre organisation sont disponibles pour les utilisateurs.
Avant de laisser un agent IA tiers s’intégrer à ton tenant, vous devez pouvoir répondre à ces questions :
Mail.ReadWrite et Files.ReadWrite.All pour « résumer des emails » devrait immédiatement lever des drapeaux. Applique le principe du moindre privilège : seuls les scopes strictement nécessaires à la fonction annoncée.Ce n’est pas à une seule personne de porter cette charge. Proposez en interne l’existence d’un comité de validation des projets IA, même informel au début, qui inclut un représentant IT/Modern Workplace, un référent sécurité et un référent juridique/conformité.
Le processus peut être léger : un formulaire de demande standardisé avec les questions listées ci-dessus, une revue technique de 30 minutes, et un go/no-go documenté. Ce qui compte, c’est d’avoir un point de contrôle avant la mise en production, pas après l’incident.
Sur les appareils personnels (BYOD), vous n’avez pas de contrôle sur le device lui-même, mais vous pouvez contrôler ce qui se passe au niveau des applications managées avec les Intune App Protection Policies.
Configuration recommandée pour limiter les fuites de données IA sur mobile :
Ces politiques s’appliquent même sur des appareils non enrôlés en MDM, ce qui est leur principal avantage dans un contexte BYOD.
Envisagez des politiques d’accès conditionnel spécifiques pour les ressources IA sensibles. Par exemple : l’accès aux déploiements Azure OpenAI de l’entreprise peut être conditionné à un appareil Intune-compliant et à une localisation géographique connue. Un accès depuis un appareil non managé ou une localisation inhabituelle déclenche alors une MFA renforcée ou un blocage.
Microsoft Entra ID supporte des politiques Conditional Access basées sur des noms d’applications cloud personnalisés : vous pouvez donc couvrir vos propres applications IA Azure dans le périmètre du Conditional Access.
C’est votre point d’observation sur la circulation des données sensibles dans le tenant. Trois signaux méritent une alerte :
C’est ici que vous détectez le Shadow AI et les usages qui échappent à votre cadre. Gardez un œil sur :
Pour les applications IA que vous hébergez vous-même, c’est votre source de vérité côté usage et abus. Surveillez en priorité :
La mise en place d’alertes sur ces signaux dans ton SIEM (Microsoft Sentinel ou autre) est un investissement de quelques heures qui peut vous éviter des semaines de gestion de crise post-incident.
Vous pouvez déployer les meilleures politiques techniques du monde, si les utilisateurs ne comprennent pas pourquoi certains comportements sont risqués, ils trouveront des contournements. Pas par malveillance, mais parce que l’outil non approuvé est souvent plus pratique que l’outil approuvé.
La formation doit être concrète et courte. Oubliez les modules e-learning de 45 minutes sur la sécurité générale. Ce qui fonctionne :
Alliez-vous avec les ambassadeurs numériques ou les Digital Champions de votre organisation s’ils existent : ce sont eux qui font le vrai travail de diffusion des bonnes pratiques au quotidien.
L’ingénieur Modern Workplace est souvent perçu comme celui qui dit non : non à l’outil non approuvé, non au déploiement sans revue sécurité, non à la clé API en clair dans le code. Ce n’est pas le bon positionnement.
Votre rôle est de rendre possible ce que le business veut faire, dans des conditions qui ne mettent pas l’organisation en danger. Ça passe par des configurations solides, des processus légers mais existants, et une communication claire sur ce qui est autorisé et comment l’utiliser.
L’IA n’est pas une menace que vous devez contenir. C’est une capacité que vous devez encadrer. Sécuriser l’IA en entreprise, c’est exactement ça : la faire tenir dans le temps, sans incident majeur, sans audit raté, sans fuite de données qui aurait pu être évitée.
C’est exactement le travail d’un bon ingénieur Modern Workplace.
