L’IA dit « c’est fait ». Comment vérifier le résultat ?

Illustration conceptuelle générée par IA, contenu à titre d’exemple hypothétique.

Supposez que vous demandiez à une IA d’enregistrer un rapport dans la documentation de l’équipe, puis de prévenir la personne responsable. Quelques minutes plus tard, elle répond : « C’est fait. »

Vous ouvrez le document et ne trouvez qu’un titre et un paragraphe d’introduction ; vous regardez ensuite la notification, et aucun message n’apparaît dans le canal indiqué. L’assistant n’a pas inventé : chaque étape qu’il a appelée a reçu une réponse, mais « c’est fait » décrit son processus d’appel, pas le résultat que vous vouliez.

Plus une tâche dépend de plusieurs systèmes, plus cette phrase risque d’être trompeuse. La seule vraie question à se poser est la suivante : le résultat exigé par la tâche existe-t-il réellement, maintenant, là où il devrait être ?

Formuler « terminé » comme un résultat vérifiable

« Organiser le rapport et prévenir l’équipe » convient comme résumé de tâche, mais ne permet pas de valider la livraison. On peut le décomposer en un ensemble de conditions vérifiables dans les systèmes cibles.

Prenons l’exemple d’un rapport concurrentiel hebdomadaire :

Exigence de la tâche	Condition d’achèvement (où la vérifier)
Organiser le rapport	Couvre la période indiquée, conserve les liens sources, signale les données manquantes
Enregistrer le document	Se trouve dans l’espace de travail et la page parente indiqués, le corps correspond à la version finale
Prévenir l’équipe	Apparaît dans le canal indiqué, le lien du message pointe vers le document ci-dessus
Livrer le résultat	Renvoie l’emplacement du document, l’enregistrement de la notification, ainsi que les éléments non terminés ou non vérifiés

Lorsque vous rédigez les conditions d’achèvement, efforcez-vous de préciser « qui peut le voir et où ». Si vous ne demandez qu’un brouillon enregistré, inutile de prévenir l’équipe ; si vous exigez que des collègues puissent le lire, vérifiez aussi les droits d’accès des membres cibles — que le compte de l’assistant puisse ouvrir le document ne signifie pas que tous les destinataires le peuvent.

Il faut également distinguer « a été envoyé » de « a été lu ». La présence d’un message dans le canal peut étayer le jugement « publié » ; en l’absence de trace de lecture ou de confirmation, on ne peut pas en déduire que le destinataire l’a vu et a donné suite.

Trois types de preuves répondent à des questions différentes

Lors de la vérification, il existe trois types de matériaux, chacun ne répondant qu’à une partie des questions.

Retour d'outil        Quelle réponse cet appel a-t-il reçue ?
                     Statut, erreur, identifiant de l'objet renvoyé
                          │
Enregistrement cible  Où le résultat a-t-il atterri ? Est-il relisible ?
                     Document, message, enregistrement dans l'application cible
                          │
Vérification du contenu  Le produit est-il conforme aux exigences ?
                     Contrôle du corps, des sources, des éléments manquants par rapport aux conditions d'achèvement

Le retour d’outil indique ce qui s’est passé lors de cet appel. Le champ de statut, le message d’erreur et l’objet renvoyé dans la réponse sont déterminés par le service appelé ; leur signification précise dépend de la convention entre l’outil et l’API cible. Si un identifiant de document est renvoyé, on peut s’en servir pour retrouver ce document ; l’identifiant seul ne permet pas de juger si le corps est complet.

L’enregistrement cible indique si le résultat a réellement atterri dans le système. Relisez le document à l’aide de l’identifiant renvoyé, ou ouvrez l’enregistrement correspondant dans l’application cible, et vérifiez le compte, l’espace de travail, la page parente et le contenu. Pour la notification, examinez aussi le canal et le message lui-même ; ne vous contentez pas de rechercher un titre similaire pour conclure que vous avez trouvé le résultat de cette tâche.

