future-agi : une plateforme unique pour tracer, évaluer et filtrer les agents LLM

Le problème visé : des outils d'observabilité qui ne se parlent pas

Le README pose le constat sans détour : les agents échouent en production, et les équipes finissent par assembler des briques d'évaluation, d'observabilité et de garde-fous qui ne referment jamais la boucle. C'est le cas typique d'un tracing qui collecte des traces que personne ne relit, à côté d'un harnais d'évaluation qui tourne sur un jeu de données figé, à côté d'un filtre de sortie qui n'a aucune idée de ce que le traceur a vu. La cible est donc l'équipe qui exploite déjà un agent en production et qui veut que chaque trace alimente la version suivante, plutôt que de recopier à la main des exemples entre trois outils.

Le périmètre revendiqué couvre six fonctions : Tracing, Evals, Simulations, Datasets, Gateway, Guardrails. Le dépôt se présente comme auto-hébergeable, avec un cœur Apache 2.0 et une offre Cloud gérée en parallèle. Pour un lecteur qui doit trancher, la question n'est pas de savoir si ces six fonctions existent quelque part sur le marché, elles existent. La question est de savoir si les réunir dans une seule pile installable en une commande vaut la dépendance supplémentaire.

Tracing, passerelle et garde-fous : ce que le dépôt décrit vraiment

Le mécanisme d'ingestion repose sur OpenTelemetry. L'exemple Python du README est explicite : on importe register depuis fi_instrumentation et OpenAIInstrumentor depuis traceai_openai, on appelle register(project_name="my-agent"), puis OpenAIInstrumentor().instrument(). Le commentaire qui suit indique que le code OpenAI existant devient tracé, sans réécriture de l'appel client.chat.completions.create. Le dépôt annonce 50+ instrumentors de frameworks, et une compatibilité HTTP au format OpenAI pour insérer ses propres composants à n'importe quelle couche.

La passerelle est un composant distinct, écrit en Go d'après la description. Le README avance des chiffres précis : environ 9,9 ns de routage pondéré, environ 29 k req/s sur une instance t3.xlarge, et un P99 inférieur ou égal à 21 ms garde-fous activés. Ces valeurs proviennent du projet lui-même, pas d'une mesure indépendante, et le README précise qu'un harnais de benchmark est committé dans le dépôt pour les reproduire. C'est la bonne façon de présenter ce genre de chiffre, mais cela reste une affirmation de l'éditeur tant que vous ne l'avez pas exécutée vous-même.

Les garde-fous se placent dans le même flux, en ligne, puisque la mesure P99 est donnée « avec guardrails on ». Le point d'architecture à retenir est donc celui-ci : la passerelle est sur le chemin critique des requêtes, et non en observation passive. Toute latence ajoutée par un garde-fou se paie directement dans le temps de réponse de l'agent.

Installation : une commande, puis un backfill à ne pas oublier

Deux chemins sont documentés. Le chemin Cloud demande une inscription sur app.futureagi.com et un pip install ai-evaluation. Le chemin auto-hébergé demande Docker Desktop ou Docker Engine avec Docker Compose disponible avant de lancer l'installeur, puis :

git clone https://github.com/future-agi/future-agi.git cd future-agi ./bin/install

Sous Windows, la variante PowerShell est .\bin\install.ps1. L'interface est ensuite servie sur http://localhost:3000. Le README précise que les images publiées sont utilisées, sans compilation depuis les sources, et que pour la production il faut passer par ./deploy/setup.sh afin de générer les secrets requis et d'épingler la version d'image. Cette distinction compte : ./bin/install vise la prise en main, ./deploy/setup.sh vise une installation que l'on assume.

Le détail le plus intéressant est la mise à jour. Si l'installation contient déjà des traces, le README indique qu'il faut initialiser explicitement les catalogues de propriétés unifiés inactifs, une fois la nouvelle pile saine, avec ./bin/property-catalog-backfill --execute (ou .\bin\property-catalog-backfill.ps1 -Execute). Le texte précise qu'un redémarrage ordinaire ne déclenche jamais de scan historique. La commande réutilise l'image déjà sélectionnée par Docker Compose, ne tire ni branche ni source, ignore les espaces de travail déjà actifs, reprend via le registre durable du catalogue, et reste bornée aux espaces et projets admis par le superviseur auto-hébergé ainsi qu'à une fenêtre glissante de 366 jours. Autrement dit : un upgrade n'est pas un simple redémarrage, et la documentation le dit clairement plutôt que de le laisser découvrir en production.

Le statut nightly est une contrainte d'exploitation, pas une mention légale

Le README ouvre sur un avertissement en tête de document : version nightly destinée aux premiers tests, aspérités attendues, version stable à venir, et invitation à ouvrir une issue en cas de problème. Ce n'est pas une clause de style. Combiné au rythme des publications visibles (v1.37.1 le 9 septembre, v1.37.0 le 9 septembre, v1.36.1 le 8 septembre), cela dessine un projet qui bouge vite et qui assume de livrer souvent. Pour une équipe, cela signifie deux choses concrètes : épingler la version d'image via ./deploy/setup.sh n'est pas optionnel, et la lecture des notes de version fait partie du coût d'exploitation.

