Comment créer

Le Démarrage rapide vous a montré un appel. Lisez cette ligne lentement, car c'est tout l'avenir en une phrase : avec une seule Application key, chaque utilisateur de votre produit obtient des milliers de connexions IA dès le premier jour, chaque utilisateur isolé avec ses propres connecteurs, identifiants et capacités, et aucun d'eux jamais exposé à Vinkius. Aucune plateforme du marché n'offre cette phrase. Les cinq builds complets de cette section montrent ce qu'elle donne en production : un chatbot grand public, des copilotes par département, une flotte d'agents, des automatisations sans intervention humaine et un SaaS multi-tenant, chacun écrit pour qu'un développeur commence au sommet et termine avec une IA fonctionnelle qui agit dans le monde réel.

Le primitif sous les cinq est celui que le reste de l'industrie n'offre pas : toute entité qui doit agir devient un utilisateur. Les analyses de coûts de l'industrie estiment à six chiffres, sur trois ans, une version maison de cette architecture, et même celle-ci n'est jamais tout à fait livrée. Sur l'AI Connect SDK, c'est la ligne de départ, pas la ligne d'arrivée.

L'idée qui débloque tout

Dans chaque tutoriel, la même ligne apparaît :

const user = vinkius.user(externalId);

Cet externalId est une valeur que vous définissez. Ce n'est pas un compte Vinkius, pas un e-mail, pas un être humain. C'est une chaîne opaque et sûre pour les URL que votre backend contrôle déjà, et le SDK la traite comme la frontière qui isole les connecteurs, les identifiants et les capacités. Comme elle est opaque, elle peut nommer tout ce qui a besoin d'agir :

Mesurez à quel point c'est radical. Chaque plateforme de connectivité que l'industrie a livrée jusqu'ici connecte une application à un service. Aucune ne donne à votre produit son propre modèle d'utilisateurs par entité, avec des identifiants que votre code ne peut jamais relire. La ligne ci-dessus le fait, et c'est toute la différence entre louer de la connectivité pour votre app et posséder une plateforme de connectivité pour vos utilisateurs.

Choisissez votre build

Le flux que tous les builds partagent

Quelle que soit l'entité que vous modélisez, la boucle d'exécution est identique. Apprenez-la une fois et vous pouvez construire les cinq de mémoire :

1. Créez un client sur votre serveur à partir d'une seule Application key.
2. Identifiez l'acteur: donnez à vinkius.user(externalId) l'id qui possède l'action.
3. Connectez un connecteur: user.connector('github').connect(), stockez les identifiants une fois, ne les relisez jamais.
4. Découvrez les capacités: user.capabilities() ne renvoie que ce que cet acteur a de prêt.
5. Passez-les à un modèle: un adaptateur convertit l'ensemble en OpenAI, Anthropic, Gemini, Vercel AI SDK, LangChain ou JSON Schema pur.
6. Exécutez et renvoyez: exécutez l'appel d'outil du modèle ; isError laisse l'agent récupérer au lieu de planter.

La barrière défensive, sous le capot

Tous les builds ci-dessous s'appuient sur la même architecture, et la comprendre est ce qui rend la promesse « vous ne possédez pas l'infrastructure d'intégration » crédible plutôt que du marketing.

• Deux plans, un secret. Un plan de contrôle (users, connectors, credentials, catalog) sur REST, et un plan d'exécution (lister et exécuter les capacités) qui parle en JSON-RPC directement au runtime de chaque connexion. Tout est atteint avec une seule clé vk_app_sk_* ; le runtime parle le protocole MCP en interne, mais cela n'apparaît jamais dans votre vocabulaire.
• Mesuré et révocable par connexion. Chaque connexion possède son propre token de données vk_live_*. La dépense et la révocation immédiate s'appliquent par connexion, ce qui explique pourquoi un département, un agent ou un compte de service peut être isolé de façon financière et opérationnelle, pas seulement logique.
• Identifiants en écriture seule. Votre serveur stocke les secrets de connecteur d'un utilisateur et peut voir quels champs sont configurés, mais rien, ni votre code, ni le modèle, ni le tableau de bord, ne relit jamais les valeurs.
• Masquage par défaut. Les hooks d'observabilité reçoivent des données déjà purgées : Authorization, les champs en forme d'identifiant et les segments d'URL vk_live_* sont masqués avant l'exécution de votre callback.
• Zéro dépendance d'exécution, partout. fetch natif, double ESM/CJS, typé, il tourne sur Node 18+, Bun, Deno et l'edge, si bien que la même cible de build couvre un conteneur cron et un Worker.
• Réessai et idempotence réfléchis. Les échecs transitoires sont réessayés automatiquement avec un backoff full-jitter, et déclarer une idempotencyKey est ce qui rend sûr de réessayer même une écriture non idempotente.

Avant de commencer

Chaque build suppose les mêmes trois prérequis, traités en profondeur dans Installation et Authentification et portée :

• Node.js 18+ ou tout runtime serveur avec fetch (Bun, Deno, edge, Cloudflare Workers)
• @vinkius/connect installé
• Un App ID Vinkius (vk_app_…) et une Application Key (vk_app_sk_…) dans des variables d'environnement serveur

Prêt ? Aucune autre plateforme du marché ne peut héberger cette section, parce qu'aucune n'en offre la prémisse : qu'un utilisateur est toute entité qui a besoin d'agir. Choisissez un build et terminez-le, avec une IA qui agit pour chaque utilisateur que vous définissez.