Open source, open core ou propriétaire : le choix de licence qui dessine votre business model autant que votre code

Un fondateur technique nous a récemment demandé s’il « devait passer en open source pour attirer des développeurs ». La vraie question n’était pas là. Ce qu’il s’apprêtait à décider, c’était sa stratégie de distribution, son pricing et sa défensibilité — pour les cinq prochaines années.

Le choix de licence est traité comme une case à cocher au moment de créer le dépôt Git. En réalité, c’est l’une des rares décisions produit qui verrouille simultanément trois dimensions : comment vous acquérez vos utilisateurs, comment vous facturez, et ce qui empêche un concurrent de vous copier. La renverser plus tard coûte cher — parfois un relicensing juridiquement risqué, souvent une communauté qui se sent trahie.

Le malentendu de départ : l’open source n’est pas un canal marketing

La plupart des fondateurs abordent l’open source par l’angle de la visibilité : « on va publier le code, avoir des étoiles sur GitHub, et les leads suivront ». Cette lecture confond la conséquence avec la cause.

L’open source fonctionne comme moteur d’acquisition quand votre produit s’adresse à des développeurs qui installent et évaluent eux-mêmes avant d’acheter. C’est le pattern de Sentry, de Supabase ou de PostHog : le développeur teste en local, adopte, puis son entreprise paie pour la version hébergée ou les fonctionnalités d’équipe. Le code ouvert réduit la friction d’adoption à quasi zéro, et transforme la confiance technique en pipeline commercial.

Mais si votre acheteur n’est pas celui qui lit le code — un directeur marketing, un responsable RH, un dirigeant de PME — publier votre dépôt ne génère aucune traction. Vous récoltez quelques contributions de convenance et vous exposez votre logique métier à la concurrence sans contrepartie commerciale. Beaucoup de startups B2B « verticales » se sont ouvertes par mimétisme, puis ont constaté que leur cœur de cible ne savait même pas ce qu’était un pull request.

La première question n’est donc pas « faut-il ouvrir le code ? » mais « qui prend la décision d’adoption, et lit-il le code pour se rassurer ? ». Si la réponse est non, l’open source ne vous achètera pas de croissance.

Open core : la ligne de découpe est une décision de pricing déguisée

L’open core — un cœur ouvert, des fonctionnalités payantes autour — est aujourd’hui le modèle dominant chez les startups d’infrastructure. Séduisant, mais piégeux : la frontière entre ce que vous donnez et ce que vous faites payer est votre pricing. Et la plupart des équipes la dessinent sur des critères techniques alors qu’elle est fondamentalement commerciale.

Le piège classique consiste à ouvrir la fonctionnalité qui crée la valeur et à faire payer ce qui est cosmétique. Résultat : les utilisateurs restent sur la version gratuite indéfiniment, l’open source cannibalise le payant, et le taux de conversion vers l’offre commerciale s’effondre. À l’inverse, brider trop le cœur ouvert tue l’effet d’adoption qui justifiait l’ouverture au départ.

La ligne de découpe qui tient dans la durée suit une logique reconnaissable : le cœur ouvert sert l’usage individuel ou de petite équipe, le payant capture les besoins d’organisation — contrôle d’accès, audit, conformité, SSO, support avec engagement de niveau de service. Ce sont précisément les fonctionnalités que le développeur individuel ne valorise pas mais que son employeur doit acheter. Vous ne bridez pas la valeur, vous facturez le passage à l’échelle et la responsabilité.

Cette décision a une conséquence d’architecture directe et souvent sous-estimée : si votre code ouvert et vos fonctionnalités propriétaires ne sont pas séparés proprement dès le départ, vous vous retrouverez à démêler des modules entremêlés au pire moment — quand un contributeur externe touche par accident à du code que vous vouliez garder fermé, ou quand vous devez publier une release sans révéler votre logique de facturation. La ligne commerciale doit exister dans votre organisation du code avant d’exister dans votre grille tarifaire.

Le risque hyperscaler et les licences « source-available »

