Sommaire
Résumer ou partager cet article :
Un mot de passe qui fuite, une pièce jointe ouverte, un faux comptable qui obtient son virement : dans chaque cyberattaque, il y a un geste humain au bout de la chaîne. La vraie question n’est pas de savoir qui a fait ce geste, mais pourquoi ce geste a suffi à tout faire tomber. C’est là que se cache le vrai problème, et c’est là que le modèle de Reason devient utile.
Car une cyberattaque réussie n’est presque jamais le fait d’une seule erreur. Le clic malheureux n’est que le dernier d’une série de faiblesses qui dormaient déjà, parfois depuis des mois, en amont de l’incident : un filtre anti-spam trop permissif, une équipe jamais formée, un compte aux privilèges trop larges, un correctif de sécurité jamais appliqué, l’absence de double authentification, aucune supervision pour donner l’alerte. La personne qui a cliqué n’a pas créé ces failles, elle les a simplement réveillées. Pour comprendre cette mécanique, un modèle venu de l’aéronautique et de la médecine est redoutablement éclairant : le modèle de Reason.
Le mot de passe qui fuit n’est jamais le seul coupable
Désigner la personne qui a fait fuiter ses identifiants, c’est confondre le symptôme et la cause. Le clic est visible, immédiat, facile à pointer du doigt. Les conditions qui l’ont rendu possible et surtout qui l’ont rendu coûteux sont invisibles, diffuses, et bien plus anciennes que l’incident lui-même.
Posez-vous la vraie question. Pourquoi ce mot de passe a-t-il suffi à ouvrir vos systèmes ? Pourquoi n’y avait-il pas de seconde barrière pour bloquer la connexion frauduleuse ? Pourquoi ce compte donnait-il accès à autant de données ? Pourquoi personne n’a rien vu pendant des jours ? Aucune de ces questions ne concerne le salarié qui a cliqué. Toutes concernent l’organisation et ses systèmes. C’est précisément ce déplacement du regard que permet le modèle de Reason, et c’est ce qui sépare une entreprise qui apprend de ses incidents d’une entreprise qui les répète.
Le modèle de Reason, ou la théorie du fromage suisse
James Reason, psychologue britannique, a forgé dans les années 1990 un modèle pour expliquer comment surviennent les accidents dans les systèmes complexes : aviation, hôpitaux, centrales, industrie lourde. Son idée est devenue une référence mondiale de la gestion des risques sous le nom imagé de théorie du fromage suisse.
Imaginez vos protections comme une pile de tranches de fromage suisse, posées les unes derrière les autres. Chaque tranche est une barrière de sécurité : le filtre des mails, la sensibilisation des équipes, la double authentification, la gestion des droits d’accès, la mise à jour des logiciels, la supervision, les sauvegardes. Aucune barrière n’est parfaite, chacune a ses trous, c’est-à-dire ses faiblesses. Tant que les trous ne sont pas alignés, une menace qui traverse une tranche est arrêtée par la suivante. L’incident grave survient uniquement le jour où, par malchance ou par négligence accumulée, les trous de toutes les tranches s’alignent et laissent passer l’attaque de bout en bout.
Le modèle est une simplification, et il l’assume : dans la réalité, les trous ne sont pas fixes, ils s’ouvrent et se referment au gré des mises à jour, des départs, des changements d’organisation. Mais c’est justement sa force pédagogique. Il dit une chose simple et puissante : un accident n’est jamais mono-causal. Si l’attaque est passée, ce n’est pas parce qu’une tranche avait un trou, c’est parce que toutes en avaient un, au même endroit, au même moment. Vous trouverez ce raisonnement au cœur des enjeux actuels de la cybersécurité pour les entreprises, où l’erreur humaine est trop souvent présentée comme une cause alors qu’elle n’est qu’un maillon.
Erreurs actives et causes latentes, deux niveaux de responsabilité

