OUTILS IA — CHOISIR, MESURER, CONTRÔLER · 02 / 10 · OBSERVABILITÉ & ÉVALUATION
Sources officielles éditeurs et dépôts publics vérifiés au 18 juillet 2026. Aucun comparatif tiers n'a servi de source.
Un assistant qui « marchait bien en démonstration » ne tombe presque jamais en panne. Il se dégrade. Quelqu'un retouche une consigne système pour corriger un cas particulier, et casse trois cas courants. Le fournisseur met son modèle à jour, et les réponses changent sans que rien n'ait bougé chez vous. Le corpus documentaire vieillit. Aucun de ces événements ne produit d'erreur technique : les temps de réponse sont bons, les journaux serveur sont propres, la supervision d'infrastructure reste au vert.
Ce qui se dégrade, c'est la justesse. Elle ne se lit pas dans un tableau de bord d'infrastructure ; elle se mesure — à condition de ne pas confondre trois choses que le marché vend ensemble : tracer, évaluer, alerter. Cet article sépare ces trois couches, montre comment monter un premier jeu d'évaluation à partir de vos propres cas plutôt que d'un classement public, et examine ce que cinq plateformes vous laissent réellement faire — au regard de leur licence, et de ce sur quoi elles facturent.
Pourquoi un assistant se dégrade sans que personne ne le voie
Trois mécanismes expliquent l'essentiel des dégradations observées en exploitation, et aucun ne déclenche d'incident.
Le premier est le changement de consigne. Un prompt système est un fichier de configuration que tout le monde s'autorise à modifier, parce que c'est du texte et que le texte n'a pas l'air d'être du code. Une phrase ajoutée pour un cas particulier modifie le comportement sur l'ensemble du trafic, et sans jeu de cas rejoué, l'effet de bord passe inaperçu.
Le deuxième est le déplacement du modèle. Vous appelez un modèle hébergé par un tiers, dont vous ne maîtrisez ni la version exacte ni le calendrier de mise à jour. Une nouvelle version peut être meilleure en moyenne et pire sur votre cas précis. La question utile n'est donc jamais « ce modèle est-il bon », mais « se comporte-t-il comme la semaine dernière sur mes propres cas ».
Le troisième est le vieillissement du corpus. Un assistant branché sur une base documentaire hérite de son obsolescence : il répond avec assurance à partir d'une procédure abrogée, et rien dans la chaîne technique ne signale que le document est périmé. C'est le mode de défaillance le plus difficile à détecter, parce que la réponse est parfaitement formée.
La dérive n'a pas de front de rupture. La qualité s'érode par paliers, chacun trop faible pour déclencher une alerte, jusqu'à ce qu'un signal externe révèle un écart accumulé depuis des semaines. Toute l'instrumentation vise à ramener le point de détection vers la gauche.
Ces trois mécanismes sont invisibles à une supervision classique : un service qui répond mal reste, pour elle, un service qui répond. C'est le décalage décrit dans « Un prototype n'est pas une mise en production » — le passage à l'exploitation ne change pas la fonctionnalité, il change ce qu'il faut surveiller.
Tracer n'est pas évaluer : les trois couches à ne pas confondre
Les plateformes regroupent sous une même offre trois fonctions distinctes, qui répondent à trois questions différentes et se déploient dans un ordre précis.
Tracer répond à « que s'est-il passé ». Une trace enregistre le déroulé d'une interaction : question reçue, documents récupérés, appels au modèle, outils sollicités, réponse produite, temps consommé. Couche descriptive, indispensable au diagnostic — mais sans jugement. Un système parfaitement tracé peut se dégrader des mois sans que ses traces le disent : elles enregistrent, elles ne notent pas.
Évaluer répond à « était-ce bon ». Cette couche confronte des sorties à une attente : réponse de référence, règle de conformité, jugement d'un modèle tiers, annotation humaine. Elle produit un score, chiffre attaché à une trace. C'est celle qui manque le plus souvent, et celle qui coûte — deux éditeurs du panorama la facturent séparément.
Alerter répond à « faut-il intervenir maintenant » : surveiller l'évolution des scores, notifier au franchissement d'un seuil. Cette couche n'a de sens qu'au-dessus des deux autres — alerter sur des traces non évaluées revient à alerter sur du volume, ce que fait déjà votre supervision.
Les trois couches se superposent et ne se remplacent pas. La trace décrit, le score juge, l'alerte déclenche. Installer la première sans les deux autres — le cas le plus courant — donne une excellente capacité de diagnostic a posteriori, et aucune capacité de détection.
L'erreur d'architecture la plus fréquente consiste à s'arrêter à la première couche en considérant le sujet traité. Vous disposez alors d'un excellent outil pour comprendre un incident dont quelqu'un d'autre vous a signalé l'existence. La même logique de supervision continue vaut pour les systèmes autonomes, détaillée dans « Superviser un agent qui travaille en continu ».
Construire son jeu d'évaluation à partir de ses propres cas
La couche d'évaluation exige un préalable que les outils ne fournissent pas : un ensemble de cas dont vous connaissez la bonne réponse. Ce jeu est le seul actif durable du dispositif — les plateformes changent, les modèles changent, un jeu issu de votre métier reste valable des années.
Le réflexe consiste à chercher un classement public pour trancher entre deux modèles. Mauvais substitut, pour une raison structurelle : ces épreuves mesurent une compétence générale sur des données dont la propreté est incertaine, sans rapport avec votre corpus ni vos exigences de forme — limite détaillée dans « Benchmarks & contamination ». Un modèle en tête d'un classement peut être médiocre sur vos vingt questions les plus fréquentes.
Quelques principes suffisent. Partez du trafic réel : les questions effectivement posées, pas celles que vous imaginez ; trente cas bien choisis valent mieux que trois cents cas synthétiques. Équilibrez les familles : questions courantes, rares, ambiguës, et — c'est ce qu'on oublie — questions auxquelles le système ne doit pas répondre. Attachez à chaque cas une attente explicite, qui n'est pas toujours un texte : parfois un fait qui doit figurer, parfois une source à citer, parfois un refus. Enfin, versionnez ce jeu comme du code et rejouez-le à chaque changement de consigne, de modèle ou de corpus : c'est la seule façon de transformer une intuition en constat. La méthode générale fait l'objet de « Évaluer une sortie d'IA : les evals », dont cet article est le prolongement outillé.
Le juge automatique : ce qu'un modèle peut noter, et ce qu'il ne peut pas
Annoter à la main quelques centaines de réponses ne passe pas à l'échelle. D'où la pratique consistant à faire noter les sorties par un autre modèle, avec une grille explicite. Elle fonctionne, dans un couloir étroit qu'il faut connaître.
Un juge automatique est fiable sur les critères vérifiables par confrontation : la réponse contient-elle le fait attendu, cite-t-elle une source figurant dans les passages transmis, respecte-t-elle le format demandé, reste-t-elle dans le périmètre autorisé. Sur ces questions, il compare plutôt qu'il n'apprécie — et il le fait à chaque déploiement, sans se fatiguer.
Il devient discutable sur les critères d'appréciation : la réponse est-elle utile, bien calibrée, commercialement acceptable. Là, le juge reproduit ses propres biais ; il valorise souvent la longueur et l'assurance, et un modèle qui note des sorties de sa propre famille n'est pas un observateur neutre. Un score de juge ne prouve donc jamais la qualité dans l'absolu : il détecte une variation. C'est déjà l'essentiel, à condition de ne pas le présenter à la direction comme une note de qualité.
Deux garde-fous rendent le dispositif défendable. Calibrer le juge sur un échantillon annoté par des humains : si son verdict diverge du vôtre sur trente cas, sa grille est à réécrire avant tout déploiement. Et conserver une part d'annotation humaine sur les cas à enjeu — refus, sujets réglementés, tout ce qui engage l'organisation. Ces annotations sont d'ailleurs annoncées sans limite de volume sur l'ensemble des paliers d'Arize AX.
Un juge automatique ne vous dit pas si votre assistant est bon. Il vous dit s'il est encore le même qu'hier. Question moins ambitieuse, et beaucoup plus utile.
— Principe de lecture d'un score d'évaluation automatisé
Ce que la licence vous laisse faire en auto-hébergement
Le partage habituel entre « open source auto-hébergé » et « offre en ligne » ne résiste pas à la lecture des licences. La question pertinente n'est pas de savoir si le code est publié, mais ce que la licence vous autorise à en faire — et si l'auto-hébergement suffit à débloquer les fonctions sensibles. Sur les cinq plateformes relevées, une seule est libre sans restriction.
Opik, gamme développée en interne par l'éditeur Comet — ce n'est pas un produit racheté — est publiée sous Apache-2.0, et son dépôt officiel indique que la plateforme complète est auto-hébergeable sans licence commerciale. Aucune clause restreignant l'usage commercial ou le service à des tiers n'a été relevée.
Langfuse occupe une position intermédiaire souvent mal résumée. Le dépôt est sous licence MIT à l'exception des répertoires ee/, web/src/ee/ et worker/src/ee/, couverts par une licence propriétaire séparée. Surtout, la documentation d'auto-hébergement liste neuf fonctionnalités qui exigent une clé payante même sur votre propre infrastructure : rôles fins par projet, étiquettes de prompt protégées, politiques de rétention, journaux d'audit, masquage de données côté serveur, personnalisation de l'interface, créateurs d'organisation, gestion d'organisation avec provisionnement automatisé des comptes, gestion d'instance. Le cœur est réellement libre, mais la couche de gouvernance et de conformité — précisément ce qu'une direction exige avant d'autoriser un déploiement — est derrière une clé commerciale.
Arize Phoenix ne doit pas être confondu avec Arize AX : deux produits distincts du même éditeur, le premier auto-hébergeable, le second exploité en ligne. Phoenix est distribué sous Elastic License 2.0, qui n'est pas une licence libre au sens de l'Open Source Initiative : elle interdit de fournir le logiciel à des tiers en service hébergé ou infogéré donnant accès à une part substantielle de ses fonctions, et de contourner le mécanisme de clé de licence. Un usage interne n'est pas visé ; une société de services qui voudrait le revendre en mode hébergé sort du cadre. C'est la différence structurante avec Opik.
Pour Braintrust, la page tarifaire mentionne un déploiement sur infrastructure du client côté grands comptes, sans conditions ni dépôt public : le point reste non vérifié, et il ne faut ni affirmer ni nier que la plateforme est ouverte. LangSmith tranche dans l'autre sens : l'auto-hébergement y est un module additionnel de l'offre grands comptes, avec clé de licence obtenue auprès du service commercial. Les paliers inférieurs sont exploités en ligne exclusivement.
| Plateforme | Licence réelle | Ce qui reste bridé en auto-hébergement | Sur quoi la facturation s'empile |
|---|---|---|---|
| Opik (Comet) | Apache-2.0, sans restriction relevée. | Rien : plateforme complète auto-hébergeable sans licence commerciale. | Offre en ligne : spans par mois, durée de rétention, membres de l'équipe. L'unité « span » englobe l'appel d'outil et l'action d'agent. |
| Langfuse | MIT, sauf les répertoires ee/, web/src/ee/ et worker/src/ee/, sous licence propriétaire séparée. |
Neuf fonctions de gouvernance exigent une clé payante même sur votre infrastructure : journaux d'audit, rétention, rôles fins par projet, masquage serveur, provisionnement des comptes, entre autres. | Une unité unique regroupant traces, observations et scores d'évaluation, avec barème dégressif par tranches. |
| Arize Phoenix | Elastic License 2.0 — pas une licence libre au sens de l'OSI. | Interdiction de fournir le logiciel à des tiers en service hébergé ou infogéré, et de contourner la clé de licence. L'usage interne n'est pas visé. | Produit auto-hébergé, sans compteur éditeur. |
| Arize AX | Offre en ligne, propriétaire. Produit distinct de Phoenix, même éditeur. | Sans objet. | Trois compteurs simultanés : spans par mois, volume ingéré en gigaoctets par mois, durée de rétention. Utilisateurs, évaluations et annotations humaines annoncés sans limite sur tous les paliers. |
| Braintrust | Non vérifié — aucun dépôt public de la plateforme relevé. | Déploiement sur infrastructure du client mentionné côté grands comptes, sans conditions publiées. Non vérifié. | Quatre lignes distinctes : données traitées en gigaoctets, nombre de scores facturé au millier indépendamment du volume, rétention au-delà de la période incluse, et crédits consommés au jeton pour les appels de modèles. |
| LangSmith | Plateforme non ouverte — non vérifié, aucun dépôt public relevé. | Auto-hébergement réservé à l'offre grands comptes, avec clé de licence commerciale (confirmé page tarifaire et documentation). | Par siège d'abord, puis traces — rétention courte et rétention longue facturées différemment — plus deux unités de calcul et de stockage propres à l'éditeur, dont la définition n'est pas publiée. |
Ce que coûte réellement l'observabilité
Voici le fait qui devrait piloter votre choix, et qui n'apparaît sur aucune page d'accueil : mesurer la qualité coûte en proportion de la mesure elle-même. Ce n'est pas une remarque de trésorerie, c'est une contrainte de conception — elle décide de la part de votre trafic que vous pourrez évaluer.
Chez Langfuse, la définition officielle de l'unité facturée englobe tout point de données de traçage envoyé à la plateforme : traces, observations et scores d'évaluation. Un score est donc facturé au même titre qu'un span, et brancher un juge automatique sur la totalité du trafic ne fait pas augmenter la facture à la marge : il la multiplie. Braintrust va plus loin en affichant une ligne de facturation dédiée aux scores, comptée au millier et indépendante du volume de données traitées. Évaluer se paie séparément de tracer.
La deuxième surprise tient à la définition de l'unité comptée. Chez Opik, le span est défini comme une opération suivie au sein du traitement — une requête au modèle, un appel de fonction ou une action d'agent. Un assistant qui répond en un appel produit un span ; un agent qui enchaîne dix outils pour la même question en produit un ordre de grandeur de plus, à trafic utilisateur identique. Le volume facturé suit l'agentivité de votre architecture, pas le nombre d'utilisateurs — angle abordé côté fonctionnement dans « Combien coûte vraiment un agent IA ».
La troisième tient aux compteurs simultanés. Arize AX facture à la fois sur le nombre de spans, sur le volume ingéré en gigaoctets et sur la durée de rétention ; ces dimensions ne sont pas substituables. Le palier gratuit plafonne à un gigaoctet par mois pour vingt-cinq mille spans : un assistant à prompts longs saturera le quota de volume bien avant celui de spans. Dimensionner au nombre de requêtes, réflexe naturel, conduit ici à une estimation fausse. Le comportement au-delà du quota n'est pas documenté sur la page tarifaire.
Enfin, LangSmith inverse la logique des autres : son coût croît d'abord avec la taille de l'équipe, puisqu'il facture par siège avant de facturer à la consommation. Pour une équipe nombreuse sur un assistant à faible trafic, le classement de coût s'inverse. Ce même éditeur distingue les traces à rétention courte de celles à rétention longue, facturées différemment : la durée de conservation est une ligne de facturation, pas un réglage.
Ces mécaniques ont une conséquence commune : l'échantillonnage n'est pas une économie de misère, c'est le régime normal. Tracer largement, évaluer sur un échantillon représentatif, réserver l'évaluation exhaustive aux flux à enjeu. Aucune page tarifaire ne vous le dira, parce qu'aucun éditeur n'a intérêt à ce que vous mesuriez moins.
Comment le vérifier vous-même
Tout ce qui précède se vérifie sur vos propres flux, et rien ne remplace ce relevé : les pages officielles décrivent des unités de facturation et des licences, pas le comportement de votre assistant sur vos cas. Le protocole ci-dessous se monte en une journée et devient ensuite votre point de comparaison à chaque changement de prompt ou de modèle.
Instrumenter un assistant ne le rend pas meilleur : cela rend visible ce qu'il fait et mesurable ce qu'il vaut, deux conditions sans lesquelles toute amélioration relève de l'intuition. La bonne façon d'entrer dans le sujet n'est pas de choisir une plateforme, mais d'écrire les trente cas dont vous connaissez la réponse. Ce fichier ne dépend d'aucun éditeur, ne se périme pas avec les grilles tarifaires, et vous dira dès la première semaine si votre assistant tient encore la promesse de sa démonstration.
Une question, un projet IA ?
Vous exploitez un assistant en production et cherchez à savoir s'il se dégrade — échangeons sur votre contexte et vos contraintes.
Prendre contact →Pour aller plus loin : côté méthode, notre article sur l'évaluation d'une sortie d'IA détaille la construction du jeu de référence dont dépend tout ce dispositif, et « Benchmarks & contamination » explique pourquoi un classement public ne peut s'y substituer. L'ensemble de nos décryptages de concepts IA reste consultable en accès libre.