Qu'est-ce qu'un audit de sécurité SaaS ?
Un audit de sécurité SaaS évalue les surfaces propres à un logiciel multi-tenant : isolation des données entre clients, rôles et privilèges, portail et back-office, SSO et cycle de vie des accès, et workflows métier sensibles. L'objectif est d'identifier les vulnérabilités qui exposent les données d'un client à un autre ou bloquent une vente.
Le piège classique : auditer « le SaaS » sans découper les surfaces
Beaucoup de produits B2B mélangent une promesse simple côté vente avec une réalité plus complexe côté sécurité : rôles multiples, tenants, comptes invités, support, exports, intégrations tierces et dépendances d'authentification.
Si le cadrage de mission reste trop large, le rapport devient descriptif. Si le cadrage est trop étroit, il manque justement les points qui inquiètent les clients : cloisonnement, comptes à privilège, parcours critiques et effets de bord entre front, API et back-office.
Les surfaces qui doivent presque toujours entrer dans le cadrage
- Isolation tenant et séparation des données entre comptes.
- Rôles, permissions, comptes support et droits exceptionnels.
- Portail client, back-office et parcours sensibles côté front.
- SSO, provisioning, désactivation et cycle de vie des accès.
- Workflows métier à impact élevé : validation, export, signature, facturation.
Relier chaque surface à un scénario et à une preuve
Cette matrice illustrative aide à préparer le périmètre. Les comptes, données et opérations doivent être convenus avec votre équipe ; elle ne décrit pas un cas client ni une couverture universelle.
| Surface | Scénario | À préparer | Preuve attendue |
|---|---|---|---|
| Isolation client | Accès du tenant A à un objet du tenant B | Deux tenants et des objets fictifs | Résultats des tests autorisés et refusés |
| Comptes support | Export ou modification hors du rôle convenu | Compte support et matrice de droits | Opérations vérifiées et état des objets |
| Portail et back-office | Validation d'un document avec un compte lecteur | Comptes lecteur et gestionnaire | Contrôles de rôle sur le front et l'API |
| SSO et sessions | Réutilisation d'un accès après désactivation | Fournisseur d'identité de test et règle de révocation | Délais et résultats observés |
| Workflow métier | Validation répétée ou changement d'état non prévu | Parcours, règles et limites d'essai | Effet métier et recommandations vérifiables |
Par exemple, un export réservé au support ne doit pas permettre à un lecteur de récupérer les données d'un autre client. Le test vérifie le droit attendu, les données réellement retournées et la correction du constat si un contre-test est prévu.
Ce qu'un acheteur ou un client va regarder
Dans un contexte B2B, la sécurité du SaaS n'est pas évaluée seulement pour « faire bien ». Elle est reliée à une décision d'achat, à une clause contractuelle, à un questionnaire sécurité ou à une assurance cyber.
Les questions reviennent toujours autour des mêmes thèmes : un tenant peut-il voir ou agir sur les données d'un autre ? Les comptes support ont-ils des droits trop larges ? Que se passe-t-il quand un utilisateur est désactivé dans le SSO ? Le portail client permet-il des exports ou validations trop permissifs ?
Un audit utile doit donc être lisible côté direction, mais assez précis pour reconnecter chaque constat à une surface métier identifiable.
Quand passer à un audit SaaS dédié
C'est le bon choix quand votre produit ne se résume plus à un simple site web : clients actifs dans le portail, rôles multiples, données sensibles, back-office opérationnel, API riche ou pression commerciale forte sur la preuve de sécurité.
Dans ces cas-là, un audit dédié évite de disperser le budget et permet de produire des constats plus utiles pour le produit, la vente et la relation client. Voir la page service audit SaaS.
Ce que l'architecture change au périmètre d'audit
Le périmètre ne se déduit pas du produit vendu mais de son architecture. Chez un éditeur qui héberge plusieurs clients sur une même instance, le point de contrôle est le cloisonnement multi-tenant et la gestion des droits internes. Sur une plateforme ouverte à des intégrateurs tiers, il se déplace vers l'API, les portées des jetons et le cycle de vie des autorisations déléguées. Sur une application B2B à rôles multiples, ce sont les parcours métier et le back-office d'administration qui concentrent le risque.
Cet article couvre l'audit, c'est-à-dire l'examen du dispositif de sécurité et de ses écarts. Si votre besoin est l'exécution offensive sur le produit lui-même, le sujet est traité en détail dans pentest SaaS B2B : les 6 surfaces critiques à tester. Le détail des livrables et du cadrage commercial est sur la page service audit SaaS.
Questions fréquentes sur l'audit de sécurité SaaS
Audit de sécurité SaaS ou pentest : quelle différence ?
Un audit de sécurité SaaS désigne l'évaluation globale des surfaces d'un produit multi-tenant, et s'appuie le plus souvent sur un test d'intrusion (pentest) pour prouver l'exploitabilité réelle des failles. Le pentest est la composante offensive de l'audit : il vérifie concrètement qu'un tenant ne peut pas accéder aux données d'un autre, qu'un compte support n'a pas de droits excessifs, ou qu'un parcours métier ne contourne pas un contrôle.
Combien coûte un audit de sécurité SaaS ?
Le prix dépend du périmètre réel : nombre de rôles et de tenants, richesse de l'API, présence d'un back-office, intégrations tierces et workflows sensibles. Plutôt qu'une grille forfaitaire qui ne colle jamais au produit, le tarif est établi sur devis après un diagnostic de cadrage qui délimite les surfaces à tester.
Quelles surfaces faut-il tester en priorité sur un SaaS B2B ?
Les quatre surfaces qui créent le plus de risque commercial et contractuel sont l'isolation entre tenants (un client peut-il voir les données d'un autre ?), les rôles et comptes à privilège (support, admin, comptes exceptionnels), le cycle de vie des accès via le SSO (que se passe-t-il à la désactivation ?), et les workflows métier à fort impact (export, validation, facturation, signature).
Un audit SaaS aide-t-il à répondre à un questionnaire sécurité client ou à NIS2 ?
Oui. Un rapport d'audit récent, avec preuves et plan de remédiation, est exactement ce qu'un acheteur B2B, un assureur cyber ou un questionnaire de due diligence attendent. Il sert de preuve dans une revue fournisseur et alimente les exigences de gestion des risques liées à NIS2 ou DORA pour les sous-traitants concernés.
Pour approfondir : Cloud Security Alliance : matrice des domaines de contrôle attendus sur un service cloud.