Cal.com ferme son code : le réveil de l'open source face à l'IA

Le 15 avril 2026, Cal.com — l'une des plateformes de prise de rendez-vous open source les plus visibles de la planète — a annoncé le passage de son code principal derrière des portes closes. Cinq années de dépôts publics, de contributions communautaires et une forte identité open source, effacées en un seul billet de blog. La raison, selon le fondateur Peer Richelsen, n'est pas un virage vers la monétisation propriétaire. C'est une décision de survie imposée par l'IA.

L'annonce est tombée huit jours après qu'Anthropic ait dévoilé Mythos Preview, un modèle interne qui découvre et exploite des vulnérabilités zero-day sur tous les systèmes d'exploitation et navigateurs majeurs. Elle arrive quelques semaines après que des scanners dopés à l'IA aient exhumé une vulnérabilité vieille de 27 ans dans le noyau BSD et généré des exploits fonctionnels en quelques heures. Pour les clients entreprises de Cal.com — hôpitaux, banques, administrations — l'équation ne tenait plus. Quand vous livrez une infrastructure de planification sensible, publier votre code revient à publier le plan d'attaque.

Ce n'est pas un coup de communication isolé. C'est le signal le plus clair à ce jour que l'IA a réécrit l'économie de la sécurité logicielle, et que chaque entreprise qui livre du code doit repenser ce que signifie « ouvert » en 2026.

Ce que Cal.com a réellement fait

L'entreprise a déplacé le dépôt de son produit principal vers une base de code privée. Cal.com for Teams, Cal.com for Enterprise et le produit hébergé sont désormais fermés. En parallèle, elle a lancé Cal.diy, un fork entièrement sous licence MIT destiné aux hobbyistes, à ceux qui hébergent eux-mêmes et aux développeurs curieux. Le projet ouvert est un outil de planification fonctionnel. Le produit fermé, lui, héberge l'authentification durcie, les contrôles SOC 2 et les intégrations entreprise.

C'est le modèle hybride qui devient discrètement la norme :

Une « édition communautaire » publique qui garde la marque, les contributeurs et la longue traîne des déploiements auto-hébergés
Une « édition entreprise » privée qui gère les données à fort enjeu, les frontières de conformité et tout ce qu'un scanner IA pourrait transformer en arme

MongoDB, Elastic, HashiCorp et Redis ont tous emprunté des variantes de ce chemin avant que l'IA ne soit le déclencheur. Cal.com est le premier acteur majeur à dire tout haut que les scanners d'exploits dopés à l'IA — et non les hyperscalers cloud — sont la raison.

Le problème des scanners IA est réel

La vérité inconfortable, c'est que la sécurité de l'open source a toujours reposé sur un postulat tacite : plus d'yeux trouveront les bugs plus vite que les attaquants. Ce postulat fonctionnait quand les attaquants étaient des humains au temps limité. Il ne fonctionne plus quand les attaquants sont des agents autonomes capables de lire une base de code entière en quelques minutes.

Trois points de données des six derniers mois racontent l'histoire :

Mythos Preview (Anthropic, avril 2026) a démontré la découverte de vulnérabilités et la génération d'exploits de bout en bout sur des cibles de production. Anthropic l'utilise comme outil de recherche défensive. Les adversaires, eux, ne se limiteront pas.
L'attaque de la chaîne d'approvisionnement de litellm (mars 2026) a été retracée jusqu'à un agent autonome — hackerbot-claw — qui a compromis le pipeline CI de Trivy, volé des jetons PyPI et empoisonné une bibliothèque téléchargée 95 millions de fois par mois. Fenêtre d'exposition : moins de trois heures. Portée : chaque environnement ayant tiré la mauvaise version.
Les données terrain de Hex Security, citées dans l'annonce de Cal.com, montrent que les applications open source sont cinq à dix fois plus faciles à exploiter que leurs équivalents fermés quand on leur pointe des scanners IA.

Le fil conducteur est l'asymétrie des coûts. L'attaque est tombée à près de zéro. La défense se facture encore en heures-homme.

Est-ce la fin de l'open source ?

Réponse courte : non. Réponse plus longue : l'open source se scinde en strates.

L'infrastructure et les primitives restent ouvertes. Linux, PostgreSQL, Kubernetes, React, FastAPI et les milliers de bibliothèques dont l'industrie dépend ont trop de revue accumulée, trop de regards et trop de soutien institutionnel pour être fermés. Les fermer casserait internet avant de protéger qui que ce soit.

Les produits de la couche applicative qui manipulent des données régulées sont ceux qui passent en privé. CRM, planificateurs, systèmes RH, plateformes de santé, backends fintech — tout ce où un seul exploit signifie une notification de violation, une amende RGPD ou l'arrivée d'un régulateur. Cal.com est en avance, pas seule.

L'outillage développeur est le milieu intéressant. Cursor, Windsurf et Claude Code sont déjà majoritairement propriétaires. La prochaine vague d'outils dev natifs IA sortira fermée par défaut, avec des composants ouverts optionnels (CLIs, runtimes, serveurs MCP) là où les effets d'écosystème comptent plus que la visibilité du code.

