À retenir en 30 secondes Voir Masquer
Cet article s'adresse aux dirigeants de PME qui évaluent une décision produit. En résumé :
- Un logiciel qui vous piège coûte 3 à 6 mois de migration. Checklist en 7 axes : contrat, code source, données, infra, licences et réversibilité.
- Durée moyenne de lecture : 9 minutes.
- Écrit par Maxence Alehausse — IA & Ingénierie, basé sur notre expérience terrain.
Le vendor lock-in désigne la dépendance excessive à un fournisseur logiciel, au point que changer devient prohibitif. Pour l'éviter, vérifiez six axes avant de signer : le contrat (clause de réversibilité, propriété intellectuelle), le code source, les données (format ouvert, export), l'infrastructure, la documentation et les licences. Une procédure de réversibilité testée annuellement complète la démarche.
Un client nous a appelés l’an dernier avec un problème simple à énoncer, cauchemardesque à résoudre : son CRM métier avait doublé de tarif au renouvellement, l’éditeur venait d’être racheté, et l’export de ses données livrait un fichier illisible sans le logiciel lui-même. Résultat du piège : quatre mois de migration et un devis à cinq chiffres pour récupérer des données qui lui appartenaient déjà.
C’est ça, le vendor lock-in. Pas un concept théorique de DSI, mais une facture qui tombe au pire moment. Ce guide vous donne une checklist en 7 axes pour garder la main sur votre logiciel métier — avant la signature, pendant le contrat, et le jour où vous voudrez partir.
Pourquoi le vendor lock-in coûte cher en 2026
Le mécanisme est toujours le même. Vous choisissez une solution pour de bonnes raisons. Puis, deux ans plus tard, les coûts de changement — migration, recodage, formation, perte d’historique — deviennent tellement élevés que rester coûte moins cher que partir. Le fournisseur le sait. C’est même souvent son modèle économique.
La dépendance peut toucher plusieurs couches à la fois : le logiciel lui-même, le cloud qui l’héberge, les formats de données, les API, et jusqu’aux compétences internes de vos équipes qui ne connaissent plus que cet outil.
Les conséquences pour une PME se chiffrent sur trois plans :
- Financier : hausses tarifaires imposées au renouvellement (+30 à +100 % vus sur le terrain), abonnements qui s’empilent, frais de sortie gonflés.
- Opérationnel : dépendance à un fournisseur unique, aucune marge de manœuvre en cas d’incident, de bug non corrigé ou de faillite de l’éditeur.
- Stratégique : impossibilité d’intégrer un nouvel outil, retards d’innovation, décisions dictées par la roadmap du prestataire plutôt que par votre métier.
Notre avis tranché de praticiens : le lock-in n’est jamais un accident. Il s’installe phrase par phrase dans des contrats signés trop vite. Chaque point de cette checklist est négociable — mais seulement avant de signer. Après, vous négociez en position de faiblesse.
Axe 1 — Le contrat : les clauses à négocier avant de signer
C’est le premier rempart, et le plus souvent bâclé. Un contrat mal rédigé est la porte d’entrée du lock-in.
La clause de réversibilité est la plus déterminante et la plus négligée. Elle doit organiser contractuellement la sortie : restitution des données dans des formats exploitables, durée d’accompagnement du fournisseur, suppression définitive en fin de contrat, conditions financières associées. Une clause réduite à « restitution des données sur demande » ne protège personne — c’est un chèque en bois juridique.
Depuis le 12 septembre 2025, le Data Act européen change la donne pour vos contrats SaaS : il interdit les clauses qui entravent le changement de fournisseur, impose des formats d’export ouverts et une documentation des API, et plafonne les frais de transfert de données. Concrètement, un éditeur qui vous facture 8 000 € pour « préparer un export » est désormais hors-la-loi. Utilisez-le comme levier de négociation, même sur les contrats en renouvellement.
La clause de propriété intellectuelle doit préciser à qui appartient le code des développements spécifiques réalisés pour vous. Sans cession explicite, le prestataire conserve ses droits — même si vous avez tout financé.
| Clause à vérifier | Ce que vous devez obtenir |
|---|---|
| Réversibilité | Format ouvert (JSON, CSV, SQL), délai ≤ 30 j, assistance technique, coût encadré |
| Propriété intellectuelle | Cession des droits sur les développements spécifiques |
| Portabilité des données | Export complet à tout moment, sans frais abusifs |
| Résiliation | Préavis raisonnable (≤ 3 mois), sans pénalité disproportionnée |
| SLA & continuité | Engagement de disponibilité chiffré, procédure en cas d’arrêt du service |
| Sous-traitance | Liste des sous-traitants, localisation des données (UE/hors UE) |
Le piège classique : signer un contrat cadre alléchant, sans lire l’annexe qui renvoie les frais de sortie à un « devis sur mesure ». Faites relire toute clause chiffrée à zéro par un juriste.
Axe 2 — Le code source : qui le possède vraiment ?
Dans un SaaS standard, vous n’êtes pas propriétaire du code applicatif. Vous achetez un droit d’usage, pas le logiciel. C’est légitime — à condition de le savoir en signant, et d’accepter que vous ne pourrez jamais le reprendre en main.
Dans un développement sur mesure, la situation devrait être différente. Mais attention : elle ne l’est pas automatiquement. Sans clause de cession explicite, le prestataire conserve la propriété du code qu’il a produit pour vous. Nous voyons régulièrement des entreprises persuadées de « posséder leur logiciel » découvrir qu’elles n’en possèdent que le droit d’usage.
Exigez concrètement :
- Une clause de cession de droits couvrant l’ensemble des développements spécifiques (code, scripts, configurations).
- Le dépôt du code source dans un espace que vous contrôlez : dépôt Git privé à votre nom, ou mécanisme d’escrow logiciel (un tiers de confiance conserve le code et vous le remet si le prestataire défaille).
- La documentation du code (commentaires, architecture, dépendances) livrée avec le reste.
Test simple : demandez à votre prestataire de vous donner accès au dépôt Git aujourd’hui. S’il hésite ou tergiverse, vous avez votre réponse sur qui contrôle réellement votre logiciel.
C’est l’approche que nous appliquons chez Step pour tous nos projets de logiciels métier sur-mesure : vous êtes propriétaire de votre code dès le premier livrable, sur votre propre dépôt.
Axe 3 — Les données : portabilité et formats ouverts
Vos données métier sont l’actif le plus précieux que vous confiez à un logiciel tiers. Et elles sont souvent stockées dans des formats propriétaires qui rendent toute migration laborieuse — parfois volontairement.
Ce que vous devez vérifier avant de déployer un outil :
- Les données sont-elles exportables à tout moment, en autonomie, sans intervention (ni facture) du fournisseur ?
- Les formats d’export sont-ils ouverts et exploitables par un tiers (CSV, JSON, SQL, XML) — et non un format propriétaire lisible uniquement par le logiciel d’origine ?
- L’API est-elle documentée et accessible sans surcoût ?
- Existe-t-il une procédure de purge certifiée de vos données en fin de contrat (essentiel pour la conformité RGPD) ?
Le test qui vaut tous les discours : demandez un export complet pendant la période d’essai, avant même de signer. Ouvrez le fichier. S’il est structuré, lisible et complet, bon signe. S’il faut le logiciel pour l’interpréter, vous savez déjà que la sortie sera douloureuse.
Une clause de réversibilité n’a de valeur que si les formats sont ouverts et testés régulièrement. Prévoyez un test annuel d’export réel — pas théorique.
Axe 4 — L’infrastructure : ne pas confondre hébergement et maîtrise
L’hébergement est le vecteur de lock-in le plus invisible. Vous utilisez une application fluide, sans réaliser que vos données vivent dans un environnement entièrement contrôlé par le fournisseur, sur une infrastructure impossible à répliquer ailleurs.
Les questions à poser à votre prestataire :
- Où sont physiquement hébergées mes données ? (Un datacenter en UE, ou un cloud américain soumis au Cloud Act ?)
- Puis-je migrer vers un hébergeur de mon choix si je veux reprendre le logiciel en main ?
- Les technologies d’infrastructure sont-elles standards (Linux, PostgreSQL, Docker, Kubernetes…) ou propriétaires et non reproductibles ?
- Existe-t-il une procédure documentée de déploiement autonome de l’application ?
Notre position : une application construite sur des briques standards peut être redéployée sur n’importe quel hébergeur en quelques jours. Une application qui dépend de services managés propriétaires spécifiques d’un cloud vous enferme, quel que soit le contrat. La souveraineté se joue autant dans les choix techniques que dans le juridique — un point particulièrement sensible pour les entreprises européennes qui traitent des données confidentielles.
Axe 5 — La documentation : le parent pauvre des projets logiciels
Un logiciel sans documentation est un logiciel que vous ne maîtrisez pas. Si votre prestataire disparaissait demain, sauriez-vous expliquer à un tiers comment fonctionne votre système, quelles sont ses dépendances, et comment le faire évoluer ? Dans 8 cas sur 10, la réponse est non.
Checklist documentation à exiger contractuellement :
- ☐ Architecture technique (schéma des composants, flux de données)
- ☐ Documentation des API (endpoints, formats de requêtes/réponses)
- ☐ Manuel d’administration (déploiement, mises à jour, sauvegardes)
- ☐ Guide utilisateur à jour
- ☐ Registre des dépendances (librairies tierces, versions)
- ☐ Procédure de reprise sur incident (PRA/PCA documenté)
La documentation doit être livrée avec le logiciel, mise à jour à chaque évolution majeure, et stockée dans un espace que vous contrôlez — pas seulement sur le wiki interne du prestataire. Astuce d’arbitrage : conditionnez le paiement du dernier jalon à la livraison d’une documentation complète. C’est le seul levier qui marche vraiment.
Axe 6 — Les licences : audit des dépendances tierces
Un logiciel sur-mesure n’est jamais écrit de zéro. Il intègre des librairies open source, des composants tiers, parfois des briques propriétaires. Chaque dépendance introduit un risque de licence.
Ce que vous devez surveiller :
- La liste des dépendances tierces et leur licence (MIT, Apache, GPL, propriétaire…).
- Les licences copyleft fortes (GPL, AGPL) : mal gérées, elles peuvent vous obliger à publier votre propre code. Rare, mais ça arrive.
- Les composants propriétaires intégrés, qui peuvent introduire des coûts cachés ou des restrictions d’usage à l’échelle.
- Les abonnements à des API tierces (cartographie, paiement, emailing, IA…) dont vous dépendez indirectement, et dont les tarifs peuvent exploser sans préavis.
Demandez un audit des licences à la recette du projet, puis à chaque mise à jour majeure. Un simple fichier listant chaque dépendance et sa licence suffit — mais il faut qu’il existe. C’est un point que nous intégrons systématiquement dans les projets menés par notre agence.
Axe 7 — La réversibilité : tester avant d’en avoir besoin
La réversibilité n’est pas un PDF rangé dans un tiroir. C’est une procédure vivante, à tester régulièrement — sinon vous découvrez qu’elle ne marche pas le jour où vous en avez besoin, c’est-à-dire au pire moment.
Procédure de réversibilité à formaliser dans le contrat :
- Déclenchement : conditions précises d’activation (résiliation, défaillance du prestataire, reprise en régie…)
- Périmètre : liste exhaustive des éléments à restituer (données, code source, documentation, configurations, paramétrage métier)
- Format et délai : formats d’export standardisés, délai maximal de restitution (30 jours max)
- Accompagnement : durée pendant laquelle le prestataire reste disponible pour vos questions techniques
- Test annuel : clause imposant un exercice de réversibilité simulé chaque année, avec compte rendu
- Purge certifiée : suppression et certificat de destruction des données après migration complète
Le point 5 — le test annuel — est presque toujours absent des contrats standard. C’est pourtant le seul moyen de savoir si votre clause de réversibilité est opérationnelle ou purement cosmétique. Chez nos clients, ce test prend une demi-journée par an. C’est la meilleure assurance que vous puissiez souscrire.
SaaS standard vs sur-mesure bien contractualisé
| Critère | SaaS standard | Sur-mesure mal contractualisé | Sur-mesure bien contractualisé |
|---|---|---|---|
| Propriété du code | ❌ Fournisseur | ⚠️ Flou | ✅ Client |
| Export des données | ⚠️ Souvent limité | ⚠️ Variable | ✅ Formats ouverts garantis |
| Choix de l’infrastructure | ❌ Imposé | ⚠️ Partiel | ✅ Libre |
| Documentation livrée | ⚠️ Partielle | ❌ Souvent absente | ✅ Contractuellement due |
| Réversibilité testée | ❌ Rarement | ❌ Non prévue | ✅ Clause + test annuel |
| Dépendance tarifaire | ❌ Forte | ⚠️ Moyenne | ✅ Faible |
| Conformité Data Act 2025 | ⚠️ À vérifier | ⚠️ À vérifier | ✅ Intégré dès la conception |
À lire entre les lignes : le sur-mesure n’est pas magique. Un sur-mesure mal contractualisé peut être pire qu’un bon SaaS — code flou, aucune doc, hébergement captif. La différence ne tient pas à la techno, mais au contrat et à qui contrôle quoi.
Auditez vos contrats actuels en 5 questions
Avant tout nouveau projet, regardez en face vos dépendances existantes. Pour chaque outil critique de votre SI, posez ces cinq questions :
- Qui est propriétaire du code et des données ?
- En combien de temps pourrais-je exporter toutes mes données dans un format exploitable ?
- Existe-t-il une clause de réversibilité opérationnelle dans le contrat ?
- La documentation permettrait-elle à un tiers de reprendre le projet ?
- Les licences tierces ont-elles été auditées ?
Si vous butez sur une seule de ces questions, vous avez une exposition au vendor lock-in que vous n’avez pas encore chiffrée. Notre article sur le calcul du ROI d’un projet IA applique une méthodologie proche pour évaluer le coût caché des dépendances technologiques.
Pour comparer les deux approches sur l’ensemble du cycle de vie, notre guide logiciel sur-mesure vs SaaS standard va plus loin.
Conclusion : la maîtrise de votre logiciel est une décision contractuelle
Le vendor lock-in ne surgit jamais du jour au lendemain. Il s’installe phrase par phrase dans des contrats signés trop vite, dans des formats de données choisis sans penser à la sortie, dans des infrastructures confiées sans procédure de reprise. La bonne nouvelle : chaque point de cette checklist est négociable — à condition de le faire avant de signer.
Notre conviction, en tant qu’équipe qui code (pas qui rédige du contenu) : votre autonomie numérique ne se décrète pas, elle se contractualise. Chez Step, nous construisons des logiciels métier sur-mesure avec des contrats clairs, des technologies ouvertes et des procédures de réversibilité testées.
Que vous soyez en train de choisir un logiciel, d’en faire développer un, ou d’auditer votre exposition actuelle, on peut poser les choses ensemble.
Échangeons 30 minutes pour analyser votre situation. Demandez un premier échange gratuit →
Questions fréquentes
Qu'est-ce que le vendor lock-in et pourquoi est-ce un risque pour une PME ?
Le vendor lock-in désigne la situation où votre entreprise devient tellement dépendante d'un fournisseur technologique que migrer vers une alternative devient coûteux, risqué ou pratiquement impossible. Pour une PME, cela se traduit concrètement par des hausses tarifaires imposées au renouvellement, un support dégradé sans recours, et une incapacité à faire évoluer votre système d'information librement.
Quelle clause juridique protège contre le vendor lock-in dans un contrat SaaS ?
La clause de réversibilité est la plus déterminante. Elle doit préciser le périmètre des données restituées, les formats d'export (ouverts : JSON, CSV, SQL), la durée d'accompagnement du fournisseur lors de la sortie, les conditions financières et la suppression définitive des données en fin de contrat. Depuis le 12 septembre 2025, le Data Act européen interdit les clauses qui entravent le changement de fournisseur et plafonne les frais de transfert.
À qui appartient le code source d'un logiciel développé sur mesure ?
Cela dépend du contrat. Sans clause explicite de cession de propriété intellectuelle, le prestataire conserve souvent les droits sur le code source. Il est indispensable de négocier, dès la commande, une cession complète des droits sur les développements spécifiques réalisés pour votre compte, et d'obtenir le dépôt du code dans un espace que vous contrôlez (escrow ou dépôt direct).
Comment tester concrètement la réversibilité d'un logiciel sans attendre la crise ?
Prévoyez un test de réversibilité annuel : exportez l'ensemble de vos données depuis l'environnement de production, vérifiez que le format est exploitable par un tiers, reconstituez un environnement de test avec ces données et documentez le temps et les ressources nécessaires. Ce test révèle les dépendances cachées bien avant une migration sous pression.
Le logiciel sur-mesure protège-t-il mieux du vendor lock-in qu'un SaaS standard ?
Oui, à condition que le contrat soit bien rédigé. Un logiciel métier sur-mesure développé avec des technologies ouvertes, hébergé sur une infrastructure que vous maîtrisez, dont vous êtes propriétaire du code source, vous donne un niveau de liberté qu'aucun SaaS packagé ne peut offrir. Le risque subsiste si la clause de propriété intellectuelle est floue ou si l'hébergement reste chez le prestataire sans procédure de sortie.