Traduction de Where Does Community Live? de Laurens Hof sur Connected Places, le 18 février 2026.
Ce qui m’a toujours intéressé dans les travaux d’Ostrom, c’est qu’elle a montré à quel point la gouvernance des communautés est très variée, avec des règles qui semblent chaotiques en apparence, mais qui partagent une structure profonde sous-jacente. De plus, sa compréhension de la manière dont les communautés s’auto-organisent et s’autogouvernent est pertinente pour le Web social d’aujourd’hui. Partout sur le Web social ouvert, de nouveaux types de communautés se forment, et les gens expérimentent activement le fonctionnement de la gouvernance au sein de ces communautés.
Lors de la conférence Eurosky à Berlin en novembre 2025, le technologue Robin Berjon a fait une déclaration faisant référence à Ostrom et liée aux protocoles : « Les propriétés qui définissent l’architecture d’un protocole et celles qui définissent les règles d’une institution sont les mêmes. » Je pense que c’est en grande partie vrai, mais je pense aussi que l’on peut être encore plus précis.
Le Web social ouvert d’aujourd’hui repose principalement sur deux protocoles, ActivityPub et ATProto, qui ont chacun une vision très différente de la manière d’organiser la vie sociale en ligne. Aucun des deux n’impose une topologie de réseau unique, et tous deux laissent aux personnes qui construisent par-dessus ces protocoles le soin de faire des choix fondamentaux quant à la manière dont l’espace social devrait être structuré. Mais leurs choix architecturaux ne sont pas neutres : ils façonnent et limitent les topologies susceptibles d’émerger, les types de communautés pouvant se former, ainsi que les outils de gouvernance à la disposition de ces communautés.
Cette spécificité est importante, car ce qui se passe actuellement au sein d’ActivityPub et d’ATProto ressemble, à première vue, à un chaos. Il existe des dizaines d’applications, d’expériences communautaires et de modes de gouvernance différents, chacun faisant des choix distincts quant à l’établissement des limites et à la répartition des pouvoirs. Mais tout comme Ostrom a constaté que la diversité des systèmes de gouvernance communautaire peut être généralisée en un certain nombre de règles structurelles communes, la diversité du Web social ouvert soulève également un ensemble commun de questions : où commence et où finit l’appartenance à une communauté, qui établit les règles, comment les violations sont-elles surveillées, et que se passe-t-il lorsqu’une personne enfreint l’entente? Les protocoles ne répondent pas à ces questions, mais ils déterminent quelles réponses sont même possibles.
La façon la plus simple de comprendre ActivityPub est de considérer que les serveurs s’échangent des messages. Une personne sur un serveur peut suivre une personne sur un autre serveur, et lorsque l’une ou l’autre publie quelque chose, son serveur transmet ce message à l’autre. Cette simplicité cache toutefois une question plus profonde : à quoi sert réellement un serveur?
La réponse qui a prévalu pendant la majeure partie de l’histoire de Mastodon est qu’un serveur est une infrastructure. Dans une entrevue accordée à The Verge en 2023, le fondateur de Mastodon, Eugen Rochko, a décrit le produit en des termes qui donnaient l’impression que les serveurs n’étaient qu’un détail d’implémentation. « Pensez-y comme au courriel, et vous comprendrez. Si vous n’aimez pas Gmail, vous pouvez passer à autre chose, mais vous n’avez pas à abandonner complètement le courriel en tant que concept. » Lorsque les utilisateurs se sont plaints de devoir choisir un serveur lors de l’inscription, la réponse de Rochko a été de faire disparaître ce choix : trier la liste des serveurs pour afficher les plus importants en premier, ajouter un bouton « Choisis pour moi » et maintenir mastodon.social accessible par défaut. Il a reconnu que cela rapprochait Mastodon du problème de Gmail qu’il disait vouloir éviter, mais il a présenté cela comme une nécessité, en déclarant : « Cependant, j’ai appris au fil des années que rien ne remplace le fait d’avoir une option par défaut, n’est-ce pas? »
Dans ce modèle, la frontière entre les serveurs est administrative plutôt que sociale. Les utilisateurs font l’expérience d’un réseau unique où le fait que leur compte réside sur un serveur plutôt qu’un autre est, idéalement, une question à laquelle ils n’ont jamais à penser, le serveur se chargeant de la disponibilité, du stockage et de l’application des règles de modération. Le graphe social s’étend librement au-delà des frontières entre serveurs et le fil d’actualité rassemble du contenu provenant de partout, ce qui donne l’impression d’un réseau unique. La topologie est fonctionnellement centralisée même si l’infrastructure est distribuée. Cela résout certains problèmes liés à l’ingénierie et à la répartition du pouvoir, mais sans pour autant créer d’espaces sociaux distincts.
Les dirigeants actuels de Mastodon tentent de s’éloigner de cette approche. Leur nouvelle directrice de la communauté, Hannah Aubrey, décrit Mastodon comme « une porte d’entrée, pas toute la maison », et évoque la mise en avant et le soutien d’autres serveurs plutôt que de canaliser tout le monde vers mastodon.social. Le directeur Felix Hlatky a fait de la répartition des utilisateurs hors de mastodon.social une priorité explicite, soulignant que concentrer les utilisateurs sur un seul serveur « n’est pas le but de la création d’un réseau social ». L’objectif est ambitieux : passer d’environ 10 000 serveurs à 100 000, ce qui, selon Hlatky, « nécessite un changement de mentalité quant à ce que signifie lancer un serveur ».
Dans ce nouveau modèle, la frontière du serveur devient une frontière sociale, et votre expérience de Mastodon est censée être façonnée par la communauté que vous avez rejointe plutôt que simplement par les personnes que vous suivez sur l’ensemble du réseau. Aubrey envisage les créateurs de serveurs comme des « leaders et organisateurs » qui souhaitent bâtir quelque chose pour leur communauté, que celle-ci soit définie par la langue, l’identité, la géographie ou un intérêt commun, en formulant la proposition de valeur en termes d’appartenance : « vous pouvez toujours faire partie d’une communauté avec d’autres personnes de manière sécuritaire et saine ».
Plutôt qu’un réseau unique doté d’une infrastructure distribuée, il s’agit d’un réseau de réseaux où chaque nœud présente une cohésion sociale significative. Newsmast, une organisation basée au Royaume-Uni qui développe une infrastructure ActivityPub pour les éditeurs et les communautés, pousse cette idée plus loin en créant des applications de marque au-dessus des communautés de serveurs individuels, qui combinent les flux communautaires avec le contenu d’un éditeur. La conclusion logique de leur approche est une application par communauté, la fédération servant de lien entre elles.
Lemmy et PieFed, les plateformes d’agrégation de liens de type Reddit sur ActivityPub, compliquent encore davantage la situation. Les communautés (l’équivalent des subreddits) existent sur des serveurs mais sont accessibles à partir d’autres serveurs, créant ainsi une double couche de frontières sociales : une communauté a son propre sujet, ses propres modérateurs et ses propres normes, mais elle réside également sur un serveur qui possède ses propres administrateurs et ses propres politiques de modération. Lorsque des utilisateurs d’un serveur participent à une communauté hébergée sur un autre, on ne sait vraiment pas quelles normes s’appliquent. Les limites du serveur et celles de la communauté se chevauchent sans s’aligner, produisant une topologie de juridictions mixtes que personne n’a encore pleinement compris comment régir.
(PieFed dispose également d’une fonctionnalité appelée « Sujets », qui regroupe les publications de plusieurs communautés dans un seul fil d’actualité autour d’un thème unique, ce qui transforme la question de la compétence en un véritable fouillis réjouissant : une même publication peut être rédigée par quelqu’un sur le serveur A, publiée dans une communauté hébergée sur le serveur B, puis regroupée dans un sujet hébergé sur le serveur C. Que se passe-t-il lorsque les règles des serveurs A, B et C entrent en conflit? Nul ne le sait.)
Le point important ici est qu’ActivityPub ne prescrit pas une topologie unique. Le protocole est suffisamment flexible pour que chaque application fasse un choix fondamentalement différent quant à l’importance sociale des limites des serveurs. Vers 2023, Mastodon traitait les serveurs comme une infrastructure invisible; en 2026, Mastodon souhaite que les serveurs soient des communautés. PeerTube les traite comme des contenants institutionnels pour des bibliothèques vidéo auto-hébergées, la fédération étant une fonctionnalité secondaire. Lemmy superpose des communautés aux serveurs, créant ainsi des frontières qui se chevauchent.
Dans ATProto, chaque utilisateur dispose d’un serveur de données personnelles (PDS) qui stocke son contenu sous forme d’enregistrements structurés, et les applications n’hébergent pas ces données mais les lisent à partir de ce serveur. Le modèle mental s’apparente à un lac partagé de données publiques : chaque PDS y apporte son flux, et chaque application en extrait le sous-ensemble pertinent pour son objectif. Une application de microblogue lit les messages, tandis qu’une application vidéo lit les enregistrements vidéo et qu’une plateforme d’hébergement de code lit les référentiels, le tout à partir du même bassin de données, à travers des prismes différents. Là où ActivityPub s’organise autour du serveur en tant qu’unité sociale, ATProto s’organise autour des données.
Bluesky est l’application dominante construite sur ATProto, et pour la plupart des utilisateurs, il s’agit simplement d’un réseau social semblable à Twitter. La formation de communautés sur Bluesky est censée se faire par le biais de flux personnalisés, et la chef de la direction de Bluesky, Jay Graber, a présenté ceux-ci comme l’innovation centrale de la plateforme. « L’algorithme, plus que le type de contenu ou l’apparence de l’application, est au cœur des médias sociaux, car il détermine la façon dont vous y portez votre attention », a-t-elle écrit en 2023, décrivant l’objectif de Bluesky comme étant de remplacer l’« algorithme maître » contrôlé par une seule entreprise par un « marché d’algorithmes » ouvert. Le discours porte systématiquement sur le choix et le contrôle individuels : ce que vous voyez, ce que vous faites défiler, ce à quoi vous vous abonnez. La FAQ de Bluesky elle-même met explicitement en évidence le contraste avec Mastodon : « Sur Mastodon, c’est votre instance, ou serveur, qui détermine votre communauté… Sur Bluesky, votre expérience repose sur les flux et les comptes que vous suivez, et vous pouvez toujours participer à la conversation mondiale. »
Mais la communauté n’est pas un problème d’attention. Les fils d’actualité organisent ce que les individus voient sans créer d’espaces partagés, de gouvernance partagée ni d’appartenance partagée. Dans la mise en œuvre par défaut de Bluesky, vous faites défiler un fil d’actualité, mais vous n’en faites pas partie. L’absence d’infrastructure communautaire au niveau du fil d’actualité découle directement de la raison d’être de ces fils : ils répondent à un besoin de curation individuelle, et non d’organisation collective. Il ne s’agit toutefois pas d’une contrainte au niveau du protocole, comme le démontre le cas de Blacksky : un fil d’actualité peut intégrer une infrastructure communautaire lorsqu’il est délibérément conçu à cette fin, avec une modération dédiée et une adhésion explicite. Mais les possibilités offertes par Bluesky favorisent le modèle de consommation passive plutôt que celui de création de communauté.
Cela pose un problème à quiconque tente de bâtir une véritable communauté sur ATProto. Blacksky, qui dessert la communauté noire sur Bluesky, montre ce qu’il faut réellement pour y parvenir. Son approche a consisté à construire d’abord une identité communautaire, en commençant par un fil d’actualité personnalisé qui créait un sentiment d’espace partagé, puis en mettant progressivement en place son propre hébergement PDS, son propre système de modération, son propre relais et sa propre interface d’application. Leur relais de modération revêt une importance particulière, car il permet à n’importe quelle application du réseau de se connecter au système de modération de Blacksky plutôt que de dépendre uniquement de celui de Bluesky. De plus, leurs récents travaux sur les publications privées constituent la rupture la plus explicite avec le principe par défaut d’ATProto selon lequel toutes les données sont publiques, créant ainsi un espace clos là où le protocole présuppose l’ouverture.
D’autres applications axées sur la communauté font face à des tensions similaires. Gander (Canada), Eurosky (UE) et Northsky (communauté queer) ciblent chacune des populations spécifiques tout en conservant une vue d’ensemble du réseau, et on ne sait pas encore clairement comment cela se traduira dans la pratique : sera-ce l’identité communautaire ou l’accès à l’ensemble du réseau qui deviendra l’expérience principale? Elles tentent de créer des espaces sociaux délimités par-dessus un protocole conçu pour être sans frontières.
Il existe ensuite des applications qui ne visent absolument pas à créer des espaces communautaires sociaux, et c’est peut-être là que l’architecture d’ATProto trouve le plus naturellement sa place. Tangled est une plateforme d’hébergement de code dotée de fonctionnalités sociales, plus comparable à GitHub qu’à Twitter. Margin.at permet aux utilisateurs d’écrire des annotations sur des pages Web visibles par les autres utilisateurs, un renversement intéressant où la couche applicative s’étend à l’ensemble du Web et où ATProto fonctionne comme une infrastructure invisible en arrière-plan. Germ, une application de messagerie, utilise le système d’identité d’ATProto (DID:PLC) pour l’identité des utilisateurs, mais construit son infrastructure de messagerie proprement dite entièrement en dehors du protocole. Blento vous permet de créer des sites Web personnels, dont les données sont stockées sur votre propre PDS.
Bien que l’architecture d’ATProto tende vers une topologie sociale plate avec des données globales, il ne s’agit pas d’une contrainte stricte, et elle peut également être utilisée pour créer des espaces sociaux distincts.
Les deux protocoles posent des problèmes diamétralement opposés en matière de formation de communautés : ActivityPub établit des limites, mais rend celles-ci difficiles à percevoir de l’extérieur, tandis qu’ATProto rend l’ensemble du réseau navigable, mais n’offre aucune limite naturelle.
Dans ActivityPub, les serveurs sont censés être des communautés, mais l’architecture ne prend pas en charge les mécanismes sociaux par lesquels les communautés se forment réellement. Vous ne pouvez pas visiter un autre serveur ou parcourir les conversations d’une autre communauté comme vous le feriez en entrant dans un bar de quartier. Et bien qu’il soit possible de suivre des individus au-delà des frontières entre serveurs, on ne peut pas être présent dans un espace sans y associer son identité. Les communautés, comme l’ont observé depuis longtemps les sociologues, ont tendance à se former par le biais de rencontres, en se retrouvant au même endroit au même moment et en découvrant des intérêts communs grâce à la proximité. ActivityPub prend en charge le suivi, mais pas la présence, et la frontière entre serveurs, bien qu’elle ait de l’importance en théorie, n’est pas quelque chose qu’un utilisateur peut percevoir dans la pratique.
Un autre défi lié au concept de « serveur en tant que communauté » réside dans le fait que la personne qui gère un serveur est à la fois l’administrateur de l’infrastructure et le chef de file de la communauté, deux rôles fondamentalement différents qui exigent des compétences distinctes. Hlatky est franc quant à cette réalité : la plupart des gens qui lancent des serveurs « n’ont aucune idée de ce que signifie la modération ». Issus du milieu technique, ils sont confrontés à une vague de pourriel et découvrent peu à peu les responsabilités qui accompagnent la gestion d’un serveur. La vision d’Aubrey, qui considère les créateurs de serveurs comme des « leaders et organisateurs » construisant quelque chose pour leur communauté, décrit une population différente de celle des personnes qui gèrent réellement les serveurs, et le chevauchement entre les compétences d’administrateur système et celles de gestionnaire de communauté est minime. Le projet de Mastodon visant à faciliter techniquement l’hébergement de serveurs risque d’élargir cet écart plutôt que de le combler, car le goulot d’étranglement ne réside pas dans la complexité technique de l’utilisation de Docker, mais dans la complexité sociale liée à la création d’une communauté.
En vertu de la Loi sur les services numériques de l’UE, les exploitants de serveurs sont des entités potentiellement assujetties à la réglementation, avec des obligations de conformité en matière de modération de contenu, de transparence et de protection des utilisateurs. La récente annonce de la stratégie de Mastodon reconnaît cette tension, s’engageant à un audit réglementaire pour « nos propres serveurs » et à explorer « comment ces connaissances peuvent être partagées avec la communauté ». On s’attend désormais à ce que la personne qui gère une instance Mastodon soit à la fois un administrateur système, un animateur communautaire et un fournisseur de services respectueux de la loi.
Le problème de l’interaction entre serveurs met en évidence les limites du modèle « serveur-communauté ». Lorsqu’un utilisateur du serveur B répond à un utilisateur du serveur A, et que le serveur A a établi des normes spécifiques concernant les avertissements relatifs au contenu et la sensibilité des sujets, l’utilisateur du serveur B n’a jamais été confronté à ces normes. L’administrateur du serveur A peut réagir a posteriori en supprimant la réponse, en bloquant le compte ou en se désaffiliant complètement du serveur B, mais il n’existe aucun mécanisme permettant de communiquer ces normes avant que l’interaction n’ait lieu. Il n’y a pas de porte à franchir, pas de règles affichées à l’entrée. Dans le cadre théorique d’Ostrom, le bon fonctionnement des institutions exige que les participants comprennent les règles avant d’agir, que la surveillance soit possible et qu’il existe des sanctions graduelles en cas d’infraction. Un serveur ActivityPub fonctionnant selon le modèle « serveur-communauté » dispose de sanctions, mais les étapes préalables font défaut : les règles ne sont pas visibles pour les personnes de l’extérieur et la surveillance est purement réactive, ce qui signifie que l’institution dispose de pouvoirs d’application, mais non de pouvoirs constitutifs.
Le contre-argument habituel est qu’il est techniquement possible de visiter d’autres serveurs : on peut parcourir un fil d’actualité local via l’interface Web et suivre des membres d’une communauté spécifique. Il existe toutefois une différence entre l’accessibilité technique et l’expérience sociale. Un fil d’actualité local est un flux chronologique brut, dépourvu de tout contexte sur la nature de la communauté, ses normes ou ce qui la distingue. Comparez cela à Reddit, où l’accès à un sous-réddit présente immédiatement l’identité de la communauté comme un élément d’interface de premier plan : son nom, sa description, ses règles, ses modérateurs, son identité visuelle. La communauté est un objet navigable que l’on peut découvrir, évaluer et choisir de rejoindre. Dans ActivityPub, la communauté se résume à des métadonnées associées à un nom d’utilisateur, et même lorsque vous suivez un groupe de personnes à partir d’un serveur, leurs publications apparaissent dans votre fil d’actualité principal mélangées à tout le reste, le contexte communautaire étant supprimé par la couche de présentation. La communauté ne survit pas à l’agrégation, car l’interface ne la préserve pas.
Cela ne signifie pas pour autant que les serveurs ActivityPub ne peuvent pas fonctionner comme des communautés. Certains le font, en particulier lorsque la communauté existait avant le serveur : un auditoire de balado, un forum existant, un réseau professionnel qui a migré en bloc. Mais dans ces cas-là, la cohésion de la communauté s’explique malgré l’architecture plutôt qu’en raison de celle-ci, le serveur fournissant une infrastructure à quelque chose qui était déjà socialement réel. Bâtir une communauté par la rencontre, comme la plupart des communautés se forment en réalité, est beaucoup plus difficile lorsque l’architecture ne fournit aucun mécanisme favorisant la rencontre.
Pour ATProto, la question de savoir où réside la communauté est encore plus ouverte. Dans ActivityPub, la réponse est au moins claire : la communauté réside sur le serveur. Cette réponse peut être structurellement difficile à mettre en œuvre, mais tous les acteurs de l’écosystème partagent une compréhension commune de l’endroit où la communauté est censée se trouver. Dans ATProto, différents projets testent des réponses fondamentalement différentes, et le protocole lui-même reste neutre à leur égard. Vu à travers le prisme d’Ostrom, la question devient : laquelle de ces réponses peut réellement produire des institutions fonctionnelles dotées de règles claires, d’une surveillance significative et de sanctions graduelles?
Le premier candidat est le fil d’actualité. Le cadre conceptuel de Bluesky positionne les fils d’actualité comme le mécanisme principal de l’autonomie des utilisateurs : un marché d’algorithmes remplaçant l’Algorithme unique, donnant aux individus le contrôle de leur attention. Mais comme le précise clairement la FAQ de Bluesky elle-même, la priorité en matière de conception est la participation à la « conversation mondiale », les fils d’actualité servant de couches de personnalisation superposées à cette vue globale plutôt que d’espaces délimités. Sur le plan institutionnel, un fil d’actualité n’a aucune capacité à établir des règles, aucune fonction de surveillance et ne prévoit aucune sanction. Il organise l’attention, mais n’organise pas les gens.
Le deuxième candidat est l’« appview », qui agrège les données du réseau et les présente sous la forme d’une application cohérente, en effectuant des choix concernant l’indexation, l’affichage, la modération et les fonctionnalités. C’est pourquoi le fait que Bluesky ait créé sa propre « appview » est significatif : cela a permis de créer un espace social entièrement indépendant, régi par des modérateurs choisis par la communauté et présentant du contenu sélectionné par celle-ci. Si la communauté vit au sein de l’« appview », alors l’opérateur de celle-ci est le créateur d’espace, et les communautés ATProto se forment autour de quiconque est disposé à construire et à entretenir cette infrastructure d’agrégation.
La troisième réponse est la pile d’infrastructure complète. Là encore, Blacksky en fournit l’exemple, en développant non seulement une « appview », mais aussi l’hébergement PDS, un relais, un système de modération et, à terme, des publications privées. Dans leur modèle, la communauté n’est pas une couche unique, mais un ensemble regroupant l’hébergement des données, la modération, l’expérience applicative et l’application des limites. Il s’agit de la réponse la plus complète sur le plan institutionnel, celle qui se rapproche le plus du cadre complet d’Ostrom, tout en étant également la plus exigeante pour les bâtisseurs de communautés.
Il convient également de noter que cette approche ressemble quelque peu au modèle de serveur ActivityPub, où un seul opérateur contrôle le stockage des données, la modération et l’expérience applicative. La différence réside dans une portabilité et une interopérabilité des données plus faciles, ainsi que dans la séparation de l’identité et des données, ce qui fait défaut à l’architecture liée au serveur d’ActivityPub. Cela implique que les exigences de la gouvernance communautaire peuvent imposer leurs propres exigences architecturales, indépendamment de ce qu’offre le protocole sous-jacent.
La dernière option consiste à se concentrer sur ATProto en tant que système d’identité numérique, où votre identité et vos données persistent d’une application à l’autre, et où vos données résident sur votre PDS. Cela fonctionne comme une sorte d’espace individuel portable : l’« espace » d’un blogueur le suit partout, le logiciel pouvant être remplacé tandis que l’identité et les données restent stables. Ici, les communautés ne deviennent qu’émergentes et éphémères, définies par vos liens sociaux. Selon les termes d’Ostrom, il s’agit de la réponse institutionnelle la plus faible : elle assure la continuité de l’identité, mais ne prévoit aucun mécanisme d’élaboration collective de règles, de surveillance ou d’application. La communauté devient alors quelque chose qui vous arrive par le biais de vos liens plutôt qu’une entité à la gouvernance de laquelle vous participez.
Chacune de ces réponses implique une topologie différente. Si la communauté réside dans les flux, ATProto est plat : un réseau, de nombreuses perspectives, aucune frontière. Si la communauté réside dans les vues d’application, la topologie ressemble au modèle de serveur d’ActivityPub, mais avec une séparation explicite des rôles et la portabilité des données. Si la communauté réside dans des piles d’infrastructure complètes, la topologie se fragmente en un petit nombre de plateformes communautaires faisant l’objet d’investissements massifs, entourées d’un grand nombre d’applications légères qui ne cherchent pas du tout à créer de communauté. Si la communauté réside dans l’identité, il n’y a aucune topologie communautaire collective, seulement des nœuds individuels.
Après plusieurs années de développement, l’écosystème ATProto a donné naissance à exactement une communauté pleinement réalisée (Blacksky) et à un ensemble de projets prometteurs qui n’ont pas encore démontré leur capacité à répondre aux exigences institutionnelles qu’implique une communauté.
ActivityPub et ATProto ne sont pas deux mises en œuvre d’une même idée. Ils représentent deux réponses différentes aux questions suivantes : comment la vie sociale devrait-elle être organisée en ligne, où doivent se situer les limites, qui devrait régir ce qui s’y passe, et que signifie « appartenir »? Ostrom a consacré sa carrière à étudier comment les communautés développent des institutions pour gérer des ressources partagées, et l’une de ses principales conclusions était que les arrangements les plus résilients évoluaient par le biais d’expérimentations locales plutôt que par une imposition externe. Les communautés prospères qu’elle a étudiées n’ont pas adopté un modèle de gouvernance unique; elles ont plutôt tenté différentes approches, ont échoué dans la plupart d’entre elles, et sont parvenues à des règles adaptées aux conditions locales. Ce qui fonctionnait dans un contexte ne s’appliquait pas nécessairement à un autre, même lorsque les ressources et les enjeux étaient similaires.
Le Web social ouvert se trouve dans cette phase expérimentale, et différents projets testent différentes réponses. Mais ces solutions ne sont pas toutes aussi viables, et les topologies qui concentrent les fonctions institutionnelles — c’est-à-dire celles qui combinent l’élaboration des règles, la surveillance et l’application au sein d’un opérateur cohérent — produisent une gouvernance plus résiliente que celles qui répartissent ces fonctions entre plusieurs niveaux ou les laissent émerger de manière organique. Cela vaut aussi bien si le point de départ est un serveur ActivityPub qu’une pile d’infrastructure ATProto. Le protocole façonne les solutions disponibles, mais la gouvernance communautaire a ses propres exigences structurelles, et ces exigences ne sont pas infiniment flexibles.
Cependant, l’expérimentation n’est pas synonyme de succès, et aucun des deux protocoles n’a encore démontré un modèle évolutif et reproductible pour la formation de communautés. ActivityPub apporte une réponse claire à la question de savoir où réside la communauté, mais celle-ci s’avère structurellement difficile à mettre en œuvre. L’architecture d’ATProto suggère un réseau plus individualisé et mondial, mais des projets comme Blacksky montrent également qu’il est possible de bâtir des communautés, même si cela nécessite d’étendre le protocole.
Robin Berjon, s’exprimant à Berlin, a fait remarquer que les propriétés structurelles d’un protocole et celles d’une institution sont identiques. S’il a raison – et les faits semblent de plus en plus indiquer que c’est le cas –, alors la question à laquelle est confronté le Web social ouvert n’est pas de savoir quel protocole l’emportera, mais si l’un ou l’autre de ces écosystèmes est capable de produire les modèles institutionnels dont les communautés qui s’y forment ont réellement besoin.
Cet article vous a plu? Pensez à faire un don! à Connected Places
Liste évolutive des traductions par Gilles en vrac
Les caractères gras dans le texte sont de Gilles.