DLP : choisir un outil et respecter le RGPD

Une solution DLP — Data Loss Prevention cherche à détecter ou limiter certains usages et transferts non autorisés d’informations. Elle peut aider à protéger un fichier clients ou un dossier confidentiel. Son intérêt dépend toutefois du périmètre réellement couvert, de la qualité des règles et des personnes qui traitent les alertes.

Ce qu’une solution DLP peut couvrir

Les fonctions varient selon le produit, la licence et la configuration : messagerie, espaces de partage, terminaux ou certains flux vers le cloud. La documentation Microsoft Purview décrit, par exemple, des politiques fondées sur le contenu et le contexte, avec des avertissements ou des blocages selon les règles. Elle distingue les emplacements et leurs prérequis. Ce périmètre ne doit pas être attribué automatiquement à tout produit DLP. Source : Microsoft, présentation de Purview DLP.

Avant une démonstration, rédigez un scénario vérifiable : « empêcher l’envoi externe d’un export clients depuis telle application, avec une procédure d’exception approuvée ». Demandez ensuite comment le produit réagit aux formats non reconnus, aux fichiers chiffrés, aux terminaux non gérés et aux applications hors périmètre.

La grille des logiciels de conformité et de cybersécurité permet de situer ce besoin parmi les autres outils. Une fonction DLP ne remplace ni la gestion des habilitations ni la restauration des données.

Le RGPD impose une sécurité adaptée, pas l’achat d’une DLP

L’Art. 32 du RGPD demande des mesures appropriées au risque. Il ne désigne pas un produit DLP obligatoire. L’Art. 25 prévoit la protection des données dès la conception et par défaut ; son application doit également tenir compte du traitement réel. Source : RGPD, Art. 25 et 32.

Le dispositif de détection peut lui-même traiter des données personnelles : identifiants, événements, destinataires et extraits de documents. Il faut donc définir ses finalités, limiter les données collectées et justifier leur conservation. La prévention des fuites ne donne pas une autorisation générale de surveiller chaque action d’un salarié. Source : RGPD, Art. 5(1)(b), (c) et (e).

Déterminer la base légale et les garanties

Pour un organisme privé, l’intérêt légitime peut être envisagé après examen de la nécessité et mise en balance des droits. Il ne se présume pas. Si une obligation légale est retenue, identifiez le texte et démontrez la nécessité des opérations effectuées pour la respecter. L’obligation de sécurité ne justifie pas à elle seule n’importe quel périmètre d’inspection. Source : RGPD, Art. 6(1)(c), (f) et 6(3).

Le triple test de l’intérêt légitime aide à documenter cette décision. Si le dispositif traite des données de l’Art. 9, il faut aussi examiner les conditions de cet article, notamment pour les extraits susceptibles de révéler des informations de santé ou syndicales. Source : RGPD, Art. 9.

Évaluez la nécessité d’une AIPD selon les risques et les listes applicables. Une DLP n’est pas automatiquement un traitement à grande échelle ; son étendue, les données observées et ses conséquences peuvent néanmoins entraîner un risque élevé au sens de l’Art. 35(1). Source : RGPD, Art. 35.

Respecter les règles de contrôle des salariés

L’information préalable prévue par l’Art. L. 1222-4 et la proportionnalité exigée par l’Art. L. 1121-1 du code du travail restent applicables. Décrivez le périmètre, les finalités, les destinataires et les modalités du contrôle, ainsi que les droits RGPD pertinents. Sources : L. 1222-4, L. 1121-1.

Lorsque le dispositif permet un contrôle de l’activité, l’information-consultation préalable du CSE relève notamment de l’Art. L. 2312-38, dans le régime des entreprises d’au moins cinquante salariés. Ne transposez pas cette règle sans vérifier le statut de l’organisme et le régime de représentation applicable. Source : code du travail, L. 2312-38.

La CNIL rappelle la nécessité d’examiner les moyens moins intrusifs et de prévenir les objectifs cachés. En pratique, limitez l’accès au contenu des alertes, définissez les conditions d’investigation et préservez la vie privée des personnes employées. Source : CNIL, contrôle de l’activité, 9 juillet 2026.

