Architecture à double face de Janus : répondre à la course de la Reine Rouge dans l’économie de l’information

Institut de recherche appliquée en théorie des réseaux

ID du document : P3-011

Version : 1.0

Novembre 2025

Résumé

Les applications de plateforme conservent leur pouvoir grâce à l’asymétrie d’information : elles créent des interfaces distinctes pour différentes classes d’utilisateurs tout en masquant les relations entre elles [c.-à-d. DoorDash Dasher (pour les livreurs), DoorDash Order Manager (pour les restaurants) et l’application client DoorDash (pour les clients)]. Nous proposons les « applications à double face de Janus » (JFA) : un cadre qui remplace les interfaces cloisonnées par des architectures transparentes et multirôles où tous les participants accèdent à l’information complète du système. En nous appuyant sur le concept d’État « à double face de Janus » d’Acemoglu et Robinson dans The Narrow Corridor, et en appliquant la théorie contemporaine de la métacommunication, les JFA permettent aux communautés d’exploiter des plateformes de coordination de manière coopérative et sans asymétrie d’information. Cela rend possible une gouvernance démocratique à l’échelle de la plateforme.

1. 1. Le problème : l’asymétrie d’information comme caractéristique architecturale

1.1 Théorie contemporaine de la métacommunication : le fondement architectural

La théorie moderne de la communication a considérablement évolué au-delà des cadres du milieu du XXe siècle, mais les intuitions fondamentales sur la façon dont la communication construit les relations de pouvoir demeurent centrales. S’appuyant sur les travaux fondateurs de Watzlawick, Bavelas et Jackson (1967) sur la pragmatique de la communication humaine, les chercheurs contemporains soulignent que toute communication opère à plusieurs niveaux simultanés :

Distinction contenu/relation :

Toute communication comporte les deux :

• Dimension de contenu : l’information littérale que transmet le message

• Dimension de relation : la métainformation sur la relation entre les communicants qui détermine comment les destinataires doivent interpréter le contenu

La dimension de relation encadre le contenu : elle fournit le contexte interprétatif à travers lequel les destinataires comprennent toute l’information. Le même message de contenu signifie quelque chose de tout à fait différent selon qu’il est communiqué entre pairs ou entre des parties placées hiérarchiquement. La dimension de relation est métacommunicative : c’est une communication sur la manière d’interpréter la communication.

Structures de relation symétriques et complémentaires :

Les systèmes de communication construisent deux types fondamentaux de relations :

• Relations symétriques : fondées sur l’égalité, où les participants disposent d’un accès équivalent à l’information et au pouvoir de décision

• Relations complémentaires : fondées sur la différence, où une partie occupe une position supérieure et l’autre une position subordonnée

Les relations complémentaires ne sont pas problématiques en soi : les relations mentor-élève, expert-novice ou soignant-bénéficiaire remplissent des fonctions importantes. Cependant, lorsque les relations complémentaires deviennent rigides et immuables, elles créent des pathologies de la communication où la partie subordonnée ne peut pas remettre en cause la structure même de la relation.

Intuition architecturale : les systèmes de communication ne se contentent pas de transmettre du contenu : ils construisent et imposent des structures de relation par le biais des informations qu’ils rendent accessibles à tel ou tel participant. Lorsqu’une plateforme accorde un accès asymétrique aux informations de niveau système (économie, algorithmes, données comparatives), elle impose architecturalement une relation complémentaire où l’exploitant de la plateforme occupe la position supérieure permanente.

Les participants de la plateforme ne peuvent pas contester cette structure, car ils n’ont pas accès au niveau métacommunicatif : l’information qui définit elle-même la relation. Cela crée ce que les chercheurs contemporains appellent le « paradoxe structurel » : la plateforme dit aux participants qu’ils sont des agents indépendants ou des partenaires précieux (niveau du contenu), tandis que l’architecture communique simultanément leur position subordonnée (niveau de la relation) en retenant les informations du système.

1.2 Vérification structurelle

Les plateformes contemporaines structurent frais et paiements en plusieurs catégories avec un langage qui met l’accent sur la variabilité et le pouvoir discrétionnaire. La documentation des frais comporte généralement des expressions comme « peut s’appliquer », « susceptible de changer », « varie selon le lieu » et « dépend de la demande » : un langage qui empêche toute vérification, même en principe.

