LangWatch : évaluer et simuler des agents LLM sans recoller les outils soi-même
The platform for LLM evaluations and AI agent testing
En bref
- De quoi s’agit-il ?
- LangWatch regroupe traces, jeux de données, évaluations hors ligne, simulation d'agents et gestion de prompts dans une même plateforme, distribuée en open core Apache-2.0. Le point à trancher avant de l'adopter n'est pas la liste des fonctionnalités, mais l'endroit où tournent vos données et le coût réel de l'auto-hébergement.
- À qui s’adresse-t-il ?
- LangWatch convient aux équipes qui ont déjà des agents en production et veulent relier traces, jeux de données et évaluations dans un même outil, y compris sur leur propre infrastructure. Il convient mal à qui cherche uniquement une bibliothèque d'évaluation légère à importer dans un notebook, ou refuse d'exploiter PostgreSQL, Redis et ClickHouse.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 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 TypeScript, 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 : recoller traces, jeux de données et évaluations à la main
Une équipe qui met un agent en production finit presque toujours par assembler trois briques séparées : un outil pour capturer les traces, un script pour transformer ces traces en jeu de données, et un troisième pour lancer les évaluations. Le README de LangWatch décrit précisément cette boucle comme son argument central : tracer, constituer un jeu de données, évaluer, optimiser les prompts ou les modèles, puis retester, le tout sans code de liaison. La cible annoncée est explicite : des équipes qui ont besoin de tests de non-régression, de simulations et d'observabilité en production sans construire leur propre outillage.
Le projet ne se présente donc pas comme une bibliothèque d'évaluation de plus, mais comme l'endroit où ces étapes se rejoignent. C'est un choix de positionnement qui a un coût : pour bénéficier de la boucle complète, il faut accepter d'exploiter une plateforme, avec les bases de données qui vont avec, et pas seulement un paquet installé dans un environnement virtuel.
OpenTelemetry comme colonne vertébrale, pas comme option
LangWatch se décrit comme natif OpenTelemetry et OTLP, agnostique vis-à-vis des frameworks et des fournisseurs de modèles. Concrètement, cela veut dire que l'instrumentation ne passe pas par un SDK propriétaire obligatoire : vos applications émettent des spans OTLP, et la plateforme les ingère. Les SDK Python et TypeScript existent (le README affiche les paquets langwatch sur PyPI et npm, et les notes de version mentionnent typescript-sdk@v1.13.0 ainsi qu'un SDK Go en v1.0.0), mais l'approche par standard ouvert laisse la porte à d'autres émetteurs OTLP.
C'est un point qui compte au moment de l'adoption : si vous instrumentez déjà vos services avec OpenTelemetry, l'intégration ne vous demande pas de réécrire votre couche de télémétrie. Si, à l'inverse, vous attendiez un SDK qui capture automatiquement les appels LLM sans rien configurer, la documentation d'intégration est l'endroit à lire avant de vous décider, car le README renvoie vers docs.langwatch.ai plutôt que de détailler le format attendu.
Ce que npx @langwatch/server installe réellement sur votre machine
L'installation locale tient en une commande, selon le README : npx @langwatch/server. Derrière cette ligne, la CLI installe uv, PostgreSQL, Redis, ClickHouse, le binaire de la passerelle IA et le runtime de l'assistant Langy dans ~/.langwatch/, génère un fichier .env avec des secrets locaux, démarre les services en parallèle et ouvre http://localhost:5560. La remise à zéro consiste à supprimer ~/.langwatch.
Trois variables de ce fichier ~/.langwatch/.env méritent d'être lues avant le premier lancement. LANGWATCH_ENABLE_LANGY vaut true par défaut : l'assistant ajoute environ 45 Mo de runtime, et le README précise que ses workers tournent sans sandbox, sous votre compte, sur votre machine. LANGWATCH_ENABLE_PRESIDIO vaut false et ajoute environ 670 Mo de modèle de langue pour l'évaluateur de détection de données personnelles. LANGWATCH_ENABLE_LINGUA vaut false et ajoute environ 95 Mo pour la détection de langue. Tous les autres évaluateurs sont installés dans les deux cas.
Pour une exécution conteneurisée, le README donne la séquence suivante : cloner le dépôt, se placer dans platform/app, copier platform/app/.env.example vers platform/app/.env, puis lancer docker compose up -d --wait --build. Le développement local sans Docker passe par docker compose up redis postgres opensearch, puis make install et make start.
La passerelle IA : un binaire Go séparé, avec ses propres chiffres
La gouvernance des coûts est traitée par un composant distinct : une passerelle compatible avec les API OpenAI et Anthropic, avec clés virtuelles, budgets hiérarchiques, garde-fous en ligne, bascule automatique entre fournisseurs et transmission du cache_control d'Anthropic. Le README indique qu'elle est livrée sous forme de binaire Go dans services/aigateway/ et de sous-chart Helm dans charts/gateway/, et annonce environ 700 ns de surcharge sur le chemin critique.
Ce chiffre vient de la documentation du projet, pas d'une mesure indépendante, et il faudrait le confronter à votre propre trafic avant d'en tirer une conclusion. Le point structurel reste : la passerelle n'est pas noyée dans l'application TypeScript, elle se déploie séparément. Cela simplifie le dimensionnement, mais ajoute une pièce à superviser dans une installation Kubernetes.
Là où le bât blesse : données, poids et périmètre de licence
Le badge de licence affiché par le dépôt indique Apache 2.0 plus Enterprise, et le texte alternatif de ce badge parle d'un socle Apache 2.0 avec extension Enterprise. Le dépôt GitHub, lui, est classé Apache-2.0. Cette divergence n'est pas anodine : avant de bâtir un produit dessus, il faut identifier dans le dépôt quels répertoires relèvent de l'extension Enterprise et lesquels restent sous Apache-2.0. Le matériel fourni ne permet pas de trancher, et je ne vais pas inventer une répartition.
Deuxième contrainte, plus prosaïque : la plateforme repose sur PostgreSQL, Redis et ClickHouse. Le mode npx les installe pour vous, mais en production c'est vous qui les exploitez, les sauvegardez et les mettez à jour. ClickHouse en particulier n'est pas une base que l'on ajoute par inadvertance à un existant.
Troisième point, l'assistant Langy. Le README est franc : ses workers tournent sans sandbox, sous votre compte. Sur un poste de développement, c'est un compromis acceptable si vous le savez. Sur une machine qui héberge autre chose, désactiver LANGWATCH_ENABLE_LANGY dans ~/.langwatch/.env avant le premier démarrage est la mesure la plus simple. Enfin, si votre besoin se limite à calculer une métrique sur une liste de réponses dans un notebook, une plateforme complète est un détour inutile : les évaluateurs hors ligne de LangWatch supposent un projet, des traces et une base de données.
Face à Langfuse : même socle OTLP, arbitrage différent
Langfuse est l'alternative la plus directement comparable, et la différence ne se joue pas sur la présence d'OpenTelemetry, que les deux revendiquent. Elle se joue sur ce qui entoure l'observabilité. LangWatch met en avant les simulations d'agents de bout en bout, présentées comme exécutées contre la pile complète (outils, état, simulateur d'utilisateur, juge), et une passerelle IA avec budgets et bascule entre fournisseurs. Langfuse, de son côté, s'est construit autour de l'observabilité et de la gestion de prompts, avec une communauté plus large.
Autrement dit : si votre douleur principale est de comprendre pourquoi un agent échoue dans un scénario à plusieurs tours, la simulation intégrée de LangWatch est l'argument à examiner en priorité. Si vous cherchez surtout à tracer et à versionner des prompts, l'écart entre les deux se réduit, et le critère décisif devient l'exploitation : quelle pile de bases de données vous savez faire tourner. Le README de LangWatch documente aussi une intégration GitHub pour garder les prompts dans Git et un lien entre versions de prompts et traces, ce qui recoupe partiellement le terrain de Langfuse.
Coût de maintenance et rythme de publication
Le dépôt n'est pas archivé et le dernier push daté dans les métadonnées est le 9 septembre 2026. Les versions récentes listées couvrent des composants distincts : sdks/go/v1.0.0, typescript-sdk@v1.13.0 et skills@v1.4.0, toutes datées de septembre 2026. Cette séparation des versions par composant signifie qu'une mise à jour de la plateforme n'entraîne pas mécaniquement celle des SDK, et inversement. Pour une équipe, cela veut dire suivre au moins deux calendriers : celui du serveur et celui du SDK qu'elle a intégré.
Côté exploitation, l'auto-hébergement se décline en Docker Compose, Kubernetes via Helm, et des configurations OnPrem pour AWS, Google Cloud et Azure, plus un mode hybride pour les contraintes de résidence des données. Chacune de ces options ajoute sa propre surface de maintenance. Le mode npx @langwatch/server est le plus simple à essayer, mais il installe tout sous ~/.langwatch/ et n'a pas vocation à servir de déploiement de production. Sur la licence, je m'en tiens à ce que le dépôt affiche : un socle Apache-2.0 accompagné d'une extension Enterprise dont le périmètre n'est pas détaillé dans le matériel fourni. Ce n'est pas un avis juridique, et la répartition exacte des fichiers doit être vérifiée dans le dépôt avant toute décision d'achat ou de contribution.
Conclusion éditoriale
LangWatch convient aux équipes qui ont déjà des agents en production et veulent relier traces, jeux de données et évaluations dans un même outil, y compris sur leur propre infrastructure. Il convient mal à qui cherche uniquement une bibliothèque d'évaluation légère à importer dans un notebook, ou refuse d'exploiter PostgreSQL, Redis et ClickHouse. Avant de vous engager, vérifiez deux choses dans le dépôt : ce que couvre exactement la licence Enterprise au-delà du socle Apache-2.0, et le contenu du fichier ~/.langwatch/.env, puisque LANGWATCH_ENABLE_LANGY y vaut true par défaut et fait tourner des workers sans sandbox sur votre machine.
Notes de la communauté