ElevenAgents pour la santé : créez un agent de planification des rendez-vous entrants

Le téléphone reste la porte d’entrée des soins de santé, mais il est saturé. La Mayo Clinic étude et les données d’Epic étude de cas montrent qu’environ 30 % des prises de rendez-vous ont lieu en dehors des horaires d’ouverture habituels. Les appels qui tombent sur la messagerie sont autant de rendez-vous qui n’ont discrètement pas lieu, tandis que les équipes d’accueil chargées de les traiter sont sous pression et se renouvellent rapidement. Les agents vocaux ont dépassé le stade de la démonstration pour aider les cliniques à combler ce manque. La prise de rendez-vous est leur point d’entrée le plus courant : un volume élevé, des tâches répétitives et prévisibles, et une part importante du travail d’accueil qui ne requiert aucun jugement clinique.

La prise de rendez-vous dans le secteur de la santé impose aussi des exigences plus élevées. Un créneau erroné ou un motif de consultation mal compris ne constitue pas seulement une mauvaise expérience : c’est un incident de sécurité et de conformité. Un agent de prise de rendez-vous à l’accueil a besoin de plus qu’une voix agréable : il lui faut une vérification fiable de l’identité, des garde-fous stricts, un chemin d’escalade clair vers un humain, le niveau de conformité nécessaire au traitement des informations de santé protégées, ainsi que la capacité de créer, modifier ou annuler des réservations dans un véritable système de planification.

Ce guide vous montre comment créer cet agent avec ElevenAgents : un agent accessible par téléphone, connecté à un DSE de démonstration, qui prend, modifie et annule des rendez-vous de bout en bout, et transfère l’appel lorsqu’il le faut. Vous disposerez du flux de travail, des garde-fous, des tests et des analyses nécessaires pour qu’il respecte son cadre — déployé sur une infrastructure conçue pour les environnements de santé réglementés.

Voici une démonstration de l’agent que vous allez créer, prenant en charge un appel en direct de bout en bout :

Prérequis

Pour commencer, vous aurez besoin des éléments suivants :

• Un compte ElevenLabs, avec accès à la plateforme ElevenAgents et à nos voix.
• Un compte Twilio et un numéro.
• Un accès à Twilio Verify.
• Un environnement DSE sandbox ou pour développeurs. Dans ce guide, nous utiliserons HAPI FHIR, une implémentation de référence open source du format HL7 FHIR, pour valider les informations avec des dossiers patients synthétiques.
• L’application de calendrier de votre cabinet. Pour ce guide, nous utilisons l’intégration native d’ElevenLabs avec Cal.com. 

Facultatif

Si vous n’avez pas accès à des données sandbox, ou si vous suivez ce guide à des fins de démonstration, nous utiliserons le serveur sandbox HAPI FHIR R4 et l’initialiserons avec un dossier patient fictif, utilisable lors de l’étape de vérification. Pour cela, exécutez la commande API suivante avec des données fictives dans votre terminal :

curl -X POST "https://hapi.fhir.org/baseR4/Patient" \
  -H "Content-Type: application/fhir+json" \
  -H "Accept: application/fhir+json" \
  -d '{
    "resourceType": "Patient",
    "identifier": [
      { "system": "http://hospital.example.org/mrn", "value": "<YOUR-FAKE-MRN-NUMBER>" }
    ],
    "name": [ { "use": "official", "family": "<YOUR-FAKE-FAMILY-NAME>", "given": [ "<YOUR-FAKE-GIVEN-NAME>" ] } ],
    "gender": "<male or female>",
    "birthDate": "<YOUR-FAKE-DOB> (in YYYY-MM-DD format)"
  }'

Une correspondance n’est confirmée que lorsque la requête renvoie exactement un dossier : aucun résultat signifie qu’il n’y a pas de correspondance, et plusieurs résultats indiquent que les paramètres de recherche ne sont pas assez précis pour poursuivre en toute sécurité. 

Architecture

