Skip to main content
Welcome. This site supports keyboard navigation and screen readers. Press ? at any time for keyboard shortcuts. Press [ to focus the sidebar, ] to focus the content. High-contrast themes are available via the toolbar.
serard@dev00:~/cv

Commons numériques empiriques — Wikipedia, Linux, OSM, et les trois modèles de gouvernance

Les Commons numériques fonctionnent. Wikipedia, Linux, OpenStreetMap, Mozilla, Apache — innovations massives, distribuées, gouvernées par leurs participants, et invisibles aux énonciateurs canoniques parce que non-monétisables directement. Ils prouvent empiriquement que Δ-citoyen peut être bas dans des écosystèmes ouverts.

Pourquoi un doc empirique positif

Cette page ouvre le bloc empirique positif de la section. Après cinq cas négatifs (Qwant, Microsoft dogfooding, Boeing, AI Act, Cambridge Analytica/Health Data Hub/McKinsey-Macron), il est politiquement nécessaire de montrer que le paradigme public produit des innovations qui fonctionnent. Sans cette démonstration, la critique des cas négatifs pourrait être lue comme nihilisme ou comme préférence pour un statu quo « moins mauvais ». Avec elle, la critique devient appel à l'action — on peut faire autrement, on l'a déjà fait, on continue de le faire.

