Automatisation Google Agenda : empêcher les réservations en double

Deux clients peuvent demander le même créneau au même instant, et une automatisation Google Agenda qui ne gère pas cette concurrence finira par créer deux rendez-vous pour un seul créneau. Le problème ne vient pas de l'API en elle-même, mais de l'ordre dans lequel votre système lit les disponibilités, écrit les événements et confirme au client. Cet article détaille une conception applicative qui réduit ce risque : lecture fraîche, réservation temporaire avec expiration, identifiants stables et confirmation uniquement après preuve d'écriture.

Pourquoi les doubles réservations surviennent

Le scénario type est simple. Un client A consulte vos disponibilités, réfléchit quelques minutes, puis confirme. Pendant ce temps, un client B interroge le même agenda, voit le créneau encore libre et réserve. Si votre automatisation se contente de lire l'agenda une fois puis d'insérer un événement, elle valide les deux demandes avec la même information périmée.

Ce problème existe aussi bien avec un formulaire classique qu'avec un agent IA de prise de rendez-vous qui discute avec le client avant de réserver. La conversation ajoute même du délai : plus le dialogue dure, plus la disponibilité lue au début risque d'être fausse à la fin. La concurrence n'est pas un cas rare dans une PME avec plusieurs canaux d'entrée, elle est structurelle dès que deux personnes peuvent accéder au même créneau.

Il faut donc distinguer trois moments : la lecture de la disponibilité, l'écriture de l'événement et la confirmation envoyée au client. Une double réservation naît toujours d'une décision prise entre le premier et le troisième moment, sur une donnée qui a changé entre-temps.

Ce que l'API Google Agenda garantit et ne garantit pas

L'API Calendar permet de créer des événements avec un identifiant explicite que vous choisissez. C'est utile : si votre système génère un identifiant déterministe pour une demande donnée, une reprise après erreur ne créera pas deux événements distincts pour la même intention. Vous pouvez consulter la documentation officielle de création d'événements pour ce mécanisme.

En revanche, l'API ne fournit pas de transaction globale entre votre système et l'agenda. Il n'existe pas d'opération qui dirait « réserve ce créneau seulement s'il est encore libre, de manière atomique avec ta propre base ». Une lecture de disponibilité suivie d'une écriture reste deux opérations séparées, avec un intervalle pendant lequel un autre client peut agir. Prétendre que l'API seule verrouille automatiquement le créneau serait faux : c'est votre architecture applicative qui doit combler cet écart.

Cette limite n'est pas spécifique à Google. Elle vient de la nature distribuée des systèmes : votre base de données et l'agenda de Google sont deux systèmes distincts, sans mémoire partagée. Toute conception de réservation doit donc assumer cet intervalle et le rendre inoffensif, plutôt que d'espérer qu'il n'existe pas.

La dernière lecture de disponibilité juste avant l'écriture

La première mesure consiste à ne jamais décider sur une disponibilité lue au début de la conversation. Relisez les créneaux à chaque étape de décision, et surtout immédiatement avant l'écriture. Un créneau proposé au client doit être revalidé au moment où il dit oui.

Concrètement, si un client entame une demande à 14h05 et confirme à 14h09, votre système doit relire l'agenda à 14h09, pas réutiliser l'état de 14h05. Si le créneau a été pris entre-temps, vous le détectez avant d'écrire, et vous proposez une alternative plutôt qu'une réservation en conflit.

Cette relecture ne supprime pas tout risque : il reste un intervalle, même court, entre la relecture et l'écriture. Elle réduit cependant fortement la fenêtre d'exposition, surtout si elle est combinée aux réservations temporaires décrites plus bas. Si vous travaillez avec des clients dans des zones différentes, la relecture doit aussi vérifier la cohérence des fuseaux horaires, un point que nous détaillons dans notre guide sur l'assistant Google Agenda et les erreurs de fuseau horaire.

Les réservations temporaires applicatives

Une réservation temporaire est un état intermédiaire dans votre propre système : le créneau est marqué « en cours de réservation » pour un client donné, pendant une durée limitée. Pendant cette période, l'automatisation refuse de proposer ce créneau à d'autres clients, même s'il apparaît encore libre dans l'agenda.

