SSPM : sécuriser la posture de sécurité de vos SaaS

Ce guide s’adresse aux responsables IT et sécurité d’entreprises de 50 à 500 collaborateurs à qui l’on vient de demander qui a accès à quoi dans le parc SaaS.

Le SSPM (SaaS Security Posture Management) est une catégorie d’outils de sécurité qui évalue en continu le risque des applications SaaS et pilote leur configuration, leurs permissions et leur conformité. Gartner le définit dans son architecture de référence de sécurité cloud comme un outil qui « évalue en continu le risque de sécurité d’une application SaaS et gère sa posture de sécurité » (Gartner, 25 novembre 2025). Concrètement, un SSPM surveille cinq choses : les paramètres des applications, les permissions des utilisateurs, les connexions applicatives tierces, le partage de données et les preuves de conformité. La plupart des entreprises de moins de 500 salariés n’achètent pas un SSPM dédié en premier. Elles reprennent d’abord le contrôle de la couche identité et accès, parce que c’est là que l’exposition se concentre et que la remédiation est réellement à portée de l’équipe en place.

Si vous exploitez déjà une plateforme de sécurité SaaS dédiée avec une personne affectée au traitement de ses alertes, ce guide sera trop introductif. Il est écrit pour l’étape d’avant, quand la question est de savoir quoi acheter, dans quel ordre, et si c’est même nécessaire.

Qu’est-ce que le SSPM (SaaS Security Posture Management) ?

Le SSPM est l’évaluation et la correction continues de la façon dont vos applications SaaS sont configurées, de qui peut y accéder, de ce que ces utilisateurs peuvent y faire, et des preuves que vous êtes capable de produire à ce sujet. Il existe parce que le SaaS a déplacé le contrôle des paramètres de sécurité : ce n’est plus l’équipe infrastructure qui décide, c’est l’administrateur de chaque application, c’est-à-dire dans une entreprise en croissance un responsable marketing pour le CRM, un responsable financier pour l’outil de facturation, et personne en particulier pour les onze applications arrivées par un essai gratuit.

La catégorie a été nommée par Gartner en 2019 et s’est stabilisée autour de cinq piliers fonctionnels. Chaque éditeur les nomme à sa façon, le tableau ci-dessous s’en tient donc à la définition fonctionnelle plutôt qu’au vocabulaire d’un fournisseur.

Pourquoi la définition compte plus que l’acronyme

Chaque glossaire d’éditeur positionné sur cette requête définit le SSPM comme ce que cet éditeur vend. Palo Alto Networks le cadre autour de la configuration, Netskope autour de l’application des politiques, Zluri autour du choix d’outil. La définition fonctionnelle ci-dessus est volontairement neutre, parce que la décision d’achat qui suit dépend entièrement du pilier qui est en défaut chez vous. Une entreprise dont le problème est celui des comptes orphelins n’a pas besoin du même produit qu’une entreprise dont le problème est le partage public de fichiers.

SSPM, CASB, CSPM et SMP : ce que chacun couvre réellement

Ces quatre acronymes sont régulièrement présentés comme concurrents. Ils ne le sont pas. Ils surveillent des objets différents, et l’architecture de référence de sécurité cloud de Gartner les liste comme des composants distincts d’une même architecture, pas comme des alternatives.

La confusion la plus coûteuse est celle entre CSPM et SSPM. Ils partagent un mot et rien d’autre. Le CSPM sécurise les serveurs, les buckets de stockage et les réseaux déployés par votre équipe technique. Le SSPM sécurise les applications auxquelles vos collaborateurs se connectent. Acheter un CSPM parce qu’une recherche sur la gestion de posture a remonté des éditeurs d’infrastructure cloud est une erreur fréquente et chère dans les entreprises qui n’exploitent presque aucune infrastructure en propre. En France, l’écart de demande entre les deux termes entretient d’ailleurs le malentendu : « cspm » pèse 590 recherches mensuelles quand « saas security posture management » en pèse 20 (DataForSEO, août 2026).

