Comment tester un workflow d’IA qui indique que la tâche est terminée alors qu’il se trompe ?

Vérifiez le résultat en dehors du récit de l’IA concernant ce qui s’est passé. Définissez le résultat correct, les modifications qu’il peut entraîner et les preuves requises avant qu’il ne puisse être considéré comme achevé. Introduisez ensuite délibérément des conditions dans lesquelles une conversation apparemment réussie peut laisser le travail inachevé, incorrect ou non autorisé. Un deuxième modèle indiquant que la réponse semble correcte ne prouve pas que l’opération métier demandée ait bien eu lieu.

Je commencerais par la phrase à laquelle votre utilisateur est susceptible de se fier : « J’ai effectué cette opération pour vous. » Quel système peut le prouver ? Si la réponse est un autre paragraphe généré, il y a une lacune dans l’évaluation avant même que vous n’obteniez un score. Une explication fluide peut masquer une transaction manquante, une mise à jour sur le mauvais enregistrement ou une demande partiellement traitée. Il s’agit là de défaillances différentes, qui appellent des solutions différentes.

Cet article propose une méthode permettant de tester cet écart. Elle combine des travaux de recherche sur l’évaluation des agents, les tests comportementaux, les juges de modèles et l’autocorrection avec un cadre original d’acceptation des flux de travail. Les exemples sont hypothétiques ; je n’ai pas testé le système d’un client ni évalué de modèle dans le cadre de cet article. Les expériences citées établissent des résultats dans les contextes décrits, et non les capacités de chaque produit actuel. Ce qui m’importe, ce sont les preuves dont vous avez besoin pour prendre une décision de mise en production circonscrite.

Définissez la finalisation avant de concevoir la consigne

Le profil de l’IA générative du NIST décrit la confabulation comme la présentation, avec assurance, d’un contenu erroné ou faux (Autio et al., 2024, § 2.2). La « fausse finalisation » est le cas opérationnel que je souhaite isoler : l’application présente une tâche comme terminée alors que ses conditions d’achèvement n’ont pas été remplies. Elle peut résulter de la sortie du modèle, de la logique d’orchestration, d’observations obsolètes ou de l’interprétation par l’interface d’une réponse de l’outil. Il n’est pas utile de supposer que chaque cas a la même cause.

Je rédigerais un contrat de complétion comportant quatre propriétés évaluées séparément. L’exactitude de la réponse concerne ce que l’application indique à l’utilisateur. L’exactitude du résultat concerne l’état métier faisant autorité. Le respect des contraintes concerne les actions autorisées tout au long de la tentative. La fidélité du rapport concerne la question de savoir si le message final décrit fidèlement ce que les preuves établissent. Une réponse peut satisfaire une propriété tout en échouant à une autre. Un solde correct affiché après une consultation non autorisée d’un compte reste inacceptable.

Prenons l’exemple d’un assistant du service client fictif habilité à annuler une commande éligible. La réalisation de cette opération peut nécessiter que la commande en question appartienne au client vérifié, que son statut autorise l’annulation, que l’annulation soit validée, que toute confirmation requise soit enregistrée et que la réponse finale décrive l’état réel de la situation. Si le règlement du remboursement intervient ultérieurement, la mention « annulation acceptée ; remboursement en attente » peut être exacte, tandis que « votre remboursement a été versé » est fausse. Le contrat doit distinguer ces étapes avant que quiconque ne qualifie cet exemple.

Les demandes ambiguës nécessitent un contrat différent. « Annulez ma dernière commande » peut désigner plusieurs commandes. Demander laquelle est visée peut constituer la prochaine étape appropriée ; en choisir une sans justification ne relève pas d’une autonomie réussie. Définissez explicitement les résultats acceptables en matière de clarification, de refus, de remontée hiérarchique et d’exécution partielle. Sinon, l’évaluateur récompensera les suppositions assurées et pénalisera le comportement que vous souhaitiez.

