Il n'y a pas d'instances dans atproto

2026-07-15

Cet article est une traduction française de « There Are No Instances in atproto » écrit par Dan Abramov et publié le 19 juin 2026 sur son blog overreacted.io. Traduit et republié avec son autorisation.

Chaque fois qu’un article sur atproto atteint la une de Hacker News, quelqu’un demande dans les commentaires : « Mais où sont donc toutes les instances Bluesky ? ». Le problème, c’est qu’il n’y a pas d’instances dans atproto ! La question est une erreur de catégorie. Les instances relèvent d’un modèle mental hérité de Mastodon, et je voulais avoir quelque chose à partager qui l’explique clairement.

Alors le voici.

RSS et Google Reader

Je sais que RSS est encore utilisé quelque part (les podcasts ?!), mais son âge d’or est sans doute derrière nous. C’est bien dommage. Pendant quelques années — dont certains d’entre nous se souviennent avec tendresse comme de l’âge d’or du web — on avait l’impression que tenir un blog était quelque chose de cool.

Maintenant, regardez cette image, car elle va avoir son importance :

Trois blogs alimentant deux applications.

Pour rappel : vous publiez des choses sur votre propre blog, que vous pouvez soit héberger vous-même, soit confier à une plateforme de blog populaire. Mais ensuite, les contenus de chacun sont agrégés dans des applications comme Google Reader et Feedly, ou dans des blogs collectifs comme Monologue (RIP).

Notez que l’hébergement et l’agrégation sont deux choses distinctes. Vos publications ne « vivent » pas dans une application comme Google Reader. Les applications ne sont que des projections de la blogosphère.

Sérieusement, gravez bien cette idée dans votre esprit ; elle va être essentielle.

Facebook et compagnie

Voici ce qu’on pourrait appeler une évolution de ce concept.

On met une boîte autour de tout ça pour que tout le monde soit enfermé dans le même espace, afin qu’on puisse afficher des publicités et tout le reste. Et puis, ne gardons qu’une seule application (on peut laisser vivre des applications alternatives un moment, mais pas longtemps). Voilà les réseaux sociaux traditionnels.

Nos publications alimentant le fil d'actualité — mais elles sont dans une boîte.

Oh non, nous voilà avec de la centralisation !

Oh non, des effets de réseau incontrôlables !

Oh non, bla bla bla.

Que faire ?

Il faut décentraliser tout ça d’une manière ou d’une autre.

Mastodon et ses instances

Je dis « Mastodon » ici parce que si je disais « ActivityPub » à la place, une foule de gens débarquerait pour dire qu’en réalité ce que je décris, c’est la façon dont Mastodon a choisi d’implémenter ActivityPub. Alors qu’ActivityPub en lui-même ne spécifie pas vraiment comment l’utiliser en pratique. Je suis sûr que tout cela est passionnant — mais je m’égare.

Comment décentraliser un réseau social ?

Construisons une version de ce que nous avons vu plus haut, mais rendons-la auto-hébergeable. Ainsi, chaque communauté peut avoir son propre « petit Facebook » ou « petit Twitter ». Nous les appellerons des instances. Elles ressemblent un peu à des pays — parce que vous vivez « à l’intérieur » de l’une d’elles :

De nombreuses instances Mastodon ne sont qu'un ensemble de telles boîtes.

Mais attendez, cela soulève un tas de questions.

Comment choisir l’instance à rejoindre ? Peut-être êtes-vous membre de plusieurs communautés qui se chevauchent. Eh bien, il va falloir choisir à quels administrateurs de communauté vous faites le plus confiance pour gérer votre identité et vos données.

Bon, autre problème : et si mon ami est sur une instance différente ? Comment verra-t-il mes publications ? Puisque chaque instance est en gros son propre petit Facebook, elles n’ont pas de source de vérité commune. Elles doivent donc s’envoyer des messages les unes aux autres :

Cette topologie de réseau vous rappellera peut-être les fiefs en guerre de la Chine ancienne.

Si Alice-de-l’instance-#1 suit Bree-de-l’instance-#2, les deux instances passent un accord : les publications de Bree seront transmises à l’instance #1 pour qu’Alice puisse les voir. C’est ce qu’on appelle la « fédération ». Vous publiez sur votre instance, puis c’est transmis aux autres instances dont les utilisateurs voulaient avoir de vos nouvelles.

Cette image a quelques implications intéressantes :

Vous « appartenez » à votre instance. Vous n’êtes pas Alice, vous êtes Alice-de-l’instance-#1. C’est pourquoi votre identifiant Mastodon est littéralement votrenom@uneinstance.com. « D’où vous venez » est une partie immuable de votre identité. (C’est même, d’une certaine façon, plus restrictif que les pays et les nationalités.)
Si les administrateurs de votre instance se disputent avec ceux d’une autre instance, ils peuvent décider de « cesser de fédérer » et de ne plus transmettre aucune publication entre elles. Cela pourrait être une raison surprenante pour laquelle vous ne voyez plus les publications de vos amis.
Si votre instance tombe en panne, votre identité cesse d’exister. Les gens qui vous suivaient suivaient vous-de-cette-instance, et non un « vrai vous » platonicien et abstrait.