Le modèle de Reason distingue deux familles de défaillances, et c’est là que tout se joue. L’erreur active est commise au bout de la chaîne, par la personne en contact direct avec le système : le clic sur le lien, le mot de passe réutilisé, la clé USB inconnue branchée sur le poste. Elle est immédiate et visible. La cause latente, elle, dort dans le système bien avant l’incident, parfois pendant des mois. Reason parle de « pathogènes en sommeil » : des faiblesses déjà présentes, silencieuses tant que rien ne vient les réveiller.
Ces causes latentes prennent racine en amont, dans des décisions et des arbitrages : un budget, une priorité, un choix de conception. Elles se déposent ensuite sous deux formes, qui pèsent autant l’une que l’autre. La première est humaine : une équipe jamais formée, surchargée, sans canal clair pour signaler un doute. La seconde est technique : un correctif jamais appliqué, une configuration laissée par défaut, un réseau sans cloisonnement. C’est ici que se joue le vrai sujet. Si un salarié clique, c’est rarement par bêtise, c’est souvent parce qu’une condition latente l’y avait préparé : personne ne lui a appris à repérer le piège, et rien dans l’outil ne l’a arrêté. Il n’a pas créé le trou, il est tombé dedans.
Concrètement, une attaque s’appuie sur des faiblesses déjà là bien avant le moindre clic :
- une formation jamais budgétée, qui laisse les équipes sans réflexe face à un mail piégé ;
- une vulnérabilité connue laissée non corrigée, un correctif de sécurité jamais appliqué ;
- une procédure absente : aucun document ne dit qui fait quoi en cas d’incident ;
- une charge de travail qui pousse à traiter ses mails vite, sans vérifier ;
- des droits d’accès trop larges, accordés par facilité et jamais revus ;
- un réseau à plat, sans cloisonnement, où un seul point d’entrée donne accès à tout.
Toutes ne relèvent pas d’une faute. Certaines faiblesses sont inhérentes à des systèmes complexes, et une faille peut exister sans qu’aucune mauvaise décision n’ait été prise. Mais la plupart résultent d’un choix repoussé ou d’un contrôle oublié. L’erreur active, c’est le « bout pointu » du problème, celui qu’on voit. La cause latente, humaine ou technique, c’est le « bout émoussé », décidé ou laissé en place en amont. Punir le premier sans toucher au second revient à éponger l’eau sans fermer le robinet.
| Critère | Erreur active | Cause latente |
| Origine | L’utilisateur final, au contact du système | Une décision en amont, qui se dépose en conditions humaines et techniques |
| Quand ? | Au moment de l’incident | Des mois avant, en sommeil dans le système |
| Visibilité | Immédiate, évidente | Cachée, silencieuse tant que rien n’arrive |
| Versant humain | Le clic, le mot de passe partagé | Équipe non formée, surchargée, sans canal de signalement |
| Versant technique | Une clé USB inconnue branchée | Faille non corrigée, réseau non cloisonné, config par défaut |
| Levier de correction | Vigilance au quotidien | Décisions en amont : budget, formation, correctifs, architecture |
Lu ainsi, le salarié qui a cliqué n’est pas la cause de l’attaque. Il en est le révélateur. Il a simplement montré, à un instant donné, que les trous étaient déjà alignés, dans les têtes comme dans les serveurs.
Anatomie d’une cyberattaque, quand les trous s’alignent
Prenons un scénario classique de PME, sans aucune fatalité. Un mail frauduleux imite un fournisseur connu et demande de « confirmer ses accès ». Voici les trous qui ont dû s’aligner pour que ce simple mail vire à la catastrophe :
- Le filtre de messagerie a laissé passer le mail au lieu de le mettre en quarantaine.
- L’équipe n’avait jamais été formée à reconnaître une tentative d’hameçonnage, faute de formation à la cybersécurité prévue au budget.
- La double authentification n’était pas activée, donc le mot de passe volé a suffi à se connecter.
- Le mot de passe était réutilisé sur plusieurs services, démultipliant la portée de la fuite.
- Le compte était sur-privilégié : un accès basique donnait la main sur l’ensemble des données.
- Aucune supervision n’était en place, l’intrusion est restée invisible plusieurs jours.
- Les sauvegardes n’avaient jamais été testées, donc inexploitables le jour où il a fallu restaurer.
Retirez un seul de ces trous et l’attaque s’arrête net. Activez la double authentification, et le mot de passe volé ne sert plus à rien. Formez l’équipe, et le mail finit à la corbeille. C’est toute la leçon de Reason : on ne sécurise pas une organisation en traquant les erreurs humaines, on la sécurise en bouchant les trous, un par un, sur chaque tranche.
La défense en profondeur, multiplier les tranches

