Nœud de déclenchement

Au démarrage, chaque workflow contient toujours un nœud par défaut de démarrage, appelé nœud trigger. En configurant ce nœud, l’utilisateur définit la manière dont le workflow sera activé. Une fois le workflow enregistré, l’utilisateur ne peut plus modifier ni changer le type de trigger de ce nœud, garantissant ainsi la stabilité du point d’entrée du flux de travail.

En cliquant sur ce nœud trigger, la plateforme affiche la page de configuration correspondante. Actuellement, six modes de déclenchement sont pris en charge : Déclencheur standard, Déclencheur vocal, Déclencheur webhook, Déclencheur manuel, Déclencheur Email et Déclencheur Programmation. Selon le mode de déclenchement sélectionné, les options de configuration s’adaptent automatiquement pour correspondre aux exigences spécifiques de chaque type de trigger.

1. Déclencheur standard

Le déclencheur standard permet de lancer automatiquement un workflow lorsqu’un événement interne survient dans le système. Il est généralement connecté à des actions comme la création, la mise à jour ou la suppression de données. Ce type de déclencheur est essentiel pour les automatisations en production, car il fonctionne sans intervention humaine. Il garantit une exécution en temps réel et assure la cohérence des პროცესus métiers en réagissant immédiatement aux modifications du système.

2. Déclencheur vocal

Le déclencheur vocal permet d’exécuter un workflow à partir d’une commande vocale utilisateur. Il s’appuie généralement sur des technologies de reconnaissance vocale et de traitement du langage naturel pour interpréter les intentions. Ce type de déclencheur est particulièrement adapté aux assistants intelligents ou aux interfaces conversationnelles. Il améliore l’expérience utilisateur en rendant l’interaction plus naturelle et intuitive, tout en permettant d’automatiser des actions sans interface graphique.

Les champs Nom, Webhook Secret et Identifiant ou numéro d’appel sont obligatoires. Le numéro d’appel doit être fourni afin que notre système puisse reconnaître l’origine de l’appel, analyser la demande et déterminer quel workflow doit être déclenché. Cela permet d’assurer un routage précis et une activation correcte du processus automatisé.

3. Déclencheur Webhook

Le déclencheur Webhook permet de démarrer un workflow lorsqu’une requête HTTP est reçue depuis un système externe. Il constitue un point d’entrée flexible pour intégrer différentes applications et services tiers. Lorsqu’un événement se produit à l’extérieur (paiement, formulaire, notification), une requête est envoyée vers le webhook, déclenchant ainsi le workflow. Ce mécanisme est largement utilisé pour construire des architectures orientées événements et faciliter les intégrations en temps réel.

Le champ Nom est obligatoire lors de la création d’un webhook.

Si un niveau de sécurité supplémentaire est requis, il est possible d’ajouter un Webhook Secret. Ce secret sera utilisé pour authentifier les requêtes entrantes. Ce webhook secret est devenu token authentification dans cURL:

  -H "Authorization: Bearer DemoWebhook123" \

Une fois la configuration renseignée, cliquez sur le bouton Confirmer. Après validation, en revenant sur la page de configuration du nœud, plusieurs informations sont automatiquement générées :

• Webhook URL
• Production Webhook ID
• Test Webhook ID

Utilisation via cURL

Le bouton Copy cURL permet de récupérer un exemple de requête pour déclencher le webhook.

Cas 1 : Sans Webhook Secret

curl -X POST "https://workflow-engine.rizlum.ai/api/v1/webhook/trigger/ee49710b-c4fd-4923-85e6-729eb1ffdea1" \
      -H "Content-Type: application/json" \
      -d '{}'

Cas 2 : Avec Webhook Secret

Lorsque le Webhook Secret est configuré, il doit être inclus dans les en-têtes de la requête :

curl -X POST "https://workflow-engine.rizlum.ai/api/v1/webhook/trigger/ee49710b-c4fd-4923-85e6-729eb1ffdea1" \
      -H "Authorization: Bearer DemoWebhook123" \
      -H "Content-Type: application/json" \
      -d '{}'

En appelant cette requête cURL depuis une plateforme externe, le workflow configuré avec un déclencheur Webhook sera automatiquement exécuté.

Cela permet d’intégrer facilement le workflow avec des systèmes tiers ou des services externes, en envoyant simplement une requête HTTP vers l’URL du webhook.

L’ID de production est généralement utilisé pour les workflows déjà déployés en environnement réel. L’ID de test, quant à lui, est principalement destiné au débogage et aux phases de test. Lors de la création initiale d’un workflow, les utilisateurs utilisent généralement l’ID de test afin de vérifier son bon fonctionnement avant le passage en production.

Mode débogage :

