Alternative à Calendly : héberger Cal.com sur un VPS
Confier les agendas de vos clients à un SaaS américain n'est pas une fatalité. Cal.com est l'alternative open source à Calendly. Voici comment l'héberger, sans cacher que c'est un déploiement exigeant.
Calendly simplifie la prise de rendez-vous, mais son utilisation implique de confier à un service SaaS externe des informations sensibles : disponibilités, adresses email, noms de clients, objets de réunions et parfois métadonnées d’agenda. Pour un freelance, un cabinet ou une PME soumis au RGPD, ce choix mérite d’être évalué avec attention, en particulier lorsque les données sont traitées hors de France.
Cal.com constitue une alternative open source intéressante. La plateforme permet de créer des liens de réservation, de définir plusieurs types de rendez-vous, de synchroniser des agendas et d’ajouter des outils de visioconférence. Son code source est disponible et l’application peut être installée sur sa propre infrastructure.
L’auto-hébergement de Cal.com n’est toutefois pas un déploiement en cinq minutes. L’application repose sur Next.js, PostgreSQL et de nombreuses variables d’environnement. Elle est sensiblement plus lourde et plus exigeante à administrer qu’une application légère comme Vaultwarden. Il faut notamment gérer les secrets, le serveur SMTP, les migrations de base de données, le HTTPS et les mises à jour.
Un VPS hébergé en France permet de conserver la base de données et l’application sous son contrôle. TalCloud prépare une offre VPS avec serveurs en France, stockage NVMe, protection Anti-DDoS Netrix et support humain. Les caractéristiques et les tarifs n’étant pas encore publiés, il serait prématuré de recommander une configuration précise. Pour Cal.com, il faudra néanmoins choisir un serveur disposant d’une marge confortable en mémoire vive et en stockage.
Les prérequis pour héberger Cal.com
Avant de commencer, réunissez les éléments suivants :
- Un VPS Linux avec suffisamment de RAM pour faire fonctionner Cal.com, PostgreSQL et le reverse proxy sans saturation
- Docker et le plugin Docker Compose (voir installer Docker sur un VPS)
- Un nom de domaine ou un sous-domaine, par exemple
reservation.exemple.fr - Un enregistrement DNS pointant vers l’adresse IP du VPS
- Un compte SMTP transactionnel pour envoyer les confirmations et les rappels
- Un accès SSH avec un utilisateur administrateur
- Une stratégie de sauvegarde pour PostgreSQL
Le SMTP n’est pas facultatif dans un déploiement réellement exploitable. Sans lui, les participants ne recevront pas correctement les confirmations, annulations, reprogrammations ou rappels. Utilisez un service transactionnel avec authentification, suivi des erreurs et configuration SPF, DKIM et DMARC sur votre domaine.
Avant l’installation, vérifiez aussi que les ports 80 et 443 sont accessibles. Le port interne de Cal.com, généralement 3000, ne doit pas être exposé directement sur Internet une fois le reverse proxy configuré.
Générer les secrets obligatoires
Cal.com utilise plusieurs secrets pour protéger les sessions et chiffrer certaines données sensibles. Ne réutilisez jamais un mot de passe humain ou une clé provenant d’une autre application.
Générez NEXTAUTH_SECRET avec OpenSSL :
openssl rand -base64 32
Générez séparément CALENDSO_ENCRYPTION_KEY :
openssl rand -base64 32
Chaque commande doit produire une valeur différente. Conservez-les dans un fichier .env protégé, jamais dans un dépôt Git. Pour le mot de passe PostgreSQL, une valeur hexadécimale évite les problèmes de caractères spéciaux dans DATABASE_URL :
openssl rand -hex 24
Une perte de CALENDSO_ENCRYPTION_KEY peut rendre illisibles des données chiffrées, notamment certains identifiants d’intégration. Ce fichier doit donc être inclus dans votre procédure de sauvegarde sécurisée, séparément de la base de données.
Déployer Cal.com avec Docker Compose
L’image Docker publiée est calcom/cal.com. Le dépôt officiel calcom/docker contient la configuration Docker maintenue par le projet et le processus utilisé pour construire l’image. Consultez sa version correspondant à la release que vous déployez, car les variables et étapes d’initialisation peuvent évoluer.
Voici une base de fichier compose.yaml à adapter :
services:
db:
image: postgres:16-alpine
restart: unless-stopped
environment:
POSTGRES_DB: calcom
POSTGRES_USER: calcom
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
volumes:
- calcom_db:/var/lib/postgresql/data
calcom:
image: calcom/cal.com:latest
restart: unless-stopped
depends_on:
- db
ports:
- "127.0.0.1:3000:3000"
environment:
NODE_ENV: production
DATABASE_URL: postgresql://calcom:${POSTGRES_PASSWORD}@db:5432/calcom
NEXTAUTH_SECRET: ${NEXTAUTH_SECRET}
NEXTAUTH_URL: https://reservation.exemple.fr
CALENDSO_ENCRYPTION_KEY: ${CALENDSO_ENCRYPTION_KEY}
NEXT_PUBLIC_WEBAPP_URL: https://reservation.exemple.fr
EMAIL_FROM: rendez-vous@exemple.fr
EMAIL_SERVER_HOST: ${EMAIL_SERVER_HOST}
EMAIL_SERVER_PORT: ${EMAIL_SERVER_PORT}
EMAIL_SERVER_USER: ${EMAIL_SERVER_USER}
EMAIL_SERVER_PASSWORD: ${EMAIL_SERVER_PASSWORD}
volumes:
calcom_db:
Placez les valeurs sensibles dans .env :
POSTGRES_PASSWORD=valeur_generee
NEXTAUTH_SECRET=valeur_generee
CALENDSO_ENCRYPTION_KEY=valeur_generee
EMAIL_SERVER_HOST=smtp.exemple.fr
EMAIL_SERVER_PORT=587
EMAIL_SERVER_USER=utilisateur_smtp
EMAIL_SERVER_PASSWORD=mot_de_passe_smtp
DATABASE_URL, NEXTAUTH_SECRET, NEXTAUTH_URL, CALENDSO_ENCRYPTION_KEY et NEXT_PUBLIC_WEBAPP_URL doivent être cohérents dès le premier démarrage. Une URL publique incorrecte provoque fréquemment des erreurs de connexion, des redirections vers localhost ou des liens d’email invalides.
Avant une mise en production, remplacez également latest par une version précise de l’image. Cela évite qu’un simple téléchargement déclenche une mise à niveau majeure imprévue. Démarrez ensuite les services et surveillez les journaux. Selon la version de Cal.com, une étape de migration ou d’initialisation de PostgreSQL peut être requise. Suivez les commandes indiquées dans le dépôt calcom/docker pour la version retenue.
Publier Cal.com en HTTPS
Placez Cal.com derrière un reverse proxy comme Caddy, Traefik ou Nginx. Celui-ci reçoit les connexions sur les ports 80 et 443, obtient un certificat TLS et transmet les requêtes vers 127.0.0.1:3000.
Avec Caddy, la configuration minimale ressemble à ceci :
reservation.exemple.fr {
reverse_proxy 127.0.0.1:3000
}
Le DNS doit déjà pointer vers le VPS pour que l’émission automatique du certificat fonctionne. Vérifiez ensuite que https://reservation.exemple.fr répond correctement et que toutes les redirections restent sur le domaine public. Nginx Proxy Manager convient également si vous préférez une interface graphique.
Ne publiez ni PostgreSQL ni le port 3000 sur toutes les interfaces réseau. Dans l’exemple Compose, l’écoute limitée à 127.0.0.1 réserve l’accès au reverse proxy local.
Créer le premier compte et un lien de réservation
Lors du premier accès, créez le compte administrateur avec une adresse email fonctionnelle. Vérifiez immédiatement la réception des emails afin de valider la configuration SMTP.
Créez ensuite un type d’événement, par exemple « Appel découverte de 30 minutes ». Définissez sa durée, les plages de disponibilité, le délai minimal avant réservation et le temps tampon entre deux rendez-vous.
Cal.com génère alors une adresse partageable, par exemple :
https://reservation.exemple.fr/votre-nom/appel-decouverte
Testez-la depuis une fenêtre de navigation privée avec une autre adresse email. Contrôlez la création du rendez-vous, l’envoi de la confirmation, le fuseau horaire, l’annulation et la reprogrammation.
Connecter Google Agenda ou CalDAV
Cal.com peut synchroniser les disponibilités avec des agendas externes afin d’éviter les doubles réservations. Pour Google Agenda, l’auto-hébergement demande généralement de créer vos propres identifiants OAuth dans Google Cloud, d’activer l’API nécessaire et de déclarer les URI de redirection correspondant à votre domaine Cal.com.
Les identifiants OAuth doivent ensuite être ajoutés aux variables d’environnement prévues par la version installée. Les noms exacts et les URL de rappel pouvant évoluer, reprenez-les dans la documentation de la release utilisée plutôt que de copier une configuration ancienne.
Pour CalDAV, renseignez l’URL du serveur, l’utilisateur et le secret demandé par le fournisseur. Lorsqu’il est disponible, préférez un mot de passe d’application à votre mot de passe principal.
L’auto-hébergement garde Cal.com et sa base PostgreSQL sur votre VPS, mais connecter Google Agenda implique toujours des échanges avec Google. La souveraineté dépend donc aussi du fournisseur d’agenda choisi. Une infrastructure CalDAV hébergée en France ou maîtrisée en interne permet d’aller plus loin dans cette démarche.
Sécuriser, mettre à jour et sauvegarder
Limitez SSH aux comptes nécessaires, utilisez des clés, activez un pare-feu et installez uniquement les services indispensables. Protégez .env avec des permissions restrictives et ne l’intégrez jamais à l’image Docker.
Sauvegardez régulièrement PostgreSQL avec pg_dump, puis copiez les archives vers un stockage distinct du VPS. Sauvegarder uniquement le volume Docker ne remplace pas toujours un export cohérent de la base. Testez périodiquement une restauration sur une instance isolée. Notre guide sur la stratégie de sauvegarde d’un serveur détaille cette approche.
Pour chaque mise à jour :
- Consultez les notes de version de Cal.com et du dépôt
calcom/docker. - Sauvegardez PostgreSQL et les secrets.
- Téléchargez la nouvelle image avec un numéro de version explicite.
- Appliquez les migrations prévues par cette release.
- Testez la connexion, les réservations, les emails et les intégrations.
- Conservez temporairement l’image précédente pour faciliter un retour arrière compatible avec la base.
Enfin, surveillez l’utilisation de la mémoire, l’espace disque, les redémarrages des conteneurs, les erreurs SMTP et l’expiration des certificats. Cal.com offre une solution de réservation souveraine et personnalisable, mais demande une véritable exploitation applicative. Pour préparer son installation sur un futur VPS TalCloud, réunissez dès maintenant le domaine, le compte SMTP, les secrets, le fichier Compose et une procédure de sauvegarde PostgreSQL testée.