Enfin, la recevabilité judiciaire d’une preuve ne doit pas être confondue avec la licéité du dispositif. Depuis l’arrêt d’assemblée plénière du 22 décembre 2023, n° 20-20.648, une preuve illicite ou déloyale n’est pas nécessairement écartée d’un procès civil : le juge procède, lorsque cela lui est demandé, à la mise en balance décrite au § 12, avec indispensabilité et stricte proportionnalité. Cela ne rend pas licite une collecte irrégulière. Source : Cour de cassation, § 12 à 14.

Évaluer un pilote avant les blocages

Voici une trame de pilote proposée :

Microsoft propose notamment un mode de simulation qui permet d’examiner les correspondances sans appliquer les actions de blocage. Il faut distinguer les résultats de simulation des protections réellement activées. Cette fonction constitue un exemple produit, pas une exigence légale ni une promesse de couverture exhaustive. Source : Microsoft, mode de simulation DLP.

Suivez le nombre d’alertes qualifiées, le taux de faux positifs, les délais de traitement et les exceptions ouvertes. Évitez le KPI « violations évitées » sans méthode démontrable : un blocage n’établit pas à lui seul qu’une violation aurait eu lieu.

Si une alerte révèle une atteinte aux données, déclenchez la procédure de gestion des fuites. Les obligations des Art. 33 et 34 s’apprécient selon leurs propres conditions ; une alerte ou un blocage DLP ne tranche pas automatiquement la question. Source : RGPD, Art. 33 et 34.

Trois situations résolues (exemples hypothétiques)

Les cas suivants sont fictifs. Ils montrent comment appliquer la grille de décision, sans prétendre décrire un dossier réel.

Cas 1 — Export clients envoyé à une adresse personnelle. Une société de services souhaite bloquer l’envoi d’exports du CRM vers des messageries privées. Le scénario est précis, le canal est identifié (messagerie professionnelle) et la finalité est la sécurité du fichier clients. Une base d’intérêt légitime peut être documentée, à condition d’avoir envisagé des mesures moins intrusives, comme la limitation des droits d’export dans le CRM. La bonne première décision est souvent de réduire la source du risque (qui peut exporter ?) avant d’inspecter les flux. La DLP intervient ensuite en complément, avec un avertissement d’abord et un blocage seulement après la période de pilote.

Cas 2 — Règle « tout document contenant des données de santé ». Un service RH demande une règle qui détecte les arrêts maladie dans les courriels. Le dispositif va alors lire des contenus relevant de l’Art. 9 pour une finalité de prévention des fuites. Deux questions précèdent la configuration : la détection est-elle nécessaire pour une catégorie aussi sensible, et quelle condition de l’Art. 9(2) s’applique-t-elle ? À défaut de réponse solide, on circonscrit la règle au service concerné, on limite l’extrait visible dans l’alerte (par exemple le type de donnée détecté, sans le contenu) ou on renonce à cette règle. Le fait que l’outil sache la créer ne la rend pas proportionnée.

Cas 3 — Alerte sur un salarié qui part. Une alerte signale qu’un commercial a copié des dossiers vers une clé USB avant son départ. Il ne s’agit pas encore d’une conclusion : la copie peut relever d’une activité autorisée (transmission à un successeur). L’investigation doit rester encadrée : accès restreint aux alertes, finalité limitée à la vérification, échange avec la personne avant toute sanction et conservation des seules pièces utiles. Si l’enquête établit une extraction non autorisée de données clients, la qualification en violation de données se fait alors selon l’Art. 33, et non du seul fait de l’alerte.

Contrat avec l’éditeur : sous-traitance, transferts et registre

Un outil DLP en SaaS traite des données pour le compte de l’organisme : en principe, l’éditeur agit comme sous-traitant, ce qui impose un contrat conforme à l’Art. 28(3) (instructions documentées, confidentialité, mesures de sécurité, sous-traitants ultérieurs, assistance, suppression ou restitution, audit). Notre article sur le contrat de sous-traitance détaille ces clauses. Source : RGPD, Art. 28.

