Détecter et résoudre les conflits de réservation (double-booking) avec n8n

Un client réserve une visite via Cal.com. Le même jour, un commercial bloque le même créneau à la main dans Google Calendar pour un autre rendez-vous, sans remarquer que la case est déjà prise ailleurs. Les deux événements coexistent tranquillement sur le calendrier partagé jusqu'à ce que quelqu'un s'en aperçoive — souvent le jour même, devant les deux personnes qui se présentent au même endroit à la même heure. Ce n'est pas un bug de Google Calendar : c'est la conséquence mécanique d'avoir plusieurs points d'entrée (outil de prise de rendez-vous, saisie manuelle, synchronisation CRM) qui écrivent chacun sur le même calendrier sans se consulter. n8n peut combler exactement ce trou, en surveillant les calendriers concernés et en signalant — ou en résolvant — les chevauchements avant qu'ils ne deviennent un problème visible du client.

Pourquoi les conflits apparaissent malgré des outils modernes

Un outil de prise de rendez-vous comme Cal.com ou Calendly vérifie bien la disponibilité — mais seulement dans son propre référentiel, au moment de la réservation. Une étude fondatrice sur les systèmes de calendrier partagés, Palen (1999), Social, Individual and Technological Issues for Groupware Calendar Systems, publiée à CHI, montre déjà que la difficulté centrale des calendriers partagés n'est pas technique mais organisationnelle : plusieurs personnes et plusieurs outils modifient la même ressource temporelle sans visibilité complète les uns sur les autres, ce qui crée mécaniquement des doubles réservations dès que le nombre de points d'entrée augmente. Vingt-cinq ans plus tard, le problème est identique — seuls les outils ont changé : Cal.com, un CRM et une saisie manuelle jouent aujourd'hui le rôle que jouaient les calendriers papier et les secrétariats distincts à l'époque de l'étude.

Le coût de ce genre de conflit n'est pas seulement l'embarras du double rendez-vous. Czerwinski, Horvitz et Wilhite (2004), A Diary Study of Task Switching and Interruptions, publiée à CHI, documente à quel point la réorganisation improvisée d'un planning en urgence — reprogrammer, prévenir, réattribuer une ressource — fragmente le reste de la journée de travail bien au-delà du temps strictement nécessaire pour résoudre le conflit lui-même. Détecter le chevauchement avant qu'il n'atterrisse devant un client évite justement cette cascade.

Ce que Google Calendar ne fait pas tout seul

Le node Google Calendar de n8n (voir notre guide complet du node Google Calendar) exécute fidèlement ce qu'on lui demande — créer, lister, modifier un événement — mais ne compare jamais deux événements entre eux de sa propre initiative. Trois angles morts reviennent systématiquement :

• Le décalage entre outils. Un rendez-vous pris sur Cal.com ou Calendly (voir nos guides Cal.com et Calendly) écrit un événement sur Google Calendar via synchronisation ou webhook — mais une saisie manuelle faite en parallèle, avant que cette synchronisation ne se propage, échappe complètement à la vérification de disponibilité de l'outil de réservation.
• Les ressources partagées entre plusieurs calendriers. Une salle de réunion réservée depuis le calendrier d'une personne et depuis le calendrier ressource de la salle elle-même peut se retrouver double-bookée si personne ne croise les deux agendas.
• Le statut « disponible » mal renseigné. Un événement créé avec le champ transparency sur transparent (« disponible ») plutôt que opaque (« occupé ») — un import de calendrier externe ou un événement « pour information » — n'apparaît pas comme un obstacle lors d'une vérification de créneau libre, alors qu'il représente bien un engagement réel pour la personne concernée.

Construire le détecteur de conflits dans n8n

Le principe : interroger régulièrement les calendriers concernés sur une fenêtre glissante, comparer chaque paire d'événements qui partagent une ressource ou une personne, et déclencher une alerte dès qu'un chevauchement est détecté.

1. Déclenchement

Deux triggers complémentaires, pas exclusifs l'un de l'autre :

• Un Schedule Trigger toutes les 10 à 15 minutes, qui relit l'ensemble des calendriers concernés sur les 7 à 14 prochains jours — le filet de sécurité qui attrape tout, y compris les conflits créés par une source qui ne déclenche aucun événement (import CSV, saisie tardive).
• Un Google Calendar Trigger sur Event Created et Event Updated, pour vérifier immédiatement le nouvel événement dès sa création plutôt que d'attendre le prochain passage du sondage — utile quand un rendez-vous est confirmé au client en direct et qu'on veut savoir tout de suite s'il chevauche quelque chose.

2. Récupérer les événements à comparer

