L'état du web décentralisé en 2026

Un réseau social est décentralisé au sens pratique lorsqu’un utilisateur peut changer de fournisseur sans perdre son identité, ses données ou ses abonnés — et ActivityPub, l’AT Protocol et Solid réussissent chacun un sous-ensemble différent de ce test.

Choisir un serveur et suivre quelques comptes, c’est la partie facile. Le vocabulaire qui accompagne ces réseaux (PDS, relais, AppView, Pod, WebID) s’accumule vite, et rien de tout cela n’a vraiment d’importance jusqu’au jour où vous voulez déménager.

Voici un état des lieux des trois protocoles qui comptent aujourd’hui pour le web décentralisé. Il explique comment chacun modélise l’identité, les données et l’audience, précise où en est chacun en matière d’adoption et de spécification, distingue dans les chiffres les comptes enregistrés des utilisateurs actifs, et se termine par un service que vous pouvez mettre en place en une après-midi.

Que signifie « décentralisé » en pratique ?

Décentralisé signifie que vous pouvez quitter l’hébergeur de votre compte et arriver ailleurs avec trois choses intactes : votre identité (le nom sous lequel les gens vous connaissent et les identifiants qui vont avec), vos données (publications, médias, abonnements, réglages) et votre audience (les personnes qui vous suivent et continuent de recevoir ce que vous publiez). Si l’un des trois manque, le changement équivaut à repartir de zéro, avec des étapes supplémentaires.

Chacun des protocoles ci-dessous est évalué à l’aune de ce test, et non du nombre de serveurs existants ni de l’identité des auteurs du logiciel. Le nombre de serveurs renseigne sur la redondance. Le test en trois volets renseigne sur le verrouillage (lock-in).

Comment ActivityPub fédère-t-il les instances entre elles ?

ActivityPub, recommandation du W3C depuis le 23 janvier 2018, fédère en faisant livrer par chaque serveur les activités d’un utilisateur directement dans les boîtes de réception (inbox) des serveurs qui hébergent les abonnés de cet utilisateur. Chaque utilisateur est un acteur doté d’une inbox et d’une outbox ; publier écrit dans votre outbox, et votre serveur envoie l’activité par POST à l’inbox de chaque abonné. Il n’existe aucun index central, seulement des serveurs qui se poussent mutuellement du JSON.

Mastodon, Pixelfed, Lemmy et PeerTube l’implémentent tous, ce qui explique qu’un compte Mastodon puisse suivre une chaîne PeerTube ou une communauté Lemmy.

C’est sur l’identité que le test échoue. Un identifiant tel que @user@instance.example appartient à l’instance : un compte qui n’a pas été migré avant l’arrêt de son serveur ne peut être récupéré nulle part ailleurs. Le déplacement de compte de Mastodon envoie une activité Move qui bascule les abonnés vers le nouveau compte, mais la documentation est claire : tout ce que vous avez publié reste sur place, et l’archive que vous pouvez en télécharger ne peut pas être chargée dans un autre compte Mastodon. Résultat face au test : l’audience survit à un déménagement planifié, les données survivent partiellement sous forme d’export, l’identité ne survit pas du tout.

AT Protocol : identité portable, infrastructure concentrée

Sur l’AT Protocol, l’identité d’un utilisateur est un DID qu’aucun serveur ne possède, et ses publications, abonnements et profil résident dans un Personal Data Server (PDS) qui peut être transféré vers un autre hébergeur sans que le DID change. Au-dessus du PDS se trouvent les relais, qui parcourent tous les PDS et émettent un unique firehose, et les AppViews, qui indexent ce firehose pour en faire le produit que rend un client. La spécification est publiée et maintenue par Bluesky Social PBC.

