Notre lecture
Commencez par le traçage et quelques évaluations sur un seul agent, puis désignez qui est alerté avant d'écrire un monitor. PagerDuty montre la boucle complète : monitor, page à faible urgence, ticket Jira. Un score d'évaluation reste un signal technique ; aucun cas lu ici ne prouve un résultat métier.
Un agent, un responsable, un seuil pour commencer
Arize AX est une plateforme de traçage, d'évaluation et de supervision d'agents IA. Une application classique plante ou non. Un agent peut répondre avec aplomb après avoir choisi le mauvais outil : il faut donc voir chaque étape et la noter. C'est ce que décrit Arize pour AX : des traces de bout en bout, des évaluations au niveau du span, de la trace et de la session, et des signaux de production qui désignent les problèmes.
Mon conseil : pilotez un seul agent et tranchez trois questions avant le premier monitor. Qui est alerté ? À quel seuil de qualité ? Qui corrige ? L'exemple PagerDuty est le modèle le plus net, car il aborde les trois.
Traces : ce qui est capté et ce que contient chaque offre
La documentation d'intégrations sépare le traçage de l'évaluation. Le traçage couvre 16 fournisseurs de LLM (dont OpenAI, Anthropic, Google GenAI et AWS Bedrock), des frameworks d'agents en Python, TypeScript ou JavaScript, Java et .NET, dix agents de code comme GitHub Copilot, Cursor et Devin, et des plateformes comme Dify, Flowise et LangFlow. Des voies OpenTelemetry sont aussi listées : Arize OTEL, OpenLLMetry et OpenLIT.
Le volume détermine l'offre. La grille tarifaire indique 25 000 spans par mois et 15 jours de rétention pour AX Free, puis 50 000 spans et 30 jours pour AX Pro à 50 dollars par mois. Enterprise a un volume et une rétention sur mesure, avec un déploiement possible en auto-hébergement. Évaluations, expériences et annotations humaines sont illimitées à tous les niveaux. Un run d'agent produit beaucoup de spans : estimez-les lors d'un test avant de choisir.
Évaluations : juge LLM, vérité de référence, retours humains
Chez PagerDuty, selon Arize, plusieurs types d'évaluation s'appliquent aux agents de PagerDuty Advance. Les questions déterministes, comme les incidents d'hier, sont vérifiées contre une vérité de référence. Un juge LLM note chaque étape : choix de l'outil, exactitude des paramètres, pertinence de la réponse. Les utilisateurs donnent aussi un pouce levé ou baissé dans Slack, relié à l'identifiant du span pour reconstituer la trace.
TheFork évalue des composants précis plutôt que le système comme une boîte noire : qualité des appels LLM, justesse des garde-fous, qualité de la recherche d'information, latence, usage de tokens et erreurs. Il combine juges LLM et contrôles en code, et cible les tranches de trafic les plus informatives, par exemple les spans qui dépassent des seuils de latence ou de garde-fous. Les évaluations en ligne tournent en continu, avec des envois horaires et des rattrapages ciblés. Selon Arize, le traçage a révélé des appels d'embedding dupliqués sur un chemin critique ; les supprimer a réduit la latence p95.
Alertes : du monitor à la page, puis au ticket
Chez PagerDuty, quand une métrique de qualité des réponses franchit un seuil, Arize envoie une alerte à PagerDuty. L'ingénieur d'astreinte de l'équipe des agents reçoit une page à faible urgence, et un workflow d'incident crée un ticket Jira pour la visibilité et la responsabilité. L'agent SRE maison trie ensuite les incidents d'IA : il évalue si une escalade humaine est nécessaire et injecte dans l'incident le contexte des schémas d'échec issu d'Arize.
Pour savoir qui corrige, le cas décrit un modèle réparti. Des ingénieurs d'agents spécialisés servent d'experts internes et construisent l'outillage commun, les ingénieurs logiciels de l'entreprise bâtissent leurs agents dessus, et les chefs de produit examinent de plus en plus le comportement des agents pour resserrer les boucles de retour. Décidez tôt, chez vous, quel rôle prend le ticket Jira.
Booking.com : collecter une fois, retirer le sensible, router
Booking.com suit deux voies. Les traces d'agents respectent les conventions OpenTelemetry et OpenInference et passent par un collecteur central qui échantillonne, retire les passages sensibles et envoie les données à Arize et aux outils d'analyse. Les modèles de ML classiques alimentent Arize avec des journaux de prédiction issus de l'entrepôt de données, complétés par les étiquettes quand elles arrivent. Si vos agents manipulent des données personnelles, un collecteur placé devant l'outil est le schéma à reprendre.
Arize rapporte deux épisodes. Dans le premier, la supervision a repéré un agent dont la latence dépassait de plusieurs écarts-types sa base habituelle ; la cause était une nouvelle expérience utilisant un autre modèle sans le bon niveau de service. Dans le second, pendant le prototypage d'un agent de planification d'itinéraires, les tokens au P90 ont grimpé et les tours suivants obtenaient de moins bons scores en évaluation multitour : de longs liens vers des attractions, réinjectés dans l'historique, gonflaient le contexte. Selon l'étude, l'équipe est intervenue avant que cette configuration n'arrive en production. Ce sont des déclarations d'éditeur sur une seule entreprise, pas un test comparatif.
Score de qualité, résultat métier et limites des sources
Tous les résultats de ces cas sont des signaux techniques : latence, choix d'outil, qualité de recherche, scores d'évaluation. Les sources lues ne relient aucun score à un chiffre d'affaires, une conversion ou un coût de support. Faites ce rapprochement vous-même, par exemple en comparant les évaluations à un indicateur suivi par l'équipe produit. C'est une recommandation éditoriale, pas une fonction d'Arize.
Un point à clarifier avant l'achat : la page d'intégrations liste des intégrations de traçage et d'évaluation, mais aucune d'alerte ou de notification, alors que PagerDuty décrit des pages et des tickets Jira. Vérifiez en essai comment un monitor atteint vos outils d'astreinte et de tickets. Les comptes de clients sur usedby disent qui utilise Arize, pas si cela fonctionne bien.
Méthode et limites
2026-10-20
Cet état daté compte les entreprises distinctes disposant de preuves clients publiques. CONFIRMED désigne une étude de cas, un témoignage nommé ou une source de presse ; DECLARED, une déclaration de l’entreprise elle-même ; OBSERVED, une liste de clients publiée par un éditeur ; SIGNAL, une offre d’emploi. Les quatre niveaux comptent, avec des forces différentes. Les lignes retirées ou sans niveau sont exclues. Les exemples forment une sélection limitée, vérifiée dans les 90 jours. Les faits éditeurs sont sourcés et vérifiés dans les 60 jours. La couverture est inégale ; une preuve absente reste inconnue. Ces chiffres ne mesurent ni les parts de marché ni les performances. Les dates de collecte ne sont pas des dates d’adoption.
