- Fonctionnalités
- Pricing

Cette page a été rédigée en anglais par nos experts, puis traduite par une IA pour vous y donner accès rapidement! Pour la version originale, c’est par ici.
Les institutions financières doivent prouver qu'elles peuvent fonctionner en toute sécurité dans le cloud sans devenir dépendantes d'un seul fournisseur de technologies. Que se passe-t-il si votre fournisseur cloud subit une défaillance ou si vous devez migrer?
Cette question était autrefois purement théorique. Cependant, depuis janvier 2025, c'est devenu une exigence réglementaire.
Le règlement européen sur la résilience opérationnelle numérique (DORA) exige des banques, des assureurs et des sociétés d'investissement qu'ils démontrent leur capacité à résister aux perturbations des plateformes cloud sur lesquelles ils s'appuient, notamment en disposant d'une stratégie de sortie documentée et testée pour chaque fournisseur de technologies.
Pour de nombreuses organisations, cela met en évidence une dure réalité : la plupart des déploiements cloud modernes sont étroitement liés à un seul fournisseur.
Si un régulateur vous demande comment tu quitterais AWS dès demain, « on trouverait une solution » n'est plus une réponse acceptable.
La plupart des architectures cloud ne sont pas portables. Elles reposent sur des services spécifiques à un fournisseur : fonctions AWS Lambda, bases de données natives Azure et configurations réseau propres à GCP, créant ainsi des dépendances profondes et invisibles. Au fil du temps, ces dépendances s’accumulent.
Quitter un fournisseur de cloud unique ne signifie pas simplement changer de compte d’hébergement. Cela implique de repenser l’architecture de ton application.
Pour une banque soumise à une réglementation, c’est risqué. Si une banque ne peut pas déplacer ses charges de travail hors d’un fournisseur, elle ne peut pas prouver sa résilience face aux pannes, aux mesures réglementaires ou aux perturbations géopolitiques.
C'est le risque de concentration que la DORA a été conçue pour traiter.
En novembre 2025, les autorités de surveillance de l'UE ont désigné 19 fournisseurs de TIC comme critiques au titre de la DORA, notamment AWS, Microsoft Azure et Google Cloud. Ces fournisseurs sont désormais soumis à une surveillance directe au niveau européen.
Pour les entités financières qui dépendent d’eux, le message est clair : prouve que tu n’es pas pris au piège.
En vertu de l'article 28 de la DORA, les entités financières doivent être en mesure de résilier leurs contrats avec les fournisseurs de TIC sans perturber les services ni enfreindre les exigences réglementaires. Cela signifie que les institutions doivent :
Quand les équipes entendent le terme « stratégie de sortie », leur premier réflexe est souvent d'adopter un environnement d'exécution multi-cloud : exécuter des applications simultanément chez plusieurs fournisseurs.
En pratique, cette approche est coûteuse et complexe.
Exécuter des charges de travail de production sur plusieurs clouds nécessite une infrastructure en double, une surveillance en double et des équipes opérationnelles en double. Pire encore, l’application elle-même peut encore dépendre de services spécifiques au fournisseur. La véritable portabilité reste hors de portée.
Ce dont les institutions financières ont vraiment besoin, c'est d'une portabilité standardisée : un modèle de déploiement où les applications peuvent être recréées chez un autre fournisseur d'infrastructure sans avoir à repenser tout le système.
Upsun adopte une approche différente face à ce problème.
Plutôt que de construire des applications autour d’un fournisseur de cloud spécifique, Upsun standardise la manière dont les applications sont définies et déployées. Le fondement de cette approche est un fichier de configuration unique : .upsun/config.yaml.
Cette configuration définit l'ensemble de l'environnement applicatif :
La définition de ton infrastructure n'est pas enfermée dans une console cloud ou une couche d'orchestration propri étaire. Elle est versionnée, vérifiable et portable.
Comme la configuration est indépendante du fournisseur, l'environnement d'application peut être recréé sur n'importe quelle infrastructure prise en charge, y compris AWS, Azure, Google Cloud, IBM et OVHCloud, sans avoir à repenser le modèle de déploiement.
Si une autorité de régulation exige un changement ou si un fournisseur subit une panne prolongée, l'application peut être restaurée ou migrée vers un autre fournisseur pris en charge en utilisant la même configuration Upsun et le même processus basé sur Git.
L'article 28 de la directive DORA impose aux entités financières de disposer de stratégies de sortie concrètes, tandis que l'article 30 définit des dispositions contractuelles spécifiques qui doivent figurer dans les accords avec les fournisseurs de TIC, couvrant la continuité du service, les droits de résiliation et la transition des données.
Upsun propose déjà un avenant contractuel DORA pour aider ses clients du secteur des services financiers à répondre à ces exigences.
Mais l'aspect technique est tout aussi important que l'aspect contractuel. La DORA attend des plans de sortie concrets, pas théoriques.
Une définition d’infrastructure portable et versionnée donne aux équipes de conformité un élément concret sur lequel s'appuyer : voici le schéma de référence
Combiné aux certifications de conformité existantes d’Upsun (ISO 27001, SOC 2 Type 2, PCI DSS Niveau 1, HIPAA et validation pour IBM Cloud for Financial Services), Upsun est conçu pour soutenir les équipes qui opèrent dans des environnements réglementés.
Une stratégie de sortie honnête nécessite plus qu'un simple fichier de configuration portable.
Déplacer une application de production d'un fournisseur de cloud à un autre nécessite toujours un processus de migration planifié : transfert de données, nouveaux tests d'intégration, basculement DNS, validation des performances et validation par les parties prenantes.
Aucune plateforme n'élimine entièrement ce travail.
Ce qu’Upsun élimine, c’est la refonte de l’infrastructure.
Le code de votre application ne change pas. Ton pipeline de build ne change pas. Tes définitions de service ne changent pas.
L'effort de migration se concentre sur les étapes opérationnelles : données, tests et basculement, et non sur la reconstruction de tout à partir de zéro. C'est une position de départ fondamentalement différente de celle d’une migration vers une nouvelle plateforme à partir d’une architecture spécifique à un fournisseur.
Si tu es une institution financière qui se prépare aux exigences de la stratégie de sortie de la DORA, commence par là :
Avec Upsun, la réponse commence par un fichier qui se trouve déjà dans ton dépôt Git.