Utiliser les outils à bon escient, dans la sécurité des systèmes d'information autant qu'ailleurs
Un des arguments des tenants de cette méthode (en dehors du nombre de jours qu’ils vont vous facturer s’il s’agit de consultants) est qu’avec une «bonne» méthode (au hasard EBIOS) on est certain de ne rater aucun risque. C’est deux fois faux: sur le plan conceptuel et empiriquement.
Sur le plan conceptuel d’abord, parce que toute méthode part de postulats (axiomes) pour inférer des résultats. Or, le choix de postulats et de la façon d’inférer exclut forcément des cas à la marge ou «dans les trous de la raquette». Rien d’étonnant à cela: une méthode, c’est un point de vue, une approche d’un problème. Et selon le point de vue, on ne voit pas tous la même chose.
Empiriquement surtout. À titre personnel j’ai eu l’occasion, dans quelques cas ciblés, de dérouler à la fois une EBIOS et une méthode «de bon sens» (et totalement conforme ISO 27005). Dans certains cas, c’est EBIOS qui ratisse le plus large, dans d’autres non.
Toutes les grandes catastrophes technologiques depuis un siècle auraient échappé à une analyse formalisée, et ceci pour trois raisons. Tout d’abord, les méthodes formelles ne sont pas calibrées pour calculer l’impact de la survenance simultanée de deux événements. C’est ce qui s’est passé à Fukushima: la centrale nucléaire était construite pour résister à un tsunami et à un séisme, mais pas aux deux simultanément. Ensuite, l’expérience montre que la probabilité d’occurrence des catastrophes est presque toujours sous-estimée. Au début du nucléaire civil, la probabilité de sinistre sur un réacteur avait été chiffrée à 1 pour 1 million (soit sur un parc mondial de 500 réacteurs une panne tous les 2000 ans) alors qu’il y a eu en moins de 70 ans trois pannes majeures.
Enfin, le facteur humain est toujours ignoré. Sans la bêtise d’un technicien qui a envoyé de l’air dans le tunnel au lieu de faire l’inverse, il n’y aurait peut-être pas eu autant de morts dans l’incendie du tunnel du mont Blanc.
Pour finir, je ne résiste pas au plaisir de caser l’argument ultime: toute méthode est un système formel, et depuis Gödel on sait que les systèmes formels sont incomplets (c’est-à-dire non-autojustifiables dans le cas présent).
Presses de l'EHESP (www.presses.ehesp.fr) en mai 2012
Avez-vous apprécié ce contenu ?
A lire également.

Comment quantifier un risque
31 mars 2026 - 08:06,
Tribune
-Après avoir expliqué qu’une PSSI et une appréciation des risques ne servaient à rien (ici 1) -mais un peu quand même -, intéressons-nous à un autre sujet brûlant qui déchaîne les passions, pire que JR (2) et la fin du Prisonnier (3) : la quantification du risque.

Publication d’un corpus inédit de comptes rendus médicaux fictifs en open data pour accélérer l’IA en santé
26 mars 2026 - 19:08,
Actualité
- Rédaction, DSIHDans un contexte réglementaire européen exigeant, qui garantit un accès et un partage sécurisés des données de santé, le projet PARTAGES apporte une réponse opérationnelle aux défis posés à l’IA en santé. Coordonné par la Plateforme des données de santé (Health Data Hub) et réunissant 32 partenaires...

Health Data Hub et Microsoft : un cadre juridique clarifié, une souveraineté à construire
23 mars 2026 - 09:58,
Actualité
- Rédaction, DSIHEn validant l’autorisation donnée au Health Data Hub pour traiter des données de santé hébergées par Microsoft en France, le Conseil d’État consolide le cadre posé par la CNIL dans sa décision du 20 mars 2026, relative à l’autorisation CNIL 2025‑013 (délibération n° 2025‑013 du 13 février 2025, proj...

Imprivata lance Agentic Identity Management pour sécuriser et gouverner les agents IA dans le secteur de la santé
11 mars 2026 - 09:52,
Communiqué
- ImprivataImprivata, fournisseur leader de solutions de gestion des identités et des accès pour le secteur de la santé et les industries critiques, vient de dévoiler Agentic Identity Management, de nouvelles capacités conçues pour sécuriser et gouverner les agents IA dans les environnements de soins de santé ...
