Trigger
Définition
Événement qui démarre un workflow : nouveau formulaire reçu, nouveau lead dans le CRM, horaire de cron, webhook entrant. Toutes les automatisations commencent par un trigger.
Comment ça marche
Un trigger est l'événement qui démarre l'exécution d'un workflow d'automatisation. Trois mécanismes principaux existent. Le webhook : le service tiers fait un POST HTTP sur une URL dédiée dès qu'un événement se produit (paiement Stripe, nouveau lead HubSpot, message Slack). Le polling : le système d'automatisation interroge périodiquement une API (toutes les 5 minutes par exemple) pour voir s'il y a du nouveau. Le cron : un workflow se lance à des intervalles fixes (chaque matin à 9h, chaque lundi). Chaque mécanisme a ses avantages selon la latence acceptable et la nature de la source.
Webhook vs polling vs cron
Le webhook est temps réel : moins d'une seconde entre l'événement et l'exécution. Idéal pour les actions critiques (paiement, notification). Inconvénient : le service tiers doit le supporter. Le polling est plus lent (5 à 15 minutes de latence selon la fréquence) mais marche avec n'importe quelle API. Idéal pour les sources qui n'ont pas de webhook. Inconvénient : consomme des appels API même s'il n'y a rien de nouveau. Le cron est le plus simple : un horaire fixe, indépendant des événements. Idéal pour les batches périodiques (rapports, synchros nocturnes). Inconvénient : pas réactif.
À quoi ça sert
Les triggers déterminent quand et comment un workflow s'exécute. Pour un workflow critique (notifier le sales dès qu'un nouveau lead arrive), on veut un webhook ou un trigger natif type "new HubSpot contact". Pour un workflow de synchronisation (envoyer les commandes Shopify de la journée vers la compta chaque soir), un cron à 23h suffit. Pour intégrer un service sans webhook (vieille API SOAP, base interne), on polle toutes les 5 minutes. Le bon choix de trigger est souvent la décision technique la plus importante pour la fiabilité et le coût d'un workflow.
Quand utiliser un webhook
On choisit le webhook quand : la réactivité importe (paiement, notification, action utilisateur immédiate), le service tiers le supporte (Stripe, HubSpot, GitHub, Calendly, Typeform proposent tous des webhooks), le volume d'événements n'est pas régulier (un pic une fois par mois ne consomme rien hors événement). Le webhook impose côté receveur : une URL publique stable (votre workflow doit toujours être joignable), une validation de signature (pour bloquer les imposteurs), une réponse rapide (sous 5 secondes typiquement, sinon retry), une gestion de la déduplication (le même webhook peut arriver plusieurs fois).
Quand utiliser un cron
On choisit le cron quand : le workflow doit tourner à intervalles réguliers indépendamment des événements (rapport quotidien, sync nocturne, nettoyage hebdo), la source n'a pas de webhook ou de mécanisme push, le besoin est tolérant à la latence (quelques heures de délai sont acceptables). Le cron est plus simple : pas d'URL à exposer, pas de signature à vérifier, pas de déduplication complexe. Mais on doit gérer l'idempotence (le cron peut redémarrer après une panne et retraiter ce qu'il a déjà traité), et le timing (deux instances qui tournent en parallèle si la précédente a planté).
Les triggers combinés
Un même workflow peut avoir plusieurs triggers en parallèle pour la robustesse. Exemple classique : un webhook pour le temps réel, plus un cron en backup qui rattrape les événements manqués (le service tiers pourrait être down au moment de l'envoi du webhook). On gère alors la déduplication : avant de traiter, on vérifie si l'événement n'a pas déjà été traité (idempotency key, timestamp, hash du payload). Sans cette précaution, on traite deux fois la même donnée, ce qui peut causer doublons en CRM, paiements multiples, e-mails envoyés deux fois.
Les pièges à éviter
Le piège du webhook sans signature : un attaquant qui connaît votre URL de webhook peut envoyer n'importe quel payload et déclencher des actions. On vérifie systématiquement la signature (Stripe, GitHub, etc. signent leurs webhooks). Le piège du polling trop fréquent : poller toutes les 30 secondes une API avec 1000 utilisateurs explose les quotas. On adapte la fréquence au besoin réel. Le piège du cron en double : sur une instance redémarrée, un cron peut se relancer en parallèle de l'instance précédente. On utilise un verrou (advisory lock PostgreSQL, Redis SETNX) pour garantir l'unicité. Et toujours logger l'arrivée d'un trigger : sans log, on ne peut pas debugger.