Un document vient d’être corrigé dans votre outil métier. Vous souhaitez qu’un agent prépare un résumé pour l’équipe, sans envoyer le message lui-même. Pour que ce déclenchement reste fiable, il faut savoir qui l’a demandé, reconnaître les doublons et pouvoir arrêter l’abonnement. Les événements du Model Context Protocol (MCP) et les extensions de ChatGPT rendent ce scénario possible à explorer, avec des limites précises.
Trois notions à distinguer
L’événement signale; l’abonnement autorise la réception
Un événement est une notification qu’un fait a eu lieu, par exemple « le document X a été modifié ». Un abonnement indique quels événements un serveur doit transmettre et pendant combien de temps. Une extension ajoute une surface d’affichage ou d’interaction, comme un panneau à côté de la conversation ou un lecteur de fichier. Ces éléments peuvent être combinés, mais ils ne font pas la même chose.
Le 29 septembre, OpenAI a annoncé la prise en charge des événements dans ses plugins MCP ainsi que de nouvelles extensions d’interface. La documentation précise que le serveur propose des événements auxquels l’utilisateur peut s’abonner, puis les transmet à ChatGPT par webhook. Un webhook est un appel HTTPS envoyé automatiquement à une adresse de réception lorsqu’un événement correspondant survient. Le produit ne transforme pas pour autant chaque événement en ordre fiable à exécuter. (OpenAI, récapitulatif DevDay du 29 septembre, OpenAI, événements MCP, OpenAI, extensions de plugins)
Le standard MCP possède, de son côté, un groupe de travail consacré aux déclencheurs et événements. Son existence décrit un travail de normalisation; elle ne signifie pas que toutes les applications MCP implémentent déjà les mêmes fonctions. (Groupe de travail MCP Triggers & Events)
Traiter l’événement comme une donnée à vérifier
Vérifier le callback avant d’envoyer le contenu
Dans notre exemple, une personne modifie un document. Le serveur peut notifier qu’un document précis a changé, et l’agent peut préparer un résumé en brouillon. Le texte reçu décrit ce changement; il ne devrait pas pouvoir modifier les règles de l’agent ni élargir les accès. Un commentaire intégré au document reste une donnée d’utilisateur, pas une instruction de confiance.
La documentation OpenAI demande de déclarer les événements et leurs filtres, puis de gérer les opérations de liste, d’abonnement et de désabonnement. Elle prévoit une URL de rappel vérifiée, un secret de signature et des abonnements persistants. Le serveur doit contrôler l’autorisation de l’utilisateur, valider les filtres et l’adresse de callback avant d’accepter l’abonnement. Les appels de vérification et de livraison doivent utiliser HTTPS et empêcher les destinations locales ou privées, afin qu’une adresse fournie ne puisse servir à atteindre un service interne. (OpenAI, cycle de vie et sécurité des événements MCP)
Cela ne garantit pas que les événements seront reçus dans l’ordre ni une seule fois. La documentation demande de conserver un identifiant stable lors des nouvelles tentatives et de rendre les opérations idempotentes, c’est-à-dire répétables sans produire un doublon. Elle signale également que les événements peuvent arriver dans le désordre. Il faut donc garder un journal de traitement avec au minimum l’identifiant d’événement, l’abonnement, le statut et la décision prise. Ces choix relèvent de l’architecture de votre serveur, pas d’une promesse de livraison exactement une fois.
Un essai prudent contient trois cas : le même événement est envoyé deux fois; l’adresse de réception échoue à la vérification; l’accès au document est retiré alors que l’abonnement existe encore. Le résultat attendu est explicite : ne pas générer deux résumés, ne pas transmettre de contenu en cas de callback invalide et arrêter les envois lorsque les droits disparaissent.
Prévoir l’abonnement, sa durée et son arrêt
La création ne suffit pas. Votre serveur doit stocker le propriétaire et les filtres de chaque abonnement, savoir le renouveler ou le supprimer, et revérifier que le compte garde accès à la ressource. À la déconnexion, à l’expiration ou lors d’une révocation, les envois doivent cesser. Pour un système qui ne peut pas rejouer les événements manqués, indiquez cette limite au lieu de laisser croire qu’aucune mise à jour ne sera perdue.
La page OpenAI précise que cette intégration MCP prend en charge le transport par webhook et la vérification du callback. Le polling et le streaming ne sont pas pris en charge; les notifications de contrôle gap et terminated du projet de protocole ne le sont pas non plus. Pour un événement sans mécanisme de reprise, une interruption peut donc créer un trou à traiter dans votre application. (OpenAI, limites de transport)
Choisir une extension utile au scénario
Pour un résumé de document, un panneau de conversation pourrait montrer le document source, l’état du résumé et les validations attendues. Un visualiseur pourrait rendre le fichier dans ChatGPT si son extension est prise en charge. La documentation énumère également les applications de barre latérale, les réglages, les modes d’affichage et les mentions du composeur. L’extension améliore la façon de consulter ou de choisir une ressource; elle ne remplace ni les contrôles d’accès du serveur ni la validation du contenu généré. (OpenAI, extensions disponibles)
La disponibilité varie selon l’interface et l’offre : OpenAI indique que les extensions Web pour les offres Free et Go sont à venir, tandis que les mentions du composeur sont réservées à l’application de bureau. Il faut revérifier ces conditions au moment de construire une intégration et prévoir un parcours simple sans panneau si la surface n’est pas disponible.
Commencer par un pilote en lecture seule
Utilisez un document fictif et limitez la première version à la préparation d’un résumé en brouillon. Évaluez les doublons, les callbacks rejetés, les révocations et les événements manquants. Aucun courriel ne part et aucune donnée réelle n’est modifiée. Une fois ce parcours compréhensible, vous pourrez décider si l’événement apporte une valeur que ne fournirait pas une simple demande ponctuelle.
Avant de déployer, documentez le propriétaire de l’abonnement, les sources autorisées, la conservation du journal et la personne responsable de la révocation. Gardez une commande ou une procédure d’administration qui désactive facilement les envois. C’est ce contrôle qui transforme un déclenchement automatique en mécanisme réversible, plutôt qu’en automatisation invisible.
Ce parcours complète notre guide consacré à l’architecture, aux autorisations et à la gouvernance de MCP.