Name: L'Open-Washing : Anatomie de la Capture Commune
Author: Amine RAITI

100%

GRIMOIRE❦

Grimoire Corpus Dindon Volumes de Synthèse Le Socle du Fer

HUMAN

Essai structurel · Juillet 2026 · Volume Autonome

◆◆◆

L'Open-Washing
Anatomie de la Capture Commune

◆

◆ Déclaration d'Asymétrie — valable pour l'ensemble de ce volume

Ce volume ne prétend pas que tout usage commercial de logiciel libre par un fournisseur cloud constitue une capture. Il a été modélisé par un architecte infrastructure, audité de façon contradictoire par deux intelligences artificielles, à partir de faits publics vérifiables — changements de licence documentés, produits commerciaux publiés, historiques de contribution publics. Il n'instruit le procès d'aucune bonne ou mauvaise foi. Il documente une asymétrie d'extraction de valeur, mécanisme par mécanisme, et propose des modèles de gouvernance assumés comme des propositions, pas des normes en vigueur.

◆◆◆

Amine RAITI — Architecte Infrastructure & SRE
Ancien professeur en école d'ingénieurs · Formateur depuis 2006
Document public · CC BY-NC-SA 4.0

HUMAN

Fil Conducteur

Ce que ce volume va démontrer, dans l'ordre

◆

Ce volume établit une chaîne en trois temps : d'abord pourquoi une licence protège un droit de lecture mais jamais un contrôle matériel (Acte I) ; ensuite, six mécanismes concrets et distincts par lesquels la capture opère réellement, du changement de licence documenté jusqu'à la contribution fantôme qui oriente discrètement un projet vers un seul type de matériel (Acte II) ; enfin, une architecture de reconquête fondée sur des leviers directement corrélés à chaque pilier — gouvernance neutre, interdiction d'émulation, blackholing de télémétrie — avant d'établir le lien explicite avec la souveraineté matérielle démontrée ailleurs dans cette collection (Acte III).

◆ La thèse en une phrase

Une licence protège un droit de lecture. Elle ne protège ni l'interface qu'on imite, ni l'usage qu'on observe à distance, ni le commit qui réoriente discrètement un projet vers un seul type de matériel, ni le mainteneur qu'on recrute avant même d'avoir besoin de forker quoi que ce soit.

ACTE I — LA THÈSE

I.1Le Gisement GratuitUne licence protège un droit de lecture, jamais un contrôle matériel

ACTE II — LA DÉMONSTRATION

II.0Les Quatre BasculesElastic, MongoDB, HashiCorp, Redis — un même schéma documenté

II.1L'Enclos de l'InterfacePilier A — le fork capture le code, l'émulation capture le geste

II.2L'Asymétrie de la TélémétriePilier B — qui possède les retours de la production ?

II.2bL'Aspiration des CerveauxQuand la capture n'a besoin d'aucun commit

II.2cL'Enracinement PropriétaireLe code reste libre, l'identité et le chiffrement ne le sont plus

II.3La Contribution FantômePilier C — un commit légitime en apparence peut orienter un projet vers un seul matériel

ACTE III — LA RECONQUÊTE

III.1La Gouvernance NeutreUne réponse au risque de licence, rien de plus — la limite du cas Kubernetes

III.2L'Interdiction d'ÉmulationRéponse au Pilier A — exiger le moteur réel, pas son imitation

III.2bLe Découplage Identité/ChiffrementOIDC indépendant, Vault souverain

III.3Le Blackholing de TélémétrieRéponse au Pilier B — couper le flux sortant, observer en interne

III.4Le Lien avec le MatérielLa souveraineté du code s'arrête où commence le silicium loué

HUMAN

I.1

Un commun sans matière reste un commun sans défense

Le code distribué librement, sans contrôle de la puissance de calcul sous-jacente, devient un gisement gratuit

◆

Une licence open source garantit un droit : celui de lire, modifier et redistribuer un code source. Elle ne garantit aucun contrôle sur l'infrastructure physique qui l'exécute à grande échelle. Cette distinction, rarement énoncée, produit une conséquence mathématique simple : un projet communautaire dont la valeur d'usage s'exprime uniquement en production, sur des machines qu'il ne possède pas, devient structurellement une matière première gratuite pour quiconque possède ces machines en quantité suffisante.

◆ Ce que la licence protège, et ce qu'elle ne protège jamais