La quatrième ligne est celle que les leaders de la catégorie omettent. Dans son guide d’architecture de sécurité cloud, Gartner place les plateformes de SaaS Management à côté du SSPM et leur attribue le contrôle des fonctions de sécurité et la cohérence de la gouvernance entre fournisseurs. C’est un composant distinct, avec son propre mandat, et c’est la porte d’entrée que prennent la plupart des équipes de taille intermédiaire, parce que l’inventaire et le cycle de vie des accès doivent exister avant qu’un référentiel de configuration ait le moindre sens.

Pourquoi l’identité est le pilier qui cède en premier

La dérive de configuration est lente. Un réglage de partage erroné en janvier l’est encore en juin, exactement de la même façon. La posture d’identité, elle, se dégrade en continu, parce qu’elle est réécrite par chaque recrutement, chaque mobilité interne, chaque départ et chaque inscription à un essai gratuit.

Trois mécanismes font l’essentiel des dégâts :

• Les comptes hors du fournisseur d’identité. Le SSO couvre les applications qui y ont été raccordées. Les outils achetés sur carte bancaire par un responsable d’équipe ne l’ont jamais été : désactiver le compte dans l’annuaire ne les ferme pas.
• L’accumulation de privilèges. Quelqu’un reçoit des droits d’administration pour une migration et les conserve trois ans. Le principe du moindre privilège est facile à énoncer et impossible à tenir sans revue récurrente.
• Les autorisations OAuth que personne n’a validées. Un collaborateur connecte un assistant de prise de notes à l’agenda et à la messagerie de l’entreprise. L’autorisation est permanente, elle survit au collaborateur, et elle n’apparaît dans aucun état de licences puisqu’elle est gratuite.

C’est la forme concrète du problème chez APGAR, cabinet de conseil de 280 personnes exploitant plus de 80 outils SaaS, qui s’est fixé pour objectif d’améliorer sa posture de sécurité en reprenant le contrôle des applications et des outils d’IA non autorisés utilisés via le navigateur. Jean-Marie Drucot, IT Manager et RSSI, le formule sans détour : « Techniquement, je ne sais pas comment je ferais mon travail aujourd’hui sans Corma. Corma m’aide énormément sur tous les aspects de détection applicative et de gestion automatique. » (cas client Corma, APGAR).

L’échelle change l’arithmétique, pas le mécanisme. Brevo compte environ 1 000 collaborateurs et plus de 400 actifs logiciels, et a automatisé plus de 400 onboardings et offboardings avec Corma (cas client Corma, Brevo). À ce volume, un processus d’arrivées et de départs manuel n’est pas un risque à surveiller, c’est un stock garanti de comptes restés ouverts.

Si c’est dans cette section que vous avez reconnu votre propre environnement, le point de départ pratique est la couche identité et accès plutôt qu’un scanner de configuration : voir comment Corma accompagne les équipes de sécurité sur les accès SaaS et la conformité.

Le pilier que la catégorie n’a pas rattrapé : les identités non humaines

Le modèle à cinq piliers a été conçu pour un parc où chaque compte appartenait à une personne. Cette hypothèse a cédé en 2025 et 2026. Comptes de service, clés d’API, utilisateurs techniques d’intégration et désormais agents IA détiennent des accès permanents à des données de production, et ils échappent aux contrôles pensés pour les salariés : ils n’apparaissent dans aucun SIRH, ils ne sont pas offboardés, et ils ne consomment pas de siège de licence que la direction financière remarquerait.

C’est là que le contenu existant sur le SSPM laisse l’acheteur seul. Mesuré par script sur le texte rendu des cinq pages éditoriales classées dans le top 20 sur cette requête en août 2026, la shadow AI est mentionnée sur une page sur cinq et les identités non humaines sur trois, toujours en passant et jamais avec un contrôle applicable. Or chez APGAR, le déclencheur du projet de posture a été précisément les outils d’IA utilisés via le navigateur, qui échappent à la supervision classique parce qu’ils ne créent de compte dans aucun système de référence.

