4 min de lecture
Le verrouillage fournisseur a longtemps été le prix que les entreprises ont payé pour le confort du cloud. En 2026, les rapports de force s’inversent : le Règlement européen sur les données (Data Act) crée des leviers réglementaires, Kubernetes fournit l’abstraction technique – et un nombre croissant d’entreprises allemandes construisent délibérément leur infrastructure de manière multi-fournisseur.
L’essentiel
- Le Règlement européen sur les données (Data Act), entré en vigueur en janvier 2024, oblige les fournisseurs de services cloud, à compter de septembre 2025, à garantir la portabilité des données et à proposer des interfaces interopérables – une étape décisive vers la souveraineté cloud – un changement de paradigme pour le verrouillage fournisseur.
- Kubernetes s’est imposé comme la norme de fait pour l’abstraction cloud : selon la CNCF, 84 % des entreprises dans le monde utilisent des conteneurs en production.
- Des entreprises allemandes telles que Zalando, Deutsche Bahn et Otto Group adoptent des architectures multi-cloud afin de réduire leur dépendance vis-à-vis des seuls hyperscalers.
- La stratégie multi-cloud peut élargir les marges de négociation sur les conditions tarifaires, mais augmente la complexité opérationnelle. L’impact global sur les coûts dépend fortement du niveau de maturité en matière de gouvernance et des compétences en FinOps.
- Le principal obstacle n’est pas technologique, mais organisationnel : la multi-cloud exige une gouvernance unifiée, une gestion transverse des compétences et une équipe FinOps centrale.
Le calcul est simple : celui qui exploite toute son infrastructure chez un seul hyperscaler bénéficie d’une intégration fluide et d’un grand confort – mais perd sa capacité de négociation, sa portabilité et, dans un scénario critique, l’accès à ses propres données. Selon le Flexera State of the Cloud 2025 Report, 70 % des décideurs IT interrogés citent le verrouillage fournisseur parmi leurs trois principaux risques cloud. Pourtant, de nombreuses entreprises peinent à s’en libérer – car les services propriétaires, les API liées à un fournisseur spécifique et les dépendances accumulées rendent la migration coûteuse et complexe.
Le Règlement européen sur les données (Data Act) : un soutien réglementaire décisif
Le Règlement européen sur les données (Data Act), en vigueur depuis janvier 2024, déploiera pleinement ses effets sur les services cloud à partir de septembre 2025. Ses exigences fondamentales sont les suivantes :
Les fournisseurs de services cloud doivent assurer l’équivalence fonctionnelle – ce qui signifie que les clients doivent pouvoir migrer leurs charges de travail vers un autre fournisseur sans avoir à les reconcevoir entièrement. Les frais de changement de fournisseur (Switching Charges) – c’est-à-dire les frais engagés lors d’un changement de prestataire – seront progressivement supprimés : à compter de septembre 2025, seuls les coûts directs liés au processus de migration pourront être facturés ; à partir de janvier 2027, tous les frais de changement de fournisseur disparaîtront totalement. En outre, les fournisseurs doivent mettre à disposition des interfaces ouvertes permettant l’exportation des données et des configurations.
Pour les entreprises allemandes, il s’agit là d’une opportunité stratégique. Celles qui, jusqu’à présent, redoutaient la complexité d’une migration multi-cloud obtiennent désormais, grâce au Data Act, des leviers réglementaires capables d’accroître la pression négociatrice exercée sur les hyperscalers. Parallèlement, l’interdiction des frais de changement de fournisseur abaisse la barrière économique à une migration partielle.
Toutefois, le Data Act ne fonctionne pas de lui-même. La définition de « l’équivalence fonctionnelle » est volontairement formulée de façon floue, et il faudra plusieurs années avant que les actes d’exécution ne soient précisés dans tous leurs détails. Les entreprises qui agissent dès maintenant se donnent un avantage concurrentiel – mais elles ne devraient pas attendre la réglementation pour poser les fondations techniques en parallèle.
Kubernetes comme couche d’abstraction
La réponse technique au verrouillage fournisseur s’appelle abstraction – et Kubernetes est l’outil qui rend cette abstraction opérationnelle. Cette plateforme d’orchestration de conteneurs permet de déployer et d’exploiter des charges de travail indépendamment du fournisseur sous-jacent de l’infrastructure.
Selon l’Enquête annuelle 2024 de la CNCF, 84 % des entreprises interrogées utilisent des conteneurs en production. En Allemagne, le taux d’adoption atteint, selon Bitkom, 67 % des entreprises de plus de 500 employés – soit une hausse de 15 points de pourcentage par rapport à l’année précédente.
Kubernetes, pris isolément, ne résout toutefois pas entièrement le problème du verrouillage fournisseur. Les services Kubernetes gérés, tels qu’EKS (AWS), AKS (Azure) ou GKE (Google), intègrent fréquemment des fonctions spécifiques à un fournisseur – équilibreurs de charge, classes de stockage, gestion des identités – qui réduisent partiellement l’avantage de portabilité.
La clé réside donc dans une décision architecturale consciente : quels fonctionnalités de Kubernetes utiliser de façon multi-fournisseur ? Quels services propriétaires accepter délibérément ? Et où tracer la ligne ? Des entreprises comme Zalando ont pris cette décision de façon systématique et exploitent leur plateforme e-commerce sur une architecture Kubernetes portable entre AWS et leur propre centre de données.
Pratique : des entreprises allemandes en route vers la multi-cloud
Zalando : Ce groupe e-commerce berlinois a très tôt opté pour une plateforme Kubernetes indépendante de tout fournisseur. L’infrastructure repose principalement sur AWS, mais elle est suffisamment abstraite pour permettre, théoriquement, l’exécution de certains services sur d’autres plateformes. La valeur stratégique réside ici dans la capacité de négociation renforcée face à AWS lors des discussions tarifaires.
« Le verrouillage fournisseur a longtemps été le prix que les entreprises ont payé pour le confort du cloud. En 2026, les rapports de forces s’inversent. »
Deutsche Bahn : DB Systel, filiale informatique de Deutsche Bahn, exploite une plateforme multi-cloud basée sur AWS et Azure. Les applications destinées aux voyageurs tournent sur AWS, tandis que les charges de travail SAP internes ont été migrées vers Azure. Une équipe centrale de plateforme veille à ce que les politiques de sécurité et les exigences de conformité soient appliquées de façon uniforme sur les deux clouds.
Otto Group : Ce groupe commercial de Hambourg utilise Google Cloud comme plateforme principale, complétée par une infrastructure sur site (on-premises) pour les systèmes hérités (legacy). Ici, la stratégie multi-cloud est moins motivée par des considérations techniques que par des impératifs organisationnels : différentes sociétés du groupe peuvent choisir librement leur plateforme cloud préférée, à condition de respecter les standards centraux de gouvernance.
Le socle organisationnel
La multi-cloud est avant tout une décision organisationnelle. La technologie seule ne suffit pas – les entreprises ont besoin de trois éléments :
Une gouvernance unifiée : Qui décide sur quelle plateforme chaque charge de travail sera déployée ? Quels services peuvent rester propriétaires, quels autres doivent demeurer portables ? Sans instance centrale de gouvernance – qu’il s’agisse d’un Cloud Center of Excellence ou d’un comité d’architecture – , la multi-cloud dégénère en chaos plutôt que de constituer une véritable stratégie.
Un FinOps transverse : Une approche multi-cloud sans suivi centralisé des coûts est une recette pour l’explosion budgétaire. Chaque fournisseur dispose de ses propres modèles tarifaires, de ses propres structures de rabais (Reserved Instances, Committed Use Discounts, Savings Plans) et de ses propres logiques de facturation. Une équipe FinOps ayant une vision globale de toutes les plateformes n’est pas une option, mais une obligation.
Une gestion des compétences : AWS, Azure et Google Cloud constituent trois écosystèmes distincts, chacun doté de ses propres certifications, de ses bonnes pratiques spécifiques et de ses propres modes de pensée. La pénurie de talents spécialisés accentue encore ce défi. Les entreprises doivent décider si elles privilégient des équipes « en T » – polyvalentes, avec une expertise approfondie sur une seule plateforme – ou si elles misent sur des équipes spécialisées par cloud, en orchestrant l’intégration de façon centralisée.
Les entreprises qui réussissent leur multi-cloud ont un point commun : elles ne traitent pas la stratégie cloud comme un projet IT, mais comme une décision d’entreprise. Le niveau directionnel (CIO) définit les grandes lignes directrices, tandis que les équipes d’ingénierie les mettent concrètement en œuvre.
Questions fréquentes
À partir de quand le Règlement européen sur les données (Data Act) s’applique-t-il aux services cloud ?
Le Règlement européen sur les données (Data Act) est entré en vigueur en janvier 2024. Les dispositions spécifiques relatives au changement de fournisseur cloud (cloud switching) et à la portabilité des données s’appliquent à compter de septembre 2025. Les fournisseurs de services cloud disposent d’un délai de transition de 40 mois pour adapter les contrats existants.
La multi-cloud est-elle toujours moins coûteuse que la single cloud ?
Pas automatiquement. La multi-cloud peut réduire les coûts grâce à une meilleure position négociatrice et à une optimisation des charges de travail – mais l’exploitation de plusieurs plateformes génère également des coûts supplémentaires liés à la complexité. L’effet net dépend du volume, du niveau de maturité en matière de gouvernance et des compétences en FinOps.
Kubernetes seul suffit-il à éviter le verrouillage fournisseur ?
Non. Kubernetes abstrait la couche de calcul (compute), mais les applications utilisent fréquemment des services propriétaires tels que des bases de données, des files de messages (message queues) ou des fournisseurs d’identité (identity providers). Une décision architecturale consciente – définissant quels services doivent être portables et lesquels peuvent rester propriétaires – est indispensable.
Lectures complémentaires
- Les professionnels du cloud : pourquoi l’Allemagne rattrape son retard en matière de montée en compétences – cloudmagazin
- La consolidation des solutions SaaS : comment les DSI maîtrisent le foisonnement d’outils – cloudmagazin
- L’informatique périphérique (Edge Computing) et l’Industrie 4.0 – cloudmagazin
Plus encore dans le réseau média MBF Media
- Rapatriement de la production en Europe : repenser les chaînes d’approvisionnement – MyBusinessFuture
- Conseil d’administration numérique : développer les compétences technologiques au sein des conseils d’administration – Digital Chiefs
- Assurance cyber 2026 – SecurityToday
Source de l’image : Pexels / Panumas Nikhomkhai
