Face à une nouvelle génération d’outils d’IA capables d’explorer automatiquement des bases de code et d’identifier des failles, Cal (cal.com) a décidé de retirer son programme commercial de l’open source et de passer à une licence propriétaire. Retour sur les raisons, les enjeux pour l’écosystème open source et des pistes pratiques pour les entreprises concernées.
Contexte
Fondée en 2022, Cal s’était positionnée dès le départ comme un projet open source (sous AGPL) pour résoudre les limites des produits de prise de rendez‑vous existants. Le succès a suivi — Cal est devenu l’un des plus grands projets Next.js — mais l’entreprise annonce aujourd’hui un retrait de son programme commercial du modèle open source.
Motif principal
La décision est motivée par un risque de sécurité aggravé par l’IA : des modèles comme Anthropic Claude Opus (et plus récemment Mythos) peuvent « parcourir » un dépôt public pour identifier automatiquement vulnérabilités et portes d’entrée. Selon la direction de Cal, l’ouverture du code revient à « donner le plan d’un coffre‑fort », et la capacité d’analyse automatisée des IA multiplie par cent le nombre d’assaillants potentiels étudiant ce plan.
Ce qui a déclenché l’alerte
- Des démonstrations publiques (notamment autour du modèle Mythos) ont montré que des IA peuvent trouver des failles dans des systèmes réputés sûrs, comme OpenBSD.
- Les fondateurs de Cal estiment qu’une application de réservation qui traite des données sensibles ne peut se permettre d’exposer son code commercial à ce risque croissant.
Mesures prises par Cal
- Passage de la licence AGPL à un modèle propriétaire pour sa plateforme commerciale.
- Publication en parallèle d’une version distincte, Cal.diy, laissée open source pour usage personnel et expérimentation, afin de permettre à la communauté d’expérimenter hors du périmètre des services commerciaux.
Réactions et positions
- Chez Cal, on insiste : l’abandon de l’open source commercial est une décision de protection des utilisateurs et non un rejet philosophique de l’open source ; l’entreprise se dit prête à revenir au modèle ouvert si la situation évolue.
- Des experts externes estiment que les applications open source sont aujourd’hui significativement plus faciles à exploiter qu’avant, ce qui pourrait pousser d’autres acteurs manipulant des données sensibles à suivre la même voie.
Implications pour l’écosystème open source
- Modèle économique : les entreprises qui comptaient sur l’open source comme levier marketing/communautaire pourraient devoir repenser la manière dont elles protègent les actifs client et les revenus.
- Sécurité collective : la logique classique — « beaucoup d’yeux trouvent les bugs » — se heurte à la réalité d’une analyse automatisée et massive faite par des acteurs malveillants.
- Risque de fragmentation : plus d’acteurs basculant vers du code fermé pourrait réduire l’innovation collaborative, mais être perçu comme nécessaire pour protéger la confidentialité et la sécurité.
Pistes de mitigation et bonnes pratiques
Conseillées pour les entreprises :
- Segmenter : maintenir une version open source allégée/non critique (comme Cal.diy) tout en conservant les composants sensibles en interne.
- Renforcer les audits de sécurité continus, tests automatisés et programmes de bug bounty actifs.
- Durcir l’infrastructure en production (WAF, détections comportementales, monitoring en temps réel).
- Limiter les informations sensibles dans les dépôts publics (configurations, clés, chemins d’accès).
- Accélérer la gestion des vulnérabilités et la capacité à patcher à grande échelle.
- Explorer des mécanismes juridiques et techniques (licences, obfuscation, contrôles d’accès) pour retarder l’exploration automatisée malveillante — sans illusion d’éliminer totalement le risque.
Conclusion
La décision de Cal illustre une tension nouvelle entre ouverture et sécurité à l’ère des IA d’analyse de code. Plutôt qu’un simple débat idéologique, il s’agit d’un arbitrage pratique : protéger des données sensibles et la confiance des clients ou exposer le code pour accélérer l’innovation collective. À court terme, on peut s’attendre à davantage d’hybridations — versions communautaires limitées, code critique fermé, et accent sur la sécurité — jusqu’à ce que des solutions techniques, opérationnelles ou réglementaires réduisent le risque posé par l’exploration automatisée des sources.
Ressources et suite
Source principale (à mentionner obligatoirement) : https://www.zdnet.com/article/ai-security-worries-force-company-to-abandon-open-source/
Call to action : Lire l’article source et partagez votre avis : « Pensez‑vous que l’open source doit s’adapter ou rester la règle ? »
