La sagesse des foules
Niccolo Machiavel a observé, dans "Discours sur la première décade de Tite-Live" que :
"Quant à la prudence et à la stabilité des intentions, j'affirme qu'un peuple est plus prudent, plus stable et d'un meilleur jugement qu'un prince. Ce n'est pas non plus sans raison que la voix du peuple a été assimilée à la voix de Dieu ; car nous voyons que les croyances largement répandues s'accomplissent d'elles-mêmes et entraînent des résultats merveilleux."
Dans son livre "The Wisdom of Crowds", James Surowiecki écrit que "dans les bonnes circonstances, les groupes sont remarquablement intelligents, et sont souvent plus intelligents que les personnes les plus intelligentes qui les composent." Il note qu'une intelligence collective produit généralement de meilleurs résultats qu'un petit groupe d'experts, même si les membres de la foule ne connaissent pas tous les faits ou choisissent, individuellement, d'agir de manière irrationnelle.
En d'autres termes, un groupe de personnes choisies au hasard sera en moyenne plus intelligent que quelques experts. C'est une thèse contre-intuitive qui se moque de siècles de sagesse reçue. Les experts dans le domaine de l'intelligence humaine (sociologues, anthropologues, psychologues) n'ont pas adhéré aux opinions de Surowiecki. Il est allé plus loin : ajouter plus d'experts à un groupe d'experts le rendra plus stupide, tandis qu'ajouter des profanes pourrait rendre un groupe stupide à nouveau plus intelligent. Comme toute recette, elle ne fonctionne que dans des circonstances spécifiques.
J'ai découvert Surowiecki lorsque j'ai commencé à travailler sur une recette reproductible pour construire des communautés. Son travail a immédiatement trouvé un écho dans ce que j'avais vécu, et il semblait pouvoir être testé. J'avais à la fois l'occasion de l'appliquer et d'expérimenter avec suffisamment de communautés pour tenter de le réfuter : la base, donc, de la vraie science.
De ce travail est né un processus permettant de créer des communautés en ligne intelligentes, autoguidées et performantes, capables de battre les groupes d'experts à tous les coups. Il s'agit d'une discipline que j'ai baptisée "architecture sociale" et qui m'a permis, pendant un temps, de me qualifier d'"architecte social". (Aujourd'hui, je suis un écrivain en difficulté, ce qui semble plus romantique).
L'architecture sociale, par analogie avec l'architecture conventionnelle, est le processus et le produit de la planification, de la conception et du développement d'une communauté en ligne. Les architectures sociales, sous la forme de communautés en ligne, sont les symboles culturels et politiques et les œuvres d'art de la société numérique. Le XXIe siècle s'identifiera aux architectures sociales qui lui survivront.
En tant qu'architectes sociaux, nous participons à des communautés, nous identifions des modèles naturels efficaces ou développons de nouveaux modèles (que j'appelle "outils"), et nous les appliquons délibérément à nos propres projets. Nous appliquons la psychologie (nos instincts sociaux), l'économie (comment nous créons une richesse commune par la spécialisation et le commerce), la politique (comment nous collectons et partageons le pouvoir) et la technologie (comment nous communiquons). Nous adaptons continuellement notre boîte à outils en fonction des nouvelles connaissances et expériences. Notre objectif est de créer des communautés en ligne qui peuvent résoudre avec précision les problèmes que nous identifions, qui se développent sainement et qui survivent par elles-mêmes.
Les communautés en ligne qui réussissent sont généralement fondées sur un contrat de bénéfice mutuel, qu'il soit implicite ou explicite. En d'autres termes, il est possible de construire une entreprise d'un milliard de dollars basée sur le travail bénévole, chaque participant contribuant pour des raisons égoïstes. Souvent, les participants ne réalisent pas qu'ils font partie d'une communauté ou ne s'en soucient pas. Cependant, chaque action que nous entreprenons est économique. Le "crowd sourcing" est l'exploitation à but lucratif du travail bénévole. Et cela ne fonctionne que si la foule veut vraiment résoudre les problèmes que vous lui soumettez, ou ceux qu'elle découvre.

