Décisions de sécurité informatique : Pourquoi les dirigeants créent les vulnérabilités qu’ils veulent éviter

L’authentification multi-facteurs est devenue un standard :

• Mot de passe + code SMS,
• Mot de passe + application d’authentification,
• Mot de passe + clé physique.

Sur le papier, c’est une évidence : multiplier les barrières réduit les intrusions. Dans la réalité organisationnelle, l’histoire est plus complexe. Chaque couche de sécurité supplémentaire produit un effet secondaire : la friction. Dans un système humain sous pression, celle-ci génère des contournements.

Ce paradoxe n’est pas un problème informatique. C’est un problème de décision systémique, et il appartient au dirigeant, pas au DSI.

La décision du dirigeant vs la réalité du terrain

Les directions IT raisonnent en termes de probabilité d’attaque : plus il y a d’étapes d’authentification, plus il est difficile d’accéder au système. Ce raisonnement est techniquement correct. Mais il néglige une variable centrale : le comportement adaptatif des utilisateurs.

Dans un système humain, toute contrainte excessive produit une réponse compensatoire, et cette réponse est souvent invisible jusqu’à l’incident. Le dirigeant qui valide un renforcement sécuritaire sans modéliser cette réponse prend une décision incomplète. Il a résolu un problème technique en créant un problème comportemental.

C’est le même mécanisme que Nokia validant des actions marketing sans toucher à son architecture décisionnelle, ou qu’une direction générale annonçant un repositionnement premium sans modifier les incitations des commerciaux. La solution tentée aggrave le problème qu’elle voulait résoudre.

La boucle sécurité / contournement

La dynamique est constante dans les organisations :

• une faille ou une attaque survient,
• l’organisation renforce la sécurité,
• les utilisateurs rencontrent des frictions quotidiennes,
• ils développent des raccourcis,
• ces raccourcis créent de nouvelles vulnérabilités,
• l’organisation renforce encore.
• La boucle se referme.

Ce n’est pas un problème technique. C’est un problème d’interaction entre système technique et système humain, une propriété émergente d’une décision prise au mauvais niveau d’analyse.

Six cas d’entreprise révélateurs

1. Les post-its sous le clavier

Une entreprise impose des mots de passe complexes renouvelés tous les 60 jours, couplés à un code SMS. Résultat : les collaborateurs notent leurs identifiants sur papier. La sécurité formelle augmente. La sécurité réelle diminue.

2. Le partage de téléphone pour les codes MFA

Dans une PME industrielle, l’accès au logiciel de gestion nécessite un code sur smartphone personnel. Certains employés refusent d’utiliser leur téléphone privé. Un seul numéro est alors utilisé pour plusieurs comptes. Un facteur censé individualiser l’accès devient mutualisé.

3. Le contournement via comptes génériques

Dans une équipe support, la double authentification ralentit la prise en charge des tickets. Un compte générique partagé est créé pour aller plus vite. La traçabilité disparaît.

4. L’épuisement cognitif

Dans une entreprise internationale, chaque outil impose sa propre méthode MFA : application différente, clé différente, fréquence différente.

Les collaborateurs accumulent les notifications. Certains valident mécaniquement sans vérifier l’origine. Dès lors, le phishing par validation devient possible. C’est exactement le mécanisme exploité chez Uber.

5. L’abandon des mises à jour

Une organisation déploie la MFA sur VPN. Les salariés en télétravail rencontrent des blocages techniques. Certains désactivent les mises à jour de sécurité pour éviter les incompatibilités. La couche supplémentaire génère une faille latérale.

6. L’ingénierie sociale amplifiée

Plus la sécurité est stricte, plus le support IT devient central. Des attaquants exploitent cette dépendance en se faisant passer pour des employés bloqués par la MFA. La rigidité technique renforce la vulnérabilité sociale.

Pourquoi ces contournements ne sont pas des erreurs humaines

Il est tentant de blâmer les utilisateurs mais ce serait une erreur d’analyse. Dans une lecture systémique, le contournement est une réponse rationnelle à une contrainte perçue comme excessive.

Les individus cherchent à préserver leur efficacité, réduire la complexité, éviter les interruptions. La sécurité n’est pas sacrifiée par négligence, elle l’est au profit de la fluidité parce que le système récompense la fluidité et punit la lenteur.

