Après Arkéa, peut-on encore confier les données financières des Européens à une infrastructure qu'on ne contrôle pas ?

# Après Arkéa, peut-on encore confier les données financières des Européens à une infrastructure qu'on ne contrôle pas ?

*La cyberattaque subie par Crédit Mutuel Arkéa en 2026 a remis brutalement sur la table une question que beaucoup de DSI évitaient : où vivent réellement vos données financières, et qui peut y accéder sans vous prévenir ? Nous avons interrogé un directeur des systèmes d'information d'une ETI du secteur des services financiers, confronté depuis plusieurs années à ces arbitrages. Il nous livre son analyse, sans langue de bois.*

RiffLab Media : L'attaque contre Arkéa a surpris beaucoup de monde. Pourquoi un acteur bancaire de cette taille reste-t-il vulnérable ?

Parce que la taille ne protège pas, elle complexifie. Arkéa, c'est un groupe mutualiste important, avec des filiales, des systèmes hérités, des interconnexions multiples. Chaque connexion entre deux systèmes est une surface d'attaque potentielle. Plus votre organisation est distribuée, plus vous avez de portes d'entrée.

Mais ce qui m'a frappé dans cet incident, ce n'est pas tant la brèche elle-même — elles arrivent, même aux mieux préparés — c'est la question de la résilience ensuite. Combien de temps pour détecter ? Combien de temps pour isoler ? Combien de temps pour restaurer ? Ce sont ces délais qui révèlent si une organisation maîtrise vraiment son infrastructure ou si elle dépend de tiers pour comprendre ce qui se passe chez elle.

On parle beaucoup de DORA depuis son entrée en vigueur. Pour ceux qui découvrent le sujet, c'est quoi exactement, et qu'est-ce que cet incident change concrètement ?

DORA, c'est le *Digital Operational Resilience Act*. C'est un règlement européen entré en application début 2025, qui s'adresse à toutes les entités financières — banques, assurances, établissements de paiement — ainsi qu'à leurs prestataires technologiques critiques. L'idée centrale : vous devez être capable de résister à une perturbation numérique, de la détecter rapidement, et de vous remettre en état dans des délais maîtrisés.

Ce que l'incident Arkéa illustre concrètement, c'est que DORA ne se réduit pas à un audit annuel. Il impose une cartographie précise de vos dépendances technologiques. Vous devez savoir, à tout moment, quels sont vos prestataires critiques, où sont hébergées vos données, selon quelles conditions contractuelles, et ce qui se passe si l'un de ces prestataires est lui-même compromis ou indisponible.

Or, si votre infrastructure repose sur des acteurs dont les serveurs sont hors de l'Union européenne, ou soumis à des législations étrangères, votre capacité à auditer et à réagir est structurellement limitée. DORA vous oblige à regarder cette réalité en face.

Vous mentionnez des législations étrangères. Est-ce que vous faites référence au Cloud Act américain ? Pouvez-vous expliquer de quoi il s'agit pour nos lecteurs ?

Oui, précisément. Le *Cloud Act* — *Clarifying Lawful Overseas Use of Data Act* — est une loi américaine adoptée en 2018. Elle autorise les autorités américaines à demander à n'importe quelle entreprise technologique soumise au droit américain de leur fournir des données, même si ces données sont stockées physiquement en Europe.

Concrètement : si vous hébergez vos données bancaires chez un acteur américain, même dans un datacenter situé en Allemagne ou en Irlande, les autorités américaines peuvent, sous certaines conditions, exiger l'accès à ces données. Sans nécessairement vous en informer. Sans passer par les canaux de coopération judiciaire habituels entre États.

Pour un établissement financier européen, c'est un problème majeur. Vous avez des obligations de confidentialité vis-à-vis de vos clients. Vous avez des obligations RGPD — le *Règlement Général sur la Protection des Données*. Et vous avez potentiellement une injonction américaine discrète qui contredit tout ça. Ce n'est pas hypothétique. C'est un risque juridique réel, documenté, que les régulateurs européens ont commencé à nommer explicitement.

