08/04/2026
Cybersecurity Insights
Data protection : les erreurs qui peuvent compromettre la réussite d’un projet DLP
La donnée est considérée comme l’or noir du 21ᵉ siècle : sa maîtrise et son exploitation permettent de bâtir des empires, les GAFA en sont des exemples typiques. Avec l’essor des IA qui s’entraînent en continu, la donnée est devenue centrale dans de nombreux processus. Sans aller dans ces sphères technologiques, la plupart des entreprises, quelle que soit leur taille, ont compris qu’une bonne connaissance de leur marché et de leurs clients passe par une bonne maîtrise de leurs données. Ce “cœur” de valeur attire évidemment les convoitises.
La donnée est désormais prise pour cible quasi systématiquement, qu’il s’agisse de la voler pour la revendre, de l’exploiter à des fins concurrentielles ou de la détruire ou menacer de la détruire (ransomware). Dans tous les cas, l’enjeu est de la protéger. C’est là qu’entrent en jeu les activités de data protection, et qu’on commence à parler de Data Leak Prevention (DLP). Lorsqu’on veut prévenir la fuite d’information, le réflexe est souvent de se focaliser d’emblée sur les solutions techniques. Or, de notre expérience, le choix de l’outil devrait venir en dernier. Toute une série de prérequis, essentiellement organisationnels, devraient être traités avant même de lancer une évaluation de solutions. Qui n’a pas déjà entendu : projet DLP décevant, trop de faux positifs, fuites bien réelles non détectées, budgets qui explosent au fil des ajouts de fonctionnalités, solutions complexes à utiliser, véritables “usines à gaz” qui découragent les équipes et décrédibilisent les responsables sécurité. L’objet de cet article est de mettre en lumière les principales erreurs qui peuvent gravement compromettre la réussite d’un projet DLP, en couvrant aussi bien les aspects organisationnels que techniques.
Les erreurs principales à ne pas commettre
Choisir trop tôt une solution technique
Mettre en place un dispositif de lutte contre la fuite d’information est d’abord un projet métier. Tant que le travail de compréhension des activités métiers et des données manipulées n’est pas fait, il est inutile de choisir ou même de présélectionner une solution technique. Comprendre les métiers, c’est comprendre les données qu’ils utilisent, produisent et échangent, ainsi que l’importance de ces données pour leur activité. Cette compréhension, côté équipe cyber, permet de mesurer la complexité des informations qui devront être identifiées par les solutions DLP. La plupart des outils savent très bien gérer des données simples, reposant sur des dictionnaires (nom, prénom, email, téléphone…). Mais les données sensibles vont bien au‑delà en général : rapports de risques, données de fabrication, coûts unitaires, remises différenciées selon les fournisseurs, plans, procédés techniques originaux, etc. Leur structure et leur contexte mettent rapidement à l’épreuve les capacités de modélisation des solutions. Nous avons par exemple rencontré, dans le domaine du génie génétique, des fichiers text based, en extension.fastq, lisibles avec un simple Notepad mais non traités par la plupart des solutions DLP, car celles‑ci s’appuient sur l’extension du fichier pour décider si le contenu est analysable. Il n’existe pas de solution miracle qui fonctionnerait immédiatement pour n’importe quelle organisation. Selon le type de données, l’architecture du SI et les objectifs, une solution efficace pour une entreprise peut être inadaptée pour une autre.
Mauvaise compréhension de la donnée sensible
Cette première erreur en amène une seconde : ne pas avoir une vision claire de ce qu’est une donnée sensible, du point de vue des métiers. Comprendre une donnée sensible, c’est aller au‑delà d’une définition théorique ; c’est prendre connaissance des activités de l’organisation, mais aussi “vivre” la vie des lignes métiers pour assimiler leur business. Un conseil souvent donné à un CISO qui débute est d’aller au‑devant des métiers : les rencontrer, comprendre leur travail, leurs outils, leurs problèmes. Au‑delà du bénéfice relationnel, c’est un prérequis pour appréhender des risques qui ne remontent pas par les circuits standards et mesurer la difficulté de déployer des mesures de sécurité parfois éloignées des préoccupations opérationnelles des lignes métiers. Dans une organisation qui ne dispose ni de politique de classification ni de communication sur la notion de données sensibles, il sera difficile d’identifier les données à protéger en priorité. Si la base même de ce que l’on veut protéger n’est pas définie, le choix et la mise en œuvre d’une solution DLP seront forcément compliqués. Pour autant, l’identification de données sensibles ne nécessite pas systématiquement une politique de classification lourde. Quelques questions pragmatiques permettent déjà d’avancer. En caricaturant, demander à un manager s’il serait à l’aise de voir un document publié sur une page Facebook publique permet déjà de distinguer une donnée publique d’une donnée interne ou sensible. L’exemple est simple, mais repose sur une approche méthodologique : qualifier la sensibilité au travers de l’impact d’une fuite d’information. La difficulté réside moins dans la complexité conceptuelle que dans le temps à dégager pour aller à la rencontre des métiers et échanger sur un sujet souvent nouveau pour eux.
Ne pas disposer d’un one pager de classification
Qu’une politique de classification existe déjà ou non, il est nécessaire de disposer d’une grille simple – un “one‑pager” – permettant à un utilisateur de classifier rapidement les données qu’il manipule. Lorsque la politique existe, nous constatons très souvent que le document est long, complexe, difficile à lire et à transposer dans le quotidien. L’utilisateur standard ne sait pas comment l’appliquer, et, faute de temps, renonce. Dans ce contexte, même en rencontrant les métiers, on se heurte à un problème : il manque un outil simple pour réaliser ce travail de classification. Il faut donc simplifier la politique existante en une matrice claire, indiquant les niveaux de sensibilité et les critères associés. Quand aucune politique n’est présente, il faut au moins construire une première ébauche avant de lancer les entretiens avec les métiers. C’est là où la compréhension des activités métiers devient un vrai levier pour les équipes sécurité : elle évite que la “cyber” reste dans une tour d’ivoire, déconnectée de la réalité.
Négliger l’accompagnement du changement et la communication
Déployer un système DLP implique de classifier et de labéliser les documents. Qu’elle soit automatique, manuelle ou hybride, la labélisation sera visible par les utilisateurs : labels sur les documents, messages, restrictions de partage. Sans accompagnement structuré, clair, porté par un sponsor interne, ces actions risquent de se heurter à des résistances ou à un manque d’adhésion. Or, l’utilisateur est celui qui connaît le mieux la sensibilité de ses données et qui les manipule au quotidien. Les actions de communication/change doivent être envisagées de manière récurrente : messages internes, webinaires, supports disponibles, relais par le management. Plus elles seront diffusées, plus l’adoption de la classification et de la labélisation sera ancrée dans les comportements. Ce point est aussi important que le choix de la solution technique, mais il est souvent sous‑estimé, faute de ressources ou de visibilité sur son importance.
Ne pas définir la gouvernance des alertes DLP
Une fois les données sensibles identifiées et les utilisateurs préparés, une autre erreur fréquente consiste à ne pas anticiper, avant le déploiement, la gouvernance des alertes DLP que la solution va remonter. Comment seront traitées les alertes ? Qui aura le droit d’investiguer, et jusqu’à quel niveau de détail ? Comment les personnes impliquées seront-elles prévenues ? Quels seront les workflows de décision et les éventuelles sanctions ? Toutes ces questions doivent être traitées avant le passage en mode run, sous peine de disposer d’un outil qui remonte des alertes sans qu’elles puissent être analysées correctement ou dans des délais compatibles avec la gravité potentielle des fuites. Ces questions touchent à la structure même de l’entreprise : prise de responsabilité, niveau de confiance donné aux équipes d’analyse, éventuelle externalisation, rôle des RH, du juridique, du DPO, des managers. Chaque entreprise a sa culture, mais certains principes sont communs :
- Un pouvoir d’investigation complet doit être donné à une équipe identifiée : on ne peut pas se contenter de lire un libellé, il faut pouvoir inspecter le contenu.
- Un dispositif de contrôle de second niveau doit exister pour rassurer la direction sur les garde-fous.
- Des échelles d’escalade doivent être définies selon la criticité de l’alerte, avec les intervenants associés.
Notre expérience nous a démontrés que les alertes critiques font intervenir directement un représentant RH, le DPO, le CISO, un membre de la direction, un représentant des risques et le manager de l’employé concerné en cas de fuite interne, afin de garantir un traitement homogène et une représentativité équilibrée.
Ne pas analyser la solution DLP par rapport à l’écosystème SOC/IT
Avec la diffusion des environnements cloud et le recours à des services SOC/SIEM, le choix d’une solution DLP doit être réalisé en tenant compte de l’architecture de cyber détection globale, qu’elle soit externalisée ou non. Les alertes DLP s’ajoutent aux autres alertes que les équipes cyber doivent traiter. Elles ne doivent plus être considérées isolément, mais intégrées dans les scénarios d’intrusion possibles. Une fuite d’information peut être le fait d’un interne (malveillant ou non) ou la conséquence d’une intrusion externe. Dans ce dernier cas, l’activité de fuite et son alerte doivent être corrélées à l’ensemble des indicateurs de compromission (IOC) : accès non autorisés, comportements anormaux, mouvements latéraux, élévations de privilèges, etc. Le choix d’une solution DLP doit donc s’entendre par rapport à ses capacités d’interconnexion et d’intégration avec le reste du dispositif de surveillance. Le cas typique est Purview, qui s’intègre dans l’écosystème de sécurité Microsoft et permet un traitement des alertes orienté “data centric first”, où l’accès et la manipulation de la donnée définissent le scénario de piratage. À l’inverse, une solution peu interopérable alourdira le traitement des alertes et réduira l’efficience globale du dispositif.
Ne pas avoir conscience des limites de la labellisation
“Si j’ai labélisé correctement tous mes documents, mon système DLP sera parfaitement opérationnel.” Cette affirmation repose sur un postulat faux : celui que tout document peut faire l’objet d’une labélisation, ce qui n’est pas le cas. Un système DLP ne doit pas s’appuyer exclusivement sur les labels. Ceux-ci peuvent, selon la configuration, être à la main de l’utilisateur, avec le risque d’erreurs ou de contournements, et tous les documents ne peuvent pas forcément être labélisés du fait de formats particuliers. Connaître ces limites et les communiquer à la Direction évite les déconvenues sur la perception du projet. Cela pèse aussi dans le choix de la solution : certaines lacunes de labélisation peuvent être compensées par d’autres mesures (contrôles de contenu, règles contextuelles, restrictions d’usage), d’autres non.
Ne pas identifier au préalable les canaux de fuite
Déployer une solution DLP sans avoir identifié au préalable les canaux de fuite revient à risquer la surprotection de certains flux et à laisser des angles morts ailleurs. La plupart des entreprises ont déjà mis en place des mesures de sécurité basiques : filtrage internet, contrôles d’accès sur les serveurs de fichiers, Conditional Access pour des environnements cloud, etc. Ces mesures ne sont pas nécessairement “DLP orientées”, mais réduisent déjà certains risques. La question centrale devient alors : à quel niveau se situe cette réduction, et, au regard des impacts possibles, est-il nécessaire d’ajouter des contrôles DLP ? Une approche pragmatique consiste à partir d’un postulat simple : où qu’elle se trouve, on suppose que la donnée est accessible à un malveillant. Sur cette base, on recense tous les canaux par lesquels elle pourrait sortir : email, stockage cloud externe, supports amovibles, impression, capture d’écran, flux applicatifs, API, etc. Ce nombre de canaux est nécessairement plus faible que l’ensemble des sources de données, ce qui rend l’analyse plus accessible. Ces canaux doivent être identifiés en tenant compte de l’infrastructure réelle (réseau, firewalling, durcissement des postes et serveurs, couches de protection existantes). La difficulté, pour l’équipe cyber, est de bien recenser ces mesures et d’en évaluer l’efficience. Une fois ce travail effectué, chaque canal est analysé sous deux angles : le risque de fuite potentiel et l’efficacité des contrôles existants (blocage, audit). Les faiblesses constatées guident ensuite la décision de compléter ou non par une solution ou des règles DLP.
Vouloir tout faire tout de suite
Dernière erreur, qui dépasse le seul cadre du DLP : vouloir tout faire en un seul projet. Cet article a souligné la complexité de ce type de démarche, qui demande des phasages spécifiques selon la nature des actions (organisationnelles, techniques, échanges métiers) et les ressources disponibles. Intégrer l’ensemble dans un projet unique présente plusieurs difficultés :
- Date de fin potentiellement très éloignée, compliquée à porter en communication ;
- Problèmes rencontrés sur certaines phases assimilés au projet global, avec un impact sur la position du sponsor ;
- Lisibilité réduite des dépendances entre composants ;
- Responsabilité lourde pour un chef de projet unique, surtout si plusieurs départements sont impliqués.
Le conseil est de considérer un programme de mise en place de la data protection. Chaque projet du programme modélise une phase spécifique de la mise en place de la protection DLP, ce qui permet d’en mieux appréhender les difficultés, de définir les responsabilités et d’allouer les ressources et budgets de manière plus fine. Contrairement aux idées reçues, un programme offre souvent une flexibilité de suivi plus grande qu’un projet monolithique.
Conclusion
Un projet DLP est bien plus qu’un simple déploiement d’outil. Une préparation organisationnelle en amont est nécessaire (compréhension des métiers, identification des types de données sensibles, définition des workflows de traitement), complétée par une préparation technique (identification des canaux de fuite, compréhension des limites de la labélisation, intégration avec l’écosystème SOC/IT). L’ensemble doit être intégré dans un programme de data protection, qui scinde les différentes étapes avant le déploiement complet d’une solution. Cette approche permet de présenter progressivement les briques fondatrices qui contribueront à atteindre la cible finale, plutôt que de porter un projet massif avec une date de mise en place trop éloignée, difficile à défendre en termes de communication et de visibilité managériale. Chaque erreur mentionnée peut faire l’objet d’un sous‑projet individuel, avec ses ressources et son budget, pour construire progressivement la cible globale. Prises une par une, ces erreurs ne représentent pas une complexité insurmontable ; au contraire, leur prise en compte structurée est une source d’efficience pour l’ensemble du dispositif DLP.
Dominique ASSING
Directeur Almond Suisse
Vous souhaitez échanger sur un projet Data protection & DLP ? Contactez-nous :
