Constructeur de chatbot sans code : flux, nœuds et webhooks

La plupart des plateformes de chatbots vous obligent à choisir entre deux mauvaises options. Soit vous faites glisser des cases sur un canevas et vous obtenez un arbre de décision glorifié incapable de parler à vos systèmes, soit vous ouvrez un éditeur de code, vous apprenez encore un dialecte YAML et vous passez une semaine à câbler quelque chose que personne d'autre dans l'équipe ne pourra modifier. Le constructeur de flux Svyazio est visuel, mais il dispose d'une porte de sortie pour chaque exigence sérieuse : entrées validées, conditions de branchement, vrais webhooks HTTP avec mappage des réponses, variables qui circulent dans toute la session et transfert à un véritable humain dès que le bot atteint ses limites.

Le même flux tourne sur tous les canaux pris en charge par Svyazio — le widget de site, les bots Telegram, les communautés VK et MAX. Les claviers inline sont rendus nativement sur chaque plateforme. Sur les canaux qui ne prennent pas en charge les claviers, les boutons basculent vers des options textuelles numérotées : le visiteur peut quand même répondre par « 1 » ou « 2 ». Vous construisez le flux une fois ; le moteur se charge de parler la langue de chaque canal.

Pourquoi un constructeur visuel l'emporte sur le code et les arbres de décision

L'argument en faveur d'un constructeur visuel ne se résume pas à « les non-développeurs peuvent l'éditer ». Les vrais bénéfices sont plus subtils :

Les flux se lisent comme des diagrammes. N'importe qui dans votre équipe — responsable du support, chef de produit, directeur marketing — peut ouvrir l'éditeur et comprendre ce que fait le bot en trente secondes. Les définitions de bot sous forme de code demandent une lecture. Les flux visuels sont perçus comme des formes. À elle seule, cette différence fait passer les cycles de revue de plusieurs jours à quelques minutes.

Les cas particuliers ont leur place. Un arbre de décision classique s'effondre dès que le trafic devient réel parce que tout flux intéressant comporte des boucles, des relances, des délais d'expiration et des transferts. Svyazio vous laisse tout câbler explicitement — un webhook qui échoue est routé vers une branche error, une entrée manquante déclenche une nouvelle invite, un délai de session expiré ouvre la boîte de réception pour un humain. Tout est visible, tout est rattaché à des nœuds précis.

Les variables rendent le bot stateful. Chaque nœud input écrit dans une variable. Chaque webhook peut mapper des morceaux de sa réponse dans des variables. Chaque nœud suivant peut les interpoler dans ses messages — Bonjour {{name}}, votre commande {{order_id}} part demain. Le bot retient les choses au lieu de repartir de zéro à chaque étape.

Les canaux où un seul flux fonctionne

Le widget de site parle Socket.IO. Telegram et MAX acceptent les claviers inline. VK a son propre format de clavier. Le moteur de chatbot traduit chaque nœud vers le bon transport : le nœud buttons devient un inline_keyboard sur Telegram, une charge utile keyboard sur VK, des événements Socket.IO sur le widget. Vous voyez le même flux dans l'éditeur, peu importe le canal.

Anatomie d'un flux

Tout flux commence par un unique nœud start. À partir de là, vous enchaînez les nœuds en faisant glisser des connexions entre eux. Chaque nœud a 0 ou 1 arête entrante et 1 ou plusieurs arêtes sortantes. Les nœuds peuvent boucler, bifurquer et fusionner — le moteur suit les arêtes une étape à la fois.

Le panneau de gauche liste tous les types de nœuds disponibles. Le canevas est l'endroit où vit le flux. Le panneau de droite affiche les propriétés du nœud sélectionné. Les modifications sont sauvegardées quand vous cliquez sur Enregistrer ; elles passent en production quand vous cliquez sur Publier. Les brouillons et les versions publiées sont séparés, ce qui vous permet d'itérer sans casser le bot en production.

1. Nœud message

Une utilisation typique : un message de bienvenue avec le prénom du visiteur récupéré depuis le profil visiteur du widget, suivi d'une courte pause avant la question suivante. Le délai est borné pour éviter les accidents : 0 à 10 secondes, vérifié côté serveur.

2. Nœud buttons

C'est dans les boutons que se loge l'essentiel de votre logique de branchement. Un menu à trois boutons (« Commandes / Support / Questions ») génère trois chemins sortants distincts — chacun peut mener à son propre sous-flux avec une logique totalement différente. Le moteur attend le clic, respecte les limites de débit (30 événements par minute par session) et, sur Telegram/MAX, supprime le clavier inline après le clic pour éviter qu'on tape deux fois.

