Pourquoi partir d'une étude de cas plutôt que du guide
La méthode EBIOS Risk Manager de l'ANSSI se lit vite et s'applique lentement. Le guide décrit cinq ateliers, mais la difficulté n'est presque jamais de comprendre ce qu'est une valeur métier ou un scénario stratégique : elle est de savoir jusqu'où descendre, quand s'arrêter, et comment relier ce qui sort d'un atelier à ce qui entre dans le suivant. Un exemple déroulé de bout en bout règle ces questions plus vite que n'importe quelle définition. Le cas présenté ici est entièrement fictif, comme celui qui illustre le guide de l'ANSSI : il sert à montrer l'enchaînement, pas à décrire une organisation réelle. Prenons une entreprise de taille intermédiaire qui exploite une plateforme de commande en ligne pour ses clients professionnels, avec une équipe informatique restreinte et deux prestataires critiques.
Ateliers 1 et 2 : cadrage, socle de sécurité et sources de risque
L'atelier 1 délimite le périmètre et identifie les valeurs métier : ici, la prise de commande, le référentiel tarifaire et les données de facturation des clients. Chacune s'appuie sur des biens supports : l'application web, la base de données, l'annuaire, l'hébergement. C'est aussi à ce stade que se fixent les échelles de gravité, et cette décision engage toute la suite : une échelle mal calibrée produit des scénarios tous classés critiques, donc inexploitables. L'atelier 1 dresse enfin le socle de sécurité, c'est-à-dire l'écart entre les référentiels applicables et ce qui est réellement en place. L'atelier 2 identifie les couples source de risque et objectif visé : un groupe cybercriminel cherchant un gain financier, un concurrent cherchant le référentiel tarifaire, un prestataire négligent. On retient les couples pertinents, pas tous les couples imaginables.
Ateliers 3 et 4 : de l'écosystème aux chemins d'attaque
L'atelier 3 sort du système d'information pour regarder l'écosystème : les parties prenantes qui ont un accès ou une dépendance, donc les deux prestataires, l'hébergeur, et les clients professionnels eux-mêmes. Chacun est évalué selon son niveau de menace et sa dépendance, ce qui fait apparaître des scénarios stratégiques que l'analyse interne seule ne voit pas, par exemple une compromission passant par le prestataire de maintenance applicative. L'atelier 4 descend au niveau technique et transforme ces scénarios en chemins d'attaque : accès initial, propagation, action sur l'objectif. C'est l'atelier le plus exigeant, parce qu'il demande une connaissance réelle de l'architecture et des modes opératoires des attaquants. C'est aussi celui que les équipes bâclent le plus souvent, faute de temps.
Atelier 5 : traitement du risque, et ce qui coince ensuite
L'atelier 5 arbitre : quelles mesures, dans quel ordre, à quel coût, et quel risque résiduel la direction accepte formellement. Il produit le plan de traitement et le plan d'amélioration continue. Sur notre cas fictif, l'analyse aboutit à trois décisions structurantes : durcir l'accès des prestataires, séparer le référentiel tarifaire de la base applicative, et surveiller les accès à la facturation. Le point de blocage arrive après. Six mois plus tard, un prestataire change, l'architecture évolue, et la question devient : faut-il tout refaire ? Avec des livrables produits dans un traitement de texte à partir d'un tableur, la réponse est presque toujours oui, et l'analyse n'est jamais reprise. C'est là que l'outillage compte davantage que la méthode.
Ce qu'il faut avoir réuni avant d'ouvrir l'atelier 1
Un atelier EBIOS RM échoue rarement pendant la séance : il échoue parce que la matière première manque. Quatre éléments doivent exister avant d'ouvrir l'atelier 1. Un mandat écrit, qui nomme celui qui arbitre et celui qui signera l'acceptation du risque résiduel : sans nom, l'atelier 5 se termine sans décision. Un périmètre qui tient en une phrase, avec ce qui en est explicitement exclu. Une liste des processus métier concernés, chacun avec un responsable capable de dire ce que coûtent réellement deux jours d'indisponibilité. Et un inventaire des biens supports, même imparfait : une cartographie approximative vaut mieux que trois séances passées à la reconstituer. Vient ensuite le choix des participants, régulièrement sous-estimé. Les métiers sont indispensables aux ateliers 1 et 5, l'architecture et l'exploitation à l'atelier 4, les achats ou le juridique à l'atelier 3, parce qu'eux seuls savent quelles clauses de sécurité ont été réellement signées avec les prestataires. Dernier point : arriver en atelier 1 avec un projet d'échelle de gravité déjà rédigé, à valider en séance. Repartir d'une page blanche transforme l'atelier de travail en débat de vocabulaire.
Les erreurs qui font dérailler l'analyse, et leurs causes
Cinq erreurs reviennent, et chacune a une cause organisationnelle plutôt que méthodologique. Confondre valeur métier et bien support : quand l'atelier 1 est mené par la seule équipe informatique, la liste se remplit de serveurs et l'analyse finit par mesurer des pannes au lieu de mesurer des conséquences. Chercher l'exhaustivité à l'atelier 2 : retenir dix sources de risque garantit que les ateliers 3 et 4 ne seront jamais terminés, alors que trois couples bien choisis couvrent l'essentiel. Dresser la liste des parties prenantes de l'atelier 3 à partir des contrats plutôt qu'à partir des accès réellement ouverts : elle décrit alors ce qui a été signé, pas ce qui est branché. Écrire des chemins d'attaque génériques, du hameçonnage à l'exfiltration, qui conviendraient à n'importe quelle organisation : c'est le symptôme d'un atelier 4 tenu sans architecte, et il n'en sort aucune mesure exploitable. Clore enfin l'atelier 5 avec des mesures sans responsable ni échéance, faute d'avoir invité ceux qui tiennent le budget : le dossier est présentable, il ne produit rien.
Les signaux qui montrent qu'une analyse sert encore
Une analyse qui sert encore se reconnaît à quelques signaux vérifiables. D'abord la part des mesures du plan de traitement qui portent un responsable nommé et une échéance, puis la part de ces échéances tenues : c'est l'indicateur le plus sévère. Ensuite le délai entre un changement réel, un prestataire remplacé ou une brique d'architecture ajoutée, et la mise à jour des scénarios concernés : au-delà de quelques semaines, l'analyse décrit un système qui n'existe plus. Puis le nombre de scénarios modifiés lors de la dernière revue : zéro signifie que personne ne l'a rouverte. Le signal le plus parlant reste une décision d'architecture ou d'investissement arbitrée en s'appuyant explicitement sur l'analyse. Le contexte réglementaire déplace surtout le curseur de la preuve : une entité concernée par NIS2, ou une entité financière soumise à DORA, doit pouvoir présenter une appréciation du risque documentée, tenue à jour et étendue à ses prestataires. Ce coût d'entretien est précisément ce que l'assistance IA de Vailor réduit : environ 70% de temps gagné sur les analyses de risque.
Ce qu'il faut retenir de cet exemple
Une étude de cas EBIOS RM utile ne cherche pas l'exhaustivité : elle boucle les cinq ateliers sur un périmètre restreint et produit un plan de traitement que quelqu'un peut exécuter. Mieux vaut une analyse terminée sur une application critique qu'une analyse abandonnée à l'atelier 4 sur tout le système d'information. Le second enseignement porte sur la durée de vie du travail : une analyse qui ne peut pas être mise à jour à moindre coût cesse d'être vraie dans l'année. Vailor conserve les liens entre valeurs métier, scénarios, chemins d'attaque et mesures, régénère les livrables sans ressaisie, et fait passer une révision d'un projet à une mise à jour. Demandez une démonstration pour dérouler ces cinq ateliers sur votre propre périmètre.