Plus sage et plus constant qu'un prince
Machiavel n'a pas expliqué ni fourni de preuves de son observation. Cependant, l'idée que la volonté collective est exacte et honnête - vox populi, vox Dei - est omniprésente dans la culture moderne. Elle sous-tend notre appréciation parfois sceptique de la démocratie et justifie nos exigences de transparence et d'accès à l'information. Elle est à la base des économies modernes, fondées sur le libre choix et les marchés libres.
Surowiecki a identifié quatre éléments nécessaires à une foule avisée : la diversité des opinions, l'indépendance des membres les uns par rapport aux autres, la décentralisation et des moyens efficaces de rassembler les opinions. Il décrit la foule sage idéale comme étant composée de nombreux individus indépendants les uns des autres, qui sont vaguement connectés, qui sont géographiquement et socialement diversifiés, qui ne sont pas émotifs à propos de leur sujet, qui ont chacun de nombreuses sources d'information et qui ont un moyen de rassembler leurs jugements individuels en une décision collective.
Selon Surowiecki, la foule sage émet des jugements rapides et précis, s'organise pour faire le meilleur usage des ressources et coopère sans autorité centrale. Certains exemples de foules sages, comme Wikipédia, connaissent un succès extraordinaire malgré les critiques intenses et répétées des opposants et les attaques des vandales et des infiltrés. C'est une proposition tellement convaincante que l'on peut se demander pourquoi il n'y a pas plus de foules sages. En effet, pourquoi le monde est-il rempli de tant de stupidité s'il est si facile d'être intelligent ?
Il existe de bonnes explications à la stupidité de nombreuses foules, et j'en parle en détail dans mon livre "Culture & Empire", dont cette section est tirée. Peu de gens ont essayé d'expliquer la stupidité des groupes en termes de sagesse collective. Et sans une compréhension claire de la fonction, comment pouvons-nous espérer comprendre le dysfonctionnement ?
Ainsi, l'échec apparent de l'intelligence collective en convainc plus d'un qu'il ne s'agit que d'une théorie fantaisiste qui échoue dans la pratique. Et pourtant, si nous observons les communautés en ligne, par exemple celles qui se forment autour de projets de logiciels libres populaires comme ZeroMQ, nous voyons des groupes qui ressemblent beaucoup aux foules sages de Surowiecki. S'il est difficile de repérer les foules sages dans le monde physique, elles semblent être le modèle dominant en ligne. Par essais et erreurs, la société numérique a redécouvert les principes des foules sages et les a adoptés comme principes de fonctionnement de base.
La solution de la société numérique à l'ancien problème de l'autorité corrompue est élégante et réussie. Il existe littéralement des millions de communautés, chacune soutenue par l'autorité de ses fondateurs. Les citoyens de la société numérique choisissent librement les autorités à respecter et celles à ignorer. L'astuce consiste à accepter l'autorité sans lui donner le "droit de commander".
Il y a donc une compétition intense pour développer une autorité juste qui ne commande pas, mais qui applique les règles nécessaires. C'est une vérité profondément subversive. Les générations qui apprennent ce modèle refuseront - jusqu'à la mort - de respecter le modèle de la société industrielle - appliqué par des rideaux de fer et des gardes-frontières armés si nécessaire - où le citoyen appartient littéralement à l'État.
Origines de l'architecture sociale
J'ai parié beaucoup d'argent sur l'architecture sociale, et j'ai fait de bons profits. Elle se rapproche des sciences sociales dures, prouvées par des années d'expériences reproductibles sur des cas vivants et des études de communautés existantes. Elle mélange la psychologie, l'économie, la politique, la technologie, l'humanisme et l'optimisme en quelque chose qui, selon moi, peut rendre beaucoup de gens heureux.
Mon voyage dans l'architecture sociale a commencé à la fin des années 1990, lorsque j'ai commencé à faire des recherches pour un livre sur la façon dont les sectes exploitent nos instincts sociaux. Les sectes ne sont pas des endroits heureux, bien sûr. Cependant, les humains sont attirés par elles parce que nous sommes des animaux sociaux qui, au cours des derniers millions d'années, ont développé des instincts pour rejoindre et se conformer à des groupes afin de survivre. C'est devenu une seconde nature pour nous de respecter facilement l'autorité, de nous conformer, d'apprendre des langues communes et d'adopter un comportement partagé. Les groupes sectaires font subir un lavage de cerveau à leurs membres en exploitant ces instincts. Ils séparent les membres de leur famille, suppriment l'intimité, les inondent de jargon, créent des règles arbitraires, et punissent et récompensent de manière aléatoire.
De cette façon, les sectes peuvent transformer la plupart des gens ordinaires en adeptes irréfléchis qui vident volontairement leur compte en banque, volent leur famille et travaillent pendant des années sans être payés. En tant qu'étudiant observant un ami occasionnel disparaître dans les cavernes de la Scientologie et d'autres sectes, cela m'a paru malin et déroutant. Plus tard, lorsque mon cousin le plus proche a abandonné ses études et a perdu cinq ans de sa vie à cause de la Scientologie, cela est devenu personnel.
En étudiant le site Web du Cult Information Centre (CIC), j'ai été frappé par le fait que ces techniques de lavage de cerveau avaient toutes plusieurs points communs. Premièrement, elles étaient toutes clairement axées sur l'attaque de la pensée et de l'action individuelles, et sur la destruction de ce qui fait notre force. Deuxièmement, elles rappelaient les environnements dans lesquels j'avais travaillé (les grandes entreprises fonctionnent souvent comme des sectes). Troisièmement, elles semblaient toutes réversibles, c'est-à-dire qu'elles pouvaient être inversées pour devenir des modèles positifs.
Ce dernier aspect est surprenant. Si un marteau brise une fenêtre, vous pouvez difficilement rendre une fenêtre plus solide en inversant le marteau. Certains exemples le montrent clairement. Prenez cette technique sur le site du CIC : "Pression du groupe de pairs - Supprimer le doute et la résistance aux nouvelles idées en exploitant le besoin d'appartenance." À l'inverse, en diminuant le coût d'entrée et de sortie du groupe, nous encourageons les nouvelles idées et la critique. Ou encore : "Suppression de l'intimité -- Perte de la capacité d'évaluer logiquement en empêchant la contemplation privée." L'inverse est : donnez aux gens un espace privé et du temps pour réfléchir, et ils deviendront meilleurs pour penser logiquement.
Mes conclusions persistent. Nous survivons en nous attachant à des groupes, en suivant les autres et en essayant de donner un sens au monde. Certains groupes fonctionnent en nous domestiquant et en nous brutalisant. D'autres groupes fonctionnent en nous donnant la liberté et en nous permettant d'être plus forts, plus intelligents et plus indépendants.
En 2000, l'Internet n'était pas encore assez bon marché pour être utilisé par le grand public, et les communautés de logiciels libres étaient petites et souvent régionales, souvent concentrées autour des universités. Les communautés open source telles que la Fondation Debian fonctionnaient encore comme des organisations classiques à but non lucratif, comme des entités légales avec des conseils d'administration, des trésoriers, etc.
En 2005, j'ai rejoint un certain nombre de projets de collaboration. D'une part, j'étais impliqué dans la FFII, qui travaillait pour arrêter les brevets logiciels en Europe. Nous (les gentils) avons pris la parole au Parlement européen, débattu avec l'Office européen des brevets (les méchants), organisé des séminaires, déposé des amendements, obtenu des votes et, plus généralement, pris part au plus grand effort de lobbying jamais entrepris à Bruxelles.
De l'autre côté, je développais des normes ouvertes, en commençant par le protocole AMQP (Advanced Message Queuing Protocol). Le contraste entre les cultures de ces organisations était très fort. La FFII était un groupe de volontaires fous, créatifs au-delà de toute croyance, et remplis d'une froide détermination à empêcher SAP, Siemens, Microsoft et Nokia (d'autres méchants) de changer la loi européenne pour légaliser le marché gris des brevets sur les logiciels. Le groupe de travail AMQP comprenait des banques et de grandes entreprises de logiciels, qui se sont avérées être folles d'une manière différente et moins agréable.
La folie m'entourant de toutes parts, la recherche sur les instincts sociaux et les techniques cultuelles m'a soudain semblé à nouveau pertinente. Avec mes amis de la FFII, nous avons lancé campagne après campagne. Sites web, pétitions, listes d'adresses électroniques, conférences... ça n'a jamais cessé. La plupart de nos campagnes n'ont pas réussi à prendre de l'ampleur, mais quelques-unes ont réussi. Mais surtout, pendant environ trois ans, nous avons expérimenté et recueilli des résultats.
Nous avons appris deux grandes choses. Premièrement, une secte est le revers de la médaille d'une foule sage. Les modèles de secte semblaient exacts, et j'ai vu des gens appliquer le modèle de secte à d'autres personnes, encore et encore. Tout groupe, famille, entreprise ou équipe intense commence à ressembler à une secte, de manière plus ou moins importante. C'est une question de degré. Cependant, dès que vous consacrez votre temps libre au projet de quelqu'un d'autre, vous commencez essentiellement à glisser sur cette pente. J'ai vu des groupes entiers dérailler, incapables de penser correctement ou de produire des résultats précis. Il y avait un effet de causalité direct : plus le groupe devenait sectaire, plus il devenait inutile.
La deuxième chose, c'est qu'il ne suffit pas d'inverser les techniques de la secte. C'est un bon début de promouvoir la force et la créativité individuelles, mais ce n'est pas la même chose que de construire une communauté solide. Pour cela, vous avez besoin de modèles plus explicites. Définissez une mission puissante pour attirer les nouveaux arrivants. Faites en sorte qu'il soit très facile pour les gens de s'impliquer. Acceptez les discussions et les conflits ; c'est de là que viennent les bonnes idées. Déléguez systématiquement et créez de la concurrence. Travaillez avec des bénévoles plutôt qu'avec des employés. Obtenez la diversité et l'échelle. Faites en sorte que les gens s'approprient le travail ; ne laissez pas le travail s'approprier les gens.
Il est bien sûr beaucoup moins cher et plus rapide de faire des expériences à grande échelle avec des personnes en ligne que dans le monde réel. Pour prouver ou réfuter une recette de construction d'une communauté, il suffit de créer un espace, de définir quelques règles du jeu, de l'annoncer au monde entier et de s'asseoir pour observer.
Mon expérience la plus importante et la plus réussie à ce jour, à laquelle je ferai souvent référence dans ce chapitre, est la communauté logicielle ZeroMQ. Elle est passée d'une équipe dans une cave slovaque à une communauté mondiale, et est utilisée par des milliers d'organisations. Par-dessus tout, ZeroMQ est entièrement construit et piloté par sa communauté : plus d'une centaine de contributeurs à la bibliothèque de base, et une centaine d'autres projets autour de celle-ci.
Architecture de la communauté ZeroMQ
Vous savez que ZeroMQ est un projet sous licence LGPL (note de l'auteur : nous nous dirigeons vers la Mozilla Public License v2, qui a le même effet tout en étant plus simple). En fait, il s'agit d'une collection de projets, construits autour de la bibliothèque centrale, libzmq. Je vais visualiser ces projets comme une galaxie en expansion :
À la base, libzmq est la bibliothèque centrale de ZeroMQ. Elle est écrite en C++, avec une API C de bas niveau. Le code est méchant, principalement parce qu'il est hautement optimisé mais aussi parce qu'il est écrit en C++, un langage qui se prête à une méchanceté subtile et profonde. Martin Sustrik a écrit la majeure partie du code original. Aujourd'hui, des dizaines de personnes maintiennent différentes parties du code.
Autour de libzmq, il y a environ 50 bindings. Il s'agit de projets individuels qui créent des API de plus haut niveau pour ZeroMQ, ou au moins qui mappent l'API de bas niveau dans d'autres langages. La qualité des liaisons varie de l'expérimental à l'impressionnant. La liaison la plus impressionnante est probablement PyZMQ, qui a été l'un des premiers projets communautaires à s'appuyer sur ZeroMQ. Si vous êtes l'auteur d'une liaison, vous devriez vraiment étudier PyZMQ et aspirer à rendre votre code et votre communauté aussi géniaux.
De nombreux langages ont de multiples liaisons (Erlang, Ruby, C#, au moins) écrites par différentes personnes au fil du temps, ou adoptant des approches différentes. Nous ne les réglementons pas de quelque manière que ce soit. Il n'y a pas de liaisons "officielles". Vous votez en utilisant l'une ou l'autre, en y contribuant ou en l'ignorant.
Il existe une série de réimplémentations de libzmq, en commençant par JeroMQ, une traduction complète de la bibliothèque en Java, qui est maintenant la base de NetMQ, une pile C#. Ces piles natives offrent des API similaires ou identiques et utilisent le même protocole (ZMTP) que libzmq.
En plus des liaisons, des milliers de projets utilisent ZeroMQ ou se basent sur lui. Certains d'entre eux, comme Zyre et Malamute, font partie de la communauté "officielle", la plupart ne le sont pas.
Libzmq, la plupart des liaisons et certains des projets externes font partie de l'"organisation" de la communauté ZeroMQ sur GitHub. Cette organisation est "dirigée" par un groupe composé des auteurs de liaisons les plus anciens. Il n'y a pas grand-chose à gérer, car tout est presque autogéré et il n'y a aucun conflit ces jours-ci.
iMatix, mon entreprise, joue un rôle spécifique dans la communauté. Nous possédons les marques déposées et les faisons respecter discrètement afin de nous assurer que si vous téléchargez un paquet s'appelant "ZeroMQ", vous pouvez avoir confiance en ce que vous obtenez. En de rares occasions, des personnes ont essayé de détourner le nom, croyant peut-être que le "logiciel libre" signifie qu'il n'y a pas de propriété en jeu et que personne n'est prêt à la défendre. Une chose que vous comprendrez à la lecture de cet article est à quel point nous prenons au sérieux le processus qui sous-tend notre logiciel (et je veux dire "nous" en tant que communauté, pas en tant qu'entreprise). iMatix soutient la communauté en appliquant ce processus à tout ce qui s'appelle "ZeroMQ" ou "ZeroMQ". Nous investissons également de l'argent et du temps dans le logiciel et le packaging pour des raisons que j'expliquerai plus tard.
Il ne s'agit pas d'un exercice de charité. ZeroMQ est un projet à but lucratif, et un projet très rentable. Les bénéfices sont largement répartis entre tous ceux qui y investissent. C'est aussi simple que cela : prenez le temps de devenir un expert de ZeroMQ, ou de construire quelque chose d'utile à partir de ZeroMQ, et vous verrez votre valeur en tant qu'individu, équipe ou entreprise augmenter. iMatix bénéficie des mêmes avantages que tous les autres membres de la communauté. Tout le monde y gagne, sauf nos concurrents, qui se retrouvent face à une menace qu'ils ne peuvent pas battre et à laquelle ils ne peuvent pas vraiment échapper. ZeroMQ domine le monde futur des logiciels massivement distribués.
Mon entreprise ne se contente pas de soutenir la communauté - nous avons également construit la communauté. C'était un travail délibéré ; dans le livre blanc original de ZeroMQ de 2007, il y avait deux projets. L'un était technique, comment créer un meilleur système de messagerie. Le second était de construire une communauté qui pourrait amener le logiciel à un succès dominant. Le logiciel meurt, mais la communauté survit.
Voeux pour que le Web ne devienne pas une Prison Numérique
Décentraliser, renouveler, propager la confiance. La sécurité, le bonheur.
Web3.0 libre