La couche de capacités : des milliers et des milliers de connecteurs et la fin des intégrations maison

Pendant vingt ans, l'unité du travail d'intégration, c'était le point de fin. Une URL, un verbe, un format de protocole, une limite de débit, un flux OAuth, et du code de liaison pour tenir le tout ensemble. L'unité est en train de changer. C'est la capacité : une chose qu'un agent peut faire à un système. « Envoyer la facture » est une capacité. « Rembourser la dernière commande » est une capacité. « Récupérer les tickets ouverts » est une capacité. Le point de fin est un détail d'implémentation dessous.

C'est pourquoi Vinkius livre un catalogue de capacités, et non un catalogue de wrappers d'API. Aujourd'hui, le catalogue contient des milliers et des milliers de connecteurs gérés et 61 738 capacités, et le chiffre qui compte n'est pas le nombre de connecteurs. C'est que chaque capacité est une unité que vous pouvez héberger, versionner, autoriser, mesurer et auditer, de la même façon que vous auditeriez n'importe quel autre service de la pile.

Cet article est l'anatomie de cette couche. Ce qu'est réellement une capacité, comment une requête la traverse, les cinq façons dont une capacité est livrée, et la mathématique des plans et le modèle de sécurité dessous. Pas de marketing : tous les chiffres ici sont ce que le produit livre.

Le nom n'est pas un accident. Dans le produit, vous ne cherchez pas des connecteurs, vous cherchez des « AI Capabilities ». Le catalogue, la barre de recherche et l'argument d'upgrade parlent la même unité. Quand un éditeur vend une couche de l'ère des agents, l'unité de vente dit ce qu'il croit vendre. Vinkius vend des actions, pas des points de fin.

L'unité de travail n'est plus le point de fin

Un agent n'envoie pas une requête HTTP à un service. Il envoie une intention. Dans le modèle d'exécution de Vinkius, l'intention a exactement trois champs. La capacité, qui est l'action à accomplir. L'entrée, qui est la donnée dont l'action a besoin. Et l'identité, qui est l'utilisateur qui autorise l'action. Tout le reste, authentification, permissions, mapping vers la bonne opération, nouvelle tentative sur une faute transitoire, appartient à la plateforme, pas à l'agent.

Puis quatre étapes s'exécutent. Authenticate branche le bon compte utilisateur. Authorize applique les permissions de l'action demandée. Resolve mappe la capacité vers la bonne opération système. Execute lance l'opération, relance quand il faut, et note ce qui s'est passé. Le résultat revient structuré : un statut, une sortie normalisée, et une trace.

Regardez ce que le modèle ne voit jamais. Le protocole de transport. La politique de relance. Le contrôle de permission. Il a demandé un résultat et il l'a eu.

C'est là que la plupart du secteur reste coincé. Les modèles sont meilleurs pour prendre un résultat et raisonner dessus que pour choyer un appel fetch. La couche de capacités est le lieu où l'intention cesse d'être un prompt et devient une transaction.

Une autre partie de l'anatomie compte si vous faites tourner des flottes d'agents : qui agit. Chaque appel de capacité porte une identité, et l'identité est un utilisateur, pas le modèle. Le produit est construit autour de ce fait. Vous pouvez bâtir une application pour un nombre illimité d'utilisateurs finaux, et les connexions et identifiants de chacun restent totalement isolés de tous les autres et de la plateforme elle-même. L'agent est la main. L'identité est de savoir à qui la main appartient.

Ce que le catalogue livre

Les chiffres d'abord, parce qu'ils ancrent tout. Des milliers et des milliers de connecteurs. 61 738 capacités. La plupart des connecteurs sont officiels, publiés et maintenus par Vinkius, et le reste est de la communauté. Un nombre croissant de fiches portent la marque « nouveau ». Le compteur du site est généré à partir des données du catalogue, pas une constante de marketing que quelqu'un retape chaque trimestre, et c'est la différence entre un chiffre qu'on peut citer au conseil et un chiffre qui flatte.

