Le 4 novembre 2026, le Crédit Mutuel Arkéa a confirmé une attaque informatique ayant permis des opérations frauduleuses. Les attaquants ont utilisé le compte propre de la banque pour envoyer des fonds vers d'autres établissements. Ces fonds auraient ensuite été convertis en cryptomonnaies.
L'enquêteur ZachXBT, spécialiste des transactions sur blockchain, chiffre le détournement à 133 millions de dollars, soit environ 118 millions d'euros. Arkéa valide l'ordre de grandeur sans confirmer le montant. Une partie des fonds a été bloquée, et les avoirs des clients ne sont pas touchés.
Les attaquants ont agi depuis le compte de la banque
Dans un second communiqué, le groupe précise le chemin suivi. Les attaquants ne sont pas entrés par Fortuneo, sa banque en ligne, contrairement aux premières informations de presse. Ils sont passés par la plateforme d'un prestataire externe, puis ont atteint Arkéa directement. Aucun compte client n'a servi aux opérations.
La banque exclut une erreur humaine et parle d'une attaque sophistiquée venue de l'extérieur. Ses dispositifs ont repéré les activités suspectes et certaines transactions ont été suspendues par précaution. La quasi-totalité des virements différés a repris dans la matinée.
Le reste n'est pas public. Plus d'une semaine après les faits, on ignore le nom du prestataire, l'accès exploité et les contrôles contournés. Il serait donc hasardeux de désigner une faille. Le point d'entrée confirmé suffit pourtant à poser une question qui dépasse largement les banques.
Une intrusion se mesure à ce qu'elle permet de faire
Chez Bureau Vallée, des données clients ont été copiées chez un prestataire (nous l'avons raconté dans les données clients étaient aussi chez le prestataire). Chez Arkéa, l'accès a servi à exécuter des virements. Le même type de point d'entrée, deux incidents de nature différente : dans le premier, l'intrus emporte, dans le second, il agit.
Deux contrôles se partagent ce terrain. L'authentification vérifie qui se connecte. L'autorisation fixe ce que cette identité a le droit de faire. La première ne remplace jamais la seconde, et c'est souvent la seconde que l'on règle trop large.
La raison est banale. Un compte technique aux droits étendus facilite le développement initial : les tests passent, la connexion fonctionne, l'application part en production. Le jour où ce compte est compromis, l'attaquant n'a rien à casser. Il utilise les capacités déjà accordées.
Nous avons détaillé cet écart entre droits accordés et droits utiles dans vos automatisations IA fonctionnent, mais à quoi ont-elles accès.
Une opération autorisée peut quand même être anormale
Réduire les droits ne suffit pas toujours. Prenez une application chargée de mettre à jour les fiches fournisseurs. Elle fait habituellement quelques dizaines de modifications par jour. Un matin, elle en tente plusieurs milliers, dont des coordonnées de paiement.
La connexion est authentifiée. Les permissions autorisent techniquement ces opérations. Le comportement, lui, n'a rien de normal, et seul un contrôle indépendant des droits d'accès peut le repérer : un plafond de volume, une alerte sur un changement inhabituel, une seconde validation pour certaines opérations.
Dans une banque, ces contrôles prennent des formes très spécifiques. Dans une PME, ils peuvent rester simples :
- une application métier crée un nouveau fournisseur, mais demande une confirmation distincte avant de modifier son IBAN ;
- une plateforme B2B accepte automatiquement les commandes habituelles et met en attente celles qui dépassent un seuil ;
- une passerelle synchronise les stocks sans avoir le droit de toucher aux prix.
Rien de cela ne demande de valider chaque opération à la main, ce qui deviendrait vite intenable. Le but est de repérer les quelques opérations dont les conséquences justifient une protection de plus.
Une bonne architecture ne cherche pas seulement à empêcher l'intrusion. Elle limite aussi ce qu'une intrusion permet de faire.
La sécurité du prestataire et celle de son branchement sont deux questions
Le réflexe naturel consiste à choisir des prestataires reconnus, certifiés, dotés d'équipes de cybersécurité. Ce sont de bons critères. Ils ne répondent qu'à une seule des deux questions.
La première : le fournisseur protège-t-il correctement son infrastructure ? La seconde : que permettrait son accès à votre système s'il était compromis ? Une certification, un contrat de maintenance ou un engagement de disponibilité éclairent la première. Ils ne fixent pas les limites techniques d'une connexion.
Cette seconde question vous appartient, quelle que soit la taille du prestataire. Un prestataire ne devrait pas pouvoir faire davantage que ce que sa mission exige. Cette limite se règle dans le système, pas seulement dans le contrat.
Couper un accès se prépare avant l'incident
Le jour où un accès est compromis, trois questions arrivent en même temps. Savez-vous couper l'accès du prestataire sans arrêter toute votre activité ? Pouvez-vous retrouver les opérations qu'il a effectuées ? Vos journaux permettent-ils de distinguer les transactions légitimes des autres ?
Ces réponses se préparent à froid. Improvisées pendant l'attaque, elles ajoutent des heures d'incertitude, puis des jours de vérifications. Pendant ce temps, il faut chiffrer les pertes et prévenir les clients concernés. Selon les cas, il faut aussi rendre des comptes à votre banque, à votre assureur ou aux autorités.
Trois questions sur votre intégration la plus critique
Inutile de commencer par un audit de tout votre système d'information. Choisissez une intégration qui compte pour votre activité : ERP, e-commerce, CRM, logiciel comptable ou plateforme d'automatisation. Une fois ses droits inventoriés, posez ces trois questions avec votre responsable technique ou votre prestataire.
1. Quelles opérations auraient des conséquences importantes ?
Modifier un bénéficiaire de paiement, supprimer des commandes ou exporter le fichier client n'a pas le même poids que consulter un statut de livraison. Ces actions-là méritent une limite ou une validation indépendante.
2. Comment verrions-nous un usage anormal ?
Les opérations sont-elles journalisées ? Quelqu'un serait-il prévenu d'un volume inhabituel de modifications, ou d'une connexion depuis un environnement inattendu ?
3. Pouvons-nous couper cet accès tout de suite ?
Qui peut le révoquer, et quels services s'arrêteraient ? Combien de temps faudrait-il pour revenir à un fonctionnement maîtrisé ?
Les réponses débouchent souvent sur des ajustements modestes : une permission réduite, deux comptes techniques séparés, une alerte, une procédure de révocation écrite. En cas de compromission, ce sont eux qui font la différence.
La confiance a besoin de limites vérifiables
L'enquête dira, si elle aboutit, comment l'accès du prestataire a mené jusqu'aux virements. La banque indique que ses dispositifs ont permis de contenir l'attaque. Une leçon, en tout cas, ne dépend pas de ces conclusions.
Un système d'entreprise n'est plus un ensemble de logiciels juxtaposés. C'est un réseau de permissions, de dépendances et de décisions automatiques, dont chaque partenaire tient un fil. La prochaine fois que vous connecterez un outil à une application métier, ne vous demandez pas seulement s'il fonctionne.
Demandez-vous aussi ce qu'il pourrait faire si quelqu'un d'autre prenait sa place.
Auteur · B.Coquisart - Chef de projet