La plupart des outils qu'une communauté utilise pour échanger sont conçus pour prélever une commission. Pas par malveillance — simplement par structure. Un pourcentage va à un prestataire de paiement, des intérêts vont à une banque, l'attention va à un annonceur et les données partent vers un lieu que personne dans la communauté n'a choisi. BeanPool est conçu pour supprimer ces sorties de valeur.
Post-extraction désigne une infrastructure qui permet aux communautés de créer et de conserver la valeur qu'elles produisent, plutôt que de la voir captée par des intermédiaires. Ce n'est pas un slogan moralisateur. C'est une contrainte sur la façon dont le logiciel peut être conçu — et ce qui l'enfreint n'est pas intégré au code.
Il convient d'être concret, car l'« extraction » reste souvent une notion floue. Lorsqu'un voisin paie un voisin via une plateforme classique, la valeur quitte la communauté par plusieurs portes à la fois :
Le schéma ci-dessus a été soigneusement étudié, et qualifié à plusieurs reprises, par des personnes qui y ont consacré des années de travail. Nous pensons que cette analyse est juste ; notre différence est que nous tentons de bâtir une issue plutôt que de simplement décrire le piège. Si vous souhaitez approfondir l'argumentation complète au-delà de notre résumé, voici par où commencer.
Traite la plateforme comme un modèle économique plutôt que comme une simple technologie : se positionner entre deux groupes qui ont besoin d'interagir, puis prélever une part sur chaque mise en relation. Comme la valeur de la plateforme croît avec le nombre d'utilisateurs, il devient de plus en plus difficile de la quitter à mesure que la commission augmente.
Décrit une seconde extraction qui s'opère parallèlement à la première. L'expérience humaine ordinaire est traitée comme une matière première sans propriétaire, transformée en prédictions sur les comportements futurs et vendue à quiconque tire profit de ces informations. La personne dont proviennent les données n'est pas le client.
La version la plus incisive de la thèse. Ce que perçoit le propriétaire d'une plateforme n'est pas un profit issu d'une production — c'est une rente, facturée pour l'accès à un espace dont il est propriétaire. Le propos de Varoufakis est que cette organisation est plus ancienne que le capitalisme plutôt que plus moderne : un rapport féodal de propriétaire foncier habillé aux couleurs d'une entreprise technologique.
Il existe une expression plus limpide pour désigner ce que l'on ressent face à ce système lorsqu'on le subit — le métayage numérique. Vous faites le travail, sur une terre qui ne vous appartient pas, et le propriétaire prend une part de tout ce que vous récoltez. Cela s'applique aussi bien au chauffeur, au vendeur, au musicien qu'au livreur, ce qui prouve généralement que la description touche à une réalité profonde.
Notre réponse n'est pas de chercher un propriétaire plus bienveillant ou une commission plus faible. C'est qu'il ne devrait y avoir aucune terre à louer au départ. Deux voisins qui échangent un après-midi de travail n'ont pas besoin de transiter par un espace appartenant à quiconque. C'est pourquoi la communauté détient le serveur, le protocole est ouvert à tous pour être exécuté ou adapté, et les seuls frais existants vont aux Communs de la communauté elle-même. Il n'y a aucune position intermédiaire que quiconque puisse monnayer — pas même nous.
Une bonne introduction, si vous préférez la vidéo à la lecture : la vidéo de Benn Jordan, « You Are Witnessing the Death of American Capitalism », qui aborde ces thèmes et renvoie aux trois ouvrages cités ci-dessus.
Les quatre premiers sont déjà opérationnels dans chaque communauté aujourd'hui. Le cinquième, la compensation entre communautés, est développé et n'a été expérimenté qu'entre deux de nos propres communautés de test, pas encore entre des communautés actives réelles. Ils sont décrits en détail dans Les règles.
BeanPool fonctionne en crédit mutuel. Lorsque vous effectuez trois heures de travail pour un voisin, trois heures de crédit voient le jour à cet instant précis — votre solde positif et son solde négatif, créés conjointement par l'échange. Aucune banque ne l'a émis. Personne ne vous l'a prêté. Il n'y a aucun intérêt, car il n'y a aucun prêteur.
C'est le fondement de toute notre conception. Si la masse monétaire doit être empruntée pour exister, un acteur extérieur à la communauté détient une créance sur son travail futur. Si la communauté la crée par ses échanges, personne n'a d'emprise sur elle.
Un solde de zéro signifie que vous avez donné à peu près autant que vous avez reçu. C'est l'état d'équilibre sain, et c'est un objectif radicalement différent de celui fixé par la plupart des économies. Il n'y a aucune récompense à accumuler des haricots, et aucun moyen de les convertir en créance sur quiconque en dehors de la communauté.
Les soldes dormants importants diminuent doucement avec le temps, selon un barème progressif. Cela incite à faire circuler les haricots — en les dépensant auprès de voisins, en les investissant dans des projets locaux — plutôt qu'à les laisser immobiles. Une économie où le moyen d'échange cesse de circuler est une économie qui cesse de fonctionner.
Surtout, ce qui est prélevé n'est pas détruit et n'est pas capté sous forme de profit : cela rejoint le fonds des Communs. Les soldes négatifs ne supportent jamais de frais. Une personne en solde négatif a utilisé le crédit que la communauté lui a accordé, et pénaliser une personne déjà débitrice creuserait le déficit au lieu de faire circuler les haricots — ce qui irait à l'opposé de l'objectif recherché.
Le fonds des Communs conserve ce que collectent les contributions de circulation et les frais d'échange, et ses ressources ont deux vocations : absorber la dette laissée lorsqu'un membre part ou est exclu en étant débiteur, et financer des entreprises et des projets approuvés par les membres via des Décisions qui s'appliquent automatiquement — des outils pour un jardin partagé, du matériel pour un atelier, tout ce qui est proposé et adopté par vote. La communauté décide de ce que son propre excédent permet de construire.
C'est une boucle fermée par construction : la valeur est produite localement, détenue collectivement et réinjectée dans la même communauté.
Lorsque des communautés commercent entre elles, l'extraction peut réapparaître sous une forme plus insidieuse — la ville la plus prospère siphonnant discrètement la plus petite. C'est le problème que John Maynard Keynes a cherché à résoudre à Bretton Woods, et la compensation intercommunautaire de BeanPool s'inspire directement de sa solution.
Les haricots ne franchissent jamais la frontière. Un échange entre deux communautés se règle via une paire de registres de liaison, tenus par chaque serveur, consignant ce que chacun doit à l'autre en travail. Chaque côté fixe sa propre limite sur ce solde — ainsi, une communauté voisine ne peut jamais vous devoir plus qu'un montant choisi par vous à l'avance.
Il en découle deux principes essentiels, qui font que ce dispositif n'est pas un simple plafond de dépenses. Régler ce que l'on doit n'est jamais bloqué — le plafond restreint uniquement l'octroi de nouveau crédit, jamais son remboursement. Et une communauté détentrice d'un excédent ne le laisse pas simplement dormir : plus une ville a de créances sur une autre, plus elle peut lui commander de travaux, transformant ainsi un déséquilibre en reprise d'échanges plutôt qu'en dette stagnante.
Pour clarifier les limites : une communauté en déficit n'est jamais pénalisée pour son déficit — l'argument de Keynes, que nous partageons, est que la pression ne doit s'exercer que sur la partie qui a le pouvoir d'agir pour rééquilibrer la situation. Le seul levier restant, une contribution sur un excédent délibérément laissé inactif, est spécifié et délibérément non implémenté tant qu'il n'aura pas satisfait à cette même exigence d'équité. La compensation s'opère entre paires de communautés plutôt qu'à l'échelle d'un réseau étendu, et chaque gestionnaire de communauté l'active par choix délibéré.
Voici les valeurs fondatrices à l'aune desquelles chaque contribution à BeanPool est évaluée. Elles sont publiées dans le guide de contribution du projet, et elles s'appliquent strictement : tout travail en contradiction avec celles-ci est refusé, quelle que soit la qualité du code.
Nous construisons une infrastructure qui permet aux communautés de créer et de conserver de la valeur plutôt que de la voir accaparée par des intermédiaires. Les contributions introduisant des dynamiques extractives — effets de réseau profitant à un seul acteur dominant, verrouillage propriétaire, monétisation par la surveillance — ne sont pas admises.
Les communautés locales doivent être capables de faire fonctionner leurs propres serveurs, de prendre leurs propres décisions de gouvernance et d'opérer en toute autonomie. Les contributions déplaçant la prise de décision vers une autorité globale, ou rendant l'exploitation locale impraticable, vont à l'encontre des objectifs du protocole.
Le protocole doit être compréhensible par les communautés qu'il dessert — et pas seulement par des ingénieurs en informatique. Les spécifications sont rédigées dans un langage clair dans la mesure du possible, avec les détails techniques disposés en sous-couche.
Aucune fonctionnalité ne doit permettre la transmission de données sans le consentement explicite, révocable et vérifiable de la partie à laquelle elles appartiennent. Les fonctionnalités intrusives pour la vie privée ne seront pas intégrées, quelle que soit leur élégance technique.
Nous mesurons notre réussite à la vitalité des communautés, des écosystèmes et des Communs grâce à BeanPool — et non à des indicateurs de croissance ou au cours d'un jeton.
Une telle affirmation n'a de valeur que si elle peut être vérifiée concrètement :