La fondation open source reste intacte. Ce qui se réduit, c'est le milieu — cette classe d'éditeurs applicatifs qui traitaient « open source » comme une posture marketing plutôt que comme un engagement structurel.

Ce que cela change pour les entreprises MENA

Pour les PME et startups de Tunisie, d'Arabie saoudite et de la région MENA au sens large, la décision de Cal.com a quatre conséquences directes à intégrer.

1. Votre stack auto-hébergée est désormais un audit de surface d'attaque. Si vous faites tourner des applications open source sur votre propre infrastructure — GitLab, Nextcloud, Matomo, n'importe quel planificateur ou CRM sous licence MIT — vous héritez du risque scanner IA. La parade n'est pas « passez au propriétaire ». C'est la discipline de patching, le sandboxing et la suppression de tout ce que vous n'utilisez pas activement. Le nombre de dépendances, c'est de la surface d'attaque.

2. L'hygiène de la chaîne d'approvisionnement n'est plus optionnelle. Épinglez les dépendances à des versions exactes avec vérification de hash. Utilisez Trusted Publishers sur PyPI et npm. Faites tourner les agents IA dans des environnements isolés qui ne peuvent pas toucher les identifiants de production. Le plan d'attaque litellm fonctionne contre n'importe qui, dans n'importe quelle région.

3. Les licences open source évoluent — lisez les petits caractères. Attendez-vous à ce que d'autres produits suivent le schéma Cal.com : un fork communautaire permissif plus un produit commercial fermé. Si votre activité dépend d'un outil open source auto-hébergé, suivez l'état de la licence à chaque version majeure. La version que vous avez déployée en 2024 n'est peut-être pas celle qui sort en 2026.

4. « Fermé » ne veut pas dire « sécurisé ». Les réactions de byteiota et de Hacker News à l'annonce de Cal.com étaient tranchées : fermer le code ralentit les scanners IA, mais ne les arrête pas. Un code fermé avec un cycle de développement faible reste vulnérable. Le vrai travail — modélisation des menaces, gestion des secrets, IAM à moindre privilège, artefacts signés — ne change pas selon que le dépôt est public ou non.

Le playbook pour les éditeurs logiciels en 2026

Si vous construisez ou exploitez un logiciel qui manipule des données client, la décision de Cal.com est une fonction de forçage. Un playbook 2026 qui tient la route ressemble à ceci :

Classez votre code. Marquez chaque dépôt comme « publiable sans risque », « publiable avec réserves » ou « doit rester privé ». La taxonomie doit reposer sur la portée d'impact en cas d'analyse complète par un scanner IA, pas sur les habitudes de licence actuelles.
Adoptez un modèle de licence hybride tôt. Une édition communautaire construit la marque. Une édition commerciale finance l'entreprise. Cal.diy est le gabarit : même héritage produit, posture sécurité différente.
Investissez dans la signature d'artefacts et les SBOM. Sigstore, les attestations in-toto et les SBOM signés permettent aux clients de vérifier ce qu'ils exécutent. C'est le minimum pour les contrats entreprise dans le monde post-litellm.
Passez des scanners IA défensifs sur votre propre code avant les attaquants. GitHub Advanced Security, Semgrep Pro et les outils plus récents natifs IA comme Hex Security et Endor Labs ferment l'écart offense-défense. Le budget est inférieur au coût d'une seule violation.
Sandboxez vos agents de codage IA. Si Claude Code, Cursor ou Copilot tourne dans un environnement avec accès direct à vos identifiants cloud, vous êtes à une dépendance compromise d'une mauvaise journée. Faites-les tourner dans des conteneurs éphémères avec des identifiants à portée réduite.

La vue d'ensemble

Le mouvement de Cal.com n'est pas une trahison de l'open source. C'est l'aveu le plus visible à ce jour que l'IA a déplacé la ligne de base de sécurité, et que certains produits ne peuvent plus absorber le coût d'une transparence publique totale. Le calcul qui a fait de « source disponible » la norme depuis deux décennies était construit pour un modèle de menace à échelle humaine. Ce modèle est terminé.

La bonne question n'est pas « devons-nous fermer notre code ? ». C'est « quel est le plus petit périmètre signifiant que nous pouvons défendre, et comment construisons-nous le reste en ouvert ? ». Pour la plupart des entreprises MENA, cela veut dire garder ouverts votre outillage interne, votre infrastructure-as-code et vos primitives publiques — tout en traitant la logique applicative orientée client comme quelque chose à protéger, signer et sandboxer.

L'annonce Cal.com ne sera pas la dernière du genre cette année. Elle ne sera probablement même pas dans le top cinq d'ici décembre. Les entreprises qui la traitent comme un signal d'alarme plutôt que comme un cas isolé sont celles qui livreront encore du logiciel en 2028.

À lire aussi sur noqta.tn :