La technologie doit-elle être ouverte ou fermée ? Approches pour maximiser la valeur de l'entreprise et l'utilité sociale

Introduction

Avec l'open source et autres approches, la publication de technologies développées en interne peut permettre une adoption rapide sur une courte période, mais elle entraîne également l'émergence de nombreux concurrents proposant des services similaires. Une prise de décision appropriée peut favoriser l'expansion de vos propres services, mais comment devriez-vous procéder pour bien juger ?

Du point de vue de la société, il est plus avantageux que les nouvelles technologies soient rendues publiques, car cela est utile pour de nombreux ingénieurs et chercheurs. Cependant, si les inventeurs ne tirent aucun profit de la publication de leur technologie, l'incitation à inventer diminue, ce qui peut paradoxalement rendre l'innovation moins probable.

Ici, nous organisons le degré de publication des technologies en 9 niveaux, allant du « complètement ouvert » au « complètement fermé », et nous résumons les cas de succès et d'échec pour chaque niveau. Nous présentons ensuite les principes pour maximiser la valeur d'entreprise et l'utilité sociale, en nous appuyant sur les dernières recherches académiques et les connaissances des praticiens.

Le degré de publication des technologies est déterminé par deux axes : la « divulgation » et la « licence »

Tout d'abord, à titre préalable, le degré de publication des technologies ne repose en fait pas sur un seul axe, mais sur deux.

L'axe de divulgation : jusqu'à quel point révéler le contenu de la technologie Il s'agit du degré de divulgation d'informations, c'est-à-dire si le code source et les spécifications techniques sont rendus publics, si seul le comportement est montré, ou si tout est gardé secret.

L'axe de licence : jusqu'à quel point autoriser l'utilisation Il s'agit du degré de droits d'utilisation, c'est-à-dire si l'utilisation commerciale, la modification, la redistribution et la commercialisation de services concurrents sont autorisées, si elle est limitée aux usages non commerciaux, ou si seule votre entreprise est autorisée à la mettre en œuvre.

Par exemple, un brevet divulgue complètement le contenu technique (publié 18 mois après le dépôt), mais en monopolise l'exercice pendant environ 20 ans. C'est donc une combinaison de « divulgation maximale, licence minimale ». Les 9 niveaux ci-après sont ordonnés par « degré de publication » selon ces deux axes.

9 niveaux de degré de publication des technologies

Niveau 1 : Complètement ouvert

