Migrer vers un cloud américain prend quelques jours. En repartir peut prendre des mois et coûter des dizaines de milliers d'euros. Ce phénomène porte un nom : le vendor lock-in, ou verrouillage fournisseur.
Selon une enquête Flexera (2025), 74 % des entreprises considèrent le vendor lock-in comme leur préoccupation principale en matière de cloud. Ce guide analyse les cinq formes de verrouillage, illustre chacune par des exemples concrets, et propose des stratégies de sortie.
Qu'est-ce que le vendor lock-in ?
Le vendor lock-in désigne la situation dans laquelle une entreprise devient dépendante d'un fournisseur technologique au point où le coût de migration vers un concurrent devient prohibitif. Ce verrouillage n'est pas accidentel : il est souvent intégré dans la stratégie commerciale des éditeurs.
« Les fournisseurs de services d'informatique en nuage prennent les mesures nécessaires pour que les obstacles [...] au changement de fournisseur soient supprimés de manière effective. »
Règlement (UE) 2023/2854 (Data Act), Article 23, paragraphe 1
Le Data Act européen, entré en application le , impose désormais aux fournisseurs cloud de faciliter le changement. Mais les effets pratiques restent limités face aux verrouillages techniques profonds.
Les 5 types de verrouillage
1. Verrouillage par les données
Vos données sont stockées dans un format propriétaire ou difficilement exportable. L'export est possible mais coûteux en temps et en frais de transfert (egress fees).
Exemple : exporter ses données depuis Salesforce coûte entre 10 000 et 50 000 USD selon le volume, et nécessite souvent des consultants spécialisés pour convertir les schémas propriétaires. AWS facture les frais d'egress entre 0,09 et 0,12 USD/Go pour les données sortant de ses datacenters.
2. Verrouillage par les API
Votre code applicatif utilise des API spécifiques au fournisseur. Changer de prestataire impose de réécrire des portions entières de votre application.
Exemple : les fonctions Lambda (AWS), Cloud Functions (Google) et Azure Functions utilisent chacune un format d'invocation, un système de déclencheurs et un modèle de facturation différents. Un code serverless écrit pour Lambda ne fonctionne pas sur Google Cloud sans adaptation significative.
3. Verrouillage contractuel
Les engagements de durée, les remises sur volume et les conditions de résiliation rendent la sortie financièrement dissuasive.
Exemple : Google Workspace propose des remises de 20 à 30 % pour des engagements annuels. Résilier en cours de contrat implique de renoncer à la remise et de payer le reliquat. Certains contrats enterprise AWS incluent des clauses de volume minimal garanti sur 3 ans.
4. Verrouillage par les compétences
Votre équipe technique s'est formée sur un écosystème spécifique. Le coût de reconversion est élevé.
Exemple : un développeur certifié AWS Solutions Architect a investi 6 à 12 mois de formation. Ses réflexes architecturaux (S3 pour le stockage, DynamoDB pour le NoSQL, SQS pour les files) sont spécifiques à AWS. Migrer vers un cloud européen nécessite un réapprentissage.
5. Verrouillage par l'écosystème
Plus vous utilisez de services du même fournisseur, plus il devient coûteux de migrer l'ensemble.
Exemple : une entreprise utilisant Google Workspace (email) + Google Analytics (analytics) + Google Cloud (hosting) + Google Ads (publicité) + BigQuery (data) a un coût de sortie exponentiel. Chaque brique est interconnectée, et migrer l'une sans les autres crée des frictions opérationnelles.
Les coûts réels d'une sortie
Le coût d'une migration de sortie se décompose en quatre postes :
| Poste de coût | Estimation PME (50 salariés) | Commentaire |
|---|---|---|
| Frais d'egress (transfert de données) | 500 à 5 000 € | Facturés par Go transféré par AWS/GCP/Azure |
| Adaptation du code applicatif | 5 000 à 30 000 € | Réécriture des intégrations API propriétaires |
| Formation des équipes | 2 000 à 10 000 € | Montée en compétences sur le nouvel écosystème |
| Interruption de service | Variable | Dépend de la stratégie de migration (big bang vs. progressive) |
Le Data Act européen (article 25) supprime progressivement les frais d'egress d'ici . D'ici là, ces frais restent un levier de rétention puissant.
L'open-source comme voie de sortie
Les logiciels open-source, lorsqu'ils sont auto-hébergés, éliminent structurellement le vendor lock-in :
- Pas de format propriétaire : les données sont stockées en formats ouverts (PostgreSQL, S3-compatible)
- Pas d'API captive : les standards ouverts (OAuth, REST, GraphQL) sont la norme
- Pas d'engagement contractuel : la licence open-source garantit la liberté d'usage
- Portabilité native : vous pouvez migrer votre instance vers n'importe quel hébergeur compatible
Exemples de substitutions souveraines et portables : Matomo (remplace Google Analytics), Plausible (alternative légère), Nextcloud (remplace Google Drive/Dropbox), Rocket.Chat (remplace Slack). Consultez le comparateur d'alternatives souveraines pour trouver un équivalent à chaque service propriétaire.
Stratégies de migration
Trois approches possibles :
- Migration progressive (recommandée) : migrer service par service, en commençant par les moins critiques. Avantage : risque maîtrisé. Durée : 3 à 12 mois pour une PME.
- Migration parallèle : faire fonctionner l'ancien et le nouveau système en parallèle pendant une période de transition. Avantage : continuité de service. Inconvénient : coût double temporaire.
- Big bang : migrer tout en une fois lors d'un week-end planifié. Avantage : rapide. Inconvénient : risque élevé d'interruption.
Quelle que soit la stratégie choisie, un audit initial est indispensable pour connaître l'étendue de vos dépendances. Les experts COCORRIDOR accompagnent les PME dans la planification et l'exécution de migrations souveraines.
Foire aux questions
Le vendor lock-in est-il illégal en Europe ?
Le vendor lock-in n'est pas illégal en soi, mais le Data Act (règlement 2023/2854) impose aux fournisseurs cloud de faciliter le changement. Les frais d'egress doivent être supprimés d'ici janvier 2027 (article 25). Les fournisseurs doivent garantir la portabilité des données en formats ouverts (article 23). En pratique, l'application de ces obligations reste progressive.
Peut-on éviter le lock-in dès le départ ?
Oui, en adoptant trois principes : (1) privilégier les standards ouverts (PostgreSQL, S3-compatible, SMTP standard), (2) éviter les services propriétaires sans équivalent (DynamoDB, BigQuery), (3) conteneuriser vos applications (Docker, Kubernetes) pour garantir la portabilité de l'infrastructure.
Mon hébergeur européen peut-il aussi créer du lock-in ?
Oui. Le vendor lock-in n'est pas exclusif aux acteurs américains. Cependant, les hébergeurs européens (Scaleway, OVHcloud, Infomaniak) proposent généralement des services compatibles avec les standards ouverts (S3-compatible, Kubernetes managéé, PostgreSQL natif), ce qui réduit fortement le risque de verrouillage technique.