Cela s’inscrit dans la lignée de l’accent mis par le cadre de gestion des risques liés à l’IA (AI RMF) sur l’évaluation dans des conditions proches de celles du déploiement et sur la documentation des limites de généralisation (Tabassi, 2023, MESURES 2.3–2.5). Ce contrat en quatre parties constitue ma proposition de mise en œuvre et non un programme de certification du NIST. Il vous faudra toujours que le responsable du processus détermine ce que signifie « achevé » lorsque les règles métier elles-mêmes ne sont pas claires.

Donnez à l’évaluateur accès à des preuves que l’agent ne peut pas inventer

Une évaluation nécessite un oracle : un moyen défendable de déterminer si le résultat attendu s’est produit. Pour une transaction, il peut s’agir d’une lecture de la base de données de test faisant autorité, complétée par un enregistrement des opérations exécutées. Pour une réponse issue d’une source, il peut s’agir d’un ensemble de propositions approuvées par des experts et liées à une version figée du document. Un seul score de similitude universel ne peut pas servir ces deux objectifs.

WebArena évalue l’accomplissement des tâches fonctionnelles, notamment en vérifiant le contenu obtenu plutôt qu’en exigeant une séquence exacte d’actions (Zhou et al., 2024, §3.2). L’article original sur τ-bench compare l’état final de la base de données à un état cible annoté dans le cadre de conversations simulées entre un agent utilisateur et un agent système (Yao et al., 2024, §3). Ces conceptions constituent des précédents utiles pour évaluer les effets. Les auteurs de τ-bench soulignent également explicitement qu’une récompense accordée peut passer à côté d’une violation de la politique, telle que le fait d’agir sans la confirmation requise. Cette limitation est importante : un état final correct ne constitue qu’une partie d’un test d’acceptation défendable. Aucun de ces benchmarks ne constitue une preuve que votre flux de travail métier fonctionne.

Je conserverais les résultats attendus dans un fichier que l’agent ne peut pas modifier. Commencez par un état connu, exécutez l’application, puis comparez l’état résultant aux résultats autorisés. Inspectez les enregistrements protégés ainsi que la cible. Un assistant qui annule la bonne commande et modifie également l’adresse d’un autre client n’a pas réussi le test, même si l’annulation demandée est bien présente. Lorsqu’il existe plusieurs résultats corrects, encodez l’ensemble acceptable au lieu d’exiger une représentation unique.

L’état final ne peut pas non plus révéler toutes les actions interdites. Un agent pourrait divulguer des informations restreintes, puis rétablir la base de données à ses valeurs d’origine. C’est pourquoi les vérifications des résultats doivent être associées à un journal d’exécution généré par la limite de l’outil, et non reconstitué à partir du récit de l’assistant. Enregistrez l’opération, l’acteur, la ressource, les paramètres nécessaires à l’évaluation, le résultat et l’identifiant de corrélation. Masquez les valeurs sensibles et limitez l’accès à la trace.

Je testerais l’évaluateur lui-même à l’aide de défauts connus : un ordre incorrect modifié, un effet secondaire supplémentaire, une sous-tâche omise et un message d’achèvement inventé. Il devrait rejeter chacun d’entre eux pour la raison prévue. Incluez également des solutions alternatives valides afin de mettre en évidence un oracle trop strict. Il s’agit ici de tests proposés, et non de résultats rapportés. Un évaluateur qui se contente de reproduire les hypothèses de l’application peut vous fournir deux implémentations concordantes d’une même erreur.

Construisez des cas autour des changements d’état et de l’incertitude

Une vaste collection de scénarios ne constitue pas nécessairement une bibliothèque de cas utile. Chaque cas doit préciser l’état initial, l’objectif de l’utilisateur, la politique applicable, les actions autorisées, les observations attendues, les résultats finaux acceptables et les conséquences d’un échec. Cela vous permet d’expliquer pourquoi un échec est significatif et de reproduire les conditions qui l’ont provoqué.

