Phishing bancaire : le moment de vérité pour une authentification qui n'obéit qu'à vous

# Phishing bancaire : le moment de vérité pour une authentification qui n'obéit qu'à vous

L'attaque de phishing ciblant les clients du Crédit Agricole n'est pas un incident isolé. C'est un signal que nous refusons de lire correctement depuis trop longtemps. Pendant que les équipes sécurité colmatent les brèches en urgence, la vraie question reste sans réponse dans la plupart des établissements financiers européens : à qui appartient réellement l'infrastructure d'authentification sur laquelle repose la confiance de vos clients ?

En 2026, répondre « à un acteur américain » devrait être inacceptable pour toute banque soumise à DORA. Pourtant, c'est encore la réalité de nombreux SI bancaires européens. Ce guide ne vous propose pas une liste de solutions miracles. Il vous propose une méthode de réflexion et d'action pour reprendre la main, concrètement, sur un des maillons les plus critiques de votre sécurité.

Étape 1 — Cartographiez honnêtement votre dépendance actuelle

Avant de parler de souveraineté, il faut avoir le courage de faire l'état des lieux. Dans combien de banques européennes la gestion des identités, des tokens d'authentification ou des notifications push repose-t-elle sur des services hébergés hors UE, ou soumis au Cloud Act américain ?

Posez-vous ces trois questions sans chercher à vous rassurer :

• Où sont hébergées les données d'authentification de vos clients ? Pas la réponse contractuelle — la réalité technique. Les logs, les tokens, les métadonnées de connexion.
• Qui peut y accéder sans vous le dire ? Le Cloud Act de 2018 autorise les autorités américaines à exiger l'accès aux données stockées par des entreprises US, y compris sur des serveurs européens. Votre contrat avec un fournisseur US ne vous protège pas de ça.
• Votre plan de continuité tient-il si ce fournisseur coupe l'accès demain matin ? Pas théoriquement. Concrètement, en heures.

Cette cartographie n'est pas optionnelle. DORA — le règlement européen sur la résilience opérationnelle numérique, applicable depuis janvier 2025 — vous impose une connaissance exhaustive de vos dépendances tierces critiques. Si vous ne l'avez pas faite, vous êtes déjà hors conformité.

Étape 2 — Comprenez pourquoi le phishing prospère là où l'authentification est externalisée

Le phishing n'est pas un problème de crédulité utilisateur. C'est un problème d'architecture. Quand le parcours d'authentification d'un client passe par des redirections multiples, des domaines tiers, des notifications applicatives gérées par des SDK externes, vous créez mécaniquement des surfaces d'attaque que les attaquants savent reproduire à l'identique.

Le schéma d'attaque observé sur Crédit Agricole est classique dans sa sophistication : reproduction fidèle d'une interface de connexion, interception du facteur secondaire, utilisation d'une fenêtre de session valide avant que la victime réalise ce qui se passe. Ce qui le rend efficace, c'est précisément la complexité des flux d'authentification modernes — complexité souvent héritée d'une intégration de briques tierces non maîtrisées.

Il faut le dire clairement : externaliser son authentification à un acteur dont vous ne contrôlez ni le code, ni les infrastructures, ni les sous-traitants, c'est externaliser votre surface d'attaque à quelqu'un d'autre.

Étape 3 — Identifiez vos obligations réglementaires réelles

Nous sommes en 2026. Le cadre réglementaire européen est désormais complet et contraignant. Ne le traitez pas comme une contrainte administrative — c'est en réalité votre meilleur levier pour obtenir les budgets nécessaires à une refonte souveraine.

DORA (Digital Operational Resilience Act) impose aux établissements financiers une gestion rigoureuse des risques liés aux prestataires tiers critiques. Si votre fournisseur d'authentification est classé CTPP (Critical Third-Party Provider), votre établissement est soumis à des exigences de supervision renforcée. Mais même s'il ne l'est pas encore, vous devez démontrer que vous comprenez et maîtrisez ce risque.

NIS2 étend les obligations de cybersécurité à un périmètre beaucoup plus large. Les établissements financiers sont des entités essentielles. Une compromission d'authentification massive entre dans le périmètre des incidents à notifier sous 24 heures.

