Prise de rendez-vous par chatbot pour cabinets et studios : agenda, règles, minimisation des données

Le quotidien d'un petit cabinet ou d'un studio a un rythme qui figure rarement dans l'agenda. La plupart des appels arrivent entre 7 h 30 et 9 h, précisément lorsque la personne à l'accueil salue les patients, réceptionne des documents et prépare les salles. Dans ce scénario, nous supposons une équipe de deux praticiens et un poste d'accueil. Celui qui appelle veut le plus souvent quelque chose de simple : un rendez-vous, un report, une annulation.

Le résultat est un conflit d'objectifs silencieux. Soit l'appel est interrompu parce que quelqu'un se tient au comptoir, soit la personne sur place attend pendant que l'on cherche la réponse au téléphone. Certains appelants ne joignent personne et n'essaient pas une seconde fois. Ce qui se perd ainsi n'apparaît dans aucune statistique, car une conversation qui n'a pas eu lieu ne laisse aucune trace.

S'y ajoute le moment. Beaucoup de gens pensent à leur rendez-vous le soir, quand le cabinet est fermé, ou à la pause de midi, quand personne ne décroche. Un répondeur recueille alors des demandes de rappel qu'il faut traiter en plus le lendemain matin et qui grossissent la pile à l'accueil avant même que la journée n'ait commencé.

Un chatbot pour la prise de rendez-vous s'attaque à cette routine, pas au traitement. Il doit absorber les cas récurrents et transmettre proprement tout le reste à des personnes. Cette ambition semble modeste, mais elle est techniquement plus exigeante qu'il n'y paraît, car un rendez-vous n'est pas un bloc de texte, mais une décision aux conséquences sur le déroulement de la journée.

Au premier abord, il suffit de lire les créneaux libres de l'agenda et de les proposer. En pratique, cela échoue sur de petits détails qui, ensemble, posent problème. Un premier examen dure plus longtemps qu'un contrôle. Certaines prestations nécessitent une salle précise ou un appareil. Après un soin, l'équipe a besoin de temps pour ranger, désinfecter ou documenter. Un agenda qui ne connaît que « occupé » ou « libre » ne rend pas cela.

S'y ajoutent les accès simultanés. Deux personnes choisissent au même instant le même créneau pendant qu'à l'accueil quelqu'un inscrit un rendez-vous à la main. Sans logique de verrouillage, des doubles réservations surviennent, que l'on ne remarque que lorsque les deux se tiennent à la porte. Le contraire est aussi pénible : un bot qui, par prudence, propose à peine des créneaux passe pour un obstacle et renvoie quand même les gens au téléphone.

