Spécifier une fonctionnalité IA : les critères d'acceptation ne marchent plus

La première fois que j’ai eu à recetter une fonctionnalité utilisant un modèle de langage, j’ai écrit mes critères comme d’habitude : « étant donné un document de type X, le système extrait le montant total ». La recette a été un désastre — non parce que la fonctionnalité était mauvaise, mais parce que mon critère ne permettait de conclure ni au succès ni à l’échec.

Sur trente documents, elle réussissait vingt-sept fois. Est-ce que le critère est satisfait ? Ma spécification ne le disait pas. Personne ne pouvait signer.

Voici ce que j’écris maintenant.

Ce qui casse dans le critère classique

Un critère d’acceptation habituel repose sur trois hypothèses implicites, et les trois tombent.

La sortie est unique. « Le système affiche le montant » suppose qu’il y a un affichage possible et un seul. Sur une reformulation, un résumé, une réponse rédigée, il y en a beaucoup — toutes acceptables.

Le résultat est reproductible. On teste une fois, on conclut. Ici, deux exécutions peuvent diverger : un cas qui passe pendant la recette peut échouer en production, et inversement. Tester un cas ne prouve rien.

L’échec est visible. Un logiciel classique qui échoue affiche une erreur. Une fonctionnalité IA qui échoue produit une réponse plausible et fausse. Un testeur qui ne connaît pas le métier la validera.

Cette troisième hypothèse est la plus dangereuse, parce qu’elle transforme la recette en approbation.

Ce que j’écris à la place

Trois éléments, systématiquement.

Une propriété vérifiable, pas une sortie attendue. Au lieu de « le système affiche 1 250 € », j’écris « le montant extrait est égal au montant total figurant sur le document ». La différence paraît cosmétique, elle ne l’est pas : la première est intestable sur un corpus, la seconde se vérifie sur mille documents sans que j’aie à écrire mille résultats attendus.

Un taux, et un échantillon. « Sur les cent documents du jeu de recette, la propriété est vérifiée dans au moins 90 % des cas. » Le chiffre est négocié avec le métier, en fonction de ce que coûte une erreur — et il n’est jamais 100 %, ce qui doit être dit dès le cadrage plutôt que découvert en recette.

Une exigence de détection. C’est la partie la plus importante, et celle que je n’écrivais pas au début : « dans les cas où la propriété n’est pas vérifiée, le système signale un doute dans au moins 95 % des cas ». Autrement dit, le système a le droit de se tromper ; il n’a pas le droit de se tromper en silence.

Ce troisième critère change la conception. Il impose une notion de confiance, un écran de validation, une file de cas douteux. Ce sont des développements en plus, décidés au cadrage plutôt que rajoutés après le premier incident.

Le jeu de recette est le vrai livrable de cadrage

Sur un projet classique, la matière du cadrage, ce sont les user stories. Sur un projet IA, c’est le jeu de cas.

Il se construit avec le métier, et il doit contenir trois familles :

• les cas ordinaires, qui représentent le flux réel — pas les plus propres, les plus fréquents ;
• les cas limites connus, ceux dont les opérateurs se souviennent parce qu’ils posent problème depuis des années ;
• les cas hors périmètre, qui doivent être rejetés. On oublie presque toujours ceux-là, et ce sont eux qui révèlent qu’un système répond à des questions auxquelles il ne devrait pas répondre.

Un point de méthode : c’est le métier qui choisit les cas, pas l’équipe technique. Quand l’équipe les choisit, elle prend spontanément ceux qu’elle sait traiter.

Photo : domaine public (CC0).

Ce qui se passe pendant la recette

Deux différences pratiques avec une recette classique.

On mesure, on ne parcourt pas. Une recette classique se fait écran par écran. Ici, on passe le jeu de cas, on obtient un taux, et on regarde la liste des échecs. La discussion porte sur cette liste, pas sur des impressions.

Les échecs se classent avant de se corriger. Un échec dû à un document illisible n’est pas un échec dû à une règle métier mal comprise. Le premier ne se corrige pas — il se traite par le parcours de reprise. Le second se corrige. Confondre les deux fait boucler une équipe sur des cas insolubles pendant que les vrais défauts restent.

Photo : Green Chameleon — licence CC0.

Ce qui change dans le suivi après la mise en production

Une conséquence qu’on n’anticipe pas au cadrage : la recette ne s’arrête pas à la livraison.

Sur une fonctionnalité classique, une fois recettée, elle reste conforme tant que personne ne la modifie. Ici, le comportement peut changer sans qu’on touche à quoi que ce soit — le fournisseur met son modèle à jour, et le taux mesuré à la recette n’est plus le taux réel.

J’inscris donc désormais dans la spécification une clause de vérification périodique : le jeu de cas est repassé à intervalle régulier, et le résultat est communiqué. Cela paraît excessif à la signature. Cela devient l’argument le plus rassurant du dossier le jour où le taux bouge et qu’on l’a vu avant le client.

Ce que je dis au client avant de commencer

Une phrase, en cadrage, qui évite beaucoup de malentendus :

Cette fonctionnalité aura un taux d’erreur. Notre travail commun consiste à le mesurer, à décider ensemble s’il est acceptable, et à faire en sorte que les erreurs restantes soient visibles et rattrapables.

Cette phrase est mal reçue une fois sur trois. C’est un bon investissement : elle est mieux reçue au cadrage qu’à la recette, où elle ressemblerait à une excuse.