Lorsqu’une application bancaire critique subit une défaillance, il ne s’agit pas seulement d’une question financière. C’est la confiance des clients qui s’érode, l’attention des autorités de régulation qui s’intensifie, et l’ensemble de l’écosystème qui se trouve fragilisé.
Dans ce contexte, la souveraineté ne relève plus du débat doctrinal : elle devient une condition essentielle de survie. C’est la capacité à conserver la maîtrise et à exercer sa propre autonomie décisionnelle.
1. La nouvelle équation des banques
Dans le secteur bancaire, les applications critiques supportent des fonctions cœur dont la moindre défaillance peut avoir un impact systémique. Ces applications représentent un enjeu d’infrastructure, mais également de souveraineté et de confiance vis-à-vis des régulateurs et des clients finaux. Le triptyque « sécuriser, transformer, décider » permet aux directions métier et IT d’aligner leurs priorités autour d’enjeux communs.
2. Ce qu’est une application critique dans la banque
Parler d’applications critiques, c’est d’abord parler de sensibilité des données et de risque métier associé à leur indisponibilité. Dans un même établissement, certaines applications peuvent supporter une interruption limitée, quand d’autres doivent fonctionner en continu, car elles conditionnent la continuité de service, la conformité réglementaire et l’image de marque. Dans la pratique, une application de paiement instantané ou de compensation interbancaire ne peut se permettre la moindre interruption : quelques secondes à peine suffisent à paralyser des milliers de transactions. À l’inverse, un outil interne de reporting peut tolérer quelques minutes d’indisponibilité sans que cela ne pose de problème majeur.
Pour structurer ces enjeux, les banques s’appuient sur des grilles internes de classification, par exemple de C1 à C4, où C3 et C4 regroupent les informations les plus sensibles et les plus critiques.
3. De la classification C1–C4 aux choix Cloud
Cette classification a un effet direct sur la stratégie Cloud : pour des données C1, il peut être acceptable de recourir à des hyperscalers non européens, à condition d’en assumer le modèle de gouvernance et la juridiction applicable. Dès que l’on dépasse C2, et a fortiori pour des périmètres C3/C4, la maîtrise de la localisation, des accès, du cadre juridique et de la protection contre les lois extraterritoriales devient un impératif, ce qui rend le recours à un Cloud souverain structurant.
En France, la qualification SecNumCloud de l’ANSSI est devenue le standard de référence pour identifier des offres de « Cloud de confiance » conçues pour protéger des données sensibles, y compris face aux lois extraterritoriales.
4. L’approche multi‑Cloud de complémentarité d’OUTSCALE
Chez OUTSCALE, marque de Dassault Systèmes, nous défendons une approche multi‑cloud de complémentarité plutôt qu’une opposition frontale entre hyperscalers et Cloud souverain. Les workloads les moins sensibles peuvent s’appuyer sur des Hyperscalers non européens, tandis que les applications et données les plus critiques doivent rester on‑premise ou migrer vers une infrastructure souveraine qualifiée.
Comprendre, ce qu’est une application critique et pourquoi la souveraineté est désormais au cœur des arbitrages Cloud des banques. Dans le prochain article “Sécuriser : conformité, SecNumCloud et résilience DORA pour les banques” nous verrons comment « sécuriser » concrètement cette trajectoire grâce à la conformité, à SecNumCloud et au cadre réglementaire DORA, avant d’aborder, dans le troisième, la transformation et l’IA souveraine.
