Chatbot webhook : comment connecter votre bot à vos outils en temps réel

Votre chatbot vient de collecter une commande, un numéro de téléphone ou une adresse. Que se passe-t-il ensuite ? Dans beaucoup de projets, la réponse honnête est : rien d’automatisé. Un collaborateur recopie la commande dans le CRM, un fichier CSV est exporté une fois par semaine, ou la donnée dort dans la base du chatbot et n’atteint jamais le logiciel métier.

Le webhook est la réponse technique à cette question, et sa configuration côté Botnation se fait sans code. C’est le mécanisme qui permet à un chatbot de dire à un autre logiciel : « il vient de se passer quelque chose, voici les données, à toi de jouer ». Connecter un chatbot à un module de génération de leads, à un module e-commerce ou à un ERP passe presque toujours par là.

Une intégration réussie ne se mesure pas au nombre de webhooks branchés. Commencez par un seul flux, celui qui soulage le plus votre équipe : une commande vers l’ERP, un lead vers le CRM. Rendez-le fiable, mesurez son délai de réponse, puis branchez le suivant. La file d’attente dédiée de Botnation absorbe les appels, mais chaque service lent ajoute de l’attente à la conversation : la sobriété est aussi une décision d’architecture, et elle se paie en minutes de conversation gagnées.

Sur Google, la requête « chatbot webhook » renvoie surtout des documentations techniques de plateformes de chatbot et des tutoriels d’intégration, souvent en anglais, rarement un guide orienté décision qui dit quand l’utiliser, comment le configurer et pourquoi ça casse. Cet article fait les trois, à partir de la documentation officielle de Botnation et de cas concrets, avec en bonus un configurateur de flux.

Créez votre chatbot gratuitement

Webhook et chatbot : la définition qui compte

Trois propriétés distinguent le webhook des autres modes d’échange :

• Il est événementiel. L’appel part au moment précis où la variable est collectée (une adresse e-mail, un numéro de commande, une localisation), pas à une heure fixe.
• Il est « push ». Le service externe n’a rien à installer ni à interroger : il expose une URL, et c’est Botnation qui l’appelle.
• Il est synchrone ou asynchrone. Le chatbot peut attendre la réponse (traitement synchrone) ou continuer sa conversation pendant que l’appel part en parallèle (traitement asynchrone). On verra que ce choix est décisif.

Le webhook n’a donc rien d’exotique : c’est le canal standard entre un chatbot et le reste du système d’information. Ce qui varie, ce sont les options de configuration et les pièges. C’est le sujet des sections suivantes.

Pourquoi un chatbot a besoin d’un webhook : quatre cas concrets

La documentation officielle de Botnation cite d’autres configurations simples et puissantes :

• Récupérer chaque matin vos dernières actualités depuis votre serveur, sans les saisir à la main dans l’arborescence du chatbot.
• Envoyer la ville ou les coordonnées GPS collectées, et recevoir en réponse un message avec la météo à 7 jours et une image générée par votre système.
• Transmettre un numéro de commande et recevoir le statut de la livraison, avec mise à jour des variables de l’utilisateur.
• Envoyer le titre d’un film demandé par l’utilisateur, et recevoir une bande annonce depuis votre base de données vidéo.

Ces exemples sont tirés de l’article « API Botnation : importer et exporter des données par webhook », qui reste la référence à lire avant de brancher votre premier flux.

Les options de l’élément Webhook : ce qui change tout

Dans la plateforme Botnation, le webhook est un élément de l’arborescence, comme un message ou une question. Il se place dans le scénario, et se règle avec quelques champs, sans une ligne de code.

Les réglages de l’appel

• URL en HTTPS obligatoirement : le protocole sécurisé est imposé par la plateforme.
• Méthode POST ou GET, au choix, selon ce que le service externe attend.
• Paramètres ajoutés directement dans l’URL, ou via l’option « + Ajouter un paramètre », avec les variables du chatbot entre accolades.
• En-tête personnalisé pour les services qui exigent une clé d’authentification.
• Bouton « Tester le Webhook » pour vérifier l’URL avant la mise en production ; si l’URL contient des variables, la plateforme propose de les simuler en saisissant des valeurs de test.

Traitement synchrone ou asynchrone ?

Le traitement synchrone met le chatbot en pause le temps que le webhook délivre sa réponse. La documentation officielle donne un exemple éclairant : deux fonctions webhook à la suite. La fonction A ajoute un utilisateur dans une base de données, la fonction B compte le nombre total d’utilisateurs et range la valeur dans une variable. Si A n’est pas terminée quand B démarre, le compteur est faux. Le traitement synchrone sur A impose l’ordre des exécutions.

Si l’option n’est pas cochée, le chatbot exécute la requête en parallèle et poursuit sa conversation : c’est le traitement asynchrone. Il est adapté à la collecte seule, quand aucun résultat n’est exploité dans la suite du scénario.

En mode synchrone, une séquence de redirection en cas d’erreur peut être sélectionnée : si le webhook ne répond pas ou retourne une erreur, l’utilisateur est dirigé vers le scénario choisi au lieu de rester bloqué.

Traiter la réponse JSON

Pour une utilisation avancée, l’élément Webhook peut lire et traiter la réponse renvoyée par l’appel HTTP. C’est ce qui permet de générer des réponses personnalisées à partir de données de vos propres serveurs : messages textes, images, vidéos, audios, variables ou boutons. Quand cette option est activée, le traitement synchrone est activé automatiquement. La documentation prévoit alors une réponse en moins de 10 secondes : au-delà, la connexion est interrompue et la réponse annulée. Ce seuil est un comportement documenté de l’option, pas un engagement de performance de la plateforme. Pour les contenus réutilisables (une actualité, la météo d’une même ville), la réponse peut être mise en cache de quelques minutes à plusieurs jours ; la documentation demande alors du JSON encodé en UTF-8, avec l’en-tête content-type application/json recommandé.

