ActivityPub vs. AT Protocol : Comprendre les protocoles derrière Mastodon et Bluesky

Une comparaison technique entre ActivityPub et AT Protocol, les protocoles qui sous-tendent respectivement Mastodon et Bluesky. Publié le 18 avril 2026 sur Fediview : ActivityPub vs. ATProtocol: Understanding the Protocols Le Web social décentralisé repose sur des protocoles, et les deux plus importants en 2026 sont ActivityPub (qui alimente Mastodon et le Fediverse) et AT Protocol (qui alimente Bluesky). Les différences entre eux ne sont pas superficielles. Elles reflètent des conceptions véritablement différentes quant à l’endroit où l’identité devrait résider, à qui contrôle les données et à ce que signifie réellement la fédération dans la pratique. Cela a de l’importance, que vous développiez des applications sociales, que vous exploitiez une instance ou que vous essayiez simplement de comprendre pourquoi passer d’une plateforme à l’autre est plus difficile que cela ne devrait l’être. ActivityPub : la norme du Fediverse ActivityPub est devenu une norme du W3C en 2018. Il définit la manière dont les serveurs communiquent pour créer des réseaux sociaux fédérés, et sa conception reflète la philosophie du Web fédéré de cette époque : des serveurs distribués, des instances gérées par la communauté, aucune autorité centrale. L’architecture s’articule autour de ce que la spécification appelle des « acteurs ». Chaque utilisateur — ainsi que certaines autres entités — est un acteur doté d’une boîte de réception et d’une boîte d’envoi. Lorsque vous publiez sur Mastodon, votre serveur envoie cette publication à tous les serveurs hébergeant l’un de vos abonnés. La fédération consiste essentiellement en des serveurs qui transmettent des messages vers les boîtes de réception les uns des autres au nom de leurs utilisateurs. Votre identité est liée à votre instance (@user@instance.example), ce qui signifie que si votre instance disparaît, votre identité disparaît avec elle, à moins que vous n’ayez déjà effectué la migration. Cette conception présente de réels atouts. L’écosystème est vaste : Mastodon, Pixelfed, Lemmy et PeerTube fonctionnent tous sur ActivityPub. Le processus du W3C assure à la spécification une gouvernance formelle et la participation de la communauté. Le protocole lui-même est relativement simple à mettre en œuvre, ce qui explique en partie pourquoi tant de plateformes différentes l’ont adopté. Aucune infrastructure centrale n’est requise : tout serveur exécutant un logiciel compatible peut se joindre au réseau. Les limites sont tout aussi réelles. Le transfert d’un compte d’une instance à une autre est un processus manuel qui ne conserve pas l’historique des messages. ActivityPub ne prescrit pas de schémas de données; par conséquent, différentes implémentations gèrent les cas limites différemment et l’interopérabilité entre, par exemple, Mastodon et Lemmy est imparfaite. La découverte entre instances repose sur des mots-clés et des outils de relais tiers plutôt que sur des fonctionnalités intégrées au protocole lui-même. Protocole AT : la base de Bluesky Le protocole AT (Authenticated Transfer Protocol) a été développé par Bluesky et repose sur des principes différents. Alors qu’ActivityPub considère l’instance comme l’unité de confiance, le protocole AT part du principe que chaque utilisateur doit être propriétaire de ses données, quel que soit le fournisseur qui les héberge. L’architecture comporte davantage de couches. Vos données résident dans un serveur de données personnelles (PDS), que vous pouvez transférer d’un fournisseur à l’autre sans rien perdre. Votre identité est un identifiant décentralisé (DID), indépendant de tout serveur — ainsi, changer de fournisseur ne modifie en rien qui vous êtes. Au-dessus de la couche PDS, des relais agrègent les données provenant de l’ensemble du réseau, et les AppViews (telles que l’application Bluesky elle-même) exploitent ces données relayées pour créer l’expérience utilisateur proprement dite. Cette conception en couches est plus complexe, mais c’est ce qui rend le concept de portabilité des données cohérent. Le protocole AT utilise également des schémas formels appelés « lexiques » pour définir les structures de données, ce qui garantit la cohérence entre les implémentations d’une manière que le modèle plus souple d’ActivityPub ne permet pas. Les algorithmes de fil d’actualité constituent un autre choix de conception délibéré : n’importe qui peut créer et publier un algorithme de fil d’actualité, et les utilisateurs peuvent choisir ceux qu’ils souhaitent utiliser. Des mécanismes de rotation des clés et de récupération de compte sont intégrés dès le départ. Les compromis sont toutefois importants. En pratique, la plupart des utilisateurs s’appuient sur la propre infrastructure de Bluesky pour les relais et les AppViews, ce qui crée un réel risque de centralisation malgré la conception portable du protocole. L’auto-hébergement de la pile complète est considérablement plus difficile que l’exploitation d’une instance Mastodon. Et en 2026, le protocole AT reste principalement un écosystème Bluesky : le protocole existe, mais l’éventail des plateformes qui s’appuient sur lui n’est pas encore comparable à celui d’ActivityPub. La gouvernance est également plus stricte : la PBC de Bluesky contrôle le développement du protocole de manière plus directe que ne le fait le processus du W3C pour ActivityPub. Comparaison côte à côte AspectActivityPubAT ProtocolOrganisme de normalisationW3CBluesky PBCIdentitéPseudo lié à l’instanceDID (portable)Emplacement des donnéesSur votre instanceDans votre PDSPortabilité des donnéesMigration de compte (partielle)Portabilité complète des donnéesModèle de fil d’actualitéChronologique (décidé par le serveur)Algorithmes personnalisés (choisis par l’utilisateur)Modèle de fédérationPeer-to-peer entre serveursHub-and-spoke (relais + AppView)Étendue de l’écosystèmeDe nombreuses plateformes (Mastodon, Pixelfed, Lemmy, PeerTube)Principalement BlueskyComplexité de l’auto-hébergementModéréePlus élevéeDécouverteMots-clés, relaisRecherche globale, flux personnalisésModérationAu niveau de l’instanceServices de balisage Des valeurs différentes, pas une hiérarchie Les protocoles reflètent des priorités différentes, et il est important de préciser en quoi elles consistent. ActivityPub privilégie l’autonomie des instances, la gouvernance communautaire et un modèle de fédération étendu. Il fait confiance aux administrateurs d’instances pour prendre des décisions au nom de leurs communautés, et cette confiance est structurelle : le protocole leur fournit les outils nécessaires et ne s’immisce pas. Le protocole AT privilégie la propriété individuelle des données, le choix algorithmique et l’identité portable. Il tente d’empêcher toute dépendance à n’importe quelle couche, y compris au niveau de la couche protocolaire elle-même. Aucune de ces deux approches n’est objectivement meilleure. Qualifier le protocole AT de « meilleure version d’ActivityPub » constitue une erreur de catégorie : ils optimisent des valeurs différentes et font des compromis différents. Interopérabilité : peuvent-ils communiquer entre eux? En 2026, ActivityPub et le protocole AT ne sont pas interopérables de manière native. Les modèles de données sont suffisamment différents pour qu’il soit véritablement difficile de mettre en place une passerelle efficace. Des services de passerelle tiers peuvent assurer la traduction entre les protocoles, permettant ainsi un certain suivi et une certaine publication interplateformes. Ces passerelles sont imparfaites : toutes les fonctionnalités ne sont pas transférées, et l’expérience s’en trouve dégradée par rapport à une utilisation native. Une véritable interopérabilité nécessiterait soit une adaptation au niveau du protocole, soit des spécifications de passerelle normalisées. Il s’agit d’un sujet de discussion active, mais qui est loin d’être résolu. Pour en savoir plus sur les outils interprotocoles, consultez notre centre d’articles. Ce que cela signifie pour les développeurs Si vous développez des applications sociales, ce choix a des conséquences pratiques. ActivityPub est le bon choix si l’intégration à l’écosystème existant du fediverse est importante — la diversité des plateformes et des utilisateurs est déjà bien établie. Le protocole AT mérite d’être sérieusement exploré si la portabilité des données et les algorithmes personnalisés sont au cœur de ce que vous développez, et non de simples ajouts de dernière minute. Il est possible de prendre en charge les deux, mais cela augmente considérablement la complexité de la mise en œuvre : vous devez essentiellement gérer deux systèmes d’identité, deux modèles de données et deux architectures de fédération. Les deux protocoles évoluent également, il est donc indispensable de se tenir au courant de leur développement. Nos notes à l’intention des développeurs abordent les considérations pratiques liées au développement sur ces protocoles. Ce que cela signifie pour les utilisateurs Pour les utilisateurs ordinaires, le protocole façonne l’expérience de quatre façons principales. Les communautés auxquelles vous pouvez accéder constituent l’aspect le plus évident : ActivityPub vous donne accès au fediverse au sens large, tandis que le protocole AT vous donne accès à l’écosystème Bluesky. La manière dont vos données sont traitées diffère de façon significative : les garanties de portabilité du protocole AT sont, par conception, plus solides. L’apparence de votre fil d’actualité est déterminée par le modèle de fil : le protocole AT offre un choix algorithmique, tandis qu’ActivityPub utilise par défaut des fils chronologiques, selon la configuration de votre serveur. Et les parcours de migration diffèrent : ActivityPub vous fait passer d’une instance à une autre, tandis que le protocole AT transfère votre PDS vers un nouveau fournisseur. Erreurs courantes Quelques idées fausses reviennent sans cesse lorsque l’on discute de ces protocoles. Il est probablement erroné de supposer qu’un protocole finira par s’imposer et que l’autre disparaîtra. Les deux répondent à des besoins réels et coexisteront probablement pendant des années. Considérer le protocole AT comme une version supérieure d’ActivityPub revient à mal interpréter ce que chacun cherche à accomplir : les compromis de conception sont véritablement différents, et non pas meilleurs ou pires selon une échelle commune. Ignorer l’écosystème entourant un protocole est également une erreur. Un protocole techniquement élégant, mais sans base d’utilisateurs significative, est moins utile qu’un protocole « assez bon » doté d’une communauté nombreuse et active. Confondre le protocole avec la plateforme aggrave encore les choses : Mastodon est une implémentation d’ActivityPub, Bluesky est une implémentation du protocole AT, et aucune des deux ne définit ce dont le protocole est capable. Enfin, s’attendre à une interopérabilité interprotocolaire transparente dans un avenir proche mènera à la déception. La qualité des ponts s’améliorera, mais la fédération native entre protocoles n’est pas à l’horizon à court terme. Foire aux questions Puis-je utiliser à la fois Mastodon et Bluesky? Oui. De nombreuses personnes ont des comptes sur les deux. Ce sont des plateformes indépendantes avec des comptes indépendants, et il n’y a aucun obstacle technique à leur utilisation simultanée. Mastodon adoptera-t-il le protocole AT? Peu probable. Mastodon repose sur ActivityPub et les valeurs de sa communauté s’alignent étroitement sur la conception de ce protocole. Une certaine interopérabilité via des ponts est plus réaliste qu’un changement complet de protocole. Quel protocole est le plus « décentralisé »? Cela dépend de ce que vous entendez par là. Le modèle peer-to-peer d’ActivityPub est plus décentralisé sur le plan de l’architecture — aucun nœud central n’est requis. La portabilité des données du protocole AT est plus décentralisée en termes d’autonomie de l’utilisateur — vos données ne sont pas prisonnières d’un fournisseur. Les deux arguments sont défendables. Puis-je créer une application qui prend en charge les deux? Oui, mais cela nécessite de mettre en œuvre les deux protocoles et de gérer les différences au niveau des modèles de données, de l’identité et de la fédération. Certains projets s’y essaient. Consultez notre page d’outils pour découvrir des outils interprotocoles. L’un des protocoles est-il plus respectueux de la vie privée que l’autre? Les deux protocoles rendent le contenu public accessible à tous. La protection de la vie privée dépend davantage de la manière dont une plateforme met en œuvre le protocole que du protocole lui-même. Notre guide des meilleurs outils présente des options axées sur la protection de la vie privée. Liste évolutive des traductions par Gilles en vracLes caractères gras dans le texte sont de l’auteur.e