Dans ce guide, vous allez créer un agent de planification fonctionnant via un numéro Twilio et intégré nativement à votre ElevenAgent. Lorsqu’un appel entrant est établi, l’agent accompagne le patient à l’aide de ses outils pour recueillir les informations de vérification et de rendez-vous, qu’il souhaite prendre un nouveau rendez-vous, en reprogrammer un ou annuler un rendez-vous existant. Il peut transférer l’appel à un humain si nécessaire.

Avec cette architecture et ces outils, un appel abouti suit les étapes suivantes :

1. Initiation de l’appel : un patient appelle le numéro Twilio associé à l’agent, qui le salue et identifie son besoin.
2. Validation du DSE : l’agent valide les informations du patient par rapport à son dossier dans le DSE.
3. Vérification : l’agent envoie un mot de passe à usage unique (OTP) au numéro de téléphone du patient pour une vérification finale à l’aide de son outil SMS.
4. Réservation ou modification : l’agent agit selon le besoin identifié dans le calendrier. Pour un nouveau rendez-vous, il recueille les informations nécessaires et vérifie les disponibilités ; pour une reprogrammation, il retrouve le rendez-vous existant et cherche un nouveau créneau ; pour une annulation, il confirme et supprime le rendez-vous existant.
5. Transfert : si la réservation ou la modification échoue, si le patient demande à parler à un humain, ou si l’agent identifie toute autre demande qu’il ne peut pas traiter, l’appel est transféré à un agent humain.
6. Confirmation et clôture : après une prise de rendez-vous, une reprogrammation ou une annulation réussie, l’agent récapitule les informations de l’appel et le clôture chaleureusement.

Prompt système et paramètres de l’agent

La première étape pour créer un ElevenAgent efficace réside dans son prompt système. En suivant le guide de prompting d’ElevenLabs, nous le structurons autour des composantes fondamentales recommandées pour tout agent en production — personnalité, objectif, ton, outils et garde-fous — chacune dans une section clairement identifiée plutôt que dans un bloc continu d’instructions.

Pour un agent de planification dans le secteur de la santé, cette structure doit tenir compte de la personne réellement au bout du fil : elle peut être âgée, souffrir, mal entendre ou simplement être anxieuse quant à la raison de son appel. Les sections sur la personnalité et le ton instaurent un rythme chaleureux et sans précipitation, avec des réponses courtes et conversationnelles. Les dates, heures et chiffres sont énoncés comme le ferait une personne, plutôt que lus sur un écran. La section sur l’objectif décrit le flux dans un ordre précis : vérifier l’identité, puis, selon que l’appelant souhaite prendre, reprogrammer ou annuler un rendez-vous, vérifier les disponibilités et confirmer le créneau, retrouver et déplacer le rendez-vous existant, ou confirmer le rendez-vous à supprimer. Les outils sont documentés avec les entrées exactes attendues au format oral. Les garde-fous appliquent les règles propres à ce domaine : ne jamais divulguer plus d’ISP que l’appelant n’en a déjà partagé, ne jamais inventer de disponibilités ni de détails de rendez-vous lorsqu’un outil échoue, refuser les questions cliniques au profit du professionnel de santé de l’appelant, et transférer immédiatement l’appel si une personne décrit des symptômes urgents ou une urgence médicale. La vérification de l’identité avant toute action sur un rendez-vous est la seule règle répétée plutôt qu’énoncée une seule fois. C’est celle que l’agent ne peut le moins se permettre d’omettre.

Vous pouvez ensuite ajouter d’autres configurations de l’agent, telles que le premier message, différentes langues (vérifiez que l’outil système detect language est activé), le LLM de votre choix, un modèle ElevenLabs conversationnel de synthèse vocale, ainsi qu’une voix ElevenLabs.

Vous trouverez un exemple de prompt système ici.

Garde-fous

