Votre agent démarre quand
il se passe vraiment quelque chose

C'est un déclencheur qui démarre un agent IA quand un service externe lui envoie un événement, au lieu de partir à une heure fixe. AgentsRoom donne au déclencheur une URL publique et un secret de signature ; vous collez l'URL dans GitHub, GitLab, Slack, Linear, Sentry ou n'importe quel outil capable d'envoyer un POST JSON. Quand ce service appelle, la signature est vérifiée, votre filtre facultatif est appliqué, et un agent démarre dans votre projet avec le payload déjà disponible sous forme de variables du prompt.

Seule la question « quand est-ce que ça part » change. Une tâche planifiée part sur une horloge (toutes les N minutes, chaque heure, chaque jour à un ou plusieurs horaires, chaque semaine ou chaque mois) ou sur la fenêtre de quota de votre abonnement IA (au retour du quota, ou avant sa réinitialisation). Un déclencheur webhook part sur un événement extérieur. Un déclencheur à la demande ne part sur rien du tout : il attend que vous appuyiez sur son bouton. Tout le reste est commun : la même liste, le même interrupteur, la même configuration d'agent, le même historique par exécution, la même portée par machine.

Parce que la surveillance en boucle coûte des tokens à chaque tour, et que presque chaque tour ne trouve rien. Un agent qui vérifie un dépôt toutes les cinq minutes exécute un tour complet toutes les cinq minutes pour répondre « non ». Un déclencheur webhook ne consomme rien tant qu'il ne se passe rien, et réagit en quelques secondes quand il se passe quelque chose. C'est tout l'argument économique de la feature.

L'URL seule ne suffit à rien démarrer. Chaque appel doit prouver qu'il vient du service qui détient votre secret : X-Hub-Signature-256 pour GitHub, X-Slack-Signature pour Slack, le token partagé X-Gitlab-Token pour GitLab, un HMAC du corps brut pour Linear et Sentry, et pour une source générique une signature qui couvre aussi un horodatage et un identifiant de livraison, si bien qu'un appel intercepté ne peut pas être renvoyé. Un appel sans en-tête de signature est rejeté, jamais laissé passer. Le secret est affiché dans l'éditeur et se régénère à tout moment, ce qui invalide immédiatement ce qui utilisait l'ancien.

Oui. Un dépôt envoie beaucoup plus d'événements que ceux qui méritent un agent, donc un déclencheur accepte une condition facultative sur le payload, par exemple action égal à opened. Les événements qui ne correspondent pas sont ignorés et rien n'est démarré. Il y a aussi un anti-rafale : au maximum une exécution par fenêtre de temps, les appels arrivés dans cette fenêtre étant regroupés.

L'événement est mis en file côté serveur et rejoué au lancement suivant de l'app : il s'exécute en retard plutôt que jamais. Les événements en file sont conservés une semaine, ce qui couvre un portable fermé pendant un long week-end sans rejouer un mois de travail périmé à votre retour. C'est le même modèle « dans l'app plus rattrapage » que les tâches planifiées. Les déclencheurs webhook ne font pas tourner votre agent dans le cloud : l'agent s'exécute toujours sur votre machine, dans votre projet.

Non. Un événement n'est consommé qu'une fois. La première machine qui le prend le verrouille, et les autres voient qu'il est pris et passent leur tour. Vous pouvez aussi épingler un déclencheur à des machines précises, exactement comme une tâche planifiée, si vous voulez qu'un ordinateur donné en soit responsable.

Le payload est transformé en variables que vous écrivez directement dans le champ prompt, entre doubles accolades : event.title, event.author, event.url, event.number, event.branch, et payload pour tout le JSON brut. Elles sont résolues au moment où le déclencheur part, comme les variables de date et d'heure d'une tâche planifiée.

L'éditeur affiche le dernier appel reçu par le déclencheur, corps JSON brut compris, et permet de le rejouer en un clic. Vous réglez donc le filtre et le prompt sur un vrai payload que vous voyez, puis vous rejouez jusqu'à ce que l'exécution soit juste, au lieu de pousser des commits de test pour découvrir le résultat.

Tous ceux qui savent envoyer un POST signé avec un corps JSON. GitHub, GitLab, Slack, Linear et Sentry sont ceux que les gens branchent en premier parce que leurs payloads sont riches, mais il n'y a pas de liste fermée : un job de CI, un outil de monitoring, votre propre backend ou un curl dans un script shell marchent exactement pareil.

Non, et ce n'est pas le but. Un déclencheur a un seul rôle : décider quand une exécution démarre et lui remettre l'événement. La partie en plusieurs étapes appartient à ce vers quoi il pointe. C'est en général un agent seul, qui lit le code, lance les outils et fait le travail ; quand vous voulez que plusieurs agents se passent le relais, pointez plutôt le déclencheur sur une équipe d'agents et l'événement lance tout le pipeline, portes de qualité et boucles de retour comprises. Ce que vous ne dessinez jamais ici, c'est un canevas de scénarios fait de boîtes et de flèches autour d'une API.

Les déclencheurs sont entrants uniquement : AgentsRoom reçoit des événements, il n'en émet pas. Si vous voulez qu'un agent appelle un service externe en fin d'exécution, c'est le travail de l'agent, avec les outils et les serveurs MCP que vous lui avez donnés.

Oui, avec une exécution restreinte. Un payload écrit par un inconnu peut cacher des instructions destinées à l'agent, donc AgentsRoom ne compte pas sur le prompt pour les contenir : en exécution restreinte, la CLI de l'agent refuse elle-même le shell, le web et tous les outils AgentsRoom, garde les fichiers du projet en lecture seule et n'appelle que les outils MCP que vous avez autorisés. Donnez au déclencheur son propre identifiant via le serveur MCP qui en a besoin, et l'agent peut publier sa revue sans jamais voir le jeton. Claude Code et Codex le prennent en charge ; les autres CLI refusent de démarrer une telle exécution.

Oui. En plus d'un agent ou d'une équipe, un déclencheur peut lancer une action du tableau : Démarrer le prochain ticket À faire. Elle fait exactement ce que fait le bouton du tableau, prend le ticket en tête de À faire en sautant ceux encore bloqués par un autre, et le démarre avec son agent ou son équipe. Le déclencheur n'a pas de prompt et ne fait aucun appel IA : une pull request fusionnée, une CI verte ou un horaire font avancer un pipeline « un ticket, un agent » sans payer un tour d'agent dont le seul travail serait d'appuyer sur ce bouton.