Cloud
Se « détacher » des offres des CSP
Par Alain Clapaud, publié le 28 janvier 2026
Les CSP et en particulier les hyperscalers proposent des catalogues de services particulièrement riches et innovants. Des fonctions extrêmement avancées en termes de haute disponibilité, de cybersécurité, sont accessibles d’un simple appel d’API, et les architectes ne se privent pas de les exploiter… avec un risque de vendor lock-in évident.
Les droits de douane imposés par Donald Trump, la dénonciation sur les réseaux sociaux des accords noués avec l’Europe tels que le Digital Markets Act et le Digital Services Act, mais aussi les mesures de rétorsion prises à l’encontre des membres de la Cour internationale de La Haye ont clairement remis d’actualité la dépendance des Européens aux fournisseurs de services cloud américains.
Dans une étude de janvier 2025, le Cigref avec Asteres estime à 264 Md€ par an la facture pour l’Europe. Or, pour de nombreux services, il existe une alternative européenne aux GAFAM. Pour autant, migrer des espaces de stockage, des machines virtuelles ou des applications « cloud native » vers ces acteurs « domestiques » est-il si simple ?
Les limites de l’approche contractuelle
Du point de vue des juristes, ce risque du vendor lock-in doit être anticipé dans le contrat signé avec le CSP. Pour celles des entreprises qui peuvent imposer leurs clauses aux hyperscalers, ils suggèrent d’ajouter des clauses de réversibilité aux contrats. Il s’agit de s’assurer, dans les pires cas, de pouvoir récupérer ses données en cas de rupture de ceux-ci.
Car si tous les fournisseurs cloud affirment à leurs clients qu’ils le peuvent à tout moment, le diable se niche dans les détails. Le contrat doit mentionner précisément les modalités de transfert des données, par exemple les formats concernés, ou les médias qui seront mis en œuvre, voire les SLA du service support.
Attention aussi aux coûts indirects qui peuvent être facturés par le CSP, notamment les fameux coûts d’egress lorsqu’il s’agit de transférer des To de données hors du datacenter. Les négociations peuvent être très poussées sur le plan de la réversibilité. On peut notamment prévoir une période de double run pour éviter que la migration ne tourne à la roulette russe le jour J.
Les services managés engendrent une forte adhérence
Outre quelques chausse-trappes, comme la facturation du trafic sortant ou le bridage des API permettant les transferts, une migration cloud à cloud est loin d’être simple. Au plus l’entreprise fait appel aux services managés proposés par le CSP, au plus il lui sera difficile de migrer.
C’est notamment le cas des applications cloud native créées par les développeurs qui ont exploité au maximum les services managés et les fonctions serverless pour gagner du temps et réduire la charge de maintenance.
Même les services IaaS n’échappent pas à cette adhérence si on met en oeuvre les fonctions réseau, les outils d’authentification, ses firewalls, etc.
Dans ces conditions, une migration s’apparentera plus à une reconstruction de l’architecture à partir de zéro qu’ à une simple translation d’un cloud à un autre.
La compatibilité avec les hyperscalers, un facilitateur à la migration
Pour faciliter l’interopérabilité avec les hyperscalers, le français Outscale, filiale cloud de Dassault Systèmes, a plutôt fait le choix de reprendre les API du leader du marché, AWS : « Dès la création d’Outscale en 2010, nous sommes partis du principe que le standard de fait du cloud public était dicté par le leader mondial, explique David Chassan, directeur stratégie du fournisseur. Nous avons créé l’API qui permet l’automatisation des ressources, afin qu’elle soit compatible avec leurs services EC2 et S3. Ce qui permettait à des clients qui avaient peut-être initié leur stratégie cloud avec AWS d’opérer avec nous. »
Cela a notamment été le cas d’OpenDataSoft qui a démarré ses activités avec un hyperscaler américain, mais a pu mettre en oeuvre sa solution sur Outscale en complément pour la partie souveraine de son service, sans avoir à retravailler l’ensemble des automatisations d’API en place. Outscale, ayant fait le choix de développer son propre hyperviseur, TinaOS, a pu développer des API compatibles avec AWS, par opposition aux CSP qui ont monté leur service sur VMware ou OpenStack.
David Chassan
Directeur stratégie d’Outscale, Dassault Systèmes
« Tous les clients utilisent aujourd’hui deux, trois, voire plus, clouds différents, y compris des clouds internes. L’avantage de Kubernetes est d’apporter sa couche d’abstraction par-dessus cette infrastructure, qui permet aux équipes de pouvoir déployer et de gérer l’ensemble du SI de manière plus centralisée et automatisée. Nous le voyons comme le nouveau standard d’usage du cloud. »
Avec ses API et le support de Terraform et Packer, Outscale veut faciliter l’intégration de ses services à la stratégie Infrastructure as code de ses clients. On retrouve cette volonté chez Cloud Temple, un CSP français certes partenaire Azure, mais aussi très actif sur le cloud souverain, en témoigne la qualification SecNumCloud de ses services. Christophe Lesur, son directeur général, souligne : « La grande tendance, c’est que toutes les ressources soient accessibles de façon programmatique, via les API. Il faut pouvoir piloter les infrastructures cloud avec des outils du marché, à l’image de Terraform d’HashiCorp, la référence du marché. C’est ce qui permet de ne pas être verrouillé par le dialecte Microsoft, AWS ou Google. »
Selon le responsable, à partir du moment où l’entreprise est capable de déployer son infrastructure de façon automatique, alors elle pourra réduire son vendor lock-in.
Kubernetes pour libérer l’entreprise de ses chaînes ?
Une solution technique alternative est en train de s’imposer pour réduire cette adhérence aux plateformes cloud : le recours aux conteneurs logiciels et au standard de fait de l’orchestration des conteneurs, Kubernetes. « C’est l’une des clés du succès de Kubernetes : avec cette solution, vous avez cette capacité de pouvoir déplacer vos applications avec assez peu de contraintes, et opérer ce qu’on appelle des réversibilités, dans des temps contraints, à des risques et des coûts acceptables », explique Christophe Lesur.
Mais aller vers les conteneurs oblige à une montée en compétences des équipes Ops, le prix à payer pour se désengluer des CSP. Et à faire de l’interopérabilité un prérequis à la conception des applications et des architectures, et s’interdire les fonctions managées qui vont à son encontre. Tout un programme et de longue haleine.
« Les risques de panne chez notre fournisseur cloud historique seront au coeur de notre PRA »
« Lorsque je suis arrivé dans le groupe, l’infrastructure on-premise accusait le poids des ans. Nous avons lancé un chantier de move to cloud et basculé notre infrastructure sur Microsoft Azure. Nous n’avions pas véritablement anticipé le phénomène de vendor lock-in, mais l’arrivée de Donald Trump au pouvoir aux États-Unis a clairement mis sur la table la problématique de notre dépendance vis-à-vis des fournisseurs américains, et notamment de Microsoft. Nous nous sommes intéressés à Terraform pour aller vers une approche Infrastructure as code, mais notre architecture ne s’y prête pas. Notre intégrateur, un expert Azure, a eu recours à de nombreux services délivrés par la plateforme Microsoft. De fait, nous sommes très liés à celle-ci et il n’y a pas de compatibilité avec des services comparables disponibles sur les autres clouds. Mais nous allons être soumis à NIS 2, ce qui débouchera sur un PRA robuste et nous oblige à travailler sur les risques de panne majeure chez notre fournisseur cloud. Traiter cette dépendance sera au coeur de notre PRA. »
Grégory Péruchon de Brochard
Directeur de l’organisation et des systèmes d’information du groupe CVE
Cet article constitue la seconde partie de notre dossier « Et si les DSI se libéraient de l’emprise des fournisseurs IT« .
Première partie : Un combat long mais nécessaire
Seconde partie : Broadcom / VMware : après le cauchemar, les réveils ?
À LIRE AUSSI :
