Vendor lock-in : la peur qui vous coûte plus cher que la dépendance elle-même

Un CTO m’expliquait récemment qu’il avait passé trois semaines à construire une couche d’abstraction maison pour ne pas « dépendre » de son fournisseur de base de données. Sa startup avait onze clients. Onze. Pendant ce temps, deux concurrents avaient shippé la fonctionnalité qui, elle, faisait signer des contrats.

C’est le paradoxe du vendor lock-in : la peur d’être piégé plus tard pousse à prendre, tout de suite, la décision la plus coûteuse — celle de ralentir.

Le lock-in n’est pas un problème technique, c’est un arbitrage de risque

On parle de vendor lock-in comme d’une maladie à éviter à tout prix. Mais la dépendance à un fournisseur — un cloud, une base managée, un service d’authentification, un provider de paiement — n’est ni bonne ni mauvaise dans l’absolu. C’est un échange : vous cédez de la portabilité future contre de la vitesse immédiate.

Et la vitesse, pour une startup early-stage, c’est la variable qui décide de tout. Le vrai risque à pre-seed ou seed n’est pas de payer un jour un coût de migration. C’est de ne jamais atteindre le stade où cette migration devient un problème, parce que vous avez brûlé votre runway à construire des abstractions que personne ne vous a demandées.

Le pattern est reconnaissable : le fondateur tech qui « architecture pour l’échelle » avant d’avoir validé son ICP. Il abstrait sa base de données derrière une interface générique, il évite les fonctionnalités propriétaires de son cloud, il refuse un service managé « pour ne pas être coincé ». Résultat : il paie le coût du lock-in — la complexité, la lenteur — sans jamais en toucher les bénéfices — la vélocité qu’offrent justement ces services.

Distinguer le lock-in qui fait mal du lock-in qui ne fait rien

Tous les verrous ne se valent pas. La question utile n’est pas « suis-je dépendant ? » mais « combien coûterait le divorce, et quelle est la probabilité que j’aie à divorcer ? »

Ce qu’il est raisonnable de verrouiller

Le socle d’infrastructure managée — base de données, file d’attente, stockage objet, fonctions serverless — est généralement un bon endroit pour accepter la dépendance. Oui, une migration de PostgreSQL managé chez un provider vers un autre demande du travail. Mais ce travail est borné, documenté, et surtout : vous ne le ferez probablement jamais avant d’avoir une équipe et un budget pour le faire sereinement. Le gain de vélocité au quotidien écrase le coût hypothétique.

De même pour les briques qui ne sont pas votre différenciateur : authentification, envoi d’emails transactionnels, facturation. Reconstruire un système de paiement conforme et robuste pour « éviter Stripe » n’a de sens que si le paiement est votre produit. Sinon, vous payez une dette de développement énorme pour fuir une dépendance qui, dans les faits, vous sert très bien.

Ce qu’il faut isoler proprement

En revanche, certaines dépendances méritent une frontière claire — pas une abstraction complète, juste une isolation propre. Tout ce qui touche à votre logique métier, à vos données clients et à votre couche de sécurité doit rester sous votre contrôle conceptuel. Si un fournisseur d’IA hébergé traite vos requêtes, l’appel à ce fournisseur doit passer par un point unique dans votre code, pas être disséminé dans quarante fichiers. Ce n’est pas de la portabilité au sens strict — c’est de l’hygiène qui vous permettra, le jour venu, de changer de modèle sans réécrire votre produit.

La nuance est importante : isoler un point d’entrée prend une heure. Construire une couche d’abstraction agnostique qui supporte trois fournisseurs interchangeables prend des semaines et vous n’en utiliserez qu’un. La première est de la prudence, la seconde de la sur-ingénierie.

Le calcul change à chaque stade

À pre-seed, la seule question qui compte est : est-ce que ce choix me permet de tester mon hypothèse plus vite ? Prenez le service le plus intégré, le plus managé, celui qui vous fait gagner des jours. Le lock-in est le cadet de vos soucis quand la survie se joue sur la validation du problème.

À seed, avec les premiers clients payants, vous commencez à voir où sont vos points de douleur réels : ce fournisseur dont les coûts grimpent, cette dépendance qui bloque une fonctionnalité demandée par un gros prospect. C’est le moment d’isoler chirurgicalement ces points-là — pas tous, ceux qui saignent.

À l’approche de la série A, le calcul bascule. La dépendance devient un sujet de due diligence. Un investisseur, un client enterprise ou un audit de sécurité peuvent légitimement s’inquiéter d’une concentration de risque sur un seul fournisseur, surtout dans un contexte réglementaire européen — la question de la localisation des données et de la conformité RGPD rend certains verrous plus sensibles que d’autres. Là, la portabilité devient un actif business, pas une lubie d’ingénieur. Mais vous l’aborderez avec une équipe, un budget, et une connaissance réelle de vos contraintes — pas en spéculant à l’aveugle deux ans plus tôt.

Le vrai coût du lock-in est rarement là où on le regarde

On imagine le vendor lock-in comme un mur : un jour, on veut partir, et on ne peut pas. Dans la réalité des startups, le coût est plus insidieux et se manifeste bien avant.

Le premier coût, c’est le pricing captif. Un fournisseur qui sait que vous ne pouvez pas facilement partir n’a aucune raison de rester compétitif. C’est particulièrement vrai sur les facturations à l’usage qui explosent avec la croissance — la facture cloud qui grossit plus vite que le revenu est souvent un problème de lock-in autant que d’architecture.

Le deuxième, c’est le plafond de fonctionnalités. Votre fournisseur ne supporte pas ce dont votre plus gros client a besoin ? Vous êtes bloqué à son rythme de roadmap, pas au vôtre.

Le troisième, plus rare mais fatal, c’est le risque d’existence : le fournisseur qui ferme, se fait racheter et déprécie son offre, ou change ses conditions du jour au lendemain. C’est le seul scénario qui justifie vraiment une stratégie de portabilité anticipée — et uniquement pour les composants dont dépend la survie de votre produit.

Ce qu’il faut vraiment faire

Arrêtez de traiter le lock-in comme un ennemi binaire. Faites-en une décision explicite, composant par composant. Pour chaque dépendance importante, posez trois questions : quel est le coût de sortie estimé, quelle est la probabilité que je doive sortir dans les douze prochains mois, et ce composant est-il mon avantage concurrentiel ?

Si le coût de sortie est faible ou la probabilité de sortie quasi nulle, adoptez la solution la plus intégrée sans hésiter. Si le composant est votre différenciateur, gardez-en le contrôle — mais parce que c’est votre valeur, pas par crainte du lock-in. Et pour tout le reste, contentez-vous d’isoler proprement les points d’intégration, sans construire d’abstraction spéculative.

Surtout, datez vos décisions. Notez pourquoi vous avez choisi tel fournisseur et à quel signal vous reconsidérerez. « On reste sur ce provider tant qu’on est sous cinquante mille euros de facturation annuelle » est une décision saine. « On évite ce provider au cas où » n’en est pas une.

La portabilité parfaite est un luxe d’entreprise mature. La vitesse d’exécution est une condition de survie de startup. Entre les deux, il n’y a pas de bonne réponse universelle — il y a le stade où vous êtes, et le risque que vous pouvez réellement vous permettre d’ignorer.

Quelle dépendance, dans votre stack actuelle, vous fait le plus peur — et depuis combien de temps repoussez-vous le calcul de ce qu’elle vous coûterait vraiment de quitter ?