Aller au contenu
ReviewRamble

La lettre hebdomadaire

L’IA, évaluée, dans votre boîte mail.

  • Les nouveaux tests d’outils, de modèles, de serveurs MCP et de dépôts, avec le verdict en premier
  • Les prix et les notes revérifiés quand quelque chose change
  • Les nouvelles analyses dès leur publication

Modèles, agents, serveurs MCP et les outils qui méritent vraiment votre temps.

Un e-mail par semaine. Désinscrivez-vous avec le lien présent dans chaque lettre. Comment nous utilisons votre e-mail

Analyses Programmation

Tester les applications d'IA, et laisser l'IA tester les vôtres : les couches, les outils et ce qu'ils coûtent

Par Sheela ·

Les tests vont désormais dans deux directions. Si vous livrez une fonction d'IA, il vous faut des tests pour quelque chose qui donne une réponse un peu différente à chaque fois. Si vous livrez un logiciel ordinaire, des outils d'IA proposent maintenant d'écrire et d'entretenir vos tests à votre place. Les deux marchés sont encombrés, les deux ont des tarifs qui cachent la vraie facture, et les deux ont un mode d'échec qui ressemble à un build au vert. Voici comment penser les couches, lequel des 16 outils que nous avons évalués convient à quel travail, et une configuration de départ qu'un chef d'équipe peut défendre.

La carte : deux métiers, sept couches

L'essentiel de la confusion vient de la comparaison d'outils qui font des travaux différents. Une bibliothèque de métriques RAG et un agent de navigateur se présentent tous deux comme des "tests par IA", et aucun ne remplace l'autre. Triez d'abord le travail.

Tester une application ou un agent d'IA comporte quatre couches :

  • Evals : entrées fixes, sorties notées. La réponse reste-t-elle fidèle aux sources, l'appel d'outil va-t-il à la bonne fonction. C'est votre test unitaire.
  • Conversations simulées : un second modèle joue l'utilisateur sur plusieurs tours, parce que les agents échouent au quatrième tour, pas au premier.
  • Régression red team : des attaques générées (injection de prompt, fuites de données, contenus nuisibles) relancées à chaque modification, pour qu'une faille corrigée le reste.
  • Notation en production : les mêmes évaluateurs tournent sur les traces réelles, et les mauvaises réponses données à de vrais utilisateurs deviennent de nouveaux cas de test.

L'IA qui teste un logiciel ordinaire en comporte trois :

  • Enregistrer et rejouer pour le backend : capturer de vrais appels d'API et les réponses de base de données qui les accompagnent, puis les rejouer comme tests.
  • Enregistrer et rejouer pour le front end : capturer de vraies sessions et comparer l'apparence des écrans avant et après un changement.
  • Agents de navigateur : une IA qui planifie, écrit, exécute et répare des tests de bout en bout, dans votre dépôt ou dans le cloud d'un fournisseur.

Tester votre application d'IA

Les evals : la couche à construire en premier

promptfoo (4,5) est le chemin le plus court entre aucun test de LLM et des tests en CI : un fichier YAML de prompts, de fournisseurs et d'assertions, et une commande qui affiche une matrice comparative. Il exige Node.js 22.22 ou plus récent. Un point à peser : le 9 mars 2026, OpenAI a annoncé qu'il rachèterait promptfoo, et l'entreprise se présente désormais comme faisant partie d'OpenAI. Il reste sous licence MIT et prend en charge d'autres fournisseurs, mais certaines équipes ne voudront pas que leur évaluateur appartienne à un fournisseur qu'elles évaluent.

DeepEval (4,2) convient aux équipes Python qui veulent des evals dans leur suite de tests existante. Les tests ressemblent à du pytest, se lancent avec deepeval test run et font échouer le build quand la fidélité ou l'accomplissement de la tâche passe sous un seuil. Son catalogue de métriques est l'un des plus larges de l'open source et couvre la planification d'agents et la voix.

Giskard (4,0) réunit des vérifications déterministes, des vérifications jugées par un LLM, la génération de jeux de test RAG et un scan red team dans une seule bibliothèque Apache-2.0. La version 3 est une réécriture qui exige Python 3.12 ou plus récent et abandonne le scan des modèles tabulaires sur lequel comptaient les utilisateurs de la v2.

Deux que vous avez peut-être déjà. Ragas (3,4) a donné son vocabulaire à l'évaluation RAG (fidélité, précision du contexte) et totalise encore environ 1,05 million de téléchargements PyPI par mois, mais personne n'y a fait de commit depuis le 24 février 2026. Gardez-le s'il fonctionne ; ne démarrez pas de nouveau projet dessus. Inspect (4,4), du UK AI Security Institute, est le cadre qu'utilisent les instituts publics de sûreté de l'IA, avec plus de 200 evals prêtes à l'emploi. C'est le bon outil pour les benchmarks de modèles, et plus de framework qu'il n'en faut à une équipe produit qui vérifie des prompts en CI.

