Vendor lock-in : ce que ça coûte et quand l’accepter

Le vendor lock-in n’est pas un défaut à éviter. Chaque outil que vous adoptez vous vend de la vitesse aujourd’hui contre de l’optionalité demain, et le travail consiste à chiffrer cet échange avant de signer.

Un fondateur de la logistique avec qui nous avons travaillé avait construit tout le portail d’opérations de son entreprise sur une plateforme no-code. Six semaines de travail, et ça a très bien fait tourner la boîte pendant deux ans. Puis son plus gros prospect a inscrit le single sign-on et un journal d’audit exportable dans le contrat, comme conditions de signature. La plateforme ne savait faire ni l’un ni l’autre. La reconstruction a pris cinq mois, et le client n’a pas attendu.

Le vendor lock-in, c’est le fait de dépendre d’un fournisseur au point que partir coûte plus cher que rester, même quand rester est la mauvaise décision. Ce n’est pas un défaut caché dans les mauvais outils. C’est le sous-produit naturel de tout outil qui fait un vrai travail à votre place, et il s’accumule à quatre endroits : votre code, vos données, vos processus et vos gens.

Ce fondateur ne s’est pas retrouvé prisonnier parce qu’il avait pris une mauvaise décision. Il s’est retrouvé prisonnier parce qu’il avait pris une bonne décision et n’était jamais revenu en vérifier le prix.

Ce que le vendor lock-in signifie vraiment

La définition de manuel parle de coûts de migration : formats propriétaires, API incompatibles, pénalités contractuelles, la dépense que représente le passage d’un fournisseur à un autre. Cette définition est exacte et à peu près inutile, car elle décrit une condition qui s’applique littéralement à chaque outil que vous adopterez un jour.

La distinction utile est ailleurs.

Vous n’êtes pas prisonnier quand partir coûte cher. Vous êtes prisonnier quand partir coûte assez cher pour que vous cessiez d’y penser.

C’est cette ligne qui compte. Un coût de migration, c’est un chiffre. Le lock-in, c’est ce qui arrive quand le chiffre devient assez gros pour se mettre à décider à votre place : quand vous arrêtez d’évaluer les alternatives, quand vous contournez une fonctionnalité manquante au lieu de l’exiger, quand vous dites non à un client parce que votre plateforme a dit non la première. Le fondateur logistique n’a pas décidé de perdre ce contrat. Sa stack a décidé pour lui, deux ans plus tôt, un mardi, alors que personne ne regardait.

Les quatre verrous

On parle du lock-in comme s’il n’y en avait qu’un. Il y en a quatre, et leurs prix sont très différents.

Verrou de code. Vous ne pouvez pas emporter le logiciel, parce qu’il n’y a pas de logiciel à emporter. Les plateformes no-code sont le cas le plus pur : aucun artefact, aucun dépôt, rien qui tourne où que ce soit en dehors de l’éditeur du fournisseur. Les langages propriétaires sont le même piège en costume. Dès l’instant où votre logique vit dans un dialecte qu’une seule entreprise compile, cette logique lui appartient.

Verrou de données. Toutes les plateformes du monde exportent vos données. Presque aucune n’exporte leur forme. Vous récupérez un CSV de clients, et vous perdez les relations entre eux, le modèle de permissions, la machine à états que traversent les commandes, les identifiants que trois autres systèmes référencent. Les lignes survivent. Le sens, non.

Verrou de processus. C’est celui que personne ne chiffre, et c’est souvent le plus cher. En deux ans, votre équipe remodèle silencieusement l’entreprise pour la faire entrer dans les hypothèses de l’outil. Quelqu’un invente une étape manuelle parce que la plateforme n’en sait pas faire une vraie. L’étape devient une habitude, l’habitude devient un processus, et le processus devient la façon dont l’entreprise fonctionne. Vous ne migrez plus un logiciel. Vous migrez une organisation.

Verrou humain. Les seules personnes capables de maintenir la chose sont certifiées dans l’écosystème du fournisseur, ce qui veut dire que vous recrutez sur un marché du travail que le fournisseur contrôle, à un prix qu’il influence. Quand votre unique développeur certifié s’en va, vous n’allez pas sur le marché. Vous allez dans l’annuaire de partenaires du fournisseur.

Le verrou de code est le plus bruyant et le plus simple à régler. Les verrous de processus et humain sont silencieux, produisent des intérêts chaque jour, et ce sont eux qui emprisonnent réellement les entreprises.

Le lock-in est un prix, pas un défaut

Voici ce que le reste d’internet rate.

Chaque abstraction que vous adoptez vous enferme. Postgres vous enferme. React vous enferme. Votre logiciel de comptabilité, votre prestataire de paie, le langage dans lequel votre produit est écrit, le cloud sur lequel tournent vos serveurs. La seule façon de n’avoir aucune dépendance est de tout construire soi-même, ce qui est un autre piège, et un bien pire.

La question n’est donc jamais « suis-je enfermé ». Vous l’êtes. La question, c’est ce que vous avez payé, et si ce que vous avez acheté le vaut.

