Defender for Cloud Apps retire ses file policies le 6 janvier 2027 au profit de Purview

Microsoft retire les file policies de Defender for Cloud Apps le 6 janvier 2027. La protection des données fondée sur les fichiers passe à Microsoft Purview : une file policy qui détecte du contenu sensible et agit dessus se recrée en stratégie DLP, une file policy qui pose une étiquette de sensibilité se recrée en stratégie d’auto-labeling. Le même jour, Microsoft retire aussi l’emplacement Instances de Purview DLP, par lequel une stratégie DLP visait les applications tierces connectées à Defender for Cloud Apps, ainsi que l’expérience de création de ces stratégies.

Defender for Cloud Apps reste en place : Microsoft précise que le produit continue d’assurer la découverte des applications SaaS, la gestion de posture et la détection des menaces. Le retrait figure dans les notes de version de juin 2026, et un assistant de migration l’accompagne dans le portail Microsoft Defender.

Ce qui change	Date ou statut	Ce que Microsoft demande ou indique
File policies de Defender for Cloud Apps	Retrait le 6 janvier 2027	Les recréer en stratégies DLP ou d’auto-labeling dans Purview avant cette date
Emplacement Instances de Purview DLP et création des stratégies correspondantes	Retrait le 6 janvier 2027	Recréer les stratégies avec les emplacements dédiés aux applications tierces connectées
DLP Purview pour Box, Dropbox, Google Workspace et Salesforce	Preview, déploiement par phases	Un connecteur d’application Defender for Cloud Apps est requis
Assistant de migration du portail Defender	Disponible, limité aux stratégies DLP SharePoint et OneDrive	L’auto-labeling et les applications tierces ne sont pas encore pris en charge
Découverte des applications SaaS, gestion de posture, détection des menaces	Restent dans Defender for Cloud Apps	Microsoft indique que le produit continue de les assurer

Relevé le 29 septembre 2026 sur la documentation Microsoft.

Inventorier les file policies et les classer par usage

La procédure de Microsoft commence par un inventaire, sous Cloud Apps > Policies > Policy management, filtre Type sur File policy. Elle demande de noter les applications ciblées, la méthode d’inspection du contenu, les types d’informations sensibles ou les étiquettes détectés, les filtres de contexte et les actions de gouvernance.

Chaque stratégie se classe ensuite selon son rôle : la détection et la réponse partent vers Purview DLP, l’étiquetage selon le contenu vers l’auto-labeling. Une file policy qui étiquette, notifie et alerte se recrée, dans l’exemple de Microsoft, en deux stratégies Purview : une stratégie d’auto-labeling et une stratégie DLP aux mêmes conditions.

La page de migration demande le groupe de rôles Compliance Administrator ou Compliance Data Administrator dans Purview, le rôle Cloud App Security Administrator dans Defender for Cloud Apps pour relire les file policies, et une licence Microsoft 365 E5, Microsoft 365 E5 Compliance ou une licence autonome Purview DLP équivalente.

L’assistant de migration traite les stratégies DLP de SharePoint et OneDrive

L’assistant ne prend en charge que les file policies DLP de SharePoint et de OneDrive : l’auto-labeling et les stratégies des applications tierces, notamment Google Workspace, Box, Dropbox et Salesforce, ne sont pas encore pris en charge. L’outil est réservé aux clients commerciaux en environnement Production, et n’est pas disponible pour les environnements gouvernementaux ou souverains. Il demande les permissions Security Administrator côté Defender et Compliance Administrator côté Purview.

On l’ouvre par le bouton Migrate du bandeau de retrait, sous Cloud apps > Policies > Policy management, onglet All policies. Il répartit les stratégies entre Can migrate, Partial migration et Cannot migrate, montre ce qu’il va créer avec un Verdict et des avertissements sur les champs à reprendre à la main, puis affiche le résultat par ligne, Created in Purview en cas de succès. Microsoft demande de ne pas fermer la fenêtre pendant la migration, sous peine de stratégies incomplètes ou mal configurées.