Trois contrôles s’appliquent ici, et tous les trois relèvent du pilier identité plutôt que du pilier configuration :

• Inventorier les identités non humaines au même titre que les identités humaines, avec un propriétaire et une date d’expiration pour chacune. Une clé d’API sans propriétaire est un compte orphelin doté de plus de privilèges que la plupart des salariés.
• Traiter la connexion d’un assistant IA comme une attribution d’accès, pas comme un outil de productivité. Connecté à une messagerie ou à une base documentaire, l’assistant hérite durablement de la portée de lecture de cet utilisateur.
• Intégrer les agents à la revue des accès. Si la revue trimestrielle ne liste que des personnes, elle certifie une fraction de la surface d’accès réelle, et l’attestation devient trompeuse plutôt qu’incomplète.

Votre entreprise a-t-elle vraiment besoin d’un SSPM dédié ?

Pas nécessairement, et la réponse honnête dépend de deux variables : combien d’applications hébergent des données réglementées ou sensibles, et si quelqu’un est responsable de leur configuration.

Un SSPM dédié se justifie quand vous exploitez quelques applications profondes et fortement paramétrées, typiquement un CRM, un ERP et une suite collaborative, chacune dotée de centaines de réglages de sécurité, et qu’au moins une personne a dans sa fiche de poste le traitement des alertes produites. En dessous, les alertes deviennent une seconde boîte de réception que personne ne lit, ce qui est pire qu’aucun outil, puisque cela produit la paperasse de la sécurité sans son effet.

Microsoft Defender ne le fait-il pas déjà ?

En partie, et c’est l’objection la plus fréquente des équipes sous Microsoft 365. Microsoft Defender for Cloud Apps embarque des capacités de gestion de posture de sécurité SaaS et, sur un parc centré Microsoft couvrant les applications principales, cela peut suffire pour le pilier configuration. Ce que l’outil natif ne couvre pas, c’est la longue traîne : les applications achetées hors IT, les outils gratuits ouverts avec une adresse professionnelle, et les assistants IA connectés en OAuth. Cette traîne est précisément l’habitat du shadow IT et de la shadow AI, et elle est invisible pour un outil qui n’inspecte que des applications qu’il connaît déjà.

Ce que le SSPM ne fait pas

Les pages de catégorie énoncent rarement les limites, les voici :

• Il ne découvre pas les applications pour lesquelles il n’a pas de connecteur. La couverture de votre parc précis compte infiniment plus que le nombre total de connecteurs affiché par un éditeur.
• Il ne décide pas qui doit avoir accès. Il rapporte l’état courant. La décision suppose un propriétaire nommé par application.
• Il ne remplace pas un fournisseur d’identité, et il ne provisionne ni ne déprovisionne les utilisateurs sauf s’il embarque aussi la gestion du cycle de vie des identités.
• Il n’empêche pas un utilisateur légitime muni d’identifiants valides de commettre un acte nuisible. Cela relève de la détection et de la réponse, une autre ligne budgétaire.

Ce que NIS2 et le RGPD exigent réellement de votre posture SaaS

Les résultats de recherche sur ce sujet sont écrits pour un acheteur américain. Sur les cinq pages éditoriales classées dans le top 20 sur cette requête en août 2026, les termes NIS2, Europe et résidence des données apparaissent zéro fois au total, mesuré par script sur le texte rendu. L’acheteur européen reçoit donc une réponse conçue pour un autre environnement réglementaire.

Le texte réglementaire est plus utile que le contenu des éditeurs, et il ne mentionne jamais le SSPM. L’article 21(2) de la directive (UE) 2022/2555 fixe des mesures minimales de gestion des risques en cybersécurité. Trois d’entre elles retombent directement sur la posture SaaS.

