Automatisez le travail. Prouvez-le d’abord.

Non. Vous choisissez un déclencheur, ajoutez des filtres depuis des listes déroulantes et choisissez des actions — et avec vingt-six recettes prêtes à l’emploi, vous partez le plus souvent de quelque chose qui fonctionne déjà. Les conditions sont des groupes tous/au moins un/aucun imbriqués avec douze comparaisons, volontairement pas un langage de formules : avec une formule, « que fait vraiment cette règle ? » ne se répondrait qu’en l’exécutant. Les webhooks et les espaces réservés sont là pour les rares cas où il faut aller plus loin, et ils restent facultatifs.

De quatre façons, avant qu’elle ne tourne pour de vrai. Le constructeur vous réécrit toute la règle en une phrase claire pendant que vous la composez. Une simulation exécute chaque étape sur un objet réel de votre compte sans rien changer, et indique pour chacune ce qu’elle ferait. Une règle enregistrée se teste quand vous le voulez. Et le backtest rejoue votre déclencheur et vos filtres sur votre propre historique d’événements et vous dit combien de fois la règle se serait déclenchée sur les trente derniers jours, et sur quoi. La plupart des moteurs de règles de cette catégorie n’en proposent aucune.

Dans les deux sens. Les événements de GitHub, Jira, Linear et PagerDuty déclenchent des règles — un workflow en échec, une pull request fusionnée, une release publiée, un incident escaladé — et les règles agissent en retour : ouvrir, étiqueter, assigner, commenter ou fermer un ticket, fusionner une pull request, demander une revue, lancer ou relancer un workflow, créer une release ou un déploiement, poser un statut de commit, faire avancer un ticket, ou créer et commenter une page Notion. Cela fait 32 actions via des comptes connectés, en plus des 47 intégrées.

Cela dépend de la façon dont elle a échoué, et c’est bien le sujet. Une panne passagère est retentée avec des pauses croissantes — 30 secondes, puis deux, cinq, dix et quinze minutes — et si elle ne passe jamais, l’exécution est abandonnée, la raison consignée, plutôt que de rester bloquée. Une permission que votre identifiant n’a pas arrête au contraire la règle immédiatement, nomme cette permission telle que le fournisseur l’écrit, et vous prévient, car quatre tentatives de plus seraient quatre refus identiques. Cinq exécutions en échec d’affilée désactivent une règle, la raison consignée. Vous pouvez aussi demander, étape par étape, que l’exécution continue malgré tout.

Plusieurs choses rendent cela difficile. Rien ne tourne tant que vous n’avez pas enregistré et activé une règle, et vous pouvez la simuler avant. Tout ce qui est irréversible peut passer derrière « Exiger une approbation », qui retient l’exécution jusqu’à ce qu’une personne désignée dise oui — et un refus met fin à l’exécution plutôt que de sauter l’étape. Une règle agit avec les droits d’une vraie personne, pas d’un compte de service illimité. Une exécution utilise une copie gelée de la règle : une modification en cours de route ne change rien à ce qui est déjà lancé. Et chaque exécution figure dans le journal d’audit, une règle supprimée restant restaurable quatorze jours.

Oui. Toutes les heures, chaque jour, chaque semaine, chaque mois, toutes les N minutes, ou une expression cron brute si vous préférez — dans le fuseau de votre organisation, avec les prochaines exécutions affichées avant d’enregistrer, pour voir que vous n’avez pas écrit 09:00 dans le mauvais fuseau. Les règles s’exécutent aussi à la main, ou se déclenchent depuis un webhook entrant auquel n’importe quel outil peut poster.

Trois règles dans l’offre gratuite, vingt-cinq sur Pro et illimité sur Business — chacune avec autant de conditions et d’actions que nécessaire. Toutes les actions sont disponibles dans l’offre gratuite, sauf les onze qui allument et éteignent des serveurs ou modifient les réglages Cloudflare, réservées à Pro. L’historique d’exécution, les simulations et le backtest ne sont pas limités du tout.