3. Nœud input (avec validation)

La validation est stricte mais utile : la vérification d'e-mail rejette les adresses manifestement mal formées, la vérification de téléphone accepte les formats internationaux et les normalise, et la vérification de texte impose simplement une réponse non vide. Le nœud retient la session jusqu'à ce que le visiteur envoie quelque chose qui passe. Si rien n'arrive avant l'expiration de la session, le bot transfère à un humain plutôt que de boucler indéfiniment.

Les variables capturées ici deviennent disponibles pour tous les nœuds suivants. Un message ultérieur peut saluer le visiteur par son prénom, un webhook ultérieur peut inclure son e-mail dans la charge utile, et le nœud action final peut écrire dans son champ de profil pour que ses réponses persistent au-delà de cette conversation.

4. Nœud condition

Les conditions sont la façon de transformer des données en contrôle de flux. Le visiteur a-t-il tapé « annuler » pendant l'étape d'input ? Routez-le vers le flux d'annulation. Son profil visiteur est-il marqué comme client récurrent ? Sautez l'introduction. Le webhook a-t-il répondu avec status = "vip" ? Sautez vers la file prioritaire. Tous les opérateurs de comparaison auxquels vous vous attendez sont là : égal, différent, contient, commence par, supérieur/inférieur numérique, vrai/faux booléen, et regex pour les cas où rien d'autre ne convient.

5. Nœud action (transfert, variables, profil)

Les actions de transfert sont essentielles. Le rôle d'un bot est généralement de qualifier, collecter et router — pas de remplacer l'agent. assign_department dépose la conversation dans la bonne file (Ventes, Support, Facturation), assign_agent l'épingle à une personne précise, et close marque la conversation comme résolue quand le bot termine de lui-même (consultation d'un statut de livraison, FAQ répondue, etc.). Le visiteur ne voit jamais ces événements comme distincts — la conversation se poursuit simplement avec un humain, sans rupture.

set_visitor_field est plus discret mais tout aussi utile. Il écrit dans le profil persistant du visiteur. L'e-mail collecté par le bot devient son e-mail de profil. Le téléphone devient son téléphone. La prochaine fois qu'il revient — depuis n'importe quel canal — les données sont déjà là.

6. Nœud delay

Les délais font la différence entre un bot qui ressemble à un raccourci clavier et un bot qui ressemble à une conversation. 300 à 800 ms entre des messages courts suffisent généralement. Des délais plus longs (2 à 3 secondes) fonctionnent bien avant un message qui annonce qu'un travail est en cours — « un instant, je vérifie votre commande » — surtout couplés à un appel webhook en cours.

