Vous avez choisi un logiciel parce qu'il était le meilleur du marché au moment de la signature. Deux ans plus tard, les prix ont doublé, le support s'est dégradé — et migrer serait trop coûteux, trop risqué, trop long. Vous êtes pris au piège.
C'est ça, le vendor lock-in. Et contrairement à ce qu'on pourrait croire, ce n'est pas réservé aux grandes entreprises. Les PME, les startups et les équipes en croissance en sont souvent les premières victimes — précisément parce qu'elles ont moins de ressources pour anticiper ces situations.
Le vendor lock-in ne commence pas le jour où vous voulez partir. Il commence le jour où vous choisissez un outil sans penser à la porte de sortie.
Qu'est-ce que le vendor lock-in ?
Le vendor lock-in (ou « dépendance fournisseur ») désigne la situation dans laquelle une organisation devient excessivement dépendante d'un prestataire technologique, au point que changer de solution devient difficile, coûteux ou risqué. Cette dépendance peut toucher n'importe quelle couche de votre système d'information : votre CRM, votre plateforme cloud, vos outils no-code, votre base de données, ou même votre outil de gestion de projet.
Le problème n'est pas d'utiliser un seul outil. Le problème, c'est de ne plus pouvoir s'en passer sans considérer ça comme une catastrophe opérationnelle.
Les 4 types de dépendance technologique
1. La dépendance aux données. Vos données sont stockées dans un format propriétaire, difficile à exporter. Ou l'export existe sur le papier, mais les données exportées sont si peu structurées qu'elles sont inutilisables ailleurs sans un travail considérable. Exemples fréquents : CRM qui limitent l'export aux abonnements premium, outils de gestion de projet qui exportent uniquement en CSV sans hiérarchie, bases de données sans connecteurs standards.
2. La dépendance à l'API et aux intégrations. Vous avez construit votre système en intégrant plusieurs outils autour d'une plateforme centrale. Si cette plateforme change ses APIs, limite ses webhooks ou fait évoluer ses tarifs, toute la chaîne est impactée. Plus vous avez connecté d'outils à une solution centrale, plus le coût de migration est élevé.
3. La dépendance contractuelle et financière. Contrats pluriannuels avec pénalités de résiliation, prix qui escaladent à chaque renouvellement une fois le système bien ancré, fonctionnalités clés disponibles uniquement sur les plans les plus élevés. Cette forme de lock-in est la plus facile à anticiper — et pourtant la plus souvent négligée lors du choix initial.
4. La dépendance aux compétences internes. Vos équipes ont appris à travailler exclusivement avec un outil. Changer impliquerait formation, adaptation et résistance au changement. Ce type de lock-in est le plus insidieux car il n'est pas visible dans les tableaux de bord financiers.
Le coût réel du vendor lock-in n'est pas juste ce que vous payez aujourd'hui. C'est le coût d'opportunité de ne pas pouvoir changer quand une meilleure option existe.
Les signaux d'alerte à surveiller
Voici les indicateurs qui doivent vous alerter sur une situation de dépendance excessive : une augmentation de prix annuelle systématique (le fournisseur sait que partir vous coûterait plus cher qu'accepter la hausse), un export de données limité ou payant (vos propres données vous sont « vendues » pour pouvoir partir), des intégrations exclusives qui ne fonctionnent qu'avec l'écosystème du même éditeur, une formation certifiante propriétaire qui enferme vos équipes sur une technologie spécifique, une roadmap opaque sur laquelle vous n'avez aucune influence, et l'absence de format standard (JSON, CSV, XML) pour exporter l'intégralité de votre base.
Cas concret documenté : Basecamp et la sortie du cloud
En 2022, David Heinemeier Hansson (DHH), co-fondateur de Basecamp, a publié une série d'articles détaillés sur leur décision de quitter AWS et le cloud public. Le constat : Basecamp dépensait plus de 3 millions de dollars par an en infrastructure cloud. En migrant vers leur propre infrastructure physique, l'entreprise estimait économiser plus de 7,2 millions de dollars sur cinq ans.
Ce cas est intéressant parce que Basecamp n'est pas une société en difficulté. C'est une PME tech profitable qui a simplement fait le calcul et réalisé que sa dépendance au cloud n'était plus justifiée économiquement.
Ce que ce cas enseigne : même des entreprises tech matures se retrouvent en lock-in progressif. Calculer le TCO sur 3 à 5 ans change radicalement la décision initiale. La sortie est possible — mais elle nécessite planification et temps.
Le contexte européen : un enjeu stratégique, pas seulement technique
En Europe, la question du vendor lock-in prend une dimension supplémentaire. La dépendance aux plateformes américaines (AWS, Google Cloud, Microsoft Azure, Salesforce, Airtable, Notion…) n'est pas seulement un risque de coût — c'est un risque de souveraineté.
Le Data Act européen (applicable depuis septembre 2025) impose progressivement aux fournisseurs de garantir la portabilité des données. C'est une avancée législative majeure — mais elle ne suffit pas à garantir une migration simple dans la pratique.
En juillet 2025, la Commission européenne a publié une feuille de route pour faire du logiciel libre un pilier de sa souveraineté numérique, avec 70 mesures concrètes : priorité à l'open source dans les achats publics, création d'un fonds de souveraineté technologique, et standards d'interopérabilité ouverts.
Le rapport Draghi (2024) sur la compétitivité européenne souligne l'urgence pour l'Europe de reprendre le contrôle de sa souveraineté numérique en adoptant massivement des solutions open source. Ce n'est plus un débat idéologique — c'est une recommandation stratégique au plus haut niveau.
5 stratégies concrètes pour éviter le lock-in
1. Privilégier les standards ouverts dès le départ. Choisissez des outils qui utilisent des formats de données standards (JSON, CSV, SQL, REST API) plutôt que des formats propriétaires. Vérifiez avant de souscrire que vous pouvez exporter l'intégralité de vos données librement, à tout moment, sans surcoût. Le Data Act européen renforce ce droit — mais vaut mieux ne pas avoir à l'invoquer.
2. Séparer la logique métier des outils. Ne codez pas votre logique métier directement dans les automatisations d'un outil spécifique. Si votre workflow Make embarque 80 % de votre logique métier, vous créez une dépendance forte à Make. Bonne pratique : décrire les workflows dans un document indépendant (Notion, Markdown) avant de les implémenter. Si l'outil change, le blueprint existe et peut être réimplémenté ailleurs.
3. Tester régulièrement la portabilité. Faites une simulation de migration tous les 12 à 18 mois. Posez-vous la question : si ce fournisseur disparaissait demain, combien de temps nous faudrait-il pour être opérationnels sur une solution alternative ? Si la réponse est « plusieurs mois », vous êtes déjà en situation de dépendance critique.
4. Négocier les clauses de portabilité. Sur les solutions entreprise, négociez : droit à l'export complet à tout moment, délai raisonnable d'accès aux données en cas de résiliation, format standardisé (JSON, SQL dump, CSV structuré), absence de pénalité de résiliation après la période minimale.
5. Préférer l'open source pour les couches critiques. C'est la stratégie la plus durable. Voir la section suivante.
Alternatives open source européennes : par catégorie
Voici les alternatives concrètes que je recommande et utilise dans mes missions, classées par usage :
Automatisation de workflows. n8n (open source, auto-hébergeable, licence MIT) plutôt que Zapier ou Make pour les workflows critiques. Vos automatisations restent sur votre infrastructure. La migration depuis Make est réaliste — les blueprints sont exportables en JSON.
Base de données collaborative. Baserow (néerlandais, open source, conforme RGPD) plutôt qu'Airtable pour les données sensibles. Auto-hébergeable chez OVHcloud ou Scaleway. Économie : jusqu'à 1 800 € par an pour une équipe de 10 par rapport au plan Team d'Airtable.
IA générative. Mistral AI (français, modèles open-weight) plutôt que GPT-4 pour les usages en environnement réglementé. Exécutable sur votre propre infrastructure, auditable, sans dépendance à OpenAI.
Analytics. Plausible (européen, open source) ou Matomo (français, auto-hébergeable) plutôt que Google Analytics. Conformité RGPD native, aucun transfert de données hors UE.
Stockage et collaboration. Nextcloud (allemand, open source) plutôt que Google Drive ou OneDrive pour les données sensibles. Hébergeable chez un prestataire français, certifié SecNumCloud disponible.
L'open source ne signifie pas « gratuit » ni « plus compliqué ». Il signifie « vous pouvez en sortir sans permission ».
Outils no-code : ce qu'il faut vérifier avant d'adopter
Le marché no-code est particulièrement exposé au risque de lock-in. Les plateformes sont conçues pour être faciles d'entrée — la sortie est rarement aussi simple. Avant d'adopter un outil no-code, vérifiez : l'export des données (toutes vos tables, relations et fichiers sont-ils exportables en format standard ?), l'API ouverte (accès REST indépendamment de l'interface ?), les webhooks sortants (connexion à d'autres systèmes sans connecteur propriétaire ?), et la santé financière de l'éditeur (quelle exposition si le service ferme ou pivote ?).
Mon évaluation rapide des outils que j'utilise régulièrement : Airtable offre un export CSV et une API REST bien documentée — dépendance modérée. Glide stocke les données dans Google Sheets ou Airtable — portabilité structurellement intégrée. Webflow permet l'export CMS en CSV et le code front-end est exportable. Make exporte les blueprints en JSON — migration vers n8n réaliste. Notion exporte en Markdown et HTML — migration manuelle sur les bases complexes.
Ce que ça change concrètement dans votre organisation
Adopter une posture anti-lock-in ne signifie pas refuser tous les outils propriétaires. Cela signifie prendre des décisions informées et documenter les risques acceptés consciemment.
En pratique : ajoutez une colonne « portabilité » dans vos grilles de comparaison d'outils, documentez pour chaque outil critique comment en sortir et combien ça coûterait, calculez le TCO sur 3 ans avant de signer (pas juste le prix mensuel affiché), automatisez des exports réguliers de vos données critiques vers un stockage que vous contrôlez, et formez les équipes sur des compétences génériques plutôt que sur des outils spécifiques.
Une organisation qui peut changer d'outil en 3 semaines est plus résiliente qu'une organisation qui a les meilleurs outils du marché mais ne peut pas en bouger. L'agilité technologique est un avantage compétitif.
Par où commencer ? L'audit de dépendance en une demi-journée
Si vous n'avez jamais évalué votre dépendance à vos outils actuels, commencez par un audit simple. Listez vos 10 outils les plus utilisés. Pour chacun : pouvez-vous exporter toutes vos données librement, en combien de temps, vers quel format ? Identifiez le ou les outils où la réponse vous inquiète. Documentez un plan de sortie, même sommaire, pour chacun d'eux.
Cet exercice prend généralement une demi-journée. Il peut vous éviter des semaines de blocage si un fournisseur change ses conditions, fait faillite ou décide de pivoter son produit.
Vous voulez construire une stack digitale portable et performante ?
Je conçois des architectures d'outils pour des PME, startups et équipes de production — en privilégiant systématiquement les standards ouverts, les alternatives européennes et les solutions auto-hébergeables quand les données sont sensibles.
Si vous souhaitez faire cet audit avec un regard extérieur, ou repenser votre stack pour réduire vos dépendances sans perdre en efficacité, c'est exactement le type de mission que j'accompagne.
→ Découvrir mes services de Product Building
→ Me contacter pour un audit de stack
Sources
DHH — We stand to save $7.2M from our cloud exit — Basecamp (2022)
DHH — We have left the cloud — Basecamp (2023)
Data Act européen — Commission européenne (2023, applicable 2025)
Stratégie numérique européenne — Décennie numérique 2030 — Commission européenne
n8n — Automatisation open source auto-hébergeable
Baserow — Alternative open source européenne à Airtable
Mistral AI — Modèles IA open-weight français
Plausible Analytics — Alternative européenne à Google Analytics
Matomo — Analytics open source auto-hébergeable
Nextcloud — Stockage et collaboration open source européen
.jpg)
