rig : une couche Rust unifiée pour les modèles, les outils et les agents
⚙️🦀 Build modular and scalable LLM Applications in Rust
En bref
- De quoi s’agit-il ?
- rig est une bibliothèque Rust qui place tous les fournisseurs de LLM derrière une interface unique et sépare les contrats portables de l'orchestration des agents. Le projet est en mouvement rapide et l'assume par écrit.
- À qui s’adresse-t-il ?
- rig convient aux équipes déjà en Rust qui veulent une abstraction fournisseur unique, des outils typés et un état d'exécution sérialisable, et qui acceptent de suivre des versions majeures fréquentes. Il ne convient pas à qui a besoin d'une API figée sur plusieurs années, ni à un projet WASI ou reposant sur MCP dans le navigateur, puisque la documentation indique que ces combinaisons ne sont pas prises en charge.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Le dépôt a reçu de nouveaux commits au cours des dernières 24 heures.
- En quel langage est-il écrit ?
- Principalement Rust, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : réécrire la même glue à chaque changement de fournisseur
Une application qui appelle un LLM finit par accumuler du code qui ne dépend d'aucun modèle en particulier : format des messages, appels d'outils, embeddings, mémoire, récupération dans un magasin vectoriel. Ce code est ensuite dupliqué pour chaque fournisseur, avec des différences de nommage et de types. rig se présente comme une bibliothèque Rust qui ramène ces fournisseurs sous une interface unique. La cible est l'ingénieur qui écrit une application Rust et veut changer de modèle sans réécrire la couche d'appel, ou qui veut brancher plusieurs fournisseurs dans le même binaire. Le README annonce plus de vingt fournisseurs de modèles et plus de dix intégrations de magasins vectoriels derrière une interface unique, ainsi que la complétion, les embeddings, la transcription, la génération audio et la génération d'images. C'est un périmètre large, et c'est justement ce qui rend la stabilité de l'API sensible.
Deux crates, un seul point d'entrée
La séparation annoncée dans le README est nette. rig-core contient les messages neutres vis-à-vis du fournisseur, les modèles de complétion, les outils portables, la mémoire, les contrats de magasin vectoriel et les correspondances vers les fournisseurs intégrés. rig-agent contient le constructeur classique, les traits de prompt et de streaming, les hooks typés, les outils contextuels, l'extraction et la machine à états AgentRun, décrite comme sérialisable. Le crate racine rig réexporte les deux aux chemins habituels, donc la plupart du code ne dépend que de rig. L'intérêt de cette découpe est concret : la partie portable compile pour wasm32-unknown-unknown, tandis que l'orchestration d'agent reste un choix activé par défaut. Le README précise aussi que les implémentations WASI ne sont pas prises en charge et que rig-rmcp, donc MCP, est réservé au natif. Ce sont des frontières de compilation, pas des détails de documentation.
Ce que l'on écrit réellement dans le code
Le README ne déroule pas un exemple complet, il renvoie à la documentation du site et à la référence d'API sur docs.rs pour le détail. Ce que le matériel confirme, ce sont les briques exposées : un constructeur d'agent, des traits de prompt et de streaming, des hooks typés, des outils contextuels, l'extraction, et un AgentRun sérialisable. Le point de vue à retenir porte sur AgentRun. Un état d'exécution sérialisable permet de suspendre un run, de le stocker et de le reprendre, ce qui est la condition pour un agent qui survit à un redémarrage de processus. En contrepartie, tout ce que l'agent transporte doit être sérialisable, et cette contrainte remonte dans les types que vous définissez pour vos outils. La documentation ne détaille pas le coût de cette contrainte, et c'est un manque réel quand on conçoit des outils qui capturent des handles de connexion ou des closures.
Installation et clés de configuration
L'installation passe par le registre de crates, avec un ajout de dépendance sur rig. L'activation ou la désactivation du runtime d'agent se fait par fonctionnalités de crate, puisque rig-agent est activé par défaut et que le README parle explicitement de fonctionnalités à ce sujet. Les fournisseurs se configurent par variables d'environnement, comme le veut l'usage, mais le matériel fourni ne nomme aucune de ces variables et je ne peux donc pas en citer une seule sans inventer. De même, la documentation ne donne pas ici de clé de configuration de magasin vectoriel. Pour l'observabilité, le README annonce la compatibilité avec les conventions sémantiques GenAI d'OpenTelemetry, ce qui implique un exporteur OTLP à configurer côté application, mais les noms de variables d'environnement correspondants ne figurent pas dans le matériel. Ces trois points (fonctionnalités de crate, variables de fournisseur, exporteur de télémétrie) sont à relever dans la documentation avant d'écrire la première ligne.
La stabilité, revendiquée comme un chantier en cours
Le README ouvre sur un avertissement qui ne laisse aucune place au doute : les futures mises à jour contiendront des changements cassants, et les chemins de migration seront annotés au fur et à mesure. Ce n'est pas une clause de style. Les versions publiées montrent un rythme soutenu, avec v0.40.0 en juillet 2026, v0.41.0 fin juillet et v0.42.0 en août 2026, et la branche par défaut a reçu des commits après cette dernière publication. Autrement dit, le numéro mineur bouge vite et le contrat d'API avec lui. Pour une bibliothèque qui occupe la couche d'appel de tous vos modèles, c'est le coût principal : chaque montée de version demande de relire les notes et de suivre les migrations. Le projet est explicite là-dessus, ce qui vaut mieux qu'un silence, mais cela reste un engagement de suivi à budgéter. Une équipe qui ne peut pas absorber une montée de version tous les mois ou deux n'a pas ici un socle tranquille.
Les cas où rig n'est pas le bon outil
Trois limites ressortent du matériel. D'abord la cible : le noyau portable et le runtime classique compilent pour wasm32-unknown-unknown, mais WASI n'est pas pris en charge, et rig-rmcp ainsi que MCP sont réservés au natif. Un service serveur compilé en WASI, ou un agent qui doit parler MCP depuis un navigateur, sort du périmètre annoncé. Ensuite le langage : rig est une bibliothèque Rust, et une équipe qui écrit son produit en Python ou en TypeScript n'a aucune raison d'ajouter une frontière Rust pour appeler un modèle. Enfin la stabilité, traitée plus haut. À cela s'ajoute un point que le README ne tranche pas : la sérialisation d'AgentRun impose des contraintes aux types d'outils, sans que le coût soit documenté. Si vos outils manipulent des ressources non sérialisables, il faut vérifier ce point avant de bâtir dessus.
Face à une couche d'abstraction écrite maison
L'alternative la plus fréquente n'est pas une autre bibliothèque, c'est un module d'appel écrit dans le projet, avec un enum de fournisseurs et un client HTTP par fournisseur. La différence porte sur trois points précis. Une abstraction maison ne couvre que les fournisseurs que vous avez écrits, alors que rig annonce plus de vingt fournisseurs et plus de dix magasins vectoriels derrière une interface unique. Elle ne fournit ni AgentRun sérialisable, ni hooks typés, ni outils contextuels, ni l'extraction, qui sont des composants de rig-agent. Elle ne fournit pas non plus la compatibilité avec les conventions sémantiques GenAI d'OpenTelemetry, qui donne un format de traces commun entre fournisseurs. En contrepartie, une abstraction maison ne casse pas quand une version mineure sort, et elle ne vous oblige pas à faire entrer vos outils dans un moule sérialisable. Le choix se joue donc entre le coût d'écriture initial et le coût de suivi des montées de version, pas entre une solution complète et une solution incomplète.
Maintenance, licence et coût de montée de version
La licence est MIT, indiquée dans le dépôt et reprise par le badge de crates.io. Comme pour toute bibliothèque MIT, l'intégration dans un produit propriétaire ne pose pas de question de contamination, mais je ne donne pas d'avis juridique : la mention de copyright et le texte de licence doivent être conservés, et un service juridique vérifiera les obligations exactes. Côté maintenance, le dépôt n'est pas archivé, la branche par défaut reçoit des commits, et les publications s'enchaînent à un rythme mensuel ou presque. Le coût réel pour l'adoptant n'est donc pas l'installation, c'est le suivi : lire chaque note de version, appliquer les migrations annotées, et retester les chemins d'appel des fournisseurs que vous utilisez. Un projet qui ne peut pas consacrer ce temps doit soit figer une version et assumer le retard, soit rester sur son abstraction maison. Le README cite par ailleurs des utilisateurs en production, dont St Jude pour un outil de visualisation génomique, Coral Protocol dans un SDK, ilert dans un proxy LLM multi-fournisseurs et Archestra dans un banc d'essai d'agents. Ces mentions indiquent des usages réels, pas une garantie de stabilité d'API.
Conclusion éditoriale
rig convient aux équipes déjà en Rust qui veulent une abstraction fournisseur unique, des outils typés et un état d'exécution sérialisable, et qui acceptent de suivre des versions majeures fréquentes. Il ne convient pas à qui a besoin d'une API figée sur plusieurs années, ni à un projet WASI ou reposant sur MCP dans le navigateur, puisque la documentation indique que ces combinaisons ne sont pas prises en charge. Avant d'adopter, vérifiez la matrice de cibles de crates/rig-agent/README.md, puis lisez la note de version de v0.42.0 et le commit de migration associé pour mesurer l'écart avec l'API que vous visez.
Notes de la communauté