Le RGPD, enfin, n'est pas qu'une question de consentement et de cookies. Transmettre des données d'authentification — qui sont des données personnelles sensibles — à un prestataire soumis à une juridiction extérieure à l'UE sans garanties adéquates, c'est une violation caractérisée. Après l'invalidation du Privacy Shield et les contentieux successifs sur le Data Privacy Framework, il serait imprudent de parier sur la stabilité des mécanismes de transfert actuels.

Étape 4 — Définissez ce que « souverain » signifie pour votre authentification

Souveraineté ne signifie pas « fait maison à tout prix ». Cela signifie : vous savez ce qui tourne, vous savez où ça tourne, et vous pouvez auditer ou changer sans dépendance critique.

Concrètement, pour une infrastructure d'authentification bancaire souveraine, voici les critères non négociables :

• Juridiction européenne des données et des opérateurs. Le prestataire doit être soumis exclusivement au droit européen. Pas de maison-mère américaine, pas de filiale sous Cloud Act.
• Auditabilité du code. Sur un composant aussi critique que la gestion des identités, vous devez pouvoir auditer. Les solutions open source sous gouvernance européenne (ou les solutions dont vous détenez le code source sous escrow) offrent cette garantie.
• Hébergement qualifié SecNumCloud ou équivalent. L'ANSSI a défini un cadre. Utilisez-le. Un hébergement qualifié SecNumCloud garantit que même une décision judiciaire étrangère ne peut forcer l'accès à vos données sans passer par les autorités françaises et européennes.
• Capacité de reprise en main. Si votre prestataire disparaît ou augmente ses prix de manière inacceptable, combien de temps vous faut-il pour migrer ? Si la réponse dépasse six mois, vous n'êtes pas souverain, vous êtes captif.

Je pense que c'est sur ce dernier point que la plupart des DSI se font piéger. La souveraineté n'est pas un état, c'est une capacité. La capacité à sortir.

Étape 5 — Lancez un appel d'offres qui teste vraiment la souveraineté

La plupart des appels d'offres pour des solutions d'authentification évaluent les fonctionnalités, les certifications et les SLA. Très peu évaluent réellement la souveraineté. Voici les questions à intégrer impérativement dans votre cahier des charges :

1. Listez tous vos sous-traitants et indiquez leur nationalité et juridiction. Une réponse vague est éliminatoire.

2. Quel est votre mécanisme de réponse à une injonction légale étrangère ? Vous voulez une réponse documentée, pas une promesse commerciale.

3. Où sont physiquement hébergées les données de production, de backup et les logs d'authentification ?

4. Disposez-vous d'une qualification SecNumCloud, d'une certification eIDAS, ou d'un équivalent reconnu par une autorité européenne ?

5. Quel est le mécanisme de réversibilité et quel est le délai estimé de migration vers un autre prestataire ?

Un acteur qui ne peut pas répondre clairement à ces cinq questions n'a pas sa place dans une infrastructure d'authentification bancaire européenne en 2026.

Étape 6 — Ne négligez pas la couche humaine, mais ne vous y réfugiez pas

Toute crise de phishing génère un réflexe : « formons mieux nos utilisateurs ». C'est nécessaire. Ce n'est pas suffisant, et surtout, ce n'est pas la vraie réponse.

La formation des clients et des équipes internes reste indispensable. Mais si votre architecture d'authentification crée des parcours complexes et des redirections opaques, vous demandez à des humains de compenser une défaillance systémique. Ce n'est ni juste, ni efficace.

Il faut plutôt travailler sur la lisibilité du parcours d'authentification : réduire les redirections, ancrer visuellement et techniquement le processus d'authentification dans un domaine que vous contrôlez, et implémenter des mécanismes de détection d'anomalies comportementales qui n'exigent pas que l'utilisateur soit un expert en cybersécurité pour se protéger.

Ce que j'attends des banques européennes en 2026

L'incident Crédit Agricole n'est pas une honte. C'est un avertissement. La vraie honte serait de le traiter comme un problème de communication de crise ou de sensibilisation client, sans s'attaquer à la racine architecturale.

Les banques européennes ont les moyens, les obligations réglementaires et désormais les prestataires souverains pour bâtir une authentification digne de ce nom. Il manque encore, trop souvent, la volonté politique interne de rompre avec des dépendances confortables mais dangereuses.

DORA ne vous laisse plus le choix sur le papier. L'incident du Crédit Agricole ne devrait plus vous laisser le choix dans les faits. Le moment de reprendre la main sur votre authentification, c'est maintenant — pas après la prochaine compromission.