L'IA change chaque trimestre. Vos connexions ne devraient pas.

Un mardi, une équipe passe de ChatGPT à Claude. L'abonnement prend trente secondes. La configuration prend trois semaines.

Pas parce que Claude est difficile. Parce que onze applications étaient connectées dans ChatGPT, chacune avec son propre grant OAuth, ses propres scopes, son petit morceau de mémoire institutionnelle. Le nouvel assistant démarre sans rien de tout cela. Quelqu'un réautorise Gmail, Slack, Notion, Stripe et la base interne. Quelqu'un découvre que l'ancien assistant avait un scope de calendrier plus large que ce que le nouveau permet. Quelqu'un demande pourquoi la piste d'audit a un trou le jour du changement, et personne n'a de bonne réponse.

La facture du modèle est visible. La facture du changement ne l'est pas, et elle est généralement plus élevée.

J'ai fondé Vinkius, et c'est le schéma que je vois dans presque toutes les équipes qui utilisent l'IA sérieusement. L'assistant est traité comme l'endroit où le travail se fait, donc les connexions y sont construites. Mais l'assistant est la couche la moins durable de la pile. Les modèles changent chaque trimestre. Les clients changent leur modèle de connecteur, leur écran de réglages, leur prix. Les applications que vous connectez sont la partie stable. La relation entre vos collaborateurs et ces applications est l'actif.

L'erreur est architecturale, pas tactique. Nous avons standardisé l'appel d'outil avec MCP, puis nous avons laissé chaque client posséder la connexion qui le produit. Le résultat est une couche de connexion dupliquée par assistant, par utilisateur, par appareil, et impossible à auditer comme un seul système.

Changer d'IA devrait être un copier-coller, pas une migration.

La facture que vous ne voyez pas

Chaque changement a un coût visible et un coût caché. Le visible, c'est l'abonnement, le nombre de sièges, l'email de migration. Le caché, c'est le travail de reconstruction de la relation entre votre équipe et ses applications, un écran de consentement à la fois.

Ce qu'un changement coûte vraiment	Ce qui se passe	Pourquoi cela s'accumule
Réauthentification	Chaque application redemande son consentement, par client	Chaque grant crée un nouveau token, avec sa propre expiration et son scope
Dérive des permissions	Le nouveau client expose un modèle de permission différent	La politique vit dans l'interface, elle est donc recréée à la main
Rupture d'audit	Les logs restent chez l'ancien fournisseur	Il n'existe pas de chronologie unique à travers le changement
Reconstruction des intégrations	Chaque client a son propre format de connecteur	Le travail se répète pour chaque application et chaque client
Confusion d'identité	Les comptes personnels et professionnels se mélangent	Le mauvais compte peut agir avec la bonne intention
Perte de contexte	Prompts, favoris et routines restent derrière	L'assistant oublie comment votre équipe travaille

Rien de tout cela n'apparaît dans un benchmark. Tout cela apparaît le premier mois.

Trois couches de lock-in

Le lock-in de modèle est celui dont tout le monde parle. Il est réel, mais il a un prix. Vous pouvez le mesurer, le négocier, le contourner avec un second fournisseur, et le marché continue de faire baisser le prix.

Le lock-in de client est celui que tout le monde ressent. C'est l'habitude, le raccourci clavier, la convention d'équipe, le projet qui vit déjà dans une barre latérale. Il est réel aussi, mais c'est surtout un problème d'UX, et les problèmes d'UX ont tendance à être résolus par la prochaine version.

Le lock-in de connexion est celui que personne ne nomme. C'est le coût de reconstruction de la relation entre vos collaborateurs et leurs applications chaque fois que l'interface change. Il n'apparaît pas sur un contrat. Il apparaît comme trois semaines de configuration et un trou dans la piste d'audit.

Dessinez la matrice. Cinq assistants en colonnes, douze applications en lignes. Soixante cellules. Chaque cellule a besoin d'un flux d'authentification, d'un identifiant, d'un scope, d'une politique et d'une ligne de log. Ajoutez maintenant un second utilisateur, un second appareil, un second framework d'agents. La matrice se multiplie, et chaque cellule est maintenue par quelqu'un qui ne l'a pas construite.

Une couche de connectivité fait s'effondrer la matrice. Les applications sont connectées une fois. Chaque client reçoit un lien. La politique et l'enregistrement vivent dans la couche, pas dans la cellule.

Ce qui casse quand la connexion vit dans le client

L'identifiant hérite de la posture de sécurité du client. Le moyen le plus rapide de connecter une application à un assistant est de coller un token dans sa configuration. Le token est maintenant dans le stockage du client, dans ses logs, sous sa politique de rétention, et dans la fenêtre de contexte d'un modèle que vous ne contrôlez pas. Une connexion qui vit dans le client hérite de la posture de sécurité du client, ce qui n'est pas une phrase qu'une équipe sécurité veut signer.

Le modèle de permission est recréé à la main. Chaque client a sa propre idée de ce qu'un connecteur peut faire. Une permission qui existe dans un assistant peut ne pas exister dans le suivant, et la politique soigneusement définie le lundi est reconstruite de mémoire le mercredi. La dérive est invisible jusqu'à ce qu'une action qui aurait dû être bloquée réussisse.

