Quand vous spécifiez une fonctionnalité comportant une composante d’IA, le critère d’acceptation cesse d’être « étant donné X, le système renvoie Y ». Le critère d’acceptation devient une eval : un jeu de données annoté, une fonction de score et un score cible que le système doit atteindre avant le lancement, puis de nouveau après chaque changement de modèle ou modification de prompt. La règle simple : si vous ne savez pas écrire l’eval, la fonctionnalité n’est pas encore spécifiée. Cet article décompose les quatre composantes d’un critère d’acceptation probabiliste et explique comment les rédiger en pratique.
Ce qui casse exactement dans une spécification traditionnelle
Une spécification classique repose sur une hypothèse : la même entrée produit toujours la même sortie. Toute la structure des tests, des définitions et des conditions de sortie en découle. Dès qu’une composante du système est un modèle de langage, cette hypothèse s’effondre, et tout l’outillage bâti dessus s’effondre avec elle.
L’expression la plus concrète en est le test d’acceptation. « L’utilisateur clique sur envoyer et reçoit un résumé du ticket » n’est pas une exigence testable, parce qu’il n’existe pas de réponse correcte unique. Deux résumés différents peuvent être tous deux excellents, et un troisième qui leur ressemble peut être complètement faux. Ce qu’il faut définir, c’est une plage de comportement acceptable plutôt qu’un résultat unique.
Le test qui fait gagner des mois de développement : avant d’écrire une ligne de code, essayez d’écrire l’eval. Si vous ne savez pas définir ce qui compte comme une bonne réponse ni comment la mesurer, l’exigence reste floue. Les fonctionnalités qui s’enlisent en pilote échouent presque toujours à cette étape, pas à l’implémentation.
Les quatre composantes d’un critère d’acceptation d’IA
| Composante | Ce qu’elle définit | Exemple |
|---|---|---|
| Description du comportement | Ce que le système doit faire, formulé de manière à admettre la variabilité | Un résumé de ticket contenant le problème, l’action menée et le statut |
| Seuil d’évaluation | Un score minimal sur un jeu de test réservé, jamais utilisé pendant le développement | 90 % des résumés contiennent les trois éléments |
| Contrainte de sécurité | Ce qui constitue une sortie inacceptable, quel que soit le score | Aucun résumé ne contient jamais le numéro de téléphone d’un client |
| Point de reprise humaine | Ce qui se passe dans les cas que le modèle ne sait pas trancher | Un score de confiance faible achemine le ticket vers une file humaine |
La différence entre la deuxième et la troisième composante est fondamentale. Le seuil est statistique et tolère des échecs isolés. La contrainte est binaire et n’en tolère aucun. Sans cette séparation, vous obtenez une fonctionnalité qui passe à 92 % de réussite alors qu’une fuite de données se cache dans les 8 % restants.
Comment construire une eval sans équipe de recherche
Une eval n’est pas un projet. Dans le cas typique, ce sont trois petits actifs maintenus dans la durée :
Un jeu de données. 50 à 150 cas réels issus du système existant, y compris les cas pénibles. Il importe qu’ils viennent du terrain plutôt que d’être inventés, car les cas inventés sont toujours trop commodes. Attachez à chacun la réponse que donnerait un expert métier.
Une fonction de score. Elle n’a pas besoin d’être sophistiquée. Dans bien des cas, il suffit de vérifier la présence d’éléments obligatoires, la conformité à une structure définie ou la correspondance de mots-clés. Là où un jugement est requis, vous pouvez utiliser un modèle comme juge, à condition d’échantillonner manuellement une partie des scores pour confirmer que le juge lui-même ne dérive pas.
Un seuil et une référence. Mesurez une fois avant de changer quoi que ce soit. Sans référence, vous ne pouvez pas savoir si une modification de prompt a amélioré ou cassé les choses, et la plupart des équipes s’en aperçoivent trop tard.
Quand l’exécuter : une eval n’est pas un contrôle unique avant la mise en production. Elle est relancée à chaque changement de modèle, chaque modification de prompt et chaque changement d’une source de données alimentant le système. C’est précisément ce qui distingue une eval d’un cas de test, et la raison pour laquelle elle doit être câblée dans le processus de build dès le premier jour.
Six sections à ajouter au document de spécification
| Section | Ce qu’on y met |
|---|---|
| Spécification du comportement du modèle | Ce que le modèle doit faire, sur quel ton, et ce qui est hors périmètre |
| Seuils d’acceptation | Les métriques et les scores minimaux, y compris les données sur lesquelles ils sont mesurés |
| Catalogue des modes de défaillance | La liste des façons dont la fonctionnalité peut échouer et ce qui se passe dans chaque cas |
| Contraintes comportementales | Lignes rouges binaires : ce qui ne doit jamais apparaître dans la sortie |
| Plan d’évaluation | Le jeu de données, la méthode de score et la fréquence d’exécution |
| Données et confidentialité | Quelles données entrent dans le prompt et à quel niveau de classification |
La dernière section renvoie directement à votre politique de classification des données. Si vous ne l’avez pas encore définie, le modèle de classification à quatre niveaux est le point de départ, car sans lui la spécification définira une capacité que vous n’avez pas le droit d’exploiter.
Le catalogue des modes de défaillance : la section qui mérite le plus d’être écrite
Dans un système déterministe, un mode de défaillance est une erreur. Dans un système comportant une composante d’IA, un mode de défaillance est généralement une réponse qui a l’air parfaitement correcte et qui ne l’est pas. Le catalogue doit donc énumérer les défaillances par ce que l’utilisateur vit, et non par ce que le système rapporte.
Quatre sont particulièrement fréquents : une réponse fausse mais assurée, qui impose de citer les sources pour être vérifiable ; un refus de répondre à une question légitime, qui impose une voie alternative ; une réponse partielle qui omet une condition matérielle ; et la dérive dans le temps, où la source de données change et la sortie se dégrade sans que personne n’ait touché une ligne de code. Le dernier est la raison principale pour laquelle une eval doit tourner périodiquement et pas seulement avant la mise en production.
Ce que cela change au calendrier et au budget
L’impact pratique est un déplacement de l’effort. Dans une spécification classique, l’essentiel du temps va à la définition des écrans et des parcours. Dans une fonctionnalité d’IA, une part importante se déplace vers la collecte et l’annotation des cas de test, et c’est un travail d’expert métier plutôt que de développeur. Budgétez-le explicitement, sinon il se fait écraser et vous arrivez en production sans aucun moyen de savoir si le système fonctionne.
Deuxième déplacement : la fonctionnalité ne « finit » jamais. Elle porte un coût de maintenance continu, celui d’exécuter l’eval et d’entretenir le jeu de test. Quand vous calculez la viabilité, ce coût doit figurer dans le modèle unitaire dès le départ plutôt que de surgir au deuxième trimestre.
Et si la fonctionnalité répond à partir de vos propres documents, la spécification doit couvrir aussi la couche de recherche, car c’est là que se joue l’essentiel de la précision réelle. Le détail complet se trouve dans le guide de la base de connaissances d’entreprise. Nous accompagnons l’ensemble du processus, de la spécification à la mise en production, dans nos domaines d’expertise.
Questions fréquentes
Qu’est-ce qu’une eval et en quoi diffère-t-elle d’un test d’acceptation classique ?
Une eval est un jeu de données annoté accompagné d’une fonction de score et d’un seuil minimal. Un test d’acceptation classique vérifie une sortie unique et renvoie réussite ou échec, alors qu’une eval mesure une distribution de qualité sur des dizaines de cas et est relancée à chaque changement de modèle, de prompt ou de source de données.
Combien de cas de test faut-il pour démarrer ?
Entre 50 et 150 cas réels issus du système existant suffisent pour la plupart des fonctionnalités. Ce qui compte, c’est qu’ils soient collectés sur le terrain plutôt qu’inventés, et qu’ils incluent les cas difficiles et pas seulement les cas commodes.
Comment écrire des critères d’acceptation pour une sortie sans réponse correcte unique ?
Définissez quatre composantes : une description du comportement qui admet la variabilité, un seuil d’évaluation sur un jeu de test réservé, une contrainte de sécurité binaire qui ne tolère aucune exception, et un acheminement vers un humain pour les cas que le modèle ne sait pas trancher.
Pourquoi séparer le seuil d’évaluation de la contrainte de sécurité ?
Parce que le seuil est statistique et tolère un pourcentage d’échecs, tandis que la contrainte est binaire. Sans cette séparation, une fonctionnalité peut passer avec un score élevé alors qu’un manquement grave, comme l’exposition de données personnelles, se cache dans le pourcentage d’échec.
Peut-on utiliser un modèle comme juge pour scorer la sortie ?
Oui, et c’est une méthode courante là où un jugement est requis. La condition est d’échantillonner manuellement une partie des scores et de les comparer au jugement humain, afin de confirmer que le juge lui-même ne dérive pas dans le temps.