Comment évaluer les fournisseurs de solutions DSPM : le cadre de sélection destiné aux acheteurs d'entreprise
- L'étendue de la découverte ne constitue à elle seule qu'un indicateur peu fiable de l'efficacité du DSPM : la précision de la classification et l'évaluation des risques sont des critères plus importants.
- Les évaluations de validation de principe doivent s'appuyer sur des données de production réelles et sur des solutions SaaS à l'échelle de l'entreprise, et non sur des ensembles de tests synthétiques.
- La précision de la classification et la hiérarchisation des risques ont le plus grand poids dans le cadre d'évaluation des fournisseurs.
- Le DSPM n'est pas une solution autonome : évaluez son niveau d'intégration avec votre infrastructure existante (SSE, DLP, SIEM et IAM).
- Constituez votre comité d'évaluation en veillant à ce qu'il comprenne des représentants des services chargés de la sécurité, de la conformité, de la gouvernance des données et des opérations informatiques.
- Les échecs les plus coûteux en matière de DSPM sont ceux qui s'inscrivent dans la durée : il s'agit d'outils qui sont mis en place, mais qui n'atteignent jamais leur maturité opérationnelle.
- Posez des questions difficiles aux fournisseurs. Les réponses génériques aux appels d'offres ne permettent pas de cerner aussi bien les défis que des réponses ciblées, adaptées à des scénarios spécifiques.
Le choix d’une solution de gestion de la posture de sécurité des données est l’une des décisions d’achat les plus cruciales qu’une équipe de sécurité aura à prendre cette année. Si vous faites le bon choix, vous bénéficierez d’une visibilité permanente sur l’emplacement des données sensibles, les personnes qui y ont accès et leur niveau réel d’exposition. Si vous vous trompez, vous aurez acheté un tableau de bord coûteux qui génère des alertes auxquelles personne ne donne suite. Le défi réside dans le fait que tous les fournisseurs de cette catégorie proposent des démonstrations convaincantes : des moteurs de classification sophistiqués analysant des environnements de test soigneusement préparés, des cartes de risque élégantes, des intégrations énumérées sur une diapositive. C’est l’écart entre ce que vous voyez lors d’une démonstration et ce que vous constatez en production qui fait échouer la plupart des achats de solutions DSPM.
Ce guide propose un cadre structuré et indépendant des fournisseurs pour évaluer les plateformes DSPM. Il s’articule autour des critères d’évaluation utilisés par des cabinets d’analystes tels que Forrester et Gartner dans leurs Magic Quadrant « Wave » et Magic Quadrant » — découverte, classification, analyse des risques, correction, niveau d’intégration et maturité opérationnelle —, mais transpose ces critères en une méthodologie de notation pratique que votre équipe peut appliquer lors de la présélection et des tests de validation de concept. Les recommandations de la Cloud Security Alliance en matière de DSPM soulignent en outre qu’une évaluation efficace doit aller au-delà des simples listes de fonctionnalités afin d’évaluer les performances d’une solution par rapport à votre environnement de données réel, à vos modèles d’accès et à vos obligations de conformité.
Que vous soyez un RSSI chargé d'élaborer une analyse de rentabilité, un délégué à la protection des données (DPO) chargé de recenser les exigences réglementaires en matière de preuves, un ingénieur en sécurité cloud chargé de tester la résistance de la couverture des API, ou un responsable des achats chargé de modéliser le coût total de possession, le cadre présenté ci-après offre à chaque partie prenante un rôle bien défini au sein d'un processus d'évaluation unique et unifié.
La mise à l'épreuve de la validation de principe
Les démonstrations des fournisseurs constituent par nature des environnements optimisés. Les données de test sont « propres », les structures d’autorisations sont simples et les modèles de classification ont été ajustés pour fonctionner dans les scénarios spécifiques présentés. Pour être efficaces, les évaluations de validation de concept doivent inclure, le cas échéant, des données de production réelles et des environnements SaaS à l’échelle de l’entreprise, car les ensembles de données de test simplifiés mettent rarement en évidence les défis liés à l’exploitation, à la visibilité et à la gouvernance qui apparaissent dans les déploiements complexes de Microsoft 365 et multicloud.
Le problème du M365
Voici un scénario qui se répète dans presque toutes les évaluations de solutions DSPM en entreprise : lors de la démonstration du fournisseur, un site SharePoint de test contenant quelques centaines de documents et doté d’autorisations simples est analysé. La précision de la classification semble excellente : plus de 95 % de précision dans la détection des données à caractère personnel, une évaluation des risques sans faille, un nombre minimal de faux positifs. Puis, vous connectez la solution à votre environnement Microsoft 365 réel.
Ce que le fournisseur ne vous a pas montré, c’est ce qui se passe lorsque son scanner rencontre des autorisations Teams imbriquées héritées à travers les hiérarchies de canaux, des sites SharePoint comportant des liens de partage complexes (toute personne disposant du lien, personnes spécifiques, à l’échelle de l’organisation), des autorisations d’accès pour les utilisateurs invités enfouies à trois niveaux de profondeur dans l’appartenance à des groupes, des fichiers OneDrive partagés via le chat Teams (ce qui crée des autorisations de partage invisibles dans l’interface d’administration de SharePoint), ainsi que des étiquettes de sensibilité appliquées de manière incohérente d’une unité opérationnelle à l’autre. Dans ces conditions réelles, la précision de la classification chute souvent de manière significative, les faux positifs explosent car le scanner ne parvient pas à résoudre les chaînes d’héritage des autorisations et, par défaut, signale tout comme étant surexposé, et le tableau de bord des risques devient tellement encombré que votre équipe de sécurité commence à l’ignorer en l’espace de quelques semaines.
Éléments à tester dans le cadre d'une véritable démonstration de faisabilité (POC)
Organisez votre démonstration de faisabilité autour de scénarios qui mettent réellement à l'épreuve une plateforme DSPM. Connectez le fournisseur à un environnement M365 de production représentatif — et non à un tenant de test. Choisissez un segment de tenant présentant une réelle complexité en matière de partage : un service qui collabore intensément avec des partenaires externes, un environnement Teams comportant des canaux privés imbriqués, ainsi que des sites SharePoint sur lesquels se sont accumulées, au fil des années, des autorisations de partage ad hoc.
Évaluez la classification par rapport aux données de référence. Avant la démonstration de faisabilité (POC), marquez manuellement un échantillon de 200 à 500 documents couvrant différents niveaux de sensibilité. Une fois les analyses DSPM terminées, comparez ses classifications à vos données de référence. Calculez la précision (quel pourcentage des éléments signalés sont réellement sensibles) et le rappel (quel pourcentage des éléments réellement sensibles ont été détectés). Les fournisseurs qui ne parviennent pas à atteindre une précision supérieure à 85 % et un rappel supérieur à 80 % sur vos données réelles dans le cadre d’une démonstration de faisabilité optimisée afficheront des performances inférieures en production.
Testez la profondeur de résolution des autorisations. Créez des scénarios de test comportant des chaînes d'autorisations complexes connues : un document partagé via le chat d'une réunion Teams, un fichier SharePoint dont l'accès est hérité par le biais d'un groupe de sécurité imbriqué comprenant des utilisateurs invités, un dossier OneDrive partagé avec un groupe M365. Vérifiez que le DSPM est capable de déterminer avec précision qui dispose d'un accès effectif, et pas seulement qui détient des autorisations nominales.
Évaluez le processus de triage des faux positifs. Un taux élevé de faux positifs reste gérable si le processus de triage et de rejet est efficace. En revanche, un taux modéré de faux positifs associé à une interface de triage peu intuitive est plus problématique. Mesurez le temps nécessaire à un analyste pour examiner, valider, puis rejeter ou remonter un résultat. Multipliez ce temps par le volume quotidien d'alertes prévu.
Effectuez un cycle complet de correction. Sélectionnez cinq cas réels de surexposition identifiés lors de l'analyse POC. Tentez de les corriger en suivant le workflow du DSPM : révoquer un lien de partage, ajuster les autorisations, appliquer une étiquette de confidentialité. Vérifiez si la correction est effectivement prise en compte dans M365 et si le DSPM reflète l'état de sécurité mis à jour lors de son prochain cycle d'analyse.
Effectuez vos tests à l'échelle réelle de vos données. Si votre entreprise dispose de 50 To de données réparties entre M365 et AWS S3, une démonstration de faisabilité (POC) portant sur 500 Go ne permet pas de tirer de conclusions quant aux performances, à la durée de l'analyse ou à l'efficacité des analyses incrémentielles. Insistez pour que la portée de la POC représente au moins 20 % du volume de vos données de production.
Questions à poser aux fournisseurs
Les listes de contrôle génériques pour les appels d'offres donnent lieu à des réponses génériques. Les questions ci-dessous ont pour but de mettre en évidence les lacunes spécifiques en matière de capacités ainsi que les réalités opérationnelles que les supports marketing des fournisseurs ne révèlent pas.
Concernant la précision de la classification : « Quel est le taux de faux positifs que vous avez mesuré sur des données non structurées dans des environnements M365 comptant plus de 10 000 utilisateurs ? Pouvez-vous nous fournir des clients de référence de taille similaire qui pourraient partager leurs indicateurs de précision après optimisation ? » Les fournisseurs qui ne citent des chiffres de précision provenant que d’environnements contrôlés ou qui refusent de vous mettre en relation avec des clients de référence pour discuter de la précision laissent entrevoir une lacune.
Concernant la résolution des autorisations : « Lorsque votre scanner détecte un fichier SharePoint dont l’accès effectif découle d’un groupe de sécurité Azure AD imbriqué comprenant des utilisateurs invités B2B, comment résolvez-vous les autorisations effectives ? Expliquez-moi en détail les appels d’API spécifiques et la logique d’héritage des autorisations. » Ce test permet de vérifier si le mappage d’accès du fournisseur tient véritablement compte de l’identité ou s’il s’appuie sur des données d’autorisation nominales sans résoudre l’imbrication des groupes.
Concernant la personnalisation de la classification : « Nous disposons de types de données sensibles spécifiques à notre secteur qui ne sont pas couverts par les classificateurs standard PII/PHI/PCI. Quelle est la procédure à suivre pour créer des classificateurs personnalisés ? Combien d’échantillons d’apprentissage sont nécessaires, quelle est la durée habituelle du cycle de réglage, et quelle précision pouvons-nous espérer obtenir avec les types personnalisés par rapport aux types intégrés ? » Cela permet de distinguer les fournisseurs disposant de moteurs de classification véritablement entraînables de ceux qui proposent des règles personnalisées basées sur des expressions régulières, présentées comme relevant de l’apprentissage automatique.
Concernant la transparence du modèle de risque : « Comment votre score de risque est-il calculé ? Quelles variables entrent en ligne de compte dans ce score, comment sont-elles pondérées, et pouvons-nous ajuster ces pondérations ? Si deux fichiers contiennent des données à caractère personnel identiques, mais que l’un est accessible à 5 utilisateurs et l’autre à 5 000, comment votre modèle de risque les différencie-t-il ? » Un système de notation des risques opaque, impossible à expliquer ou à ajuster, ne résistera pas à l’examen minutieux de votre RSSI ni aux questions de votre auditeur.
Concernant les mécanismes d’intégration : « Montrez-moi la charge utile réelle des événements que votre plateforme envoie à un SIEM. Quels champs sont inclus ? S’agit-il d’un événement structuré CEF/LEEF, d’un webhook JSON ou d’un dump syslog ? Pouvons-nous filtrer les événements qui sont transmis ? » La différence entre une intégration SIEM qui enrichit votre SOC et une autre qui l’inonde d’événements inutilisables réside dans la structure de la charge utile et la granularité du filtrage.
Concernant les limites en matière de mesures correctives : « Quelles mesures correctives votre plateforme peut-elle mettre en œuvre de manière native — non pas simplement recommander, mais réellement mettre en œuvre ? Pour M365 en particulier, pouvez-vous révoquer un lien de partage, modifier les autorisations d’accès à un site, appliquer un label de confidentialité et mettre un fichier en quarantaine ? » De nombreuses plateformes DSPM présentent les mesures correctives comme une fonctionnalité, mais se contentent en réalité de formuler une recommandation qu’un utilisateur doit ensuite appliquer manuellement depuis une console distincte.
Concernant les frais d'exploitation : « Après le déploiement initial, combien d'heures ETP par semaine un client type de notre taille consacre-t-il au réglage de la classification, au tri des faux positifs, à l'ajustement des règles et à la maintenance de l'intégration ? L'assistance au réglage est-elle incluse ou s'agit-il de services professionnels facturés en supplément ? » Le coût total de possession d'un DSPM est principalement constitué des coûts d'exploitation, et non des frais de licence.
Harmonisation des exigences des parties prenantes
Une évaluation DSPM échoue lorsqu’elle privilégie les priorités d’une partie prenante au détriment des autres. Chaque membre de votre comité d’évaluation apporte un point de vue différent, et le cadre de notation doit tenir compte de chacun d’entre eux.
Responsable de la sécurité des systèmes d'information (RSSI) : rapports sur les risques et communication avec le conseil d'administration
Le RSSI a besoin d’une solution DSPM capable de générer des rapports sur les risques destinés à la direction — non seulement des conclusions techniques, mais aussi des données sur les tendances indiquant si le niveau de sécurité des données s’améliore ou se détériore au fil du temps. Évaluez si la plateforme est capable de générer des synthèses prêtes à être présentées au conseil d’administration, qui traduisent les indicateurs d’exposition des données en termes de risques métier. Demandez si la notation des risques peut être segmentée par unité opérationnelle, type de données ou domaine réglementaire, afin que le RSSI puisse rendre compte de la posture selon les critères qui importent au conseil d’administration. Une plateforme DSPM qui fournit d’excellents résultats techniques mais qui ne parvient pas à les agréger en analyses stratégiques des risques ne répondra pas aux besoins du RSSI.
DPO : Preuves de conformité et préparation à l'audit
Le délégué à la protection des données (DPD) a besoin que le DSPM serve de moteur de preuve de conformité. Évaluez les cadres réglementaires intégrés pour le RGPD, le CCPA, la loi HIPAA, la norme PCI DSS et toute réglementation sectorielle à laquelle votre organisation est soumise. Vérifiez si la plateforme est capable de générer des rapports prêts pour l’audit, mettant en correspondance les résultats d’analyse des données avec des exigences réglementaires spécifiques — il ne s’agit pas seulement d’un tableau de bord de conformité, mais de preuves exportables qu’un auditeur peut suivre de la constatation au contrôle, puis à la correction. Le DPD aura également besoin d’un soutien pour traiter les demandes d’accès des personnes concernées : la plateforme DSPM est-elle capable de localiser toutes les occurrences des données d’une personne spécifique dans l’ensemble des référentiels analysés ?
Ingénieur en sécurité cloud : couverture des API et automatisation
L’ingénieur en sécurité cloud évalue si le DSPM s’intègre aux workflows existants d’« infrastructure-as-code » et d’automatisation de la sécurité. Il a besoin d’une couverture complète des API : pas seulement une API REST pour récupérer les résultats, mais aussi la possibilité de déclencher des analyses, de mettre à jour les politiques et d’exécuter des mesures correctives par programmation. Évaluez la prise en charge des webhooks, la disponibilité des fournisseurs Terraform ou Pulumi, ainsi que l’intégration dans les pipelines CI/CD. L’ingénieur accorde également de l’importance aux performances des analyses : combien de temps dure une analyse incrémentielle, quelle est la limitation de débit de l’API, et l’architecture d’analyse s’adapte-t-elle horizontalement à mesure que les volumes de données augmentent ?
Achats : coût total de possession
Le service des achats doit modéliser le coût total de possession (TCO) au-delà du simple coût de la licence. Les modèles de tarification DSPM varient considérablement : par base de données, par To analysé, par utilisateur, par résultat, forfait de plateforme ou modèles hybrides. Demandez aux fournisseurs une ventilation détaillée des tarifs correspondant à l’échelle que vous envisagez, incluant les frais de dépassement, les frais supplémentaires liés aux connecteurs, les services professionnels pour le déploiement et le réglage, ainsi que les conditions d’augmentation des tarifs lors du renouvellement. Modélisez le coût total de possession (TCO) sur trois ans en incluant les coûts opérationnels internes (heures ETP consacrées à l’administration, au réglage et au triage). Une solution DSPM dont la licence coûte 30 % moins cher mais qui nécessite un investissement en ETP deux fois plus important n’est pas l’option la plus économique.
Erreurs courantes commises par les acheteurs
Acheter en se basant uniquement sur la diversité de l'offre
L'erreur d'évaluation la plus courante consiste à classer les fournisseurs principalement en fonction du nombre de référentiels de données qu'ils sont capables d'analyser. L’étendue de la découverte est un critère de base : presque tous les fournisseurs de solutions DSPM d’entreprise couvrent les principaux fournisseurs IaaS, M365, Google Workspace et les plateformes de bases de données courantes. Ce qui différencie les fournisseurs, c’est la profondeur de la classification, la contextualisation des risques et la capacité de correction. Une évaluation accordant plus de 40 % de pondération à la découverte sélectionnera le fournisseur disposant de la liste de connecteurs la plus longue, ce qui ne correspond pas nécessairement au fournisseur offrant les meilleurs résultats en matière de sécurité.
Sauter la phase de validation (POC) avec des données réelles
Réaliser une démonstration de faisabilité (POC) à partir de données synthétiques ou d’un environnement de test « propre » n’apporte guère plus d’informations que de regarder une démonstration. Les données réelles présentent des classifications désordonnées, des contenus ambigus se situant à la frontière entre les informations sensibles et non sensibles, ainsi que des structures d’autorisations dont la complexité s’est accumulée au fil des années. Les fournisseurs en sont conscients ; c’est pourquoi certains vous déconseilleront de vous connecter à des environnements de production pendant la phase d’évaluation. Insistez pour obtenir une démonstration de faisabilité en environnement de production. Un fournisseur qui ne parvient pas à obtenir de bons résultats avec vos données réelles ne le fera pas non plus après votre achat.
Ne pas tenir compte des frais généraux d'exploitation
Le coût de la licence est le chiffre le plus visible dans un projet d’acquisition de DSPM, mais le coût opérationnel — les heures ETP consacrées au réglage, au triage, à la gestion des règles et à la maintenance de l’intégration — représente généralement deux à trois fois le coût de la licence sur une période de trois ans. Évaluez clairement la charge opérationnelle : quel niveau de réglage est nécessaire pour atteindre une précision de classification acceptable, combien de faux positifs votre équipe devra-t-elle traiter chaque jour, et quel niveau d’expertise est requis pour gérer la plateforme ?
Considérer le DSPM comme un système autonome
Le DSPM ne fonctionne pas de manière isolée. Son efficacité est renforcée ou réduite en fonction de la qualité de son intégration à votre architecture de sécurité globale. La Cloud Security Alliance souligne qu’une mise en œuvre efficace du DSPM tire parti d’une plateforme SSE offrant des fonctionnalités complémentaires telles que le CSPM, le SSPM, l’UEBA et la surveillance des activités en temps réel. Évaluez chaque fournisseur de DSPM au regard de votre infrastructure existante : cette solution complète-t-elle votre DLP ou fait-elle double emploi avec celle-ci ? Peut-elle transmettre ses résultats à votre CASB en vue de leur mise en œuvre ? Enrichit-elle votre SIEM avec des données contextuelles ou se contente-t-elle d'augmenter le volume d'alertes ?
Sous-estimation de l'importance de la gouvernance des données d'IA
À mesure que les organisations déploient des outils d’IA générative, des « copilotes » et des pipelines RAG, les exigences en matière de gouvernance des données s’étendent au-delà des catégories traditionnelles de conformité. Un DSPM qui se contente de classer les données selon les taxonomies PII/PHI/PCI risque de ne pas tenir compte de la nouvelle exigence consistant à identifier et à gouverner les données alimentant les ensembles d’entraînement de l’IA, les pipelines de réglage fin et les référentiels de génération augmentée par la recherche. Vérifiez si le DSPM est capable de détecter l’exposition de données sensibles aux services d’IA et si sa taxonomie de classification est suffisamment extensible pour couvrir les exigences de gouvernance spécifiques à l’IA.
Structuration du processus d'évaluation
Un processus d'évaluation rigoureux permet d'éviter les dérives de périmètre et les orientations erronées dictées par les fournisseurs.
Semaines 1 à 2 : Définition des exigences. Constituez votre comité d’évaluation (RSSI ou son représentant, délégué à la protection des données, ingénieur en sécurité cloud, service des achats). Distinguez les fonctionnalités indispensables de celles qui constituent un atout supplémentaire. Adaptez le barème de notation pondéré en fonction des priorités de votre organisation. Mettez en place l’environnement de démonstration de faisabilité (POC) et le jeu de données de référence.
Semaines 3 à 4 : Appel d'offres et présélection. Lancez des appels d'offres ciblés en vous appuyant sur les questions destinées aux fournisseurs figurant dans ce guide. Évaluez les réponses écrites en fonction de vos critères pondérés. Sélectionnez trois à quatre fournisseurs pour les démonstrations.
Semaines 5 à 6 : Démonstrations structurées. Organisez les démonstrations en suivant une liste de scénarios standardisés, et non le script de démonstration privilégié par le fournisseur. Exigez de chaque fournisseur qu’il présente les mêmes cas d’utilisation : gestion des autorisations M365, création d’un classificateur personnalisé, exécution des mesures correctives et intégration SIEM.
Semaines 7 à 10 : Validation du concept. Soumettez simultanément les deux fournisseurs finalistes à une validation du concept en conditions réelles. Évaluez les performances de cette validation du concept par rapport aux critères pondérés à l'aide des données mesurées : précision de classification, taux de faux positifs, performances d'analyse et temps de réponse pour la correction.
Semaines 11 à 12 : Notation finale, négociation et décision. Calculer les notes globales de l’ensemble des évaluateurs. Présenter la matrice de notation aux responsables de projet, accompagnée d’une recommandation claire. Négocier les conditions du contrat avec le prestataire retenu, en utilisant les données de performance issues de la démonstration de faisabilité (POC) comme levier pour définir les accords de niveau de service (SLA).