Conversations simulées

Les evals à un seul prompt ratent l'agent qui répond bien à la première question puis oublie une contrainte trois tours plus tard. LangWatch Scenario (3,9) teste cela en parlant à votre agent : un modèle joue l'utilisateur, un autre juge chaque tour, et le tout s'exécute comme un test pytest ou vitest ordinaire. Vous pouvez fixer le premier message, injecter un résultat d'outil simulé, vérifier qu'un outil précis a été appelé, puis laisser le simulateur continuer. Les agents vocaux sont couverts aussi, avec injection de bruit et latences p50 et p95. C'est un petit projet, environ 1 000 étoiles pour 165 issues ouvertes, qui trouve mieux sa place à côté d'une bibliothèque d'evals qu'à sa place.

Régression red team en CI

Un scan red team lancé une fois avant le lancement est un audit. Relancé à chaque pull request, il devient un test de régression. promptfoo génère des attaques d'injection de prompt, de jailbreak et d'exfiltration de données ; par défaut, cette génération s'exécute sur son service hébergé, et l'offre gratuite Community limite le red teaming à 10 000 sondes par mois. Le scan de Giskard écrit une suite adverse à partir d'une description en langage courant de ce que votre agent doit faire et ne pas faire, alignée sur l'OWASP LLM Top 10. Le RedTeamAgent de Scenario remplace l'utilisateur simulé poli par un attaquant qui monte en pression sur plusieurs tours, ce qui ressemble davantage aux vrais jailbreaks qu'un prompt hostile isolé.

Notation en production

Les tests avant mise en production ne couvrent que les entrées auxquelles vous avez pensé. Braintrust (4,3) est construit autour d'une question : le dernier changement a-t-il amélioré les choses. Expériences, jeux de données et notation en ligne partagent un même modèle de données, si bien qu'une mauvaise réponse en production devient un cas de test en quelques clics, et le même évaluateur tourne en CI et sur le trafic réel. Langfuse (4,6) est la voie open source, avec traçage, jeux de données, expériences et notation par LLM juge dans une édition auto-hébergée gratuite, au prix de faire tourner vous-même Postgres, ClickHouse, Redis et un stockage objet.

Laisser l'IA tester votre logiciel

Enregistrer et rejouer

Keploy (4,0) s'adresse au backend sans tests. Vous lancez votre service sous keploy record, vous parcourez les flux, et il capture les appels d'API avec le trafic PostgreSQL, MySQL, MongoDB, Redis, Kafka ou RabbitMQ qu'ils ont déclenché. keploy test rejoue les requêtes et sert les dépendances enregistrées comme mocks, si bien que la CI n'a besoin d'aucune base de test. Sous Linux, il le fait avec eBPF : aucun changement de code, mais root et un noyau 5.10 ou plus récent ; les versions natives macOS et Windows ne rejouent de façon fiable que HTTP, MySQL et MongoDB.

Meticulous (3,7) fait de même pour le front end. Un script d'enregistrement dans les builds de staging ou de prévisualisation capture des sessions et les réponses du backend qu'elles ont reçues ; à chaque pull request, il les rejoue contre l'ancien et le nouveau code et regroupe les écrans qui ont changé d'apparence. Vous passez en revue une liste de changements visuels au lieu d'écrire du code de test. Il vérifie l'apparence de l'écran, pas si la commande est arrivée dans votre base de données.

Agents de navigateur

C'est le coin le plus fréquenté, et les quatre options diffèrent surtout par qui possède les tests et qui les exécute.

Playwright Test Agents (4,1) sont fournis gratuitement avec Playwright. Un planificateur explore votre application et rédige un plan de test en Markdown, un générateur transforme ce plan en tests Playwright dans votre dépôt, et un réparateur corrige les tests en échec un par un. Ils tournent dans l'agent de code que vous utilisez déjà (VS Code, Claude Code, Codex ou opencode) et appellent Playwright MCP (4,7) pour piloter le navigateur. Le résultat est du code Playwright ordinaire, sans fournisseur entre les deux.

Momentic (4,0) vous laisse écrire un test sous forme de phrase, l'enregistre en YAML dans votre dépôt et l'exécute dans des navigateurs hébergés, des émulateurs Android ou des simulateurs iOS. Quand un bouton bouge, l'auto-heal le retrouve et propose une modification à relire.

TestSprite (3,7) se place derrière votre agent de code : il lit le code ou un document d'exigences, écrit des tests frontend et backend, les exécute dans son cloud et renvoie un dossier d'échec avec captures d'écran, structure de la page et correctif suggéré.

