Tout le monde fait des analyses de risques. Peu les font correctement.
L’analyse de risques est la pierre angulaire de la loi de transposition de la directive NIS 2, d’ISO 27001 et de pratiquement tous les référentiels de sécurité existants. Tout le monde sait qu’il faut en faire. Mais après avoir vu des centaines de matrices de risques, je peux affirmer : la plupart donnent une image précise de choses complètement erronées.
Le problème n’est pas que les organisations sautent l’analyse de risques. Le problème est qu’elles la font d’une manière qui ne fournit pas d’aide réelle à la décision. Le résultat est un document qui paraît professionnel dans un classeur mais qui n’influence jamais une seule décision.
Voici les cinq erreurs les plus courantes — et comment les éviter.
Erreur 1 : Copier les registres de risques d’autrui
Il est tentant de commencer par un modèle. Le registre de risques de quelqu’un d’autre, les risques d’exemple d’un standard sectoriel, ou une liste prédéfinie d’un cabinet de conseil. Le problème ? Les risques des autres ne sont pas vos risques.
Une organisation de production et un fournisseur SaaS ont des paysages de risques fondamentalement différents. Même dans le même secteur, les risques varient selon la taille, l’environnement IT, la structure clientèle et la maturité.
Bonne approche : Commencez par vos propres flux d’information. Quelles informations traitez-vous ? Où sont-elles stockées ? Qui y a accès ? Quels processus en dépendent ? Vos risques naissent dans l’écart entre la valeur de l’information et les menaces qui peuvent exploiter les faiblesses dans votre façon de la traiter.
Erreur 2 : Mélanger risque inhérent et efficacité des contrôles
C’est l’erreur la plus répandue. L’organisation évalue un risque comme « faible » — mais il n’est faible que parce qu’un contrôle existe déjà. Que se passe-t-il si le contrôle cesse de fonctionner ? Si la règle de pare-feu change, si le service de sauvegarde s’arrête, si le collaborateur expérimenté part ?
Quand risque inhérent et efficacité des contrôles sont mélangés dans la même évaluation, vous perdez la capacité de comprendre ce que les contrôles apportent réellement. Vous ne voyez pas où vous êtes le plus vulnérable si un contrôle échoue.
Séparez toujours l’évaluation en deux étapes :
- Risque inhérent — À quel point le risque est-il grave sans contrôles ? Cela vous donne une image de la menace sous-jacente.
- Efficacité des contrôles — Dans quelle mesure les contrôles existants réduisent-ils le risque ? Cela montre où vos investissements font réellement la différence.
La différence vous donne le risque résiduel — le risque avec lequel vous vivez réellement aujourd’hui. C’est celui qui doit être comparé à votre appétit au risque.
Erreur 3 : Fausse précision avec des échelles multidimensionnelles
Une matrice 5×5 avec probabilité et conséquence donne 25 niveaux possibles. Cela paraît précis. Mais si les évaluateurs ne peuvent pas distinguer entre « probabilité 3 » et « probabilité 4 » de manière cohérente, vous n’avez fait qu’ajouter du bruit à l’analyse.
Pire : beaucoup d’organisations utilisent des échelles où les dimensions ne sont pas indépendantes. « Haute probabilité et haute conséquence » devient automatiquement « risque critique » — mais que se passe-t-il si la probabilité est élevée justement parce que la conséquence est faible (et que l’organisation n’a donc pas priorisé la protection) ?
Ce qui fonctionne mieux :
- Utilisez moins de niveaux (3×3 suffit souvent)
- Définissez chaque niveau avec des exemples concrets pertinents pour votre activité
- Calibrez en évaluant plusieurs risques ensemble avant de procéder individuellement
- Acceptez que l’évaluation des risques soit une estimation qualifiée, pas une science exacte
Erreur 4 : Risque sans lien avec l’impact métier
« Le risque d’accès non autorisé au système est évalué comme moyen. » Parfait. Et qu’est-ce que cela signifie pour l’activité ? Rien, si l’évaluation s’arrête là.
Le conseil d’administration ne veut pas entendre parler de niveaux de probabilité. Il veut savoir : combien cela coûte-t-il si cela arrive ? Combien de temps sommes-nous à l’arrêt ? Quels clients sont impactés ? Quelles conséquences réglementaires sont déclenchées ?
Le lien entre risque technique et impact métier est ce qui transforme l’analyse de risques en aide à la décision plutôt qu’en document IT.
| Évaluation technique | Langage métier |
|---|---|
| « Probabilité élevée de ransomware » | « 30% de risque d’arrêt de production de 5 jours, coût estimé 3–8 M€ » |
| « Risque moyen de fuite de données » | « Amende RGPD potentielle et perte de 2–3 clients clés » |
| « Risque faible de DDoS » | « Maximum 4 heures d’arrêt, impact métier limité » |
Erreur 5 : Exercice ponctuel au lieu de processus vivant
Le moment le plus courant pour une analyse de risques ? Juste avant un audit, une certification ou un contrôle de l’ANSSI. Puis elle est rangée dans un dossier jusqu’à la prochaine fois.
Une analyse de risques non mise à jour depuis sa création reflète un paysage de menaces qui n’existe plus. De nouveaux systèmes sont introduits, les fournisseurs changent, les acteurs malveillants modifient leurs tactiques, l’organisation se restructure. Une analyse de risques statique est comme une prévision météo du mois dernier — elle était correcte quand elle a été faite, mais elle ne guide aucune décision aujourd’hui.
Nouveaux systèmes, fournisseurs, processus ou changements organisationnels doivent déclencher une réévaluation des risques concernés. Pas besoin d'une refonte complète — concentrez-vous sur ce qui a changé.
Au minimum annuellement, tout le registre de risques doit être révisé. Une révision trimestrielle des risques les plus prioritaires améliore encore le pilotage.
Chaque incident doit conduire à une réévaluation des risques pertinents. Les incidents vous donnent des données factuelles sur le paysage des menaces — utilisez-les.
Un registre de risques que seul l'analyste de risques peut interpréter ne guide aucune décision. Rendez-le compréhensible pour ceux qui prennent les décisions — la direction.
Analyse de risques qui guide les décisions
Une matrice de risques n’est pas un objectif en soi. C’est un outil pour prendre de meilleures décisions sur l’allocation des ressources limitées de l’organisation. Si votre analyse de risques ne change pas les priorités, n’influence pas les décisions budgétaires et n’est pas discutée au niveau direction — alors elle ne sert à rien.
Demandez-vous : quand un résultat de l’analyse de risques a-t-il réellement conduit à un changement pour la dernière fois ? Si la réponse est « jamais » ou « je ne sais pas » — alors il est temps de réévaluer non seulement les risques, mais le processus.
Le module de risques de Securapilot s’appuie sur ISO 27005 et sépare le risque inhérent de l’évaluation des contrôles — pour que votre vision des risques reflète réellement la réalité et vous donne l’aide à la décision dont vous avez besoin.
Questions fréquentes
Pourquoi les matrices de risques ne fonctionnent-elles pas ?
Les matrices de risques peuvent fonctionner — si elles sont utilisées correctement. Les problèmes surviennent quand les organisations copient des registres de risques génériques, confondent niveaux de risque et statut des contrôles, ou ne mettent jamais à jour l'évaluation. Une matrice de risques doit fournir une aide à la décision, pas seulement une image colorée.
Quelle est la différence entre risque inhérent et risque résiduel ?
Le risque inhérent est le niveau de risque avant application des contrôles. Le risque résiduel est le risque qui subsiste après implémentation des contrôles. Séparer ces deux éléments donne une vision claire des contrôles qui font réellement la différence.
À quelle fréquence l'analyse de risques doit-elle être mise à jour ?
Au moins annuellement, mais aussi lors de changements substantiels dans l'activité, l'environnement IT ou le paysage des menaces. Une analyse de risques non mise à jour depuis plus d'un an ne reflète probablement plus la réalité.
Comment lier l'analyse de risques aux décisions métier ?
Exprimer les risques en termes que le conseil d'administration comprend : impact économique potentiel, interruptions d'activité en heures/jours, et conséquences réglementaires. Éviter le jargon technique et les pourcentages de probabilité sans contexte.