La piste d'audit se coupe au changement. Quand l'appel est fait par le client, l'enregistrement est fait par le client. Changez de client et la chronologie se divise en deux. La question après un incident n'est pas « qu'a dit le modèle » mais « qui a autorisé cette action, pour quel compte, à quelle heure ». Un log par client ne répond pas à cela entre clients.

La maintenance ne finit jamais. Chaque client livre un nouveau format de connecteur, un nouvel écran de réglages, un nouveau JSON. Chaque application change son API, ses scopes, son flux OAuth. Le travail d'intégration ne disparaît pas quand vous passez à un connecteur géré. Il passe à celui qui maintient le connecteur, et si cette personne, c'est vous, il revient chaque trimestre.

L'identité devient partagée. Un lien collé dans un canal d'équipe est une identité partagée. Un token commité dans un dépôt est une identité partagée. Une connexion censée appartenir à une personne appartient maintenant à tous ceux qui peuvent lire le canal. La connexion doit être liée à une personne, pas à une fenêtre de chat.

La portabilité est une architecture, pas un bouton d'export

Le mot portabilité signifie généralement un bouton qui exporte vos données. Ce n'est pas suffisant. Un CSV de vos connexions ne les réauthentifie pas, ne transporte pas les permissions, ne préserve pas la piste d'audit et ne fait pas fonctionner le client suivant. La portabilité est une propriété du chemin, pas d'un fichier.

Une connexion est portable quand elle satisfait huit exigences :

Exigence	Ce que cela signifie en pratique
Endpoint stable	Une URL par utilisateur qui ne change pas quand le client change
Lié à l'identité	L'endpoint porte la personne, pas la fenêtre de chat ou l'appareil
Protocole ouvert	La frontière parle MCP, donc tout client compatible peut s'y brancher
Identifiants externes	Les secrets vivent dans un coffre, jamais dans le client ou le contexte du modèle
Politique externe	L'autorisation est évaluée par action, hors de l'interface du client
Audit externe	Chaque appel est enregistré dans la couche, sur une seule chronologie
Token révocable	Le lien peut être révoqué et réémis sans reconstruire les applications
Mêmes capacités partout	Chat, IDE, terminal et vos propres agents voient le même catalogue

Si une connexion meurt quand le client est désinstallé, elle n'a jamais été à vous.

Comment un seul lien y parvient

L'unité est un lien de Connector, une URL de la forme https://edge.vinkius.com/vk_YOUR_TOKEN/mcp. Il porte votre identité vers la couche. Vous le collez dans ChatGPT, Claude, Gemini, Copilot, Perplexity, Grok, DeepSeek, Cursor, VS Code, Windsurf, JetBrains, Claude Code, Cline, Lovable, Antigravity, OpenClaw/ClawX, Goose, Claude Desktop ou tout client compatible MCP. Pour les agents que vous construisez, les mêmes capacités arrivent par le SDK AI Connect, avec des adaptateurs pour le Vercel AI SDK, OpenAI Agents, Anthropic, Google ADK, LangChain, CrewAI, Semantic Kernel et AutoGen.

Un lien, une identité, tous les clients.

Le catalogue est just-in-time. Le modèle n'a pas besoin d'apprendre 9 268 noms de Connectors. Il cherche par tâche, inspecte les capacités, se connecte et exécute. Aujourd'hui, le catalogue porte 9 268 Connectors gérés et 63 133 capacités, et le nombre bouge à chaque synchronisation.

Les identifiants des applications ne sont pas dans le client. Ils sont chiffrés au repos et ne reviennent jamais au modèle. La politique est évaluée par action. La piste d'audit est écrite dans la couche, donc elle survit au changement. Le lien est un bearer token : traitez-le comme une clé, gardez-le hors des dépôts, et révoquez-le depuis la console s'il fuit. Un nouveau token est émis en quelques secondes, et l'ancien cesse de fonctionner.

Le même lien fonctionne dans un IDE ou un client de bureau. Claude Desktop le lit dans son fichier de configuration :

{
  "mcpServers": {
    "vinkius-ai-connections": {
      "url": "https://edge.vinkius.com/vk_YOUR_TOKEN/mcp"
    }
  }
}

Le client change. La configuration change. Le lien ne change pas.

Une migration à exécuter cette semaine

Inventoriez les connexions. Listez les applications, le propriétaire de chaque compte, les scopes utilisés et la dernière fois que chacun a été appelé. Ne commencez pas par les applications faciles. Commencez par celles qui feraient mal si elles étaient connectées au mauvais compte.

Connectez une fois dans la couche. Autorisez chaque application une seule fois, au même endroit. Le travail est par application, pas par application et par client. C'est toute la différence entre une matrice et une liste.

Collez le lien dans un second client et exécutez trois vraies tâches. Une lecture, une écriture, et une qui devrait être bloquée. Le troisième test est le plus important. La portabilité sans un refus n'est que de la commodité.

