Un agent vocal IA pour restaurant ne se valide pas avec une seule réservation réussie. Avant sa mise en service, il faut vérifier ce qu'il répond, ce qu'il enregistre et ce qu'il fait lorsque la situation ne correspond pas au scénario idéal. Les douze tests ci-dessous couvrent les appels courants, les erreurs et la reprise par l'équipe.
L'objectif n'est pas de piéger l'agent. Il est de s'assurer qu'une conversation agréable produit aussi un résultat métier fiable.
Préparer un environnement de test réaliste
Commencez avec une copie ou un environnement de démonstration de votre système de réservation. Les tests ne doivent pas créer de vraies tables, envoyer des confirmations à des clients ou modifier le planning de production.
Préparez ensuite une fiche de restaurant validée : horaires habituels et exceptionnels, capacité par service, taille maximale d'un groupe, informations pratiques, règles de transfert et personnes à prévenir. Une information absente de cette fiche doit rester absente de la réponse de l'agent.
Pour chaque appel, conservez quatre éléments : la demande entendue, la réponse prononcée, les données enregistrées et l'action réellement effectuée. Cette trace permet de distinguer une bonne formulation d'une exécution correcte.
Tester les réservations simples et leurs variantes
Les premiers scénarios vérifient la collecte et la confirmation des informations critiques.
1. Une réservation complète
Demandez une table en donnant la date, l'heure, le nombre de personnes et le nom dans une seule phrase. L'agent doit conserver les informations déjà fournies, vérifier le créneau et relire les éléments utiles avant de conclure.
La réservation ne doit être annoncée comme confirmée qu'après la réponse positive du système métier. Une simple compréhension de la phrase ne vaut pas confirmation.
2. Un créneau indisponible
Choisissez volontairement un horaire complet ou fermé. Vérifiez que l'agent ne force pas la demande et ne promet pas de table. Il peut proposer une alternative issue du système, recueillir une préférence ou transmettre la demande selon les règles prévues.
3. Une correction en cours d'appel
Commencez par réserver pour deux personnes, puis corrigez pour quatre. Changez ensuite l'heure. Le récapitulatif final doit contenir uniquement les dernières valeurs, sans mélanger l'ancienne et la nouvelle demande.
4. Une modification ou une annulation
Demandez à déplacer puis à annuler une réservation existante. L'agent doit identifier la bonne réservation avec les données autorisées, distinguer modification et création, puis attendre le résultat du système avant de confirmer l'action.
Provoquer les erreurs que les vrais appels contiennent
Un appel réel comporte des hésitations, du bruit et des demandes incomplètes. Ces cas révèlent souvent davantage que la démonstration idéale.
5. Une date ou une heure ambiguë
Utilisez une formulation comme « vendredi soir » ou « vers huit heures ». L'agent doit demander la précision nécessaire. Il ne doit pas choisir silencieusement une date, un service ou un horaire.
6. Une parole mal comprise
Appelez dans un environnement bruyant, interrompez une phrase ou utilisez un nom difficile à transcrire. L'agent doit faire répéter uniquement l'information incertaine, puis relire les données critiques. Une incompréhension répétée doit conduire à une prise de message ou à un transfert.
7. Une information absente
Posez une question dont la réponse n'existe pas dans la base validée, par exemple sur une animation exceptionnelle. La bonne réponse consiste à reconnaître la limite et à proposer une reprise humaine. Inventer une réponse vraisemblable reste une erreur.
8. Une question sensible
Testez une demande liée aux allergènes ou à une contrainte qui nécessite l'avis de l'équipe. L'agent peut restituer une information explicitement validée, mais il doit transmettre dès que la réponse dépend de la préparation, d'une contamination croisée ou d'un cas particulier.
Vérifier la reprise humaine et les cas hors périmètre
Le passage à un humain n'est pas un échec du dispositif. C'est une fonction à concevoir et à tester.
9. Une demande de groupe ou de privatisation
Appelez pour un groupe dépassant la limite prévue. Vérifiez que l'agent collecte les informations utiles sans confirmer la faisabilité, puis transmet une synthèse exploitable : date, taille du groupe, coordonnées et attente principale.
10. Une réclamation ou une demande explicite de responsable
L'agent ne doit pas retenir l'appelant dans un scénario commercial. Il applique la règle de transfert, ou explique clairement qu'un rappel est nécessaire lorsque personne n'est disponible.
Le tableau de bord doit permettre à l'équipe de retrouver la demande sans écouter tout l'appel ni redemander les mêmes informations au client.
Tester les incidents techniques de bout en bout
Les deux derniers scénarios portent sur le système complet : téléphone, agent, réservation et suivi.
11. Une indisponibilité de l'outil de réservation
Coupez volontairement l'accès à l'environnement de test. L'agent ne doit jamais transformer une erreur technique en réservation confirmée. Il peut recueillir une demande à valider, annoncer qu'une confirmation sera nécessaire ou passer la main selon le fonctionnement choisi.
Vérifiez aussi que l'incident apparaît dans le suivi et qu'il est possible de retrouver les demandes concernées.
12. Une interruption au mauvais moment
Coupez l'appel juste avant ou juste après l'enregistrement d'une réservation, puis rappelez avec la même demande. Ce test vérifie qu'une reprise ne crée pas silencieusement deux réservations et que l'équipe peut comprendre l'état final.
La téléphonie de bout en bout compte ici davantage qu'un test réalisé uniquement dans un navigateur : latence, coupures, transferts et actions métier doivent être observés ensemble.
Construire une grille de validation utile
Notez chaque scénario avec des critères simples et reproductibles :
| Critère | Question de contrôle |
|---|---|
| Compréhension | Les informations prononcées ont-elles été comprises sans déformation ? |
| Données | Les valeurs critiques ont-elles été structurées et relues ? |
| Action métier | Le système de réservation reflète-t-il exactement la conversation ? |
| Limites | L'agent a-t-il évité toute réponse ou confirmation non vérifiée ? |
| Reprise humaine | Le transfert ou le message contient-il ce dont l'équipe a besoin ? |
| Expérience | Le dialogue reste-t-il clair, court et naturel malgré l'incident ? |
Un scénario n'est validé que si la conversation et le résultat métier sont tous les deux corrects. Après un changement important, rejouez la même série de tests afin de comparer les résultats dans des conditions identiques.
Questions fréquentes
Combien de fois faut-il rejouer chaque scénario ?
Une seule réussite ne suffit pas à conclure. Rejouez les cas critiques avec plusieurs formulations, des voix et des conditions d'appel différentes. Le nombre de répétitions dépend du risque et du volume attendu ; l'important est de conserver le même protocole pour comparer les versions.
Peut-on tester sans connecter le logiciel de réservation ?
Oui, pour évaluer la compréhension et le dialogue. En revanche, vous ne validez pas ainsi la réservation de bout en bout. Une mise en service qui promet une action dans un outil doit être testée avec cette intégration, dans un environnement sûr.
Qui doit participer à la validation ?
La personne qui connaît les règles de réservation, un membre de l'équipe qui reprend les cas complexes et la personne responsable de l'intégration. Chacun vérifie une partie différente du résultat.
Faut-il tout automatiser avant le lancement ?
Non. Un périmètre plus étroit, avec des transferts bien conçus, est souvent plus simple à vérifier. Il pourra évoluer lorsque les appels observés et les résultats mesurés le justifient.
Pour préparer le projet, consultez le guide de cadrage des réservations et le périmètre de l'agent vocal AQG.