Si un incident grave suppose l’alignement de plusieurs trous, la parade est limpide : multiplier les tranches pour qu’aucun trou isolé ne suffise jamais à laisser passer une attaque. C’est le principe de la défense en profondeur. Reason ne l’a pas inventé, mais son modèle explique pourquoi il fonctionne : plus vous empilez de barrières indépendantes, plus la probabilité que tous les trous s’alignent un jour devient faible.
Ces tranches se répartissent sur trois plans qui se complètent. Côté humain, la sensibilisation régulière des équipes reste la première barrière, puisque c’est elle qui transforme un salarié de point faible en vigie. Côté organisation, ce sont les règles qui tiennent dans le temps : limitation des droits d’accès au strict nécessaire, sauvegardes testées et déconnectées, plan de réponse écrit et connu de tous. Côté technique, enfin, quelques barrières font une différence majeure : la double authentification, l’application régulière des correctifs de sécurité pour ne pas laisser une faille connue ouverte, le cloisonnement du réseau pour qu’un point d’entrée ne donne pas accès à tout, et le durcissement des configurations par défaut.
Aucun de ces trois plans ne suffit seul. Une équipe parfaitement formée ne compense pas un serveur jamais mis à jour, et le meilleur pare-feu ne protège pas d’un mot de passe partagé sur un coin de bureau. C’est leur empilement qui fait la solidité. La double authentification illustre bien ce rapport coût-efficacité : elle bloque la quasi-totalité des tentatives de connexion à partir d’un mot de passe volé, pour un coût de déploiement marginal. Vous retrouverez l’essentiel de ces réflexes, humains comme techniques, dans les bonnes pratiques de cybersécurité pour les PME que nous détaillons sur le blog.
La beauté de cette approche, c’est qu’elle ne repose jamais sur la perfection d’un seul élément. Elle accepte que chaque barrière soit imparfaite, et compense par le nombre et l’indépendance des barrières. Une personne peut se tromper, un correctif peut tarder, un filtre peut faillir, et l’attaque sera quand même stoppée plus loin.
Sortir de la culture du blâme
Chercher un coupable après un incident est une réaction humaine, mais c’est une catastrophe pour la sécurité. Une organisation qui punit l’erreur enseigne une seule chose à ses équipes : cacher les incidents. Le salarié qui réalise qu’il a cliqué sur un lien douteux se tait par peur des reproches, et vous perdez les heures les plus précieuses pour réagir. La peur du blâme fabrique du silence, et le silence fabrique des attaques réussies.
À l’inverse, la « just culture », ou culture de la responsabilité juste, sépare la faute intentionnelle de l’erreur honnête. Elle traite l’erreur comme une information sur l’état du système, pas comme une faute morale. Dans une telle organisation, un salarié qui signale immédiatement son clic malheureux est un atout, pas un fautif. C’est ce signalement rapide qui permet d’isoler un poste, de couper un accès et de limiter les dégâts. Le modèle de Reason ne dédouane pas l’individu de toute vigilance, il replace simplement sa part de responsabilité à sa juste mesure, et concentre l’effort là où il est vraiment utile : sur le système.
Le Classeur Cyber, donner une forme concrète à vos tranches de fromage