Les licences permissives (Apache 2.0, MIT) et même copyleft classiques (GPL) protègent la liberté de modification et de redistribution du code. Aucune d'elles n'impose de reversement économique proportionné à celui qui exploite ce code à l'échelle industrielle via un service managé — la licence régule la propriété intellectuelle, pas la rente d'exploitation.

◆ Une légalité totale, et l'asymétrie qu'elle ne dissout pas

Exploiter commercialement un projet sous licence permissive est parfaitement légal, et c'est précisément l'objet de ces licences. Ce volume documente une asymétrie distincte : quand l'échelle d'exploitation d'un hyperscaler devient si massive que la valeur extraite dépasse de plusieurs ordres de grandeur toute contribution reversée à la maintenance du projet, la licence légale ne suffit plus à décrire l'équilibre réel de la relation.

HUMAN

Acte II — La Démonstration

La mécanique de l'expropriation, en trois piliers symétriques

◆

Quatre changements de licence publics et documentés introduisent ce que ce volume appelle la mécanique de l'expropriation, avant que trois piliers distincts n'en détaillent chacun un mécanisme précis : la capture par l'interface, la capture par l'usage, et la capture par l'intérieur du code lui-même.

HUMAN

II.0

Quatre bascules de licence, un même schéma

Elastic, MongoDB, Redis, HashiCorp — le changement de licence comme signal public d'un déséquilibre

◆

En janvier 2021, Elastic a fait basculer Elasticsearch et Kibana de la licence Apache 2.0 vers la Server Side Public License (SSPL), citant explicitement l'exploitation du projet par AWS via un service managé concurrent sans reversement proportionné. MongoDB avait pris la même décision dès 2018, introduisant lui-même la licence SSPL pour la même raison déclarée. HashiCorp a basculé Terraform et ses autres produits de la licence Mozilla Public License vers la Business Source License (BSL) en 2023. Redis a fait de même pour son moteur en 2024. Dans les quatre cas, l'entreprise à l'origine du projet documente publiquement la même justification : un fournisseur cloud exploite le projet à une échelle qui génère une valeur locative significative, sans que cette valeur ne finance en retour la maintenance du bien commun.

◆ La Dette Invisible — un recadrage nécessaire

Une étude antérieure de ce corpus, La Dette Invisible, a documenté le sous-financement chronique de briques open source critiques (curl, Log4j) — la tragédie des communs au sens classique : un manque de ressources. Ce volume documente un mécanisme distinct, quoique lié : le problème n'est plus l'absence de financement, c'est l'existence d'une valeur considérable, générée par l'exploitation industrielle du projet, qui n'est structurellement jamais reversée à l'entité qui maintient l'infrastructure humaine sous-jacente. C'est cette asymétrie d'extraction — pas un manque en soi — qui force le basculement vers des licences plus restrictives.

HUMAN

II.1

Pilier A · L'enclos de l'interface

Deux mécanismes distincts — le fork du code, et l'émulation du geste

◆

Un fournisseur cloud peut répondre à un changement de licence restrictif de deux façons techniquement distinctes, qu'il convient de ne jamais confondre. Amazon OpenSearch est un fork au sens strict : une copie de la base de code d'Elasticsearch antérieure au changement de licence, maintenue et développée indépendamment — la capture porte ici sur le code source lui-même, à un instant T. Amazon DocumentDB est d'une autre nature : une émulation du protocole réseau (wire protocol) de MongoDB, compatible avec ses pilotes et ses commandes, mais reposant sur un moteur de stockage propriétaire distinct, ne partageant aucune ligne du code MongoDB. La capture ne porte alors plus sur le code, mais sur le geste du développeur qui continue de dialoguer dans le même langage de commandes.

◆ Ce que cette compatibilité capture réellement

Le geste que capture cette compatibilité n'est pas le moteur logiciel — c'est l'ensemble des habitudes, scripts, outils de développement et intégrations construites par des équipes entières autour d'un vocabulaire de commandes précis. Une application écrite pour parler « MongoDB » continue de fonctionner sans modification sur DocumentDB — ce qui signifie que migrer vers un autre fournisseur nécessite de réécrire ces intégrations, même si le moteur sous-jacent a déjà changé une fois sans que l'équipe applicative ne s'en aperçoive.

◆ Une légalité totale, un effet de verrouillage identique

Aucune règle de propriété intellectuelle n'interdit de créer une interface compatible avec un format de commandes — les interfaces ne sont généralement pas protégeables de la même façon que le code lui-même. Ce pilier ne documente donc pas une illégalité, mais un verrouillage fonctionnellement identique à celui produit par du code propriétaire, obtenu par un chemin juridiquement distinct.