CheckList distingue les tests de fonctionnalité minimale, les tests d’invariance et les tests d’attentes directionnelles pour le comportement du TALN (Ribeiro et al., 2020, §2). J’adapterais cette logique à l’évaluation des flux de travail. Un cas minimal isole une annulation accompagnée d’une autorisation claire. Un cas d’invariance modifie une formulation anodine tout en préservant l’opération prévue. Une paire limite modifie un fait pertinent pour la décision, tel que le fait que la commande ait été expédiée ou non, et nécessite une action différente. Ces cas de flux de travail constituent mon extension de la méthode, et non des expériences tirées de l’article.

Veillez à ce que les paires restent interprétables. Si vous modifiez simultanément l’utilisateur, l’ordre, la version de la politique et la disponibilité de l’outil, un résultat modifié ne vous renseignera guère sur la condition qui a eu une incidence. Les modifications isolées facilitent le diagnostic ; les cas combinés permettent ensuite de tester des interactions réalistes. Les deux sont utiles, mais ils répondent à des questions différentes. Une bonne évaluation doit couvrir aussi bien les situations de travail courantes que les cas délibérément complexes.

Je classerais la bibliothèque en fonction des conséquences opérationnelles : exécution normale, informations manquantes, action interdite, dépendance indisponible, exécution partielle et preuves contestées. Il convient d’inclure les cas où le comportement approprié consiste à mener l’opération à son terme, ainsi que ceux où l’arrêt est nécessaire. Un système peut paraître plus sûr simplement en refusant tout ; un système peut paraître productif en ignorant silencieusement les requêtes complexes. L’éventail des cas doit mettre en évidence ces deux stratégies.

Protéger un ensemble de versions contre les ajustements de routine des invites. Kapoor et al. (2024, §§ 4–5) identifient des ensembles de test insuffisants et un surapprentissage des benchmarks comme des problèmes dans l’évaluation des agents. Mon application ici consiste à séparer les exemples de développement d’un ensemble d’acceptation versionné et à conserver les variantes véritablement nouvelles. Lorsqu’un cas d’acceptation ayant échoué devient un exemple de développement, conservez-le comme test de régression, mais ne prétendez pas qu’il s’agit d’une preuve non encore observée. Enregistrez le transfert et reconstituez la couverture mise de côté.

Provoquer une défaillance de l’outil après qu’un événement s’est produit

Se contenter de tester les erreurs des outils « propres » ne permet pas de détecter les cas qui me préoccuperaient le plus. Une requête peut échouer avant son exécution, après son exécution mais avant l’accusé de réception, ou après seulement une partie d’une opération composée. Ces conditions nécessitent des réponses différentes. Un délai d’expiration est une observation concernant le chemin de communication ; en soi, il ne permet pas de déterminer si le changement d’état prévu a bien été validé.

Dans un environnement de test contrôlé, je ferais en sorte qu’une annulation de commande soit validée alors que son accusé de réception est retenu. L’assistant doit rétablir l’état du système via une lecture approuvée ou un autre chemin de récupération documenté. Répéter aveuglément une opération ayant des conséquences peut entraîner un effet indésirable, à moins que le contrat d’idempotence du service ne l’empêche. Signaler un échec sans vérification préalable peut également induire l’utilisateur en erreur. Le comportement attendu dépend du contrat API réel, que le dispositif de test doit représenter.

ReAct intègre l’interaction avec des observations externes dans la trajectoire de l’agent, en entremêlant raisonnement et action (Yao et al., 2023, §2). Cela permet d’examiner la boucle observation-action, mais ne garantit pas une récupération fiable. Mon test consisterait à faire varier les observations elles-mêmes : une lecture obsolète, une exécution retardée, un état conflictuel, une réponse vide et une réponse de transport réussie contenant un rejet au niveau métier.

