Pourquoi les tests d'IA générative mettent à mal l'assertion habituelle
Exigez que la réponse soit égale à une chaîne fixe : le test échoue dès la deuxième exécution, pour une raison qui n'a rien à voir avec votre produit. Assouplissez-la en simple sous-chaîne : elle passe alors sur une sortie subtilement fausse. Ni l'une ni l'autre n'est utile, et c'est en oscillant entre les deux que les équipes finissent par conclure que les fonctionnalités génératives sont intestables.
Que vérifier à la place
| Propriétés | JSON valide, champs obligatoires présents, longueur respectée, source citée qui existe bien. Vérifiable et stable d'une exécution à l'autre. |
| Refus | Le système refuse ce qu'il doit refuser, et le fait de manière constante. Souvent la vérification la plus précieuse de la suite. |
| Ancrage | Chaque affirmation renvoie à un élément du contexte fourni. Détecte les fabulations sans porter de jugement sur le style. |
Des taux, pas des résultats
Une seule exécution ne vous apprend rien. Rejouez la même entrée de nombreuses fois et mesurez la fréquence à laquelle la propriété est respectée. Votre unité de mesure est un taux, et votre signal est la variation de ce taux, pas un échec isolé.
Cela change aussi ce qu'est une régression. La question n'est jamais « est-ce parfait ? », mais « ce changement a-t-il dégradé la situation par rapport à la semaine dernière ? ».
Choisir les propriétés à vérifier
Le plus difficile n'est pas la mécanique, c'est de décider quoi vérifier quand on ne peut pas vérifier la réponse. Une bonne porte d'entrée consiste à se demander ce qui rendrait la sortie inutilisable, plutôt que ce qui la rendrait bonne.
« Inutilisable » est concret : une sortie malformée que l'appelant ne peut pas analyser, une citation renvoyant à quelque chose qui n'existe pas, un refus qui aurait dû être une réponse, une réponse qui aurait dû être un refus, un contenu qui dépasse une limite en aval. Chacun de ces cas est binaire et vérifiable, et chacun correspond à un incident réel, pas à une opinion sur la qualité.
« Bon », à l'inverse, relève d'un jugement qui varie d'un relecteur à l'autre et ne mérite pas d'être codé comme un critère bloquant. Suivez-le si vous le souhaitez, par une relecture humaine sur un échantillon, mais gardez-le hors du pipeline, où il produirait des débats plutôt que des décisions.
La partie qui se teste normalement
L'essentiel d'un produit doté d'une fonctionnalité générative reste du logiciel déterministe ordinaire : authentification, stockage, limitation de débit, interface autour de la fonctionnalité. Tout cela doit être testé de manière conventionnelle, et traiter l'ensemble du produit comme non déterministe parce qu'une de ses parties l'est vous fait perdre beaucoup de couverture à bas coût.
Tracez la frontière explicitement. À l'intérieur, des propriétés et des taux. À l'extérieur, des assertions classiques contre l'application en cours d'exécution.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Si vous préférez ne rien installer, le tableau de bord fait la même chose. Tout ce que la ligne de commande sait faire par ailleurs se trouve dans le dépôt CLI.
Deux voies possibles, et le choix tient surtout à qui possède le pipeline. Connecter la GitHub App depuis le tableau de bord ne demande aucune modification de votre dépôt, car elle réagit au déploiement que votre build produit déjà. Ajouter une étape GitHub Actions place la vérification dans le dépôt, où elle est relue comme le reste du build.
Ce que TestSprite couvre autour de la fonctionnalité
La majorité déterministe du produit, qui représente pour la plupart des équipes la part de loin la plus importante. L'authentification, le stockage, la limitation de débit, l'interface autour de la fonctionnalité et chaque parcours réellement emprunté par un utilisateur relèvent du logiciel ordinaire et se testent de manière conventionnelle. Auto-Authentication maintient les sessions actives pendant toute une exécution, Dynamic Variables transporte les valeurs d'un appel à l'autre, Dependency Chains déduit l'ordre d'exécution, et Auto-Cleanup supprime exactement ce que l'exécution a créé.
La couverture est générée à partir de votre produit puis affinée en langage courant, et elle s'exécute contre l'application déployée à chaque changement : ainsi, les parties du système qui peuvent être vérifiées exactement le sont exactement.
La fonctionnalité générative, elle, réclame des propriétés et des taux, c'est-à-dire un harnais distinct avec sa propre notion de réussite. C'est en traçant cette frontière explicitement qu'une équipe évite d'appliquer des méthodes statistiques à du code déterministe ou de renoncer complètement aux assertions parce que les correspondances exactes échouaient sans arrêt.
Peut-on utiliser une IA pour évaluer la sortie ?
C'est courant et viable, avec une réserve : l'évaluateur a ses propres modes de défaillance et doit être calibré. Confrontez-le au jugement humain sur un échantillon avant de lui faire confiance.
Combien d'exécutions faut-il pour obtenir un taux significatif ?
Assez pour que le chiffre cesse de bouger quand vous en ajoutez. Commencez par des dizaines plutôt que des centaines et surveillez la stabilité.
Les tests génératifs doivent-ils bloquer une fusion ?
Une forte baisse d'un taux de refus, oui. Une petite variation de qualité, non, sans quoi le pipeline devient du bruit.
Et le coût ?
Les exécutions répétées coûtent de l'argent. Échantillonnez plutôt que de lancer la totalité des tests à chaque changement, et faites tourner l'ensemble complet selon une planification.
Tester les prompts, est-ce la même chose ?
C'est lié. Les modifications de prompts sont la cause la plus fréquente des variations de taux, ce qui plaide pour traiter les prompts comme des artefacts versionnés.
Des propriétés et des taux, pas une égalité.
Les tests d'IA générative remplacent les assertions exactes par des propriétés, des refus et de l'ancrage, mesurés sous forme de taux sur de nombreuses exécutions. Testez normalement la majorité déterministe du produit et tracez la frontière explicitement.