Les stratégies créées portent le nom [Migrated] <nom d'origine> (1P DLP). Une stratégie source qui vise SharePoint et OneDrive en donne deux, une par emplacement. Elles sont créées en mode Test with notifications et n’appliquent aucune action tant que le mode appliqué n’a pas été activé. La migration ne supprime pas les file policies d’origine, et une stratégie classée Cannot migrate se recrée à la main, à moins d’attendre l’extension annoncée sous Coming soon.

Les actions de gouvernance qui changent de nature dans Purview

Extrait de la correspondance publiée par Microsoft, limité aux actions dont l’équivalent est partiel ou absent :

Action de Defender for Cloud Apps	Équivalent documenté dans Purview	Niveau de parité et remarque de Microsoft
User quarantine	File quarantine for SharePoint and OneDrive	Partiel : le fichier part vers un site de quarantaine contrôlé par l’administrateur, pas vers un dossier de quarantaine utilisateur
Remove specific collaborator	Restrict access : Block access for specific external domains or users (Preview)	Partiel : bloque l’accès, sans supprimer la relation de partage existante
Trash or delete file	Aucun équivalent direct	Restrict access DLP et Power Automate (suppression sur alerte)
Expire shared link	Aucun équivalent direct	Stratégies de partage SharePoint et accès conditionnel Microsoft Entra
Transfer file ownership	Aucun équivalent direct	Processus manuel ou Power Automate (propre à Google Workspace)

La même page donne pour équivalentes les notifications, les alertes, la quarantaine administrateur et la pose ou le retrait d’étiquette. Elle range aussi parmi les équivalents trois actions de partage, qu’elle fait correspondre à des actions Restrict access : le retrait de l’accès public et le passage en privé deviennent Block everyone except owner, le retrait des utilisateurs externes devient Block people outside org.

La différence de fond tient au partage déjà en place. Les actions Restrict access de Purview bloquent tout le monde, les personnes externes ou des domaines et utilisateurs externes précis, sans modifier le partage existant ; Microsoft renvoie à Power Automate pour le retirer. Pour le retrait d’un lien direct, la documentation donne deux réponses : la page de migration le fait correspondre à une action Restrict access : Remove sharing link, que la référence des stratégies DLP, relevée le 29 septembre 2026, ne liste pas parmi les options de SharePoint et de OneDrive. La quarantaine, elle, retire toutes les permissions et tous les liens de partage du fichier avant de le déplacer.

Les conditions sans équivalent exact

Pour SharePoint et OneDrive, le filtre Parent folder n’a pas de correspondance au niveau du dossier : la stratégie se limite à un périmètre par site. Pour les applications tierces, Microsoft liste en revanche les dossiers parents, la date de modification et la date de création parmi les attributs disponibles, sauf la date de création dans Dropbox. La condition Collaborators appliquée à toute l’organisation se remplace par Collaborators (domain). Le File ID n’est pas pris en charge comme condition, et Microsoft le déclare non migrable.

L’inspection du contenu se reporte plus directement : une file policy fondée sur Data Classification Service retrouve le même moteur de détection dans Purview DLP, et une expression régulière personnalisée doit d’abord devenir un type d’informations sensibles personnalisé.

Les fichiers déjà stockés : la quarantaine ne touche que les fichiers créés ou modifiés après l’activation

Les file policies détectent et corrigent les violations sur l’information au repos comme sur le contenu nouvellement créé. Dans Purview, la quarantaine n’a pas ce comportement, et l’auto-labeling porte sa propre restriction.