La section Guardrails du prompt système couvre les règles au niveau des instructions, auxquelles le modèle accorde un poids important. Mais un prompt reste une couche non déterministe susceptible de dériver lors d’un appel long. ElevenAgents les renforce par une application indépendante à l’exécution grâce à ses propres Garde-fous. Ils incluent le Focus Guardrail, qui renforce le prompt système lorsque les conversations se prolongent, les Manipulation Guardrails, qui détectent les tentatives d’injection de prompt avant que l’agent ne réponde, ainsi que les Content et Custom Guardrails, qui évaluent chaque réponse en temps réel et peuvent la bloquer avant que l’appelant ne l’entende. Chaque garde-fou est configuré avec un mode d’exécution — streaming pour une latence quasi nulle, ou blocking pour retenir une réponse jusqu’à sa validation — et une stratégie de sortie lorsqu’il est déclenché : mettre fin à l’appel ou réessayer avec un retour correctif injecté au tour suivant.

Pour cet agent, vous pouvez définir des garde-fous personnalisés pour les règles propres aux établissements de santé ou à la clinique : bloquer les diagnostics et recommandations de traitement, les questions de facturation, les conseils de posologie des médicaments, ainsi que tout contenu qui se substituerait à l’avis d’un clinicien agréé. En cas de symptômes urgents, configurez la stratégie de sortie pour réessayer avec un retour qui transfère l’appel à un humain, afin que le garde-fou redirige l’appel vers le personnel plutôt que d’y mettre simplement fin.

Outils

Chaque étape du flux nécessite des outils de webhook et d’intégration spécifiques pour effectuer les actions requises tout en échangeant avec le patient.

Outil de vérification du DSE

Pour vérifier le patient par rapport à son dossier dans le DSE, nous utiliserons l’action API FHIR GET /Patient. Ajoutez-la comme outil de webhook pointant vers votre URL de base HAPI FHIR, avec family, given, identifier et birthdate définis comme paramètres renseignés par le LLM. Le premier appel d’outil de l’étape Verification interroge le point de terminaison avec le nom et la date de naissance de l’appelant dans une seule requête :

GET /baseR4/Patient?family={lastName}&given={firstName}&birthdate={YYYY-MM-DD}

Une correspondance n’est confirmée que lorsque la requête renvoie exactement un dossier. L’agent ne peut passer à l’étape Booking que si cette condition est remplie.

Vous trouverez un exemple JSON de l’outil ici.

Outils de vérification SMS Twilio

Une fois la correspondance avec le DSE confirmée, l’étape Verification passe à un second facteur : l’envoi d’un code à usage unique par SMS au patient, puis sa confirmation avant toute autre action. La configuration se fait en trois étapes :

1. Créez les outils de webhook SMS. Configurez deux outils, send_SMS_verification et check_SMS_verification, tous deux dirigés vers votre service Twilio Verify. Chacun requiert le SID du service Verify (la valeur VA... dans les paramètres de votre service Verify) dans le chemin de l’URL, ainsi qu’un en-tête d’authentification Basic créé à partir de votre Account SID et de votre Auth Token enregistrés comme secret.

2. Définissez le destinataire avec une variable système. ElevenAgents fournit des variables système qui renseignent automatiquement system__caller_id avec le numéro de téléphone de l’appelant lors de tout appel vocal. Transmettez donc {{system_caller_id}} comme paramètre To, plutôt que de demander à l’appelant de lire son numéro à voix haute. Dans un environnement de production intégré à un DSE réel, le code serait envoyé au numéro de téléphone enregistré dans le dossier du patient, plutôt qu’à l’identifiant de l’appelant.

3. Activez skip_turn. L’ajout de cet outil système aux côtés des outils de webhook permet à l’agent d’attendre silencieusement que l’appelant retrouve le SMS, au lieu de parler pendant ce silence.

Seul un appelant qui réussit à la fois la recherche dans le DSE et la vérification OTP peut accéder à l’étape Booking. 

Vous trouverez un exemple JSON des deux outils ici et ici.

Outils d’intégration du calendrier

L’étape Booking doit vérifier les disponibilités, réserver, reprogrammer et annuler dans un calendrier réel. La configuration de l’intégration Cal.com se fait en trois étapes :

