Le taux de clic plaît parce qu’il tient dans une case. Il devient vite trompeur lorsqu’on lui demande de résumer toute une défense. Un clic, une saisie de mot de passe, une connexion réussie et une fraude sont quatre événements différents.
- Expositionla demande a été reçue
- Action risquéeclic, saisie ou approbation
- Passage techniquele contrôle laisse ou bloque
- Effet simulécapacité réellement obtenue
Une erreur humaine peut finir par un blocage
Le cas Cloudflare l’illustre bien. Trois personnes ont saisi leurs identifiants sur une fausse page, mais les clés physiques exigées par les applications ont empêché l’accès décrit par l’entreprise. Le taux de saisie mesure l’efficacité du leurre. Le blocage mesure la résistance du système après cette première erreur.
Les deux chiffres sont utiles. Les confondre pousse soit à ignorer un message convaincant, soit à déclarer la défense inutile alors qu’elle a précisément arrêté l’attaque. J’ai donc repris dans le mémoire une chaîne en quatre étapes : exposition, action risquée, passage technique et effet final.
Le dénominateur change le sens du chiffre
« 12 % de clics » ne veut pas dire grand-chose sans savoir qui a reçu le message. Le taux calculé parmi tous les salariés diffère du taux calculé parmi les messages réellement livrés. De la même façon, un blocage après erreur doit être mesuré parmi les tentatives qui ont atteint le contrôle, pas parmi toute l’entreprise.
Chaque indicateur devrait garder sa population, sa période et son unité. Cela paraît banal, mais c’est souvent à cet endroit qu’un tableau de bord transforme une observation locale en conclusion générale.
La difficulté du leurre compte aussi. Le NIST Phish Scale propose de décrire les indices visibles et l’adéquation du prétexte à son destinataire. Deux campagnes n’ont rien de comparable si l’une ressemble à un test évident et l’autre à une demande parfaitement intégrée au travail du jour. La méthode vise le courriel ; pour un appel ou une visioconférence, il faut décrire autrement le rôle joué, le prétexte et l’action demandée.
Mesurer le signalement et la réponse
Un salarié peut cliquer puis signaler immédiatement. Ce signalement rapide peut permettre de bloquer le domaine, prévenir les autres destinataires et chercher les comptes déjà touchés. Une organisation qui ne mesure que le clic classe pourtant cette contribution comme un échec pur.
Je suivrais au moins deux délais : du signalement à la première action utile, puis de cette action à la preuve que l’accès a pris fin. Une moyenne seule peut cacher un cas très lent. La médiane et un quantile élevé donnent une vue plus honnête lorsque l’échantillon le permet.
La réponse dépend de l’objet exposé. Après un vol de session, changer le mot de passe ne prouve pas que les jetons sont révoqués. Après une autorisation OAuth trompeuse, il faut examiner les consentements et les applications. Après une fraude au paiement, le circuit financier doit agir sans attendre une preuve de compromission informatique qui n’existe peut-être pas.
La formation mérite mieux qu’un score automatique
Une étude menée pendant quinze mois auprès de plus de 14 000 salariés a questionné l’effet de certaines formations intégrées aux simulations et montré l’intérêt du signalement collectif. Une prépublication de 2025, portant sur 12 511 participants dans une entreprise de technologie financière, n’a pas observé d’amélioration significative des clics ou des signalements pour les formats testés.
Ces travaux ne prouvent pas que toute formation est inutile. Ils rappellent que la participation à un module ou la mémorisation d’une règle ne suffit pas à démontrer une baisse du risque. Il faut préciser l’effet attendu, comparer des scénarios de difficulté proche et séparer les changements de formation des nouveaux filtres ou contrôles techniques.
La formation gagne aussi à suivre les métiers. L’assistance travaille la récupération de compte, la finance les changements de bénéficiaire, les administrateurs les sessions et les délégations, et l’ensemble des utilisateurs le signalement. Tout le monde n’a pas besoin d’apprendre le détail d’OAuth pour savoir quand interrompre une demande et utiliser un canal connu.
Un protocole simple et inoffensif
Une simulation utile peut rester sans danger : aucun vrai mot de passe, aucun accès externe et aucun paiement ne sont nécessaires. Les critères sont décidés avant l’essai. On note ce qui a été livré, ce qui a été fait, ce que le système a bloqué, ce qui a été signalé et le temps nécessaire pour contenir la situation.
Il faut également mesurer la gêne : faux positifs, délais légitimes, tickets de support et exceptions créées. Un contrôle qui bloque bien pendant un test mais pousse tout le monde vers une procédure de secours permanente finira par déplacer le risque.
Un score parfait dirait peu de choses à lui seul. Les questions utiles sont plus concrètes : quelle transition est protégée, comment l’a-t-on vérifié et que reste-t-il possible après le contrôle ?