Le problème fondamental : aucun participant ne peut vérifier les affirmations ni comprendre la transaction complète. Considérez ce que chaque classe de participants voit réellement :

Le consommateur qui initie une transaction voit :
├─ Coût de base : [amount]
├─ Frais de service : [variable by undisclosed factors]
├─ Frais de coordination : [percentage that "may increase"]
├─ [Potentially] Frais supplémentaires selon le contexte
└─ Total : inconnu jusqu’à un stade avancé du processus, varie d’une transaction à l’autre

Le consommateur ne peut pas savoir :
• Combien reçoit le prestataire de services
• Comment les autres parties prenantes sont rémunérées
• Quels facteurs déterminent les frais variables
• Si les structures de frais ont changé depuis les transactions précédentes
• Comment la valeur se répartit entre entités locales et entités de la plateforme

Le prestataire de services voit :
├─ Offre de tâche : [compensation for specified work]
├─ [After acceptance] Détails complets de la transaction

Le prestataire de services ne peut pas savoir :
• Le paiement total du consommateur
• Comment la plateforme a calculé la rémunération
• Quelle part représente les différentes catégories de paiement
• Comment la rémunération des autres parties prenantes influe sur l’économie
• Si les montants des offres s’ajustent selon les schémas d’acceptation

Les autres parties prenantes voient :
├─ Notification de la transaction
├─ Leur part : [percentage or fixed amount]

Ces parties prenantes ne peuvent pas savoir :
• Les flux de paiement complets
• Pourquoi leur rémunération a une structure particulière
• Quels sont réellement les coûts d’exploitation de la plateforme
• Si les autres participants comprennent l’économie
• Comment vérifier les affirmations de la plateforme sur les structures de coûts

La caractéristique architecturale : les concepteurs ont intégré cette opacité dans des interfaces d’application distinctes. Chaque classe de participants reçoit juste assez d’informations pour remplir son rôle, et pas assez pour vérifier les affirmations de la plateforme, négocier collectivement ou construire des alternatives.

L’information cachée fonctionne comme la dimension de relation (métacommunication) : elle classifie la manière dont les destinataires doivent interpréter le contenu. La rétention systématique de l’économie du système par la plateforme communique la structure de la relation : « Vous occupez une position subordonnée où vous devez faire confiance à des calculs non divulgués. » L’architecture impose des relations complémentaires où la vérification devient structurellement impossible.

Les prestataires de services ne peuvent pas « prendre le rôle de l’autre » (Mead, 1934) : ils ne peuvent pas voir comment les consommateurs ou les autres parties prenantes vivent la même transaction. L’architecture empêche la compréhension partagée nécessaire pour reconnaître les intérêts communs et coordonner l’action collective.

L’architecture à double face de Janus transforme cela complètement :

Tous les participants voient le même détail de la transaction :

Paiement du consommateur : [total amount]
├─ Coût principal : [amount] → Le bénéficiaire A reçoit : [amount]
├─ Prestation du service : [amount] → Le bénéficiaire B reçoit : [amount]
├─ Opérations de la plateforme : [percentage] → Couvre les coûts opérationnels
│   ├─ Infrastructure : [amount]
│   ├─ Traitement des transactions : [amount]
│   ├─ Développement : [amount]
│   └─ Frais généraux : [amount]
└─ Pourboire facultatif : [amount] → Le bénéficiaire B reçoit : [amount]

La plateforme rend le détail des opérations visible par tous :
• Infrastructure mensuelle : [fixed cost serving transaction volume]
• Traitement des transactions : [per-transaction cost]
• Coopérative de développement : [transparent labor costs]
• Assurances et réserves : [shared cost basis]

Transparence algorithmique :
• Logique d’appariement : [documented, deterministic]
• Aucun facteur de tarification variable caché n’existe
• Structure de coûts opérationnels forfaitaire
• La plateforme publie toutes les méthodes de calcul

Gouvernance démocratique :
• Tout participant peut proposer de modifier les structures de coûts
• Votes réguliers avec modélisation financière complète
• Tous les coûts de la plateforme deviennent vérifiables en temps réel
• Les membres décident collectivement de l’affectation de l’excédent