1. Connectez l’intégration. Dans l’onglet Tools de l’agent, ajoutez l’intégration Cal.com et cliquez sur Connect.

2. Fixez le type d’événement. Chaque outil de calendrier accepte un ID de type d’événement qui indique à Cal.com sur quel événement effectuer la réservation. Définissez-le comme paramètre fixe dans les outils connectés à l’aide de l’ID de votre Dashboard Cal.com.

3. Définissez l’e-mail du participant. Les outils de réservation requièrent également l’e-mail d’un participant. À des fins de démonstration, définissez votre propre adresse comme paramètre fixe afin que les confirmations arrivent dans votre boîte de réception. En production avec un DSE réel, renseignez plutôt l’e-mail présent dans le dossier du patient qu’une valeur codée en dur.

Le flux Booking dépend alors de l’intention recueillie lors de Greeting. Pour un nouveau rendez-vous, l’agent appelle calcom_get_available_slots pour interroger les créneaux disponibles avant d’en proposer un, puis calcom_create_booking après confirmation de l’appelant — toujours dans cet ordre, car la vérification préalable des disponibilités évite de réserver deux fois le même créneau. Pour une reprogrammation ou une annulation, il commence par localiser le rendez-vous existant de l’appelant avec calcom_find_bookings_by_attendee, confirme la réservation précise avec l’appelant, puis la supprime avec calcom_cancel_booking ou, dans le cas d’une reprogrammation, réserve le nouveau créneau avant d’annuler l’ancien.

Transfert à un humain

Pour transférer l’appel à un humain, vous pouvez utiliser l’outil ElevenLabs transfer_to_number outil système. Ajoutez-le comme outil système au niveau de l’agent afin qu’il soit accessible depuis Greeting, Verification ou Booking. Pour la règle de transfert, ajoutez le numéro de téléphone de destination au format E.164 et une condition en langage naturel précisant quand elle doit se déclencher. Le LLM décide quand et vers où transférer l’appel selon ces conditions et la description de l’outil. Laissez le type de transfert sur Conference, la valeur par défaut, car il permet un message de passation qui informe l’opérateur humain du motif du transfert.

Structurer le parcours patient

Flux de travail désigne des flux de conversation visuels basés sur des graphes, construits à partir de quelques types de nœuds : des nœuds de sous-agents qui superposent un prompt système, des outils et une base de connaissances à l’agent de base orchestrateur pour une phase de l’appel ; des nœuds d’outil de répartition qui garantissent l’exécution d’un outil précis et créent des branches en cas de réussite ou d’échec ; des nœuds de transfert d’agent et de transfert vers un numéro pour les passations ; et un nœud de fin pour clôturer l’appel. Les nœuds sont reliés par des arêtes, et les arêtes sortantes peuvent comporter une condition LLM : une règle en langage naturel que le modèle évalue en temps réel afin de choisir le chemin à suivre. Nous construisons l’agent avec cinq nœuds de sous-agents — Greeting, Verification, Booking, Transfer Notice et Close — chacun limité à ses propres outils, ainsi qu’un unique nœud Phone Number Transfer accessible depuis Transfer Notice.

Accueil constitue le point d’entrée : il répond à l’appel, présente la clinique et recueille l’intention du patient avant de transmettre l’appel. Il ne possède aucun outil propre, seulement suffisamment de contexte pour orienter correctement l’appel.

Vérification assure le contrôle à deux facteurs décrit précédemment en utilisant l’outil FHIR GET /Patient pour confirmer que l’appelant correspond à un dossier dans le DSE, puis les outils send_SMS_verification et check_SMS_verification pour envoyer et vérifier un code à usage unique avant que l’appelant ne puisse poursuivre. Seul un appelant qui passe les deux contrôles progresse ; tous les autres suivent une arête sortante vers Transfer Notice.

