Ce que coûte vraiment une négociation de créneau
Le calcul naïf est celui des messages : six échanges à deux minutes, douze minutes. C’est déjà du temps, et ce n’est pas le principal.
Le vrai coût est le délai. Chaque aller-retour ajoute une demi-journée, parce que les deux parties ne sont pas disponibles au même moment. Un rendez-vous qui aurait pu être fixé le jour même l’est quatre jours plus tard — et dans l’intervalle, sur une demande commerciale, l’intention refroidit et un concurrent peut passer.
Le deuxième coût est le rendez-vous manqué. Un créneau perdu, c’est le temps du créneau, plus le trajet éventuel, plus la réorganisation. Un simple rappel la veille en supprime une bonne partie, et personne ne l’envoie à la main de façon fiable.
Le troisième, propre aux activités de terrain, est le trajet. Un planning calé au fil de l’eau sans tenir compte de la géographie produit des journées où le temps de route dépasse le temps facturable.
Ce qu’on automatise
Le calcul des disponibilités réelles. À partir de tous les agendas concernés, des horaires d’ouverture, des durées par type de rendez-vous, des temps de préparation et de trajet.
Les règles métier. Délai minimum avant un rendez-vous, délai maximum de projection, nombre maximum par jour, créneaux réservés à certains types, pauses obligatoires.
La proposition et la réservation, par lien, par formulaire ou dans un échange.
La création de l’événement dans l’agenda, avec tout ce qu’il faut : adresse, contact, lien de visioconférence, contexte du dossier.
La confirmation immédiate et les rappels, à des échéances que vous choisissez.
Les annulations et reports, avec libération du créneau et proposition à une liste d’attente.
La préparation. Avant un rendez-vous, un récapitulatif du dossier envoyé à la personne qui s’y rend — historique, documents, dernière interaction.
Comment ça marche techniquement — pour qui veut le détail
La lecture des agendas. CalDAV pour les agendas ouverts, Microsoft Graph pour Microsoft 365, API Google Calendar pour Workspace. On lit les périodes d’occupation (free/busy) plutôt que le détail des événements quand c’est possible : moins de données manipulées, et la confidentialité des agendas de l’équipe est préservée par construction plutôt que par promesse.
Les fuseaux et l’heure d’été. Toutes les heures sont stockées en UTC avec le fuseau de référence conservé à côté, et converties à l’affichage. Les pièges sont réels : le dimanche de changement d’heure comporte une heure qui n’existe pas et une qui existe deux fois. On s’appuie sur la base IANA à jour plutôt que sur un décalage fixe, et un rendez-vous pris en octobre pour novembre tombe à la bonne heure.
Le calcul des créneaux. Intersection des disponibilités de tous les participants requis, moins les occupations, moins les tampons, découpée selon le pas de la grille. Les intervalles se manipulent proprement avec le type tstzrange de PostgreSQL et ses opérateurs de chevauchement, ce qui évite les erreurs classiques sur les bornes.
La réservation concurrente. Deux personnes qui cliquent sur le même créneau à la même seconde arrivent plus souvent qu’on ne le croit. Une contrainte d’exclusion GIST sur (ressource, période) rend le double engagement impossible au niveau de la base, pas seulement dans le code : la seconde transaction échoue proprement et l’interface propose un autre créneau. Un verrou applicatif ne suffit pas dès qu’il y a plus d’un processus.
Le temps de trajet. OSRM ou Valhalla auto-hébergés sur des données OpenStreetMap, avec une matrice de distances calculée sur les rendez-vous de la journée. Deux avantages : les adresses de vos clients ne partent pas chez un service de cartographie commercial, et le calcul est gratuit à l’appel, ce qui permet de l’utiliser massivement — notamment pour proposer les créneaux par ordre de proximité avec la tournée existante.
L’ordonnancement des rappels. Table d’échéances consommée par un travailleur régulier via FOR UPDATE SKIP LOCKED, jamais une minuterie en mémoire. Un rappel doit survivre à un redémarrage, et un rappel manqué pendant une coupure doit être rattrapé ou explicitement abandonné s’il est devenu sans objet — envoyer « rappel : rendez-vous demain » le lendemain du rendez-vous est le genre de détail qui décrédibilise tout le système.
Les canaux de rappel. Courriel systématiquement, SMS quand le taux de présence le justifie — le SMS coûte quelques centimes et un rendez-vous manqué coûte bien davantage, le calcul est vite fait. Le SMS porte un identifiant d’expéditeur reconnaissable et un moyen de répondre ou d’annuler en un geste, sinon il génère des appels.
L’interopérabilité. L’invitation part en iCalendar avec les bons champs METHOD, UID et SEQUENCE : un report incrémente la séquence et met à jour l’événement chez le client au lieu d’en créer un second. C’est ce détail qui fait la différence entre un agenda client propre et un agenda avec trois versions du même rendez-vous.
Les annulations. Lien signé — jeton HMAC à durée limitée — plutôt qu’identifiant devinable dans l’URL, sinon l’annulation d’un rendez-vous devient possible pour qui incrémente un nombre. L’annulation libère le créneau dans la même transaction que la notification de la liste d’attente.
L’agent conversationnel, s’il y en a un. Il n’accède pas à l’agenda : il appelle deux fonctions, « proposer des créneaux » et « réserver », avec des paramètres validés par schéma. Il ne peut donc rien faire d’autre que ce que ces deux fonctions autorisent — c’est le principe du moindre privilège appliqué à un modèle, et c’est ce qui rend son usage acceptable dans un processus qui touche à l’agenda de l’entreprise.