Ce qui a changé chez Cal.com en avril 2026
Cal.com a publié le 14 avril 2026 un billet officiel expliquant sa décision : la montée en puissance des outils d'IA, capables d'analyser le code public pour détecter des vulnérabilités, a conduit l'équipe à fermer la base de code commerciale. La version v6.4 marque le point de bascule.
Le dépôt public calcom/cal.com a été renommé calcom/cal.diy et relicencié de AGPL-3.0 vers MIT. Ce changement peut paraître libéral à première vue — le MIT est permissif — mais le cœur du problème est ce qui a été retiré du code public, pas la licence elle-même. Cal.diy est officiellement décrit comme un outil pour usage personnel et non-production : le site cal.diy recommande explicitement Cal.com (la version fermée) pour tout usage commercial ou en production.
Fonctionnalités retirées de cal.diy par rapport à l'AGPL
- Teams et Organizations : gestion multi-membres et espaces d'équipe, désormais réservés à l'offre Enterprise fermée.
- Workflows : automatisations de rappels, notifications et actions déclenchées, absentes du code public.
- SSO et SAML : authentification unique via votre fournisseur d'identité, retirée de cal.diy.
- Routing Forms : formulaires de qualification pour acheminer les rendez-vous vers le bon membre, supprimés.
- Instant Booking : réservation immédiate sans confirmation manuelle, réservée à l'offre commerciale.
- Insights : tableau de bord analytique des réservations, absent du code ouvert.
- API v1 : l'ancienne API REST documentée, remplacée par API v2 uniquement côté commercial.
- Agent téléphonique IA : fonction de planification par appel téléphonique, code fermé.
Prérequis comparés : RAM, CPU et stack par alternative
Avant de choisir, vérifiez que votre VPS correspond au profil de l'outil. Les trois alternatives ont des stacks très différentes — une en Node.js/PostgreSQL, une en PHP/MySQL, une en Elixir/PostgreSQL — ce qui se traduit par des besoins et des contraintes d'administration distincts.
Fiches ressources par outil
- Rallly (AGPL-3.0) : Next.js + PostgreSQL via Docker Compose. Comptez 2 Go de RAM minimum, 1 vCPU suffit en charge légère. Un domaine, un SMTP et Docker Compose v2 sont requis. Le bundle officiel inclut PostgreSQL, un stockage objet S3-compatible et un reverse proxy HTTPS — une seule commande suffit.
- Easy!Appointments (GPL-3.0) : PHP 8.2+ + MySQL/MariaDB. Tourne sur tout serveur LAMP classique ou en Docker. 512 Mo de RAM suffisent pour un usage individuel ou une petite structure — c'est l'alternative la plus légère des trois. Compatible hébergement mutualisé cPanel, pas uniquement VPS.
- Tymeslot (AGPL-3.0) : Elixir/Phoenix LiveView + PostgreSQL inclus dans le conteneur Docker. Stack compilée, très faible empreinte mémoire à l'exécution. Un seul conteneur Docker avec PostgreSQL embarqué — prévu pour une installation VPS propre.
Déployer Rallly sur VPS avec Docker Compose
Préparer le serveur
Connectez-vous en root sur votre VPS. Installez Docker et Docker Compose v2 si ce n'est pas déjà fait :
curl -fsSL https://get.docker.com | sh docker compose versionOuvrez les ports 80 et 443 dans votre pare-feu. Pointez un sous-domaine (
cal.votre-domaine.com) vers l'IPv4 de votre VPS via un enregistrement A dans votre zone DNS.Récupérer la configuration officielle
Clonez le dépôt d'exemples self-hosted de Rallly et créez votre fichier d'environnement :
git clone https://github.com/lukevella/rallly-selfhosted.git cd rallly-selfhosted cp .env.example .envConfigurer les variables d'environnement
Ouvrez
.envet renseignez les variables essentielles :SECRET_PASSWORD=<chaine-aleatoire-32-chars> NEXT_PUBLIC_BASE_URL=https://cal.votre-domaine.com SMTP_HOST=smtp.votre-fournisseur.com SMTP_PORT=587 [email protected] SMTP_PWD=<mot-de-passe-smtp> [email protected]Générez la chaîne aléatoire avec
openssl rand -hex 16. Ne laissez pasSECRET_PASSWORDvide — Rallly refuse de démarrer sans une valeur non vide.Lancer les conteneurs
Démarrez l'ensemble de la stack en arrière-plan. Le bundle Rallly inclut l'application, PostgreSQL, un stockage objet et un reverse proxy avec TLS automatique :
docker compose up -dVérifiez que tous les services sont
healthy:docker compose psLe reverse proxy obtient automatiquement un certificat Let's Encrypt lors du premier démarrage — attendez une minute avant d'accéder au domaine.
Vérifier l'installation et créer le premier sondage
Ouvrez
https://cal.votre-domaine.comdans votre navigateur. L'interface Rallly vous accueille sans compte obligatoire pour les participants — seul l'organisateur crée un compte. Créez un premier sondage de disponibilité pour vérifier que l'envoi d'e-mails SMTP fonctionne correctement.Si l'e-mail n'arrive pas, vérifiez les logs du service applicatif :
docker compose logs app --tail=50Activer les mises à jour automatiques (optionnel)
Pour rester à jour sans intervention manuelle, installez Watchtower qui surveille les nouvelles images et redémarre les conteneurs concernés :
docker run -d \ --name watchtower \ -v /var/run/docker.sock:/var/run/docker.sock \ containrrr/watchtower --cleanup --interval 86400Watchtower vérifie les nouvelles images une fois par jour. Rallly publie régulièrement des correctifs de sécurité — ne laissez pas votre instance sans surveillance.
Rallly vs Easy!Appointments vs Tymeslot vs cal.diy
Faites défiler le tableau
| Critère | Rallly | Easy!Appointments | Tymeslot | cal.diy |
|---|---|---|---|---|
| Licence | AGPL-3.0 | GPL-3.0 | AGPL-3.0 | MIT (code amputé) |
| Stack | Next.js + PostgreSQL | PHP 8.2 + MySQL | Elixir/Phoenix + PostgreSQL | Next.js + PostgreSQL |
| RAM minimale | 2 Go | 512 Mo | Non documenté | 2 Go |
| Docker Compose | Oui, bundle officiel | Oui, image disponible | Oui, conteneur unique | Oui |
| Cas d'usage principal | Sondages de disponibilité, votes | Rendez-vous structurés (services/prestataires) | Planification individuelle et groupes | Planification individuelle (non-prod) |
| Sync calendrier | Google, Outlook (iCal) | Google Calendar | Google, Outlook, iCloud, CalDAV, Nextcloud | Google, Outlook |
| SSO / SAML | Non | Non | Non | Retiré (offre commerciale) |
| Teams multi-membres | Non | Multi-prestataires (services) | Oui (groupes) | Retiré (offre commerciale) |
| Workflows / rappels auto | Oui (e-mails) | Oui (e-mails) | Oui (e-mails, Slack, Telegram) | Retiré (offre commerciale) |
| API REST | Oui | Oui (REST complète) | Oui + webhooks | API v2 uniquement |
| Usage recommandé en prod | Oui | Oui | Oui | Non (déclaration officielle) |
| Maturité (2026) | Actif, v4.15.2 (sept. 2026) | Actif, v1.6.0 (mai 2026) | Actif, lancé en réponse à Cal.com | Maintenu, mais périmètre volontairement limité |
Migrer depuis Cal.com AGPL : exporter vos données
Si vous avez auto-hébergé Cal.com sous AGPL et souhaitez migrer vers l'une des alternatives, voici comment extraire vos données avant de couper votre ancienne instance.
Exporter depuis une instance Cal.com AGPL existante. Cal.com stocke ses données dans PostgreSQL. Vous pouvez exporter les tables de réservations, de disponibilités et de types d'événements via pg_dump :
pg_dump -U calcom -d calcom -t bookings -t event_types -t schedules > calcom_export.sqlLes données que vous récupérez en priorité : les réservations existantes (pour votre historique CRM), les adresses e-mail de participants (si vous envoyez des rappels), et vos règles de disponibilité (horaires, créneaux bloqués).
Ce que vous ne pouvez pas importer directement. Aucune des trois alternatives ne propose d'import au format Cal.com — la migration est une reconfiguration manuelle, pas une restauration. Concentrez-vous sur l'export de votre liste de contacts et de vos règles de disponibilité, puis reconfigurez les types d'événements dans l'outil cible. Pour Rallly (sondages de groupe) ou Tymeslot (liens de réservation individuels), la reconfiguration prend généralement moins d'une heure.
Pour Easy!Appointments, si vous venez d'un système avec des services structurés (créneaux de 30 min par prestataire), c'est l'outil dont la logique est la plus proche d'un agenda professionnel classique. Importez vos prestataires et services via l'interface d'administration, puis reconfigurez les plages horaires.
Durcissement post-installation
Quelques gestes avant d'exposer votre instance au trafic réel.
Protégez l'accès administrateur avec une authentification HTTP de base devant votre reverse proxy si l'outil ne propose pas de 2FA natif — particulièrement important pour Easy!Appointments en accès public. Configurez des sauvegardes automatiques du volume PostgreSQL ou du répertoire de données MySQL : un docker exec planifié avec pg_dump ou mysqldump vers un stockage externe suffit. Vérifiez que votre VPS n'expose que les ports nécessaires (80/443 pour le web, 22 pour SSH) et que l'accès direct au port de base de données (5432 ou 3306) n'est pas ouvert sur l'interface publique.
Enfin, activez les alertes de nouvelles versions dans le dépôt GitHub de votre outil choisi (onglet Watch → Custom → Releases) : les trois projets sont actifs en 2026 et publient des correctifs régulièrement.
Dépannage courant
Rallly : l'application démarre mais les e-mails n'arrivent pas. Vérifiez SMTP_HOST, SMTP_PORT et SMTP_USER dans votre fichier .env. Certains hébergeurs bloquent le port 25 en sortie — utilisez le port 587 (STARTTLS) ou 465 (SSL). Inspectez les logs avec docker compose logs app --tail=100 | grep -i smtp.
Easy!Appointments : erreur 500 ou page blanche après installation. Vérifiez que les droits sur le répertoire storage/ sont en écriture pour le processus web (chmod -R 775 storage/). En Docker, vérifiez que le conteneur MySQL est démarré et accessible avant le conteneur applicatif — un depends_on avec condition: service_healthy dans votre Compose résout les démarrages en race condition.
Tymeslot : le conteneur démarre mais la sync calendrier échoue. La sync Google/Outlook nécessite des identifiants OAuth2 (Client ID et Client Secret) configurés dans les variables d'environnement. Créez un projet dans la Google Cloud Console, activez l'API Google Calendar, et renseignez GOOGLE_CLIENT_ID et GOOGLE_CLIENT_SECRET. L'URL de callback OAuth doit correspondre exactement à votre domaine de production.
Rallly : erreur SECRET_PASSWORD must be set. Cette variable est obligatoire et doit faire au moins 32 caractères. Générez-en une avec openssl rand -hex 16 (produit 32 caractères hexadécimaux) et renseignez-la dans .env avant de relancer docker compose up -d.
Quelle alternative choisir ?
Rallly convient si vous avez besoin de sondages de disponibilité pour trouver un créneau commun à plusieurs participants — réunions d'équipe, ateliers, appels de groupe. Pas de réservation en flux tendu, mais un vote collaboratif léger et sans friction. Sa maturité (v4.15.2 en septembre 2026, bundle Docker officiel complet) en fait l'option la plus simple à déployer.
Easy!Appointments est le bon choix si votre usage ressemble à un agenda professionnel structuré : services (consultation, cours, entretien), prestataires, créneaux fixes et confirmation par e-mail. Il fonctionne aussi bien sur hébergement mutualisé cPanel que sur VPS, ce qui le rend accessible sans Docker. Sa version 1.6.0 (mai 2026) est la plus récente.
Tymeslot se positionne comme la réponse directe au départ de Cal.com AGPL : planification individuelle avec liens de réservation, sync multi-calendriers (Google, Outlook, iCloud, CalDAV, Nextcloud), et des intégrations webhooks pour s'accrocher à n8n ou Make. Né dans le sillage de la fermeture Cal.com, il cible directement les développeurs qui cherchaient une alternative à périmètre équivalent, avec une licence AGPL garantissant la pérennité.
Cal.diy reste une option si vous n'avez besoin que d'une page de réservation individuelle basique, sans engagement sur la pérennité des fonctionnalités — l'équipe Cal.com est explicite : cal.diy n'est pas recommandé pour la production commerciale. Si c'est votre cas de départ, Rallly ou Tymeslot vous offrent les mêmes fonctionnalités de base avec une communauté qui ne cherche pas à vous vendre une mise à niveau.
