Le 4 novembre 2026, le Crédit Mutuel Arkéa a confirmé une attaque passée par la plateforme d’un prestataire. Les transactions frauduleuses ont concerné son compte propre, pas les comptes de ses clients. Pour une entreprise qui connecte des agents à sa trésorerie, la question utile porte sur les pouvoirs transmis aux fournisseurs.
Les faits confirmés, sans gonfler le montant
Arkéa indique que les attaquants sont passés par la plateforme d’un prestataire non nommé, et non par Fortuneo. Selon le groupe, ils ont utilisé son compte propre pour réaliser des transactions vers d’autres acteurs bancaires. Certaines opérations ont été différées pendant les mesures de sécurisation.
La banque ne confirme pas le chiffre précis de 118 millions d’euros évoqué dans la presse : elle en valide seulement l’ordre de grandeur. Elle indique qu’une partie des fonds a pu être bloquée et que les conséquences financières restent à évaluer. Ce montant ne doit donc pas devenir une perte définitive dans votre présentation.
Rien ne démontre ici une attaque menée par l’IA
Le communiqué ne documente ni agent IA à l’origine de l’intrusion ni mécanisme technique précis. En déduire que des robots ont détourné les fonds serait ajouter un fait inexistant.
Le lien avec les agents d’entreprise est différent : dès qu’un logiciel agit chez un fournisseur connecté à votre système de paiement, il faut connaître ses droits réels. Une interface de préparation de factures ne devrait pas hériter silencieusement du pouvoir d’exécuter les virements.
Exemple : le prestataire de trésorerie prépare et transmet
Prenons une situation fictive. Une PME confie le rapprochement de ses factures à un intégrateur. Son agent lit les pièces, propose un lot de paiements et communique avec une plateforme bancaire.
Le dirigeant pense avoir conservé l’approbation finale. Mais le compte technique permet aussi de modifier un bénéficiaire et d’envoyer le lot. La séparation des rôles n’existe que dans la procédure écrite, pas dans les autorisations du système.
La recette doit vérifier un refus effectif : avec ses propres accès, l’agent ne peut ni créer un bénéficiaire utilisable immédiatement ni exécuter un paiement sans l’approbation prévue.
Les cinq contrôles à faire démontrer
- Cartographier les pouvoirs. Pour chaque prestataire et compte technique, distinguez lecture, modification, préparation, approbation et exécution. Vérifiez les sous-traitants et les accès de maintenance.
- Séparer les identités. La personne qui approuve doit agir avec un droit distinct de celui du logiciel qui prépare. Un clic dans une interface n’est utile que si le contrôle existe aussi côté exécution.
- Limiter l’exposition. Définissez les bénéficiaires, montants et opérations autorisés par le besoin métier. Les exceptions suivent un circuit humain identifié.
- Tracer hors du périmètre de l’agent. Reliez dossier, bénéficiaire, validation et ordre exécuté. L’agent ne doit pas pouvoir effacer seul les preuves de ses actions.
- Tester la coupure. Vérifiez comment révoquer l’accès du prestataire, suspendre les transmissions et poursuivre les paiements urgents autrement.
Le contrat doit couvrir la réaction, pas seulement la disponibilité
Demandez un délai de notification, un contact joignable en crise, l’accès aux traces et une procédure de coopération avec les banques. Faites examiner les responsabilités, exclusions et frais d’investigation ; ne supposez pas qu’une assurance ou un avoir de service couvrira une fraude.
Cette semaine, choisissez un parcours de paiement et exigez sa démonstration complète. Le livrable attendu est simple : qui prépare, qui autorise, qui exécute, et comment chacun peut être arrêté.