Le fonctionnement est le suivant :

1. Le client choisit un créneau. Votre système crée une réservation temporaire, par exemple pour dix minutes, avec un identifiant unique.
2. Tant que la réservation temporaire est active, ce créneau est exclu des disponibilités proposées aux autres clients.
3. Si le client confirme dans le délai, vous écrivez l'événement dans Google Agenda et transformez la réservation temporaire en réservation ferme.
4. Si le délai expire sans confirmation, la réservation temporaire est libérée et le créneau redevient disponible.

Le choix de la durée dépend de votre parcours client. Une conversation avec un agent peut nécessiter quelques minutes pour poser des questions de qualification ; une réservation temporaire de cinq à quinze minutes est un ordre de grandeur habituel, à ajuster selon vos cas. Trop courte, elle frustre les clients hésitants ; trop longue, elle bloque des créneaux pour des demandes qui n'aboutiront jamais.

Attention à un point : la réservation temporaire vit dans votre système, pas dans l'agenda. Tant que vous n'avez pas écrit l'événement, Google Agenda ne sait rien de cette intention. C'est précisément pourquoi elle doit avoir une expiration automatique, sinon un crash de votre système laisserait des créneaux bloqués indéfiniment.

Expiration et libération automatique des créneaux

L'expiration est le mécanisme qui rend la réservation temporaire sûre. Chaque réservation temporaire porte une date d'expiration ; un processus périodique, ou une vérification à chaque lecture de disponibilité, libère les réservations dépassées.

Deux erreurs classiques méritent d'être évitées. La première : libérer la réservation temporaire uniquement à la fin de la conversation client. Si le client ferme son navigateur, la conversation ne se termine jamais formellement, et le créneau reste bloqué. L'expiration doit être indépendante du comportement du client. La seconde : ne pas gérer le cas où l'expiration survient pendant que le client confirme. Si le client clique sur « confirmer » à la seconde où la réservation temporaire expire, votre système doit revalider la disponibilité avant d'écrire, et non considérer que la réservation temporaire suffit.

Une approche robuste consiste à rendre l'écriture conditionnelle : au moment de la confirmation, le système vérifie que la réservation temporaire est encore valide et que l'agenda montre toujours le créneau libre. Si l'une des deux conditions échoue, on repart sur une proposition d'alternative. Ce contrôle double coûte une lecture supplémentaire, mais il couvre le cas de la concurrence la plus gênante pour le client.

Identifiants stables et reprises après erreur

Les erreurs réseau et les reprises font partie du quotidien d'une automatisation. Si votre système envoie une demande de création d'événement et que la réponse se perd, il ne sait pas si l'événement a été créé. Réessayer aveuglément risque de créer un doublon.

C'est là que l'identifiant d'événement explicite devient décisif. En générant vous-même un identifiant déterministe pour chaque intention de réservation, une reprise avec le même identifiant ne crée pas un second événement : l'API reconnaît l'identifiant déjà utilisé. Nous traitons ce mécanisme en détail dans notre article sur l'automatisation des workflows, les reprises et les doublons, qui s'applique directement à la réservation de rendez-vous.

La règle pratique est simple : un identifiant par intention métier, pas par tentative technique. Si le client déplace un rendez-vous existant, traitez ce déplacement comme une nouvelle opération métier avec sa propre clé de déduplication, tout en conservant l’identifiant de l’événement à modifier. Un déplacement ne justifie pas, à lui seul, la création d’un second rendez-vous. Notre guide sur le déplacement et l'annulation correcte des rendez-vous par un assistant détaille cette distinction entre créer, mettre à jour et annuler.

Confirmation du client seulement après preuve d'écriture

L'erreur la plus dommageable en termes d'image est d'annoncer au client que son rendez-vous est confirmé alors que l'écriture dans l'agenda a échoué. La confirmation doit donc être conditionnée à une preuve : la réponse de l'API qui confirme la création de l'événement, avec son identifiant.