Cinq cas principaux structurent ce doc : Wikipedia (encyclopédie collaborative), Linux (noyau de système d'exploitation), OpenStreetMap (cartographie collaborative), Mozilla (Firefox et écosystème associé), Apache (serveur web et Foundation). Plus l'initiative récente Sovereign Tech Fund allemande (2022+) qui montre que l'État européen peut financer publiquement les Communs critiques.

Ces cas démontrent que Δ-citoyen peut être bas quand les conditions matérielles sont adaptées — gouvernance par discussion, traçabilité bout-en-bout des décisions, ouverture du code, capacité à forker (créer une variante autonome).

Articulation au programme constructif : la métacratie publique propose Citizen.Dsl + Commons.Dsl + LesLois.fr qui empruntent les patterns de gouvernance éprouvés par Wikipedia/Linux/OSM (cf. 12). La proposition n'est pas naïve — elle est référencée sur des cas empiriques qui fonctionnent depuis ~25 ans.

Wikipedia (2001-)

Échelle et gouvernance

Wikipedia est l'innovation encyclopédique la plus massive de l'histoire humaine. Quelques chiffres en 2024-2026 :

  • ~60 millions d'articles toutes langues confondues.
  • 300+ langues actives, dont une vingtaine avec plus de 100 000 articles.
  • ~280 000 contributeurs actifs/mois (au moins 5 contributions/mois).
  • ~6,5 milliards de visites/mois (Alexa, similaire).
  • Wikipedia anglaise : ~6,7 millions d'articles, ~120 000 contributeurs actifs/mois.
  • Wikipedia française : ~2,6 millions d'articles, ~15 000 contributeurs actifs/mois.

La gouvernance de Wikipedia est par discussion. Concrètement :

  • Talk pages — chaque article a une page de discussion attachée, où les contributeurs débattent des modifications, contestent les sources, négocient les formulations.
  • Principes éditoriaux explicites — Neutral Point of View (NPOV : présenter les points de vue sans en privilégier un), Verifiability (chaque fait doit être sourcé par une source vérifiable), No Original Research (pas de recherche originale ; Wikipedia rapporte ce qui est déjà publié ailleurs).
  • Comités d'arbitrage — chaque grande Wikipedia (anglaise, française, allemande, etc.) a un Arbitration Committee (ArbCom) élu par la communauté pour trancher les conflits éditoriaux les plus durs. ArbCom anglaise : 12 membres élus pour 1 an, qui statuent sur les cas qui n'ont pas pu être résolus aux niveaux inférieurs.
  • Hiérarchie de droits — utilisateur anonyme → utilisateur enregistré → contributeur autopatrolled → administrateur (sysop) → bureaucrate → CheckUser → Oversight → Steward (niveau global). Chaque niveau a des droits supplémentaires et des responsabilités. Les niveaux supérieurs sont élus par la communauté.

Reagle — Good Faith Collaboration (2010)

Joseph Reagle dans Good Faith Collaboration: The Culture of Wikipedia (MIT Press, 2010) propose une ethnographie de la gouvernance Wikipedia. Sa thèse : Wikipedia fonctionne par « good faith collaboration » — une culture de collaboration de bonne foi qui présume initialement la bonne intention de tout contributeur, et qui produit des mécanismes de résolution des conflits sans recourir à la violence ni à l'autorité hiérarchique.

Cette culture n'est pas spontanée. Elle est construite par :

  • des principes explicites (NPOV, vérifiabilité, no original research) ;
  • des procédures de résolution de conflits graduées (discussion en page de talk → demande de troisième opinion → demande de comité → arbitrage) ;
  • des figures d'autorité légitimées par l'élection communautaire et révocables ;
  • une mémoire institutionnelle (l'historique de chaque article est conservé et auditable, donc les contestations peuvent invoquer des précédents).

Le consensus comme méthode éditoriale formelle est central. Pas la majorité brute (qui pourrait écraser les minorités), pas l'autorité hiérarchique (qui serait susceptible de capture), mais le consensus construit par discussion — qui prend du temps, qui exige patience, qui peut échouer mais qui est structurellement non-capturable à grande échelle (la communauté est trop diverse pour qu'un seul intérêt la domine longtemps).

Δ-citoyen Wikipedia

Δ-citoyen sur Wikipedia est quasi nul pour les modifications courantes. Concrètement :

  • Un article peut être modifié, contesté, restauré, débattu en quelques heures à jours.
  • Une erreur factuelle est généralement corrigée en quelques jours (parfois minutes pour les articles très lus).
  • Une controverse éditoriale majeure est résolue en quelques semaines à mois (rarement plus).
  • Une question constitutionnelle (modification d'un principe éditorial) est débattue en quelques mois à années via des consultations ouvertes (RfC — Request for Comments).

C'est radicalement différent des Δ-citoyen vus dans les cas négatifs (Microsoft 30 ans, Cambridge Analytica 4 ans, Boeing 5 ans + 346 morts). Wikipedia démontre empiriquement que Δ-citoyen peut être très bas dans une gouvernance distribuée par discussion.

Limites

Wikipedia n'est pas parfaite. Limites documentées :

  • Biais de genre persistants — ~85% éditeurs masculins en 2024, malgré 20 ans d'efforts pour diversifier. Conséquence : sous-représentation des sujets féminins dans les articles, biais dans le ton et le cadrage de certains sujets.
  • Biais linguistiques — la Wikipedia anglaise sur-représente certains points de vue (anglo-américain, occidental, scientifique mainstream). Les Wikipedias en langues moins dotées sont parfois moins fiables ou plus susceptibles à la capture.
  • Capture par lobbies — sur certaines pages politiques sensibles, des éditeurs payés (par firmes ou par États) tentent de modifier dans leurs intérêts. Wikipedia a des mécanismes pour détecter (paid editing disclosure, vérification IP) mais la lutte est continue, pas résolue.
  • Soutenabilité financière fragile — Wikipedia repose sur la Wikimedia Foundation (US) financée par dons. Le modèle économique est minceur — des dons annuels de la communauté + quelques subventions philanthropiques. Pas de revenus publicitaires.

Ces limites sont connues et activement travaillées par la communauté. Aucune n'efface la démonstration empirique majeure de Wikipedia : un Common numérique distribué peut produire une innovation massive avec Δ-citoyen bas.

Linux (1991-)

Échelle et impact

Linux est le noyau (kernel) du système d'exploitation Linux, démarré en 1991 par Linus Torvalds (étudiant finlandais à l'époque). Trente-cinq ans plus tard :

  • ~95% des serveurs Internet tournent sous Linux ou un dérivé (selon W3Techs 2024).
  • Android (basé sur le kernel Linux) — ~3+ milliards d'utilisateurs actifs.
  • Supercalculateurs — 100% des 500 plus puissants mondiaux tournent sous Linux (TOP500 2023+).
  • Embedded — milliards d'appareils IoT, routeurs, set-top boxes, voitures connectées.
  • Cloud public — AWS, Azure, GCP s'appuient massivement sur Linux pour leurs offres.
  • Cloud privé — Kubernetes, Docker, OpenStack — toutes ces infrastructures s'appuient sur Linux.

L'impact économique est gigantesque. Si Linux était une entreprise privée, sa valorisation serait équivalente à celle des plus grosses Big Tech. Mais Linux n'est pas une entreprise privée — c'est un Common gouverné par sa communauté, distribué sous licence GPL (General Public License), copyleft fort qui empêche la propriétisation.

Gouvernance Torvalds + maintainers

La gouvernance Linux est différente de Wikipedia. Elle suit le modèle « benevolent dictator + maintainers » (Eric Raymond, The Cathedral and the Bazaar, 1997, 2001).

  • Linus Torvalds est le « benevolent dictator for life » (BDFL) — il a le dernier mot sur tout ce qui rentre dans le kernel principal. C'est une figure d'autorité non-élue, fondée sur sa légitimité historique (il a démarré le projet) et sa compétence technique (il sait lire et juger du code C de niveau kernel).
  • Maintainers — ~1500 maintainers identifiés dans le fichier MAINTAINERS du kernel (~50 000 lignes, qui assigne chaque sous-système à un ou plusieurs maintainers responsables). Ces maintainers trient les patches reçus, intègrent dans leurs sous-systèmes, et transmettent à Torvalds (ou à des sub-maintainers principaux comme Greg Kroah-Hartman).
  • Linux Foundation — organisation à but non-lucratif (basée US, fondée 2007) qui finance l'infrastructure Linux (paie le salaire de Torvalds depuis 2007, héberge les serveurs, organise les conférences). La Foundation est gouvernée par un conseil d'administration où siègent les principales firmes contribuant à Linux (IBM, Red Hat, Google, Microsoft, Oracle, Samsung, etc.).
  • Mailing list LKML (Linux Kernel Mailing List) — la vraie gouvernance opérationnelle se fait sur cette mailing list publique. Les patches sont proposés, critiqués, raffinés, acceptés ou rejetés. Tout est traçable — chaque commit a son historique de discussion.

Eghbal — Working in Public (2020)

Nadia Eghbal dans Working in Public: The Making and Maintenance of Open Source Software (Stripe Press, 2020) propose une typologie des modèles de gouvernance des projets open source :

  • Federations (fédérations) — projets multi-acteurs avec gouvernance partagée (Apache Foundation, Linux Foundation, Eclipse Foundation). Multi-stakeholder.
  • Stewards (intendants) — projets où une personne ou une entité fait le travail de maintenance principale au nom d'une communauté plus large (Linux avec Torvalds, Python avec Guido van Rossum jusqu'en 2018, Django avec sa Foundation).
  • Clubs — projets fermés à des contributeurs sélectionnés (Postgres avec ses committers, certains projets BSD).
  • Toys (jouets) — projets personnels d'un seul mainteneur, avec contributions externes occasionnelles.

