Files
wiki/Catalogue-Self-Hosted/apps/app-cal-com.md
T
2026-06-09 18:40:21 +02:00

7.8 KiB


title: Cal.com created: 2026-06-07 updated: 2026-06-07 type: app tags: [catalogue, calendar, scheduling, booking, typescript, saas-alternative] confidence: high contested: false sources: [https://selfh.st/apps/?tag=calendar]

📅 Cal.com

La référence open source de la prise de rendez-vous en ligne : scheduling moderne, self-hosted, alternative directe à Calendly et Calendlery. TypeScript/Next.js, base PostgreSQL, écosystème riche.

Métadonnée Valeur
Site web cal.com
GitHub calcom/cal.com
License AGPL-3.0 (depuis la v2.0, juillet 2023 — auparavant sous licence Elastic)
Langage TypeScript, Next.js, tRPC, Prisma
Étoiles 13 911
Dernière MAJ 2026-05 (v5.x active)
Catégorie cat-calendar

Description

Cal.com (anciennement Calendso) est la référence open source du scheduling / booking en ligne. Né en 2021 d'un fork des idées de Calendly mais sous licence libre, le projet a explosé jusqu'à devenir la principale alternative self-hostée à Calendly. Il sert à exposer des créneaux de disponibilité (rendez-vous, démos, visios, entretiens) que vos contacts réservent eux-mêmes, sans ping-pong d'e-mails.

L'architecture est moderne : Next.js + tRPC + Prisma + PostgreSQL. Le front est en React avec un builder d'« event types » drag-and-drop (durée, tampon, redirections, workflows). Le back gère calendriers externes (Google, Outlook, iCloud, Fastmail via CalDAV), paiements Stripe, webhooks, intégrations Zoom/Google Meet, et — depuis les versions récentes — un App Store interne pour étendre la plateforme (HubSpot, Salesforce, Mattermost, etc.). Le mobile (iOS/Android) lit les rendez-vous en quasi temps réel.

Points forts : AGPL-3.0 strict (donc fork = contribution en retour), UI moderne et très propre, écosystème d'intégrations colossal, support CalDAV natif (donc interopérable avec app-radicale, app-baikal, app-davical), auto-hébergement réalisable sur un petit VPS, application mobile native, API publique complète. La version Cloud officielle (cal.com) reste gratuite jusqu'à 1 utilisateur, ce qui fait de Cal.com un modèle « open core ».

Points faibles : l'AGPL-3.0 est parfois vu comme contraignant (les SaaS qui forkent doivent publier leurs modifications — c'est précisément l'intention), besoin d'une stack lourde (Node + Postgres + Redis en pratique, Next.js pas trivial à débugger), migrations Prisma parfois casse-pieds entre versions majeures, App Store partiellement fermé côté self-hosted (certaines apps officielles Cloud-only), le développement est très rapide donc breaking changes fréquents sur les versions latest.

Installation

Via Docker (méthode officielle)

L'équipe fournit une image calcom/cal.com et un dépôt docker-compose dédié. La stack la plus simple combine l'app, PostgreSQL et un reverse-proxy.

# docker-compose.yml
services:
  calcom:
    image: calcom/cal.com:v5.0.0
    container_name: calcom
    restart: unless-stopped
    ports:
      - "3000:3000"
    environment:
      DATABASE_URL: postgresql://calcom:calcom@db:5432/calcom
      CALCOM_LICENSE_KEY: ""
      NEXT_PUBLIC_WEBAPP_URL: https://cal.example.com
      NEXTAUTH_URL: https://cal.example.com
      NEXTAUTH_SECRET: changez-moi-en-secret-32-chars
      EMAIL_FROM: noreply@example.com
      EMAIL_SERVER_HOST: smtp.example.com
      EMAIL_SERVER_PORT: 587
      EMAIL_SERVER_USER: noreply@example.com
      EMAIL_SERVER_PASSWORD: smtp-password
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16-alpine
    container_name: calcom-db
    restart: unless-stopped
    environment:
      POSTGRES_USER: calcom
      POSTGRES_PASSWORD: calcom
      POSTGRES_DB: calcom
    volumes:
      - ./data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U calcom"]
      interval: 10s
      timeout: 5s
      retries: 5

Compléter avec un reverse-proxy HTTPS (Traefik, Caddy, Nginx) pour exposer cal.example.com. Le NEXTAUTH_SECRET doit faire 32+ caractères (openssl rand -hex 32).

Installation manuelle

Node.js 20+, Yarn, PostgreSQL 14+, Redis (optionnel pour le cache). Cloner le repo, yarn install, configurer .env (voir .env.example), yarn prisma migrate deploy, yarn build, yarn start. La doc officielle détaille chaque pré-requis OS (Ubuntu, Debian, macOS).

Configuration

  1. Premier lancement : créer le compte admin depuis l'UI sur https://cal.example.com/auth/signup.
  2. Connecter un calendrier : Settings → Calendars → OAuth Google/Microsoft OU URL CalDAV (Radicale, Baïkal, DAViCal, EteSync).
  3. Créer un Event Type : Event Types → New → durée, disponibilité, lieu (Zoom, Meet, Whereby…), formulaire de questions, buffer time avant/après, redirections post-booking.
  4. Activer les webhooks : Settings → Developer → Webhooks pour notifier Mattermost, N8N, Discord, Gotify à chaque réservation.
  5. Activer Stripe si prise de paiement (clé API, lien vers compte Stripe).
  6. Workflows (v4+) : relances par e-mail/SMS, no-show follow-up, reminders.
  7. App Store (certaines apps) : Settings → Apps → installer Zoom, Google Meet, HubSpot, etc.

Alternatives

Open Source

  • app-radicale — Pas un scheduler, mais Cal.com s'y connecte en CalDAV
  • app-baikal — Idem, CalDAV, mais serveur
  • app-sabre-dav — Librairie PHP sur laquelle reposent Baïkal et DAViCal
  • Easy!Appointments (PHP) — Scheduler plus simple, sans la profondeur Cal.com
  • Nettu Scheduler (Node) — Scheduler collaboratif plus léger
  • Aurora (ex Soju) — Scheduler open source minimaliste
  • LibreBooking — Multi-ressources (salles, équipements), plus orienté bibliothèques

Propriétaires (ce que Cal.com remplace)

  • Calendly — Le leader SaaS, freemium, fermé
  • Calendlery (orthographe détournée) — Clone UI Calendly
  • Doodle — Sondages de dates, pas vraiment scheduling
  • Microsoft Bookings — Intégré à Microsoft 365, fermé
  • YouCanBookMe — SaaS, freemium
  • Acuity Scheduling (Squarespace) — Acquis, freemium

Sécurité

  • AGPL-3.0 : auditable, fork = contribution en retour (c'est l'intention)
  • OAuth2 / OIDC supportés, WebAuthn possible
  • Rate limiting sur les endpoints publics de booking
  • ⚠️ Webhooks : signer avec un secret, vérifier la signature côté consommateur
  • ⚠️ NEXTAUTH_SECRET : rotatez-le, c'est la clé de voûte
  • ⚠️ Stack lourde (Node + Postgres) : garder Node.js et les deps à jour (CVE régulières)
  • ⚠️ Migration entre versions : sauvegarder la DB avant chaque upgrade majeur
  • HTTPS obligatoire derrière reverse-proxy
  • ⚠️ Pas d'authentification à 2 facteurs native dans toutes les versions (vérifier le CHANGELOG)

Ressources

Pages Liées