Sécuriser l’IA en entreprise du tenant aux endpoints

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.

Shadow AI : pourquoi l’IA est déjà dans votre entreprise

Shadow IT, Shadow AI : même combat, surface élargie

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.

Trois scénarios type de Shadow IA que vous avez forcément croisés

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.

• Le document confidentiel remonté par Copilot. Un utilisateur signale que M365 Copilot lui a affiché un document confidentiel auquel il n’aurait pas dû avoir accès. Pas parce que Copilot a piraté quoi que ce soit, mais parce que le site SharePoint en question avait des droits « Tout le monde » configurés il y a trois ans et jamais revus.
• Le manager qui réclame ChatGPT. Il demande pourquoi son équipe ne peut pas utiliser ChatGPT alors que « tous les concurrents le font ». Et vous, vous savez que la moitié de l’équipe l’utilise déjà depuis son mobile personnel, hors de tout contrôle.
• Le « petit chatbot IA » improvisé. Une demande de déploiement d’un chatbot sur Teams, développé en deux semaines par un prestataire, avec une clé API OpenAI codée en dur dans le code source.

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.

Comprendre la surface d’attaque réelle en environnement M365

Ce que Copilot indexe vraiment

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 :

• Des sites SharePoint créés pour un projet ponctuel il y a quatre ans, toujours accessibles à l’ensemble de l’organisation.
• Des documents RH ou financiers partagés via des liens « Tout le monde avec le lien » jamais révoqués.
• Des équipes Teams archivées dont les membres incluent encore d’anciens collaborateurs ou prestataires.

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.

Les prérequis à la mise en place de Copilot

Plusieurs élements sont à prendre en compte lors de la mise en place de Copilot :

• Lancer un audit des droits d’accès SharePoint avec le rapport de partage de contenu dans Purview, ou avec l’outil SharePoint Advanced Management.
• Identifier les sites en oversharing (partagés à « Tout le monde » ou à l’ensemble de l’organisation).
• Nettoyer les permissions en commençant par les bibliothèques contenant des données RH, financières ou juridiques.

Ce travail est ingrat, mais sans lui, le déploiement de Copilot est une bombe à retardement.

Les DLP face aux requêtes LLM : les limites de l’existant

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 :

• Configurer des politiques de restriction d’application web dans Defender for Endpoint pour bloquer ou auditer l’accès aux LLM non approuvés depuis les postes managés.
• Utiliser les politiques de protection des applications (APP) Intune pour empêcher le copier-coller depuis les apps M365 vers des apps non managées sur mobile.
• Activer le logging de Microsoft Defender for Cloud Apps (anciennement MCAS) pour avoir de la visibilité sur les usages IA SaaS.

A lire aussi >> Hallucinations LLM : quelle est cette dérive de l’IA générative ?

Sécuriser Microsoft 365 Copilot : la checklist gouvernance

Sensitivity labels : la fondation indispensable

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.

Copilot Pages et la gestion des outputs

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.

Auditer les plugins et connecteurs Copilot

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.

Gérer les agents IA tiers : quand les équipes construisent leurs propres outils

Les questions à poser systématiquement

Avant de laisser un agent IA tiers s’intégrer à ton tenant, vous devez pouvoir répondre à ces questions :

• Où tourne le modèle ? Est-ce un appel à une API externe (OpenAI, Anthropic, Mistral) ou un modèle hébergé dans ton Azure ? Si c’est externe, les données du prompt quittent le périmètre Microsoft. Quel DPA est en place avec ce fournisseur ?
• Quels sont les scopes Graph demandés ? Un bot Teams qui réclame 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.
• Où sont stockées les clés API ? Les secrets ne doivent jamais être en dur dans le code ni dans des variables d’environnement non sécurisées. Azure Key Vault est la réponse standard. Si l’équipe de dev ne connaît pas Key Vault, c’est un signal d’alerte sur la maturité sécurité globale du projet.
• Y a-t-il un logging des interactions ? Chaque requête à un LLM et chaque réponse doivent être loggées pour audit. Pas dans un fichier texte local, mais dans Azure Monitor ou un workspace Log Analytics centralisé, avec une rétention conforme à tes politiques.

Mettre en place un processus de validation des projets IA

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.

Intune et la sécurisation des endpoints face à l’IA

App Protection Policies : votre filet de sécurité sur mobile

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 :

• Désactiver le copier-coller depuis les apps M365 (Outlook, Teams, Word, Excel) vers des apps non managées.
• Bloquer les captures d’écran dans les apps managées sur Android.
• Exiger un PIN d’application ou une authentification biométrique pour les apps contenant des données sensibles.

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.

Conditional Access : contextualiser l’accès aux ressources IA

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.

Surveiller pour sécuriser l’IA en entreprise dans la durée

Microsoft Purview Activity Explorer

C’est votre point d’observation sur la circulation des données sensibles dans le tenant. Trois signaux méritent une alerte :

• Les activités de partage inhabituelles sur des documents étiquetés « Confidentiel » ou « Hautement Confidentiel ».
• Les accès à des fichiers sensibles par des comptes qui n’y avaient pas touché depuis longtemps.
• Les exports massifs de données.

Microsoft Defender for Cloud Apps

C’est ici que vous détectez le Shadow AI et les usages qui échappent à votre cadre. Gardez un œil sur :

• Les nouveaux services IA SaaS accédés depuis ton réseau (détection de Shadow AI).
• Les volumes de données inhabituels uploadés vers des services inconnus.
• Les nouvelles connexions OAuth demandant des scopes larges.

Azure Monitor pour les déploiements IA internes

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é :

• Le volume de tokens consommés par utilisateur ou par application : les pics peuvent indiquer un usage anormal ou une exfiltration.
• Les erreurs d’authentification répétées sur les endpoints LLM.
• Les requêtes contenant des patterns suspects (tentatives de prompt injection connues).

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.

Former les utilisateurs : le maillon essentiel

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 :

• Des exemples réels et parlants : « voici ce qui s’est passé dans une entreprise comme la nôtre ».
• Des règles simples et mémorables : « si tu ne mettrais pas cette information dans un email à un externe, ne la mets pas dans un prompt IA public ».
• Des alternatives claires : « voici les outils approuvés que tu peux utiliser sans restriction ».

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.

Conclusion : sécuriser l’IA en entreprise, un enjeu de gouvernance continue

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.