Brancher Cal.com sur n8n : de la demande au RDV confirmé

Brancher Cal.com sur n8n : de la demande au RDV confirmé

Un créneau booké n'est pas un process. C'est un événement. Encore faut-il qu'il arrive au bon endroit, signé, et qu'un humain sache quoi faire ensuite.

La prise de rendez-vous n8n Cal.com est le premier workflow que presque toutes les PME de services nous décrivent. Coach Qualiopi, petite agence, consultant : le visiteur choisit un créneau, vous recevez un mail, et quelqu'un recopie le nom dans un tableur. Cal.com (ou Calendly) ferme le créneau. n8n est censé faire le reste.

Cet article est un tutoriel opérationnel, daté rentrée 2026. Vous saurez brancher Cal.com sur n8n de deux façons : le nœud Cal.com Trigger (à partir de n8n 2.34.0, 4 août 2026) et le webhook générique, qui reste le bon choix dès que vous sortez des quatre événements du trigger. Vous verrez le payload BOOKING_CREATED, la vérif HMAC, un workflow minimum, trois cas ICP, puis le mur : WhatsApp, no-show, CRM. Si votre site n'a toujours pas d'agenda, commencez par site vitrine vs site qui prend des RDV. Ici, on suppose que le visiteur peut déjà booker.

À la fin, un créneau de 30 minutes : on ouvre votre Cal.com et votre n8n, on dit ce qui se livre vraiment.

---

Ce que la SERP raconte — et ce qu'elle oublie

Cherchez « n8n Cal.com prise de rendez-vous » en août 2026. Vous tombez sur des pages produit Cal.com, le template vocal ElevenLabs de n8n.io, un tuto Calendly (pas Cal.com) d'une agence, et des fiches « comment connecter Cal Com à n8n » qui listent encore le Cal.com Trigger comme si 2026 n'avait rien cassé.

Ce qui a cassé est documenté. Le 24 juillet 2026, un utilisateur self-host (n8n 2.31.6) ouvre l'issue n8n#34934 : credentials et nœud Cal.com, même réglés sur « v2.0 onwards », tapent encore l'API v1. Cal.com répond : API v1 has been decommissioned. Please migrate to API v2. Le forum n8n (fil de mai 2026) dit la même chose sur n8n Cloud. Le workaround officiel des modérateurs : nœud Webhook POST, URL de production, enregistrement manuel dans Cal.com.

Le 31 juillet, la PR n8n#35055 fusionne un vrai Cal.com Trigger v2 (CalTriggerV2.node.ts). Elle part dans n8n 2.34.0, publié le 4 août 2026. Les anciennes versions du nœud sont gardées pour ne rien casser par accident. Les docs n8n, elles, n'ont pas toutes été mises à jour le jour J (la PR le notait : « Docs updated » n'était pas coché).

Donc : si votre n8n est < 2.34.0, ne suivez pas un tuto qui dit « glissez le nœud Cal.com ». Si vous êtes à jour, le trigger natif marche pour quatre événements (doc n8n) : Booking created, cancelled, rescheduled, Meeting ended. Le no-show, le paiement, le formulaire Cal.com, ce n'est pas cette liste. C'est la liste des webhooks Cal.com.

Quatre causes fréquentes : nœud encore en API v1, URL localhost, secret HMAC absent, événement hors du trigger natif.

---

Prérequis (30 minutes avant le premier nœud)

Vous avez besoin de quatre choses. Pas d'une stack « agent IA ».

1. Un type d'événement Cal.com qui prend déjà des RDV (durée, agenda Google / Outlook, questions de qualification courtes). Si le lien 404 ou exige un compte Google au visiteur, corrigez ça avant n8n.
2. n8n joignable en HTTPS public. Cloud n8n : l'URL de production du webhook. Self-host : un reverse proxy, pas http://localhost:5678. Cal.com SaaS refuse HTTP, localhost et les IP privées. Self-host Cal.com accepte HTTP et le LAN — documenté dans la page Webhooks.
3. Un secret webhook. Une chaîne longue, stockée dans les credentials n8n, jamais dans le JSON du workflow partagé sur le forum.
4. Un canal de preuve. Slack, e-mail, ou une base Notion. Le premier workflow n'écrit pas dans le CRM. Il prouve que l'événement arrive.

