Un accident n’a jamais une seule cause. Jamais.
Les accidents marquants sont rarement le produit d’une défaillance unique survenue sur le moment. Ils sont liés à des décisions, des écarts ou des faiblesses apparus des semaines, des mois, parfois des années auparavant. Et parfois à des centaines de kilomètres du lieu de l’événement. L’accident n’est pas créé au moment où il survient : il est révélé. C’est toute la différence, et c’est ce que le modèle de Reason permet d’expliquer mieux que n’importe quelle autre image.
Les tranches, ce sont vos lignes de défense
Imaginez plusieurs tranches empilées. Ce sont vos lignes de défense : la conception, les procédures, la formation, les contrôles, l’organisation. Chaque tranche comporte des trous. Le fameux « trou dans la raquette ».
Mais voici le point que la version « grand public » du modèle oublie presque toujours : Reason distingue deux familles de trous, et elles n’ont pas du tout le même poids.
| Défaillances actives | Conditions latentes |
| L’erreur ou l’écart au contact direct du danger (l’opérateur, le geste, la décision du moment). | Les décisions de conception, d’organisation, de management qui dorment dans le système. |
| Visibles, immédiates, faciles à désigner après coup. | Invisibles, installées lentement, elles n’attendent qu’un déclencheur. |
| Inévitables : il y aura toujours des erreurs humaines. | Évitables : c’est là que se joue la sûreté. |
Chercher le coupable du jour, c’est rester sur les défaillances actives. Travailler sur les conditions latentes, c’est s’attaquer aux trous qu’on laisse s’installer. C’est moins spectaculaire, mais c’est la seule stratégie qui tient dans la durée. Et c’est exactement le terrain de jeu d’un système qualité bien conçu : il n’empêchera jamais une main de trembler, mais il peut empêcher une faiblesse de dormir vingt ans dans un procédé.
Les trous ne sont pas fixes : ils bougent
Une procédure qui devient inadaptée, une charge de travail qui dérive, une compétence qui s’érode, un contrôle réalisé de manière mécanique. Les trous s’ouvrent, se déplacent, grandissent au fil du temps, souvent sans que personne ne le décide.
Tant que les trous ne s’alignent pas, le système absorbe. Le jour où ils s’alignent, l’accident traverse toutes les défenses d’un coup. C’est ce qui rend si dangereuse la phrase qu’on entend partout : « ça fait vingt ans qu’on fait comme ça, on n’a jamais eu de problème ». L’absence d’accident n’est pas la preuve que le système est sûr. C’est parfois juste la preuve que les trous ne se sont pas encore alignés.
Le contrôle est une barrière, pas une formalité
C’est probablement le modèle que j’ai le plus utilisé pour expliquer l’importance des contrôles. Parce qu’un contrôle n’est jamais neutre : c’est une barrière supplémentaire entre une faiblesse du système et un accident.
Et cette barrière n’a pas toujours la même épaisseur. Un contrôle réalisé avec rigueur et attention ne produit pas les mêmes trous qu’un contrôle fait machinalement. Le « vu, RAS » signé sans regarder, c’est une tranche en carton : elle est là sur le papier, mais elle n’arrête rien.
Le vrai danger : le mode de défaillance commun
Si le fromage suisse s’arrêtait à « empilez des barrières », ce serait rassurant. Et faux. Le piège, ce n’est pas la barrière qui manque. C’est la barrière qui n’en est pas vraiment une, parce qu’elle partage la même faiblesse que les autres.
Empilez cinq barrières qui reposent sur la même hypothèse de conception, la même équipe, le même mode opératoire : vous n’avez pas cinq tranches. Vous avez une seule tranche photocopiée cinq fois. Le trou est exactement au même endroit sur chacune. Et une cause commune les traverse toutes en même temps — pas l’une après l’autre, toutes d’un coup.
C’est ça, le mode de défaillance commun : une cause sous-jacente unique qui fait sauter plusieurs défenses simultanément. Conception, équipement, exploitation, organisation, maintenance, facteurs humains : sur le papier, six lignes de défense. Si elles dépendent toutes du même point faible, c’est une seule défense déguisée en six. Et c’est là que beaucoup de systèmes qui se croient robustes sont en réalité nus.
La décomposition IPSN de l’ISO 19443, c’est exactement la réponse
C’est là que la décomposition des activités IPSN (Importantes Pour la Sûreté Nucléaire), telle que la pousse l’ISO 19443, prend tout son sens — et arrête d’être une contrainte documentaire de plus.
L’erreur classique, c’est de tout miser sur le contrôle final. Une grosse plaque à la fin, censée tout rattraper. Sauf que si cette plaque a un trou — un contrôle fait machinalement, un point non couvert par le plan de contrôle — il n’y a plus rien derrière. Une seule barrière, et on est nu.
Décomposer l’activité en sous-activités IPSN, c’est faire l’inverse : placer un contrôle technique au plus près de chaque activité élémentaire, là où le risque naît. Pas une plaque finale, mais une plaque à chaque étape. Et comme ces contrôles portent sur des activités différentes, à des moments différents, par des acteurs différents, ils ne partagent pas le même trou. C’est précisément ce qui casse le mode commun.
La finalité de la décomposition IPSN n’est donc pas de produire plus de paperasse. C’est de transformer une défense unique et fragile en une succession de barrières réellement indépendantes. Le fromage suisse, version norme.
Trois rappels simples et exigeants
On ne mise jamais sur une seule barrière.
Une erreur sans conséquence n’est jamais anodine : elle a souvent été rattrapée ailleurs dans le système.
La robustesse d’un système ne se juge pas quand tout fonctionne, mais lorsqu’il est sous contrainte.
La question à se poser
Combien de barrières indépendantes protègent réellement votre activité la plus sensible ? Et si l’une d’elles disparaissait demain matin, les autres suffiraient-elles encore à empêcher l’accident ?
Et la question qui dérange vraiment : combien de vos barrières sont en réalité la même barrière, déguisée sous plusieurs noms ? La sûreté n’est pas une affaire de hasard. C’est une affaire d’alignement — qu’on évite.