C’est la même logique que les commerciaux qui continuent à signer des deals PME alors que la stratégie dit « grands comptes ». Ils ne s’opposent pas à la direction, ils répondent à la régulation dominante. Ici, la régulation dominante est la productivité.

Les vulnérabilités nouvelles créées par la solution

Une MFA plus forte sur le papier peut être plus fragile dans le monde réel si elle augmente le nombre de situations où l’utilisateur doit improviser. Quatre mécanismes précis méritent l’attention du dirigeant.

1. La fatigue MFA (push bombing)

Si l’authentification se fait via notifications « Valider/Refuser », un attaquant peut bombarder l’utilisateur jusqu’à obtenir une validation par lassitude. Plus les notifications sont fréquentes, plus le cerveau traite l’alerte comme du bruit. C’est le cas Uber.

2. Les canaux de récupération faibles

Quand la MFA bloque l’accès, l’entreprise ouvre des voies de secours (hotline, reset par email, procédures d’urgence). Si ces voies sont mal contrôlées, elles deviennent le chemin le plus simple pour l’attaquant. La brèche n’est pas le mécanisme MFA, c’est la procédure de contournement officielle.

3. La dépendance au terminal

Téléphone perdu, batterie à plat, application cassée, changement de numéro. Ces incidents arrivent tous les jours. Si la MFA n’intègre pas une stratégie de continuité, les utilisateurs créent la leur : captures d’écran de codes, sauvegardes bricolées, partage de token.

Le BYOD sans cadre

Imposer une MFA sur téléphone personnel sans cadre clair crée du ressentiment et des bricolages. La sécurité technique se heurte à la sécurité psychologique : « on m’impose un outil, je reprends la main comme je peux. »

La décision que le dirigeant doit prendre et non le DSI

La sécurité ne doit pas être laissée uniquement aux équipes techniques.

C’est une décision d’arbitrage organisationnel qui implique trois variables que seul le dirigeant peut pondérer :

1. Le niveau de risque acceptable (quelle exposition est tolérable ?),
2. l’impact sur la productivité (quel coût humain est justifiable ?),
3. et la cohérence culturelle (ce dispositif est-il compatible avec la manière dont cette organisation fonctionne réellement ?).

Une décision purement technique sur ces trois variables produit un déséquilibre organisationnel. Le DSI optimise la sécurité alors que le dirigeant arbitre le système.

Grille de décision dirigeant : Six principes pour une sécurité viable

Conclusion : La sécurité est un problème de décision systémique, pas un problème technique

L’attaquant qui a pénétré les systèmes d’Uber en 2022 n’a pas cassé la MFA. Il a exploité la décision qui avait rendu la MFA insupportable pour les utilisateurs. La vulnérabilité n’était pas dans le code mais dans l’arbitrage.

Dans un système humain, toute contrainte produit une adaptation. Si cette adaptation prend la forme de contournements invisibles, la sécurité formelle augmente pendant que la vulnérabilité réelle se déplace.

C’est le même mécanisme que Nokia, que les réformes qui échouent, que les repositionnements commerciaux qui n’atterrissent pas. Une décision prise sans modéliser la réponse du système humain.

La question stratégique n’est donc pas d’identifier comment ajouter une couche supplémentaire mais comment concevoir une sécurité suffisamment robuste pour décourager l’attaque et suffisamment fluide pour éviter le contournement. C’est dans cet équilibre que réside la véritable résilience numérique.

Cet équilibre ne se trouve pas dans la salle serveur mais dans la salle de direction.

Si cette situation vous est familière, vous pouvez la cartographier directement avec l’outil d’investigation systémique.

Foire aux questions – FAQ

Comment savoir si notre dispositif de sécurité génère des contournements invisibles ?

Quatre signaux à surveiller sans attendre un incident : la prolifération de comptes génériques ou partagés (signe que la MFA individuelle est contournée), le nombre d’appels au support IT pour des problèmes d’accès (signe de friction excessive), les délais de traitement anormalement courts sur des tâches qui nécessitent normalement une authentification (signe de raccourcis), et les retours informels des managers de terrain (« les équipes trouvent ça trop lourd »). Ces signaux précèdent toujours l’incident parce-qu’ils ne sont simplement pas traités comme des indicateurs systémiques.

La décision de sécurité doit-elle vraiment remonter au dirigeant ou rester au DSI ?