La transformation : passer de relations complémentaires (hiérarchiques, sans vérification possible) à des relations symétriques (égalitaires, avec vérification intégrée). Les participants peuvent alterner les rôles et vérifier toutes les affirmations, car l’architecture offre à toutes les parties un accès complet à l’information. La dimension de relation passe de « faites confiance à notre autorité » à « vous êtes des pairs dans la gouvernance de cette infrastructure ».

Avantage économique : la communauté peut redistribuer la valeur retenue dans les transactions, par la gouvernance démocratique, sous forme de : rémunération plus élevée pour les prestataires, coûts plus bas pour les consommateurs, qualité améliorée dans tout le système, ou réinvestissement communautaire. La valeur circule localement plutôt que d’être extraite vers des actionnaires lointains.

1.3 Pourquoi « à double face de Janus » ?

Dans The Narrow Corridor (2019), Daron Acemoglu et James Robinson décrivent l’État comme intrinsèquement « à double face de Janus » : il permet l’action collective tout en pouvant devenir un instrument d’oppression. Comme la divinité romaine Janus qui regardait dans deux directions, l’État doit être à la fois puissant (pour coordonner) et responsable (pour empêcher la tyrannie).

La liberté existe lorsque la capacité de l’État et la capacité de la société à contrôler le pouvoir évoluent ensemble. Lorsque le pouvoir évolue plus vite que la capacité de contrôle, la liberté s’érode.

La même dynamique s’applique aux plateformes numériques : les plateformes actuelles coordonnent l’activité économique (face habilitante) tout en extrayant de la valeur par l’asymétrie d’information (face exploiteuse). Le défi architectural : comment construire des plateformes qui conservent le pouvoir de coordination tout en éliminant la capacité d’exploitation ?

Les applications à double face de Janus sont des plateformes qui se tournent simultanément vers plusieurs rôles d’utilisateur tout en maintenant une transparence complète pour tous les participants : assez puissantes pour coordonner, assez transparentes pour empêcher la captation.

2. Architecture à double face de Janus : principes fondamentaux

2.1 Quatre transformations architecturales

1. Interface unifiée multirôle Toutes les classes d’utilisateurs accèdent à la même application avec des vues adaptées à leur rôle, et non à des applications cloisonnées distinctes. Les utilisateurs peuvent changer de rôle d’un seul clic.

2. Transparence totale de l’information Le système rend visibles pour tous les participants les données de niveau système (algorithmes d’appariement, structures de prix, économie de la plateforme). Aucun accès privilégié à l’information n’existe.

3. Attribution réversible des rôles (capacité prosommateur) Les utilisateurs peuvent alterner entre plusieurs rôles ou les occuper simultanément : consommateur, producteur, prestataire de services, investisseur, gouvernant de la plateforme.

4. Gouvernance démocratique intégrée La transparence permet une prise de décision éclairée. Tous les participants votent sur les règles de la plateforme, les structures de frais et les politiques, en comprenant pleinement leurs implications.

2.2 Le basculement métacommunicatif

Toute architecture de plateforme communique simultanément à plusieurs niveaux :

Niveau 1 — Fonctionnalité explicite : « Cet élément d’interface exécute cette action »

Niveau 2 — Relations implicites : les interfaces distinctes communiquent « Vous êtes des classes différentes avec des droits différents »

Niveau 3 — Structure de pouvoir : l’information cachée communique « Les exploitants de la plateforme prennent les décisions »

Niveau 4 — Nature du système : le code propriétaire communique « Ceci est un produit que vous utilisez, et non une infrastructure que vous gouvernez »

Les interfaces de plateforme ne se contentent pas de transmettre de l’information : elles construisent et entretiennent des relations de pouvoir entre les classes de participants. La métacommunication (la communication sur la manière d’interpréter la communication) façonne la compréhension des systèmes sociaux.

Les participants développent leur compréhension en imaginant comment les autres les perçoivent et perçoivent le système. Lorsque les plateformes créent des interfaces distinctes, les participants ne peuvent pas comprendre comment les autres classes d’utilisateurs vivent le système, ce qui empêche la compréhension partagée nécessaire à l’action collective.