Joel Spolsky a tracé la ligne il y a vingt-cinq ans dans In Defense of Not-Invented-Here Syndrome, et elle n’a pas bougé depuis :

Si c’est une fonction centrale du métier — faites-le vous-même, quoi qu’il en coûte.

C’est tout le cadre, et il se convertit proprement en une règle sur les dépendances. Le lock-in sur une fonction qui ne rapporte pas d’argent est bon marché, et vous devriez l’accueillir volontiers. Vous n’avez aucune envie de posséder votre logiciel de paie. Enfermez-vous et dormez tranquille. Le lock-in sur le système dont dépend votre marge est existentiel, et aucune remise n’est assez grosse pour le justifier. Si votre moteur de tarification, votre algorithme d’appariement ou votre logique d’octroi vit à l’intérieur du produit d’une autre entreprise, vous ne dirigez pas une entreprise. Vous dirigez une franchise.

La plupart des fondateurs font l’inverse. Ils agonisent sur le choix d’un CRM, une décision réversible en trois semaines, puis laissent tranquillement ce qui les différencie se construire dans une plateforme dont ils ne sortiront jamais. La décision entre build et buy n’est pas une question de coût. C’est une question de savoir de quel côté de cette ligne le système se situe.

Le test du coût de sortie

Avant d’adopter quoi que ce soit qui touchera à un processus central, nous posons quatre questions. Cela prend vingt minutes et c’est l’assurance la moins chère qui existe en logiciel.

1. Si nous partons dans dix-huit mois, qu’est-ce qui part physiquement avec nous ?

Nommez les artefacts à voix haute : code source, schéma de base de données, données, documentation, nom de domaine, fichier clients, intégrations. Écrivez la liste. Si la réponse honnête est « un export CSV », vous n’êtes pas un client. Vous êtes un locataire.

2. Combien de semaines, et non combien d’euros ?

Chiffrez la sortie en semaines d’ingénierie et en perturbation de l’activité, jamais en frais de licence. L’argent se récupère. Une reconstruction de cinq mois qui tombe au milieu d’une levée, non. Le coût de sortie du fondateur logistique n’était pas un montant sur une facture. C’était un trimestre et un logo de poids.

3. Notre roadmap a-t-elle besoin de l’autorisation de la leur ?

C’est la plus tranchante des quatre. Si vous ne pouvez pas livrer une fonctionnalité qui vous différencie tant que le fournisseur n’a pas décidé de la construire, vous n’avez pas acheté un outil. Vous avez sous-traité votre stratégie produit à une entreprise qui n’a jamais parlé à vos clients et se moque de savoir si vous gagnez.

4. Qui d’autre peut maintenir ça ?

Si la réponse est « les partenaires certifiés du fournisseur », vous avez un problème d’offre déguisé en choix technique. Si la réponse est « n’importe quel ingénieur compétent qui connaît ce langage », tout va bien.

Notez les quatre honnêtement. Un outil qui échoue aux questions 1 et 3 est excellent pour valider et dangereux comme architecture. Ce n’est pas une contradiction. C’est un calendrier.

Là où les fondateurs se font vraiment enfermer

Cherchez « vendor lock-in » et vous trouverez dix articles sur les frais de sortie d’AWS et la stratégie multicloud. Utiles, si vous avez une DSI. Ce n’est pas là que ça mord un fondateur. C’est ici.

La plateforme no-code que vous avez dépassée. Elle vous a donné un produit qui tourne en six semaines, et c’était le bon choix. Elle ne sait pas faire de SSO, ni de journal d’audit, ni un vrai modèle de permissions, ni l’unique processus que votre client grand compte exige. La plupart des fondateurs restent sur le no-code six à douze mois de trop, et ce retard n’est pas un échec technologique. C’est l’échec de n’avoir jamais relu l’étiquette de prix une fois l’entreprise changée.

La software house qui détient votre dépôt. Celui-là tue des entreprises, et il se découvre presque toujours au pire moment. Si votre contrat de développement logiciel ne dit pas que le code vous appartient, dans un dépôt que vous contrôlez, dès le premier jour, alors vous n’avez pas un partenaire technologique. Vous avez un propriétaire qui vous loue votre propre logiciel. Le source code escrow existe précisément parce que cela arrive assez souvent pour avoir engendré son propre instrument juridique.

Le modèle de données tordu autour d’un seul fournisseur. Quelqu’un a utilisé les identifiants d’un prestataire de paiement comme clés primaires. Quelqu’un a stocké l’état d’une commande dans un champ que seul ce prestataire écrit. Deux ans plus tard, changer de prestataire signifie réécrire le système de commandes, et le système de commandes, c’est l’entreprise.

L’outil interne que personne n’a documenté. Un prestataire l’a construit, un prestataire le comprenait, et ce prestataire est parti. Vous n’êtes plus enfermé chez un fournisseur. Vous êtes enfermé dans un système legacy dont l’effectif est de zéro.

Quand le lock-in est le bon échange

Souvent. Plus souvent que ne le suggèrent les articles alarmistes.