Je ferais également la distinction entre détection et diagnostic. Si une exécution se termine de manière incorrecte, conservez les observations disponibles à chaque point de décision avant de modifier l’instruction. Un fait indisponible nécessite une meilleure observation ou un chemin d’incertitude ; un fait disponible ignoré par le modèle peut nécessiter une orchestration différente ; une action non autorisée acceptée par un outil nécessite une correction au niveau de l’application des règles. Il s’agit là d’hypothèses à vérifier à la lumière de la trace. Réécrire l’instruction après chaque échec peut masquer un défaut situé ailleurs dans le système et permettre de reproduire le même échec en utilisant une formulation différente.

Le tableau ci-dessous présente une conception hypothétique d’un processus de résiliation. Il contient les contrôles prévus, et non les résultats mesurés.

Condition injectée	Pruves à examiner	Périmètre de reporting acceptable
Les annulations sont validées ; l’accusé de réception est perdu	Statut de l’ordre faisant autorité et identifiant d’opération	Ne confirmer qu’après rapprochement ; dans le cas contraire, signaler l’incertitude
Les annulations sont validées ; la notification obligatoire échoue	Commander le rapport et le statut de notification séparément	Expliquez ce qu’est une exécution partielle et l’étape en attente
L'utilisateur passe deux commandes mais n'en autorise qu'une seule	Champ d’application autorisé et les deux enregistrements de commande	Ne modifiez que l’ordre autorisé ; clarifiez les autres
Changements de politique au cours de la tentative	Version de la politique et calendrier de décision	Suivre la règle de transition spécifiée ou faire remonter le problème
L’outil de lecture renvoie un état obsolète antérieur à l’annulation	Preuve de la version ou de l’actualité, le cas échéant	Évitez de considérer une observation ancienne comme une preuve de l’état actuel

Réinitialisez les paramètres entre chaque essai indépendant. Sinon, l’annulation réussie d’un cycle pourrait faire apparaître le cycle suivant comme réussi sans qu’aucun travail n’ait été effectué. Pour les tests de poursuite délibérée, conservez explicitement l’état et identifiez le test comme une tentative reprise. Définissez également une fenêtre d’observation maximale. Un flux de travail qui n’atteint jamais un état terminal ne doit pas disparaître du dénominateur sous prétexte que le programme d’évaluation a cessé d’attendre.

Utilisez des modèles d’évaluation que les juges peuvent étayer

Certaines conditions d’acceptation sont faciles à automatiser. D’autres concernent la qualité de l’explication, l’exhaustivité ou la question de savoir si un message d’escalade fournit suffisamment de contexte à un humain. Un évaluateur de modèle peut aider à faire évoluer ces évaluations, à condition que vous mesuriez le comportement de l’évaluateur lui-même plutôt que de considérer sa note comme une vérité absolue.

Zheng et al. (2023, §§ 3.3–4) examinent les biais liés à la position, à la verbosité et à l’auto-valorisation dans l’évaluation des grands modèles de langage (LLM), ainsi que la concordance avec les préférences humaines dans leurs tests de performance. La leçon à en tirer est relative : un juge peut s’avérer utile tout en restant sensible à la présentation et à la conception de l’évaluation. La concordance des préférences observée dans cette étude ne valide pas la capacité d’un juge à déterminer si une opération financière ou administrative particulière a bien eu lieu.

Je procéderais à un calibrage par rapport à un ensemble validé par des experts du domaine, contenant des réponses erronées convaincantes, des réponses correctes concises, des incertitudes justifiées et des déclarations trompeuses indiquant que la tâche est terminée. Examinez les erreurs par catégorie, en particulier les fausses acceptations d’erreurs lourdes de conséquences. Un niveau global de concordance élevé peut coexister avec des échecs sur les quelques exemples qui déterminent si vous devez ou non publier le modèle. Conservez dans le dossier d’évaluation la consigne du juge, la version du modèle, les preuves fournies, les règles de notation et les décisions d’arbitrage.