Linux relève de la stewardship — Torvalds + maintainers qui pilotent au nom d'une communauté plus large. Eghbal montre que ce modèle est viable mais fragile quand l'intendant principal s'épuise ou quitte. Le bus factor (nombre de personnes qui doivent disparaître pour bloquer le projet) est faible quand un seul individu porte trop. Linux a un bus factor élevé grâce aux maintainers actifs, mais d'autres projets stewardés sont plus fragiles.

Δ-citoyen Linux

Δ-citoyen Linux est variable selon le type de modification :

  • Bugs — un bug critique signalé sur LKML est généralement corrigé en heures à jours. Les patches sont peer-reviewés, intégrés, testés, déployés.
  • Patchs sécurité — souvent en heures (vulnérabilités critiques type Log4Shell, Heartbleed sont gérées avec urgence, divulgation coordonnée, distribution rapide).
  • Évolutions architecturales — un changement architectural majeur est débattu sur LKML pendant mois à années. Discussions techniques approfondies, RFC formelles, compromis négociés. Un changement comme l'introduction de Rust dans le kernel (en cours 2022-2026) prend plusieurs années de débat.

Pour les modifications courantes, Δ-citoyen Linux est extrêmement bas. Pour les modifications constitutionnelles, il est plus long mais transparent et traçable — tout est sur LKML, tout est archivé, tout est citable.

Limites Linux

  • Burn-out des maintainers — plusieurs maintainers principaux ont quitté ou réduit leur contribution pour cause de surcharge. Le travail bénévole intense n'est pas durable individuellement.
  • Dépendance aux contributions corporate — la majorité des contributions au kernel principal vient désormais d'entreprises (Red Hat ~12%, Intel, IBM, Google, Linaro, etc.). Les contributeurs amateurs sont marginalisés en proportion. Cela crée une asymétrie : les corps qui financent les contributeurs orientent indirectement le kernel.
  • Monoculture technique — Linux est dominant à un point qui pose question pour la diversité technologique. Les alternatives BSD (FreeBSD, OpenBSD, NetBSD) survivent mais marginalisées.
  • Gouvernance non-démocratique strictement — Torvalds n'est pas élu, les maintainers sont auto-cooptés. La légitimité fonctionne mais ne suit pas les patterns démocratiques classiques.

