Comment tester une sortie IA avant de la montrer à un client

Constituez un petit jeu de questions à réponses connues, exécutez-le à chaque changement, et mesurez les erreurs qui comptent.

Les équipes testent l'IA en l'essayant. Quelqu'un pose quelques questions, les réponses ont l'air bonnes, et cela part en production. Puis la version du modèle change, ou un prompt est nettoyé, et personne ne s'en aperçoit pendant six semaines.

Il vous faut une suite de non-régression. Elle est plus petite et plus ennuyeuse qu'on ne l'imagine.

Commencez par vingt questions, pas deux cents

Vingt vraies questions, avec des réponses dont vous savez déjà qu'elles sont justes, valent mieux qu'un grand jeu synthétique. Les sources qui valent la peine :

les questions que l'équipe a réellement posées les deux premières semaines
chaque cas où le système s'est trompé (ce sont les plus précieux)
les trois questions avec lesquelles votre collègue le plus sceptique le démolit

Écrivez la réponse attendue à côté de chacune. Quand une réponse exacte n'a pas de sens, écrivez la propriété qui doit être vérifiée : « cite au moins un document », « ne donne pas de chiffre », « dit qu'il ne sait pas ».

Évaluez ce qui compte, pas la formulation

L'essentiel des sorties est de la prose, et comparer de la prose est un piège. Évaluez :

Contrôle	Comment
Les chiffres sont-ils justes ?	Correspondance exacte — ils viennent du code, donc exacts
Une source a-t-elle été citée ?	Présence d'un identifiant ou d'un titre de document
Les bons enregistrements ont-ils été utilisés ?	Comparez l'ensemble, pas la phrase
A-t-il refusé quand il le devait ?	Incluez des questions sans réponse dans les données
La recommandation est-elle la même ?	Catégorielle, pas sur la tournure

Incluez des questions qui doivent échouer. Une suite composée uniquement de questions auxquelles on peut répondre ne mesure rien de l'échec qui vous inquiète le plus. Environ une sur cinq des nôtres n'a pas de réponse correcte disponible — la condition de réussite est que le système le dise.

Exécutez-la à chaque changement, en sachant lequel

Les modifications de prompt, les changements d'outils, les changements dans la recherche documentaire et les montées de version du modèle cassent tous quelque chose. La dernière est la cause la plus fréquente du « ça marchait avant » et la plus difficile à repérer, puisque rien n'a changé chez vous.

Consignez le score avec la date, la version du modèle et la version du prompt. Un chiffre sans ces trois éléments n'est comparable à rien.

Faire évaluer par un modèle, honnêtement

Pour tout ce qui n'est pas vérifiable exactement, un second modèle peut évaluer — avec deux réserves que l'on saute souvent :

Donnez-lui la réponse de référence, pas seulement la question. Demander à un modèle si une réponse est bonne, sans lui dire ce qu'est une bonne réponse, mesure la fluidité.
Étalonnez-le une fois à la main. Évaluez trente éléments vous-même, comparez, et voyez à quelle fréquence l'évaluateur est d'accord avec vous. S'il l'est 70 % du temps, votre suite a une marge d'erreur de ±30 % et vous devez cesser de la citer à deux décimales.

Le chiffre qui compte vraiment

Pas l'exactitude. La fréquence à laquelle il se trompe avec assurance — une réponse fluide, bien mise en forme, péremptoire, et fausse. Tout le reste est rattrapable ; celle-là arrive chez le client.

Suivez-la séparément, et placez la barre là où l'activité l'exige réellement. Pour une aide à la rédaction interne, une certaine tolérance convient. Pour tout ce qu'un client voit sans relecture, presque zéro est le seul chiffre acceptable — et si vous ne pouvez pas le démontrer, gardez un humain dans la boucle et cessez d'appeler cela une mesure temporaire.

Quand arrêter de tester et livrer

Quand la suite passe, et que quelqu'un qui ne l'a pas construite s'en est servi une semaine sur du travail réel sans trouver de nouvelle catégorie d'échec. Cette semaine trouve ce qu'aucune suite ne trouve — et chaque chose trouvée devient la question vingt et un.