Lorsqu’un juge compare deux réponses, inversez leur ordre et examinez les décisions incohérentes. Lorsqu’il évalue l’exactitude, fournissez-lui des preuves faisant autorité plutôt que de lui demander de déduire un état caché à partir d’un texte. Il doit être capable de renvoyer le message « preuves insuffisantes ». Ce résultat doit déboucher soit sur une procédure définie menant à une décision humaine, soit sur un résultat non résolu ; il ne doit en aucun cas être considéré tacitement comme une validation.

L’indépendance est une propriété du processus de vérification et d’examen des preuves, et non simplement un nom de modèle différent. Deux modèles analysant le même résumé erroné peuvent aboutir à un accord pour la même raison. Pour les opérations modifiant l’état, j’utiliserais des vérifications directes de l’état dans la mesure du possible et réserverais le jugement du modèle aux parties qui nécessitent véritablement une interprétation. Si vous devez également examiner des instructions malveillantes dans les données récupérées, l’analyse distincte du contenu récupéré et de l’autorité de l’agent permet de gérer cette limite de confiance.

Considérez l’autocorrection comme une amélioration potentielle, et non comme un verdict

« Demander au modèle de vérifier son travail » est une technique raisonnable à tester. Il s’agit toutefois d’une définition insuffisante de l’acceptation. La question importante est de savoir si la correction apporte de nouvelles preuves fiables et si elle améliore les résultats qui comptent, compte tenu du temps et du budget disponibles.

Self-Refine utilise un modèle pour générer un retour d’information sur ses propres résultats et les réviser de manière itérative, en rendant compte des améliorations observées dans l’ensemble des tâches évaluées (Madaan et al., 2023, §§2–3). Huang et al. (2024, §§2–5) examinent l’autocorrection intrinsèque dans le raisonnement en l’absence de retour d’information externe sur la justesse et identifient des limites, notamment une dégradation des performances dans les conditions évaluées. Ces études diffèrent par leurs tâches, leurs consignes, leurs indicateurs et leurs protocoles expérimentaux. Les interpréter comme une affirmation universelle concernant l’ensemble des systèmes d’IA actuels reviendrait à exagérer la preuve.

Je comparerais les flux de traitement complets des candidats sur les mêmes cas mis de côté : l’application d’origine, l’application avec auto-révision et, lorsque cela est possible, une version comportant une étape de vérification externe. Enregistrez les révisions passant de « correct » à « incorrect » ainsi que les corrections. Un gain net peut masquer des erreurs nouvellement introduites dans une catégorie importante. Si un modèle modifie une réponse correcte après avoir été remis en question, il s’agit d’un mécanisme d’échec différent de celui consistant à ne jamais trouver la réponse.

La comparaison doit inclure la latence, l’utilisation des outils et la charge de vérification. Le fait d’accorder plusieurs tentatives à un workflow et une seule à un autre peut répondre à une question budgétaire plutôt qu’à une question d’architecture. Kapoor et al. (2024, §§ 2–3) plaident en faveur d’une évaluation de la précision des agents parallèlement au coût. J’intégrerais donc le budget de déploiement prévu dans l’expérience. Le flux de travail sélectionné doit justifier l’effort supplémentaire qu’il requiert par l’amélioration des résultats des tâches, et non par un compte-rendu d’apparence plus élaborée.

Distinguer la fiabilité de la simple chance d’un succès fortuit

Des essais répétés révèlent des comportements qu’une seule démonstration ne permet pas de mettre en évidence. Le τ-bench original distingue « pass@k », c’est-à-dire la réussite dans au moins un des k essais indépendants, de « pass^k », c’est-à-dire la réussite dans les k essais, en moyenne sur l’ensemble des tâches (Yao et al., 2024, §3). Ces indicateurs répondent à des questions différentes. Un flux de travail qui aboutit parfois après plusieurs tentatives n’est pas nécessairement un flux de travail qui se comporte de manière cohérente lorsqu’un utilisateur s’y fie une seule fois.