Activez (publish) le workflow avant de coller l'URL dans Cal.com. L'URL de test n8n change. L'URL de production, non.

---

Chemin A — Cal.com Trigger (n8n ≥ 2.34.0)

À partir de 2.34.0, le nœud Cal Trigger peut à nouveau créer le webhook côté Cal.com. Credentials : clé API en Authorization: Bearer, plus le header cal-api-version attendu par l'API v2 (la migration Cal.com documente 2024-08-13 sur https://api.cal.com/v2/). L'ancienne auth ?apiKey= en query, c'est v1. Elle est morte.

Étapes, sans théâtre :

1. Credentials Cal.com. Testez. Si le test échoue avec le message v1, vous n'êtes pas en 2.34.0.
2. Nœud Cal Trigger. Événement : Booking created.
3. Filtre optionnel : Event Type name or ID, si vous avez plusieurs agendas (audit vs coaching vs entretien).
4. Activez le workflow. Bookez-vous vous-même. Vérifiez l'exécution.

La PR 35055 autorise aussi un payload template. Utile pour réduire le JSON. Dangereux si vous supprimez attendees ou startTime dont le reste du graphe a besoin. Commencez sans template.

Limite à écrire dans votre runbook : ce nœud ne remplace pas Settings → Developer → Webhooks pour Booking No-show Updated ou Booking Paid. La doc n8n liste quatre events. Cal.com en liste plus de quinze.

---

Chemin B — Webhook générique (toutes versions, tous events)

C'est le chemin que le forum n8n a recommandé pendant la panne v1. Il reste le plus prévisible.

1. Nœud Webhook, méthode POST, path du type cal-booking.
2. Dans les options : collectez le raw body (nécessaire pour le HMAC).
3. Activez. Copiez l'URL de production.
4. Cal.com → Settings → Developer → Webhooks → New. Subscriber URL = cette URL. Triggers : au minimum Booking Created. Ajoutez Booking Cancelled, Booking Rescheduled, Meeting Ended, Booking No-show Updated si vous ferez des relances.
5. Secret : la même chaîne que dans n8n.
6. Sauvegardez. Bookez un vrai créneau (pas seulement « Test webhook » si vous voulez le payload complet).

Association possible : webhook utilisateur ou webhook event type. Un organisme de formation avec trois types d'appels (découverte, module, suivi) gagne à filtrer par eventTypeId dans n8n, ou à créer un webhook par type.

Visiteur booke → Cal.com POST HTTPS → n8n vérifie HMAC → branche created / cancelled / no-show → Slack et table. Rien n'est envoyé au client avant cette vérif.

---

Lire BOOKING_CREATED sans se tromper de champ

La doc Cal.com versionne les payloads. L'en-tête x-cal-webhook-version vaut par exemple 2021-10-20. La plupart des events sont wrappés :

{
  "triggerEvent": "BOOKING_CREATED",
  "createdAt": "2024-01-01T00:00:00.000Z",
  "payload": {
    "title": "Strategy Session between Organizer and Guest",
    "startTime": "2024-01-01T10:00:00Z",
    "endTime": "2024-01-01T10:15:00Z",
    "eventTypeId": 123,
    "organizer": { "name": "Organizer Name", "email": "organizer@example.com" },
    "attendees": [
      {
        "email": "guest@example.com",
        "name": "Guest User",
        "timeZone": "UTC"
      }
    ]
  }
}

MEETING_STARTED et MEETING_ENDED sont plats : les champs booking sont au même niveau que triggerEvent, sans wrapper payload. Si votre nœud Set lit payload.attendees.0.email sur un Meeting Ended, il sera vide. C'est dans la doc, pas une rumeur de forum.

Pour les event types seated, attendees ne contient que la personne du siège qui a déclenché le webhook, pas toute la salle. Ne construisez pas un « mail à tous les participants » sur ce tableau sans le relire.