La quarantaine de fichiers DLP pour SharePoint et OneDrive, encore en preview, ne s’applique qu’aux fichiers créés ou modifiés après l’activation de la stratégie qui porte cette action. Les fichiers présents avant cette activation ne sont pas évalués pour la quarantaine. Microsoft précise que ce comportement est propre à la quarantaine : les autres actions DLP, comme le blocage, s’appliquent à tous les fichiers du périmètre, quelle que soit leur date de création. Un fichier analysé par une classification à la demande peut en revanche déclencher la quarantaine si le résultat correspond pour la première fois à une règle. Enfin, la restauration d’un fichier mis en quarantaine est manuelle, les permissions de partage d’origine ne sont pas restaurées, et seule la dernière version du fichier revient.

Les stratégies d’auto-labeling peuvent étiqueter des fichiers au repos créés avant ou après la stratégie. En revanche, un type d’informations sensibles ne s’applique qu’au contenu créé ou modifié après sa propre création ou modification ; Microsoft précise que cette restriction vaut pour les types personnalisés et pour les nouveaux types intégrés. Pour les fichiers anciens restés inchangés, Microsoft recommande une classification à la demande.

Box, Dropbox, Google Workspace et Salesforce : une recréation manuelle, sans mode simulation

L’assistant ne migre pas encore les stratégies des applications tierces. Deux cas se recréent donc à la main : les file policies qui visent ces applications, et les stratégies Purview DLP de l’emplacement Instances.

Les nouveaux emplacements dédiés sont en preview. Ils prennent en charge Box, Dropbox, Google Workspace et Salesforce, qui arrivent par phases, pas forcément en même temps dans chaque tenant. La page de l’emplacement Instances cite aussi Cisco Webex parmi les applications à connecter.

Ces stratégies ont leurs propres règles de construction :

• chaque application doit être connectée à Defender for Cloud Apps par un connecteur d’application ;
• la stratégie se crée depuis le modèle Custom policy, les modèles prédéfinis Financial, Medical and health et Privacy étant exclus ;
• plusieurs applications tierces peuvent figurer dans une même stratégie, mais pas avec SharePoint, OneDrive, Exchange, Fabric ou Devices ;
• les règles sont des règles DLP avancées, et les conditions comme les actions disponibles varient selon l’application ;
• les policy tips et les user overrides ne sont pas pris en charge, pas plus que les administrative units ;
• les fichiers chiffrés et les fichiers PDF stockés dans ces applications ne sont actuellement pas pris en charge pour la classification.

Pour la bascule, une limite compte particulièrement : le mode simulation n’est pas pris en charge pour ces stratégies. À l’étape Policy mode, le choix se limite à activer la stratégie immédiatement ou à la laisser désactivée. Une stratégie peut en revanche viser toutes les instances d’une application, ou inclure et exclure des instances précises. Activity explorer et les alertes DLP couvrent ces applications, Content explorer non.

L’ordre recommandé : créer dans Purview, valider, désactiver sans supprimer, puis supprimer

Microsoft écrit que les stratégies de Defender for Cloud Apps et de Purview ne peuvent pas coexister, parce que des stratégies équivalentes actives dans les deux produits créent des conflits dans l’application des stratégies. La consigne est de ne désactiver les stratégies de Defender for Cloud Apps qu’après avoir validé et activé les stratégies Purview.

Les nouvelles stratégies tournent d’abord en mode simulation, sauf pour les applications tierces qui ne le prennent pas en charge, et leurs correspondances se comparent à celles des file policies. La mise en application s’étend ensuite d’un groupe pilote à toute l’organisation. La vérification compare enfin les stratégies Purview à l’inventaire, types d’informations sensibles et étiquettes compris.

Le retrait des file policies suit quatre temps :

1. exporter la configuration de chaque file policy, ou la capturer en images, et la conserver ;
2. dans le portail Defender, passer chaque file policy migrée à l’état Disabled, sans la supprimer ;
3. surveiller que les stratégies Purview apportent une protection équivalente ;
4. une fois cette validation faite avec les file policies désactivées, supprimer chacune d’elles.

La documentation des file policies ajoute une règle à connaître pendant la phase de surveillance : quand aucune file policy n’existe, ou quand elles restent désactivées sept jours consécutifs, la surveillance des fichiers se désactive automatiquement.