L’outil de posture devient lui-même un sous-traitant sensible

Il existe une seconde considération européenne qu’aucun glossaire d’éditeur ne soulève, et elle mérite une question directe pendant toute évaluation. Un outil de gestion de posture a besoin d’un accès API privilégié, souvent de niveau administrateur, à chaque application que vous y raccordez. Il devient donc l’un des traitements les plus sensibles de votre parc, et au sens du RGPD un sous-traitant ultérieur détenant des métadonnées sur chaque salarié et chaque application.

L’article 28(2) du RGPD est explicite : le sous-traitant ne recrute pas un autre sous-traitant sans autorisation écrite préalable, spécifique ou générale, du responsable du traitement. Autrement dit, l’hébergement et la chaîne de sous-traitance de votre outil de posture ne sont pas un détail technique, ce sont des éléments contractuels que la CNIL peut vous demander de documenter. Posez trois questions : où les données sont stockées, sous quelle juridiction, et quelle certification étaye la réponse. Corma héberge ses serveurs web et ses bases de données dans des centres de données situés dans l’Union européenne et est certifié ISO/IEC 27001:2022, avec un audit indépendant annuel.

Si NIS2 est la raison pour laquelle ce chantier a atterri sur votre bureau, la checklist de conformité NIS2 pour les équipes IT couvre les obligations plus larges au-delà de la posture SaaS.

Sécuriser sa posture de sécurité SaaS en six étapes

Cette séquence suppose qu’aucun outil dédié n’est en place au départ et suit l’ordre qui produit des preuves le plus vite.

1. Construire l’inventaire réel. Pas la liste des applications connues de la DSI, mais celle dérivée des journaux du SSO, des dépenses sur carte et facture, et de la découverte au niveau du navigateur. Attendez-vous à un chiffre réel deux à trois fois supérieur au chiffre attendu.
2. Nommer un propriétaire par application. Chaque application reçoit un propriétaire métier identifié, responsable de ses réglages et de sa liste d’utilisateurs. Sans cela, aucune étape suivante n’a de destinataire.
3. Fixer le socle d’identité. Pour chaque application : est-elle derrière le SSO, la MFA est-elle imposée, qui détient les droits d’administration, et comment les comptes sont-ils fermés au départ. Traitez d’abord les dix applications les plus sensibles en données.
4. Revoir les autorisations tierces. Exportez les autorisations OAuth sur vos plateformes d’identité et de collaboration principales, révoquez ce qui n’a pas de propriétaire, et instaurez un circuit d’approbation pour que la prochaine soit une décision et non une découverte.
5. Exécuter des revues d’accès à date fixe. Trimestrielles sur les applications sensibles, au minimum annuelles ailleurs, déléguées au propriétaire de l’application plutôt que centralisées sur la DSI. Voir comment mener des revues d’accès automatisées et conformes sans tableur.
6. Conserver la preuve comme sous-produit. Chaque revue doit laisser un enregistrement exportable indiquant qui a revu quoi, quand, et ce qui a été retiré. La preuve reconstituée après coup est la partie la plus coûteuse d’un audit.

Les étapes un, deux, trois et cinq sont atteignables avec une plateforme de SaaS Management et d’identité. L’étape quatre l’est partiellement. La mise en référentiel des configurations, sur des centaines de réglages par application, est le terrain où un SSPM dédié devient le bon instrument.

Ce que couvre Corma, et ce qu’il ne couvre pas

Corma est une plateforme européenne de SaaS Management et de gestion des identités, pas un scanner de configuration. Elle couvre les piliers qui cèdent en premier et produit les preuves attendues par les auditeurs, et elle assume la frontière.

