Note : Ce billet a été rédigé en août 2026, à la lumière des événements ayant conduit au changement de licence de Cal.com et à l’émergence de Cal.rs comme alternative viable.
Le problème : Cal.com ferme ses portes à l’open source
En avril 2026, Cal.com — l’une des plateformes de prise de rendez-vous open source les plus populaires au monde — a annoncé un changement de licence majeur avec la sortie de sa version 6.4.
Concrètement : la version commerciale de Cal.com est passée en mode « closed source ». Le fondateur Peer Richelsen a justifié ce choix par les risques que représentent les outils d’intelligence artificielle capables de scanner du code public pour y détecter des vulnérabilités.
Une version épurée, baptisée Cal.diy, reste disponible sous licence MIT, mais elle a vu de nombreuses fonctionnalités être retirées par rapport à la version commerciale.
En résumé :
| Version | Licence | Statut |
|---|---|---|
| Cal.com (commerciale) | Fermée (propriétaire) | Code non accessible |
| Cal.diy | MIT | Version allégée, sans fonctionnalités avancées |
Cette décision place Cal.com dans le sillage d’autres éditeurs ayant fait un choix similaire (HashiCorp, Redis, Elastic), mais avec une particularité : c’est la première fois qu’une entreprise cite explicitement les risques liés à l’IA comme raison du passage en closed source.
Pourquoi c’est un problème pour nous
Si vous utilisez Cal.com en auto-hébergement ou en tant qu’utilisateur final, ce changement a plusieurs conséquences directes :
- Perte de confiance : votre infrastructure dépend d’un éditeur qui peut modifier unilatéralement les conditions d’utilisation de son code.
- Risque de verrouillage : les fonctionnalités avancées ne sont plus accessibles, même pour ceux qui souhaitent contribuer.
- Fragilité : une plateforme que l’on ne peut pas auditer, modifier ou faire évoluer soi-même est un risque pour la continuité de service.
- Dépendance : si Cal.com fait faillite, change de direction ou ferme son service, vous êtes seul face à un code qui n’est plus vôtre.
Ces risques sont particulièrement intenses dans le contexte des collectivités territoriales et des services publics, où la souveraineté numérique et la maîtrise du code sont des exigences fortes.
La solution : Cal.rs, l’alternative en Rust
C’est dans ce contexte que Cal.rs (également appelé calrs) a trouvé sa raison d’être.
Cal.rs est un logiciel de prise de rendez-vous open source, écrit en Rust, conçu pour être auto-hébergé. Son nom même est un clin d’œil à Cal.com… mais avec un programme entièrement différent.
Voici ses caractéristiques principales :
- Open source : sous licence AGPL-3.0, le code est accessible, auditable et modifiable par tous.
- Rust : un seule binaire, aucune dépendance runtime. Pas de Node.js, pas de PostgreSQL, pas de JavaScript côté serveur.
- Auto-hébergé : pas de SaaS imposé, pas d’abonnement. Vous gardez le contrôle total de vos données.
- Stockage SQLite : pas de base de données lourde à administrer.
- CalDAV : synchronisation avec n’importe quel serveur CalDAV (Nextcloud, Fastmail, BlueMind, iCloud, Google Calendar, etc.).
- Gratuit : pas de modèle économique basé sur la revente d’espaces ou de fonctionnalités.
💡 En une phrase : Cal.rs, c’est « comme Cal.com, mais open source, plus léger, et écrit en Rust ».
Les avantages de Cal.rs
Voici un tableau comparatif des avantages concrets que nous avons constatés :
| Critère | Cal.com (post-v6.4) | Cal.rs |
|---|---|---|
| Licence | Fermée (commerciale) / MIT (allégée) | AGPL-3.0 |
| Langage | TypeScript / Node.js | Rust |
| Dépendances | PostgreSQL, Redis, Node.js | SQLite, rien d’autre |
| Auto-hébergement | Possible mais complexe | Natif, conçu pour |
| Abonnement | Obligatoire pour les fonctionnalités avancées | Aucun |
| Performance | Variables selon l’infrastructure | Rapide (binaire Rust) |
| Synchronisation calendrier | Propriétaire + CalDav | CalDAV standard |
| Souveraineté numérique | Limitée | Totale |
Performance
L’un des avantages techniques majeurs de Rust est la performance : Cal.rs s’exécute comme un binaire unique, sans interpréteur JavaScript intermédiaire. Les temps de chargement et de réponse sont généralement plus rapides, surtout sur des infrastructures modestes.
Simplicité d’administration
Plus de serveur PostgreSQL à maintenir, plus de worker Redis à monitorer. SQLite, c’est un seul fichier. C’est idéal pour les petites équipes, les associations ou les services municipaux qui n’ont pas deDevOps dédié.
Indépendance
Avec Cal.rs, personne ne peut changer la licence du jour au lendemain. Le code est sous AGPL-3.0, ce qui garantit que toute modification restera open source.
…et puis c’est un outil développé par Olivier Lambert, Grenoblois et PDG de Vates !
Déployer Cal.rs
Cal.rs se déploie facilement :
- Binaire unique : téléchargez la dernière version depuis cal.rs ou le dépôt GitHub.
- Configuration : liez votre serveur CalDAV existant.
- Lancement : un simple
./calrssuffit, souvent accompagné d’un reverse proxy (Nginx, Caddy).
La documentation complète est disponible sur cal.rs/docs.
Sources :
- Cal.com Blog — Cal.diy open source to closed source
- Cal.rs — Documentation officielle
- GitHub — olivierlambert/calrs
- Railway — Cal.rs deployment
⚠️ Avertissement : Cet article est une analyse à visée informative. Les comparaisons sont basées sur les informations publiques disponibles à la date de rédaction. Nous vous invitons à vérifier les spécifications techniques sur les sites officiels avant de prendre toute décision d’infrastructure.
Image d’illustration : photo de Towfiqu barbhuiya sur Unsplash
