Tracely-ai : quand une trace de production devient un test de régression qui bloque la pull request

Le problème : un tableau de bord ne bloque aucune pull request

L'argument du README tient en une phrase : l'observabilité s'arrête au tableau de bord. On constate qu'un agent a cassé, puis on ne fait rien de mécanique avec cette information. Les outils d'évaluation classiques exigent, selon la formulation du projet, que l'on rédige un jeu de données à la main : inventer des questions, écrire des réponses idéales, les maintenir à jour. Ce jeu de données est une hypothèse sur ce qui pourrait casser. Tracely prend le problème par l'autre bout. La trace de l'exécution qui a échoué contient déjà l'entrée exacte, les appels d'outils exacts et les réponses du modèle. Le README résume cette position par une formule courte : la trace enregistrée est le test. Le public visé est donc précis : des équipes qui ont déjà un agent en production, qui reçoivent des traces, et qui veulent qu'une régression connue fasse échouer la CI plutôt que d'apparaître comme une courbe sur un écran. Si votre agent n'a pas encore d'utilisateurs, l'outil n'a rien à geler.

Ce que le pipeline fait réellement, étape par étape

Le trajet décrit dans le README est une chaîne : trace de production, détection d'échec, test de régression, barrière CI, alerte. Les traces arrivent en OTLP simple. La sémantique d'agent (agent.id, conversation.id, turn, step) est promue en colonnes indexées de premier ordre, ce qui permet de regrouper les exécutions en fils de conversation plutôt qu'en une soupe de spans à plat. Des évaluateurs en ligne notent chaque exécution à son arrivée, à trois niveaux possibles : conversation, exécution, span. Le README mentionne deux familles : le LLM-as-judge et des contrôles structurels qui ne nécessitent aucun modèle. Les échecs sont ensuite regroupés, structurellement et sémantiquement, de sorte que trente et une exécutions cassées deviennent une seule issue avec un compteur. Chaque groupe peut suggérer l'évaluateur qui l'aurait attrapé. La promotion d'une trace en cas hermétique embarque l'entrée enregistrée et les sorties d'outils et de modèle comme fixtures, avec un contrat fail-to-pass : le cas doit échouer sur l'ancien code et passer sur le correctif, sinon la promotion n'est pas considérée comme fiable. Le rejeu en CI s'appuie sur ces fixtures, donc hors ligne, sans clé API et sans dépense de modèle.

Le contrat fail-to-pass est la partie qui mérite le plus d'attention

Beaucoup d'outils savent figer une trace. Peu vérifient que le cas ainsi créé mesure quelque chose. Tracely attache à chaque promotion un contrat fail-to-pass et refuse de faire confiance à une promotion qui ne le respecte pas. C'est un choix de conception qui a un coût : un cas dont l'échec d'origine ne se reproduit pas, par exemple parce qu'il dépendait d'un état externe ou d'une réponse de modèle non déterministe capturée par chance, sera rejeté au moment de la promotion. Le README ne détaille pas la procédure de validation, ni le nombre de tentatives, ni la façon dont les cas limites sont traités. C'est une zone d'ombre assumée. Pour le comportement multi-tours, le projet propose des scénarios : soit une conversation scriptée, soit un objectif adverse qu'un modèle de red team improvise. Cette seconde option introduit un modèle génératif dans la fabrication du test, mais pas dans son rejeu, puisque celui-ci reste adossé aux fixtures. La distinction est importante : le coût et la variabilité se situent au moment de la création du cas, pas à chaque pull request.

Mise en route : OTLP en entrée, tracely gate en sortie

Le README ne fournit pas de bloc d'installation complet dans l'extrait disponible, mais il expose les points d'entrée. Côté ingestion, les traces arrivent en OTLP simple, ce qui signifie que l'instrumentation se fait avec les bibliothèques OpenTelemetry existantes et que Tracely se place en aval comme collecteur. Côté CI, la commande est tracely gate : elle sort avec un code non nul, publie un commit status et met à jour un commentaire de pull request. C'est cette commande que votre workflow doit appeler, et c'est son code de sortie qui bloque la fusion. Le déploiement complet se fait via un bouton Railway qui instancie API, worker, UI, Postgres, ClickHouse, Redis et MinIO. La pile est donc lourde : ClickHouse pour les colonnes de traces, Redis et MinIO en complément. Sur PyPI, le paquet s'appelle tracely-ai et la version de Python requise est 3.10 ou supérieure, d'après les badges du dépôt. Aucune version publiée n'apparaît dans les données de release fournies, ce qui empêche de juger la cadence de publication. Le dépôt est actif (dernier push en septembre 2026) et non archivé.

Le coût de rejeu nul ne veut pas dire coût d'exploitation nul

