Serverless et Conteneurs pour la Banque en 2026 : Quand et Comment
Un guide pratique sur les architectures serverless et l'orchestration de conteneurs pour les charges de travail bancaires réglementées. Couvre les cas d'usage, les bonnes pratiques Kubernetes, la sécurité, la conformité DORA/ACPR et comment choisir entre les deux modèles.
Le serverless en banque - quand cela a du sens
L'infrastructure bancaire a passé des décennies surdimensionnée par conception. Les centres de données étaient calibrés pour les pics du jour de paie puis restaient largement sous-utilisés le reste du mois. Le serverless inverse ce modèle : on paie à l'exécution, pas à l'heure-serveur, et la plateforme redescend à zéro lorsqu'il n'y a plus d'activité.
Pour une banque ou un fintech, "serverless" ne désigne pas une seule technologie mais une catégorie : Function-as-a-Service (FaaS) - comme AWS Lambda, Google Cloud Functions ou Azure Functions - des conteneurs serverless tels que Google Cloud Run ou AWS Fargate, et des bases de données serverless qui s'adaptent indépendamment de la couche applicative. Le fil conducteur est que l'on décrit ce qu'on veut exécuter, non où ni sur combien de machines.
Le serverless a du sens en banque quand trois conditions sont réunies : la charge est pilotée par des événements et intermittente, une latence de démarrage à froid de quelques centaines de millisecondes est acceptable, et la fonction est sans état ou peut récupérer son état dans un stockage externe.
Paiement à l'exécution
Les coûts opérationnels s'alignent directement sur l'activité client. Pas de capacité oisive, pas de factures serveur la nuit quand les volumes de transactions chutent.
Élasticité automatique
Les pics du jour de paie se gèrent automatiquement sans planification manuelle de capacité ni astreinte.
Moins de charge opérationnelle
Pas de patch OS, pas de planification de capacité, pas de flotte de serveurs à gérer. L'effort d'ingénierie se concentre sur la logique métier.
Une approche hybride s'est imposée parmi les grands établissements : les systèmes de grand livre critiques restent sur une infrastructure privée, tandis que les canaux numériques orientés client et les traitements en arrière-plan s'exécutent sur des plateformes serverless et de conteneurs dans le cloud public.
Discutons de votre projet et voyons comment nous pouvons lancer votre projet. produit bancaire numérique ensemble
Demander une démoCas d'usage à forte valeur - et ce qu'il faut éviter
Toute charge de travail bancaire n'appartient pas à une plateforme serverless. Faire correspondre le profil de la charge au modèle d'exécution est la décision qui distingue une bonne architecture d'une erreur coûteuse.
| Charge de travail | Adéquation serverless | Notes |
|---|---|---|
| Validation d'événements de paiement | Bonne | Pilotée par événements, de courte durée, mise à l'échelle automatique lors des pics |
| Scoring AML/fraude (asynchrone) | Bonne | Fan-out sur des fonctions parallèles ; grands lots d'audit en minutes |
| Déclencheurs d'épargne arrondie | Bonne | Mise à l'échelle avec la base d'utilisateurs ; coût nul sans transactions |
| ETL temps réel / pipelines de données | Bonne | Transformations déclenchées par événements, sans calcul permanent |
| Inférence IA/ML (requêtes RAG) | Bonne | Pics occasionnels ; serverless évite les coûts oisifs GPU/CPU |
| Moteur de grand livre principal | Inadaptée | Longue durée, avec état, critique en latence ; démarrages à froid inacceptables |
| Autorisation de carte temps réel | Inadaptée | SLA sous 100 ms ; les démarrages à froid violent les règles des schémas de cartes |
| Trading haute fréquence | Inadaptée | SLA en microsecondes ; la surcharge serverless est trop élevée |
Un déploiement par phases réduit le risque. Commencez par les outils internes et les traitements par lots pour démontrer le ROI avant de migrer les charges orientées client. Ce n'est qu'une fois l'observabilité et la discipline FinOps en place que l'extension aux canaux numériques prend tout son sens.
Orchestration de conteneurs et Kubernetes pour la banque
Là où les fonctions serverless gèrent de courtes rafales sans état, les conteneurs exécutent les charges qui nécessitent des processus persistants, une latence prévisible ou un contrôle sur l'environnement d'exécution. Kubernetes est devenu le standard de fait pour orchestrer ces conteneurs dans les services financiers, mais son adoption dans un environnement réglementé exige d'aller bien au-delà d'un déploiement entreprise classique.
En France, l'ACPR (Autorité de contrôle prudentiel et de résolution) supervise les banques et les établissements de paiement. L'AMF intervient sur les aspects marchés. Pour la résilience opérationnelle, DORA (règlement européen sur la résilience opérationnelle numérique) est applicable depuis janvier 2025 et impose des exigences contraignantes sur la gestion des risques TIC. Les orientations de l'ACPR sur l'externalisation cloud, publiées dans le cadre de ses attentes prudentielles, précisent comment ces exigences s'appliquent aux établissements français. Certains établissements peuvent également faire face aux exigences du label SecNumCloud de l'ANSSI pour les données sensibles.
| Composant | Exigence pour la banque |
|---|---|
| Serveur API | TLS mutuel (mTLS) sur toutes les connexions ; authentification rigoureuse via OIDC, pas de tokens statiques |
| etcd | SSD haute performance, nœuds dédiés, chiffrement au repos ; etcd est l'unique source de vérité du cluster |
| Kubelet | N'accepte les instructions que du serveur API autorisé ; bootstrap TLS imposé |
| Réseau (SDN) | Équilibrage de charge granulaire, politiques réseau par espace de noms, capacités de bascule |
Le respect des standards CNCF (Cloud Native Computing Foundation) prévient la dépendance à un fournisseur et maintient la portabilité de la plateforme, un point important si les contrats d'externalisation ou les plans de reprise d'activité prévoient un déplacement des charges entre fournisseurs cloud.
Sécurité Kubernetes pour les charges réglementées
La sécurité dans un cluster Kubernetes bancaire n'est pas une couche que l'on ajoute après le déploiement. Elle traverse chaque décision de conception, de la topologie réseau à la gestion des secrets.
Réseau à confiance zéro. Chaque connexion pod à pod est traitée comme non fiable jusqu'à preuve du contraire. Intégration du RBAC avec le fournisseur d'identité central (Active Directory, Okta ou équivalent) via OIDC ; Pod Security Admissions avec le profil "Restricted" par défaut ; politiques réseau explicites pour que seuls les services qui doivent communiquer le puissent.
Gestion des secrets. Les identifiants ne doivent pas être stockés dans des variables d'environnement ni dans des Kubernetes Secrets en texte clair. Ils doivent être obtenus via un moteur de secrets dédié - HashiCorp Vault ou un Module de Sécurité Matériel (HSM) - monté comme volumes éphémères. Les identifiants ne sont ainsi jamais persistés sur le disque d'un pod.
Trinité de l'observabilité. L'ACPR et les exigences DORA traitent la traçabilité comme une exigence réglementaire. Un déploiement Kubernetes bancaire a besoin des trois piliers :
Métriques
Prometheus collecte les métriques du cluster et de l'application ; Grafana les rend visibles aux équipes SRE et aux auditeurs.
Journaux
La stack EFK (Elasticsearch, Fluentd, Kibana) fournit des pistes d'audit structurées et inaltérables pour tous les événements liés aux transactions.
Traces
Le service mesh Istio active le traçage distribué entre microservices pour suivre une demande de paiement à travers 12 services dans un unique flamegraph.
GitOps pour la conformité. En banque, la reprise d'activité est une obligation réglementaire, pas un exercice théorique. Les outils GitOps - Argo CD ou Jenkins X - automatisent la synchronisation de l'état du cluster depuis un dépôt Git versionné. Chaque modification de configuration est une Pull Request : revue, approuvée, documentée et auditable, exactement ce qu'exigent DORA et les attentes de l'ACPR.
Serverless vs. conteneurs - guide de décision
La plupart des plateformes bancaires finissent par utiliser les deux modèles. La question n'est pas quel modèle l'emporte, mais lequel convient à quelle charge de travail.
| Dimension | Serverless (FaaS / conteneurs serverless) | Conteneurs Kubernetes |
|---|---|---|
| Modèle de facturation | Par invocation / par 100 ms | Par heure de nœud (ou par vCPU-seconde pour les pools de nœuds serverless) |
| Latence de démarrage | Démarrage à froid : 100 ms - 2 s selon le runtime | Pod déjà en cours d'exécution ; latence P99 sous votre contrôle |
| Gestion d'état | Sans état par conception ; stockage externe requis | Charges avec état gérées via des volumes persistants |
| Durée d'exécution | Typiquement jusqu'à 15 minutes par invocation | Illimitée ; services longue durée supportés nativement |
| Charge opérationnelle | Quasi nulle en gestion d'infrastructure | Provisionnement du cluster, patch, gestion des nœuds |
| Portabilité fournisseur | Abstractions Knative/CNCF aident ; les APIs FaaS diffèrent | Élevée - standard CNCF ; portable entre clouds et on-premise |
| Usage bancaire typique | Gestionnaires d'événements, pipelines d'audit, inférence IA, traitements par lots | Services core, traitement des cartes, API gateways, trading |
Une règle pratique : si la charge dure quelques minutes ou moins, est déclenchée par un événement et peut tolérer une latence occasionnelle de démarrage à froid - serverless. Si elle s'exécute en continu, a besoin d'une latence prévisible ou maintient un état - conteneurs sur Kubernetes. Pour la portabilité en serverless, construire sur Knative plutôt que sur des APIs FaaS propriétaires.
Démarrages à froid, coûts et maturité opérationnelle
Deux préoccupations dominent les premières phases d'adoption serverless dans les banques : les démarrages à froid et la prévisibilité des coûts.
Les démarrages à froid sont réels mais gérables. Un démarrage à froid ajoute entre 100 ms et 2 secondes à la première requête après une période d'inactivité. Pour les charges en arrière-plan, c'est acceptable. Pour les APIs orientées client avec un SLA inférieur à 200 ms, non. Les options d'atténuation comprennent : la concurrence provisionnée (pré-chauffage d'un nombre minimum d'instances), le passage aux conteneurs serverless (qui démarrent plus vite que les runtimes FaaS avec de gros arbres de dépendances), ou le maintien du chemin critique sur des conteneurs toujours actifs.
Le coût favorise le serverless pour les charges genuinement sporadiques. Quand le trafic est continu et prévisible, la capacité réservée sur des nœuds Kubernetes est souvent moins chère que le prix par invocation. La discipline FinOps - suivi du coût par fonction via des outils comme Kubecost et budgets par espace de noms - transforme "le serverless nous a fait économiser" d'une anecdote en un chiffre vérifiable par le directeur financier.
La maturité opérationnelle est le défi le plus discret. Le serverless distribue la logique applicative sur des dizaines ou des centaines de fonctions. Sans traçage distribué et journalisation centralisée, diagnostiquer un paiement échoué qui a touché sept fonctions sur deux régions cloud devient une investigation de plusieurs heures. Investir dans la stack d'observabilité avant d'étendre la couverture serverless est rentabilisé rapidement.
Le déploiement en trois phases qui fonctionne en pratique, compatible avec les attentes de l'ACPR sur la migration progressive vers le cloud :
Phase 1 - Modernisation
Charges non critiques et outils internes. Construire les habitudes d'observabilité et de FinOps avant d'affecter les clients.
Phase 2 - Canaux numériques
APIs orientées client pilotées par événements : notifications, étapes d'onboarding, fonctionnalités IA. Mise à l'échelle sans ajouter de serveurs.
Phase 3 - Intégration FinOps
Suivi du coût par fonction, alertes budgétaires, décisions de redimensionnement. Le coût d'infrastructure devient une métrique d'ingénierie de premier plan.
FAQ
Le serverless fonctionne bien quand une charge est pilotée par des événements, de courte durée et sans état. Les bons exemples bancaires incluent : validation d'événements de paiement, scoring AML asynchrone, déclencheurs d'alertes de fraude, pipelines ETL temps réel et requêtes d'inférence IA. Si la tâche dure quelques minutes, s'adapte de façon imprévisible et peut tolérer une brève latence de démarrage à froid, le serverless est généralement le bon modèle.
Évitez le serverless pour le moteur de grand livre principal, l'autorisation de carte temps réel (avec SLA sous 100 ms selon les règles des schémas de cartes), le trading haute fréquence et tout processus avec état de longue durée. La latence de démarrage à froid et le modèle d'exécution par invocation ne conviennent pas aux charges avec SLA en microsecondes ou qui maintiennent un état en mémoire entre de nombreuses requêtes.
Kubernetes offre une orchestration de conteneurs portable et standardisée avec les contrôles de sécurité granulaires que les charges réglementées nécessitent : RBAC, politiques réseau, Pod Security Admissions, mTLS via un service mesh et infrastructure immuable via GitOps. La standardisation CNCF maintient la portabilité de la plateforme si un déplacement entre fournisseurs cloud ou vers l'on-premise s'avère nécessaire, ce que les plans de continuité d'activité exigés par l'ACPR et DORA peuvent rendre obligatoire.
Les pratiques clés sont : durcir le plan de contrôle (mTLS sur le serveur API, nœuds etcd dédiés avec stockage chiffré) ; réseau à confiance zéro avec RBAC et politiques réseau ; gérer les secrets via HashiCorp Vault ou HSM plutôt que de simples Kubernetes Secrets ; implémenter les trois piliers d'observabilité (métriques, journaux, traces) ; utiliser GitOps (Argo CD) pour des déploiements auditables et reproductibles ; exécuter FinOps (Kubecost) pour la visibilité des coûts par espace de noms. La conception du cluster doit s'aligner sur les exigences de DORA (article 11) sur la résilience opérationnelle et les attentes de l'ACPR en matière d'externalisation cloud, ainsi que sur les recommandations SecNumCloud de l'ANSSI pour les données sensibles.
Trois questions aident : La charge s'exécute-t-elle en continu ou sur événements ? A-t-elle besoin de garanties de latence sous la seconde ? Doit-elle maintenir un état entre les requêtes ? Si les réponses sont "sur événements, non, non" - serverless. Si une réponse change - conteneurs sur Kubernetes. La plupart des plateformes bancaires utilisent les deux : serverless pour les charges en arrière-plan et les rafales de canaux numériques ; Kubernetes pour les services core et tout ce qui a un SLA de latence strict. Pour la portabilité en serverless, construire sur Knative plutôt que sur des APIs FaaS propriétaires.
