DLP pour applications non Microsoft : Purview prend le relais de Defender le 6 janvier 2027

Deux annonces qui n'ont de sens qu'ensemble

Le 7 juillet 2026, Microsoft a publié un avis de retrait : les stratégies de fichiers (« file policies ») de Defender for Cloud Apps cessent d'être prises en charge et appliquées le 6 janvier 2027 (MC1417993). Ce qui n'aura pas été migré d'ici là ne protège plus rien. Un mois plus tard, le 7 août 2026, une seconde annonce est arrivée : le DLP de Microsoft Purview et l'étiquetage automatique s'étendent aux applications non Microsoft (MC1449180).

Prises séparément, ces deux nouvelles passent pour de la plomberie. Ensemble, elles décrivent un déplacement net : la protection des fichiers quitte Defender for Cloud Apps pour Purview, y compris pour les données qui ne vivent pas dans Microsoft 365. Et le calendrier est serré, parce que la capacité de remplacement arrive à peine.

Ce que le DLP pour applications non Microsoft couvre vraiment

Le périmètre s'appuie sur les connecteurs de Defender for Cloud Apps. Les stratégies DLP Purview peuvent viser Google Workspace, Box, Dropbox, Salesforce, ServiceNow, Amazon Web Services et Cisco Webex. L'étiquetage automatique, lui, ne couvre que Google Workspace et Box.

Cette asymétrie compte. Si votre plan était d'appliquer des étiquettes de confidentialité sur du contenu Salesforce ou ServiceNow, ce n'est pas au menu : vous pouvez détecter et bloquer, pas classifier automatiquement.

Le calendrier annoncé : préversion publique de la mi-août au début septembre 2026, disponibilité générale du début septembre à la fin octobre 2026. La fonction sort donc de préversion quelques semaines seulement avant l'échéance de janvier. Ce n'est pas beaucoup de temps pour valider en simulation.

Les deux mécanismes ne peuvent pas coexister

Microsoft est explicite là-dessus, et c'est le piège le plus coûteux. Avant de créer une stratégie Purview sur un emplacement non Microsoft, il faut désactiver ou supprimer la stratégie de fichiers Defender qui vise le même emplacement. Faire tourner les deux en parallèle crée des conflits d'application.

La séquence sûre est donc contre-intuitive : on crée la stratégie Purview en mode simulation, on valide ce qu'elle attrape, on l'active, et seulement là on désactive la stratégie Defender. Sans la supprimer tout de suite : on garde l'export de configuration le temps de comparer les résultats.

Ce que vous perdez dans la traduction

Les stratégies de fichiers de Defender reposaient sur plus de vingt filtres de métadonnées et un moteur d'expressions régulières intégré. Purview ne reprend pas tout, et la documentation de migration de Microsoft liste les écarts :

• La portée s'exprime au niveau du site, plus au niveau du dossier parent.
• La condition sur l'identifiant de fichier n'a aucun équivalent.
• Les expressions régulières doivent être recréées sous forme de types d'informations sensibles personnalisés.
• Plusieurs filtres de métadonnées n'ont pas de correspondance.
• La mise en quarantaine se fait vers un site administré, plus vers un dossier utilisateur.
• Le retrait d'un collaborateur précis est remplacé par un blocage, qui empêche l'accès futur sans défaire les partages déjà en place.

La facturation change de logique

Aucun de ces points n'est bloquant en soi. Ensemble, ils veulent dire qu'une migration réussie n'est pas un copier-coller de règles, c'est une révision de vos règles. Deuxième surprise possible : l'usage n'est pas couvert par la licence seule. Il faut une licence Purview de palier entreprise, et le traitement des fichiers d'applications non Microsoft est facturé par le compteur « Purview At Rest Protection » en paiement à l'usage, où mille fichiers comptent pour un actif de données.

La question à poser avant de configurer quoi que ce soit est donc simple : quels emplacements non Microsoft contiennent réellement des renseignements personnels ou des données réglementées ? Étendre le DLP partout parce que c'est possible est le meilleur moyen de payer pour scanner des dossiers marketing.

Ce qu'il y a à faire d'ici janvier

Pour une organisation assujettie à la Loi 25 ou au RGPD, il y a un bénéfice indirect à faire l'exercice maintenant. La question « où sont nos renseignements personnels et qui peut les sortir » ne s'arrête pas à la frontière de Microsoft 365, et l'inventaire que cette migration vous force à produire ressemble beaucoup à celui que réclame un registre de traitement.

• Inventorier les stratégies de fichiers actives dans le portail Defender (filtre « Type : stratégie de fichiers ») et documenter les applications visées, les conditions et les actions.
• Trier : ce qui relève de la détection va vers le DLP Purview, ce qui applique une étiquette va vers l'étiquetage automatique.
• Décider du périmètre non Microsoft à partir du risque réel, pas du catalogue de connecteurs disponibles.
• Recréer en mode simulation, comparer les détections pendant deux à trois semaines, puis basculer.
• Vérifier les rôles : administration de la conformité ou des données de conformité côté Purview, administration Cloud App Security côté Defender.