Modernisation de l'infrastructure avec Kubernetes
Un grand établissement bancaire espagnol devait moderniser son infrastructure critique vers une architecture de conteneurs hybride, sans interrompre les services en production.
Défi
Infrastructure legacy avec des services critiques qui ne pouvaient pas être arrêtés. Nécessité de moderniser vers des conteneurs et le cloud tout en maintenant opérationnelle la plateforme bancaire.
Solution
Déploiement par phases avec RKE2 et Rancher on-premise, extension vers AWS EKS, adoption de GitOps avec Rancher Fleet et observabilité complète avec Prometheus, Grafana et Loki.
Technologies
- Kubernetes / RKE2 / Rancher
- AWS EKS, ALB, RDS, S3
- GitOps / Helm / Kustomize
- Prometheus / Grafana / Loki
Contexte
Un grand établissement bancaire espagnol partait d'un environnement d'infrastructure fragmenté, avec des processus manuels qui limitaient l'agilité opérationnelle, la capacité à monter en charge à la demande et la résilience de ses services critiques. Avec des charges HPC et des systèmes essentiels pour le métier, il avait besoin d'une base technologique robuste, plus flexible et automatisée.
Cinq objectifs ont été fixés avec le client : moderniser l'infrastructure avec une plateforme d'orchestration unifiée, garantir la haute disponibilité des systèmes critiques, permettre une mise à l'échelle automatique sans surdimensionnement, améliorer l'observabilité et la traçabilité de bout en bout, et renforcer la sécurité de l'environnement en réduisant les erreurs opérationnelles.
Le défi
Avant d'engager la modernisation, l'organisation faisait face à trois limitations techniques et opérationnelles :
- Environnement fragmenté et peu scalable : difficulté à opérer de façon unifiée entre on-premise et cloud, avec des limites pour faire évoluer les services de manière dynamique.
- Processus manuels à forte dépendance opérationnelle : des déploiements lents (jusqu'à 45 minutes), sujets aux erreurs et peu traçables, qui créaient des goulots d'étranglement et une consommation de ressources inutile.
- Manque de visibilité et de résilience sur les services critiques : absence d'outils d'observabilité et une architecture exposée aux pannes qui compromettait la stabilité de systèmes clés.
Approche par phases
La modernisation a été abordée selon une approche progressive, conçue pour ne pas interrompre les services critiques du métier. La plateforme a été construite sur Kubernetes comme axe central d'orchestration, en six étapes clairement définies.
-
01
Analyse et conception
Évaluation des charges de travail, définition de l'architecture, sélection des technologies et dimensionnement initial.
-
02
Preuve de concept
Déploiement initial on-premise avec RKE2 et Rancher, en validant les environnements HPC et les services essentiels.
-
03
Extension vers AWS
Mise en place de clusters sur AWS (EKS et RKE2 sur EC2), en intégrant des services tels qu'ALB, RDS et S3 avec une connectivité hybride.
-
04
Automatisation et CI/CD
Adoption de GitOps avec Rancher Fleet et déploiements déclaratifs via Helm et Kustomize.
-
05
Observabilité et traçabilité
Intégration de Prometheus, Grafana et Loki pour la supervision, les alertes et la centralisation des logs.
-
06
Production et support
Migration complète des services, validation fonctionnelle, mise en service et support opérationnel continu.
Architecture et stratégie
La stratégie a été conçue pour répondre aux trois besoins du secteur : continuité, scalabilité et contrôle. Le choix s'est porté sur une architecture hybride combinant environnements on-premise et cloud, orchestrée depuis une console de gestion unique, ce qui a permis de conserver le contrôle sans sacrifier la capacité à monter en charge dynamiquement.
L'adoption de GitOps et d'outils de CI/CD a éliminé les tâches manuelles, réduit les erreurs et permis des cycles de déploiement plus rapides et plus prévisibles. La supervision continue et les alertes en temps réel ont été fondamentales pour garantir traçabilité, performance et conformité.
Résultats mesurables
Le choix de Kubernetes comme base technologique n'était pas un hasard : sa capacité à orchestrer des conteneurs efficacement, à monter en charge automatiquement selon la charge et à s'adapter aux environnements hybrides en a fait la solution aux défis du projet. Résumé des principaux résultats après la mise en œuvre :
| Indicateur | Avant | Après |
|---|---|---|
| Temps de déploiement | ~45 minutes | ~3-5 minutes (≈ −90 %) |
| Disponibilité des services | 95 % | > 99,99 % (+4,95 points) |
| Scalabilité | Manuelle | Automatique, dynamique |
| Coût opérationnel | Élevé | Optimisé (≈ −30 %) |
| Temps de réponse (web/API) | 200-300 ms | 50-120 ms (≈ −60 %) |
Chiffres agrégés et anonymisés dans le cadre d'un accord de confidentialité. Source : projets de Vermont Solutions.
Enseignements transposables
- La dépendance aux processus manuels a été éliminée, réduisant les erreurs et augmentant la vitesse de livraison.
- La visibilité opérationnelle a été améliorée, avec davantage de contrôle, de sécurité et d'optimisation des ressources.
- Une plateforme agile, résiliente et prête pour des charges variables a été mise en place, y compris pour des projets de recherche HPC.
- Le respect des bonnes pratiques DevSecOps et Cloud Native a été facilité : une base adaptable pour faire évoluer l'innovation, réduire les coûts opérationnels et répondre avec agilité aux nouveaux besoins métier.
Cadre réglementaire
Dans la banque, la résilience et l'observabilité ne sont pas un extra : ce sont des exigences réglementaires. La plateforme a été conçue avec ce cadre à l'esprit.
- DORA (art. 28) : l'extension vers AWS est gouvernée comme un risque lié aux tiers TIC, avec traçabilité des déploiements, capacité de retour arrière et observabilité de bout en bout.
- NIS2 : sécurité des réseaux et des systèmes dans un secteur essentiel ; segmentation, contrôle des accès et alertes en temps réel.
- Continuité d'activité : disponibilité > 99,99 % et déploiements déclaratifs reproductibles comme preuve auprès du superviseur.
Questions fréquentes
Les services bancaires ont-ils été interrompus pendant la migration ?
Non. La migration s'est faite par phases, en commençant par une preuve de concept on-premise puis en s'étendant à AWS, avec une validation fonctionnelle à chaque étape. Les six environnements ont été migrés en maintenant une disponibilité de 99,9 % pendant la transition.
Pourquoi une plateforme hybride (RKE2 on-premise + EKS) et pas uniquement du cloud ?
Parce que la banque devait garder le contrôle des systèmes critiques on-premise et, en même temps, monter en charge sur AWS pour les charges variables. Une console de gestion unique orchestre les deux environnements.
Quel rôle joue GitOps dans un environnement régulé ?
Chaque changement est versionné, revu et auditable. Les déploiements déclaratifs avec Rancher Fleet, Helm et Kustomize sont passés de 45 minutes manuelles à 3-5 minutes reproductibles, avec une traçabilité complète.
Puis-je connaître l'établissement et les chiffres complets ?
Le cas est anonymisé dans le cadre d'un accord de confidentialité. Le détail de l'architecture et les chiffres complets sont partagés après signature d'un NDA.
Contenus associés
Dernière mise à jour: 2026-09-12