La vérification du contenu indique si le produit peut être livré. Un document peut exister tout en omettant une section ; un rapport peut comporter des liens sources tout en citant des données d’une mauvaise période. Cette étape doit revenir aux conditions d’achèvement initiales et les comparer une à une, plutôt que de se contenter de vérifier « si la création a réussi ».

Les trois types de preuves peuvent être réunis dans un court reçu : ce qui a été fait, où se trouve le résultat, ce qui a été vérifié, et ce qui reste incertain. Il n’est pas nécessaire de coller tout le journal d’exécution à l’utilisateur.

Un succès partiel doit être signalé séparément

Une tâche à plusieurs étapes peut n’être que partiellement accomplie : l’étape précédente a abouti, l’étape suivante reste sans conclusion.

Voici un ensemble d’enregistrements hypothétiques servant à illustrer la méthode de traitement, et non un journal d’appels réel :

Étape	Résultat observé	Jugement actuel
Enregistrer le document	Identifiant de document renvoyé, après relecture le corps est complet et l’emplacement correct	Enregistré et vérifié
Envoyer la notification	Délai d’attente de la requête dépassé, aucun identifiant de message obtenu	Résultat inconnu
Interroger le canal cible	Le compte actuel n’a pas la permission de lire les messages	Impossible à confirmer avec ce compte

Dans ce cas, l’assistant devrait signaler « document enregistré, résultat de la notification non confirmé », en joignant le lien du document et la raison du blocage.

Un délai d’attente signifie seulement que l’appelant n’a pas reçu de réponse dans le temps prévu. La notification peut ne pas avoir été envoyée, ou avoir été écrite dans le système cible alors que la réponse a été perdue. Par conséquent, relancer directement toute la tâche risque de créer un second document ou d’envoyer une notification en double.

Le traitement ultérieur doit reprendre à l’étape dont le résultat est inconnu. Si le compte dispose des droits de lecture, vérifiez les messages selon le canal cible, l’heure d’envoi et le lien du rapport ; s’il existe un enregistrement correspondant à cette tâche, vérifiez le contenu puis complétez le reçu. Si la requête ne donne rien, il faut aussi tenir compte de la portée de la recherche, des permissions et du délai de visibilité des données, et ne pas immédiatement écrire « non trouvé » comme « non envoyé ».

Lorsqu’il est vraiment impossible d’obtenir une preuve, demandez à une personne disposant des droits de vérifier le canal cible, et suspendez tout nouvel envoi. Ce n’est qu’après avoir confirmé qu’un renvoi est nécessaire que l’on poursuit l’étape de notification, en réutilisant le document déjà vérifié.

Le compte rendu doit conserver la mention « non confirmé »

Un reçu utilisable peut être rédigé ainsi. Le contenu entre crochets est rempli par les résultats réels ; s’il est introuvable, indiquez-le clairement, sans générer un lien qui semble plausible.

Tâche : enregistrer le rapport concurrentiel de cette semaine et notifier le canal indiqué

