La raison d’être des protocoles

Photo by Jan Hof /www.janhof.nl Traduction de l’article The Purpose of Protocols par Laurens Hof, sur Connected Places, le 18 mars 2026. Récemment, Paul Frazee, directeur technique de Bluesky, a publié un billet de blogue intitulé « Practical Decentralization » « Le but de la décentralisation », écrit Frazee, « est de garantir les droits des individus et des communautés sur Internet. » Et : « Nous utilisons des protocoles pour définir qui peut faire quoi. La conception des protocoles porte souvent sur le “comment”, mais ce “comment” débouche sur un modèle d’autorité. » De ce point de vue, les protocoles sont des structures de gouvernance dont les choix de conception répartissent le pouvoir, et l’objectif de toute cette entreprise est la protection des droits. La conception de protocoles est une forme de conception politique, et la manière appropriée d’évaluer les protocoles ne réside pas seulement dans leurs propriétés techniques, mais aussi dans les résultats en matière de gouvernance qu’ils produisent. Stafford Beer, le cybernéticien spécialisé en gestion, avait une expression pour ce genre d’affirmation : « La finalité d’un système, c’est ce qu’il fait. » Pas ce qu’il vise, ni ce que ses concepteurs espèrent, mais ce qu’il produit. Si l’on applique ce principe aux quatre décennies d’histoire des protocoles ouverts, la tendance est constante : la conception d’un protocole peut encadrer la manière dont les acteurs opèrent au sein d’un système, mais elle ne peut garantir les conditions qui assurent le fonctionnement de l’écosystème dans son ensemble. Les protocoles plus récents abordent la gouvernance et le pouvoir de manière bien plus directe que leurs prédécesseurs, mais l’écart entre l’intention architecturale et la réalité opérationnelle s’est avéré tenace, même face à la conception la plus réfléchie. Les premiers protocoles Le protocole SMTP, qui achemine le courriel, ne dit pratiquement rien de sa raison d’être : son objectif déclaré tient en une seule phrase, « transférer le courrier de manière fiable et efficace », et cette phrase a constitué la description complète de sa raison d’être tout au long de trois révisions majeures et de plus de quatre décennies. Elle ne dit rien sur qui devrait envoyer ou recevoir des courriels, rien sur la vie privée ou l’identité, rien sur le pouvoir. Le protocole décrit un mécanisme permettant de transférer des messages entre des serveurs; quant au contenu de ces messages, à leur expéditeur et aux conséquences découlant de leur livraison, ce sont là des questions qu’il refuse d’aborder. Le protocole HTTP, qui achemine le Web, est tout aussi succinct : il existe pour « permettre une interaction flexible avec des systèmes d’information hypertextes en réseau ». La proposition originale de Tim Berners-Lee, datant de 1989, est plus détaillée : elle définit le problème en termes de gestion des connaissances au CERN et inclut une exigence explicite de « non-centralisation », principe selon lequel les systèmes d’information doivent pouvoir être reliés entre eux sans nécessiter de contrôle ou de coordination centralisés. Mais le protocole est né d’un contexte institutionnel spécifique, celui d’un laboratoire de physique dont la culture interne considérait l’ouverture comme une hypothèse de travail plutôt que comme un engagement politique contesté. Les protocoles RSS et XMPP suivent le même schéma. RSS n’est guère plus qu’une référence de format de données, sans objectif déclaré. XMPP précise que son objectif est « de permettre l’échange de fragments relativement petits de données structurées sur un réseau entre deux ou plusieurs entités ». Il décrit un mécanisme, mais n’explique pas pourquoi ce mécanisme devrait exister ni quelles valeurs il sert. Les premiers protocoles ouverts décrivent leur fonctionnement en termes purement fonctionnels : ils transfèrent des courriels, diffusent de l’hypertexte, syndiquent du contenu, échangent des données structurées. Ils ne disent rien sur l’importance de ces capacités, sur ceux qu’elles servent, sur les types d’arrangements sociaux qu’elles rendent possibles, ni sur les structures de gouvernance qu’elles tiennent pour acquises. Lorsque ces spécifications utilisent le mot « objectif », elles désignent une fonction technique, et non un but social. Ce silence reflétait une culture d’ingénierie dans laquelle les protocoles étaient considérés comme une infrastructure, et où l’on supposait que l’infrastructure était politiquement neutre. Une route n’a pas d’opinion sur ceux qui l’empruntent, un réseau électrique ne se soucie pas des appareils qui y sont branchés. Les ingénieurs qui ont rédigé ces protocoles, au sein de l’IETF et des communautés qui l’ont précédée, considéraient l’interopérabilité et l’accès libre comme des normes par défaut de l’ingénierie, des propriétés qu’un système bien conçu se doit d’avoir, plutôt que comme des engagements politiques qu’il fallait garantir explicitement. La question POSIWID1The Purpose Of a System Is What It Does concernant ces premiers protocoles est la suivante : qu’est-ce qui arrive lorsqu’on considère les protocoles comme une infrastructure neutre? La permissivité radicale du SMTP, le fait que n’importe quel serveur puisse envoyer des messages à n’importe quel autre serveur sans authentification, a permis à la fois l’universalisation du courriel et celle du pourriel. Elle a également permis au courriel de devenir la couche identitaire fondamentale d’Internet, une fonction pour laquelle personne ne l’avait conçu et qu’aucune partie de sa spécification n’avait anticipée. Le modèle d’autorité centré sur l’hôte du HTTP, dans lequel le serveur fait autorité sur ses ressources, a permis à la fois l’émergence du Web ouvert et la consolidation du Web en une poignée de plateformes. Les couches manquantes pour la gestion de l’état, l’identité, le paiement et la confiance ont été comblées par des acteurs dont les modèles d’affaires ont ensuite déterminé l’orientation du réseau. Le RSS a donné aux éditeurs un moyen de diffuser leur travail de manière indépendante, mais n’offrait aucun mécanisme de curation collective, et le vide laissé par cette absence a été comblé, à terme, par des plateformes algorithmiques. L’architecture fédérée de XMPP reflétait celle du courriel et en héritait les mêmes limites de portabilité, ce qui la rendait vulnérable au même type d’instrumentalisation par les entreprises. Google n’avait pas besoin de briser la fédération XMPP ni de vaincre le protocole selon ses propres règles. Il lui suffisait de cesser de se fédérer, ce qu’il a fait une fois que son réseau propriétaire eut absorbé suffisamment d’utilisateurs pour que l’ouverture du protocole ne serve plus ses intérêts. Dans chaque cas, le silence du protocole sur la gouvernance, le pouvoir et la finalité n’a pas produit un résultat neutre, mais un résultat très spécifique : la concentration du pouvoir entre les mains d’acteurs capables de s’appuyer sur l’infrastructure ouverte du protocole sans être contraints par cette ouverture. Il existe ici une asymétrie fondamentale : la conception d’un protocole peut restreindre la manière dont les acteurs opèrent au sein d’un système, mais elle ne peut garantir les conditions qui assurent le fonctionnement de l’écosystème dans son ensemble. Un protocole peut dire « si vous participez, voici les règles », mais il ne peut pas dire « vous devez continuer à participer » ou « vous ne devez pas accumuler de pouvoir dans les couches adjacentes à celle-ci ». Le silence sur la finalité n’était pas l’absence de politique, mais une politique de non-ingérence, et ses bénéficiaires étaient prévisibles : tous les acteurs qui disposaient des ressources nécessaires pour se développer dans l’espace que les protocoles laissaient sans gouvernance. Des protocoles dotés d’une finalité La spécification d’ActivityPub se définit comme « un protocole de réseautage social décentralisé », mais elle ne dit rien sur les raisons pour lesquelles la décentralisation est importante ni sur ce qu’elle est censée accomplir. Le raisonnement normatif sous-jacent au protocole se trouve ailleurs : les coauteurs d’ActivityPub, Christine Lemmer-Webber et Evan Prodromou, ont longuement écrit sur la liberté des utilisateurs, la résistance au contrôle des grandes entreprises et le Web social en tant que bien commun. La spécification elle-même ne dit rien sur la modération du contenu, la gouvernance communautaire, la prévention des abus ou les rapports de force entre les grandes et les petites instances, et chacun de ces aspects est devenu un défi pratique majeur quelques années après l’adoption du protocole. Les concepteurs avaient des opinions bien arrêtées sur la raison d’être du protocole, mais celui-ci n’a pas codifié, protégé ni même mentionné ces opinions. Alors que les engagements normatifs d’ActivityPub restaient en dehors de sa spécification, Matrix les y intègre directement, y compris la déclaration selon laquelle la communication sécurisée est un droit de la personne. ATProto va encore plus loin, en intégrant des engagements normatifs directement dans sa documentation technique : « l’expression et la portée devraient être deux couches distinctes », et « tout le monde a une voix ». Alors que les générations précédentes de protocoles se contentaient de décrire des mécanismes, les protocoles plus récents énoncent également des missions. Mais ATProto représente quelque chose qui va au-delà de cette évolution. C’est le premier protocole à intégrer des engagements normatifs directement dans sa documentation technique plutôt que de les laisser aux articles de blogue et aux présentations lors de conférences. S’il y a bien un protocole qui a comblé l’écart entre l’intention des concepteurs et la finalité du protocole, c’est celui-ci, ce qui en fait l’exemple le plus éclairant pour se demander si le fait de combler cet écart modifie ce que le protocole produit réellement. Ce que font réellement les protocoles POSIWID, cependant, ne se soucie pas des intentions, pas même des plus explicites. Ce qu’ActivityPub a produit, dans la pratique, c’est un réseau de serveurs exploités de manière indépendante dont la coordination repose sur des relations de confiance bilatérales entre leurs administrateurs. La conséquence pratique est que l’administrateur de votre serveur est l’acteur de gouvernance le plus important dans votre expérience des médias sociaux, plus important que n’importe quelle fonctionnalité de protocole ou norme au niveau du réseau. Il contrôle votre identité, puisque votre adresse prend la forme utilisateur@serveur; vos données, puisqu’elles sont stockées sur son matériel; votre portée, puisqu’il décide avec quels autres serveurs s’associer; et votre capacité à partir, puisque la migration nécessite sa coopération et efface votre contexte social accumulé. Il s’agit d’un contrôle centralisé qui est déplacé, plutôt que supprimé, d’une entreprise vers un administrateur de serveur, et le fait que cela constitue une amélioration dépend de l’échelle : une petite instance gérée par une communauté peut tenir son administrateur responsable d’une manière dont aucun utilisateur de plateforme ne peut tenir une entreprise responsable, mais une grande instance comme mastodon.social reproduit la dynamique des plateformes à plus petite échelle. Le Fediverse n’est pas un ensemble de serveurs interchangeables entre lesquels les utilisateurs individuels se déplacent selon leurs préférences; c’est un réseau de communautés semi-autonomes dont le principal mécanisme de gouvernance est la capacité de rompre la connexion les unes avec les autres. Si l’on applique le principe de Beer, l’objectif du protocole n’est pas le « réseautage social décentralisé », mais quelque chose qui se rapproche davantage de la « souveraineté communautaire exercée par le biais d’une connectivité sélective, les coûts et les avantages de cette souveraineté étant répartis de manière inégale à travers le réseau ». Les grandes instances exercent une influence disproportionnée sur les normes et les modèles de connectivité du réseau. Le blocage au niveau de l’instance, conçu comme un outil de sécurité communautaire, fonctionne également comme un mécanisme coercitif, car la liste de blocage d’une instance populaire devient une norme de facto lorsque les instances plus petites ne peuvent se permettre d’être coupées du centre de gravité social du réseau. L’exclusion, en d’autres termes, est le mécanisme de gouvernance central du fediverse, ce qui est presque l’inverse de ce que l’expression « protocole ouvert » implique habituellement. Il en résulte une gouvernance fondée sur la pression sociale et le pouvoir discrétionnaire des administrateurs, sans mécanismes formels de reddition de comptes, d’appel ou de prise de décision collective au niveau du réseau. ATProto produit une structure différente, avec ses propres défis. La séparation de l’identité et de l’hébergement — ce qui signifie que votre pseudonyme est portable et que vos données résident dans un référentiel signé cryptographiquement pouvant être déplacé d’un serveur à l’autre — résout le problème de verrouillage d’identité qui afflige ActivityPub. Mais la réalité opérationnelle actuelle est également que l’entreprise Bluesky domine l’exploitation de toute l’infrastructure, et qu’elle est au moins trois ordres de grandeur plus importante que d’autres opérateurs comme Blacksky et Eurosky, ce qui signifie que chaque couche que l’architecture était censée répartir est, en pratique, contrôlée par une seule entité. L’architecture du protocole permet la concurrence à chaque couche, mais la dynamique d’un espace de données partagé favorise la convergence vers un seul fournisseur à chaque couche. Non pas parce que le marché n’a pas eu le temps de fonctionner, mais parce que les acteurs d’un espace partagé non réglementé imitent les choix les uns des autres, et que cette imitation s’autoalimente : plus les participants utilisent un service de modération ou un AppView donné, plus celui-ci devient attrayant. Frazee le reconnaît franchement : « Bluesky est encore un acteur trop important. » Il convient de noter que tous les écarts entre l’objectif déclaré et l’objectif révélé ne se valent pas. Une architecture peut garantir certains droits avant d’en garantir tous ceux qu’elle aspire à protéger, et la couche PDS d’ATProto réduit véritablement le coût lié au fait de garder vos données hors du contrôle de l’opérateur principal de l’application. Mais si l’on définit l’objectif d’ATProto en fonction de ce qu’il fait actuellement, la réponse n’est pas « un protocole social décentralisé avec séparation des pouvoirs », mais « un protocole social doté de dispositions architecturales en faveur de la décentralisation, actuellement exploité comme un système quasi-centralisé ». La question de savoir si ces dispositions architecturales se traduiront par une véritable répartition du pouvoir dépend d’évolutions économiques et institutionnelles qu’aucune conception de protocole ne peut garantir. Parmi les protocoles examinés ici, c’est la réalité opérationnelle de Matrix qui se rapproche le plus de son objectif déclaré. Le protocole fait ce qu’il dit faire : il permet une communication fédérée et chiffrée de bout en bout, sans point de contrôle unique. Son adoption par le gouvernement français et l’armée allemande constitue une validation concrète de ses propriétés en matière de sécurité et de gouvernance, ce dont peu d’autres protocoles ouverts peuvent se prévaloir. Mais Matrix montre également où s’arrêtent les capacités de gouvernance au niveau du protocole. Les niveaux de pouvoir au niveau des salles offrent un mécanisme de gouvernance, mais pas un cadre global. Les problèmes épineux de la gouvernance communautaire — notamment comment gérer les mauvais acteurs persistants qui passent d’une salle à l’autre, comment trouver un équilibre entre fédération ouverte et sécurité, et comment financer l’infrastructure de manière durable — ne sont pas résolus par les mécanismes du protocole, mais sont renvoyés aux communautés qui l’utilisent. Où réside la gouvernance? Les protocoles examinés ici couvrent plus de quarante ans, et au cours de cette période, la relation de la communauté des concepteurs avec les questions de gouvernance et de pouvoir a considérablement évolué. Les premiers protocoles ne faisaient aucune mention de ces questions; les plus récents les abordent directement, en énonçant des droits, en définissant des valeurs et en traitant les implications politiques de la conception technique comme faisant partie intégrante du problème de conception. Mais aucun d’entre eux, qu’il reste muet sur la gouvernance ou qu’il en parle explicitement, n’a produit d’explication concrète sur la manière dont les ressources partagées générées par leurs écosystèmes devraient être gérées par les communautés qui en dépendent. La raison en est que ce travail ne peut être accompli dans le cadre des conditions que la tradition de conception des protocoles s’est elle-même fixées. Une tradition de conception fondée sur les droits individuels et la modularité architecturale ne dispose pas des ressources conceptuelles nécessaires pour créer les institutions de gouvernance collective qui assurent la durabilité d’un écosystème, car la gouvernance n’est pas une fonctionnalité pouvant être ajoutée à un protocole, mais un arrangement institutionnel qui opère au-dessus, parallèlement et parfois en tension avec l’architecture technique. Tout protocole qui soutient l’interaction sociale à grande échelle génère des ressources partagées, notamment des communautés interconnectées dont la santé dépend de normes collectives, des index de recherche, une infrastructure de relais, des outils de modération partagés et des écosystèmes logiciels dont la maintenance nécessite une coordination soutenue. Ces ressources n’appartiennent à aucun participant en particulier, mais sont plutôt produites collectivement par les interactions des participants entre eux et avec l’infrastructure partagée. Elles ne peuvent être régies par le seul choix individuel, car leur valeur dépend de la coordination, et elles ne peuvent être régies par une autorité centrale unique sans recréer la dynamique de plateforme que les protocoles étaient censés éviter. Toutes les fonctions qui assurent le fonctionnement d’un écosystème de protocole, telles que l’infrastructure, la lutte contre les abus, la visibilité et la maintenance logicielle, entraînent des coûts réels, et ces coûts ne se répartissent pas uniformément entre les participants de l’écosystème. Ils se concentrent autour des acteurs qui ont les moyens de les assumer, et une fois cette concentration établie, ces acteurs acquièrent un pouvoir de définition des priorités, que l’objectif déclaré du protocole ait ou non prévu leur rôle. Frazee identifie une partie du problème dans sa critique des systèmes d’égal à égal : « Dès lors que l’on introduit des ressources partagées (les index), il faut alors régir ces ressources. C’est là que le peer-to-peer pur échoue; il n’apporte aucune réponse quant à la gouvernance des ressources partagées. » Cette observation est juste, mais elle s’applique à un ensemble d’architectures plus large que ne le laisse entendre le cadre proposé par Frazee. La fédération, y compris celle proposée par ATProto, n’apporte pas de réponse plus satisfaisante à la question de la gouvernance des ressources partagées que ne le fait le peer-to-peer pur. L’architecture en couches d’ATProto est plus modulaire que celle d’ActivityPub, mais la modularité est une propriété structurelle du système, et non un cadre de gouvernance pour l’écosystème qui l’entoure. La séparation entre l’expression et la portée précise qui peut faire quoi au sein de l’architecture, mais elle ne traite pas de la manière dont les décisions collectives concernant l’infrastructure partagée qui soutient à la fois l’expression et la portée devraient être prises, ni par qui. Chaque communauté de protocole est parvenue à une réponse implicite à cette question. ActivityPub délègue la gouvernance au niveau des instances et présume que la responsabilisation locale produira des résultats acceptables à l’échelle du réseau, bien que rien dans le protocole ne le garantisse. ATProto s’appuie sur la concurrence entre les fournisseurs de services comme mécanisme de gouvernance suffisant, ce qui présuppose que les conditions de marché propices à une concurrence significative se concrétiseront. Matrix est celui qui s’est le plus avancé vers une gouvernance institutionnelle, en confiant à une fondation le rôle de gardienne des biens communs, bien que l’autorité de cette fondation découle d’une convention plutôt que d’un mécanisme imposé par le protocole. Quant au SMTP, il se caractérise par son absence totale de position, ce qui constitue en soi une réponse : le vide de gouvernance qu’il a laissé a été comblé par les acteurs disposant des moyens financiers les plus importants. Ce qu’aucun d’entre eux n’offre, c’est ce qui a fait l’objet d’études approfondies dans d’autres domaines, notamment par Elinor Ostrom : des principes de conception pour la gouvernance des ressources en pool commun par les communautés qui en dépendent. La conclusion centrale d’Ostrom était que les communautés peuvent réussir à gouverner des ressources partagées sans privatisation ni autorité centrale, ce qui remet directement en cause l’hypothèse, partagée par les communautés de protocoles examinées ici, selon laquelle les seules alternatives disponibles sont la concurrence de marché entre les fournisseurs et le contrôle centralisé par un seul opérateur. Mais Ostrom a démontré que cette troisième voie nécessite des conditions institutionnelles spécifiques, notamment des limites clairement définies autour de la ressource et de ses utilisateurs, une répartition proportionnelle des coûts et des avantages, des mécanismes de choix collectif permettant aux participants d’avoir leur mot à dire dans l’élaboration des règles, des mécanismes accessibles de résolution des conflits, ainsi que la reconnaissance par les autorités externes du droit de la communauté à l’autogouvernance. L’écosystème des protocoles ouverts, tel qu’il existe actuellement, ne présente aucune de ces caractéristiques au niveau du réseau. Le cadre de « l’éducation civique de l’information » proposé par Frazee va dans la bonne direction : la tradition civique porte précisément sur la relation entre les droits individuels et la gouvernance collective. Mais l’éducation civique de l’information, telle que la décrit Frazee, ne tient compte que de l’aspect des droits, et non de l’autre. Ce qui lui manque, ce sont les mécanismes de choix collectif, les limites communautaires bien définies et les mécanismes accessibles de résolution des conflits qu’Ostrom a identifiés comme des conditions nécessaires pour que les communautés puissent gérer avec succès leurs ressources partagées. Ce cadre identifie l’espace problématique sans pour autant fournir le vocabulaire institutionnel permettant d’y travailler. La trajectoire des protocoles antérieurs a montré assez clairement que le silence sur la gouvernance ne produit pas la neutralité, mais laisse la fonction de gouvernance aux acteurs disposant des ressources les plus importantes. Mais le point le plus important est que les choix de conception des protocoles ne se contentent pas de laisser la gouvernance de côté, mais la façonnent activement, car chaque décision architecturale rend certains mécanismes de gouvernance naturels et d’autres difficiles, voire impossibles. Le fait qu’ActivityPub lie l’identité au serveur fait de la gouvernance au niveau de l’administrateur le choix par défaut naturel. La séparation des couches dans ATProto fait de la concurrence de marché entre les fournisseurs la voie de la moindre résistance. Un protocole n’a pas besoin d’encoder explicitement la gouvernance pour la façonner; il la façonne en déterminant quels mécanismes sont faciles à mettre en place, lesquels sont difficiles et lesquels sont de fait impossibles dans le cadre des contraintes imposées par l’architecture. La communauté des protocoles ouverts a hérité de deux traditions intellectuelles, toutes deux inadéquates face à ce problème : un fonctionnalisme d’ingénierie qui traite les protocoles comme une infrastructure neutre dont les conséquences politiques relèvent de la responsabilité d’autrui, et un minimalisme en matière de gouvernance qui considère toute structure de prise de décision collective comme un vecteur potentiel de la centralisation même que les protocoles étaient censés empêcher. Il en résulte une communauté qui a développé une sophistication exceptionnelle en matière d’architecture technique et de droits individuels, tout en restant largement incapable de s’exprimer sur la gouvernance collective. Pour remédier à cela, la communauté des concepteurs de protocoles devra s’appuyer sur des traditions intellectuelles qu’elle n’a pas encore sérieusement explorées, notamment l’analyse institutionnelle d’Ostrom, la cybernétique organisationnelle de Beer et la littérature plus large sur la gouvernance des biens communs et la conception coopérative. Le fossé de gouvernance s’étend au-delà de la question de savoir qui contrôle l’infrastructure pour toucher aux propriétés épistémiques de l’écosystème lui-même : quelles informations il met en avant, ce qu’il sélectionne, quelle vision du discours public il produit. Lorsque la gouvernance d’une couche de portée partagée est laissée aux lois de l’économie, il en résulte non seulement que des acteurs disposant de ressources importantes contrôlent l’infrastructure, mais aussi que les dynamiques d’information de l’écosystème convergent de manière prévisible, car les mêmes structures d’incitation qui déterminent qui a les moyens d’opérer à grande échelle déterminent également le contenu que ces opérateurs sont récompensés de mettre en avant. Une couche de curation non régie au sein d’une population connectée ne produit pas la diversité que l’architecture permet; elle produit une convergence vers ce avec quoi la population connectée interagit le plus activement, et l’homogénéité qui en résulte n’est que le résultat naturel d’un système dans lequel la portée est régie par la convention plutôt que par la conception institutionnelle. Quel objectif cela sert-il? Pour revenir à l’affirmation de Frazee : « Le but de la décentralisation est de garantir les droits des individus et des communautés sur Internet. » Le mot « communautés » revêt dans cette phrase une importance plus grande que ce que le reste de l’article de Frazee développe. La communauté des concepteurs de protocoles a sérieusement réfléchi aux droits des individus : le droit d’héberger ses propres données, de transférer son compte, de choisir son algorithme, de s’exprimer sans être banni d’une plateforme, de communiquer en toute sécurité. Ces droits sont intégrés dans les protocoles les plus récents, avec plus ou moins de succès. Les droits des communautés sont plus difficiles à définir et à protéger, car ils nécessitent des mécanismes de prise de décision collective, d’application des normes et de pérennité institutionnelle qu’aucun protocole actuel ne fournit au niveau du réseau, et dont même les concepteurs de protocoles les plus avisés ont reconnu qu’ils restaient sans solution. Les droits individuels sans soutien institutionnel ne sont pas autosuffisants : le droit de migrer son compte n’a de sens que s’il existe des fournisseurs alternatifs viables vers lesquels migrer, et l’existence d’alternatives viables dépend de conditions institutionnelles — notamment la viabilité économique, la légitimité de la gouvernance et l’investissement collectif dans une infrastructure partagée — que les droits à eux seuls ne peuvent garantir. La finalité d’un protocole réside dans ce qu’il accomplit, et ce que la génération actuelle de protocoles ouverts a produit, c’est un bien commun dépourvu d’un cadre de gouvernance adapté à sa propre complexité. La décentralisation architecturale n’entraîne pas automatiquement une décentralisation opérationnelle, car la dynamique des espaces partagés dépourvus de gouvernance favorise une convergence mimétique plutôt que le pluralisme que l’architecture permet. Lorsque les participants à un écosystème partagé choisissent de manière indépendante quel relais utiliser, à quel AppView faire confiance, quel service de modération adopter, ils ne font pas ce choix de manière isolée, mais en se référant aux choix des uns et des autres, et la convergence qui en résulte s’autoalimente : ce qui commence comme un modèle d’adoption contingent se cristallise en une convention qui prend l’apparence d’une nécessité. L’infrastructure des médias sociaux utilisée par des millions de personnes est coûteuse, surtout lorsque la vidéo entre en jeu. Les entités qui financent cette infrastructure dicteront l’objectif manifeste du protocole, car elles sont devenues le point central autour duquel la convergence de l’écosystème s’est organisée — ce qui est différent de remporter un marché concurrentiel, même si cela produit un résultat similaire —, et une fois cette convergence établie, l’ouverture théorique de l’architecture n’offre guère de levier pratique pour s’y opposer. La prochaine étape exige que la communauté des concepteurs de protocoles — qui a réalisé de réels progrès dans la définition des droits et la construction d’architectures protégeant l’autonomie individuelle — reconnaisse que la gouvernance des ressources partagées ne peut découler des traditions intellectuelles dans lesquelles elle évolue actuellement, et qu’elle s’appuie plutôt sur des traditions fondamentalement différentes : non seulement l’architecture technique qui donne naissance aux ressources partagées, mais aussi les arrangements institutionnels qui les gèrent, les mécanismes d’action collective qui les soutiennent, ainsi que les principes de conception — tirés de la gouvernance des biens communs, de la cybernétique organisationnelle et de la conception coopérative — qui peuvent contribuer à garantir qu’elles servent les communautés qui en dépendent plutôt que les acteurs les mieux placés pour s’en emparer. C’est là un travail qu’aucune spécification de protocole n’a encore tenté de décrire. La question qui demeure est de savoir quelles formes de pouvoir les protocoles peuvent réellement empêcher, quelles formes ils se contentent de transférer d’un groupe d’acteurs à un autre, et quelles formes ils génèrent silencieusement, car toute fonction partagée doit finalement être régie par quelqu’un, et celui qui la régit acquiert un pouvoir sur les personnes qui en dépendent. Un protocole ouvert qui ne répond pas à la question de la gouvernance recevra tout de même une réponse, mais celle-ci sera rédigée par les acteurs qui se rendront indispensables en premier. Et la réponse que l’économie écrira déterminera non seulement qui contrôle l’infrastructure, mais aussi ce que l’écosystème privilégiera, car les mêmes dynamiques qui concentrent le pouvoir opérationnel concentrent également le pouvoir de curation, et l’environnement d’information qui en résultera reflétera les priorités de celui qui gouverne la couche de portée, que quiconque ait ou non eu l’intention de lui conférer cette autorité. Cet article a été financé par une subvention de la fondation NLnet. – CC BY-SA 4.0 Liste évolutive des traductions par Gilles en vracLes caractères gras dans le texte sont de Gilles. Notes 1The Purpose Of a System Is What It Does