Tout d’abord, il faut cliquer sur le bouton Démarrer sur la page du workflow. Le nœud Webhook Trigger est alors activé et se met à écouter les appels cURL configurés.

Il reçoit les requêtes provenant de l’extérieur de la plateforme, par exemple via une commande cURL définie dans le nœud. Lorsqu’une requête est reçue, le nœud s’exécute, le workflow est officiellement activé et passe au nœud suivant.

  curl -X POST "https://workflow-engine.rizlum.ai/api/v1/webhook/trigger/ee49710b-c4fd-4923-85e6-729eb1ffdea1" \
      -H "Authorization: Bearer DemoWebhook123" \
      -H "Content-Type: application/json" \
      -d '{}'

La ligne -d '{}' correspond à l’endroit où l’on peut transmettre des données depuis un système externe vers le workflow. Par exemple, il est possible de créer un workflow qui se déclenche lorsqu’une requête cURL est envoyée avec un paramètre tel que ticket_id, transmis directement au cURL pour traitement pendant le workflow.

Dans ce cas d’usage, le workflow a pour objectif d’analyser les informations associées à ce ticket_id et de retourner un résultat indiquant si le ticket est valide ou non. Pour que cela fonctionne correctement, il faut d’abord s’assurer que le workflow est démarré via le bouton Démarrer . Ensuite, les données peuvent être envoyées via la commande cURL, dans -d '{}', nous ajoutons le payload contenant le ticket_id, afin de déclencher l’exécution du workflow avec les bonnes informations.

  curl -X POST "https://workflow-engine.rizlum.ai/api/v1/webhook/trigger/ee49710b-c4fd-4923-85e6-729eb1ffdea1" \
      -H "Authorization: Bearer DemoWebhook123" \
      -H "Content-Type: application/json" \
      -d '{
        "ticket_id" : "9639265721"
      }'

Après l’envoi de cette requête cURL, le workflow se met en écoute et reconnaît correctement la requête reçue. En cliquant sur le nœud déclencheur, on peut afficher plus de détails sur cette requête.

Pour le système de workflow, il est nécessaire d’exécuter le workflow une première fois afin de définir les outputs.

Ainsi, lorsque l’utilisateur revient après l’exécution du workflow, chaque nœud affiche la liste des outputs sur la partie droite de la page de configuration.

Attention : la liste des outputs n’est pas fixe. Si les données envoyées via la requête cURL changent, alors la liste des outputs sera également mise à jour. Autrement dit, la liste des outputs dépend toujours des données envoyées dans le cURL. Toutefois, il est nécessaire d’exécuter le workflow au moins une fois pour que l’utilisateur puisse voir la liste des outputs mise à jour.

Regardons cette partie : on peut voir qu’il y a deux types de valeurs :

1. Valeur incluse dans la partie -d '{}' :

   "ticket_id" : "9639265721"

2. Valeurs automatiquement ajoutées

En plus des données incluses dans -d '{}', deux valeurs sont toujours ajoutées : received_at, execution_id

"received_at": "2026-04-14T06:40:40.661626",
"execution_id": "852c3e57-1223-4d7a-90b5-f0eda7427f5a"

Remarques

received_at : indique le moment où la requête cURL a été reçue par le système.

execution_id : permet d’identifier l’exécution du workflow et de s’assurer que la réponse correspond bien à la requête envoyée.

Mode Production:

Ce mode indique que le workflow est déjà déployé. Comme visible sur l’image, lorsque le workflow est en mode déploiement (production), le bouton Démarrer est désactivé, car l’exécution manuelle n’est pas disponible dans cet état. Par ailleurs, le bouton de déploiement a été remplacé par Pause, ce qui confirme que le workflow est déjà actif en production.

En mode Production, le système écoute en permanence les requêtes entrantes.

Lorsqu’une requête cURL correspondant à la configuration est reçue, le workflow est automatiquement activé et s’exécute depuis le système externe. Il n’est donc pas nécessaire de cliquer sur le bouton Démarrer pour activer l’écoute.

4. Déclencheur manuel

Le déclencheur manuel permet à un utilisateur de lancer un workflow à la demande, via une action explicite comme un clic sur un bouton. Il est particulièrement utile pour tester, déboguer ou exécuter des processus ponctuels. Contrairement aux déclencheurs automatiques, il ne dépend d’aucun événement externe ou interne. Ce type de déclencheur offre un contrôle total à l’utilisateur et est souvent utilisé lors des phases de développement ou pour des opérations exceptionnelles.

Le Mock Data (JSON) dans le cas d’un déclencheur manuel est essentiel car il permet de simuler des données d’entrée lors de l’exécution manuelle d’un workflow. Cela aide à tester le processus sans attendre des données réelles provenant de systèmes externes. Grâce au mock data, les développeurs peuvent facilement déboguer, vérifier la logique et s’assurer que le workflow fonctionne correctement dans différents scénarios. Il facilite également un développement plus rapide et plus sûr, en évitant tout impact sur les données réelles dans l’environnement de production.