HUMAN

II.2

Pilier B · L'asymétrie de la télémétrie

Un projet s'améliore par la production — qui possède les retours de production ?

◆

Un projet open source progresse en partie grâce aux signaux remontés par son utilisation réelle en production : quels chemins de code échouent le plus souvent, quelles configurations dégradent la performance, quels volumes de charge révèlent des limites non anticipées en laboratoire. Un fournisseur cloud hébergeant des millions d'instances managées d'un même projet accumule ce type de signal à une échelle qu'aucun mainteneur indépendant ne peut reproduire par ses propres moyens.

◆ Ce que cette exclusivité de signal produit

Le fournisseur cloud développe, à partir de cette télémétrie agrégée, un avantage diagnostique et prédictif réel — savoir avant tout le monde quelles configurations posent problème à grande échelle, quelles optimisations internes apportent le gain le plus mesurable. Cet avantage informe ses propres choix d'ingénierie interne et la feuille de route de son service managé concurrent, sans qu'aucune obligation ne l'engage à reverser ce même signal au projet d'origine.

◆ Une asymétrie d'information structurelle

Ce mécanisme ne repose sur aucune violation de confidentialité — les données de télémétrie de service managé appartiennent légitimement à l'opérateur du service. L'asymétrie documentée ici est structurelle : la communauté qui a produit le code n'a, par construction, aucun accès symétrique aux enseignements tirés de son exploitation à cette échelle.

◆ Ce que ce pilier ne prétend pas

Ce pilier ne prétend pas que les fournisseurs cloud cachent délibérément des informations dues à la communauté par contrat. Il documente une asymétrie d'échelle : même en supposant une totale bonne foi, aucun mécanisme structurel n'assure aujourd'hui que la connaissance accumulée par l'exploitation industrielle profite en retour à la maintenance du projet source.

HUMAN

II.2b

Ce que le code ne montre jamais

L'aspiration des cerveaux — quand la capture n'a besoin d'aucun commit

◆

◆ Un quatrième mécanisme, invisible dans le code

Il n'est pas toujours nécessaire de forker un projet ou d'en émuler l'interface : un fournisseur cloud peut simplement recruter le mainteneur principal détenant les droits d'approbation (« merge ») sur le dépôt de référence. Ce mécanisme ne laisse aucune trace dans l'historique du code — l'acquisition ne porte pas sur le logiciel, mais sur la personne qui décide de ce qui y entre. Ce volume le mentionne ici comme un mécanisme distinct des trois piliers suivants, sans prétendre l'analyser avec la même profondeur : contrairement à un changement de licence ou un commit technique, une embauche individuelle n'est ni datée publiquement de façon systématique, ni attribuable à une intention unique — mais son effet cumulé sur la gouvernance de fait d'un projet mérite d'être nommé.

HUMAN

II.2c

L'enracinement propriétaire

Le code reste libre — ses racines d'identité et de chiffrement ne le sont plus

◆

Une organisation peut appliquer scrupuleusement la mesure documentée en III.2 de ce volume — refuser tout service managé d'émulation, déployer un moteur open source authentique (PostgreSQL, Kubernetes) sur une infrastructure cloud maîtrisée. Un mécanisme de capture distinct opère malgré tout, à une couche différente : celle de l'identité et du chiffrement.

◆ Le mécanisme d'intégration native

Le fournisseur cloud propose une intégration native et sans friction apparente entre ce moteur open source et son propre système de gestion des identités (par exemple AWS IAM) ainsi que son propre gestionnaire de clés de chiffrement (par exemple AWS KMS). Le code du moteur reste intact et libre — mais les droits d'accès des utilisateurs et les clés protégeant les données sont désormais définis et détenus dans des systèmes propriétaires distincts du moteur lui-même.

◆ Ce que cette intégration rend non portable

Au moment d'envisager une migration de ce moteur pourtant authentiquement libre, l'organisation découvre que ses politiques d'accès et ses clés de chiffrement ne transfèrent pas avec lui — elles appartiennent à un écosystème de sécurité propriétaire distinct, qu'il faut intégralement reconstruire chez tout nouveau fournisseur. La liberté du code n'a jamais garanti la portabilité de ce qui l'entoure.

HUMAN

II.3

Pilier C · La contribution fantôme

Un commit légitime en apparence peut orienter un projet vers un seul type de matériel

◆