Exemple concret de transformation métacommunicative :

Lorsqu’un prestataire de services sur une plateforme traditionnelle voit « Tâche disponible », le message explicite (niveau 1) est fonctionnel. Mais le refus de l’interface d’afficher l’économie complète de la transaction avant l’engagement communique (niveau 3) : « La plateforme contrôle l’accès à l’information en fonction de votre conformité. » Le prestataire ne peut pas voir les perspectives des autres participants, et les autres participants ne peuvent pas voir les contraintes du prestataire. Personne ne peut vérifier l’affirmation de la plateforme selon laquelle l’appariement est optimal.

Dans une application à double face de Janus, la même tâche affiche une information complète : tous les montants de rémunération, toutes les structures de frais, les affectations aux bénéficiaires et la justification de l’appariement.

La métacommunication change complètement :

• Niveau 2 : « Vous êtes des pairs disposant d’une information complète » (et non des subordonnés à l’accès contrôlé)

• Niveau 3 : « Vous pouvez vérifier les affirmations et coordonner des alternatives » (et non « faites confiance à notre autorité »)

• Niveau 4 : « Ceci est une infrastructure que vous gouvernez collectivement » (et non « ceci est notre système propriétaire »)

Le prestataire de services comprend désormais les expériences des autres participants, les flux de valeur complets et les frais généraux de la plateforme. Cette compréhension partagée permet de « prendre le rôle de l’autre » : les participants peuvent imaginer les perspectives d’autrui parce que l’architecture les rend mutuellement visibles.

Les applications à double face de Janus transforment les quatre niveaux :

Niveau 1 : interfaces propres à chaque rôle + information système transparente Niveau 2 : l’application unifiée communique « Vous êtes des participants à un système partagé » Niveau 3 : l’information distribuée communique « Tous les participants contribuent à la prise de décision » Niveau 4 : le code ouvert AGPL-3 communique « Ceci est une infrastructure que vous gouvernez collectivement »

La transformation architecturale ne change pas seulement le flux d’information, mais ce que ce flux lui-même communique sur la relation des participants à la plateforme. C’est pourquoi la propriété coopérative sans transformation architecturale peine à atteindre son potentiel démocratique : la métacommunication de l’asymétrie d’information maintient la concentration du pouvoir, quelle que soit la structure formelle de propriété.

3. Mise en œuvre par développement en salle blanche

Les municipalités qui souhaitent déployer des coopératives de plateforme se heurtent à un problème pratique : les plateformes de coordination dont leurs habitants ont besoin — covoiturage, livraison, logement, services à la personne — n’existent que sous forme d’applications d’entreprise propriétaires. Copier purement et simplement ces plateformes violerait le droit d’auteur. Construire à partir de zéro exige de reproduire des années de travail de développement et d’affinement de l’expérience utilisateur.

La rétro-ingénierie en salle blanche résout ce dilemme. C’est une méthodologie légale permettant de recréer des fonctionnalités logicielles sans accéder au code source original ni le copier. Le processus consiste à séparer strictement l’observation de la mise en œuvre : une équipe documente ce que fait l’application (fonctions et comportements observables), tandis qu’une équipe entièrement distincte construit une nouvelle implémentation uniquement à partir de ces spécifications, sans jamais voir le code original. Les tribunaux ont systématiquement reconnu cette méthodologie comme créant une œuvre légalement indépendante.

Pour les coopératives de plateforme, le développement en salle blanche fait office de méthode de rénovation : il permet aux municipalités de recréer des applications de coordination essentielles qui n’existent pas encore dans le domaine public, de les publier sous AGPL-3 en tant que biens communs permanents, et d’ajouter les fonctions de transparence qui transforment les plateformes extractives en infrastructure démocratique. Chaque mise en œuvre réussie renforce l’ensemble du mouvement coopératif au lieu de créer de nouveaux silos propriétaires.

Cette méthodologie protège les coopératives contre les contestations juridiques susceptibles de détruire les plateformes avant qu’elles n’atteignent une certaine échelle, tout en empêchant l’accaparement par les entreprises des outils développés par la communauté.

3.1 Cadre juridique