L'argument du rejeu à zéro dollar est solide sur le principe : les fixtures enregistrées remplacent les appels de modèle, donc la suite est déterministe et hors ligne. Mais ce zéro concerne le rejeu, pas l'ensemble. L'évaluation en ligne qui note chaque exécution à son arrivée consomme des appels de modèle, puisque le LLM-as-judge en fait partie. Le regroupement des échecs, la suggestion d'évaluateurs et la génération de scénarios adverses sont également des opérations qui s'exécutent en amont de la CI. Autrement dit, la dépense se déplace du moment de la pull request vers le moment de l'observation. Une équipe qui reçoit beaucoup de trafic doit dimensionner ClickHouse et anticiper le volume d'évaluations. Le README ne donne aucun ordre de grandeur sur ce point, et je ne peux pas en inventer. La licence MIT, elle, est permissive : pas de copyleft, pas de contrainte de redistribution au-delà de la conservation de l'avis de licence. Elle ne dit rien du service hébergé sur tracely-ai.com, qui relève d'un autre cadre.

Les cas où l'outil est le mauvais choix

Tracely suppose un flux de traces existant. Sans production instrumentée en OTLP, il n'y a ni échec à détecter, ni trace à geler, et l'outil se réduit à une pile de services à maintenir. Il suppose aussi une CI qui accepte un code de sortie non nul comme signal de blocage : dans une organisation où la fusion reste possible malgré un statut rouge, tracely gate publiera un commentaire que personne ne lira. Troisième limite, plus structurelle : le rejeu hermétique fige les sorties d'outils. Si votre agent dépend d'une API dont le comportement change légitimement, le cas enregistré continuera de valider l'ancien comportement. Le test protège contre la régression du code, pas contre la dérive d'une dépendance externe. Enfin, la barrière de validation fail-to-pass, présentée comme un gage de confiance, écarte par construction les échecs difficiles à reproduire de façon déterministe. Ce sont souvent les plus intéressants, et ils resteront dans le tableau de bord.

Face à Langfuse ou Phoenix : la différence n'est pas la trace, c'est la barrière

Les plateformes d'observabilité pour LLM, comme Langfuse ou Arize Phoenix, partagent une grande partie de la couche amont avec Tracely : ingestion OTLP, regroupement en fils, évaluateurs, tableaux de bord. La différence se situe en aval. Ces outils exposent des métriques et des scores, et la décision de bloquer une fusion reste à construire à la main, généralement en écrivant soi-même un script d'évaluation qui interroge leur API. Tracely fournit la commande de barrière et le cycle de promotion trace vers cas. L'échange est net : vous gagnez un chemin prêt à l'emploi entre un échec observé et un blocage de PR, vous perdez la neutralité d'un outil qui se contente de stocker et d'afficher. Un tableau de bord Langfuse reste utile même si vous n'avez pas de CI ; Tracely, sans CI, n'a plus de fonction principale. À l'inverse, si votre besoin est d'explorer des traces et de comparer des modèles, la couche de test imposée par Tracely ajoute des concepts (contrat fail-to-pass, scénarios, fixtures) dont vous n'aurez pas l'usage.

Maintenance, montée de version et ce qu'il reste à vérifier

La pile auto-hébergée compte sept composants : API, worker, UI, Postgres, ClickHouse, Redis, MinIO. Chacun a son propre cycle de mise à jour et ses propres sauvegardes à prévoir. Le README ne documente pas de politique de migration de schéma, et l'absence de releases publiées dans les données fournies empêche de savoir à quel rythme les changements incompatibles arrivent. C'est un point à éclaircir avant de s'engager : demandez comment le schéma ClickHouse évolue entre deux versions. Le paquet Python tracely-ai et la pile serveur doivent rester compatibles, ce qui ajoute une contrainte de versionnement. Sur le plan juridique, la licence MIT du dépôt couvre le code, mais je ne peux pas me prononcer sur les conditions du service hébergé ni sur le traitement des traces que vous y envoyez, qui contiennent potentiellement des entrées utilisateurs. Ce dernier point mérite une vérification directe, pas une déduction depuis le README.

Conclusion éditoriale

Tracely-ai convient aux équipes qui exploitent déjà un agent en production et qui possèdent une CI capable de lancer une commande Python échouant avec un code non nul. Il ne convient pas à celles qui cherchent un outil de prototypage, ni à celles qui n'ont pas encore de trafic réel à observer. Avant d'adopter, vérifiez deux points précis : que vos traces OTLP portent bien les attributs agent.id, conversation.id, turn et step, et que la commande tracely gate s'exécute sur un runner sans accès aux fournisseurs de modèles.

Sources officielles

1. Issues
2. Jwuthri/Tracely-ai on GitHub
3. License: MIT
4. Project website
5. README