Aller au contenu
WhatsApp y agenda

Comment fonctionne un assistant de rendez-vous par WhatsApp, de l’intérieur

Un assistant de rendez-vous n’est pas « un bot ». Ce sont sept pièces, et la plus importante est celle qui empêche le modèle de décider de l’agenda.

Publié 11 min de lecture Navhera

Presque tout ce qui se publie sur les assistants de rendez-vous par WhatsApp décrit le résultat : le client écrit, le système fixe le rendez-vous, tout le monde est content. Ce qui n’est pas décrit, c’est la machine, et c’est là que se décide si le système tient le deuxième mois ou s’il fixe à quelqu’un un rendez-vous le 31 février.

Cet article ouvre la boîte. Ce sont sept pièces, et la plus importante n’est pas le modèle de langage.

Les sept pièces

Un assistant de rendez-vous par WhatsApp se compose de : un canal qui reçoit et envoie les messages, un modèle de langage qui interprète ce qu’a dit le client, une mémoire qui retient la conversation, des outils qui consultent l’agenda et y écrivent, un validateur en code qui applique les règles de l’activité, une sortie vers une personne et un journal de tout ce qui s’est passé. Lui retirer n’importe laquelle des sept en fait une démonstration, pas un système.

1 · Le canal

WhatsApp ne permet pas qu’un programme se connecte à un compte personnel. Pour qu’un système lise et écrive des messages, il faut passer par la plateforme professionnelle de Meta — sur le numéro que vous utilisez déjà dans l’application WhatsApp Business, le cas échéant —, qui remet les messages entrants à un serveur à vous et reçoit les sortants par une interface de programmation. Cela apporte ses propres règles commerciales — ce qui peut être envoyé, quand et à quel coût — développées dans l’article sur la WhatsApp Business API.

2 · Le modèle

Son travail est de comprendre, pas de décider. Il reçoit ce qu’a écrit le client — avec ses fautes de frappe, ses détours et ses « plutôt jeudi, non, pardon, vendredi » — et produit deux choses : ce que veut la personne et quelles données elle a fournies.

« Vous auriez de la place demain après-midi pour une coupe et la barbe ? » devient : intention de prendre rendez-vous, prestations coupe et barbe, date de demain, créneau de l’après-midi. C’est tout ce que fait le modèle à ce stade. Il ne consulte pas l’agenda et ne confirme rien, parce qu’il ne le peut pas : il n’a aucun moyen de le savoir.

3 · La mémoire

Les modèles de langage ne retiennent rien d’un message au suivant. Ce qui ressemble à de la mémoire, c’est le programme qui enregistre la conversation et la renvoie à chaque tour.

Dans une activité réelle, cela compte pour trois raisons pratiques. La première est que le client peut disparaître au milieu d’une conversation et revenir deux jours plus tard, et que le système devrait le reconnaître sans lui faire tout répéter. La deuxième est qu’un client qui revient le mois suivant s’attend à être reconnu. La troisième est de coût : comme l’historique est renvoyé en entier à chaque tour, une conversation longue coûte plus cher qu’une courte, et c’est pour cela que les systèmes sérieux résument le vieux au lieu de le traîner en entier.

4 · Les outils

Ce sont les fonctions que le programme expose au modèle pour qu’il puisse demander leur exécution. Dans un assistant de rendez-vous, au minimum : consulter les disponibilités sur une plage, créer un rendez-vous, l’annuler, le déplacer et retrouver le client par son numéro.

Le modèle n’exécute rien de son propre chef : il demande, et le programme décide s’il exécute. C’est cette distinction qui sépare un agent d’un générateur de texte, et elle est développée dans qu’est-ce qu’un agent d’IA.

5 · Le validateur — la pièce qui soutient tout

Les règles dures de l’activité se valident dans le code, jamais dans le modèle. Les horaires d’ouverture, les jours de fermeture, l’heure du déjeuner, la durée de chaque prestation, combien de personnes tiennent à la même heure, avec quel délai on peut réserver et jusqu’à quand on peut annuler : tout cela, c’est un programme déterministe qui le vérifie avant d’écrire quoi que ce soit.

Le motif est qu’un modèle de langage est probabiliste par construction. Il aura raison presque toujours, et ce « presque » est le problème : sur un agenda, presque toujours signifie un rendez-vous impossible toutes les quelques semaines, et ce sont précisément ceux dont le client se souvient.

Avec un validateur, le flux est autre : le modèle propose 20 h un dimanche, le code le refuse et renvoie le motif, et le modèle reformule avec les heures qui existent réellement. Le client ne voit jamais le refus ; il voit un assistant qui propose des options correctes.

6 · La sortie vers une personne

Tout assistant a besoin d’une porte par où sortir. Il y a trois moments où il doit l’utiliser sans hésiter : quand le client demande à parler à quelqu’un, quand apparaît une réclamation ou une question d’argent, et quand le système lui-même n’arrive pas à résoudre après deux tentatives.

La part que l’on oublie, c’est le retour. Si une personne prend la conversation, l’assistant doit se taire — pas continuer à répondre par-dessus — et il faut une façon explicite de lui rendre le contrôle. Un assistant qui interrompt son propre propriétaire pendant qu’il s’occupe d’un client est pire que pas d’assistant du tout.

7 · Le journal