Prise de rendez-vous regroupe les outils de calendrier de la section précédente, et l’intention recueillie lors de Greeting détermine le chemin : vérifier les disponibilités et réserver pour un nouveau rendez-vous, rechercher la réservation existante et effectuer une nouvelle réservation avant d’annuler pour une reprogrammation, ou confirmer et annuler pour une annulation. Ce nœud bascule également vers Transfer Notice : si aucun créneau ne convient dans le calendrier, si l’appelant ne peut pas être associé à un rendez-vous existant ou s’il préfère parler au personnel, l’arête l’y dirige au lieu de bloquer l’appel.

Annonce de transfert se situe entre le reste du workflow et la passation elle-même : il s’agit d’un bref sous-agent dont le seul rôle est d’indiquer à l’appelant qu’un transfert va avoir lieu (par exemple : « Je vous mets maintenant en relation avec un membre de notre équipe ») avant que l’appel ne quitte réellement l’agent. Faire passer chaque condition de transfert par ce nœud, plutôt que de déclencher transfer_to_number directement depuis Greeting, Verification ou Booking, garantit que l’appelant entend toujours ce message, au lieu d’être transféré silencieusement si le libellé varie selon le sous-agent.

Transfert vers un numéro de téléphone, fondé sur l’outil transfer_to_number, est le nœud vers lequel Transfer Notice redirige systématiquement. Ses règles associent un numéro de destination aux mêmes conditions transmises depuis l’amont — vérification échouée, demande explicite, réservation impossible à finaliser — et exécutent la passation une fois que l’appelant a été informé du transfert.

Clôture n’est atteint qu’après une réservation réussie : il récapitule les détails du rendez-vous à l’appelant et termine l’appel sur une note chaleureuse.

Vous trouverez un exemple de modèle JSON du workflow ici.

Analyse et tests

L’essentiel du travail sur un agent vocal dans le secteur de la santé ne concerne pas le parcours idéal, mais tout ce qui doit fonctionner correctement lorsque l’appel ne se déroule pas comme prévu. ElevenAgents intègre les fonctions de test et d’analyse nativement à la plateforme. Les mêmes critères d’évaluation utilisés pour les tests avant lancement servent ainsi à évaluer chaque appel en production, sans outil distinct à connecter ni résultats à rapprocher.

Critères de réussite

Définissez des critères de réussite pour couvrir des critères d’évaluation précis, alignés sur vos objectifs métier et opérationnels. Dans l’onglet Analysis, chaque critère est un prompt en langage naturel qu’un LLM exécute sur la transcription, et renvoie succès, échec ou inconnu avec une justification. Pour cet agent, ces critères peuvent notamment inclure :

• patient_verified: « Marquer comme réussi si l’agent a confirmé l’identité de l’appelant à la fois par la recherche dans le DSE et par le code à usage unique envoyé par SMS avant de procéder à la réservation. »
• appointment_booked: « Marquer comme réussi si le rendez-vous du patient a été réservé. »
• appointment_changed: « Marquer comme réussi si le patient a demandé à reprogrammer ou à annuler un rendez-vous existant, si l’agent a effectué cette modification — en mettant à jour ou en supprimant l’événement du calendrier — et en a confirmé le résultat à l’appelant. » 
• call_escalated_when_requested: « Marquer comme réussi si l’appelant a demandé à parler à un humain et si l’agent a transféré l’appel ; marquer comme échec si l’appelant l’a demandé mais que l’agent n’a pas transféré l’appel. »

Collecte de données

Vous pouvez les associer à des champs de collecte de données. Par exemple, ajoutez requested_action (réserver, reprogrammer ou annuler), appointment_date ou appointment_type, qui sont extraits de chaque transcription sous forme de valeurs structurées de type chaîne, booléen ou nombre, puis transmis en aval via un webhook post-appel au système qui suit les résultats des appels. 

Simulations et tests