Les notes font partie de la surface. Les connecteurs officiels portent un A+, et les fiches de la communauté portent des notes littérales qui descendent jusqu'à F, donc celui qui note ne décore pas. J'ai vu des éditeurs publier des scores de qualité que personne ne peut reproduire. Les nôtres vivent dans les données du catalogue, à côté de chaque fiche, et c'est là qu'on les veut.

La publication, c'est l'autre côté du grand livre. Les fiches officielles sont maintenues par Vinkius, et les fiches de la communauté, par leurs éditeurs. La distinction compte pour une raison. Officiel veut dire que Vinkius répond. Sur une fiche de la communauté, l'éditeur répond. Les deux passent par le même pipeline de vérification et arrivent dans la même recherche, et le badge de confiance est un marqueur de responsabilité, pas une catégorie.

Ce que « géré » veut vraiment dire, c'est la partie ennuyeuse. Vinkius héberge le connecteur, le maintient, le met à jour, et gère l'authentification. Quand OpenAI ou Salesforce change un point de fin, c'est notre boulot, pas le vôtre. Chaque connecteur du catalogue arrive comme une surface vérifiée : prête pour la production, avec les garanties que le label implique. Le plan de contrôle le dit en une ligne, MCP VERIFIED, PRODUCTION READY, VINKIUS GUARANTEED, et un clic active le connecteur dans votre compte.

Héberger le connecteur de quelqu'un d'autre, c'est absorber la responsabilité. Quand un tiers révoque un outil, la correction tombe dans le connecteur, pas dans votre application. Le catalogue est le lieu où cette responsabilité est posée, et où votre facture de maintenance s'arrête.

L'amplitude se voit dans la liste de noms. OpenAI, Anthropic, Stripe, GitHub, Slack, Salesforce, Tesla, PayPal, Plaid, Datadog, Jira, Shopify, plus la longue traîne : Idealista, Semrush, ElevenLabs, Hugging Face. La page du catalogue réduit tout à une phrase. Une connexion, tous les outils que votre agent peut appeler.

Deux façons de naviguer

Il y a deux étagères, et elles répondent à des questions différentes. La première est éditoriale : douze catégories choisies à la main, Industry Titans, Superpower, Loved by Developers, AI Frontier, The Unthinkable, Money Moves, Ship It, Talk to Me, Growth Engine, Brain Trust, Fort Knox, et Friends of MCP. Ce sont des jugements de goût. C'est la réponse à la question « montre-moi ce qui vaut mon temps ».

La seconde est organique : vingt-deux catégories peuplées automatiquement depuis les manifests, de Productivity et Developer Tools jusqu'aux verticales de longue traîne comme Legal, Healthcare, Travel and Hospitality, et Real Estate. C'est la réponse à la question « que puis-je brancher pour cette équipe, maintenant ».

Dans le produit, vous n'avez pas à choisir d'étagère. Discovery, Explore, Favorites, Activated, et Library sont côte à côte, et la recherche du catalogue est la même recherche qu'un agent utilise quand il cherche un outil au milieu d'une tâche. Dans Explore, quatre onglets font le travail : Top Curated, Newest, Top Tags, et Top Categories. Chacun est une réponse différente à la même question, lequel des milliers et des milliers est le mien.

Le catalogue se parcourt aussi sans compte. Discovery, tags, catégories et nouveautés sont publics, parce que le catalogue est une surface de découverte, et la découverte ne devrait pas se cacher derrière un mur de connexion. L'activation est là où le compte compte. Un clic, et le connecteur est vivant dans votre plan de contrôle. La recherche travaille sur la tâche, pas seulement sur le nom : vous décrivez ce dont vous avez besoin, et le catalogue trouve les capacités qui l'alimentent.

Les cinq façons dont une capacité arrive

Une capacité est un contrat posé sur le transport. Dessous, l'une des cinq sortes de serveurs la livre.

Le serveur API est le cheval de trait. C'est un proxy REST : vous le pointez sur une URL de base, et la surface transforme n'importe quelle API en interface MCP sans que vous reconstruisiez le côté client. Si l'éditeur livre une spec, vous l'importez, et le jeu de capacités apparaît.

Le serveur Agent Skills est différent par design. Il expose des fichiers de compétences que le modèle lit à la demande, selon un modèle appelé disclosure progressive : le modèle voit ce qui existe, puis tire le détail seulement quand il choisit ce chemin. C'est la forme de capacité qui va aux bases de code et de connaissances où la description complète de l'outil ne tiendrait pas dans le contexte.