La portabilité a ses limites. Le guide officiel de migration de compte présente ces étapes comme quelque chose qui se situe en dehors du protocole proprement dit et qui pourra évoluer, et il vous renvoie vers la CLI goat ou un outil communautaire plutôt que vers un flux intégré à l’application. Bryan Newbold, ingénieur protocole chez Bluesky, écrivait en octobre 2025 que le déplacement d’un compte fonctionne sur le réseau en production depuis début 2025, mais que cela reste une affaire de développeurs, et que les hébergeurs PDS exploités par Bluesky n’acceptent pas l’arrivée d’un compte migré.

La seconde réserve est d’ordre opérationnel. Le rapport de transparence 2025 de Bluesky indique que l’entreprise détient plus de comptes que quiconque et constitue le point d’inscription de la majorité des utilisateurs, le reste du réseau étant réparti sur des milliers de Personal Data Servers, pour la plupart exploités par des tiers. Aucun chiffre officiel ne quantifie la part du réseau qui transite par le relais et l’AppView que Bluesky exploite. Les critiques soutiennent que les hébergeurs PDS indépendants et les projets d’infrastructure communautaire s’appuient encore sur des services centraux opérés par Bluesky, et certains en concluent que le réseau n’est pas décentralisé en pratique ; il s’agit d’un jugement, non d’une mesure. Résultat face au test : l’identité et les données survivent par conception à un changement de fournisseur, les abonnés suivent parce que les enregistrements d’abonnement référencent des DID, et les couches situées au-dessus du PDS restent pour l’essentiel celles d’une seule entreprise.

Solid : des pods de données sans marché grand public

Solid stocke les données d’un utilisateur dans un Pod que celui-ci contrôle et exige que chaque application demande un accès. Un WebID identifie la personne, le Pod est un serveur HTTP qui héberge des ressources RDF, et les applications lisent et écrivent ces ressources dès lors que les règles d’autorisation le permettent. Au test du changement de fournisseur, Solid offre la conception la plus propre des trois : identité, données et règles d’accès résident toutes chez l’utilisateur, et une application n’est qu’un client.

L’adoption ne suit pas la conception. Solid Protocol est un brouillon de W3C Community Group (v0.11.0, 12 mai 2024), et non un standard du W3C, et l’index TR ne fait état d’aucune nouvelle version publiée depuis ; les versions précédentes étaient la 0.9.0 (décembre 2021) et la 0.10.0 (décembre 2022), et les travaux sur la 0.12.0 en sont au stade de l’editor’s draft. Les spécifications d’extension dont dépendent les applications — WebID Profile, Type Indexes et Application Interoperability — sont encore à l’état de brouillons, et la spécification autorise deux systèmes d’autorisation incompatibles, WAC et ACP, les serveurs étant libres d’implémenter l’un ou l’autre. L’outillage et la documentation sont en retard sur les deux autres protocoles.

L’obstacle pratique, c’est de savoir où s’inscrire. solidproject.org recense une quinzaine de services de pods hébergés, pour la plupart modestes ou expérimentaux, et Inrupt, l’entreprise cofondée par Tim Berners-Lee, commercialise désormais des infrastructures de portefeuille (wallet) destinées aux entreprises. Noel De Martin, développeur d’applications Solid, désignait en 2024 l’absence de marché grand public des pods comme le principal frein à Solid : demander à quelqu’un de se connecter avec Solid l’envoie d’abord chercher un fournisseur, et c’est là que la plupart s’arrêtent.

Combien d’utilisateurs comptent Bluesky et Mastodon ?

Le rapport de transparence 2025 de Bluesky (29 janvier 2026) comptabilisait 41,41 millions de comptes fin 2025, contre 25,94 millions auparavant, sur les PDS hébergés par Bluesky et les PDS indépendants ; l’entreprise suit mais ne publie pas de chiffre d’utilisateurs actifs mensuels. Le rapport normalise ses données de modération pour 1 000 utilisateurs actifs mensuels sans indiquer ce dénominateur.