Un node Google Calendar en opération Get Many, une itération par calendrier concerné (agenda de chaque commercial, calendrier ressource de chaque salle), filtré sur la même fenêtre temporelle. Si plusieurs calendriers doivent être parcourus, un node Loop Over Items exécute la récupération pour chacun, puis un node Merge rassemble le tout en une seule liste avant comparaison.

3. Détecter les chevauchements

C'est le cœur du workflow, dans un node Code. Pour chaque paire d'événements qui partagent une ressource (même salle, même personne, même identifiant client), on compare les intervalles [début, fin] :

const { DateTime } = require('luxon');

function seChevauchent(a, b) {
  const debutA = DateTime.fromISO(a.start).toUTC();
  const finA = DateTime.fromISO(a.end).toUTC();
  const debutB = DateTime.fromISO(b.start).toUTC();
  const finB = DateTime.fromISO(b.end).toUTC();
  return debutA < finB && debutB < finA;
}

Notre guide Luxon pour les dates et heures dans n8n détaille cette manipulation des fuseaux horaires — un point d'attention réel : comparer des horodatages sans les ramener préalablement en UTC est la source la plus fréquente de faux positifs (deux événements dans des fuseaux différents signalés à tort) ou de faux négatifs autour des changements d'heure. Ne comparez que les événements dont transparency vaut opaque (occupé) : un événement marqué « disponible » ne doit pas déclencher d'alerte.

4. Router selon la gravité

Un node IF sépare les cas :

• Chevauchement total ou partiel sur une ressource unique (même salle, même intervenant) → alerte immédiate, c'est un vrai conflit.
• Chevauchement sur un créneau tampon (buffer de 5-10 minutes entre deux rendez-vous plutôt qu'un vrai recouvrement) → simple avertissement, souvent tolérable selon l'activité.

5. Résoudre plutôt que seulement signaler

Une alerte Slack qui liste les deux événements en conflit est le strict minimum, mais deux options vont plus loin :

• Proposer une reprogrammation. Un AI Agent interroge les créneaux libres du calendrier concerné sur les jours suivants et propose deux ou trois alternatives directement dans le message d'alerte, plutôt que de laisser la personne rouvrir Google Calendar pour chercher elle-même.
• Ne jamais reprogrammer automatiquement sans validation humaine. Déplacer un rendez-vous client sans confirmation est le genre d'action à fort impact qui mérite une étape d'approbation — exactement le schéma décrit dans notre guide sur l'approbation humaine avec Wait + Slack : le workflow propose, une personne valide en un clic, et c'est seulement à ce moment que le node Google Calendar exécute l'opération Update.

Cas d'usage concrets

• Visites immobilières. Une agence qui planifie des visites (voir notre guide sur le compte-rendu de visite immobilière assisté par IA) croise facilement l'agenda d'un même agent réservé à la fois par le site web et par un appel téléphonique saisi à la main : un contrôle avant confirmation évite d'envoyer deux clients au même bien à la même heure.
• Salles de réunion partagées. Une PME qui gère plusieurs salles via des calendriers ressource Google Workspace peut appliquer le même détecteur en croisant le calendrier de chaque salle avec celui des participants invités.
• Prestataires multi-canaux. Un consultant qui accepte des rendez-vous via Calendly, par email et par téléphone bénéficie du contrôle après coup — la vérification en amont de chaque outil de prise de rendez-vous individuel ne suffit jamais à couvrir les canaux qu'il ne voit pas.

Pièges fréquents

• Comparer des chaînes de date brutes plutôt que des objets temporels normalisés en UTC — deux événements identiques en heure locale mais dans des fuseaux différents ne sont pas nécessairement en conflit, et l'inverse est vrai aussi.
• Ignorer le champ transparency et alerter sur des événements « pour information » qui ne bloquent en réalité aucune ressource.
• Ne surveiller qu'un seul calendrier alors que le conflit se joue entre deux calendriers distincts (agenda personnel et calendrier ressource d'une salle, par exemple) — la comparaison doit porter sur toutes les ressources réellement partagées.
• Reprogrammer sans prévenir personne : un déplacement automatique de rendez-vous sans validation humaine ni notification au client est le genre de correctif qui crée un second problème pire que le premier.

Pour aller plus loin

L'infrastructure d'alerte utilisée ici — détection, notification Slack, journalisation de l'incident — est la même logique que celle du workflow de digest quotidien du Pack Inbox IA (79 €), qui centralise déjà les priorités et les urgences d'une boîte mail dans un canal Slack ou Telegram. Si votre pile Slack de notifications existe déjà pour vos emails, brancher ce détecteur de conflits de calendrier dessus ne demande qu'un webhook supplémentaire — pas une nouvelle intégration à construire de zéro.