Votre agent démarre quand
il se passe vraiment quelque chose
Un déclencheur répond à une seule question : quand est-ce que cet agent démarre ? Une tâche planifiée répond par une heure. Un déclencheur webhook répond par un événement venu de l'extérieur. Une pull request s'ouvre, un build casse, une alerte part, et l'agent tourne déjà.
AgentsRoom donne à chaque déclencheur une URL publique et un secret de signature. Vous collez l'URL dans GitHub, GitLab, Slack, Linear, Sentry ou tout ce qui sait faire un POST JSON. L'appel arrive, la signature est vérifiée, le payload devient des variables de votre prompt, et un vrai agent démarre dans votre projet, avec son terminal et son transcript.
Un déclencheur, une URL publique. L'événement arrive, la signature est vérifiée, le payload devient des variables du prompt, et un agent démarre dans votre projet.
Les tâches planifiées réglaient la moitié du problème. Vous pouvez déjà demander à un agent de relire les pull requests tous les matins à 8 h. Sauf que l'essentiel du travail qu'on confierait à un agent n'arrive pas à 8 h : il arrive quand quelqu'un ouvre une pull request, quand le build passe au rouge, quand un client remonte un bug à 14 h.
Jusqu'ici, la seule façon d'attraper ça, c'était de faire surveiller : lancer l'agent sur un intervalle court, lui faire interroger l'API, demander « du nouveau ? », et payer des tokens pour la réponse « non » plusieurs centaines de fois par jour. C'est cher, ça réagit lentement, et ça devient ingérable dès qu'on veut surveiller trois dépôts.
Un déclencheur webhook inverse le sens. C'est le service qui vous prévient. AgentsRoom vous donne une URL, vous la collez dans GitHub, GitLab, Slack, Linear, Sentry ou votre CI, et rien ne tourne tant que ce service n'appelle pas. Quand il appelle, l'agent démarre avec l'événement déjà dans son prompt. Zéro token quand la journée est calme, un agent sur le coup en quelques secondes quand elle ne l'est pas.
Pourquoi un événement bat une boucle de surveillance
Vous arrêtez de payer le silence. Un agent qui vérifie un dépôt toutes les cinq minutes consomme un tour de contexte complet toutes les cinq minutes, et presque tous ces tours ne trouvent rien. Un déclencheur ne consomme rien du tout tant que l'événement n'arrive pas.
La réaction est immédiate. Pas d'intervalle à régler, pas de fenêtre où une pull request attend onze minutes parce que la vérification vient juste de passer. L'agent démarre sur l'appel, donc la relecture est déjà là quand l'auteur rafraîchit sa page.
L'événement arrive avec ses données. Le payload est transformé en variables que vous glissez directement dans le prompt : le titre, l'auteur, l'URL, le numéro, la branche, ou tout le JSON brut. L'agent n'a pas à aller chercher ce qui l'a réveillé.
C'est la fenêtre que vous connaissez déjà. Les déclencheurs gardent la liste, l'interrupteur on/off, l'historique par exécution, le choix de l'agent et la portée par machine des tâches planifiées. Un webhook, c'est juste une autre réponse à « quand est-ce que ça part ».
Un déclencheur, deux façons de partir
La fenêtre porte les deux. Prenez celle qui correspond à ce que vous attendez.
Planifié
Le mode d'origine, inchangé. Toutes les N minutes, chaque heure, chaque jour, chaque semaine ou chaque mois, sans expression cron à écrire. Pour le travail qui appartient à une horloge : la relecture du matin, l'audit de dépendances du lundi, le changelog du vendredi.
Webhook
L'agent attend un événement au lieu d'une heure. AgentsRoom vous donne une URL publique et un secret de signature, vous collez l'URL dans le service, et le déclencheur part quand ce service envoie son POST. Pour le travail qui appartient à un événement : une pull request, un build en échec, un nouveau bug.
Quoi déclencher
Des événements réels, et l'agent qu'on voudrait au bout du fil.
Relire chaque pull request dès son ouverture
Pointez un webhook GitHub ou GitLab sur le déclencheur, filtrez sur l'ouverture de la pull request, et un agent relecteur attaque le diff en quelques secondes. L'auteur reçoit un retour pendant qu'il a encore le changement en tête.
Enquêter automatiquement sur un build rouge
Votre CI peut envoyer un POST quand un pipeline échoue. Le déclencheur démarre un agent avec la branche et l'URL du run dans son prompt : il lit le job qui a cassé et revient avec une cause plutôt qu'avec un badge rouge.
Trier un crash dès qu'il est remonté
Branchez une alerte Sentry sur un déclencheur. Une nouvelle exception en production démarre un agent backend avec le titre de l'erreur et l'URL du ticket, donc le premier coup d'œil à la stack trace a lieu avant que quiconque ouvre le dashboard.
Démarrer un agent depuis Slack
Une slash command ou un webhook sortant Slack peut appeler l'URL du déclencheur. Quelqu'un tape la demande dans un canal, le payload atterrit dans le prompt, et l'agent la prend dans le bon projet.
Cadrer un ticket dès qu'il est créé
Un ticket créé sur GitHub, GitLab ou Linear démarre un agent produit qui lit le signalement, pose les questions manquantes et le transforme en quelque chose qu'un développeur peut prendre.
Lancer une passe de QA après chaque déploiement
Votre pipeline de déploiement envoie un POST quand une release part. Le déclencheur démarre un agent QA qui teste l'app sur la version qui vient d'être livrée, au lieu d'un horaire qui n'a rien à voir avec les releases.
Écrire les notes de version au tag
Un tag poussé, une release publiée, et un agent documentation transforme les commits en notes lisibles. L'événement porte le nom du tag, donc l'agent sait exactement quelle plage résumer.
Tout ce qui sait envoyer du JSON
Il n'y a pas de liste d'intégrations à attendre. Un cron sur un serveur, une étape Zapier, un outil de monitoring, votre propre backend : si ça sait envoyer un POST signé sur une URL, ça sait démarrer un agent dans votre projet.
Comment marche un déclencheur webhook, étape par étape
D'un formulaire vide à un agent qui réagit à la production, en deux minutes.
Créez un déclencheur
Ouvrez la fenêtre Déclencheurs sur votre projet et créez-en un. Même liste, même interrupteur on/off, même historique qu'une tâche planifiée, parce que c'est la même fenêtre.
Passez-le en Webhook
Choisissez Webhook au lieu de Planifié. AgentsRoom génère une URL publique pour ce déclencheur, avec un secret de signature juste à côté. Le secret se régénère quand vous voulez, pour couper l'accès à qui avait l'ancien.
Collez l'URL dans le service
Déposez-la dans un webhook GitHub ou GitLab, une app Slack, une intégration Linear ou Sentry, ou votre CI. Donnez aussi le secret de signature au service, pour que ses appels soient vérifiables.
Filtrez ce qui doit vraiment partir
Un dépôt envoie beaucoup d'événements. Ajoutez une condition facultative sur le payload, par exemple action égal à opened, et tout le reste est ignoré. Posez un anti-rafale pour qu'un service bavard ne démarre pas vingt agents en une minute.
Mettez l'événement dans votre prompt
Écrivez le prompt avec les variables de l'événement : le titre, l'auteur, l'URL, le numéro, la branche, ou tout le payload. Elles sont résolues au moment du tir, exactement comme les variables de date et d'heure des tâches planifiées.
Rejouez le dernier appel et lancez
L'éditeur affiche le dernier appel reçu par le déclencheur, JSON brut compris, et le rejoue en un clic. On câble un webhook en le regardant, pas en devinant, et une fois que c'est juste on allume le déclencheur.
La rangée de services est une liste de raccourcis, pas une liste blanche. L'éditeur le dit sous le sélecteur, et c'est pour ça que la première entrée est Any service (JSON) : tout ce qui sait envoyer un corps JSON en POST fonctionne. Choisir GitHub, GitLab, Slack, Linear ou Sentry ajoute exactement deux choses, la vérification de l'en-tête de signature propre à ce service et ses champs de payload déjà transformés en variables d'événement. Rien n'est refusé au motif que ce n'est pas dans la liste.
Les pastilles de variables ne sont pas de la documentation, ce sont des boutons : un clic l'insère dans le prompt, et celles que le dernier appel a réellement remplies sont mises en évidence. Juste en dessous se trouve le dernier appel reçu par le déclencheur : vous écrivez donc le filtre et le prompt sur un vrai payload que vous voyez, vous le rejouez, et vous n'allumez le déclencheur que quand l'exécution sort juste.
- L'événement arrive sur l'URL du déclencheur
Le service envoie son JSON. AgentsRoom vérifie la signature avec votre secret et rejette tout appel non signé, puis applique votre filtre si vous en avez posé un.
- Il attend si personne n'est là
Votre machine peut être éteinte. L'événement est conservé une semaine au plus et rejoué au lancement suivant au lieu d'être perdu, exactement le rattrapage que les tâches planifiées font déjà.
- Une seule machine le prendMac du bureauMac persoMachine de build
Si plusieurs ordinateurs ont le projet ouvert, le premier qui saisit l'événement le verrouille. Les autres voient qu'il est pris et passent leur tour, donc un événement ne produit jamais deux agents.
- L'agent s'exécute, une fois
Un vrai agent s'ouvre dans le projet, avec le rôle, le provider et le modèle que vous avez choisis, son terminal, sa vue conversation et un transcript archivé que vous relisez plus tard.
Une URL publique qui n'est pas une porte ouverte
L'URL est joignable depuis Internet, donc le déclencheur décide ce qu'il accepte avant que quoi que ce soit démarre.
Chaque appel est signé
Avant que quoi que ce soit démarre, AgentsRoom vérifie chaque appel avec votre secret : X-Hub-Signature-256 pour GitHub, X-Slack-Signature pour Slack, le token partagé X-Gitlab-Token pour GitLab, et un HMAC du corps brut pour Linear, Sentry et les sources génériques. Un appel sans signature est rejeté : connaître l'URL ne suffit pas à démarrer un agent sur votre machine.
Régénérez le secret quand vous voulez
Le secret de signature est affiché dans l'éditeur et se régénère sur place. Les anciens appels cessent immédiatement d'être valides, ce qui est exactement ce qu'on veut le jour où un service est débranché ou qu'un secret fuit dans un log.
Filtrez sur le payload
Une condition facultative décide si l'événement mérite un agent. Ne partir que si action vaut opened, que sur une branche, que pour un label. Tout ce qui ne correspond pas est écarté sans rien démarrer.
Anti-rafale
Au maximum une exécution par fenêtre de temps. Un service qui envoie trente événements en dix secondes ne démarre pas trente agents : les appels de la fenêtre sont regroupés et une seule exécution les couvre.
Le payload devient votre prompt
Le JSON envoyé par le service est transformé en variables que vous écrivez directement dans le prompt. Elles sont résolues au moment du tir, comme les variables de date et d'heure déjà utilisées par les tâches planifiées.
Vous écrivez le prompt une fois, et chaque exécution reçoit les données de l'événement qui l'a déclenchée.
{{event.title}}Le titre de l'événement : titre de la pull request, du ticket, nom de l'alerte.{{event.author}}Qui l'a provoqué : l'auteur de la pull request, la personne qui a ouvert le ticket.{{event.url}}Le lien vers l'événement, pour que l'agent puisse ouvrir la pull request ou l'alerte.{{event.number}}Le numéro de la pull request ou du ticket, quand le service en envoie un.{{event.branch}}La branche concernée, pour un push, une pull request ou un build en échec.{{payload}}Tout le JSON brut, pour ce que les variables nommées ne couvrent pas.
Review pull request #{{event.number}} "{{event.title}}" opened by {{event.author}} on branch {{event.branch}}. Read the diff at {{event.url}} and reply with the risky parts first.Les noms de variables s'écrivent entre doubles accolades dans le champ prompt, exactement comme les variables de date et d'heure d'une tâche planifiée.
event.actionevent.numberevent.titleevent.bodyevent.authorevent.branchevent.baseevent.urlevent.repositoryevent.stateevent.actionevent.numberevent.titleevent.bodyevent.authorevent.branchevent.baseevent.urlevent.repositoryevent.stateevent.actionevent.titleevent.bodyevent.authorevent.channelevent.urlevent.teamevent.actionevent.numberevent.titleevent.bodyevent.authorevent.assigneeevent.stateevent.priorityevent.urlevent.teamevent.actionevent.titleevent.bodyevent.levelevent.projectevent.urlevent.countevent.actionevent.titleevent.bodyevent.authorevent.urlevent.idCe qui s'exécute vraiment, et où
Le même modèle d'exécution honnête que les tâches planifiées, étendu aux événements.
D'où viennent les événements
Tout ce qui sait envoyer un POST signé avec un corps JSON peut démarrer un agent. Voici ce que les gens branchent en premier.
Votre CI, votre backend, n'importe quoi
Une étape de pipeline, un outil de monitoring, un service interne, un script shell avec curl. Il n'y a pas d'intégration à demander : un POST avec un corps JSON et une signature, c'est tout le contrat.
GitHub et GitLab
Pull requests et merge requests ouvertes, relues ou fusionnées, tickets créés, push, releases, workflows en échec. La source classique, et celle dont le payload est le plus utile.
Slack
Une slash command ou un webhook sortant transforme un message dans un canal en exécution d'agent dans le bon projet. Les signatures Slack sont vérifiées avec X-Slack-Signature.
Linear et Sentry
Un ticket déplacé dans une colonne, une nouvelle exception en production, une alerte de régression. L'outil de suivi part, l'agent démarre avec le ticket ou l'erreur dans son prompt.
L'autre moitié de la même fenêtre
Les déclencheurs et les tâches planifiées sont une seule feature avec deux réponses à la même question. Une tâche planifiée est un déclencheur dont l'événement est une horloge. Un déclencheur webhook est une tâche planifiée dont l'horaire est le monde extérieur. Ils vivent dans la même liste et partagent la même configuration d'agent, le même interrupteur, le même historique d'exécutions et la même portée par machine.
Vous choisissez donc par travail plutôt que par outil. L'audit de dépendances reste le lundi matin, parce que rien à l'extérieur n'annonce qu'un paquet a vieilli. La relecture de pull request passe en webhook, parce que GitHub connaît déjà la seconde exacte où elle doit avoir lieu. La page des tâches planifiées couvre le côté horloge de la famille.
Voir les tâches planifiées, le côté horloge de la même fenêtreFAQ
Qu'est-ce qu'un déclencheur webhook dans AgentsRoom ?
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.
Quelle différence avec une tâche planifiée ?
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, chaque semaine ou chaque mois. Un déclencheur webhook part sur un événement extérieur. 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.
Pourquoi ne pas simplement faire interroger l'API par un agent ?
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.
Est-ce prudent d'exposer l'URL du déclencheur ?
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, Sentry et les sources génériques. 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.
Puis-je ne partir que sur certains événements ?
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.
Que se passe-t-il si AgentsRoom est fermé quand l'événement arrive ?
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.
J'ai le projet ouvert sur deux ordinateurs. L'agent va-t-il s'exécuter deux fois ?
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.
Que puis-je mettre dans le prompt depuis l'événement ?
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.
Comment savoir si mon webhook est bien câblé ?
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.
Quels services sont pris en charge ?
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.
Est-ce un éditeur visuel de scénarios en plusieurs étapes ?
Non, et ce n'est pas le but. Un déclencheur a un seul rôle : décider quand un agent démarre et lui remettre l'événement. La partie en plusieurs étapes, c'est l'agent lui-même, qui lit le code, lance les outils et fait le travail. Si vous voulez que plusieurs agents se passent le relais, c'est le rôle des équipes d'agents, pas d'un canevas de scénarios.
AgentsRoom peut-il envoyer des webhooks vers d'autres services ?
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.
Fonctionne bien avec
Tâches planifiées
Le côté horloge de la même fenêtre. Toutes les N minutes, chaque heure, chaque jour, chaque semaine ou chaque mois, sans expression cron à écrire.
Backlog en tableau
Vous glissez un ticket dans une colonne et un agent le prend. Un déclencheur fait pareil, sauf que c'est un événement extérieur qui le glisse.
Équipes d'agents
Des agents dev, QA et PM qui se passent le travail. Pointez un déclencheur sur une équipe et un événement lance toute la routine.
AgentsRoom MCP
Les outils avec lesquels un agent lit le backlog, la mémoire et la bibliothèque de prompts. Un agent déclenché y a droit comme les autres.
Notifications d'agents
Sachez à la seconde où un déclencheur part, sur le bureau et sur votre téléphone, avec un appui pour ouvrir l'agent qu'il a démarré.
Flotte de machines
Plusieurs machines sur un compte. Épinglez un déclencheur à celle qui doit répondre, et elle seule exécute l'agent.
Arrêtez de surveiller. Réagissez.
Téléchargez AgentsRoom, collez une URL dans GitHub, GitLab, Slack, Linear ou Sentry, et laissez l'événement démarrer l'agent. Rien ne tourne tant qu'il ne se passe rien.
App companion : suivez vos agents en déplacement
Utilisez Claude, Codex, Antigravity CLI ou un autre fournisseur IA.
Remontez bugs et demandes directement dans votre backlog public.
Aperçu d'AgentsRoom en action.