Ah, et le nombre de flèches entre instances croît en O(n²). Cela n’a peut-être pas beaucoup d’importance aujourd’hui, mais cela pourrait en avoir si cette approche des réseaux sociaux devenait populaire.

atproto

Maintenant, oubliez tout ça — remise à zéro complète.

L’erreur, c’est quand nous avons dessiné cette boîte :

alt

La boîte Facebook avec des choses à l'intérieur.

Effacez la boîte.

Revenez à ceci :

Des blogs alimentant des applications comme Google Reader.

Nous avons un hébergement où les choses « vivent » réellement, et des applications qui les agrègent. Cela fonctionnait très bien pour les blogs, alors pourquoi ne fonctionnerait-il pas pour littéralement tout le reste ?

Nos contenus hébergés séparément alimentent des applications quelconques.

Comme RSS, mais pour toutes sortes de choses.

C’est ça, atproto.

Alors, où sont toutes les instances Bluesky ?

Maintenant vous savez ! Il n’y a pas d’instances dans atproto.

Les instances, ce sont ces trucs propres au modèle mental de Mastodon :

Des instances Mastodon avec des flèches entre elles.

Ce sont ces fiefs isolés où hébergement et application sont regroupés, et qui s’envoient des choses les uns aux autres.

Comparez cette image à atproto.

Dans atproto, nous séparons l’hébergement de l’agrégation au niveau du réseau :

De nombreux hébergeurs en haut, et leurs données s'écoulent vers de nombreuses applications en bas.

Il n’y a aucune instance ! Il y a un hébergement que vous pouvez changer, et il y a des applications qui agrègent à partir de l’hébergement de chacun. C’est tout à fait comme RSS et Google Reader.

La décentralisation d’atproto est plus riche en structure que « de nombreuses copies d’une même application » :

Si vous voulez changer d’hébergement, vous le pouvez. Je l’ai littéralement fait le jour où j’écris ces lignes. À part trois ou quatre accrocs côté UX, tout était automatique. Mes données atproto sont maintenant chez Eurosky. Si j’étais plus aventureux, je pourrais aussi héberger toutes mes données moi-même gratuitement sur Cloudflare.
Si vous voulez essayer de nouvelles applications ou en créer, vous le pouvez aussi ! Jetez un œil à Tangled et Semble, qui n’ont rien à voir avec Bluesky. J’ai récemment créé ma propre application (et elle est open source). Je vous recommande de vous y essayer aussi.

La décentralisation vous tient à cœur ? Vous avez ici toute latitude. Décentralisez à volonté.

Libérez-vous du modèle mental des instances

Vous voyez maintenant pourquoi toute discussion sur les réseaux sociaux décentralisés déraille à cause de ça.

Les utilisateurs de Mastodon mesurent la décentralisation au nombre d’instances parce que c’est la seule chose qu’on puisse faire dans Mastodon. S’il n’existe qu’un seul type de « boîte », et que chaque boîte est « une application couplée à un hébergement », la seule chose que vous puissiez faire, c’est héberger davantage de ces boîtes et les faire communiquer entre elles. Elles sont isolées par défaut.

Dans atproto, chaque application est une projection de toute l’Atmosphère, tout comme Feedly et Google Reader sont des projections de l’ensemble de la blogosphère. Vous « décentralisez » surtout en changeant d’hébergement, et/ou en créant et essayant de nouvelles applications. Faire tourner de multiples copies complètes du serveur de base de données de Bluesky est possible, mais ce n’est pas plus utile que de faire tourner de multiples copies de Google Reader. Certains le font effectivement (coucou Blacksky), mais toujours pour répondre à un besoin précis (comme une philosophie de modération différente). Il existe d’autres approches : ce client Bluesky n’a aucune base de données dédiée, il interroge simplement un cache gratuit et communautaire de l’hébergement de chacun. Une infrastructure réseau partagée comme les Relais est peu coûteuse à faire tourner depuis un an maintenant.

C’est pourquoi « compter les instances Bluesky » est si trompeur. Ce qui compte, c’est :

Les gens migrent-ils vers un hébergement alternatif ?
Les gens essaient-ils et créent-ils de nouvelles applications ?

Séparer l’hébergement et les applications corrige des incitations perverses aussi bien dans le social fermé que dans le social fédéré. Coupler l’hébergement et les applications était le péché originel, et le remède est simple.

Gardons nos contenus en dehors des applications ; laissons les applications les agréger.

Nos contenus s'écoulent vers les applications.

Comme RSS et Google Reader.