Ce que le terme recouvre vraiment
L'enfermement propriétaire n'est pas un contrat abusif, c'est une asymétrie. Vous restez chez un fournisseur non parce qu'il est le meilleur, mais parce que partir coûterait plus cher que rester. Ce coût de sortie prend plusieurs formes : données dans un format non transposable, logique métier exprimée dans un formalisme propriétaire, compétences de l'équipe spécialisées sur un outil, ou interruption de service pendant la migration.
Il n'y a pas de fournisseur sans aucun enfermement. Même une base de données libre crée une adhérence. La question utile n'est donc pas binaire : elle porte sur le montant de la facture de sortie et sur le fait de le connaître.
Comment il s'installe
Presque toujours par une succession de décisions justifiées. On choisit une plateforme pour aller vite, ce qui est le bon arbitrage à ce moment. On y ajoute une deuxième fonctionnalité parce qu'elle est déjà là. Puis un processus critique s'y installe. Trois ans plus tard, la logique de l'entreprise vit dans un outil que personne n'a jamais évalué comme un choix structurant.
Le moment où l'enfermement devient réel n'est presque jamais identifié sur le coup, parce qu'aucune décision ne le marque. C'est ce qui le rend particulier : il n'est pas le résultat d'une erreur, mais de l'absence de réexamen.
Les quatre questions qui le mesurent
Où sont les données, et sous quel format ? Un export existe-t-il, et produit-il quelque chose d'exploitable ou une archive illisible.
Où vit la logique métier ? Dans du code que vous possédez, ou dans un éditeur visuel propriétaire qui ne se transpose pas.
Que coûterait une migration ? En jours de travail, en interruption de service et en risque, pas en intention.
Existe-t-il une alternative crédible ? Un fournisseur unique sur son marché n'a aucune raison de modérer ses tarifs.
Les arbitrages qui le limitent
Privilégier les standards ouverts quand ils existent : une base PostgreSQL plutôt qu'un moteur propriétaire, un stockage compatible avec le protocole S3 plutôt qu'un format exclusif, Kubernetes standard plutôt qu'un orchestrateur maison. Isoler les dépendances derrière une couche d'abstraction pour que le changement soit un chantier borné. Et surtout, garder la logique métier dans du code que vous possédez, quelle que soit la plateforme qui l'exécute.
Ces choix ont un coût immédiat en vitesse. C'est un arbitrage assumé, pas un principe absolu : accepter un enfermement en le mesurant vaut mieux que de le refuser partout au prix de la lenteur. Voir aussi dette de plateforme et TCO logiciel.
