Rivet : graphes d'agents IA dans une app de bureau, exécutables depuis TypeScript

Le problème : un enchaînement de prompts qui vit dans du code

Dès qu'une application enchaîne plusieurs appels de modèle, la logique se retrouve dispersée dans des fonctions asynchrones. Modifier l'ordre des étapes, insérer une étape de récupération ou changer le modèle d'une seule étape demande une revue de code, un test et un déploiement. Rivet prend le problème par l'autre bout : l'enchaînement devient un graphe que l'on dessine, et le code ne fait plus qu'appeler ce graphe. Le README présente Rivet comme un IDE pour créer des agents IA complexes et du chaînage de prompts, puis l'intégrer dans une application. Le public visé est donc double. D'un côté une personne qui itère sur la structure d'un prompt sans vouloir toucher à TypeScript. De l'autre un développeur qui veut que son service expose des fonctions appelables depuis le graphe, et réciproquement. Rivet n'est pas une bibliothèque d'appels HTTP vers un fournisseur de modèles : c'est un format d'exécution, avec un éditeur pour le produire.

Deux artefacts distincts : l'application et le coeur TypeScript

Le dépôt sépare nettement l'application Rivet et Rivet Core. L'application est un logiciel de bureau distribué en binaires pour macOS, Linux (AppImage) et Windows, avec des liens de téléchargement directs dans le README. Rivet Core est une bibliothèque TypeScript destinée à exécuter les graphes créés dans l'application. Le README précise qu'elle est utilisée par l'application elle-même, ce qui signifie que l'éditeur et le moteur d'exécution partagent le même code : un graphe qui s'exécute dans l'IDE devrait s'exécuter de la même façon côté serveur, tant que les versions concordent. C'est un argument de cohérence, pas une garantie. Les deux paquets publiés sur NPM sont @ironclad/rivet-core et @ironclad/rivet-node. Le second est la variante orientée Node, à privilégier si vous exécutez le graphe dans un service. La documentation d'intégration se trouve sur le site du projet, sous une page intitulée Rivet Integration Getting Started, et les références d'API sont hébergées au même endroit. Le dépôt ne contient pas ces pages : c'est une limite pratique, puisque le README renvoie vers un site externe pour tout ce qui dépasse l'installation.

Le graphe comme contrat entre l'IDE et votre service

Le mécanisme décrit dans le README est une inversion d'appel dans les deux sens. Rivet peut appeler du code de votre application, et votre application peut appeler des graphes Rivet. Concrètement, cela veut dire que le graphe n'est pas un script autonome : il attend des fonctions hôtes pour les parties qui ne relèvent pas du modèle, et il expose des points d'entrée que votre code déclenche. Cette architecture a une conséquence directe sur le déploiement. Un graphe modifié dans l'application de bureau ne suffit pas à changer le comportement en production : il faut que le fichier de graphe soit livré avec le service, et que le service soit redémarré ou recharge le fichier. Le README ne détaille pas de mécanisme de rechargement à chaud, et je ne peux pas affirmer qu'il en existe un. Ce qu'on peut dire, c'est que le format de graphe devient un artefact versionné au même titre qu'un fichier de configuration, avec les questions habituelles : qui le modifie, comment il est relu, et comment on détecte qu'un graphe en production ne correspond plus à ce qui a été validé dans l'éditeur.

Intégrations documentées : modèles, embeddings, voix

Le README énumère le support LLM : OpenAI GPT-3.5 et GPT-4, Anthropic Claude Instant et Claude 2, la famille Claude 3 (Haiku, Sonnet, Opus), et le framework LeMUR d'AssemblyAI pour les données vocales. Côté embeddings et base vectorielle, il cite OpenAI Embeddings et Pinecone. Il ajoute la transcription parole vers texte d'AssemblyAI. Cette liste est ce qu'elle est : une liste de fournisseurs pris en charge, pas une promesse de parité de fonctionnalités entre eux. Un point mérite attention : les modèles nommés dans le README, notamment GPT-3.5 et Claude 2, sont anciens par rapport à la date des dernières publications du dépôt. Cela ne veut pas dire que les modèles récents ne sont pas utilisables, mais le README n'est pas la source à jour sur ce sujet. Si votre choix de modèle dépend d'une version précise, vérifiez la liste dans l'application ou dans la documentation du site avant de vous engager. Un outil d'orchestration dont la liste de modèles vieillit dans le README demande une vérification active, pas une lecture unique.

Installation : binaires, sources, et ce qui manque

