EN

15 mai 2026 · ~6 min de lecture

CC BY-NC-SA 4.0

Cyberbasics — Épisode 2 : analyse de risque

Cet article est le second épisode de la série cyberbasics, dédiée aux fondamentaux de la sécurité logicielle.

L'analyse de risque : un outil pour être conscient et prioriser

Partons d'un postulat simple : le pire des risques est celui que l'on ne connaît pas. Même si l'analyse de risque a pour but de prioriser les mesures de sécurité qu'on veut mettre en place, personnellement j'aime bien la positionner, avant tout, comme un exercice de transparence et d'honnêteté intellectuelle.

C'est OK de ne rien faire, si on assume de regarder les risques en face ! Tout le challenge étant de bien les comprendre.

Si on n'est pas à l'aise avec les risques que l'on évalue, alors on doit faire ce qui est à notre portée pour réduire les risques. Et pour être efficient il faut avoir une analyse de risque pour savoir fixer les priorités et agir en fonction de nos moyens.

Non ! La sécurité n'est pas un investissement sans fin, réalisé à l'aveugle ! C'est un investissement en réduction du risque.

Première étape : cadrer le périmètre

Là, c'est simple, on définit les objets de valeur qu'on a dans la maison et leur degré d'exposition. Cela peut passer par une cartographie exhaustive de ses actifs, ou plus simplement évaluer "à la louche" les objets qu'on a à protéger ? (données clients, secrets d'infra, réputation).

Deux exemples de déclinaison du cadrage de l'analyse :

• La version light du Rapid Risk Assessment (RRA) : idéale pour une application simple. On écrit le dictionnaire des modèles de données gérés par le service/produit en question.
• La version longue et rigoureuse proposée par EBIOS : idéale pour une entreprise entière ou pour passer la certification ISO 27001. On procède à l'atelier 1 EBIOS, lequel vise à définir le périmètre de l'étude dans un cadre formel, notamment en cartographiant les "valeurs" qu'on cherche à protéger, les responsables et les biens supports qui servent à générer ces valeurs. Cet atelier à lui seul peut prendre des jours.

Deuxième étape : calculer un risque

Je vous propose une définition du risque vulgarisée mais universelle, que vous pourrez retrouver dans les principales méthodes (i.e. EBIOS, ISO 27005, RRA, ...).

Risque = probabilité × impact

L'impact n'est pas très difficile à définir, généralement on utilise une échelle simple :

• critique = ma boite coule
• sévère ou haut = ma boite est en danger
• moyen = mon activité est perturbée
• faible = négligeable

Un impact se calcule par rapport à des événements redoutés sur vos ressources de valeur. Par exemple : vol de données, compromission d'un serveur ou d'un compte administrateur, ...

La probabilité

Pour évaluer la probabilité d'un risque on doit impérativement définir des scénarios d'attaque, c'est-à-dire se mettre dans la peau d'un attaquant. La ressource qui vous sera utile ici c'est le framework Mitre Att&ck, clairement très proche des méthodologies utilisées par les équipes de sécurité offensive ou tout simplement par les attaquants.

Pour mettre le pied à l'étrier, ma recette préférée c'est de se calquer sur le framework proposé par EBIOS pour formaliser des risques opérationnels (EBIOS atelier 4), qui propose de découper un scénario d'attaque en 4 étapes majeures :

1. La reconnaissance : est-ce que c'est facile d'avoir de l'info OSINT sur mon entreprise (ou mon service). Je vous donne une petite astuce pour comprendre de quoi on parle : tester des outils comme crt.sh ou encore n'importe quel outil OSINT de la suite exegol. Jouez ! Et constatez :)
2. L'accès initial : je vous mâche le travail, ici on a très souvent 3 axes : 1) l'exploitation de vulnérabilité pour pénétrer votre réseau, 2) le phishing en tout genre pour voler des credentials légitimes et 3) la corruption d'un employé.
3. La propagation : comment un attaquant peut évoluer dans un système, une fois qu'il a un accès. On va typiquement parler découverte, latéralisation, et d'autres étapes que vous apprendrez en travaillant avec le Mitre Att&ck.
4. L'exploitation : la capacité d'exploiter le système à distance pour un attaquant qui a réussi à obtenir un accès à votre système d'information.

C'est super intéressant de dresser ces scénarios, même si on n'en fait que quelques-uns et si on est "maladroit" au début, l'idée étant de s'améliorer avec le temps. D'après ma modeste expérience, même sans grande expertise en sécurité, certains scénarios peuvent donner des directions stratégiques très structurantes (ceci est un spoiler pour le prochain article).

Finalement, l'idéal si vous n'avez pas les compétences, c'est de déléguer ce travail à une prestation de sécurité offensive (pentest ou red team), qui aura aussi le mérite de valider par le test les scénarios d'attaque. D'ailleurs, un pentester vous demandera bien souvent des éléments de votre analyse de risque (événements redoutés, hypothèses, chemins d'attaques à valider) avant de démarrer sa prestation.

Troisième étape : réduire les risques non acceptables

Le document stratégique, qui sert à prendre des décisions (i.e. allouer des ressources, ou pas, pour faire de la sécurité), c'est la matrice de risque. Ci-après, un exemple :

Concernant les couleurs, chacun pourra juger de son algorithme pour fixer le niveau de risque, et vous pouvez toujours vous inspirer d'EBIOS Risk Manager.

Une fois qu'on a cette matrice, le but est simple : ajouter des tâches dans votre backlog pour faire baisser le niveau d'un risque, par exemple en rendant plus difficile l'exploitation d'un scénario d'attaque. Typiquement, si vous faites l'exercice de bien définir vos scénarios vous constaterez probablement que les définitions et niveau de risque proposés par le CVSS (i.e. le score donné aux CVEs qui affectent vos logiciels) vous paraîtront beaucoup plus clairs.

Pour conclure

Il y a deux risques à éviter avec l'analyse de risque : 1) ne pas en faire et 2) partir dans un schéma trop complexe ou trop coûteux. En revanche, on a le droit de ne pas être exemplaire du premier coup et clairement je préconise une approche d'amélioration continue sur ce sujet.

Pour rendre tout ça un peu plus concret, le prochain article de la série cyberbasics présentera quelques résultats évocateurs d'analyse de risque issus de ma modeste expérience.

Pour aller plus loin

• EBIOS Risk Manager — ANSSI — la méthode française de référence pour l'analyse de risque cyber
• Rapid Risk Assessment (RRA) — Mozilla — une méthode légère et pragmatique, idéale pour évaluer rapidement le risque d'un service
• MITRE ATT&CK — base de données des tactiques et techniques d'attaque réelles, indispensable pour construire des scénarios réalistes
• MITRE D3FEND — le pendant défensif d'ATT&CK : pour chaque technique d'attaque, les contre-mesures associées
• ISO 27005 — norme internationale de gestion du risque en sécurité de l'information (référence payante, disponible sur iso.org)

Cet article fait partie de la série cyberbasics, destinée aux développeuses et développeurs et aux petites structures qui souhaitent construire une posture de sécurité solide et pragmatique.