Ce qui s’est dit, quels outils ont été appelés, ce qu’ils ont répondu et ce qui a été écrit dans l’agenda. Cela sert à trois choses : comprendre pourquoi le système a fait quelque chose d’étrange, démontrer à un client ce qui a été convenu, et savoir combien cela coûte vraiment.

Sans journal, tout problème s’examine en demandant au modèle ce qui s’est passé, ce qui revient à interroger quelqu’un qui ne se souvient pas.

À quoi ressemble une conversation vue de l’intérieur

Ce que voit le clientCe qui se passe derrière
« Vous auriez de la place demain après-midi ? »Le canal remet le message. L’historique de ce numéro est chargé. Le modèle interprète : prendre rendez-vous, demain, après-midi.
(en train d’écrire…)Le modèle demande de consulter les disponibilités. Le programme exécute la requête contre l’agenda et vérifie horaires, déjeuner et durée de la prestation.
« Demain j’ai 14 h et 16 h 30. Laquelle vous convient ? »Seules sont proposées les heures qui ont passé le validateur. Celles qui n’existent pas ne sont jamais arrivées jusqu’à la réponse.
« Celle de 16 h 30 »Le modèle interprète le choix. On revérifie que l’heure est toujours libre, parce qu’entre un message et l’autre elle a pu être prise.
« C’est noté, ce sera demain à 16 h 30. »Le rendez-vous est écrit, enregistré dans le journal, et le rappel est programmé.

La deuxième vérification de disponibilité est le genre de détail qui sépare un pilote d’un système. Entre le moment où l’assistant propose un horaire et celui où le client l’accepte, il peut s’écouler des minutes, et pendant ce temps quelqu’un d’autre a pu le prendre par téléphone.

Ce qui se passe mal dans la vraie vie

  • Deux clients qui demandent la même heure en même temps. Cela se résout en écrivant le rendez-vous de façon que le système d’agenda refuse le second, pas en comptant sur le fait que cela n’arrive pas.
  • Le client qui change d’avis trois fois dans un même message. C’est la part qu’un menu de boutons ne gère pas et qu’un modèle gère, à condition de confirmer avant d’écrire.
  • Les messages qui ne portent pas sur l’agenda. « Combien ça coûte ? », « vous êtes où ? », « vous ouvrez le dimanche ? ». Mieux vaut décider d’avance auxquels il répond et lesquels il passe à une personne.
  • L’agenda modifié à la main. Le propriétaire déplace un rendez-vous depuis son téléphone. Le système doit toujours lire l’agenda réel, pas une copie à lui.
  • Le service en panne. Si l’agenda ne répond pas, l’assistant doit le dire et proposer qu’une personne confirme, pas inventer un horaire.

D’où vient cette description. De la construction et de l’exploitation de ce type de système. Les sept pièces et l’ordre dans lequel elles cassent, c’est ce que l’on apprend en les montant, pas une liste théorique.

Ce qu’il convient d’avoir réglé avant de commencer

  1. Un agenda qui soit la source de vérité, dans un système, pas dans un cahier ni dans la tête de quelqu’un.
  2. Les règles écrites : horaires, prestations, durées, qui s’occupe de quoi, politique d’annulation.
  3. Une ligne WhatsApp pour l’entreprise, séparée de la ligne personnelle de qui s’en occupe.
  4. Quelqu’un qui reçoive ce que l’assistant fait remonter, avec un délai de réponse convenu.

Si l’un des quatre manque, c’est le premier travail. La division technique l’examine lors de la réunion initiale, avant de chiffrer quoi que ce soit.

Questions fréquentes

Un assistant de rendez-vous par WhatsApp peut-il se tromper et mal fixer un rendez-vous ?

Il le peut, si le système laisse le modèle de langage décider sur l’agenda. Dans un système bien construit, les règles — horaires, jours de fermeture, durée de chaque prestation, capacité — se valident dans le code avant d’écrire quoi que ce soit, de sorte qu’une heure impossible est refusée avant d’arriver au client.

Peut-on utiliser le compte WhatsApp que l’entreprise a déjà ?

Oui, si vous répondez aujourd’hui avec l’application WhatsApp Business. Depuis 2025, Meta admet la coexistence : ce même numéro se connecte à la plateforme professionnelle sans en changer, l’historique reste synchronisé et vous continuez à répondre à la main depuis l’application pendant que l’assistant répond par la plateforme. Cela exige l’application en version 2.24.17 ou postérieure. Ce qu’on ne peut pas faire, c’est connecter un programme à un compte WhatsApp personnel.

Que se passe-t-il quand le client veut parler à une personne ?

L’assistant doit cesser de répondre et prévenir immédiatement qui s’occupe des clients, et il doit exister une façon explicite de lui rendre le contrôle ensuite. Un assistant qui continue à répondre pendant qu’une personne s’occupe de la même conversation cause plus de problèmes qu’il n’en résout.

Combien de temps faut-il pour qu’un assistant de rendez-vous soit prêt ?

Cela dépend surtout de deux choses qui ne sont pas techniques : si l’agenda vit déjà dans un système et si les règles de l’activité sont écrites. Les deux étant réglées, la construction est la partie courte ; sans elles, les mettre en ordre est le vrai projet.

Sources et notes

  1. Description fondée sur la construction et l’exploitation d’agents conversationnels propres à Navhera.
  2. Les restrictions du canal suivent la documentation officielle de la WhatsApp Business Platform de Meta.

Écrit par l’équipe de Navhera et relu avant publication. Si vous repérez une erreur, écrivez-nous : nous la corrigeons en le signalant.