Déplacez la politique dans la couche. Approbation par action pour les opérations destructrices, motifs de prévention de perte de données pour les PII et les champs financiers, un plafond de dépenses et un interrupteur qui arrête tous les agents. La politique s'applique à tous les clients à la fois parce qu'elle ne vit dans aucun d'eux.

Retirez les anciens tokens par client. La migration n'est pas terminée quand le nouveau client fonctionne. Elle est terminée quand l'ancien chemin est fermé. Révoquez les tokens collés dans les configurations des clients et vérifiez que rien n'en dépend encore.

Documentez le propriétaire et la rotation. Un bearer token sans propriétaire est un incident qui attend une date. Placez le lien sous la même discipline que n'importe quel autre secret de production.

L'objection du lock-in

Toute conversation d'architecture finit par cette question : ne remplacez-vous pas simplement un lock-in par un autre ?

C'est une question juste, et la réponse est une distinction. Le lock-in par otage signifie que partir vous coûte la capacité de travailler. Le lock-in par valeur signifie que partir vous coûte un meilleur produit, mais vous pouvez encore travailler. Le premier est un piège. Le second est un choix.

Une couche de connectivité doit rendre la sortie bon marché, exprès. Le protocole est ouvert. Le lien est à vous. Le token peut être révoqué et réémis. Les connexions ne sont pas stockées dans un client qui peut les déprécier. Si la couche disparaissait demain, vous perdriez de la commodité, pas vos applications ni vos comptes. C'est l'étalon auquel je veux être tenu.

La portabilité n'est pas une fonctionnalité qu'on ajoute à la fin. C'est la raison d'être de la couche.

La sécurité est la condition préalable

Un lien qui atteint toutes les applications est un passe-partout, et un passe-partout sans contrôle est pire que dix tokens éparpillés. Portabilité et gouvernance sont le même dessein : les deux exigent que la connexion vive sur un chemin que vous contrôlez.

Les contrôles ne sont pas des options. Ils rendent le lien sûr à transporter :

• Autorisation par action, évaluée avant que l'appel ne parte, au lieu d'un scope de token large.
• Isolation des identifiants, avec des secrets chiffrés au repos, authentifiés par signature et jamais placés dans le chemin du modèle.
• Motifs de prévention de perte de données comparés en mémoire avant que la réponse n'atteigne le modèle.
• Une piste d'audit infalsifiable, où chaque enregistrement est chaîné au précédent et signé.
• Des plafonds de dépenses et un disjoncteur qui arrête une boucle avant la facture.
• Un interrupteur d'urgence qui désactive tous les Connectors, révoque tous les tokens et termine toutes les sessions.

Comme les contrôles vivent dans la couche, ils s'appliquent à tous les clients à la fois. C'est le second bénéfice de la portabilité : vous corrigez une politique une fois, et elle tient dans ChatGPT, Claude, Cursor et l'agent que vous déploierez le mois prochain.

L'argument plus long pour chaque contrôle est dans Le plan de contrôle de l'ère des agents et Gouvernance de l'IA.

Questions fréquentes

Changer de client fait-il perdre mon historique de chat ? L'historique de chat appartient au client et y reste. Ce qui vous suit, c'est la connexion : les applications, les identifiants, les permissions et l'enregistrement d'exécution. Ce sont des actifs différents, et un seul d'entre eux devrait être lié à l'assistant.

Tous les clients d'IA prennent-ils cela en charge ? Tout client compatible MCP peut coller le lien. Plus de 20 clients sont couverts aujourd'hui, dont les principales applications de chat, les IDE et les agents de code. Pour les clients sans MCP, ou pour vos propres agents, le SDK AI Connect expose les mêmes capacités via des adaptateurs de framework.

Un seul lien est-il sûr ? C'est un bearer token, donc il est aussi sûr que sa manipulation. Gardez-le hors du contrôle de version, liez-le à une identité, révoquez-le s'il fuit et faites-le tourner régulièrement. La couche applique une politique par action même quand le lien est valide, donc un lien qui fuit ne signifie pas automatiquement carte blanche.

Deux clients peuvent-ils utiliser le même lien en même temps ? Oui. Chaque appel est attribué à la même identité et enregistré dans la même piste. Si vous avez besoin d'identités séparées, émettez des liens séparés.

Et mes propres agents ? Le même catalogue est disponible via le SDK, avec des connecteurs et des identifiants par utilisateur. Le runtime du modèle change ; la connexion ne change pas.

Est-ce réservé à MCP ? MCP est la frontière que nous standardisons parce que c'est la prise la plus large. La couche elle-même est agnostique au protocole, et les adaptateurs du SDK couvrent les frameworks qui ne parlent pas MCP directement.

L'assistant est un onglet

L'assistant est un onglet. Le modèle est un numéro de version. La connexion est le travail.

Les modèles continueront de changer. Les clients continueront de livrer de nouveaux écrans de réglages. Les applications sur lesquelles votre équipe travaille resteront à peu près les mêmes, et la relation entre vos collaborateurs et ces applications ne devrait pas être reconstruite chaque fois que l'interface l'est.

Configurez une fois. Collez le même lien dans la prochaine IA que vous utiliserez. Changez d'IA. Gardez les connexions.