Les nouvelles tentatives sont particulièrement délicates lorsque les actions ont des effets secondaires. Pour une tâche de rédaction hors ligne, la sélection du meilleur candidat peut être légitime si la méthode de sélection est également disponible lors du déploiement. Pour une transaction, les tentatives infructueuses peuvent déjà avoir modifié quelque chose. Vous ne pouvez pas écarter ces tentatives du journal et ne rendre compte que de l’issue réussie. Évaluez la politique de nouvelle tentative dans le cadre du flux de travail, notamment la manière dont elle détecte les échecs et empêche les effets répétés involontaires.

Je présenterais trois indicateurs distincts. La réussite des tâches correspond à la proportion de cas évalués satisfaisant au contrat d’exécution. L’incidence des fausses réussites correspond à la proportion de tous les cas évalués pour lesquels une réussite est revendiquée, mais où le contrat n’est pas respecté. Le taux de fausses réussites parmi les réussites revendiquées utilise uniquement les cas où l’application revendique une réussite comme dénominateur. Ce dernier indicateur permet de déterminer directement si les utilisateurs peuvent se fier à la mention « terminé », mais il doit être présenté conjointement avec le taux de déclaration de réussite et le taux global de réussite des tâches.

Supposons, à titre purement hypothétique, qu’une application affirme avoir mené à bien 80 des 100 cas et que 8 de ces affirmations soient erronées. Les fausses déclarations de réussite représentent 8% de l’ensemble des cas et 10% des réussites déclarées. Ces chiffres ne suffisent pas à eux seuls à établir la réussite totale de la tâche : les cas restants doivent également être évalués. En l’absence de déclarations de réussite, le taux conditionnel est indéfini, et non nul. Le fait de signaler cette distinction évite que l’abstention généralisée ne soit perçue comme une fiabilité parfaite.

Certains résultats ne deviennent observables qu’ultérieurement. Une requête peut être acceptée immédiatement mais rejetée au cours du traitement ultérieur. Je distinguerais la fenêtre d’évaluation pour l’accusé de réception de celle pour l’achèvement définitif, puis je signalerais les cas encore en attente de décision. Si le produit ne promet que la soumission, évaluez cette promesse avec précision. S’il promet un traitement achevé, une réponse indiquant que la soumission a abouti est insuffisante. Les étiquettes différées affectent également le suivi : un tableau de bord apparemment sain peut simplement contenir des transactions dont les échecs ne se sont pas encore manifestés. Comparez des cohortes avec des fenêtres d’observation comparables, conservez les cas non résolus et mettez à jour leur statut lorsque des preuves faisant autorité sont disponibles.

Utilisez des lignes distinctes pour les catégories de défaillances aux conséquences graves. Je ne ferais pas figurer une action non autorisée dans la même note qu’une explication légèrement maladroite. Définissez au préalable quelles défaillances entraînent l’arrêt de la mise en production, lesquelles nécessitent une portée plus restreinte ou un contrôle compensatoire, et lesquelles constituent des défauts tolérables. L’attribution des niveaux de gravité doit s’appuyer sur des justifications liées au flux de travail ; une note pondérée, aussi séduisante soit-elle, ne saurait fournir ces justifications a posteriori.

Précisez ce qu’un test en conditions réelles ne permet pas d’établir

L’absence de défaillances observées est encourageante, mais la taille de l’échantillon et le processus de sélection déterminent ce que vous pouvez en déduire. À titre d’illustration, pour une probabilité de défaillance fixe p sur n essais indépendants et identiquement distribués, la probabilité d’observer zéro défaillance est égale à (1 − p)^n. En fixant cette probabilité à 0.05, on obtient la limite supérieure de confiance exacte unilatérale à 95%, p = 1 − 0.05^(1/n). Il s’agit de la spécialisation au cas d’un événement nul du raisonnement exact par limite de confiance binomiale ; le NIST documente la méthode générale (National Institute of Standards and Technology, s.d.).