Description : Licences CC0, Unlicense (renonciation aux droits), ainsi que licences permissives comme MIT, Apache 2.0 et BSD. Le code source est rendu public et l'utilisation commerciale, la modification, la redistribution et l'intégration dans des produits fermés sont autorisées de manière quasi inconditionnelle (seule l'attribution est requise). Apache 2.0 est particulièrement adapté à l'utilisation en entreprise car il comprend une concession explicite de licence de brevet.

Conditions d'utilisation : Attribution minimale (maintien de l'avis de droit d'auteur). Il est libre d'intégrer la version modifiée, restée non publique, dans des produits commerciaux.

Objectif typique : Maximiser l'adoption et la normalisation de facto. Les technologies périphériques (SDK, formats de données, connecteurs) qui pourraient être intégrées sont rendues publiques pour élargir l'écosystème.

Cas de succès : Android (AOSP) a ouvert le système d'exploitation avec Apache 2.0 et a élargi l'ensemble du marché des smartphones, tandis que Google s'est concentré sur la récupération via des couches fermées (Play Store, publicités, licence GMS). React, VS Code et Kubernetes se sont également diffusés via des licences permissives et ont orienté la valeur vers le cœur de métier de chaque entreprise (cloud, recrutement, plateforme).

Cas d'échec : 1. Docker a rendu public la technologie des conteneurs avec une licence permissive et est devenu un standard de l'industrie en tant que technologie. Cependant, comme la technologie clé a été complètement ouverte, la majeure partie de la valeur s'est concentrée sur Kubernetes (dirigé par Google) et les services gérés des fournisseurs de cloud. Docker lui-même n'a pas réussi à monétiser ses services. En 2019, l'entreprise a vendu sa division Entreprise à Mirantis. C'est un exemple crucial montrant que « succès technologique » et « succès commercial » sont deux choses différentes. 2. OpenSSL, dont dépend la majorité du chiffrement des communications sur Internet, fonctionnait avec une extrême pénurie de ressources au moment de la découverte de la faille critique « Heartbleed » en 2014 : un seul développeur à temps plein et environ 2 000 dollars de dons annuels. Les biens publics dont tout le monde peut faire usage gratuitement incarnent le problème classique du passager clandestin, où personne ne supporte les frais. Cela a marqué le point de départ de recherches sérieuses sur la durabilité de l'open source (Eghbal, 2020).

Niveau 2 : Copyleft faible

Description : Les licences qui obligent à rendre public les fichiers ou les portions de bibliothèque modifiés, mais permettent que le produit global combiné reste fermé. C'est une position intermédiaire.

Conditions d'utilisation : Si la partie concernée est rendue publique, l'intégration dans un produit commercial fermé est possible.

Objectif typique : Compromis pour les cas où vous souhaitez que les améliorations soient restituées, mais sans entraver l'intégration commerciale. Convient aux bibliothèques et composants.

Cas de succès : Firefox (MPL) a établi une alternative pour contrer le monopole sur le marché des navigateurs. Les diverses bibliothèques LGPL (comme glibc) se sont largement intégrées aux logiciels commerciaux et sont devenues une base commune de facto.

Cas d'échec : Symbian, le système d'exploitation pour smartphone dirigé par Nokia, a été entièrement libéré sous EPL (copyleft faible) en février 2010 après être devenu désavantageux face à Android et iOS. Cependant, en novembre de la même année, la Fondation Symbian a annoncé la cessation de ses activités, et Nokia elle-même a arrêté la fourniture d'open source en 2011. Cela montre que l'ouverture après une perte de compétitivité n'offre pas de raison à un participant à l'écosystème d'investir. L'ouverture doit être « une initiative offensive » et non « une gestion de la défaite ».

Niveau 3 : Copyleft fort

Description : Licences obligeant à la divulgation du code source intégral de toute œuvre dérivée. Elles empêchent que les concurrents ne s'approprient secrètement les améliorations dans des produits fermés.

Conditions d'utilisation : L'utilisation commerciale est libre, mais si un produit contenant du code GPL est distribué, l'intégralité du code source doit être rendue publique.

Objectif typique : Prévention du parasitisme et restitution des améliorations à la communauté. Utilisée pour les projets dirigés par la communauté ou comme base d'une double licence (coexistence d'une version GPL et d'une version commerciale).

Cas de succès : Linux (GPLv2) est l'open source le plus réussi de l'histoire et s'est imposé comme base des serveurs, du cloud et de l'informatique intégrée. Red Hat, qui a monétisé par l'assistance aux distributions Linux, a été acquise par IBM pour environ 34 milliards de dollars en 2019, réalisant l'une des plus grandes valeurs d'entreprise jamais atteintes pour une société d'open source. QGIS (GPL) a également remporté une part de marché comparable aux logiciels commerciaux dans le domaine des systèmes d'information géographique.

Cas d'échec : Après son acquisition par Oracle, la communauté OpenOffice.org, méfiante envers la politique de gestion, a créé un fork et lancé LibreOffice en 2010. La majorité des développeurs et des utilisateurs ont migré. Cela montre que même si la licence est ouverte, si une seule entreprise monopolise la gouvernance et perd la confiance de la communauté, elle perd le contrôle du projet lui-même.

Niveau 4 : Copyleft réseau

Description : Licences qui étendent l'obligation de divulgation du GPL aux services fournis via réseau (SaaS). Elles empêchent les fournisseurs de services cloud de fournir secrètement des versions modifiées. C'est la licence d'open source approuvée par l'OSI la plus défensive.

Conditions d'utilisation : Si le code AGPL est utilisé pour fournir un service, la divulgation du code source comprenant les parties modifiées est requise. Les entreprises qui veulent éviter cela vendent une licence commerciale, ce qui s'inscrit dans une stratégie de « double licence ».

Objectif typique : Maintenir la transparence du code tout en dissuadant la revente par les géants du cloud et en dirigeant les revenus vers les licences commerciales.

Cas de succès : Grafana, MongoDB (initialement), Nextcloud et autres l'ont adopté. Redis est revenu à l'open source sous AGPLv3 en mai 2025 (Redis 8) suite aux critiques de sa dé-standardisation en 2024. L'AGPL est réévalué comme une solution pratique pour « s'ouvrir tout en se protéger ».

Cas d'échec : MongoDB a longtemps adopté l'AGPL, mais a décidé qu'elle ne suffisait pas à empêcher la fourniture commerciale par les fournisseurs de services cloud et est passée à la licence SSPL plus restrictive en 2018. Cependant, l'année suivante en 2019, AWS a lancé « DocumentDB », une implémentation propriétaire compatible avec l'API MongoDB. Cela a montré que même si une licence peut restreindre la copie de code, elle ne peut pas restreindre les implémentations compatibles du protocole ou de l'API (développement en room blanc), révélant la limite structurelle de la protection par licence.

Niveau 5 : Divulgation du code source avec restriction de la concurrence

Description : Le code source peut être lu, modifié et utilisé dans de nombreux usages, mais la « fourniture en tant que service concurrent » est explicitement interdite. Ce n'est pas de l'open source selon la définition de l'OSI. La BSL (Business Source License) a une structure temporelle : elle devient automatiquement open source après une certaine période (4 ans maximum).

Conditions d'utilisation : L'utilisation interne et la développement sont largement possibles, mais la fourniture du logiciel lui-même comme service commercial à des tiers est interdite (ou nécessite un contrat de licence commerciale).

Objectif typique : Maintenir la transparence et la liberté d'auto-hébergement tout en protégeant les revenus contre la « revente gratuite » par les fournisseurs de services cloud.

Cas de succès : MariaDB (l'inventeur de BSL), Sentry, CockroachDB et autres l'ont adoptée et maintiennent leur activité. MongoDB a maintenu une évaluation élevée sur le marché boursier après le passage à SSPL, montrant certains résultats dans la protection des revenus.

Cas d'échec : HashiCorp a changé Terraform de MPL à BSL en août 2023, mais seulement deux semaines plus tard, la communauté a créé un fork avec OpenTofu, qui a connu une croissance rapide sous la Linux Foundation (38 % des utilisateurs envisageaient un changement selon les enquêtes). Redis a également connu un fork de Valkey une semaine après le passage à SSPL en mars 2024 et, face aux critiques, est revenu à l'AGPL en mai 2025. De plus, comme SSPL n'est pas approuvé par l'OSI, il a été supprimé des principales distributions comme Debian et Fedora, entraînant la perte des canaux de distribution eux-mêmes. La recherche académique montre que ces forks forment une communauté organisée avec une plus grande diversité que le projet d'origine (arXiv:2411.04739, 2024). Cela révèle que « refermer ce qui a été ouvert » est légalement possible, mais c'est une décision à très haut risque qui endommage l'atout que représente la communauté.

Niveau 6 : Publication non commerciale avec conditions

Description : Le code source ou les modèles sont rendus publics, mais leur utilisation est limitée à des fins non commerciales ou de recherche, ou des conditions individuelles sont imposées en fonction du volume ou de l'usage (CC BY-NC, licences à usage de recherche uniquement, « licences communautaires » propriétaires pour les modèles d'IA, etc.).

Conditions d'utilisation : Les particuliers et chercheurs peuvent utiliser librement, mais l'utilisation commerciale nécessite des contrats individuels ou le respect de conditions.

Objectif typique : S'ouvrir aux chercheurs et développeurs indépendants pour acquérir une réputation, des retours et un écosystème, tout en dirigeant l'ensemble de l'utilisation commerciale vers une facturation.

Cas de succès : La série Llama de Meta a construit rapidement un écosystème pour contrer le modèle de fourniture d'API fermé grâce à sa stratégie « d'open weight » (divulgation des poids avec utilisation conditionnelle). Dans les logiciels académiques, le modèle de suivi « recherche gratuite / commercial payant » fonctionne aussi comme source de revenus durable.

Cas d'échec : Le LLaMA original était distribué sous conditions (accès limité aux chercheurs par demande), mais ses poids ont été divulgués sur 4chan seulement une semaine après son lancement, devenant téléchargeables par tous. Cette expérience a montré qu'une distribution conditionnelle ne peut pas être techniquement appliquée, ce qui a conduit Meta à changer de stratégie. Avec Llama 2 (juillet 2023), l'entreprise a opté pour une distribution large dès le départ, avec une « Community License » permettant l'utilisation commerciale. La stratégie d'open-weight actuelle de Llama elle-même est née de l'échec d'une application stricte de niveau 6 (usage recherche uniquement). Or, même Llama conserve ses propres conditions, comme « les entreprises ayant plus de 700 millions d'utilisateurs actifs mensuels doivent signer un contrat séparé ». Cette complexité contractuelle elle-même constitue un obstacle à l'adoption, et les équipes juridiques d'entreprises préfèrent les alternatives Apache 2.0 comme Mistral ou Qwen.

Niveau 7 : Brevets

Explication : Il s'agit d'un système où le contenu technique est entièrement divulgué en échange d'un droit d'exploitation exclusif d'environ 20 ans. Après l'expiration du délai, tout le monde peut utiliser librement la technologie. On peut voir cette structure comme un système où le contenu devient obligatoirement ouvert après une certaine période.

Conditions d'utilisation : Une autorisation du titulaire du brevet (contrat de licence) est nécessaire. Les brevets essentiels aux normes sont soumis à l'obligation d'octroyer des licences selon les conditions FRAND (justes, raisonnables et non discriminatoires).

Objectifs typiques : La protection des technologies faciles à découvrir par rétro-ingénierie (mécanismes visibles, procédés de fabrication, algorithmes). Le principe est : « Ce qui peut être découvert par analyse, il vaut mieux le divulguer publiquement et le protéger légalement ». Cela s'applique aussi aux brevets défensifs, aux licences croisées et aux revenus de licences.

Cas de succès : Qualcomm a construit ses activités de licence basées sur les brevets essentiels aux normes des télécommunications. L'industrie pharmaceutique est l'exemple type d'un modèle où l'investissement massif en R&D est rentabilisé par le monopole de période assuré par les brevets (Arora et al., 2001).

Cas d'échec : Kodak possédait un portefeuille d'environ 1 100 brevets incluant les brevets fondamentaux des appareils photo numériques, évalué entre 2,2 et 2,6 milliards de dollars avant la faillite. Après sa vente suite à la faillite en 2012, le prix obtenu était seulement de 525 millions de dollars. Cela montre que même si on divulgue et monopolise une technologie par brevets, si on perd les actifs complémentaires – manufacture, vente, marque – et le modèle commercial, la valeur des brevets s'effondre elle aussi. C'est un exemple concret de la proposition théorisée par Teece (1986) selon laquelle « les profits de l'innovation vont à ceux qui possèdent les actifs complémentaires ».

Niveau 8 : Code fermé + API

Explication : Le code source reste non public, mais les fonctionnalités sont fournies sous forme de produit, d'API ou de SaaS. L'implémentation interne n'est pas exposée, mais l'utilisation est largement autorisée.

Conditions d'utilisation : Utilisation dans les limites des conditions d'utilisation et du contrat API. L'accès à l'implémentation et sa modification ne sont pas autorisés.

Objectifs typiques : Garder secret l'implémentation et les données tout en maximisant les utilisateurs et les revenus. C'est la forme adoptée par la plupart des logiciels commerciaux et des modèles d'IA fournis par API.

Cas de succès : Les modèles fournis par API d'OpenAI et Anthropic, les SaaS comme Salesforce, iOS d'Apple (le cœur est non public mais le SDK est ouvert aux développeurs), etc. C'est le modèle dominant des activités logicielles à hauts revenus modernes.

Cas d'échec : Dans la guerre des normes de magnétoscopes domestiques, Sony a été réticente à accorder des licences pour le Betamax, tandis que JVC a largement accordé des licences VHS pour élargir le camp, et a remporté le marché (Cusumano et al., 1992). C'est un cas classique où la différence d'« ouverture » plutôt que la supériorité technique détermine le résultat de la bataille normative, montrant que dans les marchés où les effets de réseau jouent, la fermeture peut être le risque le plus grave.

Niveau 9 : Entièrement fermé

Explication : Aucune divulgation ni dépôt : la technologie est gérée comme un secret. Tant que le secret est préservé, la période de protection est illimitée, créant un échange inverse avec le système de brevets.

Conditions d'utilisation : Seule l'entreprise en assure l'exploitation. La protection légale dépend d'un régime de gestion du secret (NDA, contrôles d'accès, etc.).

Objectifs typiques : Protéger indéfiniment ce qui est difficile à découvrir par rétro-ingénierie (logique côté serveur, données d'entraînement, secrets de fabrication, données clients).

Cas de succès : La recette du sirop de Coca-Cola (gardée secrète depuis plus de 130 ans) et l'algorithme de classement de recherche de Google en sont les exemples typiques. Plutôt que d'expirer après 20 ans s'ils étaient brevés, ils deviennent un avantage illimité en tant que secrets commerciaux.

Cas d'échec : Les secrets commerciaux bénéficient d'une protection illimitée mais restent vulnérables aux fuites. Le procès alléguant qu'un ancien cadre de Waymo a apporté les secrets commerciaux de la technologie de conduite autonome à Uber s'est conclu par un règlement en actions d'une valeur d'environ 245 millions de dollars (2018). La stratégie de secret commercial ne fonctionne que si elle est associée à un investissement continu dans les systèmes de gestion des secrets – rétention des talents, contrôles d'accès, contrats – plutôt que dans la technologie elle-même.

Un cadre de pensée pour maximiser la valeur des services et entreprises

Quelles parties doivent être ouvertes et lesquelles fermées ? La valeur d'une entreprise dépend globalement de trois facteurs : « croissance du marché et des revenus × défensibilité des profits (moat) × efficacité du capital ». La stratégie d'ouverture agit sur ces trois dimensions.

Un seul principe sert de point de départ : « Fermer ce que l'on vend (biens rivaux) et ouvrir ce qui encourage son utilisation (biens complémentaires) ». Plus les biens complémentaires deviennent gratuits ou bon marché, plus la demande du produit principal (source de revenus) augmente. En ouvrant volontairement la couche adjacente à la source de revenus pour élargir le marché global et récupérer au cœur du business, on applique ce que les praticiens appellent « commoditisation des biens complémentaires » (Spolsky, 2002). Cette logique sous-tend le modèle d'Android de Google, distribué gratuitement mais monétisé via la publicité et les applications. Ce qui suit concrétise ce principe en « quoi ouvrir et quoi fermer ».

Ce qui doit être ouvert

Les couches qui créent une adoption et une normalisation sans menacer votre source de revenus doivent être ouvertes. Voici les exemples :

• Fonctionnalités et moteurs centraux : Les parties que beaucoup utilisent et qui ont un sens à devenir normes.

  • Chromium (Google) : Le moteur navigateur lui-même est ouvert. Il est devenu la base commune de Chrome, Edge et Brave, donnant à Google la mainmise sur les standards Web.

  • GitLab Community Edition : Tout le kit Git, CI/CD peut être déployé gratuitement sur votre propre serveur.

  • PostgreSQL / Elasticsearch / Docker Engine : Les « moteurs standards » de BD, recherche, conteneurs.

  • PyTorch (Meta) : Devenu la base commune du machine learning, attirant chercheurs et ingénieurs, alimentant la capacité d'IA de Meta en retour.

• Formats de fichiers, protocoles et spécifications API : D'autres outils se branchent sur le vôtre.

  • PDF (Adobe) : Spécifications publiées et normalisées ISO. En le rendant lisible par tous, Adobe en fit le standard de facto des documents.

  • S3 API (Amazon) : La spécification de l'API de stockage est devenue de facto, créant une dynamique où les concurrents se nomment « S3-compatible » pour s'adapter.

  • Spécification OpenAI API : Beaucoup de LLM implémentent maintenant « compatible OpenAI API » au point de la normaliser.

  • IFC : Norme internationale pour BIM.

• SDK, connecteurs, parties d'intégration : Biens complémentaires. Plus il y en a, plus on utilise le produit principal.

  • SDKs Stripe : Des bibliothèques multilingues gratuites permettant d'intégrer le paiement en quelques lignes, attirant les développeurs en masse.

  • SDKs et API Slack / Twilio : Des bibliothèques officielles permettent à des applications externes de se connecter, élargissant l'écosystème.

  • Providers Terraform : Ouvrir les connecteurs de connexion avec chaque cloud, augmentant la valeur du produit principal à chaque nouveau support.

• Fonctionnalités de base pour individus et développeurs : Gratuit pour élargir la base d'utilisateurs.

  • Plans gratuits de GitHub / Notion / Figma / Slack : Les individus accèdent gratuitement, on facture les fonctionnalités équipe/entreprise (freemium).

  • Docker Desktop : Gratuit pour les particuliers et petites structures, payant au-delà d'une certaine taille.

  • Version académique gratuite de Gurobi : Les étudiants habitués au logiciel deviennent ses promoteurs chez leur employeur.

Les bénéfices incluent :

• Réduction drastique du coût d'acquisition client : Les développeurs déploient et diffusent par eux-mêmes sans intervention commerciale, réalisant la même croissance à coût réduit et améliorant l'efficacité du capital (à la source des valorisations boursières élevées des entreprises open-core comme GitLab, HashiCorp, Confluent).

• Normalisation de facto et moat par effets de réseau : Un type de barrière à l'entrée qu'on ne peut pas construire avec du code fermé (Kubernetes, Linux).

• Suppression du risque de verrouillage : En levant la crainte du verrouillage chez un fournisseur spécifique, on réduit les barrières à l'adoption des grandes entreprises et secteur public.

• Marque d'employeur et effet de levier R&D par contribution externe : La recherche montre que les entreprises qui non seulement « utilisent » les OSS mais y « contribuent » tirent une productivité plus élevée de ces OSS (Nagle, 2018, 2019).

Ce qui doit être fermé

La source même des revenus et le cœur de l'avantage concurrentiel doivent rester fermés. Voici les exemples :

• La source de revenus elle-même (gestion, hébergement) : Si votre cœur de métier est de vendre le service, ne l'ouvrez pas.

  • GitLab.com / MongoDB Atlas / Databricks : Le logiciel peut être ouvert, mais « gérer et exploiter le service » reste entièrement propriétaire. Le pilier des revenus de MongoDB est Atlas, jamais ouvert à personne. WordPress.com (Automattic) : Le produit peut être auto-hébergé gratuitement, mais l'hébergement + maintenance reste fermé.

  • WordPress.com (Automattic) : Le produit peut être auto-hébergé gratuitement, mais l'hébergement + maintenance reste fermé.

  • Abonnement Red Hat Enterprise Linux : Même si Linux est sous GPL, Red Hat facture un « bundle opérationnel » : builds certifiés, support long terme, garanties.

• Fonctionnalités pour organisations et entreprises (SSO, gestion des droits, audits, conformité, support/SLA) : Faciles techniquement, mais demandés par « celui qui paie ». C'est là qu'on facture.

  • GitLab Enterprise Edition : SAML/SSO, gestion granulaire des droits, audit, conformité sont exclusifs à la version payante. Manuel du découpage open-core.

  • Mattermost / Sentry : Cœur ouvert, SSO, droits avancés et audit à la version entreprise. Cette pratique est si établie que l'industrie l'appelle « SSO tax » (sso.tax publie même une liste des entreprises et leurs tarifs SSO).

  • Grafana Enterprise : Produit sous AGPL, mais connexions de sources de données entreprise, rapports et SLA de support facturés.

• Logique métier centrale où l'avantage concurrentiel réside dans le code lui-même : Les parties où la divulgation rend la copie directe possible.

  • Algorithme de classement de recherche Google : Chromium et Android s'ouvrent, mais la logique décidant du classement des résultats de recherche – le cœur du métier – reste complètement fermée.

  • Moteur de recommandation Netflix : Beaucoup d'outils d'infra deviennent OSS (Chaos Monkey, etc.), mais la logique de recommandation de visionnage reste secrète.

  • Algorithme de trading haute fréquence : Divulguer = perte immédiate d'avantage, donc secret complet.

• Données propriétaires, modèles entraînés, savoir-faire opérationnel et base de clients : « actifs complémentaires » difficiles à imiter.

  • Poids des modèles frontières d'OpenAI / Anthropic et données d'entraînement : accessibles via API, mais le modèle lui-même et le pipeline d'entraînement restent confidentiels (combinaison des niveaux 8 et 9).

  • Données cartographiques et de trafic de Google Maps : l'API est ouverte, mais les données accumulées sur 20 ans ne sont jamais cédées.

  • Données d'achat et base d'avis d'Amazon : actif complémentaire le plus difficile à imiter, renforcé par les effets de réseau.

  • Données financières et réseau d'utilisateurs terminaux de Bloomberg : la combinaison données + base clients ne peut être rattrapée par la simple imitation de fonctionnalités.

Liste de vérification pour la décision ouvert/fermé

Pour chaque fonctionnalité, il est possible de trancher en répondant aux 5 questions suivantes.

1. Test de défense : est-ce la source de notre avantage ? → Fermer

2. Test de diffusion : l'ouverture augmente-t-elle les utilisateurs et les partenaires ? → Ouvrir

3. Test de responsabilité : une erreur pourrait-elle créer une responsabilité légale ou professionnelle ? → Fermer

4. Test de l'acheteur : est-ce une fonctionnalité que celui qui paie demande (SSO, journaux d'audit, support, SLA) ? → Fermer

5. Test de revente : si publié, les concurrents ou les géants du cloud pourraient-ils simplement le revendre ? → Fermer (ou protéger par une licence défensive comme l'AGPL/BSL)

Le principe est de fermer si au moins un critère (défense, responsabilité, acheteur, revente) s'applique, et d'ouvrir si seul le critère de diffusion s'applique.

Quel degré d'ouverture est optimal pour la société ?

Jusqu'à présent, nous avons discuté du degré d'ouverture nécessaire pour maximiser la valeur de l'entreprise. Mais qu'en est-il de la société dans son ensemble : la technologie devrait-elle être ouverte ou fermée ?

En conclusion, la solution optimale pour la société n'est ni complètement ouverte ni complètement fermée, mais un mélange intentionnellement géré qui reconnaît une fermeture temporaire tout en retournant à l'ouverture à terme, et lorsque ce cadre fonctionne, la maximisation du profit de l'entreprise s'aligne sur la maximisation du bénéfice social.

• Le prix idéal de la connaissance est « zéro », mais personne ne la créerait alors : la connaissance et la technologie possèdent la nature d'un « bien public » : une fois créées, elles peuvent être utilisées par n'importe qui avec un coût marginal quasi nul (Arrow, 1962). Si on ne considère que cette propriété, l'optimum social serait une ouverture totale et gratuite. Mais cela empêcherait les développeurs de récupérer leurs investissements, et l'innovation n'émergerait pas. Il existe un arbitrage structurel entre « l'utilisation maximale de la technologie créée (efficacité statique) » et « la préservation de l'incitation à créer la prochaine technologie (efficacité dynamique) » (Nordhaus, 1969).

• Le système de brevets est un « marché » de la société face à ce dilemme : la société résout ce dilemme par un échange : « nous reconnaissons le monopole pendant une période limitée, à condition que le contenu technique soit entièrement divulgué et qu'il devienne accessible à tous après l'expiration ». Tel est le système de brevets. La période de protection d'environ 20 ans a été conçue comme le point d'équilibre entre les méfaits du monopole et les incitations à innover, et la loi antitrust agit comme un mécanisme de correction lorsque cet équilibre penche trop vers le « monopole perpétuel d'une seule entreprise ». En d'autres termes, parmi les 9 niveaux énumérés dans cet article, on peut dire que la société a établi comme compromise fondamental au niveau institutionnel le « niveau 7 (divulgation avec monopole temporaire) ».

• La « maximisation du profit = optimum social » ne va pas de soi : ce mécanisme n'est qu'un « second meilleur » arrangement, et sans intervention, le choix des entreprises s'écarte de l'optimum social dans deux directions. Premièrement, les entreprises n'ouvrent pas assez. Beaucoup des bénéfices de la divulgation (les effets de spillover de la connaissance) ne sont pas capturés par l'entreprise qui divulgue, de sorte que le degré d'ouverture qu'une entreprise choisit volontairement est systématiquement inférieur au niveau socialement souhaitable. Deuxièmement, le monopole peut persister. L'hypothèse classique selon laquelle « la technologie s'érode et les profits disparaissent par la concurrence » ne tient pas sur les marchés numériques où les effets de réseau et les boucles d'autorenforcement des données opèrent, créant plutôt un « winner-take-all » où la domination se renforce avec le temps.

• La propriété intellectuelle plus forte n'est pas toujours meilleure : une protection trop forte peut avoir l'effet inverse. Puisque la technologie s'accumule sur les acquis du passé, accorder des droits trop forts aux inventeurs initiaux peut bloquer les innovations suivantes construites sur cette base (Scotchmer, 1991). La relation entre l'innovation et la force de la propriété intellectuelle n'est pas monotone, mais possède un optimum qui varie selon l'industrie (le contraste entre les brevets forts dans la pharmacie et les brevets potentiellement entravants dans les logiciels en est un exemple typique).

• La société différencie le degré d'ouverture selon les domaines : la conception au niveau de la société peut être résumée comme suit. La recherche fondamentale, où les effets de spillover sont importants et la propriété difficile à exercer, est fournie presque entièrement ouverte par le financement public et la publication de résultats. Le développement commercial, où l'appropriation est nécessaire à l'investissement, se voit accorder une fermeture temporaire et partielle par brevets ou secrets commerciaux. Et lorsque le monopole risque de se cristalliser, les lois antitrust, les obligations de divulgation et les limites des brevets, ainsi que la promotion de la normalisation et de l'interopérabilité ramènent le système vers l'ouverture.

• Le profit n'est pas l'unique moteur de l'innovation : enfin, le profit en monopole n'est pas le seul moteur de l'innovation. Comme le montrent les logiciels et sciences ouverts, la contribution aux biens publics et les bénéfices privés (apprentissage, réputation, carrière, amélioration des produits propres) peuvent coexister, comme l'ont montré la théorie et les preuves empiriques (von Hippel & von Krogh, 2003 ; Nagle, 2018), et des infrastructures sociales comme Linux et OpenSSL ont été créées indépendamment des profits de monopole. La société alimente l'innovation en combinant « les moteurs liés au profit » et « les autres moteurs (le désir d'utiliser soi-même, l'honneur et la réputation, le sens de la mission, la motivation d'apprentissage, etc.) ».

Tendances récentes de la recherche académique

La recherche sur les stratégies de divulgation de technologie progresse selon quatre grandes directions.

Quantification de la valeur économique des OSS

• La valeur côté demande est estimée à 8,8 billions de dollars : une équipe de recherche de Harvard Business School a estimé la valeur côté approvisionnement des OSS largement utilisés (coût de reconstruction) à 41,5 milliards de dollars et la valeur côté demande (dépenses que les entreprises auraient à consacrer au développement alternatif) à 8,8 billions de dollars. Sans les OSS, les dépenses logicielles des entreprises devraient être 3,5 fois plus élevées. De plus, 96 % de la valeur côté demande est créée par seulement 5 % des développeurs, révélant une extrême concentration dans la création de valeur (Hoffmann et al., 2024).

• La durabilité en tant que bien public est devenue une question politique : après OpenSSL/Heartbleed, la recherche s'est intensifiée sur « qui soutient les OSS fondamentaux sur lesquels toutes les industries dépendent », et la conception de mécanismes de financement par les entreprises et les gouvernements (Sovereign Tech Fund, etc.) est discutée tant dans la pratique que dans les politiques (Eghbal, 2020).

Stratégies de monétisation et conséquences des changements de licence

• Les études empiriques sur les changements de licence et les forks ont progressé : en examinant les changements de licence successifs de 2023-2025 (Terraform → OpenTofu, Redis → Valkey, Elasticsearch → OpenSearch), une recherche analysant la structure communautaire après les forks montre que les forks créés sous des fondations neutres (Linux Foundation, etc.) acquièrent une base de contributeurs avec une plus grande diversité organisationnelle que le projet d'origine (arXiv:2411.04739, 2024). C'est une validation empirique quantitative des risques de gouvernance des projets sous contrôle d'une seule entreprise.

• « Ouvert » et ses multiples sens : la théorie de l'ouverture partielle : West (2003) a théorisé comment les entreprises de plateforme adoptent une stratégie hybride « partiellement ouverte » entre l'ouverture totale et le monopole total, et Dahlander & Gann (2010) ont classé l'« ouverture » dans l'innovation ouverte selon deux dimensions : la direction (intra-muros/extra-muros) et le caractère monétaire (payant/gratuit), en quatre types. L'émergence récente de BSL/SSPL peut être interprétée comme un phénomène où l'espace de conception de cette « ouverture partielle » est encore davantage subdivisé par l'invention de licences.

Comportement de contribution des entreprises et productivité

• Les entreprises qui « contribuent » plutôt qu'elles ne « consomment » y gagnent : Nagle (2019) a montré empiriquement que parmi les entreprises utilisant des OSS, celles qui contribuent du code obtiennent une amélioration de productivité plus importante que celles qui ne le font pas, de la même source OSS (learning by contributing). Cette découverte, selon laquelle la contribution à un bien public sans compensation génère un retour privé, corrobore au niveau entreprise le « modèle d'innovation privée et collective » présenté par von Hippel & von Krogh (2003), où la contribution aux biens publics et la capture de bénéfices privés sont compatibles.

• Relation entre le degré d'ouverture de la plateforme et l'innovation : Boudreau (2010) a décomposé l'ouverture des plateformes en « octroi d'accès » et « délégation de contrôle », montrant que l'ouverture d'accès accroît fortement l'innovation, tandis que l'effet de la délégation du contrôle est limité. Non seulement « jusqu'où ouvrir », mais aussi « quoi ouvrir (l'accès ou le droit de contrôle) » détermine les résultats.

Nouveaux enjeux à l'ère de l'IA

• Émergence d'une nouvelle catégorie : les « poids ouverts » : dans les modèles d'IA, une nouvelle forme intermédiaire émerge : les « poids ouverts », où le code d'entraînement et les données restent confidentiels mais les poids du modèle sont publiés sous certaines conditions, ce qui sort du cadre de la définition traditionnelle des OSS, et la recherche sur ses effets économiques et sa sécurité avance rapidement. La dichotomie du code source (ouvert/fermé) est remplacée par une conception multi-couches d'ouverture (données, poids, code, API).

• L'utilisation de l'IA pour l'entraînement redéfinit la conception des licences : les controverses sur les droits d'auteur concernant l'utilisation des codes publics et contenus pour l'entraînement de l'IA deviennent, depuis 2024, une nouvelle motivation des changements de licence, et la validité des nouvelles conceptions de conditions telles que « ouvert aux humains mais fermé à l'entraînement de l'IA » est débattue tant en droit qu'en économie.

Conclusion

Nous avons organisé en 9 niveaux la question ouvert/fermé et synthétisé l'approche appropriée pour les entreprises et la société. En conclusion, pour maximiser la valeur de l'entreprise, la solution n'est ni complètement ouverte ni complètement fermée, mais une ouverture sélective (type open-core) : « ouvrir les couches qui créent la diffusion et la normalisation, fermer les sources de revenus, et protéger les couches ouvertes contre la revente par une licence défensive ».

Pour la société, la solution optimale est également un mélange intentionnellement géré qui reconnaît une fermeture temporaire et retourne à l'ouverture, et quand ce cadre fonctionne, la maximisation du profit de l'entreprise s'aligne sur la maximisation du bénéfice social.

Références bibliographiques

• Arora, A., Fosfuri, A., & Gambardella, A. (2001). Markets for technology: The economics of innovation and corporate strategy. MIT Press. (Ouvrage synthétisant les conditions d'émergence du « marché technologique » via brevets et licences, et l'impact de la divulgation et de l'échange de technologie sur la stratégie d'entreprise)

• arXiv:2411.04739. (2024). The new dynamics of open source: Relicensing, forks, & community impact.（Étude empirique portant sur 3 cas d'étude (Terraform/OpenTofu, Redis/Valkey, Elasticsearch/OpenSearch) montrant que les forks après changement de licence forment des communautés présentant une plus grande diversité organisationnelle que les projets d'origine）

• Boudreau, K. (2010). Open platform strategies and innovation: Granting access vs. devolving control. Management Science, 56(10), 1849-1872.（Article qui décompose l'ouverture de plateforme en « octroi d'accès » et « transfert de contrôle », et démontre les différences d'effets sur l'innovation）

• Casadesus-Masanell, R., & Ghemawat, P. (2006). Dynamic mixed duopoly: A model motivated by Linux vs. Windows. Management Science, 52(7), 1072-1084.（Étude théorique construisant un modèle dynamique de marché où les OSS gratuits et les logiciels commerciaux coexistent, analysant l'équilibre de concurrence mixte）

• Chesbrough, H. (2003). Open innovation: The new imperative for creating and profiting from technology. Harvard Business School Press.（Ouvrage qui a proposé le concept « d'innovation ouverte » permettant l'échange de connaissances au-delà des frontières de l'entreprise）

• Cusumano, M. A., Mylonadis, Y., & Rosenbloom, R. S. (1992). Strategic maneuvering and mass-market dynamics: The triumph of VHS over Beta. Business History Review, 66(1), 51-94.（Étude de cas classique analysant la guerre des normes VHS contre Betamax, montrant que le succès a été déterminé par la stratégie d'ouverture des licences et la formation d'alliances, plutôt que par la supériorité technique）

• Dahlander, L., & Gann, D. M. (2010). How open is innovation? Research Policy, 39(6), 699-709.（Article qui classifie « l'ouverture » de l'innovation selon deux axes (direction et monétarité) en 4 types, et en passe en revue les avantages et coûts de chaque forme）

• Eghbal, N. (2020). Working in public: The making and maintenance of open source software. Stripe Press.（Étude pratique analysant la réalité de la création et de la maintenance des OSS, mettant en lumière la dépendance envers un petit nombre de mainteneurs et les enjeux de durabilité）

• Hoffmann, M., Nagle, F., & Zhou, Y. (2024). The value of open source software. Harvard Business School Working Paper 24-038.（Article estimant la valeur côté offre des OSS largement utilisés à 4,15 milliards de dollars et côté demande à 8,8 billions de dollars, montrant que 96 % de la valeur provient de 5 % des développeurs）

• Lerner, J., & Tirole, J. (2002). Some simple economics of open source. Journal of Industrial Economics, 50(2), 197-234.（Texte fondateur expliquant par l'économie de la signalisation et de la formation du capital humain pourquoi les développeurs contribuent gratuitement aux OSS）

• Nagle, F. (2018). Learning by contributing: Gaining competitive advantage through contribution to crowdsourced public goods. Organization Science, 29(4), 569-587.（Article démontrant le mécanisme par lequel les contributions aux biens publics (OSS) génèrent un avantage concurrentiel pour les entreprises contributrices）

• Nagle, F. (2019). Open source software and firm productivity. Management Science, 65(3), 1191-1215.（Article démontrant empiriquement la relation entre l'utilisation/la contribution aux OSS et la productivité des entreprises, montrant que les entreprises contributrices obtiennent des rendements plus élevés）

• Spolsky, J. (2002). Strategy letter V. Joel on Software.（Réflexion d'un praticien formulant clairement la stratégie des biens complémentaires : « les entreprises intelligentes transforment en commodité les biens complémentaires de leurs produits »）

• Teece, D. J. (1986). Profiting from technological innovation: Implications for integration, collaboration, licensing and public policy. Research Policy, 15(6), 285-305.（L'un des textes les plus importants de la théorie de la stratégie technologique, montrant que les bénéfices de l'innovation reviennent aux propriétaires des actifs complémentaires plutôt qu'aux inventeurs）

• von Hippel, E., & von Krogh, G. (2003). Open source software and the "private-collective" innovation model: Issues for organization science. Organization Science, 14(2), 209-223.（Article présentant le « modèle d'innovation privé-collectif » où la contribution aux biens publics et l'acquisition de gains privés sont compatibles）

• West, J. (2003). How open is open enough? Melding proprietary and open source platform strategies. Research Policy, 32(7), 1259-1285.（Article analysant les conditions sous lesquelles les entreprises de plateforme adoptent une stratégie hybride « partiellement ouverte » entre l'ouverture complète et le monopole）