7. Nœud webhook (HTTP vers n'importe quelle API)

C'est le nœud qui transforme Svyazio d'un jouet de chatbot en plateforme d'intégration. Récupérer une commande dans votre back-end, interroger votre CRM, pinger un service de points de fidélité, appeler un endpoint de complétion GPT — tout ce que HTTP sait faire, le nœud webhook sait le faire. L'URL, les en-têtes et le corps prennent tous en charge l'interpolation de variables, donc chaque appel est contextualisé à la session en cours.

Une configuration typique :

Une fois ce nœud exécuté, {{customer_name}}, {{customer_tier}} et {{order_count}} sont disponibles pour tous les nœuds en aval. L'étape immédiatement suivante est généralement un nœud condition qui bifurque sur customer_tier == "vip".

Le nœud webhook a deux arêtes sortantes : success (HTTP 2xx) et error (4xx/5xx, dépassement de délai, blocage SSRF, réponse mal formée). Si vous ne câblez que la branche succès, les échecs retombent sur l'arête par défaut — rien ne se bloque silencieusement.

Variables et syntaxe des templates

Les variables sont le ciment. Chaque nœud input, chaque mappage de réponse webhook, chaque action set_variable écrit dans session.variables. Chaque message, chaque buttons et chaque URL/corps de webhook peut y lire via l'interpolation {{variable}}. La notation pointée fonctionne aussi : si un webhook mappe order sur tout l'objet de réponse, vous pouvez ensuite référencer {{order.tracking_number}}.

Limites strictes pour garder les sessions sous contrôle :

• Au maximum 100 variables par session
• Au maximum 2 000 caractères par valeur de variable
• Le journal de chemin de session (utilisé par les analyses) est plafonné à 500 traversées de nœuds

Vous n'atteindrez pas ces limites avec un flux normal. Elles existent pour vous protéger du cas pathologique d'une boucle incontrôlée qui écrirait dans les variables jusqu'à épuiser la mémoire.

Trois flux concrets que vous pouvez copier

Exemple 1 : bot de qualification de leads pour un SaaS

Objectif : poser trois questions, scorer le lead, router les leads chauds vers les Ventes et les leads froids vers le flux d'onboarding.

1. Start → Message (« Bonjour ! Petite question : qu'est-ce qui vous amène aujourd'hui ? »)
2. Buttons (Tarifs / Intégrations / Je regarde simplement) → enregistre le choix dans intent
3. Input (e-mail, type = email) → enregistre dans email
4. Input (taille de l'entreprise : solo / 2-10 / 11-50 / 50+) → enregistre dans size
5. Condition : intent == "Tarifs" ET size != "solo" → aller à la branche « lead chaud »
6. Action : assign_department(Ventes) sur la branche lead chaud
7. Message sur la branche froide (« Merci ! Voici une visite guidée qui pourrait vous intéresser : [lien] »)
8. Action : close après le message de la branche froide

Temps total de construction : environ 10 minutes. Sans code. Fonctionne identiquement sur le widget de site et sur Telegram.

Exemple 2 : consultation du statut d'une commande pour un e-commerce

Objectif : le visiteur demande le statut d'une commande, le bot le récupère dans le back-end de la boutique, retourne le suivi et propose un transfert si quelque chose cloche.

1. Input (numéro de commande, type = text) → order_id
2. Input (e-mail de la commande, type = email) → email
3. Delay (1500 ms) + Message (« Je vérifie cela... »)
4. Webhook → GET https://shop-api.example/orders/{{order_id}}?email={{email}}, mappe status et tracking_url
5. Sur success : Message (« Votre commande est {{status}}. Suivi : {{tracking_url}} ») → Buttons (« Tout est bon, merci » / « Il y a un problème »)
6. Sur « Tout est bon » : Action : close
7. Sur « Il y a un problème » OU sur error du webhook : Action : assign_department(Support)

Exemple 3 : bot de nuit qui transfère quand les opérateurs sont en ligne

Objectif : tourner uniquement quand tous les agents sont hors ligne, collecter l'essentiel, déposer un ticket dans Telegram pour l'équipe du matin.

Déclenché par la condition operators_offline = offline sur le déclencheur du widget (pas un nœud du flux — cela se configure dans les paramètres quand exécuter du bot). Le bot lui-même est un flux simple :

1. Start → Message (« Nous sommes hors ligne pour l'instant, mais nous vous répondrons dès le matin. »)
2. Input (e-mail) → Input (quelle est votre question ?)
3. Action : set_visitor_field(email) + set_visitor_field(phone si collecté)
4. Webhook → POST vers un webhook de canal Telegram avec le résumé, pour que l'équipe du matin le voie en arrivant
5. Action : close

Transfert à un humain et contrôle de session

Les agents ont toujours le dernier mot. Partout dans le tableau de bord, quand une session de chatbot est active sur une conversation, une bannière apparaît : « Le bot X gère cette conversation » avec un bouton Arrêter le bot. Un clic et le bot s'arrête — la session passe à HANDED_OFF, tous les claviers inline en attente sont retirés de Telegram/MAX, et la conversation est signalée comme nécessitant une attention. L'agent prend alors le relais.

Ce n'est pas qu'un bouton de panique. C'est le principal point d'intégration entre les bots et les humains. Les bots gèrent la routine ; les agents interviennent quand les choses deviennent intéressantes. Les variables collectées par le bot sont visibles par l'agent, qui ne repart donc pas de zéro.

Côté moteur, plusieurs filets de sécurité tournent en arrière-plan :

• Un verrou basé sur Redis sérialise les clics concurrents — le visiteur ne peut pas double-cliquer un bouton et déclencher deux chemins.
• Un limiteur de débit plafonne chaque session à 30 événements par minute, pour qu'un script ne puisse pas faire boucler un bot à l'infini.
• Un balayage cron tourne toutes les minutes et fait expirer les sessions en attente d'une réponse au-delà de leur limite — la conversation se rouvre pour les humains, rien ne reste bloqué.

Tarifs et limites

Les chatbots sont une fonctionnalité du forfait Pro. Le forfait inclut également l'assistant d'écriture IA, les déclencheurs et auto-messages, les départements, les analyses, les agents illimités, le white-label et 10 bots Telegram. Les deux forfaits payants comprennent un essai gratuit de 7 jours, sans carte bancaire.

Consultez la page complète des tarifs ou passez directement à la création d'un compte.

FAQ