Notre agent a marqué comme terminés douze briefings non envoyés.
Dans un projet client, un agent devait rédiger et envoyer des briefings. Depuis le 2 juillet 2026, il en avait rédigé douze. Leur contenu convenait. Le journal indiquait que le travail était terminé. Pourtant, aucun n’avait été envoyé.[S1]
Nous l’avons découvert lorsque le sponsor du programme côté client a demandé ce que signifiait « 0 envoyé ». Jusqu’alors, nous avions fait confiance à un statut saisi par l’agent lui-même. L’appel d’envoi n’avait renvoyé ni erreur ni confirmation. L’agent était passé à l’étape suivante et avait clos la tâche.[S1]
Un journal détaillé peut ainsi laisser la question essentielle sans réponse. Nous pouvions lire ce que l’agent croyait avoir terminé, mais pas vérifier si le travail avait atteint le client. Pour l’équipe qui attendait ces briefings, c’était le point décisif.
Le statut « envoyé » exige un message dans le système de messagerie.
Reprenons la tâche : un briefing doit parvenir à une personne précise. Un fichier enregistré prouve que le texte existe. Un message dans le système d’envoi atteste un envoi. Vérifiez aussi le destinataire et l’heure pour déterminer si le message correspond à cette tâche.
La réponse du service peut aider. Après un envoi réussi, l’API Gmail renvoie par exemple un message que son identifiant permet de retrouver.[S3] Conservez cet identifiant. Il ne dit toujours pas si le destinataire a lu le message ou utilisé le travail.
Pour l’équipe, distinguez les étapes : rédigé, envoyé, livré, puis vérifié par une personne. Laissez ouverte une étape non observable. Un « terminé » global devient ainsi une séquence vérifiable. L’évaluation des agents distingue de la même façon le récit d’une action de son résultat réel dans l’environnement.[S2]
Si le registre indique « envoyé », vous devez pouvoir retrouver le message.
Dix éléments relient la tâche à son résultat.
La preuve de transmission ne raconte qu’une partie de l’histoire. En cas de problème, l’équipe doit aussi connaître la tâche, les accès permis et la personne qui a vérifié le travail. Nous proposons les dix éléments suivants. Ils doivent être reliés : à partir de la tâche, retrouvez l’exécution de l’agent, puis son résultat.
| Élément | Ce qu’il permet de vérifier |
|---|---|
| Agent et version | Quel agent a travaillé, avec quel modèle et quels paramètres ? |
| Tâche et démarrage | Quel résultat était attendu, pour quand ? Qu’est-ce qui a déclenché l’exécution ? |
| Limites de la tâche | Quel était le périmètre et que pouvait décider l’agent ? |
| Accès permis | Quels systèmes pouvait-il utiliser ? Qui avait autorisé ces accès ? |
| Étapes effectuées | Qu’a-t-il appelé ou modifié, et quelle réponse a-t-il reçue ? |
| Informations utilisées | Sur quelles données et versions s’est-il appuyé ? |
| Résultat et destinataire | Où est le fichier, le message ou la trace ? À qui est-il destiné et quand a-t-il été créé ? |
| Temps et coût | Combien de temps et d’argent la tâche a-t-elle coûté ? Y a-t-il eu d’autres tentatives ? |
| Vérification humaine | Qui a vérifié ou approuvé le résultat, quand et avec quelle décision ? |
| Transmission | Le travail est-il arrivé et a-t-il été accepté ? Que reste-t-il inconnu ? |
Un identifiant de tâche commun aide à relier les entrées. Il n’est pas nécessaire de copier tout le contenu dans un autre système. Une référence au message ou à la version du fichier peut suffire. Les informations sensibles restent dans les espaces auxquels les responsables ont les accès appropriés.
Quelqu’un doit aussi agir lorsqu’un résultat manque. Notre réponse sur la responsabilité en cas d’erreur explique comment attribuer ce rôle. Celle sur les identifiants d’accès (en anglais) précise qui autorise l’agent à utiliser ses outils.
Relier chaque tâche à son message révèle les manques et les doublons.
Vous pouvez rechercher cet écart chez un agent déjà en activité. Choisissez une semaine et une tâche précise, comme l’envoi de briefings. Listez ceux qui étaient dus, puis cherchez dans le système d’envoi les messages réellement présents. Cette seconde liste doit provenir d’autre chose que du statut de fin de l’agent.[S1]
Associez chaque briefing attendu à son message. Le destinataire et l’heure sont-ils corrects ? Manque-t-il quelque chose ? Y a-t-il un double envoi ? Les totaux ne suffisent pas : un message manquant et un doublon peuvent se compenser. Ce contrôle par tâche prolonge la comparaison de deux listes proposée dans notre récit.[S1]
Si un envoi est incertain, cherchez le message avant de réessayer. Il peut avoir réussi sans confirmation. Une nouvelle tentative immédiate créerait alors un doublon. Confiez les points non résolus à une personne nommée, avec une échéance de vérification.
Le test d’acceptation doit inclure la transmission au destinataire.
Pour le prochain agent, testez la transmission finale dès le départ. Dans un cadre maîtrisé, essayez une tâche ordinaire, une action échouée et une réponse ambiguë. Une autre personne peut-elle ensuite expliquer les faits et les inconnues ? Notre liste de contrôle avant mise en production (en anglais) couvre les autres questions.
Nous travaillons aussi sur une vérification distincte des modifications de fichiers, indépendante du récit de l’agent. Sa capacité à détecter ce type d’incident avant une personne reste à démontrer.[S1] Sans attendre, choisissez une tâche en cours et essayez de suivre le travail jusqu’à son destinataire.
Fondements de cette réponse
Les douze briefings concernent un seul projet client de juillet 2026, décrit dans The Hybrid Company.[S1] Les registres sont privés ; ce cas n’établit pas un taux général d’échec. Les dix éléments et le rapprochement par tâche sont notre méthode pratique proposée. Les équipes responsables doivent définir la conservation, la protection des données et les accès selon leur propre tâche.