Malgré ces limites, Linux est l'innovation logicielle libre la plus massive et la plus pérenne. Sa réussite empirique est incontestable et a changé l'industrie informatique mondiale.

OpenStreetMap (2004-)

Échelle

OpenStreetMap (OSM) est un projet de cartographie collaborative ouverte démarré en 2004 par Steve Coast (UK) en réaction au verrouillage propriétaire des données géographiques par Ordnance Survey (UK) et Google Maps. En 2024-2026 :

  • ~10 millions de contributeurs cumulés (~80 000 actifs mensuels en 2024).
  • Couverture mondiale quasi-complète des routes principales et zones urbaines, avec grande qualité dans les zones bien cartographiées (Europe occidentale, Amérique du Nord) et qualité variable ailleurs.
  • Données réutilisées par Apple Maps, Facebook (Maps), Wikipedia, Pokémon Go, Lyft (US), des dizaines de milliers de services tiers.
  • Open Database License (ODbL) — licence copyleft sur la base de données. Toute réutilisation doit partager sous la même licence.

Gouvernance

  • OpenStreetMap Foundation (UK) — organisation à but non-lucratif qui détient l'infrastructure et coordonne la gouvernance globale.
  • Working groups thématiques — Operations Working Group, Data Working Group, Communication Working Group, etc. Chaque groupe traite un aspect (infrastructure, conflits éditoriaux, communication externe).
  • Communautés locales — chaque pays/région a sa propre communauté OSM avec ses pratiques (e.g. OSM France comme association séparée de la Foundation, qui mène ses propres projets).
  • Talk pages et forums — comme Wikipedia, OSM a une culture de discussion publique sur les modifications.

Mission humanitaire — HOT

Une innovation majeure d'OSM est le Humanitarian OpenStreetMap Team (HOT, 2010+). Quand une catastrophe humanitaire frappe une zone mal cartographiée, HOT mobilise des milliers de cartographes bénévoles dans le monde pour cartographier la zone à partir d'imagerie satellite. La cartographie est ensuite utilisée par les ONG (MSF, Croix-Rouge, Care, etc.) pour leurs opérations.

Cas concrets :

  • Haïti 2010 — après le tremblement de terre, cartographie complète de Port-au-Prince en quelques jours par HOT.
  • Tacloban 2013 (typhon Haiyan, Philippines) — cartographie en 48h.
  • Crise Ebola 2014 — cartographie des villages d'Afrique de l'Ouest pour faciliter les opérations sanitaires.
  • COVID-19 2020 — cartographie d'établissements de santé dans les zones mal couvertes pour soutenir la réponse pandémique.

HOT démontre que les Communs numériques peuvent agir politiquement à l'échelle mondiale, en complément ou en substitut des États (qui souvent ne peuvent pas/ne veulent pas cartographier).