La conséquence pratique est qu'un déploiement en production sur ce dépôt suppose une capacité à absorber des changements fréquents. Si votre organisation ne peut pas consacrer de temps à suivre les versions, l'offre Cloud gérée est le chemin que le projet lui-même met en avant comme le plus rapide. C'est un arbitrage honnête : la souveraineté des données contre la charge de mise à jour.

Un mot sur la licence. Le cœur est publié sous Apache 2.0, ce qui autorise l'usage commercial, la modification et la redistribution, avec les obligations habituelles de conservation des mentions de licence et de copyright. Le README mentionne en parallèle une offre Cloud avec des engagements SOC 2 Type II et HIPAA, et indique que les données restent dans votre région. Ces engagements portent sur le service géré, pas sur le code du dépôt. Si vous auto-hébergez, la conformité redevient votre problème. Ce paragraphe décrit la licence telle qu'elle est identifiée dans le dépôt et ne constitue pas un avis juridique.

Quand cette pile est le mauvais choix

Le cas le plus net est celui d'une équipe dont l'observabilité LLM tourne déjà en production et qui n'a pas de douleur particulière à relier traces et évaluations. Migrer l'ingestion vers un nouveau traceur OpenTelemetry, réinstrumenter les applications, puis gérer le backfill des catalogues de propriétés représente un coût réel, et le bénéfice annoncé (une boucle unique) ne se matérialise que si vous utilisez effectivement les simulations et les garde-fous. Sinon, vous déplacez une pile qui fonctionne vers une pile en nightly.

Deuxième cas : les équipes qui n'ont pas de compétence Docker Compose en interne. L'installation auto-hébergée suppose Docker Desktop ou Docker Engine avec Compose, et l'exploitation suppose de savoir épingler une image et lancer une commande de backfill bornée à 366 jours. Ce n'est pas insurmontable, mais ce n'est pas un simple pip install non plus.

Troisième cas, plus subtil : si votre besoin principal est l'analyse hors ligne de traces déjà collectées, la passerelle sur le chemin critique n'apporte rien et ajoute un composant à maintenir. Le P99 annoncé avec garde-fous activés reste une latence ajoutée à chaque requête, quelle que soit sa valeur exacte.

Face à une pile assemblée à la main

L'alternative la plus courante n'est pas un produit unique, c'est une combinaison. Le README cite lui-même les briques qu'il prétend remplacer : Langfuse pour l'observabilité, Braintrust pour l'évaluation, Helicone pour la passerelle, Guardrails AI pour les filtres, plus un simulateur maison. La différence d'approche est structurelle. Dans une pile assemblée, chaque outil a son propre modèle de données, son propre format de trace et son propre mode d'authentification. Vous écrivez la glue, et cette glue est ce qui casse en premier lors d'une montée de version d'un des composants.

future-agi propose l'inverse : un seul modèle de données partagé par le tracing, les évaluations, les simulations et les garde-fous, avec OpenTelemetry comme format d'entrée et une compatibilité HTTP au format OpenAI pour les composants que vous voulez garder. Le coût de cette unification est la dépendance à un seul projet pour toute la chaîne. Si un composant ne vous convient pas, vous ne remplacez pas une brique, vous contournez une partie de la plateforme.

Il faut noter que le README cite ces alternatives par leur nom, ce qui est un choix éditorial assumé. Cela ne prouve rien sur la supériorité de l'approche unifiée, et le projet ne fournit pas de comparatif chiffré face à ces outils. C'est à vous de mesurer, sur vos propres traces, si la boucle se referme plus vite.

Coût de maintenance et prochaine étape concrète

Le coût de maintenance se lit dans trois signaux du dépôt. Le rythme de publication est élevé, avec trois versions en deux jours sur la fenêtre visible. Le statut nightly est annoncé en tête de README. Et l'upgrade comporte une étape explicite, ./bin/property-catalog-backfill --execute, à lancer après que la pile est saine, avec une reprise via un registre durable et une fenêtre source de 366 jours. Ce dernier point est rassurant sur la conception : la commande est idempotente par construction, ignore les espaces déjà actifs et ne rescanne pas l'historique à chaque redémarrage. Mais elle existe parce que le schéma a évolué, et c'est le genre d'étape qui se retrouve dans un runbook.

Le paquet ai-evaluation publié sur PyPI est un point à vérifier séparément : le README l'installe pour le chemin Cloud, et le badge PyPI du dépôt pointe vers ce paquet. Rien dans le matériel fourni ne garantit que sa version corresponde à celle de la pile auto-hébergée que vous déployez.

La prochaine étape utile n'est donc pas une évaluation théorique. Clonez le dépôt, lancez ./bin/install, ouvrez http://localhost:3000, instrumentez un appel OpenAI avec register et OpenAIInstrumentor, et regardez si la trace apparaît avec le niveau de détail dont votre équipe a besoin pour déboguer. Si la réponse est non, aucune des cinq autres fonctions ne compensera.

Conclusion éditoriale

À adopter si vous voulez une seule boucle trace, évaluation, garde-fou, sur votre propre infrastructure, et si vous acceptez de suivre des versions nightly. À éviter si votre équipe a déjà une pile d'observabilité en production et ne veut pas migrer son ingestion. Vérifiez d'abord trois points : que ./bin/install démarre bien la pile complète sur votre machine, que la commande ./bin/property-catalog-backfill --execute est nécessaire pour vos données existantes, et que le paquet ai-evaluation sur PyPI correspond à la version que vous comptez exploiter.

Sources officielles

1. future-agi/future-agi on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases