Tester un agent IA après un changement de modèle
Pour savoir si votre agent IA répond encore juste après un changement de modèle, il faut l'avoir prouvé avant le changement, pas le constater après. La méthode tient en trois éléments : un jeu de cas de référence tirés de vrais messages, avec pour chacun ce qu'est une bonne réponse ; une vérification automatique rejouée avant chaque modification ; et une trace de chaque réponse donnée. Sans cela, on change de modèle et l'agent recommence à annoncer une garantie de dix ans au lieu de deux, sans que personne ne le voie.
Je suis développeur Sylius et Symfony indépendant, et je construis des agents IA pour des boutiques en ligne. Les tests sont la couche que l'on repousse toujours, et c'est pourtant celle qui décide si un agent tient dans la durée.
Pourquoi votre agent changera-t-il de modèle, que vous le vouliez ou non ?
Parce que les fournisseurs retirent leurs anciens modèles. La page des retraits de modèles d'Anthropic indique que les requêtes vers un modèle retiré échouent, et que les clients concernés sont prévenus au moins 60 jours avant le retrait des modèles publics. Elle conseille de tester ses applications avec les nouveaux modèles bien avant la date. Chez OpenAI, la page des dépréciations annonce un préavis d'au moins six mois pour les modèles disponibles en général, d'au moins trois mois pour les variantes spécialisées, et d'environ deux semaines pour les préversions, sauf impératif de sécurité ; à la date de fermeture, le modèle n'est plus accessible.
Le modèle n'est pas la seule chose qui bouge. Vous modifiez une règle de retour, vous mettez à jour vos CGV, vous retouchez le prompt système, vous réglez le routeur qui choisit entre petit et gros modèle. Chacun de ces changements peut casser une réponse qui fonctionnait la veille.
| Changement | Ce qui peut casser | Ce qu'il faut rejouer |
|---|---|---|
| Nouveau modèle | Ton, respect des règles, appels d'outils | Tous les cas |
| Nouvelle règle du commerçant | Cas voisins qui appliquaient l'ancienne règle | Tous les cas qui citent une règle |
| Documents modifiés | Citations de source, durées de garantie | Les cas qui s'appuient sur ces documents |
| Prompt système retouché | Refus, ton, format du brouillon | Tous les cas |
| Réglage du routeur | Dossiers délicats envoyés au petit modèle | Les cas difficiles en priorité |
Qu'est-ce qu'un jeu de cas de référence ?
C'est une collection de messages réels, chacun accompagné de ce qu'on attend de l'agent. Pas une réponse mot pour mot, car un modèle ne formule jamais deux fois exactement pareil, mais des critères vérifiables : quel client doit être retrouvé, quelle règle doit être citée, quelle action doit être proposée, et ce qui ne doit surtout pas apparaître.
Sur l'agent de service après vente que je construis en ce moment pour une boutique sous Sylius 2, ce jeu comptera entre 40 et 60 cas réels anonymisés, rejoués avant chaque changement. On y trouve les demandes courantes, les cas limites où deux règles se contredisent, les clients qui écrivent depuis une autre adresse que celle de leur commande, et des messages piégés qui tentent de faire déraper l'agent. L'OWASP recommande d'ailleurs de tester régulièrement un système à base de modèle de langage en le traitant comme un utilisateur non fiable : les tentatives de manipulation ont leur place dans le jeu de tests.
Et si un agent le faisait pour vous ?
Laissez votre numéro : je vous rappelle sous 24 heures ouvrées et je regarde avec vous ce qu'un agent peut prendre en charge dans votre boutique, dans votre budget.
Comment noter les réponses sans tout relire ?
Je sépare ce que le code peut vérifier de ce qui demande un œil humain. Le code vérifie que le bon client a été retrouvé, que la règle citée est la bonne, que l'action proposée est la bonne, qu'aucune action interdite n'est apparue et que la source citée existe. Ces contrôles sont rapides, répétables et ne se laissent pas convaincre.
Il reste le ton et la justesse de la formulation. Là, je compare la réponse du nouveau modèle à celle de l'ancien, et je ne relis que les cas où elles divergent. On peut confier un premier tri à un autre modèle, mais je ne lui laisse jamais le verdict : un correcteur qui se trompe avec assurance est le même problème déplacé.
Quels pièges faussent ces tests ?
Le premier est le jeu trop facile : des cas que n'importe quel modèle réussit ne détectent rien. Les cas qui comptent sont ceux qui ont déjà posé problème. Le deuxième est de ne rejouer qu'une fois : un modèle de langage n'est pas parfaitement constant, et un cas qui passe une fois sur trois est un cas qui échoue. Le troisième est d'oublier de tester l'ancien modèle sur le même jeu, faute de quoi vous ne savez pas si l'écart vient du changement ou du test lui-même.
Le quatrième piège est juridique : des conversations réelles contiennent des données personnelles. Elles doivent être anonymisées avant d'entrer dans le jeu de tests, sujet que j'aborde aussi dans l'article sur les e-mails clients et le RGPD. Enfin, un jeu de tests vieillit : chaque erreur repérée en usage réel doit devenir un nouveau cas.
À quoi servent les traces ?
Les tests disent si l'agent fonctionne avant le changement ; les traces disent ce qu'il a fait après. Sur l'agent que je construis, chaque passage enregistre ce qu'il a lu, ce qu'il a proposé, les règles citées, la version des règles en vigueur, le modèle utilisé et le coût. Si un client conteste une réponse, on retrouve exactement pourquoi l'agent l'a proposée, et avec quelle version de quoi.
C'est aussi ce qui permet de repérer une dérive lente : une règle qui n'est plus jamais citée, un modèle qui coûte soudain plus, une hausse des brouillons rejetés par la personne qui valide. Ce même agent n'envoie d'ailleurs jamais rien seul : il prépare un brouillon et une action en attente, et un humain valide. Les traces montrent donc aussi ce que l'humain a corrigé, ce qui alimente les cas de référence suivants.
Les tests et les traces sont la huitième des couches d'un agent solide, présentées dans l'article sur l'agent IA d'entreprise fiable. Si votre agent doit bientôt changer de modèle, ou si vous ne savez pas comment il est testé, je propose un diagnostic IA offert : je vous rappelle sous 24 heures ouvrées et je regarde comment il se comporterait le jour du changement.