TanStack AI 1.0 facilite le changement de modèle et précise les responsabilités de l’application

Schéma éditorial original de Ken Jo, fondé sur les sources présentées ci-dessous.

Changer de modèle devrait être une décision de produit. Dans une application qui accumule formats de messages propres aux fournisseurs, états du navigateur et rappels d’outils, cela peut devenir un chantier de migration avant même de comparer les nouvelles réponses.

TanStack AI 1.0, annoncé le 23 octobre 2026, prend un engagement précis à cette frontière : des API centrales stables, 23 adaptateurs de fournisseurs et plusieurs frameworks d’interface pris en charge. Sa nouvelle infrastructure d’agents, ou « harness », reste expérimentale. Pour choisir sur quoi construire aujourd’hui, cette distinction compte davantage que le numéro de version. Annonce de TanStack.

TanStack développe des bibliothèques open source pour les créateurs d’applications. Cette version concerne le logiciel entre le modèle d’IA et le produit : réponses en continu, outils, interfaces et état applicatif. Voici comment évaluer sa promesse de portabilité, son intérêt dans trois projets courants et les préparatifs nécessaires à une application en 0.x.

Exemple officiel TanStack AG-UI, © 2025 Tanner Linsley, licence MIT. L’image montre l’interface d’exemple du projet et son modèle sélectionné, pas une exécution réalisée pour cet article.

Une interface commune réduit l’ampleur du changement de fournisseur

Un adaptateur traduit les attentes de l’application vers l’API d’un fournisseur. Il offre un point d’entrée cohérent pour demander une réponse au modèle et traiter le résultat. L’application conserve son affichage des conversations et ses règles métier tout en remplaçant la partie tournée vers le fournisseur.

Cette couche ressemble à un standard téléphonique : elle établit des connexions compréhensibles sans rendre identiques les systèmes à l’autre bout. C’est utile précisément parce que les modèles, l’hébergement et les besoins du produit évoluent indépendamment.

L’annonce du 23 octobre présente 23 adaptateurs et une option compatible OpenAI pour les services qui utilisent ce format d’API. Elle distingue aussi le cœur stable des paquets de harness expérimentaux. Ce sont des engagements de compatibilité et de maintenance, pas une promesse que chaque fournisseur prend en charge toutes les fonctions d’un modèle. Périmètre de la version.

La question immédiate est donc précise : quelles parties de l’application actuelle survivraient à un changement de fournisseur ? L’affichage des réponses peut se transférer facilement. Un processus fondé sur les identifiants de fichiers d’un fournisseur, un comportement particulier des outils ou des hypothèses propres au modèle exigera peut-être encore des adaptations réfléchies.

Nous pensons que c’est la bonne manière de mesurer le progrès. La portabilité vaut quelque chose lorsqu’elle réduit le code produit à réexaminer. Le nombre de fournisseurs disponibles importe moins que la capacité à remplacer la dépendance qu’un produit réel doit changer.

L’application reste responsable de la définition du succès

Une API commune ne rend pas équivalentes les décisions de deux modèles. L’un peut mieux respecter un contrat de sortie structurée ; l’autre réagir différemment à une longue conversation ou à un résultat d’outil ambigu. L’adaptateur normalise le trajet de la requête sans démontrer que la réponse satisfait les exigences de l’application.

Il faut donc séparer les tests d’intégration du fournisseur des exemples définissant un comportement produit acceptable. Une requête correctement terminée vérifie un contrat ; une réponse exacte, un outil bien choisi et une interface compréhensible en vérifient plusieurs autres.

Un assistant de support peut disposer d’un outil qui consulte une commande et d’un autre qui prépare une demande de remboursement. Les deux fournisseurs peuvent les appeler correctement au niveau du protocole. Ce qui compte est que chaque modèle choisisse la bonne opération, respecte les mêmes autorisations et décrive fidèlement le résultat.

Avant de basculer, utilisez un petit jeu d’évaluation identifié. Incluez demandes incomplètes, entrées inhabituelles, outil indisponible et conversation reprise après un échange antérieur. Il s’agit d’une procédure d’ingénierie suggérée, pas d’un benchmark publié par TanStack. Elle rend reproductible la définition du succès propre à l’équipe.

L’adaptateur peut préserver le contrat de connexion. Les évaluations propres à l’application établissent si le comportement obtenu reste acceptable.

Trois projets révèlent des portabilités différentes

