Points clés
- Le lock-in cloud rend le retour arrière coûteux — les services propriétaires créent des dépendances bien plus fortes que les services standardisés
- DORA impose aux institutions financières d'évaluer leur capacité de sortie des fournisseurs ICT critiques
- Une stratégie multi-cloud réduit le lock-in mais augmente la complexité opérationnelle : un arbitrage de gouvernance explicite
- Le règlement européen Data Act (2023) interdit les pratiques contractuelles qui rendent le changement de fournisseur cloud artificiellement difficile
La dépendance technique aux services cloud — le "vendor lock-in" — se construit progressivement à chaque adoption d'un service propriétaire. La migration initiale vers le cloud était motivée par la réversibilité ; la réalité opérationnelle produit souvent l'inverse. Les applications conçues pour AWS Lambda, Azure Cognitive Services ou Google BigQuery nécessitent une réécriture significative pour fonctionner ailleurs.
Ce risque a des implications stratégiques directes : si un fournisseur modifie unilatéralement ses tarifs, cesse un service, ou fait l'objet d'une sanction réglementaire, quelle est la capacité de l'organisation à migrer ? Cette "sortability" est une dimension de la résilience stratégique rarement évaluée lors des décisions initiales d'adoption.
Les niveaux de dépendance technique
Les dépendances cloud se distinguent par leur intensité. Les services standardisés (stockage objet compatible S3, bases de données MySQL, conteneurs OCI) créent des dépendances faibles : la migration vers un fournisseur alternatif est coûteuse mais faisable. Les services propriétaires — fonctions serverless, services d'IA, bases de données managées spécifiques — créent des dépendances fortes qui peuvent nécessiter une réécriture complète des applications concernées.
La décision d'adopter des services propriétaires versus standardisés est une décision de gouvernance avec des implications à long terme. Elle devrait être évaluée en termes de coûts de sortie potentiels, pas uniquement de valeur fonctionnelle immédiate.
Stratégies de réduction du lock-in
Quatre stratégies documentées permettent de réduire le lock-in : l'architecture cloud-agnostique (standards ouverts prioritaires), le multi-cloud délibéré (répartition des workloads entre fournisseurs), les couches d'abstraction (Kubernetes, Terraform), et la cartographie des dépendances (inventaire des services propriétaires utilisés avec évaluation régulière des coûts de migration). Chacune implique des compromis opérationnels et des coûts à arbitrer explicitement par la gouvernance.
Le règlement européen Data Act (2023) introduit des obligations légales pour les fournisseurs cloud : ils ne peuvent pas opposer de barrières techniques ou contractuelles injustifiées au changement de fournisseur, et doivent fournir des outils de portabilité des données dans des formats standardisés.
Suite aux sanctions économiques de 2022, plusieurs fournisseurs cloud américains ont cessé leurs services en Russie. Des organisations ayant des filiales dans ce pays ont dû conduire des migrations urgentes. Leurs dépendances aux services propriétaires AWS ou Azure rendaient ces migrations plus complexes et coûteuses que prévu. Le risque géopolitique du lock-in cloud pour les organisations opérant dans des environnements réglementaires volatils a été révélé de manière concrète.
L'initiative GAIA-X, lancée par la France et l'Allemagne, vise à réduire la dépendance des organisations européennes aux fournisseurs cloud américains. Sa motivation principale est la réduction du lock-in et le maintien de la souveraineté sur les données. Le Data Act européen interdit désormais les pratiques contractuelles rendant le changement de fournisseur artificiel — une avancée réglementaire directement issue du constat de lock-in massif dans les secteurs critiques.
Le gouvernement indien a adopté une politique de cloud souverain (MeghRaj) imposant aux ministères d'évaluer leur dépendance aux fournisseurs cloud étrangers. Plusieurs administrations ont découvert des dépendances à des services propriétaires AWS et Microsoft non évaluées lors des migrations initiales. Des programmes pluriannuels de réduction de ces dépendances ont été lancés, incluant le développement d'alternatives nationales pour les services les plus critiques.