Le serveur MCP Server Deploy, c'est votre propre code. Vous l'emballez, vous l'envoyez sur le edge, et il tourne dans le runtime des isolates V8 que j'ai détaillé ici. L'histoire du runtime est le lieu où vivent les chiffres de coût et de latence.

Le serveur YAML est le déclaratif. Un manifest en YAML, compilé au moment du déploiement. C'est la forme de capacité que les équipes veulent dans git, revue comme de l'infrastructure.

L'authentification vit dessous tout, en quatre formes. Aucune, quand la surface est publique. Bearer, pour les services à jetons. Basic, pour le coin du legacy. Et un en-tête personnalisé, pour les éditeurs qui refusent de rentrer dans les trois autres. Le point de la taxonomie, c'est que le modèle ne voit rien de tout ça. Le modèle voit une capacité ; le transport, la forme d'authentification et la politique de relance sont le problème de la plateforme.

Du côté de l'utilisateur, l'authentification n'est pas un mur. Chaque connecteur montre son état d'un coup d'œil : configuration requise, connecté, prêt. Pas de page de connexion cachée, pas de « ça doit marcher ». Il y a une autre unité qui mérite son nom avant la mathématique des plans : le jeu de capacités. Chaque connecteur livre son jeu complet, les actions exactes que votre IA peut choisir quand vous lui demandez de travailler avec ce connecteur. L'agent ne voit pas tout le catalogue d'un coup ; il voit les outils qu'il a vraiment. Ce n'est pas un détail de produit. C'est ce qui garde le contexte du modèle honnête.

La mathématique des plans

L'accès aux capacités est verrouillé par plan en un seul endroit : la tier gratuite. Elle tourne à cent requêtes par cycle de trente jours, un jeton de connexion, deux installations de catalogue, et ses tableaux de bord sont étiquetés données d'exemple, pour que personne ne confonde une démo avec un système en vie. À partir des tiers payants, le catalogue n'a pas de plafond d'installation, et les plafonds de requêtes sont les vrais chiffres de planification : 5 000 par cycle en Lite, 25 000 en Starter, 100 000 en Pro, et 500 000 en Business.

Les plafonds ne sont pas de la décoration. C'est la couche de mesure. Une capacité qui peut rembourser une commande est une capacité qui peut tourner en boucle, et une boucle qui brûle mille dollars par nuit est un problème de gouvernance avant d'être un problème d'ingénierie. Le KPI propre au produit, Cost Saved, mesure les octets qu'un plafond de coût retire du chemin de sortie, donc le chiffre du tableau de bord est un chiffre défendable en réunion de budget.

Au-delà du plafond, le dépassement se facture en limite souple, sans couper l'appel, et c'est volontaire. Un arrêt dur en production, c'est une file de support. Un dépassement mesuré, c'est une ligne de facture. C'est toute la philosophie des plafonds : ce sont des chiffres pour planifier, pas des murs contre lesquels on bute.

Les jetons de connexion grimpent l'escalier : trois en Lite et Starter, dix en Pro, vingt-cinq en Business. L'historique d'activité passe de trois jours sur les tiers payants d'entrée à sept en Pro et trente en Business, et la piste d'audit du tier supérieur est la piste immuable. C'est là que vivent les organisations : équipes, rôles, périmétrage par projet, comptes de service et provisionnement de clés API, SSO, piste d'audit immuable de trente jours, révocation instantanée des jetons, et un arrêt d'urgence avec disjoncteur.

La couche de sécurité que votre CISO va demander

Chaque connecteur tourne dans son propre bac étanche. Au moins trente-quatre règles s'appliquent sur chaque requête, et elles couvrent les limites de mémoire, les limites de CPU, la protection contre le SSRF, le blocage des réseaux privés, la protection contre les fichiers malveillants, et l'isolement des identifiants. Les événements de sécurité arrivent en temps réel vers Datadog, Splunk, ou un webhook. La piste d'audit est signée et enchaînée, signatures Ed25519 sur des blocs SHA-256, donc un record falsifié ne peut pas disparaître en silence sans casser la chaîne.