Avec 100 essais de ce type et zéro échec, la borne supérieure est d’environ 2.95%. Avec 1,000, elle est d’environ 0.299%. Il s’agit d’exemples calculés, et non de mesures issues d’un système d’IA. Une borne de confiance fréquentialiste ne signifie pas non plus qu’il existe une probabilité de 95% que ce taux inconnu particulier soit inférieur à la valeur affichée. Son interprétation dépend de la procédure d’échantillonnage répété et des hypothèses retenues.

Ces hypothèses sont de nature substantielle. Des cas adversaires triés sur le volet ne constituent pas un échantillon aléatoire du trafic ordinaire. Des centaines de variations d’un même modèle ne garantissent pas une couverture étendue des flux de travail. Des tentatives répétées au cours d’une même interruption de service peuvent être corrélées. L’ajustement continu par rapport à l’ensemble de test modifie la procédure. L’application mécanique de la formule dans ces contextes peut donner une apparence de précision sans que celle-ci soit étayée par des preuves correspondantes.

Je présenterais deux points de vue complémentaires : un compte rendu de la couverture axé sur les risques, expliquant quels mécanismes de défaillance ont été remis en cause, et des estimations statistiques uniquement pour un plan d’échantillonnage défendable. Veillez à ce que les strates restent visibles lorsque les types de clients, les classes de tâches ou les conditions de politique ont des conséquences sensiblement différentes. Les exemples supplémentaires ne sont utiles que s’ils apportent des informations pertinentes. Ils ne peuvent pas pallier l’absence d’un oracle ou une limite d’autorisation non testée.

Dans le cas d’une action rare mais inacceptable, l’absence totale de défaillances observées peut constituer un critère de validation sans pour autant prouver que l’action est impossible. Cette distinction doit rester explicite. Les contrôles préventifs, les autorisations restreintes et la réversibilité peuvent assumer une part plus importante de la charge de l’assurance qu’un nombre raisonnable de conversations échantillonnées.

Veuillez indiquer le nom du relecteur et l’environnement d’exploitation

Une étape de validation humaine crée un flux de travail supplémentaire à évaluer. Je vérifierais si le réviseur peut consulter la demande d’origine, l’action effectivement proposée, les preuves et toute incertitude avant que la décision n’ait des conséquences. Une personne chargée d’approuver un résumé généré sans avoir accès à l’état sous-jacent ne peut pas résoudre de manière indépendante la défaillance abordée dans cet article.

Élaborez des exercices validés contenant des propositions incorrectes, des propositions correctes et des cas nécessitant véritablement des éclaircissements. Évaluez ce que le réviseur détecte, ce qui est validé et la durée pendant laquelle les cas non résolus restent en attente. Mettez en place des procédures d’autorisation organisationnelles appropriées et des mesures de protection des participants. Il s’agit ici d’exercices d’acceptation proposés ; aucune étude impliquant des sujets humains n’est rapportée ici. L’interface doit permettre le rejet et la remontée en escalade sans que l’approbation soit le seul moyen pratique de mener la tâche à bien.

L’environnement de test doit également présenter un lien documenté avec le déploiement. Un outil de paiement simulé peut s’avérer utile pour l’injection de défauts, mais il ne reproduit pas le comportement d’un véritable service de paiement. Un simulateur d’utilisateur simplifié peut omettre des interruptions, des malentendus ou des changements d’instructions. Consignez ces différences et identifiez celles qui nécessitent une vérification d’intégration ou opérationnelle distincte. Sinon, un test soigneusement contrôlé pourrait être interprété à tort comme une preuve concernant des conditions qu’il a intentionnellement exclues.

Sculley et al. (2015, §§ 3, 6–7) décrivent les dépendances de données, les problèmes de configuration et les changements dans l’environnement externe comme des sources de dette des systèmes d’apprentissage automatique. Pour ce workflow, je versionnerais ensemble la configuration du modèle, les invites, les schémas d’outils, le modèle d’autorisations, les règles métier, l’instantané de récupération, les fixtures et l’évaluateur. Une modification apportée à l’un de ces éléments peut invalider une partie des preuves de version, même si le nom du modèle reste inchangé.