Champs que nous mapppons en audit, presque toujours :

Les heures sont en ISO UTC. Convertissez vers Europe/Paris dans n8n (nœud Date & Time), pas dans votre tête. Un coach qui envoie « 10 h » à un client en Guadeloupe a déjà perdu le RDV.

---

Vérifier le HMAC, ou accepter les faux bookings

Cal.com : vous posez un secret. À la réception, vous calculez un HMAC-SHA256 du corps brut avec ce secret. Vous comparez à l'en-tête x-cal-signature-256. Si ça diffère, le POST n'est pas fiable.

Exemple illustratif (nœud Code, crypto Node.js). Adaptez aux noms d'items de votre Webhook. Ce n'est pas un copier-coller « production certifiée » :

const crypto = require('crypto');
const secret = $credentials.calWebhookSecret; // à brancher via credentials, pas en dur
const raw = $input.first().json.bodyRaw || $input.first().json.body;
const expected = crypto
  .createHmac('sha256', secret)
  .update(typeof raw === 'string' ? raw : JSON.stringify(raw))
  .digest('hex');
const received = $input.first().json.headers['x-cal-signature-256'];
if (expected !== received) {
  throw new Error('Cal.com signature mismatch');
}
return $input.all();

Piège n8n : si le nœud Webhook parse le JSON avant de vous donner le raw body, le HMAC casse (espaces, ordre des clés). D'où l'option raw body. Si vous n'arrivez pas à matcher, ne « désactivez pas le secret pour avancer ». Corrigez le raw body. Un webhook sans signature sur Internet, c'est un formulaire public qui crée des lignes CRM.

Self-host : vous contrôlez le réseau. SaaS Cal.com → n8n Cloud : HTTPS + HMAC, les deux.

---

Le workflow minimum (celui qui doit tourner ce soir)

Objectif : un booking créé produit (1) un message Slack / e-mail interne, (2) une ligne dans une table (Notion, Airtable ou Google Sheets), (3) rien d'autre vers le client. Cal.com envoie déjà la confirmation au booker. Dupliquer ce mail depuis n8n, c'est le moyen le plus rapide d'avoir deux confirmations contradictoires.

Graphe :

1. Webhook (ou Cal Trigger) → HMAC.
2. Switch sur triggerEvent.
3. Branche BOOKING_CREATED : Set (email, nom, startTime Europe/Paris, eventTypeId, URL Cal.com si présente).
4. Slack (canal #rdv) : une ligne lisible. Pas un dump JSON.
5. Notion / Sheets : une row Nouveau, statut À préparer.
6. Branche BOOKING_CANCELLED : même table, statut Annulé. Slack plus court.
7. Error Workflow : si Slack ou Notion tombe, vous le savez. Sinon vous croyez que « n8n a marché » parce que le webhook a répondu 200.

C'est volontairement pauvre. Un consultant indépendant le termine en une soirée. Une agence 8 personnes aussi, si quelqu'un possède n8n.

N'ajoutez pas Claude « pour résumer le brief » tant que le HMAC et la table ne tiennent pas une semaine. Un LLM sur un payload non signé, c'est un résumé de spam.

HMAC d'abord, mapping ensuite, Slack et table en parallèle. Le client a déjà la confirmation Cal.com : n8n prépare l'humain, il ne redit pas le créneau.

---

Trois situations, trois mappings

Même stack. Pas le même eventTypeId.

Coach / organisme : découverte vs module

Deux types Cal.com. Découverte 30 min, module 90 min. Le webhook unique arrive. Le Switch n8n lit eventTypeId. Découverte : Slack + row Notion « Pipeline ». Module : row « Session » + tâche « convocation J-2 ». Vous ne mettez pas un agent IA sur la convocation Qualiopi. Un nœud qui remplit un modèle de document, oui. ChatGPT Work, non — on l'a tranché dans Work à 20 $ vs n8n.

Le brief du prospect (trois questions Cal.com : thématique, effectif, déjà Qualiopi) va dans Notion, champs fixes. Pas dans un paragraphe généré.

Petite agence : onboarding après le kickoff

Le booking « cadrage 30 min » (celui de ce site, Cal.com) doit créer : dossier Drive ou page Notion client, tâche « CR J+1 », ping Slack du commercial. Le paiement d'acompte, s'il existe, n'est pas ce webhook. C'est Stripe, ou Booking Paid si vous encaissez dans Cal.com. Mélangez les deux dans le même nœud Set, et vous marquerez « payé » des gens qui n'ont fait que booker.

Les 70 serveurs MCP n8n peuvent aider un agent à chercher la page Notion du client. Ils ne remplacent pas le nœud qui crée la row avec des champs figés.

Consultant : prep pack, pas un CRM inventé

Un indépendant à 800–2 000 €/j n'a pas besoin de HubSpot le soir du premier webhook. Il a besoin : nom, société (question Cal.com), lien visio, startTime, et un rappel à lui 2 h avant (nœud Schedule / Wait jusqu'à startTime - 2h, ou un second workflow cron qui lit la table). Le CRM vient quand le pipeline a plus de vingt opportunités ouvertes, pas avant.