Δ-citoyen OSM

  • Ajouter une rue manquante — quelques minutes par un contributeur expérimenté.
  • Corriger une erreur — quelques minutes à heures.
  • Imports massifs (e.g. cadastre national d'un pays) — discussions communautaires sur plusieurs mois pour valider les conditions de licence et de qualité.
  • Changements de schéma (e.g. comment représenter un nouveau type d'objet) — débats sur le wiki OSM, RFC formelles, consensus communautaire — plusieurs mois.

Sovereign Tech Fund (Allemagne, 2022-)

Récit empirique

Le Sovereign Tech Fund (STF) est une initiative gouvernementale allemande lancée fin 2022 par le Bundesministerium für Wirtschaft und Klimaschutz (BMWK, ministère fédéral de l'Économie et de l'Action climatique) sous le gouvernement Scholz. Mission : financer publiquement les infrastructures critiques open source dont dépend l'économie et la sécurité mondiales et qui sont maintenues bénévolement par quelques personnes.

Quelques projets financés :

  • curl (Daniel Stenberg, suédois, mainteneur principal de l'utilitaire de transfert HTTP universellement utilisé) — finance partielle de son travail à plein temps.
  • OpenSSL (suite cryptographique fondamentale, scène de la faille Heartbleed 2014) — soutien à l'équipe de mainteneurs.
  • GnuPG (suite cryptographique de signature et chiffrement, base de la sécurité email PGP) — finance Werner Koch, mainteneur principal historique.
  • Sequoia-PGP (alternative moderne en Rust à GnuPG) — projet émergent.
  • Plein d'autres — certaines dizaines de projets en 2024-2026, pour un budget annuel ~10-15 millions d'euros (modeste mais croissant).

Importance métacratique

Le STF est paradigmatique pour la métacratie publique pour plusieurs raisons :

  1. Reconnaissance étatique de la dépendance massive de l'innovation néolibérale aux Communs numériques. L'État allemand reconnaît officiellement que les Big Tech exploitent gratuitement ces Communs — sans contribuer durablement à leur maintenance — et que cette situation est politiquement instable.

  2. Cas Mazzucato symétrique — l'État européen public re-finance les Communs que le privé exploite. Au lieu de la R&D fondamentale captée par le privé (Mazzucato classique cf. 04), le STF finance la maintenance fondamentale captée par le privé. C'est un mouvement de re-publicisation partielle.

  3. Modèle reproductible ailleurs en Europe et au-delà. Plusieurs gouvernements observent le STF et envisagent des dispositifs similaires :

    • France — l'ANSSI ou la DINUM pourraient porter un programme similaire. Discussions en cours en 2024-2026, sans décision encore.
    • UE — la NIS2 directive (2022, application 2024+) reconnaît l'importance des Communs critiques mais sans financer directement.
    • US — le programme Open Source Security Foundation (OpenSSF) est plutôt une initiative privée (consortium de Big Tech) qui ressemble au STF allemand mais sans la légitimité publique.

  4. Valeur démocratique — le STF est une innovation publique au sens fort. Il prend une décision politique (financer les Communs critiques avec de l'argent public), il l'applique transparentement (les bénéficiaires sont publics), il est sujet au contrôle démocratique (Bundestag, Cour des comptes allemande).

Possibilité française

Une possibilité française Sovereign Tech Fund France serait un test empirique du programme métacratique. Si la France lance un dispositif similaire en 2025-2027, et que ce dispositif est porté avec ambition (budget ~30-50 M€/an, gouvernance publique, transparence des financements), c'est une réussite de la métacratie publique sur l'axe écologie numérique-souveraineté.

Si ce dispositif n'est pas lancé, ou s'il l'est mais avec un budget anecdotique (~1-3 M€/an), c'est un échec de la fenêtre d'opportunité 2024-2026 et un signal sur la difficulté du modèle public-européen face aux modèles capturés (cf. 09-bis).

C'est un test de réfutation explicite (cf. 12 section « Test de réfutation »).

Mozilla, Apache, FreeBSD, Debian, NixOS

Cette page mentionne mais ne développe pas substantiellement plusieurs autres Commons numériques majeurs :

Mozilla (1998-)

Issue de la libération du code de Netscape Navigator en 1998. Firefox comme navigateur web alternatif aux dominants (Internet Explorer hier, Chrome aujourd'hui). Mozilla Foundation (Etats-Unis) finance le développement par revenus publicitaires (notamment via le partenariat avec Google qui paye pour rester moteur par défaut), un modèle fragile parce qu'il dépend de Google qui pourrait retirer ce partenariat. Mozilla Corporation (subsidiaire de la Foundation) gère les opérations commerciales.

Firefox a perdu des parts de marché significatives (de ~30% en 2010 à ~3% en 2024 pour le mobile, ~10% pour le desktop). Mais reste alternative crédible au monopole Chrome. Démontre les limites du modèle Common-marchand-mixte face aux Big Tech bien financés.

Apache (1995-)

L'Apache HTTP Server est le serveur web open-source le plus utilisé historiquement (2000s-2010s, dépassé partiellement par nginx ensuite). Plus largement, l'Apache Software Foundation (ASF) coordonne ~350 projets (Hadoop, Spark, Kafka, Cassandra, Maven, Tomcat, etc.) qui constituent l'infrastructure de fait du big data et de nombreuses architectures techniques.

Modèle ASF : meritocratic governance — devenir committer sur un projet ASF s'obtient par contribution démontrée et acceptation par le Project Management Committee. Modèle « federations » selon la typologie Eghbal.

FreeBSD, NetBSD, OpenBSD

Les systèmes d'exploitation BSD sont des alternatives à Linux sous licence permissive (BSD au lieu de GPL). Moins utilisés mais hautement respectés pour leur qualité de code (OpenBSD réputé pour la sécurité). Modèle « clubs » selon Eghbal — communauté plus restreinte de committers.

Debian (1993-)

Debian est une distribution Linux « universelle » et contractuelle. Son Contrat Social Debian définit les engagements démocratiques de la communauté envers ses utilisateurs. Debian a un chef de projet élu annuellement par les développeurs accrédités. Modèle « stewardship » avec rotation démocratique. Démontre qu'on peut combiner gouvernance démocratique (élection) et expertise technique.

NixOS (2003-)

Distribution Linux fonctionnelle qui résout le problème des dépendances par approche reproductible. Innovation technique majeure (langage Nix, store immuable, configuration déclarative) qui change la pratique de la gestion des systèmes. Communauté plus jeune mais en croissance.

Limites communes des Commons numériques

Les cas étudiés ont des limites communes qu'il faut nommer pour ne pas idéaliser :

Soutenabilité financière fragile

Les exemples Heartbleed (2014) et Log4Shell (2021) ont rendu visible la fragilité financière des Communs critiques :

  • Heartbleed (avril 2014) — faille critique dans OpenSSL, qui sécurisait deux tiers d'Internet, maintenue bénévolement par 2-3 personnes sous-financées (en pratique, un seul mainteneur principal à plein temps, soutenu par le projet « OpenSSL Software Foundation » dont le budget annuel était ~2 000 USD avant Heartbleed). La criticité de la faille — qui a forcé la rotation de millions de certificats SSL/TLS dans le monde — a révélé l'asymétrie entre l'importance économique d'OpenSSL (utilisé par toutes les entreprises Internet) et son financement (anecdotique).

  • Log4Shell (décembre 2021) — faille critique dans Log4j, librairie Java de logging utilisée dans ~3 milliards d'appareils. Maintenue par quelques bénévoles, dont la principale était également mal financée. La faille a forcé la mobilisation mondiale (équipes de sécurité travaillant 24/7 pendant des semaines) et a coûté des centaines de millions de dollars cumulés en remédiation.

Le Sovereign Tech Fund allemand est précisément la réponse à ce pattern. Mais il reste petit relativement aux besoins.

Tensions communauté-corporate

Une tension structurelle traverse tous les Commons numériques : les corporate users qui ne contribuent pas.

Wikipedia est massivement utilisée par Google (Knowledge Graph), Apple (Siri), Amazon (Alexa) — ces firmes valorisent à milliards de dollars les données Wikipedia gratuitement, et leurs contributions financières sont marginales par rapport aux bénéfices extraits.

Linux est massivement utilisé par AWS, Azure, GCP — ces firmes facturent des milliards à leurs clients pour des services qui s'appuient sur Linux gratuit, et leurs contributions au kernel sont significatives mais asymétriques par rapport aux profits.

Les coursiers Uber utilisent OpenStreetMap gratuitement pour leurs apps de cartographie — sans contribution financière à OSM Foundation.

Cette asymétrie n'est pas sanctionnable formellement (les licences permissives le permettent). Mais elle pose la question politique : comment financer durablement les Communs si les acteurs qui les exploitent le plus n'y contribuent pas proportionnellement ? Le STF allemand est un début de réponse public-public ; d'autres réponses seraient possibles (taxation des Big Tech avec affectation au Common, reverse-engineering des contributions exigées par licence).

Reproduction des biais Bourdieu

Les Commons numériques ne sont pas automatiquement diversifiés. Les contributeurs sont massivement issus du Nord Global, des classes moyennes ou supérieures, masculins, avec capital culturel élevé. Wikipedia : ~85% éditeurs masculins. Linux : ~5-10% femmes parmi les contributeurs. OSM : asymétrique selon les régions (Europe occidentale bien couverte par contributeurs locaux ; Afrique subsaharienne couverte principalement par contributeurs occidentaux distants).

Cette reproduction n'est pas l'effet d'une politique intentionnelle d'exclusion — c'est l'effet structurel des capitaux pré-distribués (cf. 04). Les personnes qui peuvent contribuer aux Communs numériques sont celles qui ont déjà le temps libre, l'éducation technique, l'accès à Internet stable, la culture anglo-saxonne dominante, le capital symbolique pour se faire entendre. Ces personnes sont statistiquement masculines et nordistes.

Renverser ce biais exige des programmes spécifiques (outreach, mentorat, bourses, allocation de temps de travail rémunéré sur les Communs pour des publics sous-représentés). Wikimedia, Wikimedia France, OpenStreetMap, Mozilla mènent ces programmes avec des résultats partiels.

Risque thermidorien

(Cf. 12 sur le thermidor.) Tous les Commons numériques sont exposés à la capture post-installation. Patterns documentés :

  • OpenAI a démarré comme organisation à but non-lucratif (2015), a basculé en partiellement commerciale (2019), et a maintenant une structure hybride avec OpenAI Inc. (non-lucratif) et OpenAI LP (à profit, contrôlée par Microsoft à 49%). Le modèle initial open a été progressivement fermé — les modèles GPT-4+ ne sont plus open source.
  • Elastic (moteur de recherche open-source) a fork hostile en 2021 sa propre licence pour empêcher AWS d'utiliser Elastic gratuitement. La licence est devenue moins permissive (passage de Apache 2.0 à Server Side Public License puis Elastic License v2). AWS a fork Elastic en OpenSearch (Apache 2.0). Cas paradigmatique de tension corporate-Common qui mène à fragmentation.
  • MongoDB, CockroachDB, Confluent ont fait des changements de licence similaires pour empêcher les Big Tech (notamment AWS) d'exploiter leur Common sans contribuer.

Ces cas montrent que les Commons numériques sont fragiles face aux pressions corporate. Les clauses anti-thermidoriennes (copyleft fort AGPL, gouvernance constitutionnellement distribuée, droit de fork garanti) sont nécessaires pour la pérennité.

Articulation avec le projet métacratique

Citizen.Dsl + Commons.Dsl + LesLois.fr (cf. 12 et blog/metacratie-compilateur/08-commons-citizen.md) empruntent les patterns de gouvernance éprouvés par Wikipedia/Linux/OSM. La proposition n'est pas naïve — elle est référencée.

Concrètement :

  • De Wikipedia : la culture de bonne foi (Reagle), les principes éditoriaux explicites (NPOV adapté au juridique = Neutrality of Legal Point of View), les Talk pages comme mécanismes de discussion, les comités d'arbitrage électifs, le consensus comme méthode formelle.
  • De Linux : la stewardship graduée (mainteneur de territoire, mainteneur de cadre, BDFL si nécessaire mais idéalement non), la mailing list publique pour traçabilité, le copyleft fort (AGPL équivalent juridique).
  • De OSM : la cartographie territoriale collaborative comme analogue de la cartographie juridique territoriale (Law.France2026 + chaque territoire avec son cadre).
  • De STF : le financement public des Communs juridiques critiques.

Le programme métacratique n'est pas une utopie sans précédent. Il est une transposition d'un savoir-faire de gouvernance distribuée éprouvé sur les Commons numériques, vers le domaine juridique-politique. La transposition exige des adaptations (le droit a des spécificités que le code n'a pas — cf. metacratie/comment-les-dsls-communiquent.md) — mais le pattern fondamental est validé empiriquement.

Trois modèles de gouvernance des cadres juridiques

Le doc blog/metacratie-compilateur/16-qui-va-ecrire.md du blog technique développe trois modèles de gouvernance pour les cadres juridiques Law.${Space}${Time}.${Author} :

Modèle 1 — Étatique

Un cadre juridique national est écrit par l'État via DGFiP/Légifrance/Conseil constitutionnel. C'est le modèle dominant 2026 — Law.France2026.RépubliqueFrançaise. La signature ${Author} est l'État.

Avantages : autorité juridique reconnue, capacité d'application, ressources étatiques.

Inconvénients : capture par les nommés (cf. 01-bis), Δ-citoyen long, opacité partielle des arbitrages.

Modèle 2 — Fédéré façon Wiki

Le cadre est écrit collectivement par une communauté de juristes-citoyens, gouvernée par discussion comme Wikipedia, avec autorité éditoriale graduée. Pour Law.France2026.Wiki :

  • Talk pages sur chaque article du Code Civil/Pénal/Commerce/Travail.
  • Arbitration Committee élu par la communauté pour les conflits éditoriaux durs.
  • Principes éditoriaux (NPOV juridique : présenter les jurisprudences sans en privilégier une ; Vérifiabilité : chaque assertion sourcée par texte officiel ou jurisprudence ; No Original Research : pas d'interprétation sans source).
  • Consensus comme méthode formelle.

Ce modèle existe partiellement en pratique — Wikilegal, Légipédia, certains projets académiques — mais sans la masse critique d'une Wikipedia juridique reconnue.

Modèle 3 — Radicalement ouvert

Fork-able comme Linux, gouverné par maintainers + benevolent dictator. Pour Law.Citoyen2026.Free :

  • N'importe quel citoyen peut forker le cadre national pour produire sa version (avec ses interprétations, ses ajouts, ses critiques).
  • Une communauté de maintainers fait tourner le cadre forké, accepte/refuse les patches, intègre.
  • Pas d'autorité unique — c'est la qualité du cadre forké qui détermine sa diffusion (effet de réputation comme Linux).

Ce modèle est plus radical — il suppose que les citoyens prennent au sérieux leur droit de fork, et qu'ils exercent ce droit même sans application immédiate. C'est une gymnastique citoyenne — pratique de l'auto-institution même quand elle n'est pas reconnue.

Coexistence des trois modèles

Le point central : les trois modèles peuvent coexister simultanément dans META(Ex × Ty). Chaque combinaison Espace × Temps × Auteur peut choisir son modèle. La métacratie publique ne dit pas « il faut le modèle Wiki » — elle dit « il faut que les trois modèles soient possibles, et qu'aucun ne capture les autres ».

Concrètement :

  • Law.France2026.RépubliqueFrançaise (étatique) coexiste avec Law.France2026.Wiki (fédéré façon Wiki) coexiste avec Law.France2026.Citoyen.Free (radicalement ouvert).
  • Les trois sont compilables par le compilateur métacratique.
  • Les trois sont traçables et signables.
  • Les trois peuvent dialoguer (un article de Law.France2026.Wiki peut citer son équivalent dans Law.France2026.RépubliqueFrançaise et expliquer pourquoi il diffère).

Wikipedia, Linux, OSM sont les preuves empiriques que les modèles 2 et 3 fonctionnent. La résistance majeure à leur adoption pour le droit est métacratique — l'État, la finance, l'académie ne reconnaissent pas la légitimité des modèles 2-3 pour le droit. C'est exactement la question de 02 — qui dit ce qu'est l'innovation, qui dit ce qu'est un cadre juridique légitime.

Mermaid — Modèles de gouvernance comparés

Diagram

Quatre modèles de gouvernance des Commons numériques étudiés — Wikipedia (federation par discussion, comités d'arbitrage élus, principes éditoriaux explicites, consensus), Linux (stewardship + maintainers, mailing list publique, copyleft GPL fort), OpenStreetMap (Foundation + working groups + communautés locales + missions humanitaires), Sovereign Tech Fund allemand (financement public des Commons critiques). La métacratie publique emprunte ces patterns pour le programme constructif (cf. 12).

Conclusion

Les Commons numériques empiriques démontrent que le paradigme public peut produire des innovations qui scalent et durent. Wikipedia, Linux, OpenStreetMap, Mozilla, Apache, Sovereign Tech Fund — toutes ces réussites sont invisibles aux énonciateurs canoniques (cf. 02) parce qu'elles ne sont pas monétisables directement, mais elles fonctionnent matériellement et elles transforment l'infrastructure mondiale.

Le programme métacratique (cf. 12) ne propose pas une utopie sans précédent. Il transpose le savoir-faire de gouvernance distribuée éprouvé sur ces Commons, vers le domaine juridique-politique avec les Citizen.Dsl + Commons.Dsl + LesLois.fr. Les trois modèles de gouvernance (étatique, fédéré façon Wiki, radicalement ouvert) coexistent dans META(Ex × Ty) — chaque combinaison Espace × Temps × Auteur choisit son modèle, et la métacratie publique exige que les trois restent possibles.

Δ-citoyen sur les Commons numériques est empiriquement bas (heures à mois pour la plupart des modifications, années pour les changements constitutionnels — toujours transparents et traçables). C'est radicalement différent des Δ-citoyen vus dans les cas négatifs (4-30 ans selon les cas). La preuve empirique est faite.

Limites connues : soutenabilité financière fragile, tensions communauté-corporate, reproduction des biais Bourdieu, risque thermidorien. Ces limites ne réfutent pas la démonstration empirique — elles imposent la vigilance continue (cf. 12 section thermidor).

Le doc suivant 11 développe la figure du citoyen-validateur-innovateur qui rend possibles ces Communs — Ostrom, Castoriadis, Lex Studio, Lagasnerie comme frère ennemi, et la nuance Spinoza-Élias sur le rôle universel partiel.

Voir aussi :

⬇ Download