Pour l'application, le chemin le plus court est le binaire. Le README fournit quatre liens de téléchargement : Rivet.dmg pour macOS, Rivet.AppImage pour Linux, un second Rivet.dmg listé pour Linux, et Rivet-Setup.exe pour Windows. La présence de deux entrées dmg dont une étiquetée Linux est une incohérence du README, à traiter comme telle : sur Linux, prenez l'AppImage. Pour exécuter des graphes dans votre propre code, l'installation passe par NPM avec les paquets @ironclad/rivet-core et @ironclad/rivet-node. Le README ne donne pas de commande d'installation ni d'exemple de code d'appel : il renvoie à la page Rivet Integration Getting Started. C'est une lacune réelle pour un lecteur qui veut évaluer l'API en dix minutes. Ce que le README établit, c'est l'existence des paquets et leur rôle respectif. La compilation depuis les sources est traitée dans CONTRIBUTING.md, que le README mentionne sans en reprendre le contenu. Si vous comptez modifier l'application elle-même, ce fichier est votre point d'entrée obligatoire.

La limite structurelle : un format de graphe propre à l'outil

Le point faible le plus net n'est pas technique, il est stratégique. Un graphe Rivet est un fichier produit par une application de bureau. Votre orchestration devient dépendante d'un format que vous ne contrôlez pas, et dont l'évolution suit le rythme de publication du projet. Les versions récentes montrent deux trains séparés : app-v1.11.3 pour l'IDE et v1.25.0 pour les bibliothèques. Deux numérotations distinctes signifient que la compatibilité entre un graphe enregistré par une version de l'IDE et une version donnée de @ironclad/rivet-core n'est pas garantie par construction. C'est le risque opérationnel à surveiller en premier. Deuxième cas où Rivet est le mauvais outil : si votre équipe écrit déjà son orchestration en Python, adopter Rivet impose soit un service TypeScript supplémentaire, soit une réécriture, parce que le coeur est une bibliothèque TypeScript. Troisième cas : si votre enchaînement tient en trois appels séquentiels, l'éditeur graphique ajoute une couche d'indirection et un fichier à versionner sans rien simplifier.

Face à une orchestration écrite à la main

L'alternative la plus fréquente n'est pas un autre produit, c'est du code : des fonctions TypeScript ou Python qui appellent les modèles dans l'ordre, avec les paramètres en clair. La différence d'approche est nette. Dans du code, la structure de l'enchaînement est noyée dans la syntaxe : pour voir l'ordre des étapes, il faut lire le fichier. Dans Rivet, la structure est l'artefact principal, et le code hôte ne fournit que les fonctions périphériques. Le compromis suit cette différence. Le code à la main se teste avec les outils habituels, se relit en diff, et ne dépend d'aucun format externe. Le graphe se modifie sans redéploiement logique, se montre à quelqu'un qui ne lit pas TypeScript, mais introduit un fichier binaire ou semi-structuré dans le dépôt et un couplage à la version de l'IDE. Il n'y a pas de réponse universelle : si la valeur de votre produit réside dans la structure de l'enchaînement et qu'elle change souvent, le graphe se défend. Si elle réside dans la logique métier autour des appels, le graphe déplace la complexité sans la réduire.

Maintenance, licence et coût de mise à jour

Le dépôt est sous licence MIT, ce qui autorise l'usage commercial, la modification et la redistribution, à condition de conserver l'avis de licence et de copyright. Ce n'est pas un avis juridique : pour un usage en entreprise, faites relire le fichier LICENSE et vérifiez les licences des dépendances, que le README ne liste pas. Le projet n'est pas archivé et la dernière poussée sur la branche main est datée du 26 août 2026, ce qui indique une activité continue. Le coût de maintenance se répartit en deux postes. Le premier est la mise à jour de l'IDE, qui suit son propre calendrier de versions. Le second est la mise à jour des paquets NPM, qui suit un autre calendrier. Ces deux calendriers doivent rester alignés sur les graphes que vous exécutez, sinon vous vous exposez à un graphe lisible dans l'éditeur mais refusé à l'exécution, ou l'inverse. Le README ne décrit pas de politique de compatibilité entre les deux trains de versions. La contribution passe par CONTRIBUTING.md et un CODE_OF_CONDUCT.md, et le canal d'entraide cité est le serveur Discord du projet.

Conclusion éditoriale

Rivet convient aux équipes qui veulent concevoir et modifier un enchaînement de prompts sans redéployer du code, tout en gardant l'exécution dans un service TypeScript via @ironclad/rivet-core et @ironclad/rivet-node. Il ne convient pas si votre orchestration est déjà écrite en Python, si vous refusez un format de graphe propre à un outil, ou si vous avez besoin d'une garantie de compatibilité entre versions de fichiers. Avant d'adopter, ouvrez un fichier .rivet de votre côté, vérifiez quelles clés d'environnement vos noeuds réclament, puis confirmez que la version de @ironclad/rivet-core installée sait lire ce fichier : c'est le point de rupture le plus probable entre l'IDE et la bibliothèque.

Sources officielles

1. Ironclad/rivet on GitHub
2. License: MIT
3. Project website
4. README
5. Releases