---

Rappels J-1 et no-show : là où le trigger natif ne suffit plus

Cal.com envoie déjà des e-mails. Beaucoup de PME s'arrêtent là. Puis elles mesurent les absents.

L'événement documenté côté Cal.com s'appelle Booking No-show Updated. Il n'est pas dans la liste des quatre events du Cal Trigger n8n. Chemin B, donc : webhook manuel, trigger coché.

Ce que nous posons en prod, ordre de grandeur de pratique, pas un benchmark national :

• J-1 : e-mail ou SMS « demain à {heure locale}, lien {url} ». Template figé. Pas d'IA.
• J-0 − 2 h : ping interne si le booking est toujours accepted.
• No-show : statut table No-show, tâche « relance J+1 », pas un second mail « vous avez oublié » dans la minute. Un humain valide. C'est du HITL, même sans agent.

WhatsApp pour le rappel : autre article, autre mur (opt-in, templates Meta, 24 h). Le tuto chatbot WhatsApp n8n + Claude pose le canal. Il ne pose pas l'opt-in CNIL — sujet séparé. N'empilez pas WhatsApp sur ce workflow tant que l'e-mail J-1 n'est pas fiable.

Meeting Ended (plat, rappel) sert à créer la tâche CR, pas à « transcrire avec l'IA » par défaut. La transcription est un projet. Le CR dû à J+1 est un booléen.

Le trigger natif (n8n ≥ 2.34.0) couvre quatre events. Cal.com en documente bien plus. No-show et paiement passent par le webhook générique.

---

Appels API v2 (créer un booking, lister les types)

Le trigger reçoit. Parfois vous devez écrire : créer un booking depuis un formulaire maison, lister les event types. L'API v1 (/v1/bookings?apiKey=) est décommissionnée. La migration Cal.com montre :

curl https://api.cal.com/v2/bookings \
  -H "Authorization: Bearer cal_live_xxxxxx" \
  -H "cal-api-version: 2024-08-13"

Dans n8n : nœud HTTP Request, pas l'ancien nœud Cal.com d'action s'il est encore coincé en v1 sur votre version. Bearer, header de version, JSON. Testez d'abord dans un workflow manuel. Ne construisez pas un « agent qui booke tout seul » tant que vous n'avez pas un quota et un HITL. Un double booking, c'est un client perdu, pas un log.

Self-host Cal.com : la base URL n'est pas api.cal.com. C'est la vôtre. Le header de version reste celui de votre instance. Lisez votre doc, pas un gist 2024.

---

Ce que ça coûte (ordre de grandeur)

Cal.com : offre cloud ou self-host. n8n : Cloud à l'exécution, ou VPS. Un workflow webhook + Slack + Notion, c'est des centaines d'exécutions par mois pour une PME qui booke 20 RDV, pas des millions de tokens. Les fourchettes de mise en place (cadrage, nœuds, HITL) sont dans prix n8n / Make 2026 — ordres de grandeur de pratique, pas un barème public.

