Dans beaucoup d’entreprises françaises, la voix redevient un canal stratégique. Non pas parce que le téléphone “revient à la mode”, mais parce qu’un assistant vocal bien conçu enlève immédiatement la friction : le client parle, le système comprend, la demande est traitée. Là où un SVI classique impose des choix “tapez 1, tapez 2”, un Voicebot apporte une interaction naturelle, pilotée par la reconnaissance vocale, le NLP et une logique conversationnelle maîtrisée. Résultat : des demandes simples (horaires, suivi, modification, commande) se résolvent en quelques secondes, tout en libérant les équipes humaines pour les cas à valeur.
Ce tutoriel vous guide avec une approche terrain : construire un voicebot de prise de commande de café dans Dialogflow (Google), depuis la structuration des intentions jusqu’à l’appel à un backend via webhook, puis l’exposition sur un numéro de téléphone. Pour rendre le tout concret, on suivra l’exemple d’une entreprise fictive, “Café des Halles”, qui veut absorber les pics d’appels du matin sans dégrader la qualité. Si votre objectif est l’automatisation du service client, ou la création d’un “callbot” transactionnel, les étapes sont transférables à la plupart des catalogues (restauration, retail, SAV, rendez-vous). L’idée n’est pas de bricoler une démo : c’est de poser des fondations propres, exploitables et mesurables.
En bref
- Voicebot = voix + intelligence artificielle : une expérience plus fluide qu’un SVI, complémentaire d’un chatbot.
- Choisir entre Dialogflow ES (simple) et Dialogflow CX (flux complexes, entreprise) change la façon de concevoir.
- Un agent robuste repose sur : intents bien séparées, entités propres (IDs), et routage clair entre pages/flux.
- Le webhook est le pont vers votre SI : commande, CRM, stock, paiement, tickets.
- Pour la téléphonie, une intégration comme AudioCodes permet d’associer rapidement un numéro au bot.
- On pilote la performance avec des KPIs : taux de résolution, taux d’abandon, temps moyen, transfert agent.
Comprendre un Voicebot et Dialogflow : bases solides avant le tutoriel
Un Voicebot est un logiciel conversationnel qui permet à un utilisateur d’interagir uniquement par la voix. Il combine en général trois briques : la reconnaissance vocale (speech-to-text), la compréhension (NLU / NLP), puis la restitution (text-to-speech). Dans la pratique, c’est la différence entre “je navigue dans un menu téléphonique” et “je dis ce que je veux”. Ce changement paraît simple, mais il transforme l’expérience : la personne n’a plus à deviner la bonne touche, elle exprime son intention.
Pour un décideur IT ou Relation Client, le point clé est que le bot vocal ne remplace pas forcément les autres canaux : il les orchestre. Un chatbot gère très bien les conversations écrites, tandis que l’assistant vocal excelle lorsque l’utilisateur est en mobilité, pressé, ou dans un contexte où taper est pénible. Cette complémentarité est au cœur d’une stratégie omnicanale, comme détaillé dans l’approche omnicanale de l’expérience client, où l’on cherche la continuité plutôt que la multiplication d’outils.
Dialogflow : NLU et design conversationnel, pas seulement un “outil Google”
Dialogflow est une plateforme cloud de Google centrée sur la compréhension du langage et la conception de dialogues. L’objectif : transformer des phrases naturelles (“Je voudrais un espresso au miel”) en données exploitables (type de café = espresso, topping = miel) et en actions (envoyer une commande). Là où certains projets se bloquent, c’est qu’ils traitent Dialogflow comme une simple boîte noire. Or, la qualité vient surtout de votre modélisation : intentions, entités, parcours, gestion des ambiguïtés.
En termes d’architecture conversationnelle, Dialogflow fournit des “briques” qui structurent le bot : agents, flux, pages, intents, paramètres, types d’entités, webhooks et intégrations. Imaginez un restaurant : les entités sont votre carte, les intents sont les façons de commander, le flux est le scénario du service, et le webhook est la porte qui mène à la cuisine (votre SI). Cette analogie aide à éviter un écueil fréquent : empiler des intents sans logique globale.
Dialogflow ES vs Dialogflow CX : décider tôt pour éviter de refaire
Dialogflow existe en deux grandes versions. Dialogflow ES (Essentials/Standard) est adapté aux besoins simples : un bot FAQ, quelques scénarios, une structure légère. Dialogflow CX est conçu pour les parcours complexes, multi-étapes, et une gouvernance plus “entreprise” avec une modélisation par pages/flux plus explicite. Pour un cas de commande (même limité à quelques boissons), CX devient rapidement confortable dès que vous ajoutez des variantes : tailles, personnalisation, allergies, retrait en boutique, créneaux.
Pour “Café des Halles”, le choix de CX est rationnel : le bot doit encaisser le rush du matin, gérer des reformulations, et éviter les impasses. C’est typiquement le genre de projet où l’automatisation est rentable si le design est propre dès le départ. L’insight à garder en tête : plus le parcours ressemble à un vrai dialogue, plus CX vous fait gagner du temps.
À retenir
Un Voicebot performant n’est pas un “chatbot avec une voix” : c’est un parcours pensé pour l’oral, avec des questions courtes, des confirmations utiles et des sorties de secours vers un humain.
Modéliser un Voicebot de commande de café dans Dialogflow CX : flux, pages et entités
Passons au concret : bâtir un Voicebot qui prend une commande de café. Le scénario de base est simple : salutation, demande, choix du café, options, confirmation, envoi au backend. Mais un bon bot doit aussi gérer l’imprévu : “finalement un cappuccino”, “sans sucre”, “je veux deux cafés”, “qu’est-ce que vous proposez ?”. C’est ici que la modélisation Dialogflow CX (pages/flows) devient un avantage.
Créer un projet et un agent : cadrage technique et choix de région
Dans la console, vous créez d’abord un projet Google Cloud, puis vous activez l’API Dialogflow. Ensuite, vous créez l’agent CX en choisissant une région proche de votre base d’utilisateurs, pour limiter la latence. Ce détail compte en voix : 300 à 600 ms de délai perçu peuvent suffire à rendre l’échange moins naturel. Pour “Café des Halles”, basé en France, un hébergement européen est le choix logique.
Dès la création, l’agent inclut une page de démarrage qui gère souvent les salutations. Testez immédiatement via l’outil de test : ce réflexe évite de construire “dans le vide”. La voix pardonne moins que le texte : si le bot répond à côté, l’utilisateur raccroche. Vous cherchez donc à obtenir très tôt un comportement cohérent sur les salutations et la prise en charge.
Identifier et entraîner les entités : préférer des IDs aux libellés
Pour notre commande, deux familles d’entités sont essentielles : types de café et garnitures. On pourrait être tenté d’envoyer “espresso” au système de commande. Mauvaise idée : votre backend devra faire un matching textuel, source d’erreurs (synonymes, accents, pluriels). Une pratique plus robuste consiste à associer chaque item à un identifiant stable (ex. CAFE_001) et à renvoyer cet ID au backend via les paramètres.
Exemple : “espresso” peut devenir la valeur CAFE_001, “cappuccino” CAFE_002, etc. Idem pour les toppings : TOP_001 (miel), TOP_002 (cannelle)… Ainsi, l’agent collecte des choix humains, mais transmet des valeurs système. C’est une différence décisive quand vous connectez ensuite un CRM, un OMS, ou un outil de caisse.
Pour les garnitures, prévoyez d’emblée le multi-choix : un client peut dire “miel et cannelle”. Dans CX, vous configurez le paramètre comme une liste, ce qui évite de perdre des éléments. Ce point, très banal en apparence, est souvent la cause de commandes incomplètes dans les POC.
Définir les flux : modulariser comme du code réutilisable
Les flows sont l’équivalent conversationnel de modules de code : vous séparez ce qui est réutilisable et logique. Dans une version simple, vous gardez le flow “Default Start” et vous créez un flow “Commande”. Plus tard, si “Café des Halles” ajoute le paiement, vous pourrez créer un flow “Paiement” sans casser le reste. Même chose si vous ajoutez un flow “FAQ” ou “Suivi de commande”.
Cette séparation est stratégique pour la maintenance : une équipe métier peut enrichir la FAQ pendant que l’IT sécurise le flux de commande. Et si vous industrialisez sur plusieurs points de vente, vous réutilisez la structure en changeant seulement le catalogue.
Conseil pratique
Avant d’ajouter 30 intents, dessinez le parcours sur une page : objectifs, questions du bot, données à collecter, et conditions de sortie (transfert humain, répétition, annulation). Vous réduirez drastiquement les erreurs de design.
Pour approfondir les concepts Dialogflow et les bonnes pratiques d’agent, vous pouvez croiser votre approche avec ce guide pas à pas sur la création d’un agent Dialogflow et adapter les étapes au modèle CX.
Créer les intents et le routage dans Dialogflow CX : faire comprendre l’oral sans ambiguïté
La réussite d’un Voicebot tient souvent à un point : la précision de la compréhension d’intention. En voix, les phrases sont plus longues, moins structurées, avec des hésitations. Vous devez donc concevoir des intents claires, non chevauchantes, et des exemples d’expressions variés. Dialogflow ne “devine” pas votre métier : il apprend votre univers via les formulations, les entités et la logique de routage.
Deux intents clés pour démarrer : initier et passer la commande
Dans notre scénario, on démarre avec deux intentions : “Initier la commande” et “Passation de commande”. La première capture l’instant où l’utilisateur signale qu’il veut commander. Exemples : “Je veux commander”, “Aidez-moi à passer une commande”, “Je souhaite prendre un café”. La seconde correspond à l’énoncé qui contient déjà les items : “Un espresso au miel”, “Un café noir avec beurre et cannelle”.
Une règle d’or : ne mélangez pas deux objectifs dans une seule intent. Si vous fusionnez “commander” et “demander les horaires”, vous obtiendrez une compréhension instable. Les équipes support le sentent immédiatement : plus le bot se trompe, plus les agents récupèrent des appels frustrés.
Annoter les entités dans les phrases d’entraînement
Idéalement, Dialogflow repère automatiquement les entités (types de café, garnitures). Quand ce n’est pas le cas, sélectionnez le mot dans la phrase d’entraînement et associez-le au type d’entité. Prenez le temps de créer des variantes : “expresso”/“espresso”, “café noir”, “américain”, “cappu” si vous l’acceptez, et quelques formulations orales (“un p’tit espresso”).
Pensez aussi aux reformulations. Dans la vraie vie, un client peut dire : “Je prends un cappuccino… enfin non, un espresso”. Il faut prévoir des routes de correction, ou au moins une confirmation intelligente : “Vous confirmez : 1 espresso, topping miel ?”. Un bot vocal ne doit pas tout confirmer (c’est lent), mais il doit confirmer ce qui coûte cher en erreur (produit, quantité, allergènes, adresse).
Routage entre pages et flows : l’ossature de votre bot
Le routage dans CX permet d’aller d’une page à une autre, ou d’un flow à un autre. Concrètement, depuis le flow de démarrage, vous créez une route qui, si l’intent “Initier la commande” est détectée, transfère l’utilisateur vers le flow “Commande”. Dans le flow “Commande”, vous créez une route sur l’intent “Passation de commande” qui mène vers une fin de flow (ou une page de confirmation).
Ce mécanisme est simple, mais c’est la charpente. Un routage propre évite les boucles (“je commande” qui renvoie à “bonjour”) et limite les abandons. Pour un centre de contacts, cela se traduit par une baisse du temps perdu sur des échanges stériles.
« 67% des consommateurs préfèrent les chatbots pour les demandes simples. »
— Étude Gartner, 2025
Cette statistique, souvent citée côté chatbot, se transpose bien au vocal dès lors que le Voicebot traite des demandes courtes et répétitives. Le point n’est pas de “forcer” le canal, mais d’offrir un chemin rapide.
Pour mieux comprendre le positionnement du vocal par rapport au texte, l’article Voicebot vs chatbot : différences et usages aide à choisir le bon canal selon le contexte.
Connecter le webhook : faire passer Dialogflow du dialogue à l’action métier
Un Voicebot devient réellement utile quand il déclenche une action. Dans notre exemple, une fois le café et les garnitures identifiés, il faut créer une commande dans le système (caisse, ERP, outil de préparation) ou au minimum envoyer les informations à un endpoint. C’est le rôle du webhook : une “prise” entre Dialogflow et votre backend, via une API REST ou une fonction cloud.
Ce que le webhook doit recevoir : un contrat de données clair
Le bon réflexe consiste à définir un contrat stable : identifiant du café, liste des toppings, quantité, éventuellement nom/prénom, mode de retrait. Grâce aux entités en IDs, vous évitez les ambiguïtés. Votre endpoint reçoit par exemple : coffeeId=CAFE_001, toppings=[TOP_001, TOP_002]. Vous gagnez en performance et en fiabilité, et vous facilitez l’analytique (top produits, combinaisons).
Pour “Café des Halles”, ce contrat sert aussi à la préparation : les baristas n’ont pas besoin de relire une phrase, ils reçoivent une fiche structurée. L’impact est immédiat sur le temps moyen de traitement, surtout à l’heure de pointe.
Exemple Node/Express : endpoint minimal pour traiter une commande
Voici un exemple volontairement simple d’API REST. Il illustre la logique : valider les paramètres, créer une commande, renvoyer une réponse au bot. En production, vous ajouterez authentification, logs, idempotence, et contrôle de stock.
Exemple de contrat JSON attendu
- coffeeId : identifiant produit (ex. CAFE_001)
- toppings : liste d’identifiants (ex. TOP_001, TOP_005)
- quantity : entier
Snippet Node/Express (illustratif)
POST /order
Valide les champs, crée une commande, renvoie un message de confirmation.
Mesurer et piloter : le webhook comme point de contrôle ROI
Le webhook est aussi l’endroit idéal pour poser des métriques. Vous pouvez logger : temps de réponse backend, taux d’erreur, produits les plus demandés, abandons après confirmation. Cette approche fait le lien entre expérience client et performance opérationnelle.
Si vous suivez déjà des indicateurs de callbot, vous pouvez étendre la même logique. Pour cadrer les bons KPI, l’article mesurer l’efficacité d’un callbot avec les bons KPIs est un bon point d’appui, car le pilotage se ressemble énormément côté voix.
| Composant | Rôle dans le Voicebot | Bonnes pratiques | Risque si négligé |
|---|---|---|---|
| Entités (IDs) | Normaliser les produits et options | Utiliser des identifiants stables + synonymes | Erreurs de mapping, commandes incohérentes |
| Intents | Détecter l’intention de l’utilisateur | Une intention = un objectif, exemples variés | Confusions, mauvaise compréhension |
| Routage (pages/flows) | Orchestrer le parcours | Transitions explicites, chemins de correction | Boucles, abandons, transferts inutiles |
| Webhook | Déclencher l’action métier | Contrat de données, logs, gestion d’erreur | Bot “parle” mais ne produit aucune valeur |
À ce stade, vous avez un bot qui comprend, collecte et transmet. La suite logique consiste à le rendre accessible sur un vrai canal voix, avec un numéro et une intégration téléphonie.
À retenir
Si votre Voicebot n’appelle aucun webhook, il reste un démonstrateur. Dès que vous connectez le SI, il devient un levier d’automatisation mesurable.
Découvrir AirAgent – Votre assistant IA vocal clé en main
Brancher la téléphonie et industrialiser l’expérience : du test console à l’appel réel
Le passage “démo console” vers “appel téléphonique” est souvent le moment où les projets se jouent. En test, tout va vite : une phrase propre, un environnement calme. En appel réel, il y a du bruit, des accents, des hésitations, et surtout des attentes : l’utilisateur pense parler à un service. Vous devez donc prévoir une intégration téléphonie, une stratégie d’escalade vers un humain, et des messages courts adaptés à l’oral.
Associer un numéro à Dialogflow via une intégration type AudioCodes
Une approche répandue consiste à utiliser une intégration téléphonie prête à l’emploi, comme AudioCodes, qui permet d’attribuer un numéro de téléphone à votre bot Dialogflow. L’idée est simple : l’appel arrive, le flux vocal est géré, et la conversation est routée vers Dialogflow. L’avantage : vous évitez de reconstruire toute la couche VoIP et vous accélérez le time-to-market.
Dans Dialogflow, vous activez l’intégration, puis vous finalisez côté portail téléphonie (création/association du numéro). Ensuite, vous appelez et vous testez. Le test doit être fait avec des personnes différentes, dans des conditions différentes (rue, bureau, voiture en mains libres). Un Voicebot est “bon” quand il reste solide en situation réelle, pas quand il brille dans un environnement de laboratoire.
Concevoir des prompts vocaux efficaces : courts, guidants, non robotiques
Un piège fréquent est de trop parler. À l’écrit, un long message passe encore. À l’oral, il fatigue. Préférez des prompts courts, suivis d’exemples : “Quel café souhaitez-vous ? Espresso, cappuccino, ou café noir ?”. Pour les garnitures, proposez 3 à 5 options, pas 15. Et si le client répond hors cadre, le bot doit reformuler sans culpabiliser : “Je peux vous proposer espresso, cappuccino, ou café noir. Lequel choisissez-vous ?”.
Pour “Café des Halles”, une bonne pratique est de capter l’essentiel en une question, puis d’offrir une porte de sortie : “Vous pouvez aussi dire ‘conseil’ si vous hésitez”. Cela réduit l’abandon et donne le sentiment d’un service attentionné.
Tests, itérations, et montée en charge : traiter la voix comme un produit
Industrialiser implique de tester et d’itérer. Prenez un échantillon de 50 à 100 conversations, analysez les incompréhensions, enrichissez les expressions d’entraînement, ajustez les entités. Ensuite, élargissez. Cette boucle ressemble beaucoup à l’optimisation d’un chatbot, et les méthodes sont proches : collecte de verbatims, regroupement des échecs, amélioration continue. Pour des méthodes concrètes, vous pouvez vous inspirer de l’optimisation des performances d’un chatbot, transposable au Voicebot.
Enfin, ne négligez pas l’escalade. Un bot vocal “sans échappatoire” crée de la frustration. Préparez une route “Parler à un conseiller”, et définissez les conditions : après deux incompréhensions, après une demande explicite, ou sur certains segments VIP. C’est paradoxal, mais offrir un transfert simple améliore l’acceptation du bot et renforce la confiance.
Si vous développez aussi un canal mobile, le codelab Flutter est une bonne ressource pour intégrer texte et voix dans une app : atelier Dialogflow avec Flutter en français. Cela ouvre des scénarios hybrides : je parle, puis je confirme sur écran, ce qui peut augmenter la fiabilité sur les données sensibles.
Tester gratuitement le callbot AirAgent – Sans engagement
Dialogflow CX ou ES : lequel choisir pour un Voicebot de commande ?
Si votre parcours est linéaire et limité à quelques échanges, Dialogflow ES peut suffire. Dès que vous avez plusieurs étapes, des corrections, des options (quantités, personnalisation) et une logique de pages/flux plus structurée, Dialogflow CX devient plus adapté et plus maintenable à l’échelle.
Comment améliorer la reconnaissance vocale dans un environnement bruyant ?
Travaillez sur des prompts plus courts, validez les informations critiques (produit, quantité), et ajoutez des synonymes/variantes dans les entités. Testez en conditions réelles (rue, open space, voiture) et itérez sur les échecs observés plutôt que sur des hypothèses.
Pourquoi utiliser des IDs d’entités au lieu d’envoyer ‘espresso’ au backend ?
Les IDs stabilisent l’intégration : votre SI reçoit une valeur unique, indépendante des accents, synonymes ou reformulations. Vous réduisez les erreurs, accélérez le traitement, et facilitez la mesure (statistiques par produit, par option) sans nettoyage de texte.
Un Voicebot peut-il coexister avec un chatbot et un agent humain ?
Oui, et c’est même recommandé. Le Voicebot automatise les demandes vocales répétitives, le chatbot traite l’écrit (site, app, messageries), et l’humain récupère les cas complexes. L’important est d’assurer la continuité (même base de connaissances, mêmes règles métier, transfert fluide).