La rétro-ingénierie en salle blanche crée des implémentations juridiquement indépendantes :

Étape 1 — Équipe de spécification : documente la fonctionnalité observable, sans détails de mise en œuvre

Étape 2 — Revue du droit d’auteur : vérifie que les spécifications ne contiennent aucun élément propriétaire

Étape 3 — Équipe de mise en œuvre : construit uniquement à partir des spécifications, sans jamais voir le code original

Étape 4 — Extension à double face de Janus : ajoute l’interface multirôle ainsi que les outils de transparence et de gouvernance

Cette méthodologie garantit la conformité juridique tout en permettant la transformation architecturale de l’asymétrie d’information vers la transparence.

Considérations relatives aux brevets

Si la méthodologie de la salle blanche répond aux préoccupations de droit d’auteur, elle ne protège pas intrinsèquement contre la contrefaçon de brevets. Les brevets protègent la fonctionnalité (ce que fait le système) plutôt que l’expression (la manière dont les développeurs écrivent le code), ce qui signifie qu’une implémentation en salle blanche peut tout de même contrefaire des brevets si elle reproduit des méthodes brevetées.

Brevets de plateforme courants :

• Algorithmes d’appariement (p. ex. méthodes d’optimisation pour associer prestataires et consommateurs)

• Mécanismes de tarification dynamique (tarification de pointe, ajustement des frais selon la demande)

• Systèmes de réputation et de notation (méthodologies de notation spécifiques)

• Optimisation des itinéraires et coordination logistique

• Systèmes de suivi et de notification en temps réel

Stratégies d’atténuation :

1. Analyse du paysage des brevets : avant de commencer le développement, les équipes mènent des recherches approfondies de brevets dans les juridictions pertinentes afin d’identifier les brevets existants couvrant la fonctionnalité visée. Des outils comme Google Patents, la base de données de l’USPTO et les recherches professionnelles de brevets peuvent repérer les conflits potentiels.

2. Développement de contournement : lorsque les équipes identifient des brevets, elles mettent en œuvre des méthodes alternatives qui obtiennent des résultats similaires par des approches techniques différentes. Par exemple :

   • Si quelqu’un a breveté l’appariement par proximité avec des critères d’optimisation spécifiques, les développeurs utilisent d’autres objectifs d’optimisation (minimisation de l’impact environnemental, équilibrage de la charge de travail)

   • Si quelqu’un a breveté des algorithmes de tarification dynamique, les développeurs mettent en œuvre des structures de prix transparentes, à tarif fixe ou déterminées démocratiquement

   • Si quelqu’un a breveté des méthodes spécifiques de notation de réputation, les développeurs créent des cadres d’évaluation alternatifs

3. Publication défensive : les équipes documentent et divulguent publiquement les méthodes de coordination, approches algorithmiques et mécanismes de gouvernance inédits qu’elles développent pour les JFA. Cela crée un état de la technique qui empêche d’autres de breveter ultérieurement ces méthodes et établit une liberté d’exploitation.

4. Participation à des pools de brevets : les coopératives peuvent former des pools de brevets ou rejoindre des pools existants (comme Open Invention Network pour les logiciels), où les membres se concèdent des licences croisées, créant des zones exemptes de brevets pour le développement de plateformes coopératives.

5. Considérations géographiques : les droits de brevet sont territoriaux — un brevet délivré dans un pays ne s’applique pas dans les autres. Les équipes peuvent réduire le risque par des déploiements initiaux dans des juridictions comptant moins de brevets pertinents ou des dispositions d’usage loyal plus solides.

6. Différenciation fonctionnelle : les différences architecturales fondamentales des JFA (interfaces multirôles, transparence totale, gouvernance démocratique) exigent souvent des approches de mise en œuvre fonctionnellement différentes qui évitent naturellement de contrefaire les méthodes brevetées spécifiques que les concepteurs ont créées pour des systèmes opaques et hiérarchiques.

Avantage des JFA :

Les exigences de transparence favorisent en réalité l’évitement des brevets. Lorsque toute la logique algorithmique doit être documentée et approuvée démocratiquement, les plateformes développent naturellement des méthodes de coordination plus simples et plus explicables, plutôt que des algorithmes propriétaires complexes susceptibles d’être brevetés. Les processus de gouvernance démocratique tendent vers des règles d’appariement transparentes (proximité géographique, file d’attente chronologique, préférence des membres) plutôt que vers des fonctions d’optimisation opaques.

