Agent vocal pour les rendez-vous : comment concevoir une conversation utile
Évaluer un usage circonscrit de l'IA téléphonique sur les demandes entrantes.
L'équipe éditoriale SqualiOnline · 2026-09-07
Avant de se demander si un système automatique peut répondre au téléphone, il vaut mieux se demander quel appel il peut clore seul. Fixer un rendez-vous en fait partie : il a un but unique, peu d'informations à recueillir et un résultat vérifiable, c'est-à-dire un rendez-vous qui apparaît dans l'agenda et qui est le bon. Tout le reste doit être remis à une personne, et la façon dont cela se fait décide si le système est utile ou nuisible.
Le risque n'est pas que l'agent vocal parle mal. C'est qu'il termine l'appel en laissant celui qui a appelé convaincu d'avoir un rendez-vous qui n'existe pas, ou de ne pas en avoir un alors qu'il existe.
Ce qu'il doit savoir faire, et avec quelles données
Trois éléments, et aucun des trois n'est la voix.
- La disponibilité doit être la vraie, lue depuis l'agenda que les personnes utilisent réellement. Un calendrier copié ou mis à jour à la main produit des doubles réservations, et la première double réservation brûle la confiance interne dans le système.
- Les données minimales doivent être décidées avant : nom et prénom, un contact rappelable, le motif en deux mots et les informations qui changent la durée du rendez-vous. Tout le reste se demande en personne.
- La confirmation doit être écrite et partir immédiatement. Il faut établir où elle arrive, ce qu'elle contient, c'est-à-dire date, heure, lieu et ce qu'il faut apporter, et comment on annule. Si la confirmation ne part pas, le rendez-vous n'est pas confirmé.
Il faut aussi décider ce que le système ne peut pas faire : déplacer les rendez-vous d'autrui, réserver au-delà d'un certain nombre de jours, accepter des cas qui exigent une évaluation, donner des prix ou des délais de traitement.
Ce qui tourne mal au téléphone
Une conversation téléphonique ne se relit pas, elle se chevauche, et celui qui appelle est souvent dans la rue, à l'atelier ou avec quelqu'un à côté.
- Les noms propres : noms de famille longs, doubles lettres, noms étrangers. Ils doivent être répétés et relus à la fin, toujours, même quand ils semblent compris.
- Les dates relatives : jeudi prochain signifie des choses différentes pour des personnes différentes. Le système doit répondre avec la date complète et demander confirmation.
- Les numéros dictés : le contact doit être relu chiffre par chiffre, sans exception.
- Le bruit et les chevauchements : quelqu'un qui parle pendant que le système parle, quelqu'un qui s'interrompt, quelqu'un qui répond à quelqu'un d'autre dans la pièce.
- Les demandes doubles en une seule phrase : je voudrais un rendez-vous et savoir combien ça coûte. Le système doit gérer la première et transmettre la seconde, pas en ignorer une.
- Le silence de quelqu'un qui cherche son agenda : l'interpréter comme la fin de la conversation est un moyen sûr de perdre une réservation.
Un script démonstratif : trois appels
Date ambiguë
- La personne qui appelle dit qu'elle voudrait venir jeudi matin.
- Le système répète la date en entier, jour de la semaine, numéro et mois, et demande confirmation avant de chercher dans l'agenda.
- Si la personne corrige, on repart de la date et non du début de la conversation.
Horaire non disponible
- Le système propose deux alternatives proches, une avant et une après. Il ne lit pas une liste de dix horaires, que personne ne mémorise au téléphone.
- Si aucune ne convient, il demande une préférence générale, matin ou après-midi, cette semaine ou la suivante, et propose à nouveau.
- Si toujours rien ne se trouve, il recueille le contact pour un rappel et le dit explicitement : un opérateur vous rappellera, ce n'est pas moi qui m'en occupe.
Demande hors périmètre
- La personne qui appelle veut un devis pour un travail complexe.
- Le système déclare qu'il ne peut pas donner de devis, recueille le nom, le contact et deux mots sur le motif, et confirme que quelqu'un rappellera.
- Il n'improvise pas de chiffre, ne promet pas de délais, ne dit pas que cela coûte peu. Un système qui répond hors périmètre produit des engagements que l'entreprise n'a pas pris.
Dans les trois cas, une règle s'applique : à la fin, le système répète ce qu'il a compris, date, heure, nom et contact, et demande une confirmation explicite. C'est le seul moyen de s'apercevoir de l'erreur pendant que la personne est encore en ligne.
Le passage à une personne, et le canal alternatif
Les conditions de sortie doivent être écrites avant, pas ajustées après les premières plaintes.
- Si la personne qui appelle le demande, même de façon indirecte : puis-je parler à quelqu'un est une sortie immédiate.
- Après deux incompréhensions consécutives sur le même point.
- Quand la demande sort du périmètre : réclamations, urgences, situations délicates.
- Quand émerge quelque chose qui exige une évaluation humaine, de quelque nature que ce soit.
Le passage doit emporter avec lui ce qui a déjà été dit, le contact et le motif : faire tout répéter depuis le début annule l'avantage. Il faut aussi décider ce qui se passe quand il n'y a personne. Hors horaires, un message clair avec les horaires d'ouverture et l'engagement de rappeler vaut mieux qu'une conversation qui tourne à vide.
Avant de mettre en service : informations et vérifications
Certaines vérifications ne concernent pas la technologie et doivent être faites avant la mise en service, pas après le premier problème.
- La personne qui appelle doit savoir qu'elle parle à un système automatique. On le dit au début, en une phrase.
- Si l'appel est enregistré ou transcrit, les règles sur les enregistrements s'appliquent : information préalable, motif, durée de conservation, qui peut écouter.
- Les données recueillies sont des données personnelles et doivent être traitées comme celles d'un formulaire, avec les mêmes bases et les mêmes informations.
- Ce que le système dit doit être vérifié par rapport à ce que l'entreprise peut réellement affirmer et promettre.
Ces vérifications doivent être convenues avec la personne qui suit les obligations dans l'entreprise, ou avec un consultant. Un système techniquement excellent qui démarre sans ces réponses est un risque, pas une économie.
Ce que ce guide ne couvre pas
Ici, on parle d'appels entrants, c'est-à-dire de personnes qui vous appellent pour réserver. Les appels sortants à but promotionnel sont un sujet différent, avec ses propres contraintes et des vérifications à faire avant toute configuration : ce n'est pas un usage qu'on peut mettre en place par extension de ce qui est écrit ici. Quand un assistant doit s'arrêter et passer la main à une personne, et comment on le teste avant de le mettre en ligne, font l'objet de guides dédiés.
Questions fréquentes
Comment éviter que le système prenne des rendez-vous erronés ?
Avec trois précautions : lire la disponibilité depuis l'agenda réel, répéter à la fin toutes les données recueillies en demandant confirmation, et envoyer immédiatement une confirmation écrite. Pendant les premières semaines, il est en outre préférable qu'une personne revoie les rendez-vous pris la veille, jusqu'à ce que des erreurs récurrentes à corriger apparaissent.
Faut-il dire qu'il s'agit d'un système automatique ?
Oui, et cela vous est aussi favorable. Celui qui le sait dès le départ adapte sa façon de parler, répète les données et s'énerve beaucoup moins quand quelque chose n'est pas compris. Le découvrir au milieu de la conversation produit presque toujours un appel interrompu et une plainte.
Que se passe-t-il si la personne ne veut pas parler à un système ?
Elle doit pouvoir sortir immédiatement, sans devoir répéter sa demande ou passer par des étapes. Si personne n'est disponible à ce moment-là, le système recueille le contact et déclare qu'elle sera rappelée, en indiquant quand. Insister est le moyen le plus rapide de perdre un client qui appelait pour réserver.
Évaluons ensemble le parcours téléphonique pour vos rendez-vous.
Si vous voulez en parler, le service concerné est Intelligence artificielle.