Prenons d’abord une application existante de support client. Elle possède déjà des comptes, des droits et un historique des conversations. Les réponses en continu doivent s’y intégrer sans imposer le remplacement de la navigation ou de la responsabilité des données. Une couche d’IA commune devient intéressante si elle permet de conserver ces structures tout en évaluant les fournisseurs derrière elles.

Dans ce projet illustratif, commencez par une recherche d’aide en lecture seule. Vérifiez que la réponse cite les documents fournis et qu’une annulation laisse la conversation dans un état cohérent. Ajoutez des actions lorsque l’interface distingue clairement une proposition d’une opération accomplie. Un changement ultérieur de modèle doit réutiliser ces mêmes vérifications.

Deuxième scénario : un outil interne d’écriture. L’équipe souhaite permettre de sélectionner un paragraphe, de demander sa révision et de comparer le résultat à l’original. L’interface est un éditeur, pas une fenêtre de discussion classique. Une intégration sans interface imposée est utile, car le produit doit décider où le texte généré apparaît et quand une personne l’accepte.

Ici, la portabilité doit préserver le travail de l’utilisateur. N’écrasez pas le paragraphe original au seul motif que le flux est terminé. Gardez la proposition séparée, laissez la personne l’examiner et définissez comment abandonner une génération interrompue ou échouée. Ces choix appartiennent à l’application, quel que soit le SDK fournissant le flux.

Troisième scénario : une équipe dispose déjà d’un serveur écrit dans un autre langage. L’exemple AG-UI officiel de TanStack relie un client React à six langages de serveur possibles par Server-Sent Events. Le README précise que ces serveurs parlent le protocole de transport sans nécessiter de paquets TanStack côté serveur. Exemple officiel multilangage.

Cet exemple concrétise la promesse de portabilité. Une équipe peut évaluer une interface de navigateur sans réécrire immédiatement un serveur fonctionnel. Elle doit toujours produire correctement les événements attendus, protéger le point d’accès et associer l’état de la conversation à ses utilisateurs. La démonstration d’un protocole compatible est un point de départ.

Ces scénarios montrent que le choix dépasse la comparaison de bibliothèques de discussion. La question est de savoir quelle part du produit reste cohérente lorsqu’un composant change. Même avec le même modèle, les frontières importantes varient selon l’équipe.

Cœur stable et harness expérimental demandent deux décisions

La version affirme l’engagement 1.0 pour le cœur, tandis que le nouveau harness d’agents conserve des API expérimentales en 0.x. L’équipe doit consigner deux choix de dépendances distincts. Installer les deux n’étend pas au harness la garantie de stabilité du cœur. Annonce du 23 octobre.

Pour une fonction délimitée, un cycle de vie simple est souvent plus facile à comprendre : une requête arrive, le modèle travaille, puis l’application traite le résultat. Un agent plus durable ajoute des questions sur les messages simultanés, la reprise, l’état enregistré et les actions qui survivent à la connexion du navigateur. Le harness offre un endroit où organiser ces préoccupations.

Le caractère expérimental est une donnée de maintenance, pas une raison de renoncer à toute expérimentation. Isolez l’évaluation du chemin critique du produit, attribuez les responsabilités et prévoyez les changements d’API. Un prototype peut montrer l’utilité de cette interaction prolongée avant que l’équipe s’engage à l’exploiter.

Si le besoin immédiat est une réponse en continu dans un écran existant, commencez là. Ajoutez l’orchestration lorsque le parcours utilisateur le nécessite. Une abstraction plus riche doit résoudre un problème concret de cycle de vie, sans devenir un préalable à chaque petite fonction d’IA.

Commencer par une interaction petite mais complète

Le guide actuel relie une route serveur, les identifiants du fournisseur et une interface propre au framework. Son exemple React utilise un appel de modèle côté serveur et une connexion SSE, avec un identifiant de conversation explicite. La clé d’API reste hors du navigateur. Démarrage rapide, consulté le 27 octobre 2026.

Pour une première évaluation, suivez cette séquence dans une branche de développement séparée. L’objectif est une interaction que l’équipe peut examiner de la requête au résultat. Il n’est pas nécessaire de migrer une infrastructure sans rapport pour savoir si l’intégration convient.