Dans le secteur de la santé, un agent doit gagner la confiance avant son premier appel réel : les modes d’échec doivent apparaître lors des tests, et non face à un patient. L’API de simulation de conversation simule des scénarios d’appelants réalistes, de bout en bout comme sur des segments ciblés, et évalue automatiquement les résultats à l’aide des mêmes critères qu’en production — les vérifications précises patient_verified et appointment_booked définies ci-dessus, et non une grille réservée aux tests. Exécutez des simulations complètes pour l’ensemble de l’appel ou des simulations partielles qui démarrent au milieu de la conversation pour valider un seul point de décision. C’est le moyen le plus rapide d’itérer sur un nœud sans relancer tout le flux. 

Pour cet agent, cela consiste à écrire des scénarios qui dépassent le parcours idéal : un appelant dont le nom ne correspond à aucun dossier dans le DSE, une personne qui se trompe deux fois dans l’OTP, un patient qui demande une reprogrammation plutôt qu’une réservation et un appelant qui demande explicitement à parler à un humain au cours de la vérification. Ces scénarios clairs et ciblés couvrent les cas limites, l’utilisation des outils et la logique de repli, au lieu d’espérer qu’ils apparaissent en production.

Connectez votre numéro de téléphone Twilio

Une fois l’agent créé, le fait de le connecter à un numéro en direct ne prend que quelques minutes :

1. Dans le Dashboard ElevenLabs, accédez à Numéros de téléphone et cliquez sur Importer un numéro.
2. Saisissez un Libellé, le Numéro de téléphone, ainsi que vos identifiants Twilio SID du compte et Jeton d’authentification
3. Une fois le numéro importé, attribuez-le à votre agent depuis le menu déroulant.
4. Appelez le numéro pour le tester, puis consultez l’historique des conversations dans le Dashboard pour vérifier que les premiers appels se sont déroulés comme prévu.

Prêt pour de vrais patients

Vous avez créé un agent de planification des rendez-vous patients qui fait plus que répondre au téléphone : il vérifie l’identité avec un DSE et un OTP de second facteur avant d’accéder à un dossier, prend, reprogramme et annule directement des rendez-vous dans un calendrier en direct via l’API de Cal.com, et sait quand s’effacer pour transmettre l’appel à un humain. Le workflow déterministe, les garde-fous à l’exécution et les critères d’évaluation offrent aux équipes la piste d’audit et le modèle de tests reproductibles nécessaires aux déploiements dans le secteur de la santé.

Le passage en production est là où ce modèle démontre sa valeur. Les critères d’évaluation définis lors de la création deviennent le seuil de mise en production : lorsque l’agent les satisfait systématiquement et que les métriques se stabilisent, vous pouvez lancer avec confiance plutôt que vous en remettre à votre jugement. Après le lancement, l’apprentissage passe des tests simulés aux transcriptions de production. Nous abordons ces pratiques, des déploiements progressifs au moment où il faut cesser d’itérer, dans un précédent article de blog.

Une étape clé vers la conformité HIPAA concerne le traitement des données. L’activation de Mode de rétention zéro supprime les enregistrements d’appels, les transcriptions et les métadonnées contenant des informations personnelles identifiables dès la fin de l’appel, éliminant ainsi la principale source de risque de conformité dans un déploiement téléphonique. Associé à un webhook post-appel, vous conservez toute la visibilité : chaque résultat de réservation, de vérification et d’évaluation est envoyé à votre propre système en temps réel à la fin de l’appel.

Vous disposez désormais d’un modèle pour placer une IA vocale agentique à l’entrée de votre clinique. La planification est le point de départ au plus fort volume, et ce même modèle s’étend à l’accueil des patients, aux renouvellements d’ordonnance, à la facturation et aux suivis après consultation : autant d’appels qui ne doivent plus tomber sur la messagerie en dehors des horaires d’ouverture. Notre équipe Forward Deployed Engineering travaille étroitement avec les organisations de santé pour transformer des déploiements comme celui-ci en fonctionnalités produit concrètes. Si vous souhaitez déployer un workflow destiné aux patients sur ElevenAgents avec le niveau de conformité exigé par le secteur de la santé, testez cette approche et partagez-nous votre avis.