Une fuite de données ne ressemble presque jamais à l’image que l’on s’en fait. Dans l’imaginaire collectif, c’est un attaquant masqué qui aspire une base entière au cœur de la nuit. Dans la réalité des dossiers traités par la CNIL et les CSIRT, c’est le plus souvent un fichier client envoyé au mauvais destinataire, un document confidentiel déposé sur un cloud personnel pour le consulter le week-end, ou un export Excel collé dans un chatbot pour gagner du temps. La donnée n’a pas été volée : elle est sortie, par une porte restée ouverte.
Le DLP, pour Data Loss Prevention, est précisément l’ensemble des dispositifs qui surveillent et contrôlent ces portes. C’est une brique de sécurité particulière, car elle ne protège pas un système ou un réseau : elle protège la donnée elle-même, dans son mouvement. Et c’est aussi l’une des plus délicates à déployer, parce qu’elle touche directement aux habitudes de travail. Cet article propose une lecture de RSSI : ce qu’est réellement un DLP, pourquoi le sujet revient en force en 2026, et comment cadrer un projet sans tomber dans le piège de la surveillance contre-productive.
DLP : protéger la donnée, pas seulement le système
La plupart des dispositifs de sécurité raisonnent en termes de périmètre et d’accès. Un pare-feu filtre des flux réseau. Un système de gestion des identités décide qui a le droit d’ouvrir quoi (voir /cybersecurite/iam-pam-gestion-identites-2026/). Un EDR surveille le comportement des postes (voir /cybersecurite/edr-mdr-xdr-comparatif-rssi/). Tous protègent des contenants.
Le DLP raisonne autrement : il s’attache au contenu. Sa question n’est pas « cet utilisateur a-t-il le droit d’accéder à ce fichier », mais « cette donnée a-t-elle le droit de partir vers cette destination ». La nuance est essentielle. Un collaborateur parfaitement légitime, authentifié, habilité, peut malgré tout provoquer une fuite : en envoyant un fichier sensible à une adresse externe, en le copiant sur une clé USB, en le téléversant sur un service tiers. Aucun contrôle d’accès ne s’y oppose, puisque l’accès était autorisé. C’est exactement l’angle mort que le DLP vient couvrir.
On distingue traditionnellement trois zones de surveillance :
- Le DLP réseau, qui inspecte les flux sortants (messagerie, web, transferts de fichiers) pour détecter une donnée sensible en transit.
- Le DLP endpoint, installé sur les postes de travail, qui contrôle les actions locales : copie vers un support amovible, impression, capture, dépôt sur un cloud personnel.
- Le DLP cloud et stockage, qui scanne les espaces de partage (suites collaboratives, stockage objet) pour repérer les données sensibles mal placées ou partagées trop largement.
Aucune de ces briques ne remplace les autres. Une fuite peut emprunter n’importe lequel de ces canaux, et la couverture partielle laisse mécaniquement des trous.
Pourquoi le sujet revient en force en 2026
Trois dynamiques expliquent la remontée du DLP dans les priorités des DSI et RSSI.
La pression réglementaire sur les violations de données. Le RGPD impose à tout responsable de traitement de notifier une violation de données personnelles à la CNIL dans les 72 heures, et d’en informer les personnes concernées lorsque le risque est élevé [3][6]. La CNIL publie régulièrement le volume des notifications reçues, qui reste à un niveau historiquement haut [2]. Or une part importante de ces violations relève précisément de fuites évitables : erreur d’envoi, mauvaise configuration de partage, perte de support. Le DLP s’inscrit directement dans la démonstration de conformité : pouvoir prouver que des mesures techniques empêchent les fuites accidentelles fait partie des « mesures appropriées » attendues.
L’explosion des canaux d’exfiltration. Le travail hybride a multiplié les surfaces. La donnée ne reste plus sagement dans un partage réseau interne : elle circule entre la messagerie d’entreprise, les suites collaboratives cloud, les terminaux personnels, les espaces de stockage tiers. Le rapport ENISA Threat Landscape confirme que la compromission et la fuite de données figurent parmi les menaces majeures pour les organisations européennes [7]. Chaque nouvel outil de productivité ouvre potentiellement un canal de sortie supplémentaire.
L’irruption de l’IA générative grand public. C’est la nouveauté marquante de cette période. Coller un contrat, un fichier RH ou un code source dans un assistant conversationnel public revient, dans bien des cas, à transmettre cette donnée à un tiers hors du périmètre maîtrisé. Le phénomène recoupe celui du shadow IA, que nous avons traité par ailleurs (voir /ia-tech/shadow-ai-risques-entreprise/). Les DLP modernes intègrent désormais la détection de ces flux vers les services d’IA, ce qui en fait un cas d’usage en soi.
À ces forces s’ajoute le cadre des entités essentielles et importantes : la directive NIS2 [8] impose une gestion des risques qui couvre la protection de l’information, et la transposition française renforce les attentes en matière de mesures techniques (voir /cybersecurite/loi-resilience-transposition-nis2/).
La classification : le prérequis que l’on saute trop souvent
Voici la cause d’échec numéro un d’un projet DLP : déployer l’outil avant de savoir ce que l’on protège.
Un DLP fonctionne en reconnaissant des données sensibles parmi le flot des données ordinaires. Pour cela, il s’appuie sur des critères : motifs (un numéro de sécurité sociale, un IBAN, un format de carte de paiement), mots-clés, empreintes de documents de référence, étiquettes de classification apposées sur les fichiers. Si l’entreprise n’a jamais défini ce qui est confidentiel et ce qui ne l’est pas, l’outil n’a aucun repère fiable. Il bascule alors dans deux travers symétriques : soit il bloque tout ce qui ressemble de loin à une donnée sensible, et noie les équipes sous les faux positifs ; soit on le règle si large qu’il ne détecte plus rien d’utile.
La classification est donc le travail fondateur. Le guide d’hygiène informatique de l’ANSSI rappelle l’importance de connaître et de hiérarchiser son patrimoine informationnel [1]. En pratique, une échelle à quatre niveaux suffit dans la plupart des cas :
- Public : information diffusable sans restriction.
- Interne : usage interne, sans préjudice majeur en cas de divulgation.
- Confidentiel : divulgation préjudiciable (données clients, contrats, éléments financiers).
- Secret / critique : divulgation gravement préjudiciable (données de santé, secrets industriels, éléments soumis à des obligations sectorielles).
Cette classification n’a de valeur que si elle est opérationnelle : portée par les métiers, appliquée au moins aux données les plus critiques, et reliée à des règles de manipulation concrètes. Un DLP vient ensuite faire respecter ces règles automatiquement. Sans cette fondation, on installe un radar sans savoir ce qu’il doit détecter.
Déploiement : observer avant de bloquer
La deuxième erreur récurrente consiste à activer le blocage dès le premier jour. C’est la garantie d’un rejet immédiat : des envois légitimes refusés, des réunions paralysées parce qu’une pièce jointe ne passe plus, une équipe commerciale qui ne peut plus transmettre un devis. La confiance dans l’outil s’effondre, et avec elle le projet.
La bonne séquence est progressive et repose sur un mode observation, souvent appelé audit only ou monitor.
Phase 1 : observation silencieuse. L’outil détecte et journalise, mais ne bloque rien. Pendant plusieurs semaines, il révèle les flux réels : qui envoie quoi, vers où, par quel canal. C’est presque toujours une découverte. Des transferts de données sensibles vers des boîtes personnelles, des partages cloud trop ouverts, des exports massifs réguliers que personne n’avait cartographiés apparaissent. Cette phase a une valeur en soi : elle donne la photographie honnête des usages, indispensable pour calibrer les règles.
Phase 2 : réglage et réduction des faux positifs. À partir des données d’observation, on affine. On distingue les flux légitimes (un service comptable qui transmet des factures à un partenaire identifié) des flux à risque (le même type de données vers une destination inconnue). On accepte des exceptions documentées, on resserre là où c’est justifié. L’objectif est d’arriver à un jeu de règles dont la précision est suffisante pour que les alertes soient crédibles.
Phase 3 : bascule en blocage par périmètre. On n’active pas le blocage partout en même temps. On commence par les cas les plus clairs et les moins ambigus : exfiltration de données réglementées vers des destinations externes non autorisées, dépôt sur des services de stockage personnels. On élargit ensuite, périmètre par périmètre, en mesurant l’impact à chaque étape.
Cette approche progressive rejoint une logique que nous défendons régulièrement sur d’autres sujets : la sécurité durable se construit par itérations maîtrisées, pas par un grand soir technique. C’est la même philosophie que celle d’une trajectoire Zero Trust (voir /cybersecurite/zero-trust-architecture-5-etapes/).
Articuler le DLP avec le reste du dispositif
Un DLP isolé a peu de valeur. Sa force vient de son intégration dans un ensemble cohérent.
Avec la gestion des identités et des accès. Le DLP suppose des accès déjà maîtrisés. Si les habilitations sont laxistes, l’outil passe son temps à courir derrière des données auxquelles trop de monde a accès. Resserrer les droits en amont réduit mécaniquement la surface à surveiller (voir /cybersecurite/iam-pam-gestion-identites-2026/).
Avec la journalisation et la détection. Les alertes DLP nourrissent la supervision de sécurité. Une tentative d’exfiltration détectée par le DLP devient un signal pertinent dans un SIEM, surtout corrélée à d’autres indices (connexion inhabituelle, volume anormal). La CNIL elle-même range la traçabilité des accès et la gestion des incidents parmi les mesures de sécurité attendues [5]. Le DLP sans collecte ni corrélation des événements perd une partie de son intérêt (voir /cybersecurite/siem-journalisation-detection-logs-entreprise/).
Avec la sécurisation des postes. Le DLP endpoint vient compléter le durcissement général des terminaux que recommande la CNIL pour sécuriser les postes de travail [4] : restriction des supports amovibles, contrôle des applications, chiffrement des disques. Ces mesures réduisent le nombre de canaux que le DLP doit surveiller.
Avec la défense contre les rançongiciels. Les groupes de ransomware pratiquent massivement la double extorsion : ils exfiltrent les données avant de les chiffrer, pour faire pression par la menace de publication. Un DLP bien réglé peut détecter ces mouvements massifs de données vers l’extérieur et déclencher une alerte précoce (voir /cybersecurite/ransomware-2026-vecteurs-attaque/). Il s’inscrit ainsi dans la conformité plus large attendue des entreprises soumises à NIS2 (voir /cybersecurite/nis2-entreprise-guide-2026/).
La dimension humaine et juridique : le point qu’on ne peut pas éluder
Le DLP a une particularité qu’aucun pare-feu ne partage : il observe l’activité des personnes. Surveiller les flux sortants, c’est inévitablement regarder ce que les salariés envoient, copient, publient. Cette dimension impose des garde-fous que la CNIL rappelle régulièrement [6].
La proportionnalité. Le dispositif doit être limité à ce qui est nécessaire. Inspecter le contenu de toutes les communications, y compris privées, de façon systématique, serait disproportionné. On cible les données et les canaux qui le justifient.
La transparence. Les salariés doivent être informés de l’existence du DLP, de sa finalité et de ses modalités. Un dispositif de surveillance dissimulé est non seulement contraire au RGPD, mais aussi juridiquement fragile en cas de contentieux. L’information passe par une politique d’usage claire et la mention du traitement dans le registre.
Le dialogue social. La mise en place d’un outil susceptible de contrôler l’activité des employés relève de la consultation des instances représentatives du personnel. C’est une étape à intégrer dès le cadrage du projet, pas à découvrir une fois l’outil déployé.
Ces exigences ne sont pas des freins, ce sont des conditions de robustesse. Un DLP déployé dans la transparence, perçu comme un filet de sécurité collectif plutôt que comme un outil de flicage, est mieux accepté et donc plus efficace. À l’inverse, un déploiement opaque et brutal génère du contournement, du shadow IT et, à terme, du contentieux.
Ce qu’un RSSI retient
Le DLP n’est pas un produit que l’on installe : c’est une démarche que l’on conduit. Sa réussite tient à trois conditions, dans cet ordre. D’abord savoir ce que l’on protège, par une classification au moins partielle des données critiques. Ensuite déployer en observant avant de bloquer, pour ne pas paralyser le travail et calibrer des règles crédibles. Enfin assumer la dimension humaine et juridique, en intégrant la proportionnalité, la transparence et le dialogue social dès le départ.
Vu sous cet angle, le DLP n’est pas une couche de surveillance supplémentaire mais un prolongement logique de la gouvernance des données. Il rend tangible une politique de classification qui, sans lui, reste souvent un document mort. Et il offre, face à une obligation RGPD de notification toujours plus contraignante, un moyen concret de réduire le volume des fuites évitables, celles qui forment l’essentiel des violations déclarées.
FAQ
Quelle différence entre DLP et chiffrement des données ?
Les deux protègent la donnée mais répondent à des risques différents. Le chiffrement rend la donnée illisible pour qui n’a pas la clé : il protège contre le vol d’un support ou l’accès non autorisé au stockage. Le DLP, lui, contrôle le déplacement de la donnée : il détecte et bloque une tentative d’envoi, de copie ou de publication d’une information sensible vers une destination non autorisée, même par un utilisateur légitime. Un fichier chiffré au repos peut très bien être déchiffré par son propriétaire puis exfiltré en clair : c’est précisément ce flux que le DLP surveille. Les deux briques sont complémentaires, pas substituables.
Un DLP est-il compatible avec le RGPD quand il surveille les salariés ?
Oui, à condition de respecter trois principes. D’abord la proportionnalité : la surveillance doit être limitée aux données et aux canaux qui le justifient réellement, sans inspection généralisée du contenu des communications privées. Ensuite la transparence : les salariés doivent être informés du dispositif, de sa finalité et de ses modalités, via une politique d’usage et une mention dans le registre des traitements. Enfin le dialogue social : la mise en place d’un outil susceptible de contrôler l’activité des employés relève de la consultation du comité social et économique. La CNIL rappelle que la sécurité des données ne justifie pas une surveillance disproportionnée des personnes.
Faut-il déployer un DLP avant ou après avoir classifié ses données ?
Avant le déploiement réel, la classification est un prérequis. Un DLP fonctionne en reconnaissant ce qu’il doit protéger : sans politique de classification (public, interne, confidentiel, secret) et sans marquage ou empreinte des données sensibles, l’outil ne dispose d’aucun critère fiable et multiplie les faux positifs. En pratique, on peut lancer une phase d’observation DLP pour cartographier les flux existants, mais la mise en blocage suppose une classification au moins partielle des données les plus critiques.
Cet article a été rédigé et relu par Marc Aubert, rédacteur en chef de Cyber Networks, ex-RSSI dans le secteur bancaire (CISSP, CISM, EBIOS Risk Manager). Il s’appuie sur les recommandations de l’ANSSI, les fiches sécurité de la CNIL et les publications de l’ENISA. Conformément à la charte éditoriale, aucun éditeur de solution DLP n’a participé à sa rédaction.