Analyse de risques : relier scénarios SaaS et mesures de traitement

Publié et mis à jour le 1 octobre 2026 · Rédaction : Scope & Evidence

Une analyse de risques SaaS commence par des scénarios qui affectent votre service et vos clients. Elle ne consiste pas à copier une liste de menaces puis à donner la même note à chaque ligne. Le CTO décrit les systèmes et les conséquences possibles ; la direction arbitre les traitements et l’acceptation des risques résiduels. La méthode doit être cohérente avec votre périmètre et assez explicite pour que deux responsables puissent discuter une même évaluation.

Cadre de référence : source primaire du sujet. Les recommandations opérationnelles ci-dessous sont à adapter à votre organisation.

Définir ce que vous protégez

Identifiez les informations et les activités importantes : accès client, données hébergées, code, facturation ou capacité de rétablir le service. Précisez les conséquences d’une perte de confidentialité, d’intégrité ou de disponibilité dans votre contexte. Les engagements envers les grands comptes aident à comprendre les impacts, mais ne remplacent pas l’examen de vos opérations. Distinguez les actifs dont vous maîtrisez l’administration et les dépendances externes. Associez chaque objet à un responsable capable de décrire son usage.

Écrire des scénarios exploitables

Un scénario doit relier un événement, une faiblesse ou une exposition, puis une conséquence. Par exemple, un jeton de déploiement trop permissif pourrait être utilisé pour modifier un environnement de production. Il faut ensuite examiner les protections existantes et les traces disponibles. Une simple ligne « cyberattaque » ne permet pas de choisir un traitement. Utilisez des scénarios réalistes pour votre architecture, sans prétendre estimer un taux d’attaque à partir d’un panorama national ou européen.

Fixer les critères avant de noter

Définissez comment vous comparez les impacts et la vraisemblance. Les échelles peuvent être qualitatives si leurs niveaux sont expliqués. Notez les hypothèses et les limites des informations disponibles. Évitez les calculs qui donnent une précision artificielle à des estimations peu documentées. La cohérence entre scénarios importe davantage qu’un chiffre décoratif. Faites valider les critères d’acceptation par les personnes autorisées à décider, et conservez cette validation pour les prochaines revues.

Relier les traitements aux décisions

Un traitement doit avoir un responsable, une action et un moyen de constater son exécution. Pour le jeton de déploiement, vous pourriez limiter les droits, modifier sa gestion et tester les autorisations. Ce sont des propositions de travail à adapter, pas une prescription universelle. Comparez le risque après traitement avec vos critères. Si un risque reste accepté, documentez qui décide et pourquoi. Le consultant peut aider à structurer la décision, mais ne l’assume pas à la place de votre direction.

Faire vivre le registre

Réexaminez les scénarios lorsque le produit, les fournisseurs ou les engagements changent. Utilisez les incidents et les exercices pour corriger les hypothèses. Un registre inchangé alors que l’architecture a évolué mérite une revue. Les publications de menace peuvent fournir des pistes, mais elles ne mesurent pas directement votre exposition. Gardez la version précédente et la raison des changements pour expliquer les décisions. Les mesures retenues peuvent ensuite alimenter votre déclaration d’applicabilité et votre programme de contrôle.

Séparer les incertitudes des décisions

Un scénario peut reposer sur une information encore inconnue, par exemple la capacité d’un fournisseur à poursuivre son support pendant une panne. Gardez cette hypothèse visible et attribuez une action de recherche. Ne remplacez pas l’incertitude par une note favorable pour fermer le registre. La direction peut décider un traitement provisoire en attendant la réponse. Lorsque l’information arrive, réexaminez le scénario et conservez la raison du changement. Cette traçabilité rend l’analyse plus utile qu’une matrice dont les valeurs ne peuvent plus être expliquées.

Exemple de travail, fictif

Exemple fictif : un SaaS dépend d’un seul fournisseur d’identité pour l’administration et le support. Le CTO décrit un scénario d’indisponibilité empêchant l’intervention pendant une panne. L’équipe examine les accès de secours, leurs protections et les essais réalisés. La direction choisit un traitement et valide le risque résiduel avec ses hypothèses. Aucun objectif de disponibilité ni probabilité chiffrée n’est inventé ; ces valeurs doivent provenir des besoins et de l’analyse de l’éditeur.

Ce que votre dossier doit permettre de vérifier

Des actifs et activités reliés au périmètre du SaaS.
Des scénarios reliant exposition, événement et conséquence.
Des critères d’évaluation et d’acceptation compris par les décideurs.
Un plan de traitement avec responsables et preuves d’exécution.
Une revue déclenchée par les changements, incidents ou exercices.

Questions avant de décider

Faut-il utiliser une méthode unique ?

La méthode choisie doit être adaptée et explicite. Vérifiez sa cohérence avec le cadre retenu et votre organisation. Nous ne déclarons pas une méthode obligatoire pour tous les SaaS.

Qui accepte le risque résiduel ?

La personne autorisée dans votre gouvernance. Le rôle et les critères d’acceptation doivent être définis ; le consultant ne décide pas à la place de la direction.

Un rapport de menace suffit-il ?

Non. Il peut alimenter les scénarios, mais l’exposition dépend de votre architecture, de vos pratiques et des conséquences propres au service.

Préparer la suite du travail

Sources et portée de lecture

Les sources ci-dessous documentent le cadre ou le fait cité. Les propositions d’organisation sont des conseils de préparation à adapter à votre situation. Elles ne reproduisent pas le texte des normes et ne constituent pas une décision d’audit ni un avis juridique.