AI SDK : une couche TypeScript unique au-dessus des fournisseurs de modèles

Le problème : réécrire la couche modèle à chaque changement de fournisseur

Chaque fournisseur de modèle expose ses propres noms de paramètres, ses propres formats de réponse et sa propre gestion des appels d'outils. Une application qui appelle OpenAI directement hérite de cette surface d'API dans tout son code. Passer à Anthropic ou à Google revient alors à toucher chaque point d'appel. L'AI SDK répond à ce problème en imposant une seule interface, generateText, et en déplaçant les différences dans des paquets fournisseurs séparés.

Le public visé est précis : des équipes TypeScript qui construisent des applications et des agents avec Next.js, React, Svelte, Vue ou Angular, sur Node.js. Le README mentionne aussi Node.js 22+ comme prérequis. Si votre code est en Python, en Go ou en Rust, la bibliothèque ne vous concerne pas, quelle que soit la qualité de son API.

Deux chemins vers un modèle, et ce que cela implique

L'architecture repose sur une couche d'abstraction unique avec deux modes d'accès. Le premier passe par la passerelle Vercel AI Gateway, activée par défaut : on transmet une chaîne de caractères comme 'anthropic/claude-opus-4.6' ou 'openai/gpt-5.4' et le SDK résout le fournisseur. Le second consiste à installer les paquets fournisseurs et à les appeler explicitement, par exemple anthropic('claude-opus-4-6') après npm install @ai-sdk/openai @ai-sdk/anthropic @ai-sdk/google.

Le choix entre les deux n'est pas neutre. La chaîne de caractères est plus rapide à mettre en place et donne accès à tous les fournisseurs majeurs sans configuration, mais elle fait transiter les requêtes par l'infrastructure de Vercel. L'import direct place l'appel chez le fournisseur choisi, au prix d'une dépendance supplémentaire par fournisseur dans votre package.json. La documentation ne tranche pas à votre place : elle présente les deux et laisse la décision à l'intégrateur.

Sorties structurées et validation par schéma

generateText ne renvoie pas seulement du texte. L'exemple du README montre un appel avec Output.object et un schéma Zod décrivant une recette : nom, tableau d'ingrédients avec nom et quantité, tableau d'étapes. Le résultat est exposé via la propriété output, déjà typé.

Le point intéressant est que la validation vit dans le schéma, pas dans le prompt. Vous décrivez la forme attendue en TypeScript, et Zod s'occupe de la vérification à l'exécution. Cela déplace une partie du travail de robustesse du texte du prompt vers du code vérifiable. La contrepartie est une dépendance à Zod, visible dans l'import du même exemple. Le README ne documente pas ce qui se passe lorsque le modèle produit une sortie non conforme au schéma, ni s'il existe une politique de nouvelle tentative. C'est une zone que la documentation laisse ouverte.

ToolLoopAgent : la boucle d'outils prise en charge par le SDK

Pour les agents, le SDK fournit ToolLoopAgent. On lui passe un model, un system prompt et un objet tools. Le README donne l'exemple d'un agent avec un outil shell qui exécute des commandes dans un bac à sable Vercel Sandbox et renvoie stdout. Un second exemple, plus complet, construit un agent de génération d'images avec openai.tools.imageGeneration et partialImages: 3.

Ce qui distingue cet exemple, c'est la chaîne de bout en bout qu'il décrit. L'agent est exporté depuis un fichier, son type de message est dérivé avec InferAgentUIMessage, une route Next.js App Router appelle createAgentUIStreamResponse, et le composant client utilise useChat de @ai-sdk/react avec des parties typées comme 'tool-generateImage'. Le composant associé reçoit une invocation et bascule sur invocation.state, avec les cas 'input-available' et 'output-available'.

Autrement dit, le SDK ne s'arrête pas au serveur : il définit aussi la forme du message qui traverse le réseau jusqu'au composant React. C'est pratique, et c'est aussi un couplage. Votre interface utilisateur hérite des conventions de parties de message du SDK, et le composant de rendu d'outil doit connaître l'état exact de l'invocation. Toute rupture dans ce contrat se propage du serveur jusqu'au rendu.

Installation et mise en route