Document : enregistré et vérifié
Emplacement : [lien réel du document ou identifiant d'enregistrement]
Vérifié : espace de travail cible, page parente, corps, liens sources

Notification : résultat non confirmé
Raison : délai d'attente de la requête d'envoi dépassé ; le compte actuel ne peut pas lire les messages du canal cible
Traitement : renvoi suspendu pour éviter une notification en double

À confirmer de votre part : le canal cible contient-il déjà un message avec le lien du document ci-dessus

Ne compressez pas « échec », « non exécuté » et « résultat inconnu » en un seul état : ils correspondent à des traitements différents. Lorsqu’un outil signale explicitement un refus d’accès, il faut généralement vérifier le compte et les permissions ; si la tâche n’a pas du tout atteint cette étape, il faut décider s’il faut continuer ; si le résultat de l’envoi est inconnu, il faut d’abord consulter les enregistrements. Lorsque la cause de l’erreur ne change pas, soumettre plusieurs fois la même requête ne change généralement pas le résultat.

Pour les processus automatisés de longue durée, conservez également l’identifiant de résultat et l’état de vérification de chaque étape. Ajoutez un numéro à la tâche pour faciliter la corrélation des enregistrements, mais le numéro en lui-même n’empêche pas les écritures en double ; la possibilité de réessayer en toute sécurité dépend de la prise en charge de l’idempotence par l’API cible et de l’exécution effective d’une vérification de déduplication par le processus.

Ce que les traces d’exécution OOMOL permettent de vérifier

La couche de connexion peut fournir la capacité d’appel et les enregistrements d’appel ; le jugement d’acceptation doit toujours être fourni par la tâche elle-même.

Le contrôle des permissions d’OOMOL configure les opérations appelables par connection. Deux points méritent attention lors de la conception d’une tâche : premièrement, il faut aussi tenir compte de la capacité de lecture nécessaire à la vérification ; autoriser la création d’un document n’implique pas automatiquement que l’assistant puisse relire les enregistrements correspondants ; deuxièmement, même si les permissions autorisent l’appel d’une opération, avant d’envoyer un message, de modifier des données externes, d’élargir la portée de partage ou de supprimer du contenu, il convient de confirmer la connection cible, l’opération et les paramètres finaux.

Lors d’un déploiement auto-hébergé d’OpenConnector, les enregistrements d’exécution récents contiennent un résumé des entrées expurgé et les erreurs du provider ; on peut utiliser OOMOL_CONNECT_ALLOWED_ACTIONS et OOMOL_CONNECT_BLOCKED_ACTIONS pour limiter les opérations exécutables. L’assistant ne voit que le schéma, le scope, l’état d’exécution et les étiquettes de compte sécurisées. Ces enregistrements conviennent pour diagnostiquer un échec d’appel, mais ils décrivent l’appel, pas si l’objectif métier a été atteint. Guide d’auto-hébergement

Si la tâche nécessite une attente d’approbation humaine, les nœuds Approval et Wait d’Open Flow persistent l’état d’attente ; après confirmation, on peut poursuivre la même exécution sans relancer les étapes déjà accomplies. L’historique d’exécution est associé à la version correspondante du flux, ce qui permet de déterminer quelle version de la logique a produit un résultat donné. Version hébergée · Code source et auto-hébergement

Les conditions d’achèvement, l’état des étapes, la décision de réessayer et le reçu final doivent être mis en œuvre par les instructions de l’assistant, le code métier ou le workflow. La couche de connexion fournit le chemin d’appel et les enregistrements ; elle ne juge pas à votre place si l’ensemble de la tâche passe l’acceptation.

Commencez par une tâche au résultat vérifiable

Choisissez d’abord une seule étape d’écriture, ne reliez pas toute la chaîne d’un coup. Configurez dans OOMOL Connections les connexions nécessaires à la tâche, vérifiez les opérations disponibles, puis confiez la consigne suivante à l’assistant :

Enregistrez ce rapport déjà confirmé à l’emplacement de document de test que j’indique. Après l’enregistrement, relisez-le, vérifiez que le corps correspond au manuscrit, et renvoyez le lien réel du document. Ne prévenez personne pour l’instant. Si vous ne pouvez pas lire ou vérifier, expliquez les étapes exécutées, les identifiants d’enregistrement renvoyés et les conditions manquantes, sans marquer la tâche comme entièrement terminée.

Une fois l’enregistrement et la vérification stables, ajoutez la notification et exigez le renvoi de l’enregistrement de message correspondant. À chaque étape d’écriture ajoutée, ajoutez une condition d’achèvement vérifiable dans le système cible.

L’essentiel de l’acceptation ne réside pas dans ce que l’assistant dit à la fin, mais dans votre capacité à suivre l’emplacement qu’il indique pour retrouver ce résultat dans le système cible. Lorsque chaque étape d’écriture correspond à une condition vérifiable, ce « c’est fait » a une base.