Le point le plus sensible est de savoir ce que l'on peut demander dans le chat. Qui attribue des rendez-vous pour des prestations médicales ou thérapeutiques s'aperçoit vite que des questions aimables (« Qu'est-ce qui ne va pas ? ») mènent dans une direction délicate juridiquement et humainement. Selon le RGPD, les données de santé constituent une catégorie particulière de données à caractère personnel. C'est un repère connu, pas un conseil juridique, et il invite à en toucher le moins possible dans le chat.

L'aiguillage le plus important ne concerne pas la formulation, mais la compétence. Un modèle de langage peut comprendre des demandes et répondre aimablement, mais il ne devrait jamais décider si un rendez-vous est possible. Cette décision revient au système d'agenda avec ses règles. Le modèle fait l'interface entre la personne et le système, comme un bon accueil fait le lien entre le patient et le carnet de rendez-vous.

On en tire une question de contrôle pour chaque fonction : le modèle peut-il ici inventer quelque chose qui figurera plus tard dans l'agenda ? Pour la proposition de créneaux, la réponse est non, si les créneaux proviennent d'une interface et que le bot ne fait que les restituer. Pour les descriptions libres (« c'est urgent », « mon enfant a mal »), la réponse est oui, et c'est précisément là qu'intervient le transfert au personnel.

Cela a des conséquences pour la protection des données. Si le bot n'a besoin que du type de rendez-vous, du créneau souhaité et de la voie de contact, il n'a rien d'autre à demander. Ce qui n'est pas collecté n'a pas à être protégé, stocké ni supprimé. La minimisation des données n'est pas ici un supplément, mais une décision de conception qui simplifie la structure et réduit la surface d'erreurs et d'abus.

De ce point de vue, une pondération simple se dégage. Moins le bot doit interpréter, plus il travaille de façon fiable. Nous déciderions donc tôt quelles demandes il traite entièrement, lesquelles il ne fait que préparer et lesquelles il transmet immédiatement. Cette répartition en trois compte plus que toute finesse dans le ton de la conversation.

Il existe en gros trois possibilités. La première est un widget de réservation classique, avec formulaire et calendrier, intégré au site web. Il est stable, prévisible et n’exige aucun dialogue. Sa faiblesse tient aux personnes qui ne savent pas de quel type de rendez-vous elles ont besoin, et aux questions qui ne rentrent pas dans des champs de formulaire. Celui qui hésite abandonne souvent ou finit par téléphoner.

La deuxième possibilité est un dialogue qui s’appuie sur la logique de rendez-vous du calendrier existant. En quelques questions, le bot détermine quel rendez-vous convient et propose des créneaux précis. Il peut répondre aux questions complémentaires (« Combien de temps cela dure-t-il ? », « Dois-je apporter quelque chose ? ») sans que personne dans l’équipe n’ait à écrire un message. Cette voie associe la fiabilité du calendrier à l’accessibilité de la conversation.

La troisième possibilité serait un assistant à formulation libre, qui attribue des rendez-vous sans séquence fixe. C’est ce qui paraît le plus moderne et le plus risqué. Quand on laisse la bride au modèle, on obtient des rendez-vous qui sonnent bien mais conviennent mal, et un comportement difficile à tester. Pour un cabinet où un mauvais rendez-vous irrite ou met en danger les personnes, ce n’est pas le lieu des expériences.

Nous choisirions donc la deuxième voie et conserverions le widget comme solution de repli. Celui qui ne veut pas du dialogue réserve directement. Celui qui reste bloqué dans le dialogue est transféré à une personne. Le bot complète les canaux existants, il ne les remplace pas. Cela limite le risque et permet de développer l’ensemble par étapes sans perdre la confiance.

La conception commence par une liste des types de rendez-vous. Chaque type reçoit un nom, une durée, les personnes responsables, le délai nécessaire et une indication sur ce qu’il faut savoir au préalable. Dans un cabinet, il pourrait s’agir de premier contact, de contrôle et de rendez-vous court ; dans un studio, de séance d’essai, d’entraînement individuel et de cours. La liste semble banale, mais elle est la base de tout le reste et devrait être rédigée par l’équipe elle-même, non par les techniciens.

La conversation suit alors quelques étapes : identifier la demande, confirmer le type de rendez-vous, choisir l’horaire, indiquer les coordonnées. Chaque étape a une forme claire, par exemple des champs de sélection plutôt que du texte libre dès que c’est possible. Cela accélère l’échange et évite que les gens n’écrivent inutilement des informations personnelles. Le texte libre est permis, mais non exigé, et une mention explique que les détails médicaux ne sont pas nécessaires ici.

À la fin, une confirmation succincte apparaît dans le chat avec la date, l’heure, le lieu et la durée, ainsi que la manière d’annuler ou de reporter. Le même texte est envoyé à l’adresse de contact indiquée. Celui qui ne peut pas lire une confirmation parce qu’elle disparaît dans une fenêtre de chat risquerait sinon de manquer son rendez-vous. Le choix des mots compte aussi : « Votre rendez-vous est réservé » sonne autrement que « confirmé », et si une validation par l’équipe est nécessaire, le bot doit le dire clairement.

Sur le plan technique, la connexion au calendrier est le point le plus critique. Le bot ne lit pas les créneaux libres dans une copie, mais les interroge en direct à chaque demande. Que cela passe par une interface du logiciel du cabinet, un calendrier en ligne ou un système de réservation dépend de l’existant. Nous commencerions par établir ce que le système en place offre réellement avant de construire quoi que ce soit de nouveau. Certains systèmes n’autorisent que l’accès en lecture, d’autres distinguent proprement types de rendez-vous et salles.

Une courte réservation aide à éviter les doubles réservations. Dès que quelqu’un choisit un créneau, celui-ci est bloqué pendant quelques minutes jusqu’à la confirmation ou l’expiration du délai. Si, à la même seconde, l’équipe saisit un rendez-vous, c’est l’opération d’écriture dans le calendrier qui tranche, non le bot : si elle échoue, la personne reçoit aussitôt de nouvelles propositions. L’essentiel est qu’un seul et même système détienne toujours la vérité et que le bot ne tienne pas sa propre copie.

Les marges et les types de rendez-vous sont enregistrés sous forme de règles. Un contrôle de vingt minutes peut être assorti de cinq minutes de battement, un premier examen d’un délai pour l’inscription et les documents. Un délai minimal (aucun rendez-vous dans l’heure suivante sans confirmation) et des plafonds, par exemple pour les rendez-vous en ligne par jour, sont également utiles. Ces limites protègent le déroulement de la journée et peuvent être modifiées sans programmation, dès lors qu’elles figurent dans une configuration.

Les rappels passent par des messages que le bot ne rédige pas lui-même, mais génère à partir de modèles fixes. Ils indiquent la date, le lieu et la durée, contiennent un lien pour annuler ou reporter et arrivent à l’intervalle choisi par le cabinet. En cas d’annulation, le système libère immédiatement le créneau afin qu’il puisse être réattribué. Qui travaille avec une liste d’attente peut proposer des créneaux libres de façon ciblée, à condition que les personnes concernées y aient consenti.

Les cas particuliers décident si l’équipe fait confiance au bot. Le premier est l’annulation la veille au soir ou le matin même. Elle doit être aussi simple que la réservation, sinon la place reste vide et l’équipe ne l’apprend qu’à l’arrivée. Le bot reconnaît l’intention, confirme le rendez-vous concerné et libère le créneau. Les éventuelles conséquences d’une annulation tardive dépendent des règles du cabinet et sont mentionnées dans le chat de façon factuelle, sans commentaire.

Le deuxième cas est le problème qui semble urgent. Qui écrit au sujet de fortes douleurs, d’une difficulté à respirer ou d’un accident n’a pas besoin d’un calendrier. Dans de tels cas, le bot ne doit ni rassurer ni évaluer, mais renvoyer vers le numéro d’urgence et le cabinet dès que certains mots-clés ou formulations apparaissent. Cette détection doit être réglée largement : mieux vaut un transfert de trop qu’un de moins, même s’il est parfois inutile au quotidien.

Le troisième groupe est constitué des demandes qui ne sont pas des rendez-vous : demandes d’ordonnance, questions sur des résultats, factures, plaintes concernant un traitement. Le même principe s’applique ici. Le bot explique aimablement que cela ne passe pas par lui, indique la bonne voie et propose d’enregistrer une demande de rappel avec nom, moyen de contact et un mot-clé, sans détails. La demande de rappel arrive dans la boîte de réception de l’équipe, pas dans l’historique de chat de la plateforme.

Les ambiguïtés sont également délicates : enfants, proches qui réservent pour d’autres, ou rendez-vous à la suite pour plusieurs personnes. Le bot demande alors pour qui est le rendez-vous et, en cas de doute, transfère à une personne. Celui qui a été mal compris trois fois dans une conversation ne doit pas être interrogé une quatrième fois, mais joindre un humain. La règle « transférer après deux tentatives infructueuses » est simple et protège la confiance.

Un bot de rendez-vous doit soulager l’équipe et fiabiliser les rendez-vous. Y parvient-il ? On le voit à des indicateurs que le cabinet connaît déjà ou peut facilement relever : nombre d’appels de routine sur le créneau du matin, nombre de rendez-vous obtenus sans questions complémentaires, taux d’absences sans annulation et part des conversations transférées au personnel. Ce qui compte, c’est une comparaison sur plusieurs semaines avant et après le lancement, non l’impression de quelques jours.

Parmi les indicateurs de qualité figurent les doubles réservations, les types de rendez-vous mal choisis et les plaintes concernant des rendez-vous qui ne correspondaient pas à la situation. Ils sont rares lorsque les règles résident dans le calendrier, et ils sont la jauge à laquelle se joue la confiance. Une seule erreur bien visible pèse plus lourd dans l’équipe que dix réussites silencieuses ; c’est pourquoi il vaut la peine de lire ces cas un par un et pas seulement de les compter.

Ce que l’on ne peut pas promettre, ce sont des économies fixes ou un taux de remplissage donné. Ils dépendent du public cible, des horaires d’ouverture, des délais et de la propension des patients à réserver en ligne. Certains publics n’utilisent guère le chat, d’autres s’y mettent aussitôt. Les taux d’absence ne baissent pas non plus automatiquement : les rappels aident, mais ne remplacent pas une règle d’annulation claire. Il est plus fiable de fixer une mesure et d’y ajuster ses attentes.

Une image honnête se dégage lorsque les transferts sont eux aussi analysés. S’ils comprennent beaucoup de demandes que le bot aurait pu traiter, des règles ou des textes manquent. S’il s’agit de demandes qu’il ne devrait jamais traiter, il fonctionne correctement. Les deux sont des informations, non une défaite. L’analyse devrait être discutée chaque mois en équipe, avec des exemples concrets plutôt que des moyennes.

Premièrement : les types de rendez-vous sont le véritable projet. Qui les définit proprement a accompli la partie la plus difficile, car le bot n’a pas besoin d’intelligence mais d’un tableau précis. Les équipes qui portent jusqu’ici leur logique de rendez-vous dans leur tête découvrent souvent, en la mettant par écrit, des différences que personne n’avait jamais nommées, par exemple que la même prestation dure plus ou moins longtemps selon les deux praticiens.

Deuxièmement : le bot a besoin d’un caractère, mais ni d’un prénom ni d’un spectacle de personnalité. Des phrases courtes et calmes, des options claires et la mention ouverte qu’il s’agit d’un assistant automatique fonctionnent mieux qu’une fausse proximité. Que les gens sachent avec qui ils écrivent est un principe largement reconnu pour les chatbots et, au quotidien du cabinet, c’est tout simplement poli.

Troisièmement : le transfert mérite le même soin que la réservation. Il doit transmettre de façon compacte la demande de rendez-vous, le moyen de contact et ce que la personne a dit, sans collecter de détails de santé. La joignabilité compte ici plus que la rapidité : un transfert lu seulement le lendemain n’en est pas un. Nous définirions donc qui consulte la boîte de réception et quand, et ce qui se passe après la fermeture.

Quatrièmement : la protection des données et la documentation doivent venir en premier. Où circulent les données, qui est le sous-traitant, combien de temps les historiques sont-ils conservés, que dit la politique de confidentialité ? Ce sont des questions à régler avant le lancement et qu’un délégué à la protection des données ou un avocat doit examiner. Nous nommons les points mais ne donnons pas de conseil juridique, et des obligations de diligence renforcées s’appliquent dans le domaine de la santé.

La prise de rendez-vous par chatbot vaut la peine pour les cabinets et studios dont le téléphone est saturé aux heures de pointe et dont les types de rendez-vous peuvent être décrits clairement. Elle est moins intéressante lorsque presque chaque rendez-vous exige une concertation individuelle ou que le calendrier n’est pas accessible. Dans ce cas, il convient d’abord de mettre de l’ordre dans la gestion des rendez-vous avant d’y greffer un bot.

L’utilité ne naît pas de la conversation, mais de la discipline qui la sous-tend : un calendrier comme seule vérité, des règles en configuration plutôt que dans le modèle, peu de données collectées et un transfert qui fonctionne. Le résultat ne peut pas être garanti, mais il peut être vérifié, avec des chiffres que votre équipe connaît déjà.

Le fonctionnement après le lancement fait aussi partie du tableau. Les types de rendez-vous évoluent, les congés déplacent les responsabilités, de nouvelles prestations s’ajoutent. Quelqu’un dans l’équipe devrait pouvoir entretenir les règles sans appeler un prestataire, et relire de temps à autre les textes du bot. Un bot de rendez-vous n’est pas un projet ponctuel, mais un petit outil qui grandit avec le cabinet.

La prochaine étape est modeste : notez en une heure vos types de rendez-vous avec leur durée, leur marge et la personne responsable, et relevez quels appels reviennent le plus souvent au cours d’une semaine normale. À partir de cette liste, on peut juger si un bot serait pertinent et par où il devrait commencer. Nous l’examinons volontiers avec vous, sans engagement et avec une appréciation honnête.