Éviter le vendor lock-in dans le cloud : des choix concrets pour les PME

Il y a trois ans, vous avez tout basculé dans le cloud. La facture grimpe, un concurrent vous fait une meilleure offre, mais dès que vous chiffrez sérieusement un changement de fournisseur, c'est le silence : la moitié de vos données se trouve dans une base de données propriétaire, votre authentification dépend d'un seul fournisseur d'identité et vos workflows serverless sont écrits dans une syntaxe que seul votre fournisseur actuel comprend. En 2026, la dépendance fournisseur (vendor lock-in) n'est plus seulement un terme technique : c'est une raison de perdre des négociations commerciales. Dans ce guide, nous voyons comment une PME peut repérer le lock-in, pourquoi l'Union européenne vous aide désormais activement et quels choix font réellement la différence dès aujourd'hui.

Qu'est-ce que le vendor lock-in exactement ?

Le vendor lock-in signifie que le coût ou la complexité d'un changement de fournisseur est si élevé que, dans les faits, vous restez lié à un seul prestataire. C'est rarement un seul maillon. Il s'agit le plus souvent d'un empilement de trois couches qui forment ensemble un mur épais : des formats de données et services de stockage propriétaires, des API qui ne fonctionnent que sur cette plateforme, et des engagements commerciaux (instances réservées, remises en échange d'une durée plus longue) qui rendent le départ coûteux.

Le lock-in n'est pas forcément négatif. Choisir un service managé qui n'existe que chez le fournisseur X peut être la bonne décision si ce service est réellement meilleur. Le lock-in devient un problème dès lors que vous ne l'avez pas choisi en connaissance de cause, que vous n'avez pas de stratégie de sortie, ou que le coût de rester dépasse celui de migrer.

Pourquoi le lock-in est-il un sujet urgent aujourd'hui ?

En 2026, trois évolutions simultanées rendent le lock-in plus visible.

Premièrement, l'EU Data Act. Ce règlement (UE 2023/2854) s'applique aux services cloud depuis le 12 septembre 2025 et oblige les fournisseurs à lever les obstacles commerciaux, contractuels, techniques et organisationnels au changement de fournisseur. Tout contrat cloud doit contenir une clause de changement de fournisseur prévoyant une période de transition de 30 jours maximum, après un préavis de deux mois maximum. À partir de janvier 2027, les fournisseurs n'auront plus le droit de facturer de frais de changement ni de frais de sortie (egress).

Deuxièmement, les grands fournisseurs ont pris les devants. AWS, Google Cloud et Microsoft Azure ont supprimé leurs frais d'egress dès 2024, chacun avec ses propres conditions : Azure exige la résiliation de tous les abonnements Azure pour obtenir le crédit sur facture, et les services spécialisés comme ExpressRoute et le VPN en sont exclus. AWS exige une demande auprès du support et applique une fenêtre de 60 jours. Google a estimé que l'egress représente environ 2 % du coût total d'une migration : ce n'est donc pas une raison en soi pour migrer, mais cela abaisse le seuil politique.

Troisièmement, l'autorité britannique de la concurrence, la CMA, fait elle aussi pression depuis mars 2026 sur les frais d'egress et l'interopérabilité, ce qui a conduit AWS et Microsoft à prendre des engagements volontaires.

Autrement dit, vos chances de changer de fournisseur ont augmenté, mais uniquement si votre architecture et vos contrats le permettent. Une entreprise qui a bâti toute son activité sur des services propriétaires reste bloquée, aussi bas que soit le prix de l'egress.

Les trois couches où naît le lock-in

Données et stockage

C'est souvent là que se trouve le nœud le plus serré. Si vos données sont stockées dans un format propriétaire (par exemple une base NoSQL spécifique à un fournisseur) ou dans un service de stockage sans équivalent direct, la migration est douloureuse. Une base PostgreSQL se déménage en une semaine ; une base Cosmos DB ou DynamoDB avec triggers et procédures stockées exige un véritable projet de reconstruction.

Calcul et runtime

Les fonctions serverless séduisent parce qu'il n'y a rien à administrer, mais leurs interfaces de code divergent. Une fonction Lambda écrite avec un SDK AWS n'est pas une Azure Function. Les conteneurs sur Kubernetes sont quasi universels, un PaaS propriétaire ne l'est pas.

Identité et intégration

Votre authentification, votre stack de supervision, vos pipelines CI/CD : s'ils sont tous imbriqués avec un seul fournisseur, vous ne déménagez pas seulement vos workloads, mais tout votre processus opérationnel. C'est la couche que les PME sous-estiment le plus.

Quelle est l'ampleur du lock-in dans votre entreprise ?

Tout lock-in ne justifie pas une refonte de l'architecture. Voici un test pratique en trois questions :

1. Combien coûte le fait de rester ? Faites le point sur votre facture cloud annuelle, croissance comprise. Comparez-la aux prix du marché chez les alternatives.
2. Combien coûte le départ ? Estimez le nombre de mois-homme nécessaires pour l'extraction des données, la reconstruction du code et l'adaptation des intégrations. Ajoutez un trimestre supplémentaire pour les imprévus.
3. Quelle marge de manœuvre stratégique abandonnez-vous ? Un fournisseur qui augmente obstinément ses prix ou qui arrête un service, alors que vous n'avez aucune option de sortie réaliste, l'emporte à chaque négociation.

Si la réponse à la troisième question est « presque aucune » et que les hausses de prix restent limitées, rester en connaissance de cause est un choix tout à fait valable. Si une ou plusieurs réponses sont préoccupantes, il est temps d'agir, même si vous ne souhaitez pas changer de fournisseur maintenant.

Six choix d'architecture qui limitent le lock-in

1. Des formats de données ouverts, pas de modèles propriétaires

Conservez vos données dans des formats ouverts comme Parquet, Avro ou sous forme relationnelle classique (PostgreSQL, MySQL). Chaque fournisseur en propose des versions managées. Vous restez portable sans rien sacrifier en performances.

2. Kubernetes et conteneurs plutôt qu'un PaaS propriétaire

Un conteneur tourne partout. La même image Docker passe d'AWS ECS à Azure AKS puis à un Kubernetes on-premise sans reconstruction. Le serverless (Lambda, Azure Functions) se met en place plus vite, mais vous lie davantage. Pour la plupart des workloads de PME, un cluster Kubernetes léger ou un service d'application conteneurisé est largement suffisant, et pérenne pour des années.

3. L'infrastructure as code avec des outils indépendants du fournisseur

Terraform, OpenTofu et Pulumi décrivent votre infrastructure dans du code transposable (moyennant des adaptations) chez plusieurs fournisseurs. Un environnement configuré à la main en cliquant dans le portail ne peut être déplacé nulle part. L'IaC est en outre un gain pour vos opérations quotidiennes : environnements reproductibles et gestion de versions de votre infrastructure.

4. Une fine couche de logique propriétaire

Peut-on utiliser un service propriétaire ? Bien sûr, à condition de ne pas construire massivement par-dessus. La règle empirique : réservez les services propriétaires à la périphérie de votre architecture (par exemple pour une file d'attente managée ou un service d'IA spécifique), et encapsulez-les dans une couche d'abstraction afin que leur remplacement ne touche pas votre logique métier.

5. Identité ouverte, supervision ouverte

Utilisez les standards OpenID Connect et OAuth 2.0. Un fournisseur d'identité moderne comme Microsoft Entra ID n'est toujours pas portable à 100 %, mais les protocoles standard facilitent nettement l'ajout d'une couche intermédiaire de courtage d'identité. Basez vos logs et vos métriques sur OpenTelemetry : ils seront alors exploitables dans n'importe quelle plateforme d'observabilité.

6. Le multi-région contre la dépendance au cloud, le multi-cloud seulement en connaissance de cause

Le multi-cloud ressemble à la réponse ultime au lock-in, mais il est en pratique coûteux et complexe. Pour la plupart des PME, le multi-région chez un seul fournisseur suffit largement pour la disponibilité ; réservez le multi-cloud aux cas où vous avez une raison métier ou réglementaire claire. L'expérience montre que seule une minorité d'entreprises maîtrise réellement la portabilité entre fournisseurs.

Six choix contractuels qui gardent la porte de sortie ouverte

• Contrat annuel ou mensuel, pas d'engagement pluriannuel sans remise nette à la clé. Une remise de 10 % sur trois ans vaut rarement trois ans de flexibilité.
• Clause de sortie avec SLA pour le transfert des données. L'EU Data Act l'impose de fait depuis septembre 2025, mais formalisez-la explicitement : quel format, dans quel délai, avec quelle coopération.
• Clause de benchmark. Un accord qui vous permet de confronter vos prix au marché chaque année et de les renégocier en cas d'écart significatif.
• Portabilité de l'outillage. Toute la configuration en IaC, des intégrations documentées et des sauvegardes aux standards ouverts.
• Des modèles de prix transparents. Un tarif fixe par utilisateur ou par unité de consommation est transposable ; les colonnes de remises obscures des contrats entreprise le sont moins.
• Pas de crédits gratuits sans plan de sortie. Les crédits pour startups et les bonus de migration sont tentants, mais ils vous enfoncent plus profondément dans une stack dont vous ne sortirez pas, malgré vous, avant trois ans.

Microsoft 365 et Google Workspace : du lock-in aussi ?

Assurément, mais d'un autre type. Vos données dans Microsoft 365 ou Google Workspace sont exportables (exports OneDrive, exports de boîtes aux lettres) et les principaux formats de fichiers sont ouverts. Le lock-in tient à l'adoption par les utilisateurs : vos collaborateurs connaissent Outlook ou Gmail, et vos processus reposent sur SharePoint ou Drive. Changer exige donc surtout de la conduite du changement et de la formation, bien plus que de la portabilité des données. Pour approfondir, consultez notre comparatif Google Workspace et Microsoft 365 et notre guide complet sur l'externalisation de la gestion du cloud.

Ce que l'EU Data Act change pour votre contrat

En bref : tout contrat cloud que vous signez ou renouvelez aujourd'hui doit contenir une clause de changement de fournisseur. Le fournisseur ne peut pas mettre plus de 30 jours pour transférer vos données, après un préavis de deux mois maximum. Les frais de changement et d'egress restent autorisés sous une forme limitée jusqu'en janvier 2027, puis sont totalement interdits pour les services standard.

Concrètement : pour chaque nouveau contrat, demandez une section explicite sur le changement de fournisseur précisant les formats, les délais et l'obligation de coopération ; pour les contrats existants, demandez un avenant. L'EU Data Act fait peser cette exigence sur le fournisseur, la résistance devrait donc rester limitée. Notre guide sur le SaaS, le PaaS et l'IaaS pour les PME explique comment les responsabilités se répartissent selon le modèle de service.

Un exemple concret, légèrement anonymisé

Une PME d'e-commerce d'environ 40 salariés fonctionnait sur un PaaS propriétaire avec base de données managée et fonctions serverless. La facture augmentait chaque année. En quatre trimestres, nous avons placé la base de données derrière une interface compatible PostgreSQL, reconstruit les fonctions serverless sous forme de conteneurs et décrit l'infrastructure dans Terraform. Le devis d'un fournisseur concurrent est soudain devenu un véritable levier de négociation.

Questions fréquentes sur le vendor lock-in dans le cloud

Le cloud signifie-t-il automatiquement lock-in ? Pas automatiquement, mais souvent. Chaque cloud propose ses propres services managés qui vous incitent à utiliser des fonctionnalités propriétaires. Le lock-in naît des choix que vous faites dans le cloud, et non du simple fait d'« être dans le cloud ». Avec des formats ouverts, des conteneurs et l'infrastructure as code, vous conservez de vraies options de sortie, y compris dans le cloud.

Le multi-cloud est-il alors la solution ? Rarement pour une PME. Le multi-cloud double la complexité opérationnelle, les compétences nécessaires et parfois les coûts. Pour la plupart des PME, le multi-région chez un seul fournisseur apporte plus de valeur que le multi-cloud. Le multi-cloud devient intéressant face à des exigences réglementaires strictes, pour des produits SaaS qui doivent rester indépendants des fournisseurs ou pour des besoins de continuité spécifiques.

En combien de temps puis-je réduire le lock-in sans tout reconstruire ? En un an, vous pouvez déjà faire beaucoup de chemin. Commencez par l'IaC pour les nouveaux environnements, migrez une base de données propriétaire vers un équivalent ouvert et négociez une clause de changement de fournisseur dans chaque nouveau contrat. Les grandes reconstructions prennent plus de temps, mais l'essentiel du gain se trouve dans les 20 % de choix d'architecture qui déterminent 80 % de votre portabilité.

Les fournisseurs cloud ont-ils déjà l'interdiction de me facturer un changement de fournisseur ? Non, l'interdiction totale pour les services standard ne s'applique qu'à partir de janvier 2027 en vertu de l'EU Data Act. Pour l'instant, les fournisseurs doivent abaisser les obstacles et proposer des clauses de changement de fournisseur, et la plupart des grands acteurs ont déjà supprimé volontairement leurs frais d'egress en cas de départ (sous conditions).

Quel est l'impact du lock-in sur notre cybersécurité ? Le lock-in amplifie l'effet d'un incident chez votre fournisseur : si vous ne pouvez pas partir facilement, une panne prolongée ou un problème de sécurité vous touche plus durement. Une stratégie de sortie avec un transfert testé vers une alternative est en réalité aussi une mesure de continuité. Notre guide sur le plan de continuité d'activité montre comment l'intégrer à votre PCA.

Conclusion

En 2026, le vendor lock-in n'est plus une fatalité. L'EU Data Act contraint les fournisseurs à l'ouverture, les frais d'egress disparaissent et la plupart des outils techniques de portabilité (conteneurs, formats ouverts, infrastructure as code) sont suffisamment matures pour les PME. La question est de savoir si vos contrats et votre architecture vous donnent réellement l'option de sortie que la loi promet désormais. Commencez par un inventaire honnête des services propriétaires que vous utilisez, dressez une courte liste d'alternatives ouvertes et, dès aujourd'hui, négociez une clause de changement de fournisseur dans chaque nouveau contrat.

Vous voulez savoir à quel point votre environnement cloud actuel est verrouillé, et quelles étapes rapporteraient le plus dans votre situation ? TRON Group fait l'inventaire des architectures cloud de PME et y intègre la portabilité pas à pas, sans vous imposer une migration pénible. Appelez-nous sans engagement au +31 85 303 5869 ou découvrez notre offre de gestion du cloud pour un premier échange.