NIS2 est une autre directive souvent citée. Quelle est la différence avec DORA, et pourquoi les DSI de PME et ETI doivent-ils s'en préoccuper ?

Bonne question, parce que les deux textes coexistent et se complètent, mais ils ne s'adressent pas aux mêmes périmètres.

NIS2 — *Network and Information Security*, deuxième version — est une directive européenne sur la cybersécurité des secteurs critiques. Elle est beaucoup plus large que DORA : elle couvre les opérateurs d'énergie, de transport, de santé, les administrations, les acteurs du numérique… et les établissements financiers aussi. Elle impose des obligations de gestion des risques cyber, de déclaration d'incidents, et elle étend la responsabilité aux dirigeants — pas seulement aux équipes techniques.

La différence clé avec DORA : DORA est un règlement spécifique au secteur financier, directement applicable dans tous les États membres. NIS2 est une directive, transposée différemment selon les pays. Mais les deux convergent vers la même exigence : vous devez démontrer que vous contrôlez votre chaîne de dépendances numériques.

Pour une ETI, ça signifie concrètement : si vous êtes sous-traitant d'un acteur financier, si vous gérez de la paie, de la facturation, des données de paiement, vous êtes probablement dans le périmètre. L'incident Arkéa devrait servir de signal d'alarme à des centaines de directions informatiques qui se croient hors scope.

Quelles leçons opérationnelles tirez-vous de cet incident pour les organisations qui veulent reprendre la main sur leur infrastructure ?

Trois leçons, dans l'ordre de priorité.

Première leçon : cartographiez vos dépendances de façon honnête. Pas pour cocher une case réglementaire. Pour savoir, en cas d'incident, où vous avez du levier et où vous n'en avez pas. Si votre SIEM — c'est votre outil de surveillance de la sécurité, *Security Information and Event Management* — est hébergé chez un acteur sur lequel vous perdez la main en cas de crise diplomatique ou juridique, vous avez un problème structurel.

Deuxième leçon : testez vraiment votre plan de continuité. Un PCA — *Plan de Continuité d'Activité* — qui n'a jamais été testé en conditions réelles n'existe pas. Les exercices de crise cyber doivent simuler l'indisponibilité complète d'un prestataire externe. Pas juste une panne serveur.

Troisième leçon : le sujet de la souveraineté n'est plus un débat idéologique. C'est un critère de résilience. Choisir une solution dont vous pouvez auditer le code, dont vous savez où sont les données, dont vous comprenez le régime juridique applicable — ce n'est pas du protectionnisme. C'est de la gestion de risque responsable. Des acteurs européens comme Outscale — la branche cloud souveraine de Dassault Systèmes — ou Tixeo pour les communications sécurisées existent et répondent à des besoins réels. Ce ne sont pas des alternatives de second rang.

Dernière question : est-ce que vous pensez que les régulateurs européens tirent les bonnes conclusions de ce type d'incident ?

Ils avancent, mais pas assez vite face à la réalité du terrain. DORA et NIS2 sont de bons cadres. Le problème, c'est l'application et le contrôle. Les régulateurs nationaux — l'ACPR en France pour le secteur financier, l'ANSSI pour la cybersécurité — publient des recommandations. Mais entre une recommandation et une obligation auditée, il y a un gouffre.

Ce que j'attends des régulateurs, c'est qu'ils aillent jusqu'au bout de la logique. Si une entité financière européenne ne peut pas garantir que ses données sont hors de portée d'une injonction étrangère, ce risque doit apparaître explicitement dans son rapport de conformité. Pas dilué dans cinquante pages de politique de sécurité générale.

L'incident Arkéa devrait accélérer ce mouvement. Chaque cyberattaque sur un acteur financier européen est une démonstration que la souveraineté numérique n'est pas un confort politique. C'est une condition de survie opérationnelle.

*Propos recueillis par la rédaction de RiffLab Media. L'interviewé a souhaité conserver l'anonymat.*