Les alertes peuvent contenir des extraits de documents. Demandez donc où ils sont stockés, qui y accède côté éditeur (support, ingénieurs) et dans quel pays. Si des données sont accessibles depuis un pays tiers, le chapitre V s’applique : décision d’adéquation, clauses types ou autre garantie. Voir l’article sur les transferts hors UE et celui sur le Data Privacy Framework. Source : RGPD, Art. 44 à 46.

Enfin, le traitement doit figurer au registre prévu par l’Art. 30 (finalités, catégories de données et de personnes, destinataires, durées, mesures de sécurité). La DLP est un traitement à part entière : elle ne se cache pas derrière la ligne « sécurité informatique » générique. Source : RGPD, Art. 30.

Conservation des alertes et droits des personnes

Les journaux et alertes ne doivent pas être conservés sans limite : l’Art. 5(1)(e) impose de fixer une durée adaptée à la finalité. Distinguez les alertes closes sans suite, les alertes ayant donné lieu à une procédure et les journaux nécessaires à la sécurité du dispositif lui-même. Le règlement ne fixe pas de durée unique pour ces données : c’est à l’organisme de la justifier et de la documenter dans le registre.

Un salarié peut demander l’accès aux données le concernant (Art. 15). Les alertes qui le visent, leur qualification et les extraits conservés peuvent entrer dans cette demande, sous réserve des droits des tiers et des exceptions applicables, appréciés au cas par cas. Prévoyez une procédure interne pour retrouver ces éléments plutôt que de la découvrir à réception de la demande. Source : RGPD, Art. 5(1)(e) et 15.

Côté sécurité, l’outil concentre des informations sensibles : limitez les comptes administrateurs, activez l’authentification forte, et conservez la trace des consultations des alertes. Un outil de prévention des fuites mal protégé devient lui-même une source de fuite (Art. 32).

Ce qu’il faut retenir

• Choisissez une DLP à partir de scénarios et d’un périmètre vérifiables.
• Le RGPD exige une sécurité adaptée, sans imposer cet achat à tous.
• La détection doit respecter les droits des salariés et les règles de contrôle.
• Mesurez les résultats qualifiés, pas seulement le volume d’alertes.
• Encadrez l’éditeur (Art. 28, transferts), inscrivez la DLP au registre et fixez une durée de conservation des alertes.
• Commencez par réduire la source du risque (droits d’export) avant d’inspecter les flux.

FAQ

Une DLP empêche-t-elle toutes les fuites ?

Non. Les résultats dépendent des canaux couverts, des formats, des règles et de la configuration. Un pilote doit documenter aussi les limites et les cas non détectés.

Peut-on activer la surveillance avant d’informer les salariés ?

Un mode d’observation peut déjà collecter des données sur les personnes. L’absence de blocage ne dispense pas des obligations préalables applicables au traitement et au contrôle.

Une alerte impose-t-elle de notifier la CNIL ?

Il faut d’abord qualifier les faits et déterminer s’il existe une violation de données personnelles. La notification dépend ensuite des conditions de l’Art. 33, notamment du risque pour les personnes.

L’éditeur d’une DLP est-il sous-traitant ?

Dans un modèle SaaS où l’éditeur traite les alertes pour votre compte et selon vos instructions, il agit en principe comme sous-traitant, et l’Art. 28(3) impose un contrat. Le rôle réel se vérifie selon qui détermine les finalités et les moyens ; l’intitulé du contrat ne suffit pas.

Une DLP peut-elle analyser les données de santé ou syndicales ?

Elle le fait techniquement si la règle l’y conduit, mais le traitement doit alors respecter l’Art. 9 et la proportionnalité. Limitez ces règles au strict nécessaire et évitez d’afficher le contenu dans les alertes.

Recevez nos analyses conformité : inscrivez-vous à la newsletter.

Thiébaut Devergranne, docteur en droit, travaille depuis plus de 20 ans sur la protection des données et le droit des technologies.