Un agent toujours actif a aussi besoin d'une condition d'arrêt

Le 29 septembre, OpenAI a présenté dots : des agents capables de poursuivre leur travail sur leurs propres ordinateurs dans le cloud. Cette annonce rend une question de conception très concrète : si un agent continue après la fin de la conversation, qu'est-ce qui lui indique que sa mission n'est plus valable ? [1]

Imaginons une équipe éditoriale qui demande à un agent de préparer des contenus pour un lancement. Le lancement est ensuite reporté, la vidéo source change ou la personne responsable quitte le projet. Continuer consciencieusement pourrait alors produire le mauvais travail. Selon nous, une mission récurrente a besoin d'un cycle de vie : un objectif toujours valable, un périmètre défini, une personne responsable et des conditions d'arrêt. Ce sont des recommandations pour le déploiement d'agents continus, et non des fonctions de dots que nous aurions vérifiées.

OpenAI distingue la recherche proactive de dots des actions qui peuvent suivre. Dans ses explications sur la sécurité, l'entreprise précise que la recherche en arrière-plan utilise des outils en lecture seule ; les actions ultérieures restent soumises aux règles et contrôles habituels. Ce mode précis de recherche ne doit pas être confondu avec toutes les tâches autorisées qui se poursuivent en arrière-plan. [2]

Pour une équipe, il faut donc distinguer détection, préparation et publication. L'arrivée d'un nouveau fichier d'entretien peut justifier la préparation d'un premier montage. Elle n'autorise pas, à elle seule, sa publication sur le compte d'une marque. La mission doit préciser les contenus utilisables, la destination du résultat, l'éventuelle personne chargée de l'approuver et les changements qui rendraient cette approbation caduque. Si l'utilisateur a déjà autorisé une action récurrente bien délimitée, cette autorisation doit pouvoir s'exercer dans son périmètre ; il ne s'agit pas de redemander son accord à chaque étape sans conséquence.

La documentation MCP Events d'OpenAI décrit un traitement asynchrone, des tentatives répétées et des événements susceptibles d'arriver dans le désordre. Elle demande des identifiants d'événement stables d'une tentative à l'autre et des outils d'écriture idempotents. Accuser réception d'une livraison et terminer le travail demandé constituent donc deux étapes distinctes. Il s'agit de règles d'intégration documentées, et non de la preuve que nous avons testé un plugin donné. [3]

Dans une production vidéo, deux notifications pour un même envoi ne devraient pas entraîner deux publications. Un ancien commentaire de relecture ne devrait pas non plus écraser une version approuvée plus récente. Une solution pratique consiste à suivre ensemble le contenu source, sa version et l'action prévue, puis à vérifier cet ensemble avant de répéter une écriture. La personne responsable doit pouvoir distinguer les états reçu, en préparation, en attente de décision, terminé et arrêté. Une simple étiquette « en cours » masque précisément ce qu'elle doit savoir pour décider d'intervenir.

Le même guide MCP Events exige de gérer l'expiration des abonnements aux événements et d'arrêter les livraisons lorsque l'accès est révoqué. La durée d'un abonnement régit la livraison ; elle ne détermine pas, à elle seule, la date à laquelle un objectif métier cesse d'être valable. Cette seconde limite reste à définir. [3]

Nous recommandons de consigner, pour chaque mission récurrente, une personne responsable, une date de réexamen, un périmètre autorisé et des conditions d'arrêt. La fin d'une campagne, le retrait d'une source ou le départ de la personne responsable peuvent déclencher ce réexamen. Avant toute modification externe, il faut vérifier que la mission et la version pertinente de la source sont toujours valables. Si l'agent délègue, les limites applicables doivent suivre le travail délégué ; il faut aussi tester ce qui se passe à l'arrêt de la tâche principale. Une demande d'arrêt doit avoir un résultat observable, y compris pour les étapes déjà achevées ou encore en cours.

La FAQ d'OpenAI sur dots indique que déconnecter un plugin empêche de nouveaux accès, sans effacer le contexte déjà conservé. Elle distingue aussi la suppression d'un dot de celle des fichiers ou conversations enregistrés séparément. Ce sont des faits propres à ce produit ; la leçon opérationnelle plus générale est de préciser quel état est modifié. [4]

Annuler un projet peut vouloir dire arrêter les travaux futurs, révoquer une connexion, archiver des documents de travail ou supprimer le contexte conservé. Ces résultats sont distincts. La personne responsable doit savoir lesquels ont eu lieu et lesquels nécessitent encore une action. Il ne faut pas afficher « annulé » comme si cela retirait aussi un message déjà envoyé. De même, supprimer une intégration ne signifie pas forcément supprimer toutes les copies des contenus obtenus auparavant. Définissez le résultat voulu, puis vérifiez-le dans les systèmes qui conservent l'état concerné.

Un premier essai utile consiste à choisir un processus limité et réversible : surveiller une source approuvée et préparer un brouillon pour une personne chargée de la relecture. Envoyez ensuite volontairement un événement en double, modifiez la source pendant la préparation, retirez l'accès, annulez la tâche principale et épuisez un budget de temps ou de coût défini. Vérifiez si des modifications sont dupliquées, si des brouillons deviennent caducs, si des tâches déléguées se poursuivent et si la raison de l'arrêt est clairement expliquée. Le budget doit être appliqué par le système d'exécution lui-même : une phrase dans une instruction ne prouve pas l'existence d'une limite ferme.

Il y a un véritable compromis : trop de confirmations peuvent transformer l'agent en une boîte de réception de plus à gérer. Mieux vaut définir explicitement l'autorité accordée pour les actions courantes et réserver l'intervention aux changements de périmètre, aux étapes lourdes de conséquences ou aux situations non résolues. La documentation publique ne permet pas d'établir la fiabilité de chaque intégration dans ces cas, et nous n'avons pas mené d'évaluation en production. Ce lancement rend une question pressante : le système sait-il arrêter un travail devenu inapproprié avec autant de fiabilité qu'il sait commencer un travail utile ?