Cloud Banking en 2026 : le guide complet
Analyse approfondie du cloud banking en 2026 : core banking SaaS, cloud public, privé et hybride, DORA, ACPR, schémas de migration et les éditeurs qui font tourner de vraies banques dans le cloud.
Qu'est-ce que le cloud banking ?
Le cloud banking est le modèle dans lequel une banque ou un établissement financier agréé fait tourner son core banking, son grand livre, son moteur de paiements, son analytique et ses canaux clients sur une infrastructure cloud publique, privée ou hybride, plutôt que sur des serveurs hébergés dans son propre centre de données. En 2026, ce n'est plus un cas marginal. C'est la trajectoire par défaut de toute nouvelle licence en Europe, en Amérique du Nord et en APAC, et l'aboutissement de presque tous les programmes de modernisation des banques historiques.
Trois forces poussent simultanément : les hyperscalers avec des offres dédiées à la banque (AWS Financial Services, Microsoft Cloud for Financial Services, Google Cloud for Financial Services), une nouvelle génération d'éditeurs de core banking cloud-native (Mambu, Thought Machine, Finxact, Tuum, 10x, Pismo) et les régulateurs, qui sont passés de "le cloud est risqué" à "le cloud convient, à condition d'en maîtriser le risque". Le règlement DORA est pleinement applicable dans l'UE depuis le 17 janvier 2025 et codifie précisément la manière dont les banques doivent piloter leurs fournisseurs cloud.
Core banking SaaS
Grand livre, comptes, crédits et paiements livrés en service managé, mis à jour par l'éditeur et consommés via API.
Architecture cloud-native
Microservices, conteneurs, event streaming, infrastructure-as-code. Scalabilité horizontale plutôt que batch de nuit.
Résilience supervisée
DORA dans l'UE, recommandations ACPR et orientations BCE, guidance FFIEC aux États-Unis. Le cloud est supervisé comme une dépendance critique.
L'horizon est partout le même : une banque capable de sortir un nouveau produit en un sprint, d'ouvrir un pays sans construire de datacenter, de survivre à une panne régionale sans impact client, et d'en apporter la preuve à son superviseur avec une piste documentaire qui se génère d'elle-même.
Discutons de votre projet et voyons comment nous pouvons lancer votre projet. produit bancaire numérique ensemble
Demander une démoCloud public, privé et hybride, mono-tenant contre multi-tenant
Tous les "clouds" ne veulent pas dire la même chose. Un DSI qui choisit un modèle arbitre en réalité sur deux axes : où vit l'infrastructure et comment le logiciel est partitionné entre clients. Les deux décisions ont des conséquences réglementaires directes.
| Modèle | De quoi il s'agit | Usage typique | Contrepartie |
|---|---|---|---|
| Cloud public | Infrastructure hyperscaler partagée (AWS, Azure, Google Cloud, Oracle, IBM) consommée à la demande. | Néobanques greenfield, fintechs et la plupart des nouveaux déploiements de core banking. | Meilleure économie et meilleure scalabilité. Le risque de concentration et la stratégie de sortie doivent être documentés au titre de DORA. |
| Cloud privé | Infrastructure dédiée, dans les locaux de la banque ou en colocation, exploitée à la manière d'un cloud. | Banques Tier-1 avec contraintes de résidence des données ou de legacy. | Contrôle total, coût unitaire plus élevé, délai plus long pour livrer de nouvelles capacités. |
| Cloud hybride | Mélange : charges sensibles en privé, charges élastiques en public, avec un plan de contrôle commun. | Banques mid-cap et Tier-1 pendant des programmes de migration pluriannuels. | Réaliste sur le plan opérationnel, plus lourd architecturalement. Bon compromis sur 3 à 5 ans. |
| SaaS multi-tenant | Plusieurs banques partagent la même plateforme logique, isolées au niveau des données et des politiques. | Mambu, Tuum, Pismo et autres cores cloud-native. | Déploiement le plus rapide, coût le plus bas, moins de personnalisation par banque. |
| Mono-tenant | Une instance dédiée par banque, généralement sur le compte cloud de la banque. | Thought Machine Vault, 10x, grandes transformations. | Plus de contrôle, plus de confort réglementaire, prix plus élevé. |
Règle pratique en 2026 : le greenfield part en cloud public multi-tenant. Les grandes banques partent en hybride avec des cores mono-tenant. Tout ce qui se trouve entre les deux se négocie au cas par cas avec le superviseur, pas avec l'éditeur.
Pourquoi le cloud, et pourquoi maintenant
Le business case tournait auparavant autour du coût. En 2026, le coût est la partie la moins intéressante de la conversation. Les cinq moteurs ci-dessous, dans cet ordre, sont ceux qui amènent réellement un conseil d'administration à valider une migration cloud.
Vitesse
Lancer un produit en semaines, pas en fenêtres de release. Environnements en quelques minutes.
Scalabilité
Absorber les pics de paie, le Black Friday et les pointes de croissance sans surdimensionner.
Résilience
Multi-AZ, multi-région, bascule automatique. Objectifs de reprise au niveau DORA par défaut.
Innovation
Accès direct aux services IA, données et analytique. Pas de contractualisation séparée pour chacun.
Coût
Opex plutôt que capex. Unit economics qui suivent l'activité, pas le rack.
Côté régulateur, le ton a changé entre 2022 et 2025. La BCE, l'ACPR et l'OCC portent désormais des attentes de supervision qui postulent ouvertement l'adoption du cloud. Ne pas recourir au cloud n'est plus l'option prudente ; c'est de plus en plus celle qui exige sa propre justification lors d'une inspection.
Le paysage des éditeurs de cloud banking
La pile se divise proprement en deux couches : les hyperscalers qui fournissent l'infrastructure et les services sectoriels, et les éditeurs de core banking qui fournissent le produit de référence. Un déploiement réel mélange généralement un de chaque.
Infrastructure cloud pour les banques
- AWS Financial Services - plus grosse empreinte dans la banque mondiale, écosystème de partenaires profond.
- Microsoft Cloud for Financial Services - fort en Europe et chez les acteurs équipés de Dynamics et M365.
- Google Cloud for Financial Services - deals tirés par la donnée, l'IA et l'analytique, Vertex AI pour la fraude.
- Oracle Financial Services - Flexcube et OFSAA sur Oracle Cloud Infrastructure.
- IBM Cloud for Financial Services - cadre de politique co-construit avec Bank of America, fort en hybride.
Core banking cloud-native
- Mambu - SaaS multi-tenant, retail, PME, crédit, utilisé par N26 et ABN AMRO (New10).
- Thought Machine Vault - mono-tenant, propulse Lloyds, Standard Chartered Mox et Intesa Isybank.
- Finxact - orienté États-Unis, racheté par Fiserv, core axé dépôts.
- Tuum - core européen nouvelle génération, composable, fort en pays nordiques et DACH.
- 10x Banking - plateforme méta-core derrière Chase UK et Westpac en Australie.
- Pismo - cartes et core en LATAM et APAC, racheté par Visa en 2024.
Le choix d'un éditeur ne se joue que rarement sur une grille de fonctionnalités. Il se joue sur les trois questions du régulateur : qui est responsable, comment sort-on, et que se passe-t-il pendant une panne cloud. Un bon éditeur arrive au premier rendez-vous avec les réponses déjà écrites.
Réglementation : DORA, ACPR et la carte de conformité 2026
Deux cadres dominent la conversation en 2026. Dans l'UE, DORA (Règlement UE 2022/2554) est en vigueur depuis le 17 janvier 2025 et couvre le risque TIC, la notification d'incidents, les tests de résilience et la supervision directe des prestataires tiers critiques, y compris les hyperscalers. En France, cela se conjugue avec les recommandations de l'ACPR sur l'externalisation informatique et le recours au cloud. L'ACPR a désigné 2026 comme une "année de supervision" et attend la remise du Registre d'information avant le 31 mars 2026.
- Tenir un Registre d'information. Au titre de l'article 28 de DORA, chaque entité régulée maintient un registre des accords TIC avec les tiers et le transmet chaque année à l'ACPR.
- Documenter une stratégie de sortie. Avant de contractualiser avec un fournisseur cloud qui supporte une fonction critique ou importante, la banque doit prouver qu'elle peut migrer hors de ce fournisseur dans un délai défini. "Nous faisons confiance à AWS" ne constitue pas un plan de sortie.
- Tester la résilience opérationnelle. Les tests de pénétration fondés sur la menace (TLPT) sur les fonctions critiques sont obligatoires au titre de DORA pour les entités importantes. L'ACPR attend les résultats et les plans de remédiation.
- Maîtriser le risque de concentration. DORA reconnaît explicitement que trop de banque sur un seul hyperscaler est un enjeu systémique. Diversification, multi-région et architectures portables sont désormais un sujet de comex.
- Protéger la souveraineté des données. RGPD, EU Data Act, directive NIS2 et règles nationales encadrent les transferts transfrontaliers. Le choix de la région cloud est une décision réglementaire autant qu'une décision d'architecture.
Ajoutez les transverses : SOC 2, ISO 27001, PCI DSS 4.0, NIS2, l'AI Act pour le risque de modèle et les orientations EBA sur l'externalisation. Rien n'est optionnel. La bonne nouvelle : les éditeurs cloud-native matures livrent les contrôles prêts à l'emploi, et les hyperscalers publient la matrice de responsabilité partagée ligne par ligne. Le questionnaire CAIQ de la Cloud Security Alliance reste l'instrument habituel pour objectiver ces contrôles vis-à-vis de l'ACPR.
Bénéfices pour les acteurs établis et pour les nouveaux entrants
Le business case change selon le point de départ. Une banque Tier-1 qui quitte un mainframe n'a rien de commun avec une fintech qui démarre de zéro. Les deux gagnent, mais pas de la même manière.
Acteurs établis (migration)
- Retirer les parcs COBOL et mainframe coûteux
- Réduire l'empreinte datacenter et le capex fixe d'infrastructure
- Accélérer la livraison produit, du trimestre au sprint
- Activer l'analytique et l'IA temps réel sur la donnée client
- Atteindre par conception les objectifs de résilience DORA
Nouveaux entrants (greenfield)
- Pas de legacy, pas de dette technique, pas de datacenter à construire
- Mise en production sur un core SaaS en 6 à 12 mois
- Ouverture de nouveaux pays sans nouvelle infrastructure
- Coût fixe réduit, opex qui suit le chiffre d'affaires
- Vivier d'ingénieurs cloud-native, pas des retraités du mainframe
Point commun : les deux camps cessent de se concurrencer sur l'infrastructure et commencent à se concurrencer sur le produit. Une fois la couche cloud réglée, le différenciateur, c'est ce qu'on construit au-dessus.
Sécurité, disponibilité et posture de conformité
L'objection historique était : "le cloud est moins sûr que mon centre de données". Les chiffres ne la soutiennent plus. Les hyperscalers investissent chaque année davantage en sécurité que n'importe quelle banque prise isolément, et les certifications le montrent. À quoi ressemble sur le papier une pile de cloud banking en 2026:
La responsabilité partagée est le seul concept qui compte vraiment. L'hyperscaler sécurise le cloud ; la banque sécurise ce qu'elle met dans le cloud. Identité, segmentation réseau, gestion des secrets, propriété des clés (BYOK ou HYOK), journalisation vers le SIEM et réponse à incident répétée sont l'affaire de la banque. Bien exécutés, ils passent l'audit ; à l'inverse, aucun certificat accroché au mur du fournisseur ne les sauve.
Trajectoires de migration : strangler, parallel run, big-bang
Il existe trois stratégies de migration honnêtes. Aucune n'est indolore, et la bonne dépend du point de départ, de l'appétit au risque et du superviseur.
| Schéma | Principe | Durée | Profil de risque |
|---|---|---|---|
| Strangler | Encapsuler le core legacy d'APIs, router les nouvelles capacités vers une plateforme cloud-native, retirer le legacy morceau par morceau. | 2 à 4 ans | Risque le plus faible. Préféré par les Tier-1. Livraison de valeur continue. |
| Parallel run | Faire tourner legacy et core cloud en parallèle, migrer les segments clients par vagues avec réconciliation complète. | 12 à 24 mois | Risque modéré. Idéal pour les banques ayant des portefeuilles ou des géographies distincts. |
| Big-bang | Basculer tout le portefeuille sur un seul week-end après de longues répétitions. | 9 à 18 mois | Risque le plus élevé, retour le plus rapide. Surtout viable pour des banques petites ou moyennes à gamme simple. |
Quel que soit le choix, deux points ne sont pas négociables : un plan de déploiement réversible et une stratégie de réconciliation qui prouve, centime par centime, qu'aucun solde client n'a bougé dans le mauvais sens. Le superviseur demandera à voir les deux.
Lancez votre cloud banking avec Crassula
Crassula est une plateforme bancaire cloud-native qui tourne sur l'hyperscaler de votre choix et se comporte comme un produit SaaS quand vous le souhaitez. Le core, le grand livre, la fourniture d'IBAN, l'émission de cartes, l'orchestration KYC, le routage des paiements et le back-office d'administration sont déjà construits. Vous choisissez le modèle de déploiement (SaaS multi-tenant, mono-tenant sur votre compte cloud ou hybride), nous gérons le reste.
Lancement en semaines
Un produit de cloud banking sous votre marque en production en 6 à 12 semaines, sur AWS, Azure ou Google Cloud.
Prêt pour DORA
Stratégie de sortie, notification d'incidents, Registre d'information et tests de résilience intégrés à la plateforme.
Modulaire
Remplacez n'importe quel module, apportez votre propre core, branchez-vous sur des rails BaaS partenaires. Pas de vendor lock-in par conception.
Que vous planifiez une migration, une nouvelle banque digitale ou une fintech verticale, Crassula vous fournit une pile de cloud banking déjà conforme, déjà résiliente et déjà intégrée aux réseaux de paiement dont vous avez besoin.
FAQ
Le cloud banking, c'est lorsqu'une banque fait tourner ses systèmes centraux, son grand livre, ses paiements et ses canaux clients sur une infrastructure cloud publique, privée ou hybride, plutôt que dans son propre centre de données. En pratique, cela passe souvent par un core banking SaaS posé sur un hyperscaler type AWS, Azure ou Google Cloud.
Oui. Dans l'UE, DORA est en vigueur depuis le 17 janvier 2025 et encadre précisément la manière dont les banques peuvent utiliser le cloud. En France, les recommandations de l'ACPR sur l'externalisation informatique et le recours au cloud s'appliquent en parallèle. Le cloud est supervisé comme une dépendance critique, mais il est explicitement permis et très largement attendu.
Le cloud public s'appuie sur un hyperscaler partagé comme AWS ou Azure. Le cloud privé est une infrastructure dédiée exploitée à la manière d'un cloud, typiquement pour des raisons de résidence des données ou de legacy. L'hybride combine les deux avec un plan de contrôle commun. La plupart des nouvelles banques partent en public et multi-tenant ; la plupart des grandes banques tournent en hybride pendant la migration.
Mambu, Thought Machine Vault, Finxact, Tuum, 10x Banking et Pismo dominent la catégorie cloud-native. Ils tournent sur les hyperscalers et équipent des banques comme Lloyds, Standard Chartered Mox, Chase UK, N26 et Intesa Isybank. Voir notre guide des systèmes de core banking pour un comparatif complet.
DORA impose un Registre d'information pour chaque contrat TIC avec un tiers, une stratégie de sortie documentée pour les prestataires critiques, des tests de pénétration fondés sur la menace, la notification des incidents majeurs sous 24 heures et une gestion explicite du risque de concentration dès qu'une banque dépend d'un hyperscaler unique. En France, la remise du Registre est attendue avant le 31 mars 2026.
Un lancement greenfield sur un core SaaS peut aller en production en 6 à 12 mois. Une migration complète d'une banque établie s'étale typiquement sur 2 à 4 ans avec le schéma strangler. Les parallel run se situent entre 12 et 24 mois, et le big-bang reste rare en dehors des banques de taille moyenne à gamme simple.
Les hyperscalers détiennent les certifications SOC 2, ISO 27001 et PCI DSS 4.0 et investissent plus en sécurité que n'importe quelle banque individuelle. Le modèle est celui de la responsabilité partagée : le fournisseur sécurise le cloud, la banque sécurise l'identité, la donnée, les clés et la configuration. Bien exécuté, le cloud banking égale ou dépasse la sécurité on-premise. Le CAIQ de la Cloud Security Alliance reste l'outil standard pour le démontrer à l'ACPR.
Crassula fournit une plateforme bancaire cloud-native avec grand livre, IBAN, émission de cartes, KYC, paiements et back-office d'administration déjà construits. Elle tourne sur AWS, Azure ou Google Cloud, se déploie en SaaS multi-tenant ou mono-tenant et embarque des contrôles prêts pour DORA. Vous lancez un produit bancaire sous votre marque en quelques semaines, sans reconstruire la plomberie.
