Dans la nuit du 1er novembre, un groupe bancaire français de 5,8 millions de sociétaires et 211,5 milliards d'euros d'actifs a commencé à perdre de l'argent, discrètement. Pas sur les comptes de ses clients. Sur le sien.
Crédit Mutuel Arkéa a confirmé le 4 novembre avoir été victime d'une cyberattaque qui a permis à un tiers d'utiliser le compte de la banque elle-même pour émettre des virements vers d'autres établissements financiers, avant de convertir les fonds en stablecoins. La banque n'a pas confirmé le montant. L'enquêteur blockchain ZachXBT, qui avait signalé les retraits avant toute communication publique de la banque, l'estime à 118 millions d'euros au maximum, soit environ 133 millions de dollars, retirés en USDC et en USDT.
Relisez cette phrase : un braquage bancaire où aucun solde client n'a bougé, aucun coffre ne s'est ouvert, aucune carte n'a été clonée. L'attaquant n'a pas volé les clients de la banque. Il a emprunté l'identité de la banque pendant quelques heures et laissé le système financier faire le reste.
C'est la forme de la criminalité financière moderne, et elle devrait changer la façon dont chaque équipe de la région pense l'accès aux paiements.
Ce qui s'est réellement passé
La chronologie compte plus que le total.
- 1er novembre — des retraits frauduleux commencent sur des comptes de plateformes centralisées, ensuite rattachés à des transactions initiées du côté d'Arkéa.
- 2 novembre — ZachXBT publie une alerte sur un retrait non autorisé de grande ampleur, sans nommer l'établissement.
- 3 novembre — selon l'enquêteur, environ 30 millions de dollars ont déjà été blanchis. Aucune communication publique, donc aucun gel coordonné.
- 4 novembre — la banque révèle l'incident, déclare qu'il est « clos et sous contrôle » et assure à ses clients que leurs actifs ne sont pas affectés.
- 7 novembre — la FAQ de la banque confirme que l'attaquant a atteint son réseau directement via la plateforme d'un prestataire de services, et écarte sa filiale Fortuneo.
Les avoirs des clients sont restés intacts. Certains virements ont pris du retard. La banque indique travailler avec la police et les autorités judiciaires pour établir l'origine et le mode opératoire exacts.
Les dégâts ne relèvent donc pas d'une fuite de données au sens classique. Il s'agit d'un événement de liquidité exécuté à la vitesse de la machine, sur des rails bancaires parfaitement légitimes.
Le compte utilisé était celui de la banque
L'essentiel des budgets de sécurité dans la banque est organisé autour de la protection des clients. C'est là que pointe la régulation, là que tombent les audits, et là que va la couverture presse.
Mais les comptes corporate et de trésorerie d'une banque ne sont pas un détail. Ce sont ceux qui peuvent déplacer neuf chiffres en un après-midi sans qu'un humain ne signe quoi que ce soit à la main. Ils portent des instructions permanentes, des relations de correspondant bancaire et des identifiants d'API auxquels les autres établissements font confiance par défaut. Quand un attaquant obtient une session dans ce compte, les contrôles antifraude voient une contrepartie connue faire une chose connue.
Voler les clients un par un coûte cher. Le compte de l'institution elle-même est la cible à forte valeur, et il bénéficie souvent d'une surveillance comportementale plus faible que le retail, parce que « la banque sait ce qu'elle fait ».
La porte était un prestataire
Le point d'entrée, selon la FAQ de la banque, était la plateforme d'un prestataire de services. C'est la phrase que tout RSSI du Golfe devrait lire deux fois.
Les plateformes tierces ne sont plus une note de bas de page de la chaîne d'approvisionnement. Elles sont la couche opérationnelle : outils de trésorerie, orchestration des paiements, tableaux de bord de conservation, prestataires KYC, hébergement cloud et, de plus en plus, copilotes d'IA assis dans la même session avec les mêmes droits que l'équipe finance. Chacune est une porte. Chaque porte vaut ce que vaut l'identité derrière elle.
La question inconfortable n'est pas de savoir si votre fournisseur est sûr. C'est de savoir si vous pouvez prouver, pour chaque transaction, quel humain ou quel compte de service l'a initiée, depuis quel appareil, via quel saut tiers, avec quelle approbation. Si la réponse exige une chaîne d'e-mails et une semaine d'archéologie dans les logs, vous n'avez pas un contrôle. Vous avez un espoir.
La vitesse a décidé de la perte
Entre le premier retrait et la communication publique, il s'est écoulé environ trois jours. Trente millions de dollars ont bougé dans cette fenêtre, selon l'enquêteur, et l'argument avancé alors était direct : le silence a donné à l'attaquant le temps de blanchir.
La vitesse de révélation est désormais un contrôle de limitation des pertes. Les régulateurs européens s'y engagent déjà, et les attentes de notification d'incident aux Émirats se durcissent avec le reste de la pile de conformité. Une banque qui attend un récit parfait avant de décrocher le téléphone choisit une perte plus lourde.
La même logique vaut en interne. Un runbook d'incident qui exige un comité avant que quiconque puisse geler un canal de paiement n'est pas un runbook. C'est un délai avec une page de garde.
Cinq contrôles à construire ce trimestre
Vous n'avez pas besoin d'un bilan de 211 milliards pour être exposé à ce schéma. Toute entreprise capable d'envoyer de l'argent par API a la même faiblesse, simplement avec moins de zéros.
- Traitez les comptes de trésorerie sortants comme des joyaux de la couronne. Séparez-les du reste de l'IT corporate. Donnez-leur leur propre politique d'identité, leur propre supervision et leur propre astreinte.
- Attestez chaque session tierce. Journalisez quelle plateforme, quel compte de service et quelle validation humaine ont produit chaque instruction de paiement. Si un fournisseur ne peut pas le fournir requête par requête, il n'a rien à faire dans le chemin de paiement.
- Fixez des limites de vélocité qu'aucun humain ne peut valider d'un clic. Un paiement vers une nouvelle juridiction, converti en crypto ou au-delà d'un plafond glissant doit se mettre en pause de lui-même au lieu d'attendre un manager.
- Entraînez-vous à geler. Une fois par trimestre, mesurez le temps nécessaire pour suspendre un canal de paiement de bout en bout. Si cela dépasse une heure, l'attaquant gagne par défaut.
- Rédigez la communication à l'avance. Le communiqué, la notification au régulateur et le message aux clients doivent être prêts avant d'être nécessaires, pour que la première heure serve au confinement et non au comité.
Ce que cela signifie pour les équipes du Golfe
Arkéa est française, mais le mécanisme est transposable. Les banques, plateformes, fintechs et family offices du CCG fonctionnent sur les mêmes rails : relations de correspondant, règlement en stablecoins, tableaux de bord de trésorerie hébergés par des tiers et une couche croissante d'agents d'IA dans les flux de paiement.
La leçon n'est pas « durcir le périmètre ». La leçon est que le périmètre est aujourd'hui un ensemble de permissions détenues par des tiers, et que le joyau de la couronne est la capacité de l'institution elle-même à déplacer de l'argent. Auditez cela. Instrumentez cela. Posez un arrêt dur qui ne nécessite pas de déploiement pour se déclencher.
Parce que le prochain braquage ne ressemblera pas à une intrusion. Il ressemblera à un mardi ordinaire, exécuté depuis un compte légitime, via un partenaire de confiance, et terminé avant que la première réunion à ce sujet ne commence.
L'essentiel : si vous ne pouvez pas nommer, transaction par transaction, qui l'a autorisée et via quel tiers, vous n'êtes qu'à une session de fournisseur compromise de devenir l'étude de cas.