Le traitement des identifiants suit une règle. Limité à un périmètre, contrôlé par l'utilisateur, révoquable à tout moment, et la plateforme n'entraîne jamais ses modèles sur vos données. Le FAQ du produit le dit lui-même, mot pour mot, pour pouvoir le citer en retour : « Vinkius n'entraîne jamais sur vos données, et vous pouvez révoquer l'accès à tout moment. » Les identifiants des utilisateurs finaux sont stockés en sécurité et ne sont plus jamais affichés après enregistrement, et les connexions de chaque utilisateur restent totalement isolées de toutes les autres et de la plateforme. La surface d'audit de déploiement exporte un PDF, et c'est le format qu'un régulateur ou un comité de direction lit réellement.

Depuis des années, je demande aux éditeurs d'écrire ces deux phrases sur leur page. Le catalogue les écrit.

Pourquoi le géré bat le bricolé

Chaque intégration sur mesure est une promesse qu'il faut tenir pour toujours. L'éditeur change un champ. Vous réécrivez le parseur. Le flux d'authentification bouge. Vous le traquez. Une intégration que personne n'a regardée depuis un an est une dette déguisée en fonctionnalité. Le catalogue inverse le modèle de maintenance. Hébergement, authentification, exécution, surveillance, mises à jour : la plateforme les fait, et une capacité devient une ligne dans un manifest, au lieu d'une base de code de liaison que quelqu'un doit choyer.

La mathématique de cette inversion est l'argument. Disons que votre pile a besoin de cent connecteurs. Cent intégrations sur mesure, c'est cent promesses de maintenance, chacune un parseur qui peut pourrir, un flux d'authentification qui peut casser, une version qui peut changer sous vous. Cent connecteurs du catalogue, c'est cent surfaces maintenues, et le coût de maintenance tombe du côté plateforme de la facture. C'est la différence entre acheter un outil et en être propriétaire.

Il y a aussi l'argument du premier jour. Votre application IA démarre avec des milliers de connecteurs dans le catalogue, et c'est une différence réelle face à l'équipe qui passe son premier trimestre à câbler les deux intégrations de la démo. Le catalogue est la raison pour laquelle le premier commit d'une application d'agents peut être celui qui produit.

Du côté des clients, même forme. Les surfaces du catalogue parlent MCP, ce qui veut dire que le même connecteur fonctionne depuis ChatGPT, Claude et Gemini, depuis Cursor, Cline et VS Code, et depuis le Vercel AI SDK dans votre propre application. Vous maintenez le jeu de capacités une fois, et chaque client qui parle le protocole peut l'appeler.

Où ça se place

Le catalogue, c'est la couche de capacités. Le plan de contrôle, ce sont les règles des appels : identité, application sur le chemin, dépense bornée, isolement des secrets, registre infalsifiable, continuité de trace, une porte humaine et une coupure, et un surcoût mesuré. J'ai écrit les huit règles dans l'article sur le plan de contrôle. Le runtime des isolates V8 a son propre article. Le catalogue est le lieu où ces règles ont quelque chose à gouverner.

Trois articles, une pile. L'article du plan de contrôle couvre les règles des appels. Celui du V8 couvre l'endroit où le code tourne. Celui-ci couvre l'unité qui rend les deux autres utiles. Sans catalogue, le plan de contrôle ne gouverne rien, et le runtime des isolates n'a rien à faire tourner. Le catalogue, c'est le côté offre de l'économie des agents. Il décide quelles actions existent, qui les maintient, ce qu'elles coûtent, et ce qui se passe quand elles échouent.

Quand un agent demande le monde, la couche de capacités est la porte, et le plan de contrôle est le verrou. Le travail du catalogue est de rendre la porte assez large pour qu'aucun agent n'ait à en bâtir une seule. Le seuil que j'exigerai du catalogue, et de tout catalogue qui revendique le même espace : des surfaces vérifiées, des notes que vous pouvez reproduire, une mesure qu'une équipe financière peut défendre, et une piste d'audit qu'on ne peut pas rééditer en silence. Le reste, c'est un répertoire, pas une couche.