En outre, l’extension architecturale vers la transparence multirôle exige souvent des implémentations techniques inédites qui constituent des méthodes véritablement différentes, et non de simples reproductions d’approches existantes. Le passage de l’asymétrie d’information à la symétrie nécessite des structures de données, des architectures d’interface et des mécanismes de coordination différents.

Évaluation des risques :

Le risque lié aux brevets varie sensiblement selon :

• Le type de plateforme : les plateformes de logistique et d’appariement font face à une densité de brevets plus élevée que les plateformes de traitement des paiements ou de type place de marché

• La juridiction : les États-Unis comptent plus de brevets liés aux plateformes que la plupart des autres juridictions

• Les spécificités de la mise en œuvre : les approches inédites de la transparence et de la gouvernance démocratique sont moins susceptibles d’entrer en conflit avec les brevets existants créés par les concepteurs pour des plateformes extractives

Approche recommandée :

Pour chaque mise en œuvre d’une JFA :

1. Les équipes mènent des recherches de brevets ciblées pour le type de plateforme spécifique et sa fonctionnalité centrale

2. Les équipes documentent les choix de conception démontrant le développement indépendant et la différenciation fonctionnelle

3. Les équipes privilégient des méthodes de coordination transparentes et gouvernées démocratiquement, distinctes des algorithmes d’optimisation brevetés

4. Les équipes font appel à un conseil en brevets pour les implémentations à haut risque (notamment dans les domaines de la logistique et de la tarification dynamique)

5. Les équipes versent leurs innovations dans les bases de données de publication défensive

Cette approche à plusieurs niveaux répond aux préoccupations relatives aux brevets tout en préservant les objectifs de transformation architecturale au cœur des JFA.

3.2 Développement Janus

La salle blanche traditionnelle reproduit la fonctionnalité existante :

• Interface consommateur → interface consommateur (équivalente)

• Interface prestataire → interface prestataire (équivalente)

• Interface partie prenante → interface partie prenante (équivalente)

• Résultat : plusieurs interfaces distinctes, la même asymétrie d’information

La salle blanche des JFA étend la fonctionnalité de manière architecturale :

• Multiples interfaces cloisonnées → plateforme unifiée avec changement de rôle

• Logique système cachée → algorithmes et économie transparents

• Classes d’utilisateurs distinctes → fluidité prosommateur

• Contrôle centralisé → gouvernance démocratique distribuée

• Résultat : une seule application, transparence totale, capacité coopérative

L’extension ne viole pas le droit d’auteur, car elle crée une fonctionnalité qui n’existait pas dans le système original.

3.3 AGPL-3 comme protection structurelle

NTARI publie toutes les implémentations en salle blanche sous AGPL-3 (licence publique générale Affero de GNU) pour empêcher leur recapture :

Protections clés :

• Copyleft réseau : les développeurs doivent publier sous AGPL-3 les modifications des services réseau

• Partage viral : l’incorporation de code AGPL-3 oblige à publier toute la plateforme sous AGPL-3

• Biens communs irrévocables : le code demeure dans les biens communs de manière permanente

Pour les coopératives :

• Empêche l’acquisition et l’accaparement par les entreprises

• Permet la fédération (plusieurs municipalités partagent la base de code)

• Décourage la concurrence des entreprises (impossible d’incorporer sans ouvrir toute la plateforme)

• Protège l’investissement de la communauté dans les biens communs

AGPL-3 crée un « système immunitaire » contre la captation par les entreprises : une protection architecturale pour l’infrastructure démocratique.

4. Définitions propres aux JFA

Au-delà des pratiques standard de développement open source, les JFA requièrent quatre caractéristiques architecturales qui les distinguent des plateformes conventionnelles :

4.1 Identité unifiée multirôle