Une peur revient systématiquement : « et si un grand cloud prend mon code open source, le propose en managé, et me tue ? ». Le scénario est réel — c’est ce qui a poussé Elastic, MongoDB, HashiCorp et Redis à quitter les licences open source classiques pour des licences dites source-available (BSL, SSPL, Elastic License).

Ces licences laissent voir et modifier le code, mais interdisent de le revendre en service concurrent. Le compromis est clair : vous protégez votre marché contre les hyperscalers, mais vous perdez le label « open source » officiel et une partie de la bonne volonté communautaire. Pour une startup française early-stage, cette menace est le plus souvent hypothétique : vous n’avez pas encore le volume qui rendrait votre projet assez attractif pour qu’un cloud majeur le fork. Se protéger contre un risque de série C alors qu’on cherche encore son product-market-fit, c’est optimiser le mauvais problème.

Le conseil pragmatique : démarrez avec une vraie licence open source permissive (Apache 2.0, MIT) si l’adoption est votre priorité absolue, et gardez la bascule vers une licence source-available comme option pour plus tard. Attention toutefois — relicencier n’est trivial que si vous détenez tous les droits sur le code. Faites signer un accord de cession de droits (CLA) à vos contributeurs dès le premier jour. C’est la précaution la plus négligée et la plus difficile à rattraper : sans elle, vous ne pourrez jamais changer de licence sans le consentement de chaque contributeur.

Le propriétaire n’est pas un aveu de faiblesse

Dans l’écosystème tech, ouvrir son code est devenu une posture presque morale, au point que garder son produit fermé passerait pour de l’archaïsme. C’est une erreur de lecture. La grande majorité des startups SaaS à succès sont entièrement propriétaires, et pour de bonnes raisons.

Si votre valeur réside dans l’expérience, dans une donnée propriétaire, dans une intégration métier fine ou dans une motion de vente pilotée par des commerciaux, l’ouverture du code ne vous apporte rien et vous coûte du temps de maintenance communautaire que vous n’avez pas. Gérer une communauté open source est un métier à part entière : triage des issues, revue des contributions, gouvernance, documentation publique. Pour une équipe de cinq personnes qui court après ses premiers clients, c’est une distraction déguisée en stratégie.

Le propriétaire est aussi le choix par défaut le plus honnête quand on ne sait pas encore pourquoi on ouvrirait. Une startup qui n’a pas de thèse claire sur ce que l’ouverture lui rapporte — adoption bottom-up, confiance sur un composant critique, effet réseau de contributions — n’a rien à ouvrir. Le doute, ici, penche vers le fermé.

Ce qu’il faut vraiment décider, selon votre stade

En pré-seed, tranchez d’abord la question de l’acheteur. Si votre utilisateur est un développeur qui évalue en autonomie, l’open source ou l’open core est un accélérateur d’adoption qui vaut l’investissement, avec une licence permissive et un CLA en place immédiatement. Si votre acheteur est non-technique, restez propriétaire et concentrez vos forces sur la vente et le produit.

En seed, si vous avez ouvert, la priorité devient la ligne de découpe open/payant : validez qu’elle convertit réellement avant d’empiler des fonctionnalités. Un cœur ouvert massivement adopté avec un taux de conversion nul vers le payant n’est pas un succès, c’est un coût d’infrastructure que vous offrez gratuitement.

À l’approche de la série A, la question du risque concurrentiel et de la défensibilité mérite enfin d’être posée sérieusement. C’est le moment d’évaluer une bascule vers une licence source-available si votre traction attire l’attention, et de vous assurer que votre séparation code ouvert / code fermé est propre au niveau architecture. Un investisseur en due diligence technique regardera précisément cette frontière : elle raconte si votre avantage est protégé ou offert au premier venu.

Le vrai fil conducteur, à chaque stade, reste le même : le code que vous ouvrez est le code que vous ne facturez pas. Quelle partie de votre valeur êtes-vous prêt à donner pour gagner en distribution — et de quelle partie avez-vous besoin pour survivre commercialement ? Répondez à cette question avant de toucher au fichier LICENSE.