Notre lecture

Nous ne considérerions pas la migration comme terminée quand l’assistant affiche Created in Purview : l’auto-labeling, les applications tierces, les stratégies classées Cannot migrate et les actions sans équivalent restent à reprendre. Nous ferions donc l’inventaire complet avant sa première exécution.

L’écart qui nous paraît le plus important concerne les fichiers déjà stockés, et le tableau de Microsoft ne le signale pas comme une absence d’équivalent. Une file policy qui mettait en quarantaine du contenu au repos n’a pas le même effet dans Purview, où la quarantaine ne touche que les fichiers créés ou modifiés après l’activation. Pour l’auto-labeling, la limite tient au type d’informations sensibles, s’il est personnalisé ou récent. Nous planifierions une classification à la demande dès que l’objectif de la stratégie d’origine portait sur des fichiers anciens.

Pour les applications tierces, sans simulation ni coexistence avec la stratégie d’origine, la validation se fait en production. Nous commencerions par une instance, avec des actions de notification et d’alerte si l’application les propose, avant d’activer des actions plus contraignantes.

Enfin, une file policy qui retirait un partage existant, qu’il s’agisse de collaborateurs précis, de l’accès public ou d’un lien, change de nature dans Purview : les actions Restrict access bloquent l’accès sans retirer le partage, et la quarantaine retire toutes les permissions et déplace le fichier, ce qui dépasse le simple retrait d’un partage. Nous traiterions ce cas à part, avec un flux Power Automate ou les réglages de partage SharePoint que Microsoft désigne. Et puisque Purview DLP ne descend pas sous le niveau du site dans SharePoint, l’inventaire des sites SharePoint sensibles devient la base du périmètre des stratégies, comme il l’est déjà quand il s’agit de limiter ce que Copilot voit dans SharePoint avec Restricted Content Discovery.

Ce qu’il faut vérifier

• L’inventaire des file policies, avec pour chacune les applications ciblées, la méthode d’inspection, les filtres de contexte et les actions de gouvernance.
• Les file policies qui posent une étiquette : elles se recréent en auto-labeling, à la main, et se doublent d’une stratégie DLP si elles notifient ou alertent aussi.
• Les stratégies qui utilisent Parent folder, File ID, Collaborators sur toute l’organisation ou une expression régulière personnalisée.
• Les actions Trash or delete file, Expire shared link, Transfer file ownership, Remove specific collaborator et User quarantine, qui n’ont qu’un équivalent partiel ou aucun équivalent direct.
• Les stratégies qui retirent un partage, par Remove public access, Remove external users, Make private ou Remove direct shared link : les actions Restrict access bloquent l’accès sans retirer le partage existant, et l’action Remove sharing link que la page de migration associe au retrait d’un lien ne figure pas dans la référence des stratégies DLP.
• Les stratégies qui devaient agir sur des fichiers déjà stockés, pour prévoir une classification à la demande.
• L’emplacement de quarantaine Purview, configuré avant toute stratégie qui utilise l’action File quarantine.
• Les stratégies Purview DLP de l’emplacement Instances, les connecteurs d’application dont dépendent les nouveaux emplacements et la disponibilité de chaque application tierce dans le tenant.
• La surveillance des fichiers dans Defender for Cloud Apps, qui se désactive automatiquement si aucune file policy n’existe ou si elles restent désactivées sept jours consécutifs.

Les sources Microsoft

• Migrate file policies to Microsoft Purview
• What’s new in Microsoft Defender for Cloud Apps
• File policies in Microsoft Defender for Cloud Apps
• Use data loss prevention policies for non-Microsoft cloud apps
• Use Microsoft Purview data loss prevention policies for non-Microsoft connected apps (preview)
• Learn about DLP file quarantine for SharePoint and OneDrive
• Data Loss Prevention policy reference
• Apply a sensitivity label to content automatically