Le README indique Node.js 22+ et un gestionnaire de paquets. L'installation de base tient en une commande : npm install ai. Pour l'interface, il faut ajouter le paquet du framework, par exemple npm install @ai-sdk/react. Pour un accès direct aux fournisseurs, npm install @ai-sdk/openai @ai-sdk/anthropic @ai-sdk/google.

Le README mentionne également une commande destinée aux agents de codage : npx skills add vercel/ai, présentée comme utile si vous utilisez Claude Code ou Cursor. Elle ajoute une compétence au dépôt, ce qui suppose que votre outil d'assistance lise ce format. Ce n'est pas une étape d'installation obligatoire.

Il n'y a pas, dans le matériel fourni, de fichier de configuration à éditer, de clé d'environnement nommée, ni d'étape de build spécifique. Le SDK s'utilise depuis le code, pas depuis un fichier de configuration. C'est un point à garder en tête : si vous cherchez un fichier de paramètres central, il n'apparaît pas dans la documentation fournie.

Ce que le dépôt ne dit pas

Le champ licence du dépôt porte la valeur NOASSERTION. Cela signifie que l'identifiant de licence n'a pas été reconnu automatiquement par l'outillage qui produit cette métadonnée. Le README ne nomme aucune licence. Avant toute utilisation en contexte commercial, il faut ouvrir le fichier LICENSE du dépôt et le lire, ou le faire lire par qui de droit. Je ne peux pas vous dire ici quelles obligations il contient.

La maintenance, elle, est active et rapide. Trois branches de versions reçoivent des correctifs le même jour : ai@7.0.95, ai@6.0.279 et ai@5.0.254, tous publiés le 2026-09-09. Cette cadence a un revers concret : trois lignes majeures maintenues en parallèle signifient que les correctifs de sécurité et de compatibilité arrivent sur des branches distinctes. Une équipe qui épingle la version 5 ne bénéficie pas automatiquement du travail fait sur la 7, et devra planifier une montée de version majeure. Le README ne décrit pas de politique de support ni de durée de vie des branches.

Deuxième angle mort : la documentation fournie ne traite pas du tout le cas où un fournisseur tombe ou renvoie une erreur. Aucun mécanisme de reprise, de bascule ou de délai d'attente n'apparaît dans les exemples. Si votre application dépend d'un seul fournisseur, cette couche de robustesse reste à votre charge.

Face à un client HTTP écrit à la main

L'alternative la plus directe n'est pas un autre SDK, c'est l'absence de SDK : appeler l'API REST du fournisseur avec fetch, et écrire soi-même la gestion des messages, des appels d'outils et du streaming. La différence d'approche est nette. Avec fetch, vous ne dépendez que de la spécification du fournisseur, vous contrôlez chaque octet envoyé, et vous n'ajoutez aucune dépendance au projet. En échange, vous réécrivez la boucle d'outils, la sérialisation des messages et le format des parties côté client, et vous le refaites pour chaque fournisseur que vous ajoutez.

Le SDK prend le pari inverse : une dépendance partagée, un format de message imposé, et un changement de fournisseur qui se limite à une chaîne de caractères ou à un import. Ce pari se défend lorsque vous prévoyez de comparer plusieurs modèles ou d'en changer. Il se défend moins si vous n'utiliserez jamais qu'un seul fournisseur avec une poignée d'appels : vous payez alors une abstraction complète pour un besoin que fetch couvre en quelques dizaines de lignes.

Conclusion éditoriale

Adoptez l'AI SDK si votre application est déjà en TypeScript avec Next.js, React, Svelte ou Vue et que vous voulez changer de fournisseur de modèle sans réécrire la couche d'appel. Passez votre chemin si votre pile est en Python ou en Go, ou si vous refusez une dépendance à la passerelle Vercel pour l'accès par défaut aux modèles. Avant d'intégrer, vérifiez deux points précis : la compatibilité de votre runtime avec Node.js 22+, exigé par le README, et le fichier LICENSE du dépôt, dont l'identifiant NOASSERTION signifie que la licence n'est pas reconnue automatiquement et doit être lue à la source.

Sources officielles

1. Issues
2. Project website
3. README
4. Releases
5. vercel/ai on GitHub