QA Wolf (4,1) vend le travail plutôt que l'outil. Ses agents écrivent et exécutent des tests Playwright et Appium, décident si un échec vient d'un test périmé ou d'un vrai bug, et ouvrent les bugs avec vidéo dans Linear ou Jira ; dans l'offre gérée, des ingénieurs QA humains examinent chaque échec sous 24 heures. Le code est exportable.

Une mise en garde sur les tests unitaires générés par IA. Qodo (3,8), l'entreprise autrefois appelée CodiumAI et d'abord connue pour générer des tests, a abandonné cet automne sa commande de génération de tests sans remplacement et vend désormais de la revue de pull requests. Les agents de code écrivent volontiers des tests unitaires sur demande ; le risque est qu'un test écrit à partir du code vérifie ce que le code fait, pas ce qu'il devrait faire. Faites écrire ou valider l'assertion par une personne.

Quel outil pour quel travail

TravailCommencer parNotre noteCe que ça coûte
Tests de régression des prompts et du RAG en CIpromptfoo ou DeepEval4,5 / 4,2Gratuit ; vous payez les tokens du juge et du modèle
Vérifications, questions RAG et scan red team dans une bibliothèque PythonGiskard4,0Gratuit ; tokens du juge, gpt-4o-mini par défaut
Comportement d'un agent sur plusieurs toursLangWatch Scenario3,9Gratuit ; deux appels LLM par tour et par test
Benchmarks de modèles et evals de sûretéInspect4,4Gratuit ; tokens et calcul pour les sandbox
Noter le trafic de production, en hébergéBraintrust4,3Offre gratuite ; Pro 249 $ par mois
Traçage et evals que vous hébergez vous-mêmeLangfuse4,6Gratuit en auto-hébergé ; cloud à partir de 29 $ par mois
Backend sans testsKeploy4,0CLI gratuite ; Pro 19 $ par utilisateur et par mois
Régressions visuelles dans un front end très actifMeticulous3,7Non publié
Tests de bout en bout qui vous appartiennent, déjà sur PlaywrightPlaywright Test Agents4,1Gratuit ; tokens de l'agent de code
Tests de bout en bout en langage courant, web et mobileMomentic4,050 $ d'usage gratuits ; Scale 500 $ par mois
Un agent de code qui vérifie son propre travail dans un navigateurTestSprite3,7À partir de 19 $ par mois en crédits
Confier les tests de bout en bout à quelqu'un d'autreQA Wolf4,11 $ par exécution web, 2 $ par exécution mobile

Ce que ça coûte vraiment

Presque tous les outils d'evals open source sont gratuits à installer et se paient en tokens à l'exécution. DeepEval, Ragas et Giskard notent la plupart des métriques avec un juge LLM, donc la facture vaut à peu près cas de test fois métriques fois exécutions. Quelques centaines de cas à chaque pull request finissent par peser, et Scenario double la mise, puisqu'un simulateur et un juge parlent à chaque tour. Lancez la suite complète chaque nuit et un petit jeu de smoke tests à chaque pull request.

Les plateformes hébergées comptent autrement, et le compteur décide à qui elles conviennent. Braintrust facture les données et les notes plutôt que les sièges : Pro à 249 $ par mois couvre 5 Go et 50 000 notes, puis 1,50 $ pour 1 000 notes, si bien que juger chaque requête de production est la ligne qui grossit le plus vite. L'exemple chiffré de Langfuse lui-même place Pro à 5 millions d'unités à 551 $ par mois. Le cloud de LangWatch coûte 29 € par siège en Growth, et Confident AI, la plateforme de DeepEval, passe de Free à 200 $ par mois.

Pour les tests de navigateur, l'unité est l'exécution ou l'étape. L'exemple de QA Wolf lui-même, 50 tests web chaque jour ouvré, revient à environ 1 083 $ par mois, et lancer les mêmes tests à chaque pull request multiplie ce montant. Momentic facture 0,0125 $ par étape normale et 0,025 $ pour une étape que l'IA a dû déduire ; ses 50 $ gratuits représentent environ 4 000 étapes, et quand le solde est épuisé, les tests se mettent en pause au lieu de dépasser. L'offre Starter de TestSprite coûte 19 $ pour 400 crédits, mais la page de tarifs ne dit jamais ce qu'achète un crédit. Pro de Keploy inclut 400 exécutions de test, puis 0,22 $ chacune. Meticulous ne publie aucun prix ; les estimations des sites d'avis vont d'environ 2 000 $ par an à 600 $ par mois.