Les systèmes JFA doivent maintenir des modèles de données unifiés prenant en charge l’occupation simultanée de rôles. Une seule identité d’utilisateur permet d’assumer plusieurs rôles (consommateur, prestataire, partie prenante, gouvernant) sans comptes distincts. Tous les droits et vues liés aux rôles découlent de cette identité unique. Le changement de rôle ne doit exiger qu’une seule interaction (un clic ou une touche), sans déconnexion ni réauthentification. L’interface doit indiquer clairement le rôle actuel et rendre tous les rôles disponibles immédiatement accessibles.

Pourquoi c’est important : les plateformes conventionnelles séparent architecturalement les classes d’utilisateurs pour maintenir l’asymétrie d’information. L’identité unifiée permet de « prendre le rôle de l’autre » (Mead, 1934) : les participants peuvent vivre le système sous plusieurs perspectives, construisant la compréhension partagée nécessaire à la coordination démocratique telle que la conçoivent les défenseurs du coopérativisme de plateforme (Scholz et Schneider, 2016).

4.2 Transparence totale des transactions

Les enregistrements de transactions doivent capturer et exposer des ventilations économiques complètes, visibles par tous les participants en temps réel :

• Tous les flux de valeur (vers tous les bénéficiaires, montants et justification)

• Structures de frais complètes (ce que couvre chaque frais, méthodes de calcul)

• Coûts opérationnels de la plateforme (infrastructure, traitement, développement, réserves)

• Algorithme d’appariement utilisé (numéro de version, justification lisible par l’humain, alternatives envisagées)

Chaque transaction est liée à sa documentation algorithmique. Les structures de coûts de la plateforme se mettent à jour en temps réel et restent visibles par tous les participants. Toute l’information de niveau système doit être accessible via des API publiques (authentifiées, mais universellement disponibles pour les membres).

Pourquoi c’est important : la transparence élimine l’impossibilité architecturale de la vérification. Lorsque les participants peuvent vérifier toutes les affirmations, l’asymétrie d’information ne peut plus maintenir la concentration du pouvoir.

4.3 Gouvernance démocratique intégrée

Les capacités de gouvernance doivent être intégrées dans les interfaces fonctionnelles, et non isolées dans des systèmes administratifs distincts :

• Les systèmes de propositions incluent une modélisation de l’impact financier intégrée et visible par tous les membres

• Mécanismes de vote accessibles depuis n’importe quelle vue de rôle

• L’état et les résultats de la mise en œuvre sont suivis et publiquement visibles

• Tous les algorithmes d’appariement et de coordination sont approuvés par des processus de gouvernance démocratique

• Les décisions algorithmiques sont journalisées pour la revue de gouvernance et l’amélioration du système

Pourquoi c’est important : séparer la gouvernance des opérations maintient la structure de relation complémentaire. Intégrer la gouvernance dans les interfaces fonctionnelles communique « vous gouvernez cette infrastructure » à chaque interaction.

4.4 Architecture de fédération

L’architecture technique doit prendre en charge la fédération : plusieurs instances indépendantes partageant des standards de protocole et, en option, des données :

• Les instances locales conservent une autonomie totale tout en bénéficiant des effets de réseau

• Les standards de protocole permettent la coordination entre instances sans contrôle centralisé

• Les protocoles ouverts publiés sous AGPL-3 empêchent l’accaparement

• L’interopérabilité empêche les dynamiques du « gagnant rafle tout » de recréer des monopoles

Pourquoi c’est important : la fédération permet aux réseaux coopératifs d’atteindre l’échelle tout en empêchant la consolidation du pouvoir. C’est la réponse architecturale à « les coopératives de plateforme ne peuvent pas rivaliser à grande échelle » : elles ne rivalisent pas individuellement, elles se fédèrent.

5. Programme de recherche

5.1 Questions essentielles

Économiques :

• Quel effet multiplicateur local réel se produit lorsque la valeur reste au sein des communautés ?

• Comment les coûts coopératifs d’acquisition de clients se comparent-ils à ceux des plateformes financées par le capital-risque ?

• Quelles différences d’efficacité opérationnelle émergent de la transparence ?

• Comment la gouvernance démocratique affecte-t-elle la vitesse d’adaptation de la plateforme ?

De gouvernance :

• Quels taux de participation les membres atteignent-ils dans la gouvernance démocratique ?

• Comment la transparence affecte-t-elle la qualité de la gouvernance et la satisfaction des membres ?