Les grands fournisseurs cloud figurent parmi les contributeurs les plus actifs de nombreux projets open source majeurs, mesurés en volume de commits. Ce volume de contribution est un fait public et vérifiable dans l'historique Git de ces projets. Ce pilier documente un sous-ensemble spécifique de ces contributions : celles qui, sous couvert d'optimisation de performance, introduisent une dépendance fonctionnelle à un composant matériel ou logiciel propriétaire spécifique au contributeur.

◆ Le protocole de vérification applicable à ce mécanisme

Vérifier ce mécanisme suppose de croiser trois éléments publics : l'affiliation employeur du compte auteur d'un commit (déclarée ou déductible du domaine e-mail associé), la nature technique de l'optimisation introduite (quel composant matériel ou quelle bibliothèque propriétaire elle cible spécifiquement), et l'existence ou l'absence d'un chemin de code équivalent pour du matériel générique ou concurrent. Une optimisation qui n'accélère le projet que sur un jeu d'instructions propriétaire, ou qui n'active un mode performant qu'en présence d'un composant de chiffrement propre à un seul fournisseur, répond à ce critère.

◆ L'effet cumulatif documenté, sans jugement d'intention

L'accumulation de ce type de commits sur plusieurs années produit un effet mesurable indépendamment de toute intention individuelle : un projet dont une part croissante des chemins de code optimisés cible spécifiquement l'infrastructure d'un contributeur majoritaire tourne, à performance égale, mieux sur cette infrastructure que sur un socle matériel générique ou souverain — créant une obsolescence de performance relative sur tout matériel extérieur à cet écosystème.

◆ Ce que ce pilier ne prétend pas et ne peut pas établir seul

Ce pilier ne prétend établir aucune intention de nuire de la part des auteurs individuels de ces commits — une optimisation ciblée peut être proposée de bonne foi par un ingénieur cherchant simplement à améliorer les performances sur l'environnement qu'il connaît le mieux. Ce que ce pilier établit est un effet cumulatif structurel, vérifiable par l'analyse de l'historique public du code, indépendant de l'intention de chaque contribution individuelle.

HUMAN

Acte III — La Reconquête

Trois leviers pour trois piliers — la gouvernance seule ne suffit pas

◆

Chaque pilier de l'Acte II appelle une réponse de nature différente. La gouvernance neutre répond au risque de changement de licence documenté en introduction de l'Acte II — elle ne répond ni à la capture par interface (Pilier A), ni à l'asymétrie de télémétrie (Pilier B). Cette partie ajoute les deux leviers architecturaux et matériels manquants, avant d'établir le lien avec la souveraineté du matériel démontrée ailleurs dans cette collection.

HUMAN

III.1

Un mainteneur unique reste une cible unique

La gouvernance neutre — une réponse au risque de licence, rien de plus

◆

Un projet gouverné par une seule entreprise commerciale présente une structure d'exposition simple : cette entreprise détient seule le pouvoir de changer la licence sous la pression documentée en introduction de l'Acte II. Un projet transféré à une fondation neutre — sur le modèle de l'Apache Software Foundation ou de la Cloud Native Computing Foundation — répartit ce pouvoir entre plusieurs organisations membres, rendant plus difficile un changement de licence unilatéral.

◆ La limite stricte de ce levier — le cas Kubernetes

Kubernetes est gouverné par la CNCF, une fondation neutre exemplaire. Cela n'empêche pourtant en rien Amazon (EKS) et Google (GKE) de capter la télémétrie d'usage massif de leurs services managés respectifs sans la reverser au projet, ni d'émuler ou d'encapsuler ses interfaces pour capturer le geste développeur. La gouvernance neutre protège la licence — elle ne protège ni contre le Pilier A ni contre le Pilier B.

HUMAN

III.2

Répondre à l'enclos de l'interface — interdire l'émulation dans les standards internes

Réponse directe au Pilier A · Exiger le moteur réel, pas son imitation

◆

Face à la capture par émulation documentée dans le Pilier A, une organisation peut agir directement sur ses propres standards d'architecture, sans attendre aucune évolution du marché ou de la réglementation.

◆ La mesure concrète

Inscrire dans les standards internes d'architecture l'interdiction d'utiliser des services managés d'émulation d'interface (tels que DocumentDB pour un usage nécessitant MongoDB) au profit du moteur réel, hébergé sur une infrastructure maîtrisée — machine virtuelle ou serveur physique sous contrôle direct de l'organisation. Le recours à un fork gouverné par une fondation neutre (comme OpenSearch) reste, lui, compatible avec cette règle, la capture qu'il documente relevant du Pilier de licence, pas de celui de l'interface.