5. Déclencheur email

Le nœud email trigger est un composant essentiel dans les systèmes d’automatisation de workflow. Il permet de déclencher automatiquement un processus dès qu’un email est reçu à une adresse configurée au préalable. Lorsqu’un message arrive, ce nœud peut analyser le contenu, l’objet ou les pièces jointes afin de déterminer les actions suivantes. Par exemple, il peut créer une tâche, enregistrer des données ou envoyer une réponse automatique. Cette approche réduit les interventions manuelles, améliore l’efficacité et garantit que toutes les informations importantes provenant des emails sont traitées rapidement et avec précision.

L’utilisateur doit d’abord fournir le nom du nœud. Ensuite, la configuration du serveur est requise, incluant le serveur IMAP, le port ainsi que l’adresse email. Ces paramètres sont indispensables pour activer correctement la fonctionnalité.

Le protocole IMAP (Internet Message Access Protocol) permet d’accéder aux emails directement depuis le serveur, tout en assurant la synchronisation entre plusieurs appareils. Les paramètres IMAP (serveur et port) sont fournis par le service de messagerie utilisé. Par exemple, pour Gmail, le serveur IMAP est imap.gmail.com et le port sécurisé est 993 (SSL/TLS).

Il est fortement recommandé d’utiliser les configurations officielles du fournisseur. Une mauvaise configuration du serveur ou du port peut entraîner un échec de connexion. Enfin, assurez-vous que l’accès IMAP est activé dans les paramètres du compte email avant toute utilisation.

Ensuite, le fournir du mot de passe d'application est necessaire pour vraiment synchoromiser et pour retirer les email non lu depuis le compte email.

Comment générer un mot de passe d’application ?

1. Accédez à un moteur de recherche Google et saisissez le mot-clé : “app password Gmail”. Sélectionnez ensuite la page officielle de support de Google (support.google.com).
2. Sur la page, faites défiler jusqu’à la section “Créer et gérer vos mots de passe d’application”, puis cliquez sur le lien correspondant. Connectez-vous avec le compte Gmail que vous souhaitez configurer.
3. Une fois connecté, créez un nouveau mot de passe d’application en renseignant le nom de votre application, puis cliquez sur “Créer”.
4. Un mot de passe sera généré et affiché dans une fenêtre dédiée. Copiez ce mot de passe et collez-le dans le champ mot de passe d’application lors de la configuration du nœud email trigger. Ce mot de passe est requis pour assurer une connexion sécurisée entre votre application et le service de messagerie.

Il y a deux scénarios :

En environnement de production (PROD) :Un mécanisme automatisé s’exécute toutes les 60 secondes afin de récupérer les emails non lus depuis l’adresse configurée dans le système. Ce processus garantit une surveillance continue et fiable, assurant que chaque nouveau message est détecté et traité rapidement sans intervention manuelle.

En environnement de développement (DEV) : Le déclenchement repose sur une action manuelle de l’utilisateur. À chaque clic sur le bouton Démarrer, une requête API est envoyée pour vérifier la présence d’emails non lus depuis l’adresse configurée. Cette approche offre plus de contrôle et facilite les phases de test et de validation.

De plus, un champ de configuration permet de définir la priorité de traitement lorsque plusieurs emails non lus sont détectés. Ce paramètre est essentiel pour contrôler le comportement du workflow. Si vous choisissez l’option email le plus ancien, le système traitera en priorité le premier message reçu, garantissant un ordre chronologique et évitant de manquer des emails importants. À l’inverse, l’option email le plus récent permet de traiter immédiatement les dernières informations reçues, ce qui est utile pour des cas nécessitant une réactivité rapide. Le choix dépend donc du besoin métier et du niveau de priorité accordé à la temporalité des messages.

6. Déclencheur programmé

Le déclencheur programmé permet de définir une date et une heure précises pour l’activation d’un workflow. L’utilisateur peut configurer un moment exact (jour, mois, année, heure et minute) afin de planifier l’exécution automatique. Grâce à une expression de type cron ou une planification simple, le système lance le workflow automatiquement au moment défini, sans intervention humaine.

Ce mécanisme est très utile pour automatiser des tâches récurrentes ou ponctuelles avec une grande précision. Il garantit une exécution fiable à des moments prédéfinis, réduisant les erreurs humaines et améliorant l’efficacité des processus. Les entreprises peuvent ainsi planifier des opérations critiques comme les rapports, les sauvegardes ou les synchronisations de données, tout en optimisant la gestion du temps et des ressources.