Quand vous êtes encore en validation. Si l’entreprise n’existe peut-être plus dans un an, l’optionalité est un produit de luxe que vous ne pouvez pas vous offrir. Enfermez-vous franchement, livrez en six semaines, et découvrez si quelqu’un en veut. Une optionalité que vous n’exercez jamais, c’est de l’argent brûlé.

Quand la fonction n’est pas centrale. La paie, la messagerie, la comptabilité, le CRM de votre équipe commerciale de six personnes. Prenez le leader du marché, enfermez-vous, et n’y repensez plus jamais. La charge mentale de rester portable sur une commodité est elle-même un coût.

Quand la sortie est réellement réversible. Si vous pouvez partir en moins de quatre semaines, ce n’est pas du lock-in. C’est un coût de migration, et les coûts de migration sont normaux.

D’où la règle empirique que nous utilisons, et la seule phrase de cet article qui mérite d’être écrite au tableau :

Acceptez le lock-in en proportion inverse de la proximité entre le système et votre marge.

Plus un système est loin de l’argent, plus vous devriez accepter le lock-in de bon cœur. Plus il s’en approche, plus vous devriez en être propriétaire. Presque toutes les erreurs coûteuses qu’on nous appelle à réparer sont une violation de cette seule ligne.

Comment éviter le vendor lock-in sans devenir paranoïaque

L’échec inverse existe, et il est plus fréquent chez les équipes techniques que chez les fondateurs : construire des couches d’abstraction « au cas où », écrire son propre wrapper autour de chaque service, refuser l’infrastructure managée parce qu’un jour, peut-être, on bougera. C’est une taxe de portabilité, et vous la payez tous les jours pour une migration qui n’aura probablement jamais lieu. Le coût de la portabilité prématurée, c’est un loyer. Le coût d’une migration, c’est un crédit. Le loyer est pire.

La version proportionnée tient en peu de mots.

Possédez le dépôt, dès le premier jour, sur un compte que vous contrôlez. Possédez votre modèle de données, et comprenez-le assez bien pour le décrire en une phrase. Possédez le nom de domaine et le DNS. Exportez vos données tous les mois et, au moins une fois, restaurez réellement cet export ailleurs. Un export que vous n’avez jamais restauré n’est pas une sauvegarde. C’est une croyance.

Puis mettez-le dans le contrat : propriété du code dès le premier jour, clause de portabilité des données, et documentation comme livrable nommé, pas comme faveur.

Les régulateurs ont commencé à traiter les coûts de migration comme un problème de concurrence plutôt que comme un désagrément technique. Le Data Act européen, applicable depuis septembre 2025, pose un cadre qui oblige les fournisseurs de services de traitement de données à laisser leurs clients changer de prestataire, et interdit les clauses contractuelles qui bloquent le partage des données. La direction est claire : le droit de partir devient quelque chose qui vous est dû, et non quelque chose qui se négocie. C’est une bonne nouvelle, et elle arrivera bien trop tard pour vous aider avec le fournisseur que vous choisissez ce trimestre.

Questions fréquentes

Qu’est-ce que le vendor lock-in, en termes simples ?

Dépendre d’un seul fournisseur au point que changer coûterait plus cher que rester, même quand rester vous fait du mal. Le coût peut tenir au code que vous ne pouvez pas emporter, aux données que vous ne pouvez pas exporter utilement, aux processus bâtis autour des limites de l’outil, ou au personnel qui ne connaît que l’écosystème de ce fournisseur.

Quel est un exemple de vendor lock-in ?

Une startup construit son portail d’opérations sur une plateforme no-code. Deux ans plus tard, un client grand compte exige le single sign-on et un journal d’audit. La plateforme ne fournit ni l’un ni l’autre, il n’y a pas de code source à modifier, et la seule voie possible est une reconstruction de cinq mois. Le coût de migration était invisible le premier jour et décisif le sept-centième.

Comment éviter le vendor lock-in ?

On ne l’évite pas. On le chiffre. Avant d’adopter un outil, demandez ce qui part physiquement avec vous si vous partez, combien de semaines prendrait la sortie, si votre roadmap dépend de celle du fournisseur, et qui, en dehors de ses partenaires, peut maintenir l’outil. Ensuite, possédez le dépôt, le modèle de données et le nom de domaine, et testez vos exports.

Le vendor lock-in est-il toujours une mauvaise chose ?

Non. Le lock-in sur une fonction devenue commodité est un bon échange, et souvent une affaire. Le lock-in sur le système qui produit votre marge est une erreur stratégique. La distance entre le système et votre chiffre d’affaires détermine lequel des deux vous avez sous les yeux.

Le fondateur logistique a reconstruit son portail. Cinq mois, et il a perdu le client. Quand nous lui avons demandé ce qu’il ferait différemment, il n’a pas dit qu’il aurait évité la plateforme no-code. Il a dit qu’il aurait écrit noir sur blanc, le jour où il l’a adoptée, ce que ça coûterait d’en partir.

Il n’a jamais écrit ce chiffre, alors il a grandi en silence pendant deux ans, et il ne l’a appris que le seul jour où il ne pouvait pas être payé.

Le lock-in n’a jamais été le problème. Ne pas en connaître le prix, si.