Après la mise en production, surveillez les signaux susceptibles de révéler des défaillances silencieuses : transactions rapprochées, corrections effectuées par les utilisateurs, demandes réouvertes, sous-tâches incomplètes et divergences entre l’achèvement déclaré et l’achèvement observé. Déterminez qui mène l’enquête et ce qui doit empêcher toute action autonome ultérieure. Conservez suffisamment de preuves pour diagnostiquer les défaillances sans transformer les journaux d’évaluation en une copie incontrôlée de documents sensibles. L’article complémentaire consacré à la protection de la vie privée tout au long du cycle de vie RAG examine ce problème de gestion des données plus en détail.

Formulez une déclaration suffisamment modeste pour pouvoir la défendre

Une décision de mise en service utile précise quelles tâches le système est autorisé à effectuer, sous quelles autorisations, avec quelles preuves d’exécution et quelle solution de repli. Elle identifie la configuration testée, les cas exclus, les questions en suspens, les résultats d’échecs critiques, les limites de l’échantillonnage et le décideur responsable. Le cadre de référence de gestion de l’IA (RMF) du NIST préconise la participation d’experts internes n’appartenant pas à l’équipe de développement de première ligne et/ou d’évaluateurs indépendants lors des évaluations régulières (Tabassi, 2023, MESURE 1.3). Cet examen doit remettre en question tant le contrat d’acceptation que la note attribuée.

La décision qui en résulte ne doit pas nécessairement se résumer à un choix binaire entre une autonomie totale et l’abandon. Supposons que l’évaluation révèle une préparation fiable des demandes d’annulation, mais une reprise peu fiable après des réponses ambiguës de l’outil. Un candidat plus restrictif pourrait préparer la demande tout en exigeant qu’un réviseur résolve l’état d’incertitude avant que l’exécution ne se poursuive. Ce candidat doit disposer de sa propre preuve d’acceptation : le réviseur doit recevoir les faits pertinents, et l’application doit effectivement s’arrêter à la limite. Le simple fait d’ajouter une étiquette d’approbation à l’interface existante ne prouve pas que le chemin d’échec a changé. Je consignerais l’échec d’origine, l’autorité modifiée et le nouveau test spécifique requis avant d’élargir à nouveau le champ d’application.

On peut légitimement objecter que cette approche coûte plus cher qu’une simple comparaison de référence. Pour un assistant de rédaction aux conséquences limitées, une évaluation proportionnée peut en effet s’avérer bien moins lourde. Je vérifierais tout de même si le résultat répond à son objectif, mais je n’exigerais pas de preuves au niveau des transactions pour un système incapable d’effectuer des transactions. La charge de travail doit être proportionnelle aux conséquences, à l’incertitude et aux voies de récupération disponibles. Définir la tâche de manière plus restrictive peut constituer un meilleur investissement que de mettre en place une évaluation complexe reposant sur des prérogatives excessives.

Ce cadre présente également des limites. Un oracle peut se tromper, une bibliothèque de scénarios peut être incomplète et une politique révisée peut présenter des incohérences internes. L’appréciation humaine peut introduire des désaccords plutôt que de les éliminer. La méthode ne garantit pas une sécurité universelle, la conformité légale ni l’immunité face à des défaillances inédites. Sa valeur est plus concrète : elle rend la déclaration de mise en production vérifiable et met en évidence les éléments de preuve qui font encore défaut.

Si votre IA signale une réussite mais que vous ne pouvez pas démontrer de manière indépendante ce qu’elle a accompli, demandez une présentation sur l’assurance des flux de travail de l’IA. Apportez un flux de travail bien délimité et la décision que vous devez prendre. Je vous aiderais à définir son contrat d’exécution, à sélectionner des cas de défaillance ayant des conséquences significatives et à préciser les preuves requises pour la validation. Cela vous fournira une base pratique pour déterminer dans quels cas l’automatisation peut se poursuivre, dans quels cas une intervention humaine est nécessaire et dans quels cas le système doit encore prouver qu’il a bien fonctionné.