Le format de réponse JSON, décodé

Quand le traitement de la réponse est activé, le service externe doit répondre en JSON pur encodé en UTF-8 ; la documentation recommande l’en-tête content-type application/json. Le format attendu par la plateforme tient dans un schéma très court :

La clé botnation avec la valeur v1 est obligatoire pour que la réponse soit prise en compte. Le tableau reply contient ensuite un ou plusieurs éléments, chacun avec un type et une valeur. La réponse doit contenir uniquement le JSON : rien avant, rien après, pas même une ligne de log.

À vous : configurez votre flux webhook

Quatre réponses suffisent pour obtenir une configuration recommandée, adaptée au format de réponse attendu par Botnation et aux pièges de cette section.

No-code ou développeur : qui branche votre webhook ?

Le webhook de Botnation se configure dans l’éditeur, par des champs et des cases à cocher : pas de code, pas de serveur à maintenir. C’est le produit d’une plateforme no-code, et c’est le cas d’usage qui convient à la majorité des équipes marketing, support ou e-commerce.

Mais il y a l’autre face du miroir : le service qui reçoit l’appel. Une API de CRM n’est pas toujours triviale à documenter, un ERP interne peut exiger un travail d’ingénierie, et le format de réponse JSON doit être respecté au mot près. C’est là qu’intervient le second métier de Botnation. En plus d’éditer la plateforme, Botnation réalise des chatbots sur mesure via son offre Entreprise, avec ses experts en création de chatbot : configuration du bot, branchements, scénarios, livraison. Le prix et les délais passent par un devis.

L’avantage qui fait la différence : l’équipe qui construit votre chatbot est celle qui édite la plateforme. Pour un métier très spécifique, une régie sur place ou un intégrateur déjà en poste chez vous, une agence tierce reste une option légitime : cela se discute, et c’est même un point de confiance pour un projet à fort enjeu.

Les six erreurs qui font échouer un webhook

La documentation traitant des pannes est courte, et c’est instructif : presque tout se résume à six cas, dont trois sont des réglages.

1. Activer le cache sans raison. Si l’appel ne part pas à chaque fois, c’est certainement la case « cache » qui est cochée à tort. Si vous activez un cache réglé sur une heure, l’appel n’est envoyé qu’une fois par heure maximum, alors que vous voulez chaque événement. Le cache est fait pour une information réutilisable, comme la météo.
2. Placer le webhook avant la collecte. À cet endroit, le webhook n’a aucune donnée à envoyer. Le test simple : afficher la variable dans un message juste avant l’appel, et vérifier qu’elle n’est pas vide.
3. Dépasser le délai de réponse. Pour le traitement de la réponse JSON, la documentation indique une réponse attendue en moins de 10 secondes ; au-delà, la connexion est interrompue et la réponse annulée. Un serveur lent ou une base lourde est un cas d’école.
4. Répondre autre chose que du JSON pur. Une ligne de log, un espace blanc ou un apostrophe mal placée avant ou après le JSON suffit à annuler la réponse. L’en-tête content-type application/json est recommandé par la documentation, et l’encodage doit être UTF-8.
5. Oublier le synchrone quand l’ordre compte. Deux fonctions enchaînées sans attente produisent des résultats faux, comme le compteur d’utilisateurs lancé avant la fin de l’ajout.
6. Ne pas prévoir la séquence de redirection. En cas d’erreur, sans redirection configurée, l’utilisateur reste sur place et le parcours s’arrête net. Une redirection vers un message de confirmation ou vers un conseiller règle le problème.

Et si un doute persiste, la page « Pourquoi mon webhook ne fonctionne pas toujours » du support Botnation fait le tour de la question, cas de cache compris.

Ce que ça coûte

Les webhooks font partie des fonctions incluses dans les offres payantes de Botnation : la page Tarifs les mentionne parmi les fonctionnalités comprises dans le plan (consultée le 26/08/2026). L’élément Webhook est un composant standard de l’éditeur, pas une option à acheter séparément. Le compte gratuit sert surtout à créer et tester avant la mise en ligne. Ce qui change selon le plan, ce sont les limites d’usage (utilisateurs, crédits, fonctionnalités avancées) :

À titre de repère : pour un développement de chatbot mené par vos propres moyens, hors plateforme SaaS, la page Tarifs de Botnation indique « en général entre 5 000 € et 30 000 €, voire bien plus, selon les fonctionnalités », et précise que ces fourchettes sont indicatives (consultée le 26/08/2026). Côté Botnation, la fourchette exacte dépend du périmètre, et l’offre Entreprise se négocie sur devis, comme toute prestation sur mesure : le bon réflexe est de décrire le flux cible et de demander l’estimation.

Questions fréquentes

Ce qu’il faut retenir

Un webhook n’est pas une technologie réservée aux développeurs : c’est le standard de connexion entre un chatbot et un système d’information, et sa configuration côté Botnation se fait sans code. Trois règles de base évitent la plupart des pannes : placer le webhook après la collecte, activer le synchrone quand l’ordre des étapes compte, et ne pas activer le cache pour une donnée qui doit circuler à chaque événement.

Et quand le format de réponse ou l’ERP se complique, vous avez le choix : configurer vous-même dans l’éditeur, ou confier le flux à l’équipe Botnation qui édite la plateforme. Dans les deux cas, les cas d’usage sont déjà documentés, testés et illustrés dans le support officiel.