1. Choisissez un écran existant et une tâche limitée. Une question en lecture seule sur une documentation fournie est plus facile à examiner qu’un processus modifiant immédiatement les dossiers clients.
2. Installez ensemble les paquets stables de cette interface. Pour le départ React/OpenAI documenté, utilisez npm i @tanstack/ai@^1 @tanstack/ai-react@^1 @tanstack/ai-openai@^1. Versionnez le fichier de verrouillage pour identifier les versions évaluées.
3. Implémentez la frontière serveur selon le guide actuel. Gardez les secrets dans l’environnement serveur. Reliez la requête à un utilisateur authentifié et à un identifiant de conversation géré par l’application.
4. Rendez visibles le streaming, la fin et l’annulation. L’utilisateur doit savoir si la réponse arrive encore, est terminée ou a été interrompue. Conservez sa saisie en cas d’échec.
5. Exécutez la même tâche avec un second fournisseur compatible. Gardez les sources et les cas d’évaluation fixes. Notez séparément les différences de comportement et les changements d’intégration.
6. Examinez le résultat comme une fonction produit. Avant d’étendre l’intégration, regardez ce que voient les utilisateurs, les données conservées et les échecs nécessitant une intervention.

La procédure est volontairement assez petite pour être répétée. Une bonne réponse est encourageante, mais un échec compréhensible est tout aussi instructif. Une abstraction utile facilite la maintenance des deux chemins.

La migration depuis 0.x inclut les données

Le guide de migration retire les API dépréciées pendant la série 0.x et décrit les mises à jour coordonnées. Il traite séparément les conversations, exécutions et fichiers enregistrés. Une vérification de types réussie ne prouve donc qu’une partie de la préparation. Guide de migration 1.0, consulté le 27 octobre.

Ce point se perd facilement si l’application paraît saine dans une nouvelle session de navigateur. Une nouvelle conversation peut réussir alors qu’une ancienne contient un état que le nouveau client ne sait pas reprendre. La migration doit inclure des enregistrements persistants représentatifs, pas seulement de nouvelles requêtes.

Le guide distingue le renommage d’une propriété de la fourniture de sa bonne valeur. Un threadId explicite exige un véritable modèle de propriété ; une modification automatique ne peut décider comment une route ou une base identifie une conversation. De même, une option body ressemblante ailleurs dans l’API ne doit pas subir un remplacement textuel aveugle.

Utilisez le codemod documenté en aperçu, inspectez les différences et mettez à jour ensemble les paquets stables du client et du serveur. Suivez ensuite les étapes concernant les données enregistrées dans un environnement de test, avant le déploiement. Maintenez les paquets expérimentaux du harness sur leur série documentée, sans supposer que tous les paquets associés partagent la même version majeure.

La migration est terminée lorsque les conversations existantes et l’interface fonctionnent encore, en plus du nouveau code compilé.

Définissez la validation par des comportements visibles. Ouvrez une conversation existante, poursuivez-la, annulez une autre réponse et essayez une action d’outil autorisée puis une action refusée. Vérifiez que la décision d’autorisation reste liée au bon utilisateur. Les conséquences deviennent examinables sans transformer la version du SDK en note de qualité.

La portabilité est une capacité de changement entretenue

TanStack AI 1.0 propose une direction utile aux équipes qui souhaitent continuer à choisir leurs modèles et interfaces délibérément. L’adoption est particulièrement pertinente lorsqu’une frontière claire de l’application peut être simplifiée. Elle l’est moins si l’on attend d’un adaptateur qu’il efface toutes les différences de comportement.

Le véritable test arrive au deuxième changement : autre fournisseur, conversation reprise, contrat d’outil révisé ou ancien enregistrement ouvert avec un nouveau client. Rendez ces changements observables, et la portabilité devient une capacité d’exploitation plutôt qu’une promesse dans un document d’architecture.

Sources

• Annonce de TanStack AI 1.0, 23 octobre 2026.
• Démarrage rapide de TanStack AI, consulté le 27 octobre 2026.
• Migration vers 1.0, consultée le 27 octobre 2026.
• Exemple AG-UI officiel multilangage et licence MIT, examinés le 27 octobre 2026. Les scénarios et la procédure d’évaluation sont illustratifs ; aucun benchmark comparatif de fournisseurs n’a été réalisé.

Une recommandation de Telli.sh

Conservez les requêtes, les sources et les décisions derrière une intégration d’IA dans une collection consultable. Créez un compte Telli.sh pour organiser vos notes de projet et vos documents de revue.