Le flux correct est le suivant : relecture de disponibilité, écriture de l'événement, vérification de la réponse, puis seulement envoi de la confirmation au client. Si l'écriture échoue, le client reçoit un message d'alternative ou de report, jamais une confirmation fictive. Cette règle s'applique aussi aux notifications internes : votre équipe ne doit pas bloquer un créneau sur la foi d'une intention non écrite.

Cette exigence de preuve rejoint un principe plus général : la connexion de transport, l'autorisation du fournisseur et la preuve d'opération sont trois choses différentes. Une requête partie avec succès n'est pas une opération réussie ; seule la réponse du service en atteste. Concevez vos messages clients autour de cette distinction, et non autour de l'optimisme du moment d'envoi.

Tableau décisionnel : que faire selon la situation

Situation	Risque	Conduite à tenir
Créneau demandé, disponibilité lue il y a plusieurs minutes	Donnée périmée	Relire l'agenda avant toute décision
Deux clients sur le même créneau simultanément	Double réservation	Réservation temporaire exclusive pour le premier
Client hésite au-delà du délai temporaire	Créneau bloqué trop longtemps	Expiration automatique et libération
Réponse API perdue après création d'événement	Doublon à la reprise	Identifiant d'événement explicite et déterministe
Confirmation envoyée avant vérification de la réponse	Rendez-vous annoncé inexistant	Confirmation uniquement après preuve d'écriture
Expiration pendant la confirmation du client	État incohérent	Revalider disponibilité et réservation temporaire avant écriture
Révocation d'accès en cours de processus	Écriture impossible	Détecter l'échec, informer, ne pas confirmer

Exemple principal commenté : un mardi matin chargé

Prenons un cas hypothétique, explicitement fictif. Un cabinet propose des consultations de 30 minutes. Mardi, à 9h02, le client A demande le créneau de 14h00 via votre agent conversationnel. L'agent relit l'agenda, voit 14h00 libre, et crée une réservation temporaire de dix minutes, identifiant « b47c2a6f19d84a92a3d18a5e62f70311 », expirant à 9h12.

À 9h05, le client B interroge les disponibilités. Votre système exclut 14h00 de la liste, car la réservation temporaire de A est active. B choisit 14h30, avec sa propre réservation temporaire. À 9h10, A confirme. Le système vérifie : réservation temporaire valide, agenda montre toujours 14h00 libre. Il écrit l'événement avec l'identifiant explicite « b47c2a6f19d84a92a3d18a5e62f70311 », reçoit la confirmation de l'API, puis envoie le message de confirmation à A.

À 9h13, B hésite encore. Sa réservation temporaire expire à 9h15. À 9h16, il confirme 14h30. Le système revalide : créneau toujours libre, réservation temporaire expirée depuis une minute mais le créneau n'a pas été proposé à personne d'autre entre-temps. Il réactive une réservation temporaire courte, écrit l'événement, confirme. Supposons maintenant un troisième client, C, qui à 9h17 demande 14h00 : la relecture montre l'événement de A, et l’agent vérifie les disponibilités restantes et propose 15h00 ou un autre jour, sans écrire en conflit.

Le point clé de cet exemple : à aucun moment une décision n'a été prise sur une donnée ancienne, et aucune confirmation n'a été envoyée sans preuve d'écriture. La réservation temporaire a servi de verrou applicatif là où l'agenda n'en fournit pas.

Procédure exploitable pour sécuriser vos réservations

Voici une procédure en sept étapes à transposer dans votre propre outil de réservation :

1. Numéroter les intentions. Chaque demande de réservation reçoit un identifiant métier unique et déterministe, réutilisé en cas de reprise technique.
2. Relire avant de proposer. Les disponibilités affichées au client sont calculées à partir d'une lecture fraîche de l'agenda, jamais d'un cache ancien.
3. Poser une réservation temporaire. Dès qu'un client choisit un créneau, votre système le marque comme réservé provisoirement, avec une expiration fixée.
4. Exclure les créneaux temporairement réservés. Les autres clients ne voient pas ces créneaux, même s'ils sont encore libres dans l'agenda.
5. Revalider à la confirmation. Au moment du oui du client, vérifier la validité de la réservation temporaire et la disponibilité réelle avant d'écrire.
6. Écrire avec preuve. Créer l'événement avec l'identifiant explicite, vérifier la réponse de l'API, puis seulement confirmer au client et à l'équipe.
7. Libérer à l'expiration. Un mécanisme indépendant du client libère les réservations temporaires arrivées à échéance, et un journal trace chaque transition.

