Face à des modèles d’IA capables de scruter automatiquement des bases de code pour détecter des vulnérabilités, Cal (cal.com) a décidé de retirer son offre commerciale de l’open source et de passer à une licence propriétaire, tout en lançant une version hobby (cal.diy) ouverte. Ce choix marque un tournant potentiellement majeur pour les projets open source qui gèrent des données sensibles.
Contexte
Lancée en 2022 comme projet ouvert, Cal s’était positionnée sur le modèle open source pour résoudre les limites des outils de planification existants. La société est devenue l’un des plus grands projets Next.js et a longtemps défendu la transparence du code comme moteur d’innovation et de confiance.
La décision
En avril 2026, Cal a annoncé qu’elle fermait son programme commercial open source et basculait vers une licence propriétaire. La raison invoquée : l’explosion des capacités des outils d’IA (ex. Claude Opus, et plus récemment les résultats produits par Anthropic / Mythos) permettant d’automatiser la recherche de failles et d’exploiter rapidement des vulnérabilités présentes dans un code ouvert.
Pourquoi l’IA change la donne
- Automatisation de l’analyse : des modèles d’IA modernes peuvent parcourir un dépôt open source et repérer motifs, failles logiques, configurations dangereuses, secrets laissés par inadvertance, etc. Là où il fallait auparavant des experts et du temps, l’IA accélère la découverte et multiplie les « regards » sur le code.
- Augmentation du risque opérationnel : selon les dirigeants de Cal, la transparence du code devient comparable à « donner le plan d’une banque », car le nombre d’attaquants potentiels et leur efficacité augmente fortement.
- Preuves récentes : des démonstrations publiques (ex. par Mythos) ont montré que des modèles d’IA peuvent identifier et exploiter des failles même dans des logiciels réputés sécurisés (ex. OpenBSD).
La réponse de Cal
Cal retire donc son offre commerciale open source pour protéger les données sensibles de ses utilisateurs. En parallèle, l’entreprise publie cal.diy, une version entièrement open source destinée aux hobbyistes et à l’expérimentation — mais le produit gérant les données à enjeux restera fermé.
Réactions et avis
- Dirigeants de Cal : la décision est présentée comme pragmatique — « nous voulons être une société de scheduling, pas une entreprise de cybersécurité ».
- Experts : des spécialistes estiment que les applications open source sont désormais plus faciles à exploiter (estimation citée : 5–10× plus facile) quand l’attaquant dispose d’outils d’IA sophistiqués.
Conséquences pour l’écosystème open source
- Risque de fermeture : d’autres projets manipulant des données sensibles (santé, finance, identifiants) pourraient suivre le même chemin si la pression d’exploitation augmente.
- Impact communautaire : moins d’accès public au code peut réduire les contributions, la transparence et la confiance, mais peut être considéré comme nécessaire pour la protection des utilisateurs.
- Économie du logiciel : le modèle économique de nombreux projets open source peut être remis en cause ; certains basculeront vers des modèles hybrides (open core, versions hobby vs pro fermées).
Mesures d’atténuation possibles
Pour les mainteneurs et entreprises qui veulent préserver l’ouverture tout en limitant le risque, plusieurs approches existent :
- Séparation des responsabilités : garder open source les composants non sensibles et fermer les modules gérant les données critiques.
- Minimisation des données : éviter de stocker des informations sensibles dans les parties open source et ne jamais inclure de secrets dans les dépôts.
- Bug bounty et sécurité proactive : renforcer les programmes de récompense, audits réguliers, revues de code automatisées et tests fuzzing.
- Hardening et obfuscation ciblée : durcissement, chiffrement côté serveur, contrôles d’accès stricts et cloisonnement des services.
- Surveillance et détection : systèmes de monitoring pour repérer scans et tentatives d’exploitation automatisées.
- Licences et politiques hybrides : modèles commerciaux combinant transparence pour l’innovation et protection pour les offres managées.
- Collaboration secteur / régulation : partage d’IOCs, normes et bonnes pratiques entre éditeurs pour contrer l’automatisation des attaques.
Limites et risques de la fermeture
- Perte de confiance et d’adoption communautaire.
- Frein à l’innovation collaborative.
- Risque que l’obscurité n’empêche pas les attaquants déterminés (la sécurité par l’obscurité n’est pas une panacée).
Conclusion et perspectives
La décision de Cal illustre un tournant : l’avènement d’IA très compétentes en analyse de code force les entreprises à réévaluer l’équilibre entre ouverture et sécurité. À court terme, on peut s’attendre à plus d’initiatives hybrides (partiellement open source, parties sensibles fermées) et à une intensification des pratiques de sécurité. À long terme, la communauté open source devra coopérer pour définir des standards et méthodes pour rester viable face à une menace automatisée.
Appel à l’action
Invitez vos lecteurs à débattre : « Pensez-vous que la fermeture du code est une réponse justifiée à la menace des IA ? Ou la communauté devrait-elle intensifier la sécurité collaborative ? » Laissez votre avis en commentaires.