Mastodon publie de son côté un chiffre à l’échelle du réseau, sur la page des serveurs de joinmastodon.org, et les traqueurs tiers qui interrogent les API de statistiques des instances publient les leurs. Les chiffres ne concordent pas. TechCrunch rapportait en février 2026 que le site de Mastodon annonçait environ 785 000 actifs mensuels, tandis que les traqueurs allaient d’environ 750 000 à un million selon celui que l’on consultait. Ces traqueurs situent le nombre de comptes enregistrés autour de 10 millions répartis sur quelque 10 000 serveurs, même si les totaux varient d’un million ou plus d’un traqueur à l’autre, selon la manière dont chacun traite les serveurs devenus inactifs.

Sur Mastodon, inscriptions et actifs diffèrent d’un ordre de grandeur, et le ratio de Bluesky est inconnu. Une comparaison qui oppose les inscriptions d’un réseau aux actifs d’un autre compare des grandeurs différentes.

Que peut-on construire sur ActivityPub, Solid et Bluesky ?

Les trois protocoles reposent sur du HTTP standard, et c’est pourquoi un terminal suffit pour les inspecter :

# ActivityPub: resolve a handle with WebFinger, then fetch the actor document
curl -s 'https://mastodon.social/.well-known/webfinger?resource=acct:Mastodon@mastodon.social'
curl -s -H 'Accept: application/activity+json' https://mastodon.social/users/Mastodon

# Solid: read an RDF resource from a pod as Turtle (replace with a real pod URL)
curl -s -H 'Accept: text/turtle' https://alice.example.org/profile/card

WebFinger relève de la RFC 7033 et d’une convention de l’écosystème Mastodon ; il ne fait pas partie d’ActivityPub à proprement parler. Les serveurs Solid doivent servir les ressources RDF en Turtle ou JSON-LD sur demande.

Le projet le plus accessible est un feed personnalisé Bluesky. Un feed personnalisé Bluesky est un service HTTP qui renvoie une liste ordonnée d’URI de publications ; l’AppView récupère et affiche lui-même ces publications, de sorte que le service de feed n’a jamais à stocker ni à servir le contenu des publications. Deux routes XRPC sont requises, et le lexicon getFeedSkeleton définit les paramètres (feed, limit jusqu’à 100, cursor) ainsi que l’erreur UnknownFeed :

// feedgen.mjs — run with: node feedgen.mjs
import { createServer } from 'node:http';

const SERVICE_DID = 'did:web:feeds.example.com';
const FEED_URI = 'at://did:plc:yourpublisherdid/app.bsky.feed.generator/weekend';

// A real generator fills this from a firehose consumer or a database.
const POSTS = [
  'at://did:plc:ragtjsm2j2vknwkz3zp4oxrd/app.bsky.feed.post/3jux6xlrdb42v',
  'at://did:plc:ragtjsm2j2vknwkz3zp4oxrd/app.bsky.feed.post/3jux7x2uvip2v',
];

const json = (res, status, body) => {
  res.writeHead(status, { 'content-type': 'application/json' });
  res.end(JSON.stringify(body));
};

createServer((req, res) => {
  const { pathname, searchParams } = new URL(req.url, 'http://localhost');

  if (pathname === '/xrpc/app.bsky.feed.describeFeedGenerator') {
    return json(res, 200, { did: SERVICE_DID, feeds: [{ uri: FEED_URI }] });
  }

  if (pathname === '/xrpc/app.bsky.feed.getFeedSkeleton') {
    if (searchParams.get('feed') !== FEED_URI) {
      return json(res, 400, { error: 'UnknownFeed', message: 'Feed not found' });
    }
    // Requests may carry a JWT signed by the user's key. A feed that is
    // identical for every user can ignore it, as this one does.
    const limit = Math.min(Number(searchParams.get('limit') ?? 50), 100);
    const start = Number(searchParams.get('cursor') ?? 0);
    const page = POSTS.slice(start, start + limit);
    const cursor = start + limit < POSTS.length ? String(start + limit) : undefined;
    return json(res, 200, { feed: page.map((post) => ({ post })), cursor });
  }

  json(res, 404, { error: 'NotFound' });
}).listen(3000);

