Créer un agent IA de prise de rendez-vous avec Botpress et Google Calendar
Tutoriel complet pour créer un agent IA de réservation avec Botpress et Google Calendar : disponibilité, anti double booking, création, modification, annulation, rappels et sécurité.
Créer un agent IA de prise de rendez-vous avec Botpress et Google Calendar
La prise de rendez-vous est un cas d'usage très complet pour apprendre à construire un agent IA.
L'agent doit comprendre une demande en langage naturel, consulter un calendrier, éviter les conflits, créer un événement, modifier ou annuler un rendez-vous et envoyer des relances.
Dans cette vidéo, je construis tout le système avec Botpress et Google Calendar.
La vidéo complète
Le tutoriel détaillé est disponible ici :
Ce que l'agent doit savoir faire
L'objectif est de gérer le cycle complet d'un rendez-vous.
L'agent doit pouvoir :
- vérifier les disponibilités ;
- créer un rendez-vous ;
- retrouver un rendez-vous existant ;
- modifier la date ou l'heure ;
- annuler un rendez-vous ;
- envoyer un rappel automatique.
Pour obtenir un système fiable, il faut aussi gérer les conflits de créneaux et l'identification de l'utilisateur.
Connecter Google Calendar à Botpress
La première étape consiste à connecter Google Calendar à Botpress.
Une fois l'intégration installée et le compte connecté, il faut sélectionner le calendrier utilisé par l'agent.
L'intégration expose ensuite les actions nécessaires au workflow.
Le calendrier devient une source de vérité pour les disponibilités.
Définir les informations nécessaires
Avant de créer un rendez-vous, l'agent doit récupérer les données indispensables.
Selon le cas d'usage, cela peut inclure :
- nom ;
- email ;
- date ;
- heure ;
- type de rendez-vous ;
- durée ;
- commentaire éventuel.
Je préfère collecter uniquement les données réellement utiles.
Cela réduit la longueur de la conversation.
Donner les règles du service
L'agent doit connaître les contraintes du planning.
Par exemple :
- horaires d'ouverture ;
- durée de chaque type de rendez-vous ;
- jours fermés ;
- délai minimum avant réservation ;
- adresse ;
- règles de modification ;
- règles d'annulation.
Ces informations doivent être suffisamment claires pour que l'agent ne propose pas des créneaux impossibles.
Vérifier la disponibilité avant de réserver
C'est l'une des parties les plus importantes du tutoriel.
Un agent ne doit pas créer directement un événement dès que l'utilisateur demande une heure.
Il doit d'abord vérifier que le créneau est disponible.
Le workflow peut donc suivre cette logique :
- récupérer la date et l'heure demandées ;
- consulter Google Calendar ;
- vérifier les événements présents sur cette période ;
- déterminer si le créneau est libre ;
- seulement ensuite créer le rendez-vous.
Cette vérification évite le double booking.
Pourquoi le contrôle doit être robuste
Une simple phrase dans le prompt peut ne pas suffire pour une règle critique.
Si le rendez-vous ne doit jamais être créé sur un créneau occupé, cette règle mérite d'être renforcée dans la logique du workflow.
Le système doit empêcher l'action lorsque le contrôle de disponibilité échoue.
C'est particulièrement important lorsque l'agent fonctionne de manière autonome.
Gérer les dates en langage naturel
Les utilisateurs ne donnent pas toujours une date complète.
Ils écrivent souvent :
demain à 10 h
ou :
mercredi prochain dans l'après-midi
L'agent doit convertir ces formulations en date et heure exploitables.
Il faut donc lui donner la date actuelle et tenir compte du fuseau horaire.
Cette étape évite les erreurs sur les expressions relatives.
Respecter les horaires d'ouverture
La disponibilité du calendrier ne suffit pas.
Un créneau peut être vide à 6 h du matin alors que le service ouvre à 9 h.
Les horaires doivent donc être contrôlés séparément.
Si la demande sort des horaires, l'agent peut proposer une alternative.
Créer le rendez-vous
Une fois le créneau validé, l'agent peut créer l'événement Google Calendar.
L'événement doit contenir les informations utiles pour l'équipe.
Par exemple :
- nom du client ;
- email ;
- type de rendez-vous ;
- date ;
- heure ;
- éventuelle note.
L'agent confirme ensuite la réservation au client.
Toujours confirmer les actions importantes
Avant une action sensible, je demande une confirmation.
Pour une création, l'agent peut récapituler :
Rendez-vous mardi 14 avril à 10 h pour une consultation. Je confirme ?
Cette validation réduit les erreurs de compréhension.
Elle devient encore plus importante pour une modification ou une annulation.
Retrouver un rendez-vous existant
Pour modifier ou annuler un rendez-vous, l'agent doit d'abord retrouver le bon événement.
Une recherche peut être faite à partir de l'email ou d'autres informations.
Une fois le rendez-vous identifié, son identifiant peut être stocké dans une variable.
Cela évite de refaire la recherche à chaque étape.
Modifier un rendez-vous
Le processus de modification peut suivre plusieurs étapes :
- retrouver le rendez-vous ;
- demander la nouvelle date ;
- vérifier la disponibilité du nouveau créneau ;
- demander confirmation ;
- mettre à jour l'événement ;
- confirmer la modification.
Le contrôle de disponibilité doit être refait avant la modification.
Déplacer un rendez-vous vers un créneau déjà occupé créerait le même problème qu'une réservation initiale mal contrôlée.
Annuler un rendez-vous
L'annulation suit une logique similaire.
L'agent retrouve l'événement puis affiche les informations au client.
Il demande ensuite une confirmation explicite.
Après validation, il supprime ou annule l'événement selon le fonctionnement choisi.
L'utilisateur reçoit enfin un message de confirmation.
Envoyer des relances automatiques
La vidéo ne s'arrête pas à la réservation.
On ajoute aussi un workflow de rappel.
Le principe est de lancer régulièrement une vérification des rendez-vous à venir.
Le workflow récupère par exemple les rendez-vous du lendemain puis envoie un email aux participants.
Le rappel peut contenir :
- date ;
- heure ;
- adresse ;
- type de rendez-vous ;
- consignes particulières.
Cette logique peut réduire les oublis et les rendez-vous manqués.
Construire un workflow planifié
Le rappel ne dépend pas d'un message de l'utilisateur.
Il doit donc être lancé automatiquement.
Un workflow planifié peut s'exécuter chaque jour.
Il consulte les événements de la période ciblée, récupère les informations nécessaires puis déclenche l'envoi.
Cette logique peut être adaptée pour un rappel 24 heures avant ou plusieurs heures avant le rendez-vous.
Sécuriser l'identification des utilisateurs
Pour une démonstration, retrouver un rendez-vous avec un nom ou un email peut suffire.
Pour un système en production, il faut être plus strict.
Un utilisateur ne doit pas pouvoir modifier le rendez-vous d'une autre personne simplement en connaissant son adresse email.
Une solution consiste à associer l'utilisateur de la conversation à l'identifiant du rendez-vous dans une table.
L'agent vérifie alors cette correspondance avant toute modification ou annulation.
Stocker les identifiants utiles
Lorsqu'un rendez-vous est créé, on peut enregistrer :
- identifiant utilisateur ;
- identifiant de l'événement Google Calendar ;
- email ;
- statut ;
- date de création.
Cette table facilite ensuite les opérations futures.
L'agent sait exactement quel événement appartient à quel utilisateur.
Cas limites à tester
Un agent de réservation doit être testé sur des situations qui sortent du parcours idéal.
Je recommande au minimum :
- créneau déjà réservé ;
- date dans le passé ;
- demande hors horaires ;
- utilisateur sans email ;
- plusieurs rendez-vous pour la même personne ;
- rendez-vous introuvable ;
- changement de date plusieurs fois ;
- annulation ambiguë ;
- API indisponible ;
- fuseau horaire incorrect.
Ces cas permettent de voir si l'agent sait récupérer proprement ou s'il prend une décision incorrecte.
Pourquoi ce projet est intéressant pour apprendre les agents IA
Ce cas combine plusieurs éléments importants :
- conversation naturelle ;
- extraction de données ;
- appel d'outil ;
- logique déterministe ;
- contrôle avant action ;
- intégration externe ;
- stockage ;
- automatisation planifiée.
C'est exactement le type de projet qui montre la différence entre un chatbot qui répond à des questions et un agent qui agit.
Pour comprendre comment connecter d'autres services, vous pouvez lire mon article sur les APIs dans Botpress.
Si vous voulez construire un agent de réservation adapté à votre métier, vous pouvez me contacter.
Vous voulez appliquer ces idées ?
Réservez un diagnostic pour identifier les premiers cas d'usage utiles dans votre activité.