Le coût caché n'est pas n8n. C'est la recopie manuelle qui continue « au cas où », et le mail de confirmation bricolé qui contredit Cal.com. Si après deux semaines quelqu'un recopie encore Slack dans Excel, le workflow n'est pas adopté. C'est un sujet d'équipe, pas de nœud.

RGPD, très court, parce qu'un agenda est une donnée personnelle. Base légale (souvent mesures précontractuelles B2B — à faire valider par votre conseil). Sous-traitant : Cal.com Cloud vs self-host, n8n Cloud vs VPS UE. Journal : qui a reçu le payload. Ce n'est pas un avis juridique. C'est la checklist qu'un cabinet RH ou un coach nous pose avant le go-live.

---

Le mur : où le DIY s'arrête

Vous pouvez, ce soir, livrer le chemin B + Slack + une sheet. C'est déjà mieux que le mail Cal.com seul.

Vous ne livrez pas, ce soir :

1. WhatsApp. Opt-in, templates, 24 h, ban Meta. Pas un nœud « Send message ».
2. No-show en cascade (SMS + e-mail + tâche + offre de report) sans HITL.
3. CRM bidirectionnel. HubSpot / Pipedrive qui écrase le booking, ou l'inverse. Mapping d'IDs, pas un Zap « create contact ».
4. Plusieurs agendas, plusieurs marques, un seul n8n. Filtrage eventTypeId, secrets séparés.
5. Paiement. Booking Paid ou Stripe. Jamais déduit d'un BOOKING_CREATED.
6. Signature HMAC + raw body sur une instance n8n mal proxifiée (body re-sérialisé).
7. n8n < 2.34.0 + obstination à utiliser le Cal Trigger. Mettez à jour, ou restez en webhook.
8. Site sans bouton RDV. n8n ne convertit pas une vitrine. Voir l'audit site.

C'est le périmètre de l'agence n8n et de l'audit automatisation : un workflow nommé, un owner, des erreurs Slack, une doc d'une page. Pas une démo ElevenLabs.

Trigger, HMAC, mapping, canal interne, table, puis seulement rappels, no-show, CRM, WhatsApp. L'ordre n'est pas négociable.

---

Checklist 30 minutes, avant de « tout automatiser »

1. Quelle version n8n ? Si < 2.34.0, chemin B uniquement pour le trigger natif.
2. L'URL collée dans Cal.com est-elle l'URL production HTTPS ?
3. Un secret est-il posé, et le HMAC testé avec un vrai booking ?
4. BOOKING_CREATED mappe-t-il email, nom, startTime, eventTypeId — et rien d'inventé ?
5. Slack (ou e-mail interne) est-il lisible en 5 secondes ?
6. Une table unique, un statut, un owner humain ?
7. Cal.com envoie-t-il déjà la confirmation client ? Alors n8n ne la duplique pas.
8. Avez-vous besoin du no-show ? Si oui, webhook manuel, pas seulement le Cal Trigger.
9. Combien de types d'événements ? Un Switch, ou plusieurs webhooks.
10. Le site a-t-il un CTA unique vers l'agenda ? Sinon le workflow tourne dans le vide.
11. Error workflow : qui est pingé à 23 h si Notion 500 ?
12. Si le Switch bloque : réservez 30 minutes. On ouvre les deux consoles ensemble.

---

Conclusion

Brancher Cal.com sur n8n n'est pas « poser le nœud Cal.com » comme en 2025. L'API v1 est morte. n8n 2.34.0 (4 août 2026) répare le trigger pour quatre events. Le webhook générique + Settings → Developer → Webhooks reste le chemin complet, surtout pour le no-show. HMAC sur le raw body. Mapping UTC → fuseau du client. Slack et une table avant WhatsApp et le CRM.

Les concurrents SEO vendent encore la connexion magique, ou Calendly. Votre rentrée, c'est un événement signé qui prépare un humain. Pas un second mail de confirmation.

Prochaine action : un booking test, une exécution n8n verte, une ligne Slack lisible. Puis le cadrage si vous voulez J-1, no-show et CRM sans bricolage. On sort de l'appel avec un périmètre, pas avec un template ElevenLabs.