Vendor lock-in (IA)
Dépendance à un fournisseur IA au point où changer d'outil ou de modèle a un coût de migration réel : abonnements restreints, configs non portables, workflows figés.
Définition
Le vendor lock-in appliqué à l'outillage IA recouvre deux couches distinctes. La première : le lock-in modèle/abonnement — un abonnement premier-parti (Claude Code sur l'abonnement Anthropic, par exemple) qui restreint son usage aux outils du même éditeur, empêchant de le réutiliser comme provider dans un agent tiers. La seconde : le lock-in configuration — les agents, skills, hooks et commandes custom construits pour un outil (`.claude/`, `.opencode/`) ne se réutilisent pas tels quels sur un autre. Les deux se cumulent : changer d'outil signifie souvent reconstruire à la fois l'accès au modèle et la configuration de workflow.
Point de vue postcursors
Le lock-in n'est pas disqualifiant en soi. Un outil premier-parti bien intégré peut valoir le compromis si l'intégration rapporte plus qu'elle ne coûte à migrer. L'erreur n'est pas de choisir un outil verrouillé — c'est de ne jamais maintenir de sortie de secours testée, et de découvrir le coût du lock-in seulement quand le fournisseur change les règles.
En pratique
Le cas concret : Anthropic a restreint l'utilisation de l'abonnement Claude Code dans les outils tiers, cassant du jour au lendemain un workflow OpenCode qui consommait cet abonnement comme provider. Aucune option de repli n'était en place, la migration s'est faite dans l'urgence. Le second cas, plus lent : un setup `.claude/` avec agents spécialisés, skills et hooks ne se porte pas vers OpenCode ou Kilo Code — il faut le reconstruire, format par format.
Confusions fréquentes
- ✗ Traiter le lock-in comme un argument absolu contre un outil, sans jamais chiffrer le coût réel de migration face à ce que l'outil rapporte au quotidien
- ✗ Confondre lock-in modèle (accès au provider) et lock-in configuration (agents/skills/hooks) — les deux se cumulent mais se résolvent par des moyens différents