Chaque étape existe pour une raison précise : les étapes 2 et 5 réduisent la fenêtre de concurrence, l'étape 3 l'empêche entre clients de votre système, l'étape 6 empêche les confirmations fictives, et l'étape 7 évite le blocage durable des créneaux.

Tester les cas limites : timeout, conflit, resynchronisation, révocation

Une conception de réservation ne vaut que par ses tests. Quatre familles de tests méritent d'être menées avant toute mise en production.

Test de timeout. Simulez une perte de réponse lors de la création d'un événement. Vérifiez que la reprise avec le même identifiant ne crée pas de doublon et que le client ne reçoit qu'une seule confirmation.

Test de conflit. Simulez deux clients confirmant le même créneau à quelques secondes d'écart. Un seul doit obtenir l'écriture ; l'autre doit recevoir une alternative, sans jamais voir une confirmation fictive.

Test de resynchronisation. Si quelqu'un modifie l'agenda manuellement pendant qu'une réservation temporaire est active, votre système doit le détecter à la revalidation. Les mécanismes de synchronisation décrits dans la documentation de synchronisation de Calendar permettent de suivre les changements de l'agenda ; l'important est que la revalidation à la confirmation s'appuie sur un état récent, pas sur un état supposé.

Test de révocation. Révoquez les accès pendant un processus de réservation en cours. Le système doit détecter l'échec d'écriture, ne pas confirmer au client, et proposer une reprise propre une fois l'accès rétabli. Une révocation silencieuse qui se traduit par des confirmations fictives est le pire des scénarios.

Ces tests se prêtent bien à une démarche outillée : notre article sur le test d'un agent conversationnel IA propose une méthode de construction de scénarios reproductibles, applicable à ces quatre familles.

Questions fréquentes

L'API Google Agenda peut-elle empêcher seule les doubles réservations ?

Non. L'API permet de créer des événements, avec des identifiants explicites utiles pour les reprises, mais elle n'offre pas de transaction globale avec votre système. La prévention des doubles réservations repose sur votre architecture : relecture de disponibilité, réservations temporaires et confirmation après preuve d'écriture.

Quelle durée choisir pour une réservation temporaire ?

Cela dépend du parcours client. Une conversation avec qualification peut justifier dix minutes, un paiement en ligne plutôt cinq. Le critère est le délai réaliste entre le choix du créneau et la confirmation, avec une marge. Trop longue, la durée bloque des créneaux pour des demandes abandonnées ; trop courte, elle force des revalidations et des alternatives.

Que se passe-t-il si un client confirme exactement à l'expiration de sa réservation temporaire ?

Votre système doit revalider les deux conditions avant d'écrire : la disponibilité réelle du créneau dans l'agenda et l'état de la réservation temporaire. Si le créneau est toujours libre, la réservation peut aboutir, éventuellement après recréation d'une réservation temporaire courte. Sinon, le client reçoit une alternative, jamais une confirmation non prouvée.

Pourquoi générer soi-même l'identifiant de l'événement plutôt que laisser l'agenda le choisir ?

Parce qu'un identifiant déterministe lié à l'intention métier rend les reprises sûres. Si une réponse se perd et que vous réessayez, le même identifiant désigne la même intention et ne produit pas de second événement. Avec un identifiant généré côté agenda, chaque tentative crée un événement distinct et le doublon devient inévitable.

Faut-il bloquer toute écriture manuelle dans l'agenda pour que le système fonctionne ?

Non, mais il faut l'assumer. Si votre équipe ajoute des rendez-vous manuellement, la relecture de disponibilité et la resynchronisation doivent en tenir compte. La conception présentée ici tolère les écritures manuelles précisément parce qu'elle ne fait jamais confiance à un état supposé de l'agenda : elle relit, réserve temporairement, puis confirme sur preuve.