Trois éléments méritent d’être confrontés à toute alternative que vous évaluez. Corma expose sur son site public des pages d’intégration dédiées pour 282 applications distinctes, vérifié sur le sitemap live le 16 août 2026, ce qui est un signal de couverture plus utile qu’un chiffre marketing arrondi. La plateforme est reconnue au Gartner Magic Quadrant pour les SaaS Management Platforms en 2026, pour la deuxième année consécutive, soit le composant même que Gartner place à côté du SSPM dans son architecture de sécurité cloud. Et elle héberge les données dans l’Union européenne sous certification ISO/IEC 27001:2022, ce qui compte d’autant plus que l’outil détiendra la cartographie des accès de toute votre entreprise.

Capacités associées : SaaS Management, gestion des identités et des accès, détection de la shadow IA et gouvernance des identités automatisée. Pour voir la cartographie des accès de votre propre parc, demandez une démo.

Questions fréquentes

Qu’est-ce que le SSPM en termes simples ?

Le SSPM est un outillage qui vérifie en continu comment vos applications SaaS sont configurées, qui peut y accéder et ce que ces utilisateurs peuvent y faire, puis signale ce qui sort de votre politique. Il porte sur les applications utilisées par vos collaborateurs, pas sur l’infrastructure cloud déployée par vos équipes techniques.

Quelle est la différence entre SSPM et CASB ?

Un CASB se place sur ou à côté du chemin réseau et inspecte les données qui circulent vers et depuis les services cloud. Un SSPM se connecte à chaque application via son API et inspecte les paramètres internes, les permissions et les applications connectées. Le CASB voit le trafic, le SSPM voit la configuration.

Quelle est la différence entre SSPM et CSPM ?

Le CSPM sécurise l’infrastructure en environnement IaaS et PaaS comme AWS, Azure et Google Cloud, en couvrant machines virtuelles, stockage et réseaux. Le SSPM sécurise les applications SaaS auxquelles vos collaborateurs se connectent, en couvrant paramètres, rôles et permissions. Les entreprises qui exploitent peu d’infrastructure en propre relèvent du SSPM, pas du CSPM.

Les PME et ETI ont-elles besoin d’un SSPM ?

Elles ont besoin de maîtriser leur posture SaaS, ce qui n’est pas la même chose qu’acheter un produit SSPM dédié. En dessous d’environ 500 salariés, le travail au meilleur rendement reste l’inventaire applicatif complet, un propriétaire par application, la couverture SSO et MFA, et des revues d’accès récurrentes. Un SSPM dédié devient pertinent quand plusieurs applications fortement paramétrées hébergent des données sensibles et que quelqu’un est responsable des alertes.

NIS2 impose-t-elle un SSPM ?

Non. La directive (UE) 2022/2555 ne nomme jamais cette catégorie. Son article 21(2) impose des mesures minimales, dont la sécurité de la chaîne d’approvisionnement, les politiques de contrôle d’accès, la gestion des actifs et l’authentification multifacteur. Elles peuvent être satisfaites avec une plateforme de SaaS Management et d’identité, avec un SSPM dédié, ou avec un processus manuel documenté, à condition que la preuve existe.

Le SSPM et le SaaS Management, est-ce la même chose ?

Non. Gartner liste la gestion de posture de sécurité SaaS et les plateformes de SaaS Management comme deux composants distincts de son architecture de référence de sécurité cloud. Le SSPM évalue le risque et la posture de sécurité des applications. Une plateforme de SaaS Management gouverne l’inventaire, les licences, la dépense et le cycle de vie des accès, et Gartner lui attribue le contrôle des fonctions de sécurité et la cohérence de la gouvernance entre fournisseurs.

À quelle fréquence mener les revues d’accès SaaS ?

Trimestrielle pour les applications qui hébergent des données sensibles ou réglementées, annuelle au minimum pour les autres. Les auditeurs ISO 27001 et SOC 2 cherchent une cadence documentée et réellement tenue, avec la preuve de ce qui a été retiré, plutôt qu’une fréquence particulière.