AIREITERFactory Automations peut lancer une session Droid selon un calendrier, à partir d’un message Slack de premier niveau, d’un événement GitHub ou d’une requête HTTP entrante. Les déclencheurs webhook sont encore en Private Preview, tandis que les planifications utilisent des horaires UTC fixes et ne tiennent pas automatiquement compte du passage à l’heure d’été ou d’hiver. L’outil se prête à un pilote limité, pas à un déploiement en production sans garde-fous.
Ce que Factory Automations exécute réellement
Chaque automatisation associe un déclencheur, des consignes, une identité et une cible d’exécution (documentation Factory).
| Déclencheur | Ce qui lance l’exécution | Particularité principale |
|---|---|---|
| Planification | Fréquence en langage naturel ou expression cron à cinq champs | S’exécute sur un ordinateur ou une cible d’exécution sélectionnée ; les ordinateurs gérés prennent en charge 10 automatisations, dont 5 planifiées à la minute |
| Slack | Message de premier niveau correspondant aux critères dans un canal | Répond dans le fil du message d’origine |
| GitHub | Pull requests, commentaires, pushes, labels, vérifications ou planification | S’exécute dans GitHub Actions après la finalisation de la configuration |
| Webhook | Requête HTTP POST envoyée par un autre service | Droid Computer ou modèle d’exécution ; Private Preview |
Une automatisation peut rester privée ou être partagée avec une organisation. La confidentialité des sessions est un réglage distinct : elle détermine qui peut ouvrir les sessions créées par les exécutions.
Le déclencheur choisi détermine le fonctionnement opérationnel
Exécutions planifiées : le meilleur point de départ
Les planifications acceptent des formulations simples comme « every Monday at 9am PST » ou une expression cron telle que 0 9 * * 1. Factory affiche un aperçu de l’horaire obtenu, mais cron fonctionne en UTC. Lorsqu’un fuseau horaire est indiqué en toutes lettres, il est converti en une planification UTC fixe qui ne s’ajuste pas automatiquement au changement d’heure (documentation Factory).
Pour commencer, les bons candidats sont un récapitulatif quotidien d’état, un audit des dépendances, une vérification de documentation obsolète ou un agent de revue de pull request qui prépare les éléments d’analyse sans fusionner de code.
Messages Slack : pratiques, mais limités aux signaux de premier niveau
Une automatisation Slack démarre lorsqu’un message de premier niveau correspondant aux critères apparaît dans un canal accessible. Les réponses dans un fil ne déclenchent pas indépendamment une nouvelle exécution. Les filtres peuvent porter sur le motif du canal, le type d’expéditeur, des mots-clés, des mots-clés à exclure ou des expéditeurs à ignorer.
Les exécutions répondent dans le fil du message déclencheur. Si plusieurs automatisations correspondent, seule la première y répond ; les autres publient des messages séparés contenant un lien vers l’original. Factory documente ces comportements, ainsi que les règles d’accès aux canaux privés (documentation Factory). C’est adapté à un canal d’incident maîtrisé, mais pas aux workflows qui dépendent de chaque réponse publiée dans un fil.
Événements GitHub : puissants, mais soumis à une étape de configuration visible
Les automatisations GitHub personnalisées peuvent réagir aux pull requests, aux pushes, aux commentaires, aux changements de labels, aux vérifications terminées ou à une planification. Elles s’exécutent dans GitHub Actions, et leur création ouvre une pull request de configuration dans chacun des dépôts sélectionnés.
Cette pull request de configuration doit être fusionnée avant l’activation du workflow. Les exécutions lancées avant l’arrivée du workflow sur la branche par défaut échouent ; l’automatisation ne peut pas non plus publier de commentaires, pousser des commits ou ouvrir des pull requests avant cette étape. GitHub est le déclencheur le plus solide lorsque le travail récurrent correspond déjà à un événement du dépôt et que la revue classique des pull requests reste la limite avant mise en production.
Webhooks : une vraie capacité, mais une disponibilité limitée
Factory présente les automatisations webhook comme une fonctionnalité en Private Preview et demande aux organisations de contacter le support pour l’activer. Un webhook lance une exécution à partir d’une requête HTTP POST externe, mais il ne peut pas fonctionner sur l’ordinateur local d’un utilisateur : il lui faut un Droid Computer ou un modèle d’exécution.
Factory fournit une URL de webhook, une option d’en-tête X-Webhook-Secret et un format d’URL pour les émetteurs incapables de définir des en-têtes. La documentation recommande l’en-tête, car les secrets placés dans une URL peuvent apparaître dans les journaux ; le secret n’est affiché qu’une seule fois et sa rotation invalide l’ancienne valeur (documentation Factory sur les webhooks).
Cette même documentation fixe une limite de 200 KiB pour le corps de la requête, 60 requêtes acceptées par minute, une conservation des enregistrements de livraison pendant 30 jours, une fenêtre de déduplication de 10 minutes pour les corps identiques et un plafond de 10 exécutions par heure. Ces garde-fous rendent les webhooks testables pour la gestion des alertes, mais leur statut de fonctionnalité en aperçu reste un obstacle dès qu’un accès prévisible est nécessaire en production.
Les contrôles qui déterminent si l’automatisation est sûre
Les automatisations planifiées, Slack et webhook peuvent s’exécuter au nom de l’utilisateur ou d’un compte de service partagé. L’identité choisie influe sur l’accès aux connecteurs, la facturation et l’attribution dans Slack ; les règles liées aux cibles d’exécution sont détaillées dans la documentation Factory.
Gardez les consignes étroitement délimitées, utilisez des identifiants révocables, choisissez une cible d’exécution dédiée et laissez les contrôles de déploiement et de fusion aux mécanismes déjà en place dans les dépôts. La fiche de Factory dans Slack Marketplace précise explicitement que l’application peut commettre des erreurs et recommande de vérifier le code et les réponses.
Un utilisateur a signalé des lacunes de supervision, notamment l’absence d’application de bureau Linux et de synchronisation entre ordinateurs (publication de @JoelDeTeves sur X) ; c’est un point important pour les équipes qui souhaitent superviser un travail automatisé de longue durée loin de leur ordinateur de bureau.
Factory Automations face à une simple GitHub Action
| Besoin | Factory Automations | Simple GitHub Action |
|---|---|---|
| Exécuter une consigne sur un dépôt | Session Droid native et cible d’exécution | L’équipe fournit le runtime de l’agent et le code du workflow |
| Travail planifié | Langage naturel ou cron, avec la contrainte UTC | Cron GitHub et logique personnalisée |
| Déclencheur Slack | Messages de premier niveau avec filtres et réponses dans les fils | Configuration d’une application Slack ou d’un webhook |
| Événement GitHub | Pull request de configuration guidée et exécution dans GitHub Actions | Fichier de workflow direct |
| Webhook | Intégré, mais en Private Preview | Construire le point d’accès, l’authentification, les nouvelles tentatives et le worker |
| Limite de revue | Peut préparer le travail pour une revue humaine | Dépend des permissions du workflow |
Choisissez une GitHub Action lorsque la tâche relève d’une plomberie API déterministe, comme un récapitulatif quotidien des pull requests. Factory est plus pertinent lorsque l’étape récurrente demande une investigation, du contexte sur le dépôt, une proposition de modification du code ou une session lisible par un humain. Il n’est pas utile d’adopter une plateforme d’agents simplement pour éviter d’écrire un petit script.
Un pilote à faible risque pour gagner progressivement en autonomie
- Choisissez une tâche récurrente avec un périmètre d’entrée bien défini, par exemple la revue des nouvelles pull requests ou la vérification de fichiers générés.
- Commencez par une automatisation planifiée plutôt que par un webhook ; vous évitez ainsi l’accès en aperçu et rendez la cadence facile à contrôler.
- Faites produire un rapport ou une pull request, pas un déploiement ou une fusion.
- Consignez les exécutions échouées, les tâches bloquées, les fichiers modifiés et les corrections humaines ; les seules pull requests acceptées ne constituent pas une preuve suffisante.
- N’élargissez qu’une seule dimension à la fois : une autre catégorie de tâche, un autre dépôt ou un autre déclencheur.
Les recommandations de Factory sur les workflows préconisent de reproduire l’échec initial, de tester la correction dans un environnement propre et de vérifier un cas voisin avant de conserver une consigne réutilisable. C’est une bonne exigence pour un pilote d’Automation.
FAQ
Factory Automations prend-il en charge les webhooks ?
Oui, mais les déclencheurs webhook sont en Private Preview et peuvent nécessiter une activation au niveau de l’organisation. Les exécutions requièrent un Droid Computer ou un modèle d’exécution. Les détails figurent dans la section consacrée aux webhooks.
Les réponses dans les fils Slack déclenchent-elles une automatisation ?
Non. Seul un message de premier niveau correspondant aux critères lance l’exécution ; voir la section Messages Slack.
La planification tient-elle compte du changement d’heure ?
Non. Factory enregistre une planification UTC fixe ; vérifiez-la lorsque les règles locales de changement d’heure évoluent. Voir la section Exécutions planifiées.
Les automatisations GitHub s’exécutent-elles avant la fusion de la pull request de configuration ?
Non. La pull request de configuration doit d’abord atteindre la branche par défaut ; les exécutions antérieures échouent. Voir la section Événements GitHub.
Que se passe-t-il lorsqu’une livraison webhook est répétée ?
Un corps identique reçu dans les 10 minutes est enregistré comme Deduped et ne lance pas une nouvelle exécution. Factory enregistre également les livraisons filtrées, limitées par le débit, ignorées et échouées.
Le compromis à garder en vue
Lancez un pilote sur une tâche planifiée ou déclenchée par GitHub lorsque le résultat peut rester dans une boucle de revue via pull request. Slack est pratique si l’équipe adopte des conventions de messages de premier niveau ; les webhooks sont suffisamment détaillés pour être testés, mais leur statut de Private Preview signifie qu’ils ne devraient pas encore soutenir un système d’incident en production.