Le modèle de Reason reste une grille de lecture tant qu’il n’est pas outillé. C’est là qu’intervient le Classeur Cyber, le document de référence qui rassemble au même endroit tout ce qui fait tenir votre dispositif. Documenter ses barrières, ce n’est pas faire de la paperasse, c’est déjà boucher des trous. Une procédure qui existe sur le papier mais que personne ne connaît est un trou. Une procédure écrite, partagée et répétée est une tranche solide.
Le Classeur Cyber réunit les éléments qui, le jour de l’incident, font la différence entre une gestion maîtrisée et l’improvisation totale :
- Les procédures de crise : qui fait quoi, dans quel ordre, dès la première heure.
- Le plan de continuité et de reprise, pour savoir comment continuer à travailler systèmes coupés.
- Les fiches réflexes, des modes d’emploi courts à dégainer sous stress.
- Le registre RGPD et la chaîne d’alerte, indispensables car une violation de données personnelles impose une notification à la CNIL sous 72 heures.
- Les contacts utiles : prestataire, assureur cyber, autorités, référent interne.
Le jour J, une PME qui a son Classeur Cyber sait qui prévenir, dans quel ordre et sous quel délai. Une PME qui ne l’a pas découvre, en pleine panique, que l’absence de procédure était elle aussi un trou qui n’attendait que de s’aligner. C’est cette logique qui structure notre guide de survie cyber pour les PME du Grand Est, pensé pour des dirigeants qui veulent du concret, pas de la théorie.
Questions fréquentes
Le modèle de Reason, c’est quoi en une phrase ? C’est l’idée qu’un accident grave ne survient jamais à cause d’une seule défaillance, mais quand les faiblesses de plusieurs barrières de sécurité s’alignent au même moment, comme les trous de tranches de fromage suisse empilées.
L’erreur humaine est-elle vraiment responsable des cyberattaques ? Elle est souvent le déclencheur visible, rarement la cause profonde. Le clic d’un salarié n’a de conséquences que parce que des conditions étaient déjà réunies en amont : personne ne l’avait formé, et aucune barrière technique n’a bloqué la suite. Le système porte la responsabilité principale.
Quelle différence entre erreur active et cause latente ? L’erreur active est commise au moment de l’incident par l’utilisateur final (cliquer, saisir un mot de passe). La cause latente est une faiblesse installée bien avant, sous une forme humaine (équipe non formée, surchargée) ou technique (faille non corrigée, réseau non cloisonné). C’est elle qui rend l’erreur active possible.
La défense en profondeur, est-ce réservé aux grandes entreprises ? Non. Pour une PME, empiler quelques barrières simples sur les trois plans (sensibilisation, droits limités et sauvegardes, double authentification et mises à jour) coûte peu et réduit massivement le risque. C’est l’inverse d’un investissement réservé aux grands groupes.
À quoi sert concrètement un Classeur Cyber après une attaque ? Il vous dit immédiatement qui prévenir, dans quel ordre et sous quel délai, comment continuer à travailler et comment notifier les autorités dans les temps. Il transforme la panique en procédure, et fait gagner les heures qui comptent le plus.
Penser la sécurité comme un système, pas comme un coupable
Le modèle de Reason change radicalement la manière de regarder un incident. Tant que vous cherchez un coupable, vous restez aveugle aux failles réelles, humaines comme techniques, et vous condamnez votre entreprise à revivre le même scénario. Le jour où vous regardez votre sécurité comme un système de tranches à renforcer, chaque incident devient une information utile, chaque trou repéré devient une barrière de plus. Vous ne cherchez plus qui a cliqué, vous cherchez ce qui a permis au clic de coûter cher, et vous le corrigez.
C’est exactement la posture que nous adoptons chez Zetruc. Depuis 20 ans, nous accompagnons les dirigeants de TPE et de PME avec une approche concrète, sans jargon : identifier vos trous, empiler les bonnes barrières, formaliser votre Classeur Cyber et former vos équipes pour qu’elles deviennent une tranche solide plutôt qu’un point faible. Si vous voulez savoir où sont vos trous avant qu’un attaquant ne les trouve à votre place, faisons le point ensemble.