# Quand tous les tests sont verts et que l'IA se trompe quand même > Les équipes produit savent dire quand une fonctionnalité est terminée. Pour une réponse générée par une IA, la question se pose autrement : à partir de quand peut-on s'y fier ? J'ai fini par écrire une méthode pour y répondre, la Definition of Trustworthy. Voici d'où elle vient et comment elle fonctionne. - Author: Moamen Elmasry - Published: 2026-10-20 - Category: Articles - Language: fr - Canonical URL: https://moamen.fr/blog/definition-of-trustworthy/ - Also available in: https://moamen.fr/en/blog/definition-of-trustworthy/ - Licensed CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). When quoting or reusing this content, credit "Moamen Elmasry, moamen.fr". --- *Moamen Elmasry, product owner. Definition of Trustworthy, version 1.0.* Ma méfiance envers les réponses de l'IA générative tient à une chose simple : à la même question, une IA ne répond jamais deux fois de la même façon. Un logiciel classique est déterministe, il refait exactement ce qu'on lui a demandé. Une IA générative est probabiliste. Elle choisit à chaque fois parmi plusieurs réponses possibles, et rien ne garantit que la prochaine sera aussi bonne que celle que je viens de relire. Quand j'ai commencé à tester des produits IA comme product owner, cette méfiance est devenue une question de travail. Je devais dire si une fonctionnalité pouvait partir chez les utilisateurs, et mes outils habituels ne m'aidaient pas. La Definition of Done, que toute équipe agile connaît, suppose qu'une fonctionnalité finit par être terminée. Une réponse de l'IA générative ne l'est jamais tout à fait, puisqu'elle ne sera jamais exactement celle que chaque utilisateur attend. Je me suis donc posé d'autres questions. Que devrait me montrer l'IA pour que je lui confie mes utilisateurs ? À partir de quel niveau de qualité ? Et que fallait-il ajouter à la Definition of Done pour couvrir ce qu'elle ne couvrira jamais ? La Definition of Trustworthy est née de ces questions. Son point de départ est resté le même depuis : remplacer une impression de confiance par des preuves. Pour voir ce qui peut mal tourner sans elle, prenons une équipe qui s'apprête à livrer un assistant chargé de rédiger le compte rendu d'une réunion à partir de sa transcription. Avant la mise en production, elle fait les choses sérieusement. Vingt-cinq réunions de test, pour chacune un compte rendu de référence écrit par quelqu'un du métier, et un score qui mesure si les informations importantes ont bien été reprises. Le résultat tombe : 0,96, pour un objectif fixé à 0,85. Tout le monde est content. Sauf qu'un des vingt-cinq comptes rendus affirme qu'un budget a été validé en séance, alors que personne ne l'a validé. Le texte reprend pourtant toutes les informations attendues. Il obtient donc la note maximale et disparaît dans la moyenne. S'il part chez un client ou devant un comité, l'erreur coûtera bien plus cher que les onze points gagnés au-dessus de l'objectif. ## Ce que la Definition of Done ne sait pas faire La Definition of Done fixe ce qu'une fonctionnalité doit remplir pour être considérée comme terminée. Elle marche très bien pour tout ce qui a une réponse exacte. Un utilisateur sans droits voit la fiche client ou ne la voit pas ; un lien expire au bout de trente minutes ou il n'expire pas. On écrit le test, on le lance, on obtient oui ou non, et on obtiendra le même oui demain. Une réponse générée ne se laisse pas enfermer dans ce oui ou non. Il existe dix bonnes façons de résumer une réunion, et l'assistant n'écrira jamais deux fois la même. Comparer mot pour mot rejetterait de bons résumés. Relire quelques exemples reviendrait à valider sur une impression, c'est-à-dire exactement ce que je voulais éviter. J'ai donc séparé les deux questions. La Definition of Done continue de couvrir ce qui est exact. La Definition of Trustworthy, que j'abrège en DoT, couvre le reste. Elle doit prouver qu'un résultat généré atteint la qualité nécessaire pour l'usage prévu, au niveau de risque que l'on accepte. D'une réponse de l'IA générative, on ne se demande pas si elle est finie, mais si l'on peut s'y fier. ## Savoir de quel côté on se trouve Le plus difficile n'est pas de mesurer, c'est de classer. Un même produit mélange presque toujours les deux natures. L'assistant vérifie les droits de l'utilisateur, va chercher les bonnes données, respecte un format, puis rédige. Je ne classe donc jamais un produit entier, mais chacun de ses comportements, en me posant deux questions. La première est simple : peut-on écrire à l'avance le bon résultat et le comparer exactement ? Si plusieurs réponses sont acceptables, on est du côté de la DoT. La seconde est moins évidente, et c'est pourtant elle qui règle les cas difficiles : d'où vient ce bon résultat ? S'il découle d'une règle écrite (un schéma, une table de décision, une formule), c'est de la Definition of Done. S'il a fallu qu'une personne examine chaque cas pour dire ce qui était juste, c'est de la DoT. Prenez un tri de demandes en trois catégories. Si le tri suit une table écrite par l'équipe, on peut le tester cas par cas, et il relève de la Definition of Done. Si c'est un modèle entraîné qui trie, personne n'a écrit la règle : on ne peut que comparer ses choix à des exemples annotés, et il relève de la DoT, même avec trois catégories seulement. Il faut alors accepter qu'il se trompe parfois, puisque c'est précisément ce que signifie un seuil. Quand le métier refuse toute erreur, la solution n'est pas un seuil à 100 %. C'est d'écrire la règle pour pouvoir la tester. ## Une expérience plutôt qu'un test Concrètement, une évaluation DoT ressemble davantage à une expérience qu'à un test unitaire. On fige une version du produit, on la fait tourner sur un ensemble de cas versionnés, puis on note chaque résultat avec des évaluateurs choisis à l'avance. Ce peut être un script, une grille, une personne, parfois une IA chargée de juger, à condition de l'avoir d'abord comparée à des notes humaines. Viennent enfin les règles d'acceptation. Tout se joue sur le moment où ces règles sont fixées : avant la première exécution. La tentation est connue. On regarde le score d'une démonstration, 4,2 sur 5, et l'on fixe l'objectif à 4. Le test passera forcément, et il ne prouvera plus rien. > **Encadré : dix questions à trancher avant de lancer une évaluation** > > - Quelle capacité évalue-t-on ? Une seule à la fois. > - Sur quels cas, et dans quelle version ? > - Qu'est-ce qu'une réponse acceptable : une référence annotée, une grille ? > - Avec quelle métrique ? > - Quel seuil, et approuvé par qui ? > - Quels sous-ensembles doivent réussir seuls (une langue, un type de client, une catégorie sensible) ? > - Quelle erreur bloque tout, quel que soit le score ? > - Quels modèle, consignes, paramètres et nombre de répétitions ? > - Que garde-t-on comme preuves ? > - Qui approuve le protocole, et qui décide à la fin ? > > S'il manque une seule réponse, l'évaluation n'est pas prête à être lancée. ## Pourquoi une bonne moyenne ne suffit pas Revenons à nos comptes rendus. Avec un seuil seul, le 0,96 passait. Pour l'arrêter, il faut deux outils de plus. Le premier est le veto : une règle qui dit qu'une décision inventée bloque l'acceptation, même une seule fois, quel que soit le score. Le second est le segment critique : on vérifie à part les cas qui comptent le plus, par exemple les réunions où l'on engage de l'argent, pour qu'une bonne moyenne générale ne cache pas un groupe qui va mal. Dans notre exemple, monter le seuil à 1 n'aurait servi à rien. Le compte rendu fautif avait la note maximale, et seul le veto pouvait le bloquer. Le verdict, lui, peut prendre trois valeurs. « Pass » si tout a été mesuré et que chaque règle est tenue, « Fail » si l'une d'elles ne l'est pas. Et « Not Ready » quand il manque une des dix réponses de l'encadré. On prend souvent cette troisième valeur pour une formalité ; c'est pourtant elle qui protège le plus. Une équipe pressée a toujours envie de remplir le seuil manquant, « pour avancer, on fera valider plus tard ». Dans le rapport, ce chiffre tapé à la hâte ressemble trait pour trait à un chiffre approuvé, et plus personne ne fera la différence. ## La décision reste à quelqu'un Pour un produit qui mêle les deux natures, et c'est le cas de la plupart des assistants, chaque volet doit réussir séparément. Il y a d'abord les tests exacts, puis l'évaluation DoT, puis les tests avec les utilisateurs quand le produit leur est exposé. Je refuse de fondre le tout en une note globale : un excellent score de rédaction ne rattrape pas un utilisateur qui voit des données auxquelles il n'a pas droit. Reste à savoir qui décide. Ni la personne qui teste, ni l'outil. Les seuils et les vetos reviennent au responsable du produit et aux métiers concernés, parce que ce sont eux qui portent le risque. L'exécution d'une évaluation peut être automatisée, c'est d'ailleurs le rôle du Testing Agent, que j'ai conçu pour cela. Mais quand un seuil manque, l'outil doit le signaler, pas le deviner. ## Ce que la méthode ne promet pas La DoT n'est pas une norme. C'est une méthode écrite à partir de ma pratique et des niveaux de test enseignés depuis longtemps. Elle a aussi un coût : réunir des cas annotés par des personnes du métier prend du temps, et c'est souvent là que les projets bloquent. Je n'ai pas trouvé de raccourci. Sans ces cas, on peut toujours produire des chiffres, mais on ne sait pas ce qu'ils valent, et on revient à la confiance sur impression d'où tout est parti. Cette page fait référence pour la méthode. Elle sera datée à chaque changement de fond. *Pour aller plus loin : le [Testing Agent](/testing-agent/) applique la méthode directement dans votre assistant IA, et le [cours AI Product Testing](/cours/) la reprend pas à pas, avec des exercices qui tournent dans votre navigateur.*