Elle doit être co-construite, mais l’arbitrage final appartient au dirigeant dès lors qu’elle touche à la productivité, à la culture et au niveau de risque acceptable. Le DSI optimise techniquement. Il ne peut pas arbitrer seul entre sécurité et fluidité opérationnelle qui sont des variables organisationnelles, pas techniques. Un DSI qui décide seul d’un renforcement sécuritaire majeur sans validation dirigeante prend un risque organisationnel que l’organisation n’a pas consciencieusement accepté.

Comment expliquer à un board ou à un COMEX que plus de sécurité peut créer plus de vulnérabilités ?

Le cas Uber est l’argument le plus efficace. Un système MFA renforcé contourné en 10 minutes par un attaquant de 18 ans, précisément parce qu’il était trop contraignant. Complétez avec la question : « Combien de collaborateurs dans notre organisation valident mécaniquement des notifications MFA sans vérifier leur origine ? » Si personne ne connaît la réponse, c’est que le problème n’a pas encore été posé au bon niveau.

Faut-il réduire la sécurité pour réduire les contournements ?

Non, et c’est le faux dilemme à éviter. La solution n’est pas moins de sécurité, c’est une sécurité mieux conçue. Graduer les niveaux de protection selon la criticité réelle (tous les accès ne méritent pas le même niveau de friction), unifier les méthodes pour réduire la charge cognitive, et sécuriser les procédures de récupération plus que les accès eux-mêmes. L’objectif est un équilibre dynamique, pas un curseur à pousser dans un sens ou dans l’autre.

La culture d’entreprise influence-t-elle vraiment l’efficacité d’un dispositif de sécurité ?

Massivement. Une sécurité imposée après un incident, présentée comme une contrainte et non expliquée, génère systématiquement plus de contournements qu’une sécurité co-construite avec les utilisateurs et accompagnée de pédagogie sur les risques réels. Ce n’est pas de la sensiblerie managériale, c’est un constat opérationnel documenté. La perception modifie le comportement. La sécurité subie crée des adversaires internes alors que la sécurité comprise crée des alliés.

Références

Cybersécurité et comportements organisationnels

• CISA & FBI (2022) – Alert AA22-264A : MFA Fatigue Attacks – Cybersecurity and Infrastructure Security Agency (analyse officielle de l’attaque Uber 2022, mécanismes de MFA fatigue, recommandations)
• Anderson, R. (2020) – Security Engineering : A Guide to Building Dependable Distributed Systems – Wiley (référence fondamentale sur l’ingénierie de la sécurité, interaction systèmes techniques et humains)
• Sasse, M.A. & Flechais, I. (2005) – Usable Security : Why Do We Need It? How Do We Get It ? – O’Reilly (practicité de la sécurité, friction cognitive, comportements de contournement)

Décision organisationnelle et systèmes humains

• Crozier, M. & Friedberg, E. (1977) – L’acteur et le système – Éditions du Seuil (réponses adaptatives aux contraintes organisationnelles, zones d’incertitude, contournements comme réponse rationnelle)
• Dupuy, F. (2011) – Sociologie du changement – Dunod (résistances organisationnelles, régulations implicites, pourquoi les décisions managériales produisent l’inverse de l’effet voulu)

Facteur humain et sécurité des systèmes

• Reason, J. (1990) – Human Error – Cambridge University Press (erreurs systémiques vs erreurs individuelles, modèle du « fromage suisse », facteur humain dans les défaillances de sécurité)
• Hadnagy, C. (2011) – Social Engineering : The Art of Human Hacking – Wiley (ingénierie sociale, exploitation des comportements adaptatifs, vulnérabilités humaines)
• Mitnick, K. & Simon, W. (2002) – The Art of Deception – Wiley (manipulation sociale, contournement des dispositifs de sécurité par exploitation du comportement humain)

Gouvernance de la sécurité et rôle des dirigeants

• Jimenez, C. & Perez-Diaz, N. (2012) – Résilience : Connaître et surmonter les adversités – Dunod (résilience organisationnelle, conception de systèmes robustes face à l’adversité)
• ANSSI (2022) – Recommandations relatives à l’authentification multi-facteur et aux mots de passe – Agence Nationale de la Sécurité des Systèmes d’Information (référentiel francophone de référence sur la MFA, recommandations opérationnelles)

Articles similaires