Cal.com ferme son code source à cause des IA comme Claude Mythos, invoquant la menace des IA offensives
Cal.com ferme son code source à cause des IA comme Claude Mythos, invoquant la menace des IA offensives :
une décision symbolique qui ne résout rien, ou un précédent dangereux pour l'écosystème libre ?
Pendant quatre ans, Cal.com s'est construit sur une promesse fondatrice : celle du logiciel libre. Le 14 avril 2026, la plateforme de planification de rendez-vous a rompu ce pacte en fermant son dépôt principal, invoquant une menace inédite : l'intelligence artificielle au service des attaquants. Une décision qui secoue la communauté open source et soulève des questions bien plus larges sur l'avenir des logiciels développés en public.
Cal.com n'est pas n'importe quel projet. Fondée en 2022 par Bailey Pumfleet et Peer Richelsen, la plateforme s'est imposée comme une alternative open source à Calendly, permettant aux utilisateurs de gérer leurs prises de rendez-vous via des liens partageables tout en offrant aux développeurs la possibilité de l'héberger et de la personnaliser eux-mêmes. Plus encore, Cal.com se présente comme le mainteneur du plus grand projet open source développé avec le framework Next.js au monde. Ce n'est donc pas une startup obscure qui tourne le dos à l'open source : c'est l'un de ses représentants les plus emblématiques.
À sa création, la philosophie était limpide. Pumfleet écrivait lui-même que les limitations des outils de planification existants « ne pouvaient être résolues que par l'open source » :
« Dès le premier jour, il était évident pour nous que Cal.com serait un projet open source. Les choses que nous avions l'intention de faire étaient fondamentalement plus difficiles en tant que produit SaaS fermé que d'être open source.
« Le point clé ici est que les limitations des produits de planification existants ne pouvaient être résolues que par l'open source. De nombreux fondateurs empruntent le mauvais chemin en pensant qu'ils devraient créer une alternative open source à un produit existant, pensant que leur produit réussira uniquement parce qu'il est open source. Au lieu de cela, vous ne devriez envisager de rendre votre projet open source que si l'open source résout réellement les défis que vous souhaitez relever (par exemple, la personnalisation, l'auto-hébergement).
« Par exemple, vous pourriez créer une alternative open source à Twitter, mais il est peu probable qu'elle décolle, car les réseaux sociaux ne profitent pas vraiment d'être open source. Il existe de nombreux exemples de projets qui sont open source juste pour le plaisir d'être open source.
« Cependant, si vous regardez par exemple l'industrie du commerce électronique, qui est principalement dominée par des produits SaaS comme Shopify ou BigCommerce, vous pouvez voir qu'avoir une alternative open source permettrait aux magasins d'être auto-hébergés, entièrement personnalisés et en marque blanche, et d'être étendus de manières impossibles avec un produit closed source. Ce serait un bon exemple des raisons pour lesquelles vous devriez ouvrir votre projet.
« En plus de cela, avec tout logiciel ouvert, accessible et gratuit, il existe des inconvénients évidents et non évidents. L'open source a de nombreux avantages dont vous êtes probablement conscient, mais l'open source n'est pas sans ses désavantages. »
Aujourd'hui, le PDG affirme qu'il faut protéger les données de réservation des clients de l'entreprise, et que ce besoin passe avant l'attachement au logiciel libre. Le dépôt GitHub public a été rendu privé. Les utilisateurs professionnels et payants recevront une invitation d'accès au dépôt désormais fermé.
L'IA offensive : un changement de paradigme sécuritaire
L'argument central de Cal.com tient en une idée : l'intelligence artificielle a basculé l'équilibre entre attaquants et défenseurs. Par le passé, exploiter une application nécessitait un pirate hautement qualifié, des années d'expérience et un investissement en temps considérable pour trouver et exploiter des failles. Aujourd'hui, une IA peut être pointée sur un dépôt public et le parcourir méthodiquement pour identifier des vulnérabilités.
La société cite notamment Claude Mythos d'Anthropic, annoncé début avril 2026 : ce modèle a identifié une vulnérabilité vieille de 27 ans dans OpenBSD, l'un des projets open source les plus axés sur la sécurité au monde, et a généré des exploits fonctionnels en quelques heures. Il a également détecté une faille de 16 ans dans FFmpeg que des outils automatisés avaient scanné cinq millions de fois sans jamais la signaler.
Ces derniers mois, une vague de startups spécialisées en sécurité a commencé à industrialiser cette capacité. Chaque plateforme fait remonter des vulnérabilités différentes, rendant difficile l'établissement d'une source de vérité unique sur ce qui est réellement sécurisé. C'est ce flou, autant que la menace elle-même, qui a conduit la direction à trancher.
Peer Richelsen, cofondateur et président, résume la situation ainsi : « La sécurité open source a toujours reposé sur des humains pour trouver et corriger les problèmes. Désormais, les attaquants bousculent cette transparence grâce à l'IA. » Pumfleet va plus loin en filant la métaphore : distribuer un code source public, c'est « comme distribuer les plans d'un coffre-fort à la banque. Et maintenant, il y a 100 fois plus de pirates qui étudient ces plans. »
L'entreprise s'appuie également sur l'analyse d'Huzaifa Ahmad, PDG de Hex Security, selon lequel les applications open source sont désormais 5 à 10 fois plus faciles à exploiter que leurs équivalents propriétaires. Un chiffre frappant, même s'il émane d'un acteur dont le modèle économique repose précisément sur la vente de tests d'intrusion automatisés par IA.
Cal.diy : une porte de sortie ou un leurre ?
Pour ne pas se couper totalement de la communauté open source, Cal.com a lancé simultanément Cal.diy, une version de son code source redistribuée sous licence MIT, destinée aux développeurs, aux amateurs et à quiconque souhaite expérimenter la plateforme.
Mais la documentation de Cal.diy est sans ambiguïté : « À utiliser à vos propres risques. Cal.diy est l'édition communautaire open source de Cal.com, destinée aux utilisateurs souhaitant héberger leur propre instance. Son usage est strictement recommandé pour des fins personnelles, hors production. » La comparaison des fonctionnalités est parlante : la version libre se passe des équipes, du SSO, de la synchronisation d'annuaire SCIM, des formulaires de routage, du tableau de bord analytique et du panneau d'administration, autant de briques essentielles pour un usage professionnel.
Richelsen précise que la décision de quitter l'open source était déjà en cours bien avant l'annonce de Claude Mythos et de la vulnérabilité OpenBSD : « Nous avions pris cette décision bien avant, mais le calendrier est effrayant. » Cette clarification suggère que les événements récents ont au moins servi de détonateur médiatique, si ce n'est de justification première.
« Aujourd'hui, l'IA peut analyser un code source ouvert et le scanner systématiquement à la recherche de vulnérabilités.
« Être open source revient de plus en plus à fournir aux attaquants les plans d'un coffre-fort numérique. Lorsque la structure est entièrement visible, il devient beaucoup plus facile d'identifier les failles et de les exploiter.
« Ces derniers mois, nous avons vu fleurir de nombreuses startups spécialisées dans la sécurité IA, commercialisant cette capacité. Chaque plateforme révèle des vulnérabilités différentes, ce qui rend difficile l'établissement d'une source unique et fiable d'informations sur ce qui est réellement sécurisé.
« Cette incertitude nous a contraints à faire un choix*: rester open source et accepter un risque accru pour les données de nos clients, ou passer à un modèle propriétaire pour réduire ce risque. Ce n'est pas une solution parfaite, mais nous devons tout mettre en œuvre pour protéger nos utilisateurs.
« Parallèlement, l'open source nous tient toujours à cœur. C'est pourquoi nous publions une version de notre code source sous licence MIT, sous le nom de Cal.diy. Bien que notre code source de production ait considérablement divergé, notamment avec des réécritures majeures de systèmes centraux comme l'authentification et la gestion des données, nous tenons à garantir qu'une version véritablement ouverte reste disponible pour les développeurs, les amateurs et tous ceux qui souhaitent explorer et expérimenter. »
Une décision qui fait débat : sécurité par l'obscurité ?
La réaction de la communauté technique a été sceptique, voire acerbe. Le reproche le plus fondamental tient à un principe vieux comme la cryptographie moderne : la sécurité par l'obscurité ne constitue pas une véritable sécurité. Cacher le code ne corrige pas les failles, il les dissimule provisoirement jusqu'à ce qu'un attaquant suffisamment déterminé les trouve quand même.
Plusieurs voix sur les plateformes spécialisées ont soulevé une contradiction flagrante : si le code est trop dangereux à rendre public pour un usage commercial, pourquoi est-il jugé acceptable de le distribuer librement aux amateurs sous Cal.diy ? D'autres ont rappelé que les outils d'IA peuvent aussi bien analyser du code machine compilé que des sources, rendant le passage en source fermée d'une efficacité très relative face à un adversaire sophistiqué.
Un argument technique mérite d'être pris au sérieux : l'asymétrie entre offensif et défensif dans l'usage de l'IA. Un attaquant peut se permettre des faux positifs et des erreurs, un exploit raté ne lui coûte presque rien. Le défenseur, lui, ne peut pas se permettre qu'un correctif généré par IA introduise lui-même une nouvelle faille ou écrase des données. Fermer le code source transfère ainsi un type de risque (la découverte publique de vulnérabilités) contre un autre : moins de contrôle externe, davantage de dépendance aux processus internes, et une possible perte de confiance de la communauté de développeurs qui a contribué à sa croissance.
D'autres observateurs, moins indulgents, y voient tout simplement le schéma classique d'une entreprise open source qui se referme une fois le produit devenu rentable, en habillant la décision d'une justification acceptable. Comme le formule un commentateur : « À chaque fois qu'on veut faire quelque chose de peu reluisant, on dit maintenant que c'est la faute à l'IA. »
Un précédent pour l'écosystème open source commercial ?
Au-delà de Cal.com, c'est la question de la viabilité du modèle « open core » qui se pose. Bien avant l'IA, des entreprises bâties sur des fondations open source ont adopté des modèles plus restrictifs, souvent pour des raisons commerciales, qu'il s'agisse de limiter l'usage par les fournisseurs cloud ou de mieux contrôler la monétisation. The New Stack HashiCorp, Redis, MongoDB ont ouvert ce chemin. Cal.com fraie le même sillon, mais avec une argumentation nouvelle.
Ce qui distingue potentiellement le cas Cal.com, c'est que la menace invoquée n'est pas concurrentielle mais sécuritaire et que cette menace, si elle est réelle, est structurelle et non conjoncturelle. Si des modèles comme Claude Mythos démontrent effectivement une capacité à industrialiser la recherche de vulnérabilités sur des bases de code publiques, d'autres projets open source à vocation commerciale pourraient se retrouver face au même dilemme. La défense se déplace alors du code lui-même vers des éléments plus difficiles à copier : fonctionnalités d'entreprise profondément intégrées, programmes de sécurité documentés et auditables, SCIM, SSO, politiques de rétention.
Pumfleet laisse une porte entrouverte : « Si la situation venait à changer, nous pourrions rouvrir le code. » Mais cette promesse conditionnelle ressemble surtout à une tentative de ménager la chèvre et le chou dans une communauté qui a fondé sa confiance sur la transparence.
Sources : billets de l'entreprise (décision de se tourner vers l'open source, abandon de l'open source), vidéo dans le texte
Et vous ?
L'argument de Cal.com constitue-t-il un véritable tournant dans la doctrine de sécurité open source, ou une rationalisation commode pour un mouvement motivé en réalité par des considérations commerciales ?
Répondre avec citation
Partager