• Quelles structures de prise de décision fonctionnent le mieux à différentes échelles ?

• Comment les plateformes fédérées coordonnent-elles la gouvernance entre localités ?

Techniques :

• Quelles fonctions de transparence les membres utilisent-ils et valorisent-ils réellement ?

• Comment les plateformes fédérées peuvent-elles maintenir la coordination sans contrôle centralisé ?

• Quelles barrières techniques empêchent ou favorisent l’adoption ?

• Comment le développement open source affecte-t-il la sécurité et la fiabilité de la plateforme ?

Sociales :

• Comment la propriété coopérative affecte-t-elle la dignité et la satisfaction des participants ?

• Quels facteurs culturels favorisent ou inhibent l’adoption ?

• Comment les communautés passent-elles de plateformes extractives à des plateformes coopératives ?

• Quels cadres éducatifs soutiennent la gouvernance démocratique des plateformes ?

6. Conclusion : instaurer la liberté de l’information

Le capitalisme de plateforme extrait une valeur substantielle par des choix architecturaux qui créent l’asymétrie d’information. La propriété coopérative à elle seule ne peut résoudre cela : les plateformes détenues par leurs membres mais dotées d’interfaces cloisonnées concentrent toujours le pouvoir par le contrôle de l’information. La liberté dépend du maintien de l’équilibre entre la capacité de coordination et la capacité de contrôle. Lorsque les plateformes évoluent plus vite que la compréhension des participants, la liberté s’érode vers un autoritarisme algorithmique. Les institutions démocratiques doivent évoluer à la vitesse de la technologie des plateformes, sinon la liberté décline.

Les applications à double face de Janus offrent l’alternative architecturale : des plateformes transparentes et multirôles où la symétrie de l’information permet une gouvernance démocratique authentique. La capacité technique existe. Les cadres juridiques sont établis. L’argument économique est clair. Reste à construire les premières mises en œuvre, à prouver le modèle et à catalyser la transition du capitalisme de plateforme vers la coopération de plateforme.

Le développement en salle blanche d’applications à double face de Janus par NTARI, sous AGPL-3, crée des biens communs permanents : une infrastructure que les communautés peuvent déployer, modifier et gouverner démocratiquement sans crainte d’accaparement. Les municipalités peuvent faciliter la transition par un financement d’amorçage, des préférences dans les marchés publics et une clarté réglementaire. Les coopératives peuvent adopter des modèles reproductibles, les premiers adoptants accélérant la transition à l’échelle du mouvement. Les développeurs peuvent innover en matière de transparence architecturale, en mettant en œuvre une infrastructure démocratique qui n’existe pas dans les plateformes propriétaires. L’objectif n’est pas de meilleures applications, mais une architecture économique fondamentalement différente qui distribue le pouvoir au lieu de le concentrer.

Comme Janus regardant simultanément le passé et l’avenir, les applications à double face de Janus regardent vers la coordination et la responsabilité : assez puissantes pour organiser une activité économique complexe, assez transparentes pour empêcher la captation et l’extraction. C’est l’infrastructure du corridor étroit. C’est la liberté à l’échelle de la plateforme.

Références

Acemoglu, D., & Robinson, J. A. (2019). The Narrow Corridor: States, Societies, and the Fate of Liberty. Penguin Press.

Mead, G. H. (1934). Mind, Self, and Society: From the Standpoint of a Social Behaviorist. University of Chicago Press.

Scholz, T., & Schneider, N. (Eds.). (2016). Ours to Hack and to Own: The Rise of Platform Cooperativism, A New Vision for the Future of Work and a Fairer Internet. OR Books.

Watzlawick, P., Bavelas, J. B., & Jackson, D. D. (1967). Pragmatics of Human Communication: A Study of Interactional Patterns, Pathologies, and Paradoxes. W.W. Norton & Company.

Contacto: info@ntari.org

« Lorsque le travail est accompli et leur but atteint, le peuple dira : “Nous l’avons fait nous-mêmes.” » — Tao Te King, 17

« La liberté ne surgit pas du vide... Elle est le résultat d’une lutte continue pour équilibrer le pouvoir entre l’État et la société. » — Acemoglu et Robinson