ChatGPT peut désormais surveiller votre tableau de projet : ce qu'il manque encore aux agents événementiels

Le récapitulatif du DevDay d’OpenAI du 29 septembre résume l’exemple sans détour : « vous pouvez demander à ChatGPT de surveiller les nouvelles tâches sur un tableau de projet. Dès qu’une tâche arrive, ChatGPT peut lire les documents associés et ébaucher un plan d’action, même en votre absence. » En coulisses, ChatGPT prend désormais en charge la proposition de spécification MCP Events sur l’ensemble de ses forfaits, accompagnée de deux fonctionnalités d’équipe : les tâches d’équipe exécutées selon un calendrier ou sur déclenchement d’événements, et @ChatGPT dans Slack et Teams.

Pour une équipe qui utilise déjà des agents de développement, confier la surveillance d’un tableau à des agents redéfinit le sens même d’une nouvelle tâche. Auparavant, celle-ci attendait une intervention humaine. Aujourd’hui, elle peut réveiller un ou plusieurs agents. Si deux personnes demandent chacune à ChatGPT de surveiller le même tableau, et que le tableau lui-même assigne déjà un Agent aux nouvelles tâches, un seul élément entrant peut générer trois ébauches de plan à trois endroits différents, sans que personne n’ait défini laquelle fait foi.

En résumé

MCP Events offre à ChatGPT une méthode propre et signée pour être notifié des changements survenant dans une application connectée, tandis que les tâches d’équipe de ChatGPT introduisent le travail planifié et événementiel dans les forfaits Business et Enterprise. Déclencher un agent à partir d’un événement représente la partie facile, et OpenAI s’en est acquitté avec soin. La partie complexe réside dans ce que l’événement produit sur le tableau : qui est responsable du travail généré, où atterrit le plan provisoire, comment est-il relu et validé, et comment éviter que deux agents ne répondent au même événement. Formalisez cela sous la forme d’une règle de routage : un type d’événement, un seul responsable, des plans rattachés à la tâche (Task) et une validation humaine avant que quoi que ce soit ne soit considéré comme terminé.

Les nouveautés annoncées au DevDay

MCP Events est une proposition d’extension du Model Context Protocol qui permet à un serveur MCP de notifier ChatGPT dès qu’un événement survient dans une application connectée, afin qu’un plugin puisse lancer une automatisation en réponse. Le guide MCP Events d’OpenAI détaille la partie serveur. Le serveur annonce qu’il prend en charge les événements et implémente trois méthodes : events/list, events/subscribe and events/unsubscribe. ChatGPT prend uniquement en charge la distribution par webhooks, signés via le HMAC de Standard Webhooks après un test de validation HTTPS (challenge), à raison d’un événement par requête dans la limite de 256 KiB. Lorsqu’un événement arrive, pour reprendre les termes du guide, « ChatGPT reçoit l’événement dans la discussion abonnée et applique les instructions de l’utilisateur pour y répondre. »

Les détails techniques sont soignés là où cela compte. Le serveur doit attribuer à chaque événement un identifiant unique qui reste inchangé d’une tentative à l’autre. Les abonnements doivent être idempotents : leur identité découle du principal, de l’URL de rappel (callback), du nom de l’événement et des arguments, de sorte qu’une réinscription met à jour l’abonnement existant au lieu d’en créer un second. Le serveur doit impérativement bloquer les adresses de rappel privées et locales, et ne doit pas suivre les redirections.

Ensemble, ces fonctionnalités font de ChatGPT un point de départ pour le travail en dehors d’une simple conversation. Il s’agit d’une véritable avancée, qui sera largement suffisante pour de nombreuses tâches récurrentes.

Le déclencheur n’est que la partie facile

Appliquons l’exemple du récapitulatif à une équipe réelle. Une nouvelle tâche arrive sur le tableau. ChatGPT consulte les documents liés et rédige un plan. Quatre questions surgissent immédiatement, et aucune ne relève du transport de données.

Qui est responsable du travail qui en découle ? Une ébauche de plan ne vaut pas assignation. Quelqu’un doit assumer la responsabilité du travail décrit, et dans la plupart des équipes, cette attribution se matérialise sur le tableau : un nom sur la tâche et un état qui avance. Une bonne ébauche ne modifie aucun des deux par elle-même.

Où le plan atterrit-il ? L’événement parvient à la discussion abonnée, et le plan se retrouve là où les instructions de cette personne l’envoient : une simple réponse dans le chat, ou une écriture sur le tableau si le plugin le permet et que les consignes le prévoient. L’équipe doit le savoir, sans quoi le tableau continuera d’afficher « nouveau » pendant qu’un plan parfaitement viable patiente à un endroit que personne ne consulte.

Comment est-il relu ? Un plan constitue un arbitrage sur le périmètre. Une personne autre que son auteur doit le lire avant que le code ne commence, à un emplacement accessible au prochain intervenant.

Qui répond à l’événement ? L’idempotence empêche un abonnement de se dédoubler. En revanche, elle ne coordonne pas deux personnes distinctes : le principal faisant partie intégrante de l’identité de l’abonnement, la souscription de chaque personne reste autonome. Ajoutez un Agent assigné sur le tableau, et une même tâche peut se retrouver planifiée plusieurs fois. La déduplication au niveau des webhooks ne règle pas la question de l’attribution au niveau du travail.

Ces interrogations relèvent de la gestion de projet. Elles existaient déjà avant l’arrivée des agents, lorsque trois collaborateurs risquaient d’ouvrir le même ticket, et elles réapparaissent encore plus vite face à des entités qui ne dorment jamais. Concernant la revue du travail autonome, consultez notre article sur les agents de développement en votre absence.