Là où ces outils vous trompent

  • Des juges instables. Un juge est un modèle, et il échoue comme tel. Parmi les issues les plus discutées de DeepEval figurent des juges qui renvoient du JSON invalide, ce qui fait échouer le test pour une raison sans rapport avec votre application. Les notes bougent aussi quand le modèle juge change : figez la version du juge et traitez sa mise à jour comme celle d'une dépendance, en relançant la référence avant de comparer.
  • Le non-déterminisme. Votre application varie, l'utilisateur simulé varie et le juge varie. Le cache_key de Scenario fait se répéter l'utilisateur simulé, mais un prompt modifié invalide le cache. Mesurez des taux de réussite sur plusieurs exécutions et alertez en cas de baisse, plutôt que de faire échouer le build sur un seul échantillon rouge.
  • L'autoréparation qui cache des bugs. Le travail d'un réparateur est de faire passer un test du rouge au vert, et parfois le bon résultat est rouge. La documentation de Playwright indique que le réparateur peut juger une fonction cassée et sauter le test, ce qu'une équipe pressée peut prendre pour un succès. Momentic propose des correctifs à relire au lieu de les appliquer en silence, et les agents de QA Wolf cherchent à distinguer les tests périmés des vrais bugs. Quel que soit votre achat, lisez chaque diff réparé et comptez les tests sautés comme des échecs.
  • Les enregistrements ne connaissent que le passé. Keploy et Meticulous ne couvrent que ce que quelqu'un a fait pendant l'enregistrement, et les réponses enregistrées se périment quand le schéma change. Une suite de rejeu au vert ne dit rien du parcours que personne n'a cliqué.
  • Vos données quittent la maison. TestSprite exécute les tests dans son cloud, donc les pages et captures d'écran de votre application passent par son infrastructure. L'enregistreur de Meticulous capture les frappes au clavier et les réponses réseau ; les mots de passe sont masqués par défaut, les autres données personnelles demandent des règles que vous écrivez. La télémétrie est activée par défaut dans promptfoo, DeepEval, Ragas et Giskard, et chaque appel au juge envoie vos prompts de test au fournisseur que vous configurez.

Une configuration de départ

Pour une équipe avec une fonction d'IA et une application web ordinaire, ceci couvre l'essentiel du risque pour à peine plus que le coût des tokens :

  1. Écrivez 30 à 50 cas d'eval tirés de vraies questions d'utilisateurs dans promptfoo ou DeepEval, avec des assertions déterministes partout où la réponse le permet et un juge LLM seulement ailleurs. Lancez-les à chaque pull request qui touche un prompt ou un modèle.
  2. Ajoutez un scan red team (promptfoo ou Giskard) au build de nuit, et transformez chaque attaque qui passe en cas de test permanent.
  3. Si la fonction est un agent, ajoutez trois à cinq tests Scenario pour les conversations qui ont déjà mal tourné, avec l'utilisateur simulé en cache.
  4. Envoyez les traces de production à Langfuse ou Braintrust et versez chaque semaine une poignée de mauvaises réponses dans le jeu d'evals.
  5. Pour le reste de l'application, couvrez les cinq parcours qui ne doivent jamais casser (inscription, paiement, l'export dont dépend un gros client) avec Playwright Test Agents si vous utilisez déjà Playwright, ou avec l'offre gratuite de Momentic sinon. Faites relire chaque plan et chaque test réparé par quelqu'un.
  6. Activez les options de désactivation de la télémétrie (PROMPTFOO_DISABLE_TELEMETRY, DEEPEVAL_TELEMETRY_OPT_OUT=1, DO_NOT_TRACK=1) avant la première exécution, pas après.

Le hic : chaque couche ici rend une suite de tests moins chère à produire, et aucune ne décide de ce que veut dire correct. Un jeu d'evals qui ne pose que des questions faciles passe, un réparateur qui réécrit les assertions passe, et un rejeu du trafic du mois dernier passe. La partie coûteuse des tests a toujours été de décider quoi vérifier, et ce travail reste celui de votre équipe.

Notre avis : traitez l'IA dans les tests comme une nouvelle recrue rapide. Laissez-la écrire les cas, les exécuter et proposer des correctifs, et gardez entre les mains d'une personne la liste de ce qui doit être vrai et la validation de tout test qu'elle modifie. Ne payez un service hébergé que lorsque la facture est inférieure au temps qu'une personne de votre équipe passe à maintenir en vie la version gratuite.

La lettre ReviewRamble

L’IA, évaluée. Une fois par semaine, dans votre boîte mail.

Les verdicts qui comptent en IA, robotique et tech, avec ce qu’il faut utiliser et ce qu’il faut éviter. Pas de battage, pas de résumé de tout.

Modèles, agents, serveurs MCP et les outils qui méritent vraiment votre temps.

Un e-mail par semaine. Désinscrivez-vous avec le lien présent dans chaque lettre. Comment nous utilisons votre e-mail