◆ Ce que cette mesure coûte, sans le dissimuler

Renoncer à un service managé d'émulation signifie renoncer à une partie de la simplicité opérationnelle que ce service promet. C'est un compromis explicite entre confort opérationnel immédiat et réversibilité technique à moyen terme — pas une solution sans coût.

HUMAN

III.2b

Découpler l'identité et le chiffrement du moteur

Réponse directe à l'Enracinement Propriétaire (II.2c)

◆

◆ La mesure architecturale

Face à l'enracinement documenté en II.2c, la mesure complémentaire à l'interdiction d'émulation (III.2) consiste à imposer, dans les mêmes standards d'architecture internes, le découplage systématique de la gestion des identités et du chiffrement vis-à-vis de tout moteur open source déployé — par exemple via un fournisseur d'identité indépendant respectant le standard OIDC plutôt que le système propriétaire du cloud sous-jacent, et un coffre de gestion de clés auto-hébergé (tel que HashiCorp Vault, avant son propre changement de licence documenté en II.0, ou une alternative équivalente) plutôt que le gestionnaire de clés natif du fournisseur. Un moteur open source dont les accès et le chiffrement restent portables l'est réellement — un moteur libre dont l'identité et les clés sont enracinées chez un seul fournisseur ne l'est qu'en apparence.

HUMAN

III.3

Répondre à la captation de visibilité — couper le flux, observer en interne

Réponse directe au Pilier B · Blackholing de la télémétrie sortante

◆

Face à l'asymétrie de télémétrie documentée dans le Pilier B, une organisation peut agir sur ses propres flux réseau sortants, indépendamment de tout changement chez le fournisseur du service managé.

◆ La mesure concrète — le blackholing par pare-feu strict

Configurer des règles de pare-feu strictes bloquant explicitement (« blackholing ») tout flux de télémétrie sortant vers les points de collecte propriétaires des éditeurs tiers de services managés, tout en maintenant une observabilité complète en interne. Cette mesure ne prive pas l'organisation de sa propre visibilité opérationnelle — elle prive uniquement le fournisseur externe de l'accès à cette même visibilité.

◆ Le lien avec un autre volume de cette collection

Un autre volume de cette collection, L'Amnésie du Diagnostic, a documenté l'érosion de la compétence de diagnostic causal interne, en partie remplacée par une dépendance aux outils d'observabilité de fournisseurs tiers. Le blackholing de la télémétrie sortante n'a de sens que couplé à cette compétence de diagnostic interne restaurée — bloquer un flux sortant sans capacité interne de lecture des journaux bruts ne fait que priver l'organisation de toute visibilité, externe comme interne.

HUMAN

III.4

La souveraineté du code s'arrête où commence le silicium loué

Le lien explicite avec la matière déjà démontrée ailleurs dans cette collection

◆

Un autre volume de cette collection, L'Illusion du Nuage, a démontré qu'aucune souveraineté numérique n'est possible sans maîtrise du matériel sous-jacent. Ce volume établit le corollaire logique pour le logiciel libre : un code sous licence protégée par la gouvernance la plus neutre possible, exécuté exclusivement via des services managés du même acteur dont ce volume documente les mécanismes de capture, reste vulnérable aux Piliers A et B — quelle que soit la solidité de sa gouvernance de licence.

◆ Ce que ce volume ne prétend pas résoudre seul

Ce volume ne prétend pas que les trois leviers de cette Reconquête, pris isolément, suffisent chacun à neutraliser totalement le mécanisme auquel il répond. Il établit que la souveraineté sur le code, la souveraineté sur l'interface, et la souveraineté sur la visibilité opérationnelle sont trois conditions distinctes — aucune ne remplaçant les deux autres.

HUMAN

Clôture

Une asymétrie d'extraction, une architecture de résistance à trois étages

◆

◆ La thèse en une phrase

◆ Appel ouvert — Pull Request humaine

Ce volume est un système ouvert en attente de correctifs du monde réel. Nous invitons explicitement tout mainteneur de projet open source ayant vécu l'un de ces mécanismes à documenter son expérience, et à corriger ou enrichir cette anatomie.

◆◆◆

Un commun sans défense n'est pas un commun protégé par la loi. C'est une ressource gratuite en attente d'un exploitant assez grand pour la récolter à l'échelle industrielle.

◆◆◆

Amine RAITI · 2026