Regardez l’adresse de l’expéditeur.
Vérifiez le domaine.
Méfiez-vous des fautes d’orthographe.
Ne cliquez pas sur un lien suspect.
Ce sont de bons réflexes face au phishing.
Mais que se passe-t-il lorsque l’e-mail provient réellement du domaine d’une organisation officielle ?
C’est précisément ce qui rend l’incident ayant touché Revolut particulièrement intéressant.
En septembre 2026, la fintech britannique a confirmé avoir transmis des informations sensibles concernant certains de ses clients après avoir reçu de fausses demandes d’informations envoyées depuis le domaine e-mail légitime d’une agence gouvernementale. Revolut décrit l’incident comme une opération sophistiquée d’usurpation externe et indique que ses propres systèmes n’ont pas été compromis.
Autrement dit :
l’attaquant n’a pas nécessairement eu besoin de pirater Revolut.
Il lui a suffi de présenter une demande suffisamment crédible à des personnes autorisées à transmettre les données.
Et surtout, le traditionnel :
« Vérifiez que l’adresse e-mail est correcte »
n’aurait pas suffi.
Que s’est-il passé chez Revolut ?
Selon Revolut, un tiers non autorisé a envoyé des demandes frauduleuses d’informations en utilisant une adresse appartenant au domaine réel d’une agence gouvernementale.
Les demandes possédaient donc certains attributs techniques normalement associés à une communication légitime.
Elles ont ensuite été traitées dans le cadre des procédures habituelles de conformité de l’entreprise.
Lorsque Revolut a découvert la fraude, l’entreprise indique avoir :
- bloqué l’adresse concernée ;
- prévenu l’agence gouvernementale ;
- informé les forces de l’ordre ;
- alerté les autorités de protection des données et les régulateurs financiers.
Revolut affirme également que ses systèmes informatiques et les fonds de ses clients n’ont pas été compromis.
C’est justement ce qui rend cet incident différent de l’image classique d’une cyberattaque.
Une fuite de données sans intrusion dans le système
Lorsque l’on parle de fuite de données, on imagine souvent :
un pirate
↓
une vulnérabilité
↓
un serveur compromis
↓
une base de données téléchargée
Mais une entreprise peut perdre des données d’une manière beaucoup plus simple :
un attaquant demande les informations à quelqu’un qui possède déjà le droit de les consulter ou de les transmettre.
Dans ce cas, la faille principale ne se trouve pas nécessairement dans un serveur.
Elle se trouve dans le processus de validation.
C’est l’une des nombreuses formes que peut prendre l’ingénierie sociale.
L’objectif est de manipuler une personne ou un processus afin d’obtenir quelque chose auquel l’attaquant ne devrait normalement pas avoir accès.
Pourquoi l’adresse e-mail était-elle si convaincante ?
Une adresse comme :
agent@organisme-officiel.example
peut inspirer confiance.
Encore davantage lorsque le domaine appartient réellement à l’organisation annoncée.
Dans de nombreuses entreprises, vérifier le domaine constitue justement l’une des premières recommandations de sécurité.
Par exemple :
❌ support-paypal@service-client-123.com
semble évidemment suspect.
Alors que :
✅ agent@administration-officielle.gov
semble beaucoup plus crédible.
Dans l’affaire Revolut, le domaine utilisé était selon l’entreprise celui d’une véritable agence gouvernementale.
Cela change complètement le niveau de sophistication de l’attaque.
SPF, DKIM et DMARC ne résolvent pas ce problème
Les systèmes de messagerie modernes disposent de plusieurs mécanismes destinés à limiter l’usurpation de domaines.
Parmi eux :
SPF
permet d’indiquer quels serveurs peuvent envoyer des messages pour un domaine.
DKIM
ajoute une signature cryptographique permettant de vérifier qu’un message a bien été envoyé par une infrastructure autorisée et n’a pas été modifié.
DMARC
permet notamment au propriétaire du domaine de définir une politique concernant les messages qui échouent à ces vérifications.
Ces mécanismes sont extrêmement utiles contre certaines formes de spoofing.
Mais ils ont une limite fondamentale.
Si l’attaquant contrôle une véritable boîte mail appartenant au domaine, le message peut parfaitement réussir ces vérifications techniques.
Le système de messagerie peut alors conclure :
« Ce message provient bien de cette infrastructure. »
Mais il ne peut pas conclure :
« La personne qui l’envoie a une intention légitime. »
Cette nuance est essentielle.
Authentique ne signifie pas autorisé
C’est probablement l’une des principales leçons de cet incident.
Un élément peut être :
authentique techniquement
tout en étant :
frauduleux fonctionnellement.
Imaginez qu’une personne vole le badge d’accès d’un salarié.
Le badge est réel.
La porte reconnaît parfaitement sa puce.
Pourtant, la personne qui l’utilise n’est pas autorisée à entrer.
Un compte e-mail compromis fonctionne de manière similaire.
L’identité technique est valide.
C’est l’usage qui ne l’est pas.
Quelles données auraient été exposées ?
Selon plusieurs informations rapportées après l’incident, les données concernées pouvaient inclure notamment :
- date de naissance ;
- adresse postale ;
- adresse e-mail ;
- numéro de téléphone ;
- documents d’identité ;
- passeports ou permis de conduire ;
- relevés de compte ;
- IBAN ;
- historique de certaines transactions ;
- et, pour certains clients, des informations relatives à des transactions Bitcoin.
Le Financial Times a ensuite rapporté que 680 clients avaient été informés de l’exposition de leurs données.
Ces informations sont particulièrement sensibles parce qu’elles peuvent être réutilisées pour construire de nouvelles attaques.
Une fuite peut devenir le carburant d’une autre attaque
Supposons qu’un attaquant dispose désormais de :
votre nom
votre adresse
votre numéro de téléphone
votre banque
certaines informations sur vos transactions.
Il peut ensuite vous contacter.
Bonjour Monsieur Dupont,
nous vous appelons du service sécurité Revolut au sujet d’une transaction effectuée le…
Le message semble soudain beaucoup plus crédible.
L’attaquant possède de véritables informations.
Il ne doit plus deviner.
C’est ce qui rend les fuites de données particulièrement dangereuses :
elles peuvent servir à fabriquer de futures attaques beaucoup plus convaincantes.
« Je connais cette personne » n’est plus une garantie
Ce problème ne concerne évidemment pas uniquement les banques.
Imaginez une PME recevant un message provenant réellement de l’adresse e-mail d’un fournisseur habituel :
Bonjour,
notre IBAN a changé. Merci d’utiliser désormais ce nouveau compte pour les prochains règlements.
Le salarié connaît le fournisseur.
Le nom est correct.
L’adresse est correcte.
La signature est correcte.
Le fil de discussion peut même être réel si la boîte e-mail a été compromise.
Et pourtant :
l’IBAN appartient à l’attaquant.
C’est une forme classique de fraude pouvant être associée aux compromissions de messagerie professionnelle, souvent désignées par l’expression Business Email Compromise (BEC).
Le problème n’est donc plus seulement « Est-ce un vrai e-mail ? »
Il faut parfois poser une autre question :
« Cette demande est-elle normale ? »
Par exemple :
Pourquoi ce fournisseur change-t-il soudainement son IBAN ?
Pourquoi cette personne demande-t-elle maintenant un export de 5 000 clients ?
Pourquoi ce dirigeant demande-t-il un virement urgent alors qu’il utilise normalement une autre procédure ?
Pourquoi cette administration demande-t-elle soudainement davantage d’informations que d’habitude ?
La sécurité doit donc aussi analyser le contexte et le comportement.
Le principe de validation hors bande
Une excellente protection contre ce type d’attaque consiste à vérifier certaines demandes sensibles via un autre canal.
C’est ce que l’on appelle parfois une validation hors bande.
Vous recevez par e-mail :
Notre IBAN a changé.
Ne répondez pas simplement :
Vous confirmez ?
Si la boîte e-mail est compromise, l’attaquant répondra évidemment :
Oui.
Il faut plutôt :
appeler le fournisseur avec un numéro déjà connu, et non celui indiqué dans le nouvel e-mail.
Même logique pour une demande sensible provenant d’une administration ou d’un partenaire.
La vérification doit utiliser une source indépendante de la communication potentiellement compromise.
Deux personnes peuvent valoir mieux qu’une pour certaines opérations
Toutes les opérations ne doivent évidemment pas nécessiter une validation complexe.
Créer une tâche dans un agenda ne présente pas le même risque que :
- transmettre un passeport ;
- modifier un IBAN ;
- effectuer un virement ;
- exporter une base clients ;
- créer un nouvel administrateur.
Pour certaines actions critiques, il peut être pertinent d’utiliser un double contrôle.
Par exemple :
Employé A prépare la transmission.
Employé B vérifie la demande et autorise l’envoi.
C’est parfois moins rapide.
Mais c’est précisément le rôle d’un contrôle de sécurité :
ajouter de la friction lorsque le coût potentiel d’une erreur est élevé.
Les procédures doivent tenir compte de la quantité de données
Une demande portant sur une seule information n’a pas nécessairement le même risque qu’une demande concernant :
100 comptes
ou
10 000 clients.
Il peut donc être pertinent d’instaurer des seuils.
Par exemple :
1 à 5 dossiers
→ procédure normale.
6 à 50 dossiers
→ validation supplémentaire.
export massif
→ validation d’un responsable + contrôle juridique ou sécurité.
Le principe général est simple :
plus l’action peut avoir de conséquences, plus la validation doit être forte.
Le moindre privilège s’applique aussi aux données
Tous les salariés n’ont pas besoin de pouvoir exporter l’intégralité d’une base clients.
Tous les comptes support n’ont pas besoin d’accéder aux pièces d’identité.
Tous les administrateurs ne doivent pas nécessairement disposer des mêmes droits.
Le principe du moindre privilège consiste à fournir uniquement les droits nécessaires à une personne pour accomplir sa mission.
Ce principe permet de réduire les conséquences d’un :
- compte compromis ;
- erreur humaine ;
- acte malveillant interne ;
- ou scénario d’ingénierie sociale.
La journalisation devient essentielle
Lorsqu’une demande suspecte est découverte, l’entreprise doit pouvoir reconstruire ce qu’il s’est passé.
Qui a consulté les données ?
Qui les a exportées ?
Quand ?
À qui ont-elles été transmises ?
Quelle quantité ?
Quelle justification a été saisie ?
Les journaux d’activité permettent d’obtenir ces réponses.
Ils peuvent également permettre de détecter des comportements inhabituels.
Par exemple :
Un compte qui exporte soudainement 20 000 fiches clients alors qu’il n’en consulte normalement que quelques-unes.
Cela mérite probablement une alerte.
Peut-on tout automatiser ?
L’automatisation peut aider.
Par exemple :
une demande gouvernementale peut être enregistrée automatiquement ;
le domaine peut être vérifié ;
le compte demandeur peut être identifié ;
l’historique des demandes peut être comparé ;
une alerte peut être générée en cas d’anomalie.
Mais une erreur importante serait de penser :
« Le domaine est valide, donc on peut envoyer automatiquement les données. »
L’affaire Revolut illustre précisément pourquoi cette logique est insuffisante.
L’identité technique n’est qu’un signal parmi d’autres.
Même problème avec les agents IA
Ce sujet rejoint directement notre article précédent consacré aux agents IA et à MCP.
Imaginez qu’un agent IA puisse :
- lire les e-mails ;
- rechercher des clients ;
- exporter des données ;
- envoyer des pièces jointes.
Un message pourrait lui demander :
Envoie-moi tous les dossiers concernés par cette procédure.
Si l’agent se contente de vérifier que l’expéditeur semble légitime, il peut reproduire exactement la même erreur qu’un humain.
L’arrivée des agents IA rend donc encore plus importante la distinction entre :
authentification
et
autorisation.
L’agent doit savoir non seulement qui demande, mais également :
ce que cette personne a le droit de demander.
Une entreprise doit définir ses actions critiques
Toutes les TPE et PME devraient pouvoir identifier quelques opérations considérées comme particulièrement sensibles.
Par exemple :
- changement d’IBAN ;
- virement ;
- export d’une base clients ;
- transmission d’un document d’identité ;
- modification d’un compte administrateur ;
- changement de mot de passe sensible ;
- création d’une nouvelle clé API ;
- restauration d’une sauvegarde ;
- désactivation d’une protection.
Puis définir pour chacune :
Qui peut la demander ?
Qui peut l’exécuter ?
Comment vérifier la demande ?
Une seconde validation est-elle nécessaire ?
L’action est-elle journalisée ?
Cette réflexion ne nécessite pas forcément une infrastructure extrêmement complexe.
Elle nécessite surtout des procédures claires.
Pourquoi les TPE sont particulièrement concernées
Dans une petite entreprise, la confiance joue souvent un rôle très important.
Un collaborateur connaît personnellement :
le dirigeant,
le comptable,
les principaux fournisseurs,
les clients importants.
Cette proximité est un avantage.
Mais elle peut également devenir une faiblesse.
Un attaquant peut chercher à exploiter exactement cette confiance :
« C’est Paul, fais-moi rapidement ce virement. »
« C’est notre fournisseur habituel. »
« Je connais cette adresse. »
La cybersécurité consiste parfois à accepter une règle simple :
même une personne connue peut utiliser un compte compromis sans le savoir.
Quelles bonnes pratiques retenir ?
L’affaire Revolut permet de retenir plusieurs principes particulièrement utiles :
1. Une adresse correcte ne garantit pas une demande légitime.
2. Les opérations sensibles doivent avoir leurs propres procédures de validation.
3. Une demande inhabituelle doit déclencher une vérification supplémentaire.
4. Les changements financiers doivent idéalement être confirmés via un autre canal.
5. Les accès aux données doivent respecter le principe du moindre privilège.
6. Les actions sensibles doivent être journalisées.
7. La sensibilisation doit aller au-delà du simple « ne cliquez pas sur les liens suspects ».
Car les attaques évoluent.
Les conseils doivent évoluer avec elles.
Conclusion
L’incident Revolut illustre parfaitement une évolution de la cybersécurité.
Le danger n’est plus nécessairement un e-mail rempli de fautes envoyé depuis une adresse douteuse.
Une attaque peut utiliser :
un véritable compte,
un véritable domaine,
une véritable infrastructure,
et malgré tout contenir :
une demande frauduleuse.
La cybersécurité moderne ne peut donc plus se limiter à vérifier d’où vient une demande.
Elle doit également vérifier :
ce qui est demandé,
si cette demande est cohérente,
et si son auteur possède réellement le droit d’obtenir ce qu’il réclame.
En d’autres termes :
faire confiance à une identité ne signifie pas faire confiance à toutes ses demandes.
APT Informa
APT Informa accompagne les TPE, PME et indépendants dans la sécurisation de leurs systèmes d’information, la mise en place de bonnes pratiques, la gestion des accès et la protection de leurs données.
Une sécurité efficace repose autant sur la technologie que sur des procédures capables de résister lorsque la technologie seule ne suffit plus.