38 % et 88 % ne répondent pas à la même question
Selon le Cyber Security Breaches Survey 2025/2026, 38 % de l’ensemble des entreprises britanniques ont identifié un hameçonnage. Parmi les entreprises ayant identifié une attaque ou une atteinte à la sécurité, ce chiffre atteint 88 %. Il s’agit de la même enquête, mais de deux groupes différents.
Publié le 30 avril 2026, le rapport repose sur une enquête pondérée auprès de 2 112 entreprises, interrogées d’août à décembre 2025 sur les douze mois précédents. Une attaque identifiée n’est pas nécessairement une intrusion réussie ; l’activité non détectée échappe à la mesure. Ces résultats concernent le Royaume-Uni. La question pratique est de savoir quelle action un message suspect peut déclencher dans votre entreprise. [1]
de l’ensemble des entreprises britanniques
des entreprises ayant identifié au moins une attaque ou une atteinte à la sécurité
Identifié ne signifie pas réussi
Les chiffres couvrent les attaques par hameçonnage identifiées, tentatives comprises. Ce ne sont ni des taux de réussite des attaquants, ni des estimations pour l’Allemagne ou le monde entier.
Source : DSIT · Cyber Security Breaches Survey 2025/2026 · publié le 30 avril 2026
Échantillon : 2 112 entreprises ; sous-groupe ayant identifié une attaque ou une atteinte à la sécurité : 1 026. Résultats pondérés.
Royaume-Uni · enquête d’août à décembre 2025
Part des entreprises ayant identifié un hameçonnage dans les douze mois précédant leur entretien. Les dénominateurs diffèrent : ces pourcentages ne s’additionnent pas et ne représentent pas une évolution dans le temps.
Protéger le domaine limite une forme d’usurpation
SPF, DKIM et DMARC aident les services destinataires à vérifier qu’un message est autorisé à utiliser un domaine. DMARC relie le domaine visible de l’expéditeur à un contrôle SPF ou DKIM aligné et publie la conduite souhaitée en cas d’échec. Une politique de rejet appliquée rend plus difficile l’usurpation de ce domaine précis. Elle ne garantit ni l’identité de l’auteur ni la véracité du contenu.
Commencez par les expéditeurs légitimes : boîtes mail, logiciel de facturation, newsletters et prestataires. Vérifiez leur authentification avant de durcir la politique. Un domaine ressemblant enregistré par un tiers n’est pas couvert par votre règle DMARC. Les messages envoyés depuis une vraie boîte compromise peuvent aussi réussir les contrôles de domaine. [2] [3] [5]
La boîte mail exige son propre contrôle d’accès
L’authentification multifacteur protège l’accès au compte. CISA recommande des méthodes résistantes à l’hameçonnage, telles que FIDO2/WebAuthn, qui lient l’authentification au service prévu. Un code à usage unique n’offre pas la même résistance.
La vérification doit aller au-delà de la simple activation de la MFA. Quels comptes sont couverts ? Quelles méthodes de connexion restent autorisées ? Comment fonctionne la récupération ? Commencez par les administrateurs et les comptes traitant des factures ou des données sensibles. Attribuez à chaque exception un responsable et une date de suppression. Même une connexion bien protégée ne valide pas le contenu d’une facture. [4]
Un nouveau compte bancaire doit être confirmé indépendamment
Lorsque les coordonnées bancaires changent, le contrôle décisif appartient au processus de paiement. Le FBI recommande de vérifier ces modifications directement auprès du demandeur. Utilisez un numéro déjà connu ou un autre canal convenu auparavant. Le numéro indiqué dans l’e-mail douteux ne constitue pas une source indépendante.
Répondre dans le même fil ne suffit pas non plus si quelqu’un contrôle la boîte. Nous recommandons de consigner la vérification avant de modifier les coordonnées et, lorsque l’effectif le permet, de confier la vérification et l’autorisation de paiement à des personnes différentes. L’urgence ne doit pas suspendre la règle. Sinon, l’exception devient le moyen le plus simple de contourner le contrôle. [5] [6]
Associer chaque protection à son scénario
Ces contrôles se complètent. Leur distinction permet de traiter une lacune précise sans attendre d’un seul réglage une protection complète. [2] [3] [4] [5] [6]
Faites défiler le tableau horizontalement.
| Méthode d’attaque | Contrôle adapté | Limite |
|---|---|---|
| Usurpation exacte de votre domaine | SPF/DKIM et politique DMARC appliquée | Ne couvre pas les domaines ressemblants distincts |
| Accès à une vraie boîte obtenu par hameçonnage | MFA résistante à l’hameçonnage | Ne valide pas le contenu des factures |
| Domaine ressemblant ou nom affiché familier | Filtrage et vérification par un autre canal | Un nom familier ne prouve pas l’identité |
| Coordonnées bancaires modifiées dans une demande | Confirmation indépendante avant autorisation | Les exceptions doivent aussi être vérifiées |
Faire examiner la même demande par l’informatique et la comptabilité
Pour une courte revue interne, utilisez une demande explicitement fictive de changement de coordonnées bancaires d’un fournisseur. L’informatique explique les contrôles d’expéditeur qui seraient visibles. La comptabilité montre où trouver un numéro fiable pour rappeler et qui autorise la modification. Ne modifiez aucune donnée de paiement réelle.
Consignez les responsabilités manquantes et la prochaine action concrète. Une liste d’expéditeurs incomplète, une connexion non protégée et un changement bancaire non vérifié sont trois tâches distinctes. Les séparer transforme une demande générale de meilleure protection en actions que l’on peut attribuer et mener à terme.
Sources
- DSIT · Cyber security breaches survey 2025/2026 · 30 April 2026
- NCSC UK · Email security and anti-spoofing
- NCSC Netherlands · Protect domains against phishing · version 2.0
- CISA · Implementing Phishing-Resistant MFA
- FBI · Business Email Compromise
- NCSC UK · Phishing attacks: defending your organisation