En une phrase. EBIOS Risk Manager (EBIOS RM) est la méthode d’appréciation et de traitement du risque numérique publiée par l’ANSSI avec le Club EBIOS. Ses cinq ateliers relient missions métier, sources de risque, scénarios d’attaque et décisions de traitement. Elle aide à justifier une stratégie de sécurité ; aucun texte général du RGPD ou de NIS2 ne l’impose comme méthode unique.
Le point de départ n’est pas une liste de vulnérabilités. Une direction doit d’abord savoir quelle activité protéger, contre quels événements redoutés, avec quel niveau de risque acceptable. EBIOS RM organise ce dialogue entre métiers, sécurité et décideurs. Le guide EBIOS RM de l’ANSSI et son édition 1.5 de septembre 2024 exposent les cinq ateliers et leurs cycles stratégique et opérationnel.
La méthode s’applique à un service, un projet ou un périmètre organisationnel défini. Un résultat utile permet de décider qui corrige quoi, de vérifier l’effet des mesures et de réexaminer les hypothèses lorsque l’environnement change. Une PSSI traduit ensuite les décisions transversales en règles communes ; le durcissement des postes et serveurs peut être l’une des mesures retenues. L’analyse EBIOS conserve la justification propre au périmètre étudié.
Points clés
- Atelier 1 : cadrer les missions, valeurs métier, événements redoutés, biens supports et socle de sécurité.
- Ateliers 2 à 4 : sélectionner les sources de risque, décrire leur chemin par l’écosystème puis leurs modes opératoires techniques.
- Atelier 5 : arbitrer les traitements, responsables, échéances et risques résiduels.
- Le socle répond aussi aux risques courants, accidentels ou environnementaux ; les scénarios ciblent surtout les menaces intentionnelles.
- Une AIPD et un dossier NIS2 ont d’autres questions à résoudre. EBIOS peut les alimenter sans se substituer à leurs exigences propres.
1. Choisir l’objet étudié avant d’ouvrir les ateliers
Un périmètre tel que « toute l’entreprise » donne souvent des scénarios trop vagues. Préférer une mission et les processus qui la rendent possible : par exemple, assurer la paie de plusieurs établissements, exploiter une plateforme de rendez-vous ou maintenir une production industrielle. Indiquer les interfaces avec le reste du système d’information, les sites, les prestataires, les données et la période étudiée. Le périmètre doit permettre à une personne de décider des mesures qui en ressortiront.
Réunir au minimum un représentant métier capable de décrire les conséquences d’une interruption, une personne chargée de la sécurité, les exploitants des biens supports et un décideur habilité à accepter ou financer le traitement du risque. Consigner les hypothèses : volume d’activité, dépendances, projets déjà décidés, obligations spécifiques. Sans propriétaire des hypothèses, une analyse ancienne peut continuer à circuler alors que son objet a changé.
La méthode associe approche par conformité et approche par scénarios. Dans l’atelier 1, comparer le socle de sécurité aux règles applicables et aux bonnes pratiques permet de traiter les risques habituels, y compris panne ou erreur. Les ateliers suivants explorent ce que des adversaires pourraient obtenir malgré ce socle. Cette articulation évite de réduire EBIOS à un catalogue d’attaquants.
2. Atelier 1 : relier les événements redoutés aux impacts métier
Une valeur métier est un processus ou un ensemble d’informations important pour la mission étudiée : exécuter la paie ou préserver les informations des salariés et de leurs paiements, par exemple. Les applications, serveurs, réseaux, locaux et équipes dont la sécurité relève directement du périmètre sont des biens supports de ces valeurs. Un fournisseur extérieur dont l’organisation ne maîtrise pas directement la sécurité est une partie prenante de l’écosystème à examiner notamment à l’atelier 3, même s’il héberge un élément utile au processus. La perte de confiance des usagers constitue plutôt une conséquence à apprécier dans la gravité d’un événement redouté. Une base de données n’est pas automatiquement une valeur métier : distinguer le support technique des informations importantes qu’elle contient, lesquelles peuvent elles-mêmes être une valeur métier.
Pour chaque valeur, décrire un événement redouté et ses conséquences. Dans un exemple hypothétique de paie externalisée, « modification non autorisée des coordonnées bancaires avant virement » touche les salariés et la trésorerie ; « impossibilité de transmettre les ordres de paie » touche la continuité et les délais. Le niveau de gravité doit découler de ces conséquences documentées, et non du seul nom de l’attaque. Une grille simple peut distinguer effets limités, sérieux et critiques, à condition de définir les critères en amont.
Inventorier ensuite les contrôles du socle : gestion des accès, sauvegardes, segmentation, correctifs, continuité, procédures fournisseurs. Noter pour chaque contrôle s’il existe, sur quelle partie du périmètre et avec quelle preuve récente. Une politique signée ne démontre pas, à elle seule, qu’une sauvegarde a été restaurée ou qu’un accès révoqué a disparu. Les écarts du socle peuvent déjà alimenter le plan de l’atelier 5, avant même la construction des scénarios avancés. Le guide de durcissement Windows et Linux aide à examiner une partie de ce socle technique.
3. Atelier 2 : sélectionner des sources de risque pertinentes
L’atelier recherche les couples source de risque / objectif visé. Une source peut être un groupe criminel, une personne interne malveillante ou un acteur cherchant à perturber une mission. Un objectif visé est ce qu’elle veut obtenir : rançon, données revendables, sabotage ou influence. Une catégorie générique comme « pirate informatique » éclaire peu la décision ; préciser capacité, intérêt pour l’organisation et opportunités observables.
Ne pas retenir toutes les combinaisons imaginables. Dans l’exemple hypothétique de paie, un acteur criminel cherchant un détournement de virement et un acteur cherchant l’exfiltration de données RH conduisent à des chemins et défenses différents. La sélection gagne à utiliser des incidents publics comparables, les alertes du secteur et les connaissances des équipes, avec une mention explicite de l’incertitude. Ne pas transformer l’absence d’incident connu en preuve d’absence de menace.
Les erreurs de saisie, pannes et événements naturels doivent rester visibles dans le socle et les autres analyses de continuité. Le guide ANSSI réserve la démarche par scénarios aux menaces intentionnelles, notamment ciblées ou sophistiquées. Il serait trompeur de forcer une panne électrique dans un récit d’attaquant pour remplir l’atelier 2.
4. Atelier 3 : examiner les chemins par l’écosystème
Cartographier les parties prenantes qui peuvent donner accès aux valeurs métier : hébergeur, mainteneur, fournisseur d’identité, logiciel métier, banque, partenaire d’échange. Pour chacune, identifier la relation technique réelle, les droits accordés, les données visibles et l’effet d’une compromission. La cartographie d’un contrat sans flux ni droits ne suffit pas à comprendre une dépendance.
Un scénario stratégique explique comment une source de risque atteindrait son objectif en passant par une partie prenante ou par le système étudié. Dans l’exemple hypothétique, un acteur prend le contrôle du compte d’administration d’un prestataire de paie, puis modifie des coordonnées avant validation. À ce stade, l’intérêt porte sur le chemin, les barrières existantes et la gravité métier, pas encore sur une suite exhaustive de commandes techniques.
Comparer plusieurs chemins vers le même événement redouté. Une dépendance externe peut concentrer les droits de plusieurs entités ; à l’inverse, une interface limitée, isolée et contrôlée peut réduire l’attractivité du chemin. Les risques de la chaîne de sous-traitance NIS2 offrent un prolongement lorsque l’organisation doit aussi examiner les dépendances réglementaires de son secteur. Les contrats, droits d’accès et architectures réellement déployés priment sur les déclarations commerciales d’un fournisseur.
5. Atelier 4 : rendre les scénarios vérifiables
L’atelier opérationnel détaille les étapes plausibles : point d’entrée, privilèges requis, déplacement, action finale, traces possibles et barrières. Pour le scénario de paie, demander si le prestataire utilise un compte partagé, si une double validation sépare changement de RIB et émission du virement, et si les journaux permettraient de reconstituer la séquence. Une vraisemblance « forte » sans ces éléments est difficile à discuter.
La vraisemblance doit tenir compte des capacités de la source, de l’exposition et de l’efficacité constatée des contrôles. La gravité provient des événements redoutés de l’atelier 1. Une matrice peut aider à prioriser, mais la multiplication mécanique de deux notes ordinales ne transforme pas l’appréciation en probabilité chiffrée. Conserver les raisons de la note, les désaccords et les hypothèses qui pourraient la faire évoluer.
Pour tester la solidité d’un scénario, l’équipe peut demander : le chemin existe-t-il dans l’architecture actuelle ? Le compte ou flux mentionné est-il encore actif ? Une mesure censée bloquer l’étape a-t-elle été testée ? Les résultats d’audit, de revue d’habilitations et de tests de restauration apportent plus qu’un simple statut « conforme ». Les détails d’exploitation sensibles peuvent rester dans une annexe à accès limité.
6. Atelier 5 : transformer les risques en décisions suivies
Le traitement peut consister à réduire l’exposition, modifier le projet, partager certains effets contractuellement ou accepter un risque résiduel dans la limite de l’appétence définie. Un transfert financier, comme une assurance, ne supprime pas l’obligation de sécurité ni l’impact possible sur les personnes. Chaque décision doit identifier un responsable, une action vérifiable, une échéance et le risque qu’elle vise.
Dans l’exemple hypothétique, la double validation des modifications de coordonnées réduit une possibilité de fraude ; une revue des droits du prestataire réduit l’accès disponible ; un exercice de restauration améliore la résilience. Le plan indique la preuve attendue : configuration validée, journal d’essai, compte rendu de revue ou contrat modifié. Après déploiement, réévaluer la vraisemblance et faire accepter le risque résiduel par une personne compétente, avec la date et les motifs. Accepter le risque avant de vérifier la mesure promise reviendrait à confondre intention et résultat.
L’analyse doit vivre avec le périmètre. Un nouveau fournisseur, une interconnexion, une attaque observée dans le secteur ou un changement majeur de mission justifie une révision ciblée. Le suivi peut être plus fréquent pour les mesures opérationnelles que pour les hypothèses stratégiques ; le guide ANSSI distingue justement ces deux cycles. Éviter une « mise à jour annuelle » purement formelle si le contexte a changé plus tôt.
7. Articuler EBIOS RM avec le RGPD et l’AIPD
Une AIPD exigée par l’article 35 RGPD examine un traitement susceptible d’engendrer un risque élevé pour les droits et libertés des personnes. EBIOS RM étudie d’abord les risques numériques pour l’objet métier. Ses scénarios et mesures peuvent alimenter le volet sécurité d’une AIPD, mais ils ne remplacent ni l’examen de la nécessité et de la proportionnalité du traitement, ni l’information des personnes, ni l’analyse des atteintes qui ne passent pas par une cyberattaque.
La méthode PIA de la CNIL s’inspire historiquement d’EBIOS dans un contexte de protection des données. Il ne faut pas en déduire qu’une AIPD doit employer la version EBIOS RM ou qu’un rapport EBIOS valide automatiquement l’AIPD. On peut réutiliser une description de périmètre et des scénarios, puis ajouter les décisions propres au traitement : finalité, minimisation, base juridique, durée, exercice des droits, conséquences pour les personnes et consultation préalable éventuelle.
Par exemple, une analyse de risque d’un outil RH peut montrer un risque d’exfiltration et recommander chiffrement et contrôle d’accès. L’AIPD doit aussi demander si le score RH envisagé est nécessaire, s’il peut être expliqué ou contesté, et si les données utilisées sont proportionnées. Le guide de l’article 35 aide à garder ces questions distinctes. Les contrôles retenus alimentent ensuite l’examen des mesures de sécurité de l’article 32.
8. Articuler EBIOS RM avec NIS2 sans créer une obligation fictive
La directive NIS2 demande aux entités concernées de gérer les risques liés à la sécurité des réseaux et systèmes d’information. Son article 21 décrit des catégories de mesures, notamment analyse de risques, gestion des incidents, continuité, chaîne d’approvisionnement et contrôle d’accès. Elle ne nomme pas EBIOS RM comme méthode obligatoire. Les exigences françaises applicables doivent être vérifiées selon la qualification de l’entité et les textes en vigueur ; les anciens termes OSE et OIV ne résument pas, à eux seuls, le champ NIS2.
Dans le projet de référentiel ReCyF publié par l’ANSSI en mars 2026, EBIOS RM est présenté comme une méthode pouvant servir à l’analyse de risques. Une organisation peut donc s’appuyer sur ses ateliers pour éclairer des mesures NIS2 et garder une matrice de correspondance vers les exigences applicables. L’analyse ne démontre pas à elle seule que la continuité, les notifications, la gouvernance ou les contrôles fournisseurs sont effectivement mis en œuvre. Le guide d’audit NIS2 complète cette vérification.
9. Outils, compétences et limites
L’ANSSI fournit un guide et un tableur pour mener les ateliers. Des outils logiciels peuvent recevoir un label EBIOS RM de l’ANSSI ; ce label concerne la conformité de l’outil à la méthode, pas la qualité de toutes les analyses qu’on y saisit. Choisir un support qui permette de tracer les hypothèses, liens entre scénarios et mesures, versions et décisions. Un tableur correctement gouverné peut suffire pour un périmètre limité.
L’ANSSI et le Club EBIOS proposent un cadre de formation ; le CFSSI dispense la méthode aux agents publics. Formation, label logiciel et certification individuelle éventuelle ne se confondent pas. Les coûts et délais dépendent du prestataire, du périmètre et de la disponibilité des métiers : aucun barème général ne permet de promettre qu’une analyse prendra un nombre fixe de semaines.
La principale limite pratique est la qualité des échanges. Une analyse avec uniquement l’équipe sécurité risque de mal noter les impacts métier ; une analyse avec uniquement les métiers peut ignorer les chemins techniques. Documenter les incertitudes et réviser les décisions est plus utile qu’une matrice paraissant précise mais fondée sur des hypothèses invérifiées. Le niveau de détail doit rester proportionné à la décision à prendre.
FAQ
EBIOS RM est-elle obligatoire ?
Non, les textes généraux du RGPD et de NIS2 n’imposent pas cette méthode particulière. Un contrat, une politique interne ou un cadre sectoriel peut toutefois la demander dans un cas précis. Vérifier l’exigence applicable au périmètre.
Peut-on employer EBIOS RM pour une AIPD ?
Oui, ses scénarios de sécurité peuvent nourrir l’AIPD. Il faut aussi traiter les droits et libertés des personnes, la nécessité et la proportionnalité du traitement ainsi que les autres exigences de l’article 35.
Quelle différence avec ISO 27005 ?
ISO 27005 fournit un cadre international de gestion des risques de sécurité de l’information. EBIOS RM est une méthode française détaillée en cinq ateliers, avec un socle de sécurité et des scénarios centrés sur les sources de risque et l’écosystème. Les approches peuvent être articulées.
Quel résultat remettre à la direction ?
Une synthèse des valeurs métier, événements redoutés, scénarios prioritaires, hypothèses, mesures décidées, responsables et risques résiduels. La direction doit pouvoir comprendre ce qu’elle accepte, finance ou demande de revoir.