Intégrer le routage directement sur le tableau

Sur un tableau où les agents figurent parmi les assignés (Assignees), « surveiller les nouvelles tâches » revient essentiellement à « assigner la tâche ». Dans Sharkly, une Task assignée à un Agent démarre une exécution dès qu’elle quitte le Backlog et que son Computer et son Runtime sont prêts. L’emplacement d’assignation d’exécution n’accueille qu’un seul Agent ou Crew, et Sharkly fusionne le travail en attente afin qu’une série rapide de commentaires ne génère pas de doublons d’exécution pour un même Agent et une même Task. La responsabilité devient un champ explicite, et non une simple convention.

Pour les événements qui doivent déclencher du travail sans assignation préalable, les Sharkly Automations représentent l’équivalent côté tableau. Une Automatisation repose sur une règle unique : des instructions, un Agent ou Crew, un ou plusieurs déclencheurs et un historique d’exécution, sous le statut Active ou Paused. Ses déclencheurs incluent une planification (cron avec fuseau horaire), le passage d’une Task à un statut donné, un commentaire contenant une expression clé, un webhook issu d’un service externe, ainsi qu’un bouton Run now pour les tests. Chaque exécution se lance directement et conserve son historique au niveau de l’Automatisation ; les instructions doivent donc préciser où consigner le résultat. Le filtrage des statuts et des commentaires s’appliquant aujourd’hui à l’ensemble de l’organisation, la documentation des Automations recommande d’inclure des instructions vérifiant la Task déclencheuse avant toute action.

Voici la grille de correspondance événements-tâches pour un Space :

Et voici la règle sous-jacente, formulée là où l’équipe peut en débattre :

Routing rule: new work in the ENG Space

1. One event type, one owner. Each event maps to exactly one
   Automation or one Agent Assignee. Personal watchers (a chat
   subscription, a dot) may read the board; they do not plan on it.
2. New requests enter Triage. A person accepts before any Agent runs.
3. Accepted work that needs a plan moves to "Needs plan", a status in
   the Backlog category. The "Draft plan" Automation runs the Planner
   Agent, which first checks the Task's Space and type and stops if
   the Task is not ours.
4. The plan returns to the Task as a comment. The Planner does not
   change status and does not assign anyone.
5. The Task's human assignee reads the plan, assigns the executing
   Agent, and moves the Task to Todo. That move starts the run.
6. Done means a person accepted the result. No Agent moves a Task
   into a Completed status.

Placer « Needs plan » dans la catégorie Backlog est précisément le détail qui sécurise l’étape 5 : une Task assignée dans le Backlog reste en attente, ce qui garantit la relecture du plan avant le lancement effectif. Précisez rigoureusement dans les instructions du Planner où doit être transmis le plan, et testez le flux avec Run now avant de vous fier au déclencheur. Lorsqu’un Agent a besoin d’un arbitrage en cours d’exécution, la Task indique qu’elle attend une réponse humaine et apparaît dans l’Inbox du responsable : c’est là que la notion de travail « en votre absence » repasse la main à l’humain. La Task constitue le point de rencontre où une demande sur une messagerie de groupe devient une tâche traçable, et le même principe s’applique pour une issue GitHub assignée à un agent.

Quelle place pour la surveillance par ChatGPT ?

Privilégiez un abonnement MCP Events lorsqu’une personne souhaite obtenir une alerte et un premier brouillon dans son propre chat : un tableau qu’elle suit sans le piloter, le gestionnaire de tâches d’un partenaire, ou un récapitulatif personnel le vendredi. Utilisez les tâches d’équipe lorsque le travail récurrent consiste en une mise à jour d’équipe centralisée dans ChatGPT et que votre organisation dispose d’un abonnement Business ou Enterprise, car vos collaborateurs ajustent alors un socle d’instructions commun plutôt que d’en rédiger chacun de leur côté. En revanche, appliquez une règle intégrée au tableau dès lors que l’événement crée du travail dont l’équipe doit être responsable : un plan à mettre en œuvre, un correctif à relire ou une Task qui doit être comptabilisée le lundi matin.

Les agents d’IA événementiels ne valent que par la règle qui détermine lequel doit intervenir. L’événement n’est que la tuyauterie ; le routage, la responsabilité et la relecture relèvent du management, et leur place est sur le tableau auquel chaque agent rend compte, quel que soit l’éditeur de la solution. Pour définir les priorités des agents une fois la file d’attente remplie, consultez notre guide sur la gestion et le triage de backlog à l’ère de l’IA. Les Dots, première annonce du récapitulatif d’OpenAI, soulèvent exactement la même problématique du côté de l’agent.

Si vous exploitez déjà plusieurs agents, Sharkly vous offre une plateforme unique pour centraliser et gérer leurs tâches ainsi que leurs résultats.

Ressources complémentaires

• Sharkly Automations : les quatre types de déclencheurs, l’historique d’exécution et les limites de l’automatisation
• De la messagerie d’équipe aux tâches de code traçables : transformer un message en travail attribué
• Gestion et triage de backlog par l’IA : déterminer les prochaines priorités de vos agents
• Assigner une issue GitHub à un agent d’IA : du ticket à la pull request prête pour revue
• Des agents de développement en votre absence : exécutions autonomes et file de révision
• Comprendre les OpenAI dots : des agents personnels permanents, et le cadre indispensable qu’une équipe doit leur apporter