Extension dynamique du GRID vers le cloud
Un grand groupe financier espagnol devait absorber les pics de calcul de risque de sa salle des marchés sans ajouter de matériel. Nous avons étendu son GRID vers le cloud avec un autoscaling transparent : −35 % de temps d'exécution, +200 % de capacité et −20 % de coût mensuel de calcul.
Défi
Infrastructure on-premise saturée lors des pics quotidiens de calcul de risque (exigences de Bâle et de la Banque d'Espagne). Monter en charge par des moyens traditionnels était lent et coûteux et, en période de faible occupation, la plateforme restait surdimensionnée.
Solution
Des groupes d'autoscaling qui créent et détruisent des nœuds cloud selon la charge détectée par les gestionnaires de calcul, intégrés de façon transparente au cluster GRID existant : les ressources internes sont utilisées en premier et, si elles ne suffisent pas, des nœuds sont activés dans le cloud et s'éteignent une fois le travail terminé.
Technologies
- HPC / Grid Computing
- Cloud bursting avec Auto Scaling Groups
- Architecture hybride on-premise + cloud
- Automatisation du cycle de vie des nœuds
Contexte
La salle des marchés d'un grand groupe financier espagnol exécute des calculs de risque de plus en plus complexes et fréquents, en réponse à des exigences réglementaires telles que celles de Bâle ou de la Banque d'Espagne. Ces calculs s'exécutent sur un système GRID d'entreprise qui répartit les tâches entre des milliers de cœurs on-premise.
Le problème n'était pas un manque de technologie, mais une infrastructure qui ne montait pas en charge sous pression : les pics quotidiens saturaient la capacité disponible et, en dehors de ceux-ci, la plateforme restait surdimensionnée. L'organisation avait besoin d'une solution flexible, scalable et compatible avec le GRID déjà en place, sans le remplacer.
Le défi
Quatre points de friction concentraient le coût, les délais et le risque réglementaire :
- Surcharge aux moments critiques : les pics de calcul quotidiens, en particulier ceux de la Trésorerie, saturaient l'infrastructure disponible.
- Montée en charge lente et coûteuse : ajouter du matériel n'était ni viable à court terme ni efficace à long terme.
- Faible efficacité opérationnelle : en période de faible charge, l'infrastructure était surdimensionnée, à un coût peu optimisé.
- Dépendance à l'environnement local : l'architecture GRID existante limitait l'adoption de solutions plus flexibles sans une intégration adéquate.
Approche par phases
Le projet s'est déroulé en cinq phases, garantissant une adoption progressive, contrôlée et alignée sur les exigences opérationnelles de la banque.
-
01
PoC et architecture hybride
Validation technique initiale et conception d'une architecture compatible avec le GRID existant et avec le cloud.
-
02
Définition de l'autoscaling
Établissement des métriques de charge qui activent des nœuds selon la demande réelle des gestionnaires de calcul.
-
03
Intégration et tests
Validation du fonctionnement des nœuds cloud comme partie transparente du cluster de calcul.
-
04
Automatisation et supervision
Orchestration complète du cycle de vie des nœuds et supervision continue avec alertes préventives.
-
05
Charges réelles et ajustements
Exécution de charges de production et réglage fin des politiques de mise à l'échelle.
Architecture et stratégie
La clé a été d'étendre, et non de remplacer. Des groupes d'autoscaling (Auto Scaling Groups) ont été configurés pour créer et détruire automatiquement des nœuds cloud en fonction de la charge détectée par les gestionnaires de calcul. Ces nœuds s'intègrent au cluster de calcul de la banque, de sorte que les processus de risque et de trésorerie les utilisent comme s'ils faisaient partie de l'environnement on-premise.
Le flux est simple : les tâches de calcul sont gérées depuis le système central GRID ; les cœurs fixes internes, toujours actifs, sont utilisés en premier ; s'ils s'avèrent insuffisants, des cœurs supplémentaires sont activés automatiquement dans le cloud ; une fois les tâches terminées, ces nœuds s'éteignent d'eux-mêmes. Compatibilité totale avec l'infrastructure existante, scalabilité adaptée à la charge réelle, automatisation du cycle de vie des ressources cloud et supervision continue avec capacité de réaction immédiate.
Résultats mesurables
L'architecture hybride a transformé un goulot d'étranglement opérationnel en avantage concurrentiel : elle n'a pas seulement résolu le problème de charge, elle a amélioré la performance des systèmes de risque et de trésorerie.
| Indicateur | Avant | Après |
|---|---|---|
| Temps total d'exécution des charges de calcul de risque | Fenêtres saturées lors des pics | −35 % |
| Capacité de calcul | Limitée au matériel on-premise | +200 % sans investissement physique |
| Coût opérationnel mensuel de calcul | Surdimensionnement permanent | −20 % en moyenne (paiement à l'usage) |
| Scalabilité validée | Extension manuelle du matériel | +1 500 cœurs simultanés |
Chiffres agrégés et anonymisés dans le cadre d'un accord de confidentialité. Source : projets de Vermont Solutions.
Enseignements transposables
- Étendre plutôt que remplacer : on obtient les avantages du cloud sans perturbation ni risque pour l'exploitation de la Trésorerie.
- L'autoscaling à la demande élimine le surdimensionnement et transforme le coût fixe en coût variable.
- L'intégration transparente dans le cluster évite de modifier les processus métier : pour le gestionnaire de calcul, un nœud cloud est un nœud comme un autre.
- La supervision continue avec alertes préventives est ce qui permet de faire confiance à la mise à l'échelle automatique dans un environnement régulé.
Cadre réglementaire
Le calcul de risque d'un établissement bancaire est soumis à des délais et aux exigences du superviseur ; la capacité de calcul est donc une exigence de conformité, et pas seulement d'efficacité.
- Bâle III/IV et les exigences de la Banque d'Espagne : des calculs de capital et de risque plus fréquents et plus exigeants.
- DORA (art. 28) : l'extension vers le cloud est conçue comme un risque lié aux tiers TIC, avec contrôle du prestataire et résilience opérationnelle numérique.
- NIS2 : sécurité des réseaux et des systèmes dans un secteur essentiel ; routage sécurisé entre le datacenter et le cloud (répartiteurs de charge, VPN, règles de failover).
Questions fréquentes
A-t-il fallu modifier les processus de risque ou de trésorerie pour utiliser le cloud ?
Non. Les nœuds cloud s'intègrent au cluster GRID existant et les gestionnaires de calcul les traitent comme leurs propres cœurs. Les processus métier ne changent pas ; ce qui change, c'est la capacité disponible derrière eux.
Que devient le coût lorsqu'il n'y a pas de pics de charge ?
Les nœuds cloud s'éteignent d'eux-mêmes à la fin des tâches. Le modèle de paiement à l'usage élimine le surdimensionnement : le coût opérationnel mensuel de calcul a baissé de 20 % en moyenne.
Est-ce applicable à un GRID sur IBM Spectrum Symphony ou TIBCO DataSynapse ?
Oui. La conception est indépendante du gestionnaire de calcul : l'extension se fait au niveau des nœuds du cluster. Vermont maintient une équipe spécialisée sur les deux produits et sur leur migration.
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