Le curseur est opaque pour l’AppView et vous appartient entièrement ; un index de position suffit pour une liste figée, et le tutoriel officiel recommande un curseur composé d’un horodatage et d’un CID dès lors que les publications proviennent d’un index en temps réel. Pour passer en production, vous déployez en HTTPS, publiez un document DID qui pointe vers l’hôte (le starter kit le configure par défaut en did:web), et exécutez son script publishFeedGen.ts pour créer l’enregistrement app.bsky.feed.generator dans votre propre dépôt. Dès lors, le feed apparaît dans l’application Bluesky comme n’importe quel autre.

Où en sommes-nous

Mesurés à l’aune du test du changement de fournisseur, ActivityPub transporte les abonnés mais pas l’identité ; l’AT Protocol transporte les trois sur le papier, alors que l’essentiel du réseau passe encore par le relais et l’AppView d’une seule entreprise ; et Solid transporte tout en principe, sans marché grand public pour le porter. Choisissez le protocole dont vous pouvez assumer le mode de défaillance, puis consacrez un week-end au générateur de feed ci-dessus : c’est le chemin le plus court entre lire des articles sur le web décentralisé et en faire tourner un morceau.

FAQ

Les utilisateurs de Bluesky et de Mastodon peuvent-ils se suivre mutuellement ?

Pas nativement : ActivityPub et l'AT Protocol ne sont pas interopérables, les abonnements entre réseaux passent donc par un pont. Bridgy Fed, opéré par l'association A New Social, fonctionne sur la base de l'opt-in : un utilisateur Bluesky suit @ap.brid.gy, et un utilisateur du fediverse suit @bsky.brid.gy@bsky.brid.gy. Les comptes pontés apparaissent sous la forme user.instance.ap.brid.gy sur Bluesky et handle@bsky.brid.gy dans le fediverse. Seules les publications entièrement publiques sont pontées, et les publications du fediverse de plus de 300 caractères sont tronquées sur Bluesky.

Quelle est la différence entre did:plc et did:web sur l'AT Protocol ?

L'AT Protocol ne prend en charge que deux méthodes DID. did:plc, développée par Bluesky Social PBC, enregistre les identifiants dans l'annuaire PLC, gère la rotation et la récupération des clés, et c'est ce que l'installateur officiel du PDS crée pour les nouveaux comptes. did:web dérive l'identifiant d'un nom d'hôte que vous contrôlez, n'autorise que des identifiants au niveau du nom d'hôte sans chemin, et n'offre aucune récupération si vous perdez le domaine : elle convient donc à des services tels que les générateurs de feeds.

Puis-je utiliser mon propre domaine comme identifiant Bluesky sans héberger de PDS ?

Oui. Un identifiant est un nom d'hôte DNS lié bidirectionnellement à votre DID, et ce lien est indépendant du PDS qui stocke vos données. Publiez le DID à l'un de ces deux endroits : un enregistrement DNS TXT nommé _atproto.votredomaine dont la valeur est did= suivi de votre DID complet, ou une réponse en texte brut à l'adresse https://votredomaine/.well-known/atproto-did. La spécification recommande la méthode DNS pour les particuliers ; la méthode HTTPS visant les services de grande taille.

Si j'auto-héberge un Personal Data Server, puis-je toujours utiliser l'application Bluesky ?

Oui. Le PDS officiel est distribué sous forme d'image Docker pour un VPS doté d'une adresse IPv4 publique, d'un enregistrement DNS wildcard et des ports 80 et 443 ouverts ; Bluesky recommande 1 Go de RAM et 20 Go de stockage pour 1 à 20 utilisateurs. Connectez-vous en saisissant l'URL de votre PDS dans l'application. La configuration par défaut pointe vers l'AppView, le relais et l'annuaire PLC de Bluesky : le PDS reste donc dépendant de services opérés par Bluesky au-dessus de la couche de données.