Vendor lock-in logiciel : comment éviter de dépendre de son prestataire

La réponse courte : le vendor lock-in ne se voit presque jamais avant de signer — il se découvre le jour où vous voulez partir. S'en protéger se joue entièrement dans les clauses du contrat initial, avant même le premier euro dépensé.

Ce qu'est concrètement le vendor lock-in

C'est la situation où changer de prestataire ou d'éditeur logiciel coûte si cher, ou est si techniquement compliqué, que vous restez captif même si vous n'êtes plus satisfait. Ça peut venir d'un format de données propriétaire impossible à exporter, d'un code que vous ne possédez pas, ou d'une architecture si spécifique que seul le prestataire d'origine sait la maintenir.

Les signaux à repérer avant de signer

• Le contrat ne mentionne aucune cession de propriété du code
• Vos données sont stockées dans un format propriétaire, sans export standard prévu
• Aucune documentation technique n'est prévue à la livraison
• Le prestataire n'évoque jamais la question de la réversibilité de son propre chef

Comment s'en protéger concrètement

Faire préciser la propriété du code par écrit, avec le moment exact où elle devient effective — voir notre article sur à qui appartient le code d'un logiciel sur mesure.

Demander une copie exploitable du code, pas seulement une clause de propriété sur le papier — un accès réel, techniquement récupérable.

Vérifier que vos données peuvent être exportées dans un format standard, indépendamment du logiciel lui-même.

S'assurer qu'une documentation technique minimale existe, pour qu'un autre prestataire puisse reprendre le projet sans repartir de zéro.

Le scénario type, pour comprendre comment ça arrive

Une entreprise signe avec un prestataire, satisfaite du prix et des délais. Deux ans plus tard, le prestataire augmente ses tarifs de maintenance, ou change d'organisation, ou devient injoignable. L'entreprise cherche alors une alternative — et découvre à ce moment précis, pas avant, qu'aucune clause de propriété n'a jamais été signée, que le code n'a jamais été transmis, ou que la documentation technique n'existe nulle part. Reconstruire l'équivalent ailleurs coûte alors presque aussi cher que le projet initial, avec en plus le temps perdu pendant la recherche d'une solution. Ce scénario n'est presque jamais dû à une mauvaise foi du prestataire d'origine — c'est simplement qu'aucune des deux parties n'avait anticipé la question au moment de signer.

Le lien avec la propriété du code

La propriété du code est la protection la plus solide contre le vendor lock-in — un logiciel dont vous êtes propriétaire peut toujours être repris ailleurs, même si la relation avec votre prestataire d'origine s'arrête. C'est pour ça que ce point mérite d'être vérifié avant de signer, pas découvert après. Voir aussi notre liste de questions à poser avant de signer un devis.