{
  "$type": "site.standard.document",
  "canonicalUrl": "https://atproto.fr/posts/3mplbr27ur722",
  "description": "Nous sommes aujourd’hui, avec les applications sociales, à un tournant similaire à celui de l’open source il y a trente-cinq ans. Un nouveau mouvement se lève.",
  "path": "/posts/3mplbr27ur722",
  "publishedAt": "2026-07-01T08:31:11.922Z",
  "site": "at://did:web:did.atproto.fr/site.standard.publication/3mozzdjvrnn22",
  "tags": [
    "atproto"
  ],
  "textContent": "import _img01 from \"./open-social-01.svg\";\nimport _img02 from \"./open-social-02.svg\";\nimport _img03 from \"./open-social-03.svg\";\nimport _img04 from \"./open-social-04.svg\";\nimport _img05 from \"./open-social-05.svg\";\nimport _img06 from \"./open-social-06.svg\";\nimport _img07 from \"./open-social-07.svg\";\nimport _img08 from \"./open-social-08.svg\";\nimport _img09 from \"./open-social-09.svg\";\nimport _img10 from \"./open-social-10.svg\";\nimport _img11 from \"./open-social-11.svg\";\nimport _img12 from \"./open-social-12.svg\";\nimport _img13 from \"./open-social-13.svg\";\nimport _img14 from \"./open-social-14.svg\";\nimport _img15 from \"./open-social-15.svg\";\nimport _img16 from \"./open-social-16.svg\";\nimport _img17 from \"./open-social-17.svg\";\nimport _img18 from \"./open-social-18.svg\";\nimport _img19 from \"./open-social-19.svg\";\nimport _img20 from \"./open-social-20.svg\";\nimport _img21 from \"./open-social-21.svg\";\nimport _img22 from \"./open-social-22.svg\";\nimport _img23 from \"./open-social-23.svg\";\nimport _img24 from \"./open-social-24.svg\";\nimport _img25 from \"./open-social-25.svg\";\nimport _img26 from \"./open-social-26.svg\";\nimport _img27 from \"./open-social-27.svg\";\nimport _img28 from \"./open-social-28.svg\";\nimport _img29 from \"./open-social-29.svg\";\nimport _img30 from \"./open-social-30.svg\";\nimport _img31 from \"./open-social-31.svg\";\nimport _img32 from \"./open-social-32.svg\";\nimport _jetstream from \"./jetstream.mp4\";\n\nCet article est une traduction française de « Open Social » écrit par Dan Abramov et publié le 26 septembre 2025 sur son blog overreacted.io. Traduit et republié avec son autorisation.\n\nL'open source a clairement gagné. Oui, il existe une multitude de produits et d'entreprises propriétaires. Mais l'infrastructure partagée — les biens communs — fonctionne avec de l'open source.\n\nNous avons peut-être tendance à considérer cela comme acquis, mais ce n'était pas une conclusion évidente il y a trente-cinq ans. Des forces puissantes voulaient que l'open source échoue. Certains croyaient au modèle open source, mais ne pensaient pas qu'il pourrait un jour rivaliser avec le logiciel propriétaire. De nombreuses catégories d'outils n'existaient qu'en version propriétaire. Un PDG de Microsoft avait qualifié l'open source de cancer — dix ans avant que Microsoft ne rebâtisse son empire autour de lui. Le mouvement de l'open source n'a peut-être pas été à la hauteur des idéaux du « logiciel libre », mais il a gagné en adoption industrielle. Aujourd'hui, personne n'est renvoyé pour avoir choisi l'open source. Pour une grande partie des logiciels essentiels, l'open source est désormais l'option par défaut.\n\nJe pense que nous sommes aujourd'hui, avec les applications sociales, à un tournant similaire à celui de l'open source il y a trente-cinq ans. Un nouveau mouvement se lève. J'aime l'appeler « open social ». Il existe plusieurs visions concurrentes de ce que devrait être l'« open social ». Je pense que le protocole AT créé par Bluesky est la proposition la plus convaincante à ce jour. Il n'est pas parfait, il est encore en construction, mais je ne connais rien qui lui ressemble.\n\n(Précision : j'ai travaillé chez Bluesky sur l'application cliente Bluesky. Je n'ai pas participé à la conception du protocole. J'en suis un fan, et cet article est ma tentative d'expliquer pourquoi.)\n\n<Figure src={_img01} bg=\"white\" alt=\"Un web de données : les enregistrements d'Alice et de Bob se référencent mutuellement.\" />\n\nDans cet article, je vais expliquer les idées du protocole AT, affectueusement appelé atproto, et comment il change la relation entre l'utilisateur, le développeur et le produit.\n\nJe ne m'attends pas à ce qu'atproto et son écosystème (appelé l'Atmosphère) conquièrent les cœurs du jour au lendemain. Comme pour l'open source, cela pourrait prendre quelques décennies avant de devenir omniprésent. En expliquant ces idées ici, j'espère faire avancer légèrement le calendrier. Malgré l'emprise des entreprises de médias sociaux actuelles, je crois que l'open social finira par apparaître, avec le recul, comme inévitable — tout comme l'open source aujourd'hui. Les bonnes choses peuvent arriver ; il suffit d'années d'efforts soutenus par une communauté de passionnés obstinés.\n\nAlors, de quoi s'agit-il exactement ?\n\nCe que l'open source a fait pour le code, l'open social le fait pour la donnée.\n\n---\n\nAvant le social\n\nLe web est une belle invention.\n\nVous tapez https://alice.com et vous arrivez sur le site d'Alice.\n\nOu vous tapez https://bob.com et vous arrivez sur le site de Bob.\n\n<Figure src={_img02} bg=\"white\" alt=\"Alice et Bob possèdent des domaines de premier niveau qui servent du HTML.\" />\n\nVotre navigateur est en quelque sorte un portail vers des millions de mondes différents, chacun avec sa propre petite juridiction. Alice seule décide de ce qui apparaît sur le site d'Alice. Bob seul décide de ce qui apparaît sur le site de Bob. Ils sont réellement propriétaires de leurs données.\n\n<Figure src={_img03} bg=\"white\" alt=\"Alice et Bob contrôlent réellement ces domaines.\" />\n\nCela ne veut pas dire qu'ils sont isolés. Au contraire, Alice peut intégrer une image de Bob avec un <img src>, et Bob peut renvoyer vers la page d'Alice avec un <a href> :\n\n<Figure src={_img04} bg=\"white\" alt=\"Le HTML hébergé par Alice et Bob peut se référencer mutuellement.\" />\n\nAlice et Bob peuvent se citer mutuellement, mais chacun reste maître de son site.\n\nQu'est-ce que je veux dire quand je dis qu'Alice et Bob sont maîtres de leurs sites ? Même s'ils n'hébergent pas physiquement leur contenu sur leur propre machine, ils peuvent toujours changer d'hébergeur. Par exemple, si l'hébergeur d'Alice commence à supprimer ses pages ou à y injecter de la publicité, Alice peut déménager son contenu chez un autre hébergeur et faire pointer https://alice.com vers une autre machine. Les visiteurs n'en sauront rien.\n\n<Figure src={_img05} bg=\"white\" alt=\"Alice peut faire pointer son domaine vers un autre hébergeur en conservant son contenu existant.\" />\n\nC'est important. Les hébergeurs n'ont pas de véritable prise sur Alice et Bob. Si l'hébergeur « devient malveillant » et commence à altérer votre site, vous pouvez simplement partir et l'héberger ailleurs (à condition d'avoir une sauvegarde). Vous ne perdez pas votre audience. Tous les liens existants continueront de résoudre vers la nouvelle destination.\n\nSi Alice change d'hébergeur, Bob n'aura pas besoin de mettre à jour les liens vers le site d'Alice. Le site d'Alice continuera à fonctionner comme si de rien n'était. Au pire, un changement de DNS pourrait le rendre inaccessible pendant quelques heures, mais le web se réparera ensuite :\n\n<Figure src={_img06} bg=\"white\" alt=\"Les sites d'Alice et de Bob continuent à se référencer, comme si rien n'avait changé.\" />\n\nImaginez à quel point les incitations seraient différentes si les liens étaient rattachés à des serveurs physiques !\n\nSi changer d'hébergeur faisait perdre à Alice son audience, elle y réfléchirait à deux fois avant de le faire. Peut-être resterait-elle chez son hébergeur actuel même si celui-ci altérait son site, car perdre ses connexions serait pire encore. Heureusement, la conception décentralisée du web évite cela. Parce qu'il est facile de partir, les hébergeurs sont forcés d'être compétitifs, et l'hébergement est devenu un bien banalisé.\n\nJe trouve que le web est une belle idée. Il relie des îlots décentralisés contrôlés par différentes personnes et entreprises en une seule surface interconnectée que chacun peut indexer et parcourir. Les liens décrivent une relation entre documents logiques plutôt qu'entre serveurs physiques. Résultat : vous n'êtes pas otage de votre hébergeur.\n\nComme disait un sage, en théorie il n'y a pas de différence entre la théorie et la pratique, mais en pratique il y en a une. Alors qu'est-il arrivé au web ?\n\n---\n\nLe social fermé\n\nAu début des années 90, la façon principale de publier quelque chose sur le web était d'avoir son propre site. Aujourd'hui, la plupart des gens publient du contenu en utilisant une application de médias sociaux.\n\nAlice et Bob continuent à publier des choses. Mais au lieu de publier sur des domaines comme alice.com et bob.com, ils publient sous des pseudos comme @alice et @bob attribués par une entreprise de médias sociaux. Les choses qu'ils publient ne sont plus des pages HTML, mais des entités propres à l'application : profils, publications, commentaires, mentions « j'aime », etc.\n\nCes entités sont généralement stockées dans une base de données sur les serveurs de l'entreprise sociale. La façon la plus courante de visualiser une base de données est comme une suite de lignes, mais on peut aussi la voir comme un graphe. Cela ressemble alors beaucoup au web lui-même :\n\n<Figure src={_img07} bg=\"white\" alt=\"Alice et Bob ont des morceaux de données (un like, un profil, un follow) au lieu de morceaux de HTML.\" />\n\nQu'est-ce que ce graphe social permet que le web des sites personnels ne permet pas ?\n\nL'avantage de stocker des entités structurées propres à une application, comme des publications et des likes, plutôt que des documents HTML est évident. Ces entités ont une structure plus riche : on peut toujours les transformer en documents HTML plus tard, mais on peut aussi les agréger, les filtrer, les interroger, les trier et les recombiner de différentes façons avant cela. Cela permet de créer plusieurs projections des mêmes données — une page de profil, une liste de publications, une publication individuelle avec ses commentaires.\n\nLà où cela prend vraiment tout son sens, c'est lorsque beaucoup de gens utilisent la même application sociale. Comme le contenu public de tout le monde se trouve désormais dans une seule base de données, il est facile d'agréger à travers le contenu publié par de nombreuses personnes. Cela permet des fonctionnalités sociales comme la recherche globale, les notifications, les fils d'actualités, les algorithmes personnalisés, la modération partagée, etc.\n\nC'est précisément cette agrégation sociale qui balaye le paradigme des « sites personnels ». Les gens sont des créatures sociales, et nous voulons nous retrouver dans des espaces partagés. Nous ne voulons pas seulement visiter les sites des uns et des autres — nous voulons passer du temps ensemble, et les applications sociales fournissent l'infrastructure partagée. Des fonctionnalités d'agrégation sociale comme les notifications, les fils et la recherche sont incontournables dans les produits sociaux modernes.\n\nAujourd'hui, la façon la plus courante d'implémenter ces fonctionnalités a la forme suivante :\n\n<Figure src={_img08} bg=\"white\" alt=\"Les données d'Alice et de Bob sont en réalité dans une boîte, qui représente une base de données. Depuis cette boîte partent des projections vers différentes routes et écrans de l'application.\" />\n\nIl existe toujours un modèle logique de données similaire au web — nos profils, nos publications, nos abonnements, nos likes, tout ce que nous avons créé — mais il vit à l'intérieur de la base de données d'une application sociale. Ce qui est exposé au web n'est que des projections de ce modèle — la page d'accueil, l'écran des notifications, les pages HTML des publications individuelles.\n\nCette architecture a du sens. C'est la façon la plus simple de faire évoluer le paradigme des « sites personnels » pour supporter l'agrégation, et il n'est donc pas surprenant que les applications d'aujourd'hui aient largement convergé vers elle. Les gens créent des comptes sur des applications sociales, ce qui permet à ces applications de construire des fonctionnalités agrégées, ce qui incite plus de gens à s'inscrire à ces applications.\n\nCependant, quelque chose s'est perdu en chemin. Le web que nous créons réellement — nos publications, nos abonnements, nos likes — ne nous appartient plus vraiment. Même si une grande partie de ce que nous créons est publique, cela ne fait pas partie du web ouvert. Nous ne pouvons pas changer d'« hébergeur » parce que nous sommes désormais à un pas de distance du fonctionnement d'internet. Nous, et le web que nous créons, sommes devenus des lignes dans la base de données de quelqu'un d'autre :\n\n<Figure src={_img09} bg=\"white\" alt=\"Rien n'appartient réellement à Alice ou à Bob. Ils vivent dans des boîtes contrôlées par des entreprises comme Facebook et Twitter.\" />\n\nCela crée un déséquilibre.\n\nQuand Alice publiait ses affaires sur alice.com, elle n'était liée à aucun hébergeur en particulier. Si elle était mécontente de son hébergeur, elle savait qu'elle pouvait en changer sans perdre son audience ni casser de liens :\n\n<Figure src={_img10} bg=\"white\" alt=\"Alice déplace son contenu vers un autre hébergeur.\" />\n\nCela tenait les hébergeurs en respect.\n\nMais maintenant qu'Alice publie sur une plateforme de médias sociaux, elle ne peut plus « partir » sans perdre quelque chose. Si elle s'inscrit sur une autre plateforme sociale, elle serait forcée de repartir de zéro, même si elle veut conserver ses connexions. Il n'existe aucun moyen pour Alice de rompre la relation avec une application particulière sans s'arracher elle-même, ainsi que tout ce qu'elle y a créé, du graphe social :\n\n<Figure src={_img11} bg=\"white\" alt=\"Alice ne peut pas quitter Facebook sans effacer son existence et son contenu.\" />\n\nLe web qu'Alice a créé — qui elle suit, ce qu'elle aime, ce qu'elle a publié — est prisonnier d'une boîte qui appartient à quelqu'un d'autre. Partir, c'est laisser tout cela derrière soi.\n\nÀ l'échelle individuelle, ce n'est peut-être pas si grave.\n\nAlice peut reconstruire sa présence sociale, connexion par connexion, ailleurs. Avec le temps, elle pourrait même retrouver la même portée que sur la plateforme précédente.\n\nCependant, collectivement, l'effet net est que les plateformes sociales — d'abord graduellement, puis soudainement — tournent le dos à leurs utilisateurs. Si vous ne pouvez pas partir sans perdre quelque chose d'important, la plateforme n'a aucune incitation à vous respecter en tant qu'utilisateur.\n\nPeut-être que l'application est pressée par les investisseurs, et qu'une publication sur trois est désormais une publicité. Peut-être qu'elle est rachetée par un conglomérat qui voulait éliminer la concurrence et qui la maintient sous perfusion. Peut-être qu'elle est à court de fonds, et que votre contenu disparaîtra dans deux jours. Peut-être que les fondateurs sont acquihired — un excitant nouveau chapitre. Peut-être que l'application a été rachetée par un type, et vous êtes à présent cuisiné à petit feu par l'algorithme.\n\n<Figure src={_img12} bg=\"white\" alt=\"Ce qui était Twitter est soudainement un site différent.\" />\n\nSi votre prochaine plateforme ne vous respecte pas non plus, vous pourriez essayer de la quitter, elle aussi.\n\nMais qu'allez-vous faire ? Allez-vous « exporter vos données » ? Que ferez-vous de ce fragment isolé d'un graphe social ? Vous pouvez l'uploader quelque part sous forme d'archive, mais c'est arraché de son contexte social — un piètre souvenir de votre exil auto-imposé.\n\nCes mégaoctets de JSON que vous récupérez en partant sont des données mortes. C'est comme une branche arrachée à son arbre. Cela n'a plus sa place nulle part. Pour donner une nouvelle vie à nos données, il faudrait collectivement les exporter, puis collectivement les importer dans une prochaine application sociale acceptée par tous — un exploit de coordination quasi impossible. Et même dans ce cas, les effets de réseau sont si forts que la plupart des gens finiraient par revenir en arrière.\n\nVous ne pouvez pas quitter une application sociale sans laisser derrière vous le web que vous avez créé.\n\nEt si vous pouviez le conserver ?\n\n---\n\nOpen social\n\nAlice et Bob utilisent toujours des applications sociales. Ces applications ne ressemblent pas beaucoup à celles d'aujourd'hui. On pourrait à peine deviner que quelque chose a changé.\n\nQuelque chose a pourtant changé. (Le voyez-vous ?)\n\n<Figure src={_img13} bg=\"white\" alt=\"Alice et Bob ont des morceaux de données, comme avant. Mais le pseudo d'Alice est @alice.com plutôt que @alice, et celui de Bob est @bob.com.\" />\n\nRemarquez que le pseudo d'Alice est maintenant @alice.com. Il n'est pas attribué par une entreprise de médias sociaux. Son pseudo est plutôt le pseudo internet universel, c'est-à-dire un nom de domaine. Alice possède le domaine alice.com, elle peut donc l'utiliser comme pseudo sur n'importe quelle application open social. (Sur la plupart des applications open social, elle apparaît sous @alice.com, mais sur certaines elle préfère avoir une identité distincte et déconnectée, elle possède donc un autre pseudo qu'elle préfère ne pas partager.)\n\nBob possède aussi un domaine, même s'il n'est pas technique. Il ne sait peut-être même pas ce qu'est un « domaine ». Bob pense simplement à @bob.com comme son « pseudo internet ». Certaines applications open social vous proposent un sous-domaine gratuit à l'inscription, tout comme Gmail vous donne une adresse Gmail gratuite, ou peuvent offrir un parcours supplémentaire pour acheter un domaine. Vous n'êtes pas prisonnier de votre premier choix, et vous pouvez passer à un autre domaine plus tard.\n\nLe fait que votre pseudo internet soit quelque chose que vous possédez réellement est l'aspect le plus visible pour l'utilisateur des applications open social. Mais la différence bien plus grande est invisible pour l'utilisateur.\n\nPrécédemment, quand vous voyiez le graphe social ci-dessus, il était prisonnier à l'intérieur de la base de données d'une application sociale. Il y avait une boîte autour de ce graphe — il ne faisait pas partie du web. Avec l'open social, les données d'Alice — ses publications, likes, abonnements, etc. — sont hébergées sur le web lui-même. À côté de son site personnel, Alice a désormais un répertoire personnel de ses données :\n\n<Figure src={_img14} bg=\"white\" alt=\"Le site web d'Alice contient le HTML d'Alice. Le répertoire d'Alice contient les données d'Alice. Ils coexistent côte à côte.\" />\n\nCe « répertoire » est un serveur web classique qui implémente la spécification du protocole AT. Le seul rôle du répertoire personnel d'Alice est de stocker et de servir les données créées par Alice sous forme de JSON signés. Alice est technique, elle aime parfois inspecter son répertoire avec des outils open source comme pdsls, Taproot ou atproto-browser.\n\nBob, en revanche, n'est pas technique. Il ne sait même pas qu'il existe un « répertoire » avec ses « données ». Il en a reçu un discrètement quand il s'est inscrit à sa première application open social. Son répertoire stocke ses données (provenant de toutes ses applications open social).\n\nReprenons cette image :\n\n<Figure src={_img15} bg=\"white\" alt=\"Alice et Bob ont des morceaux de données.\" />\n\nCe ne sont pas des lignes dans la base de données de quelqu'un. C'est un web de JSON hyperliés. De la même façon que chaque page HTML a une URI https:// pour que d'autres pages puissent y renvoyer, chaque enregistrement JSON a une URI at:// pour que n'importe quel autre enregistrement JSON puisse y renvoyer. (Sur cette illustration et les suivantes, @alice.com est un raccourci pour at://alice.com.) Le protocole at:// est un ensemble de conventions au-dessus de DNS, HTTP et JSON.\n\nRegardez maintenant les flèches entre leurs enregistrements. Alice suit Bob, elle a donc un enregistrement follow qui pointe vers l'enregistrement profile de Bob. Bob a commenté la publication d'Alice, il a donc un enregistrement comment qui pointe vers l'enregistrement post d'Alice. Alice a aimé son commentaire, elle a donc un enregistrement like avec un lien vers son enregistrement comment. Tout ce qu'Alice crée reste dans son répertoire sous son contrôle, tout ce que Bob crée reste dans son répertoire sous son contrôle, et les liens expriment les connexions — tout comme en HTML.\n\nTout cela se passe en coulisses et est invisible pour un utilisateur non technique. L'utilisateur n'a pas besoin de penser à l'endroit où ses données sont stockées jusqu'à ce que cela devienne important, tout comme l'utilisateur ne pense pas au fonctionnement des serveurs quand il navigue sur le web.\n\nLes répertoires d'Alice et de Bob pourraient être hébergés sur la même machine. Ou ils pourraient être hébergés par différentes entreprises ou communautés. Peut-être qu'Alice auto-héberge son répertoire, tandis que Bob utilise un service d'hébergement gratuit fourni par défaut avec sa première application open social. Ils peuvent même faire tourner des implémentations complètement différentes. Si les deux serveurs suivent le protocole AT, ils peuvent participer à ce web de JSON.\n\nNotez que https://alice.com et at://alice.com n'ont pas besoin de pointer vers le même serveur. C'est intentionnel : avoir un joli pseudo comme @alice.com ne force pas Alice à héberger elle-même ses données, à toucher à son site web, ni même à avoir un site tout court. Si elle possède alice.com, elle peut faire pointer at://alice.com vers n'importe quel serveur.\n\nSi Alice est mécontente de son hébergement, elle peut plier bagage et partir :\n\n<Figure src={_img16} bg=\"white\" alt=\"Alice déplace de façon transparente les données de son répertoire vers un autre hébergeur.\" />\n\n(Cela demande aujourd'hui un minimum de compétence technique, mais cela devient de plus en plus accessible.)\n\nComme pour le déménagement d'un site personnel, changer l'endroit où son répertoire est servi ne nécessite pas la coopération de l'hébergeur précédent. Cela ne perturbe pas non plus sa capacité à se connecter aux applications et ne casse aucun lien. Le web se répare tout seul :\n\n<Figure src={_img17} bg=\"white\" alt=\"Les données d'Alice restent les données d'Alice. Les données de Bob restent les données de Bob. Les liens entre elles fonctionnent toujours.\" />\n\nIl vaut la peine de s'arrêter un instant pour apprécier ce que nous avons ici.\n\nChaque bribe de donnée publique qu'Alice et Bob ont créée — leurs publications, leurs likes, leurs commentaires, leurs recettes, leurs scrobbles — leur appartient vraiment. Ce n'est pas dans une base de données soumise aux caprices d'un PDG, mais hébergé directement sur le web ouvert, avec la possibilité de « partir » sans perdre son audience ni casser de liens.\n\nComme le web des sites personnels, ce modèle est centré sur l'utilisateur.\n\nQu'est-ce que cela signifie pour les applications ?\n\nChaque application open social est comme un CMS (système de gestion de contenu) pour un sous-ensemble de données qui vit dans les répertoires de ses utilisateurs. En ce sens, votre répertoire personnel joue un rôle similaire à un compte Google, un dossier Dropbox ou un dépôt Git, avec les données de vos différentes applications open social regroupées dans différents « sous-dossiers ».\n\nQuand vous publiez sur Bluesky, Bluesky met cette publication dans votre répertoire :\n\n<Figure src={_img18} bg=\"white\" alt=\"L'application Bluesky appelle createRecord dans un répertoire. Une publication apparaît.\" />\n\nQuand vous mettez une étoile à un projet sur Tangled, Tangled met cette étoile dans votre répertoire :\n\n<Figure src={_img19} bg=\"white\" alt=\"L'application Tangled appelle createRecord dans un répertoire. Une étoile apparaît.\" />\n\nQuand vous créez une publication sur Leaflet, Leaflet la met dans votre répertoire :\n\n<Figure src={_img20} bg=\"white\" alt=\"L'application Leaflet appelle createRecord dans un répertoire. Une publication apparaît.\" />\n\nVous voyez l'idée.\n\nAu fil du temps, votre répertoire devient une collection de données issues de différentes applications open social. Ces données sont ouvertes par défaut — si vous vouliez consulter mes publications Bluesky, mes étoiles Tangled ou mes publications Leaflet, vous n'auriez pas besoin d'appeler les API de ces applications. Vous pourriez tout simplement consulter mon répertoire personnel et énumérer tous ses enregistrements.\n\nPour éviter les collisions de noms, les données du répertoire sont regroupées par format :\n\n<Figure src={_img21} bg=\"white\" alt=\"Le contenu du répertoire d'Alice, séparé par type d'enregistrement.\" />\n\nDans le répertoire de tout utilisateur, les publications Bluesky voisinent avec d'autres publications Bluesky, les publications Leaflet avec des publications Leaflet, les étoiles Tangled avec des étoiles Tangled, et ainsi de suite. Chaque format de donnée est contrôlé et évolue sous la responsabilité des développeurs de l'application concernée.\n\nJ'ai dessiné une ligne pointillée pour les séparer, mais c'est peut-être trompeur.\n\nComme les données de différentes applications « vivent ensemble », les applications open social ont beaucoup moins de barrières pour s'appuyer sur les données des autres. D'une certaine manière, cela commence à ressembler à un multivers connecté d'applications, avec des données d'une application qui « débordent » sur d'autres applications.\n\nQuand je me suis inscrit à Tangled, j'ai choisi d'utiliser mon pseudo @danabra.mov existant. C'est logique puisque l'identité peut être partagée entre applications open social. Ce qui est plus intéressant, c'est que Tangled a prérempli mon avatar à partir de mon profil Bluesky. Il n'a pas eu besoin d'appeler l'API Bluesky pour cela ; il a simplement lu l'enregistrement de profil Bluesky dans mon répertoire. Chaque application peut choisir de s'appuyer sur les données des autres applications.\n\nCela peut vous rappeler Gravatar, mais cela fonctionne pour chaque type de donnée. Chaque application open social peut tirer parti des données créées par toutes les autres applications open social :\n\n<Figure src={_img22} bg=\"white\" alt=\"Le contenu du répertoire d'Alice, cette fois sans séparation. Le contenu créé par chaque application circule dans toutes les applications.\" />\n\nIl n'y a pas d'API à appeler, pas d'intégrations à construire, rien dont on puisse vous exclure. Toutes les données sont dans le répertoire de l'utilisateur, vous pouvez donc les analyser (en tant que JSON typé) et les utiliser.\n\nLe protocole est l'API.\n\nCela a des implications profondes sur le cycle de vie des produits. Si un produit est fermé, les données ne disparaissent pas. Elles sont toujours dans les répertoires des utilisateurs. Quelqu'un peut construire un remplaçant qui redonne vie à ces données. Quelqu'un peut construire un nouveau produit qui intègre une partie de ces données, ou laisse les utilisateurs choisir ce qu'ils veulent importer. Quelqu'un peut construire une projection alternative des données existantes — un produit forké.\n\nCela réduit également le problème du « démarrage à froid » pour les nouvelles applications. Si une partie des données qui vous intéressent existe déjà sur le réseau, vous pouvez amorcer votre produit à partir de là. Par exemple, si vous lancez une application de courtes vidéos, vous pouvez vous appuyer sur les enregistrements follow de Bluesky pour que les gens n'aient pas à se retrouver. Mais si cela n'a pas de sens pour votre application, vous pouvez avoir vos propres enregistrements follow, ou proposer un import unique. Toutes les données existantes sont disponibles pour la réutilisation et le remixage.\n\nCertaines applications open social sont explicitement construites autour de ce genre de remixage. Anisota est principalement un client Bluesky, mais il prend en charge nativement l'affichage de documents Leaflet. Popfeed peut republier des avis à la fois sur Bluesky et Leaflet. Si Leaflet devient très populaire, rien n'empêche Bluesky lui-même de supporter un document Leaflet comme un autre type de pièce jointe à une publication. En fait, un client Bluesky tiers pourrait décider de le faire en premier, et le client officiel pourrait suivre plus tard.\n\nC'est pour cela que j'aime le terme « open social ».\n\nL'open social libère nos données comme l'open source a libéré notre code. L'open social garantit que les anciennes données peuvent avoir une nouvelle vie, que les gens ne peuvent pas être expulsés du web qu'ils ont créé, et que les produits peuvent être forkés et remixés. Vous n'avez pas besoin d'une « application tout-en-un » quand les données de différentes applications circulent sur le web ouvert.\n\nSi vous êtes technique, vous vous posez peut-être maintenant une question brûlante.\n\nComment diable l'agrégation fonctionne-t-elle ?!\n\nPuisque les enregistrements de chaque utilisateur vivent dans le répertoire de cet utilisateur, il pourrait y avoir des millions (potentiellement des milliards ?) de répertoires. Comment une application peut-elle interroger, trier, filtrer et agréger efficacement des informations à partir de ceux-ci ? Elle ne peut certainement pas les chercher à la demande.\n\nJ'ai précédemment utilisé un CMS comme analogie — par exemple, une application de blog pourrait écrire directement des publications dans votre répertoire, puis lire les publications depuis celui-ci quand quelqu'un visite votre blog. Ce cas d'usage « en solo » ne nécessiterait aucune agrégation.\n\n<Figure src={_img23} bg=\"white\" alt=\"L'application Leaflet demande des données au répertoire de l'utilisateur.\" />\n\nPour éviter de solliciter le répertoire de l'utilisateur à chaque affichage d'une publication de blog, vous pouvez vous connecter au répertoire de l'utilisateur par un websocket. Chaque fois qu'un enregistrement pertinent pour votre application est créé, mis à jour ou supprimé, vous pouvez mettre à jour votre base de données :\n\n<Figure src={_img24} bg=\"white\" alt=\"L'application Leaflet s'abonne aux mises à jour du répertoire de l'utilisateur par websocket.\" />\n\nCette base de données n'est pas la source de vérité des données de l'utilisateur — c'est plutôt un cache propre à l'application qui vous évite d'aller solliciter le répertoire utilisateur chaque fois que vous avez besoin de données.\n\nIl se trouve que c'est le mécanisme exact que vous utiliseriez pour l'agrégation. Vous écoutez les événements de tous les répertoires des utilisateurs de votre application, vous les écrivez dans une base de données locale et vous interrogez cette base de données autant que vous le voulez, sans latence supplémentaire.\n\nCela peut vous rappeler la façon dont Google Reader crawle les flux RSS (RIP).\n\nPour éviter d'ouvrir un million de connexions de socket d'événements, il est logique d'écouter un flux qui retransmet les événements de tous les répertoires connus sur le réseau :\n\n<Figure src={_img25} bg=\"white\" alt=\"L'application Leaflet s'abonne aux mises à jour de tous les répertoires utilisateurs par websocket.\" />\n\nVous pouvez ensuite filtrer ce flux pour ne garder que les événements qui vous intéressent, puis mettre à jour votre base de données locale en réponse aux événements qui concernent votre application.\n\nPar exemple, Leaflet ne s'intéresse qu'aux événements concernant les enregistrements pub.leaflet.. Cependant, Leaflet peut également choisir d'écouter d'autres événements. Si Leaflet voulait ajouter une fonctionnalité qui montre les backlinks des discussions Bluesky vers un document Leaflet, il commencerait simplement à suivre aussi les enregistrements <Lex nsid=\"app.bsky.feed.post\" />. (Édit : on m'a informé que Leaflet le fait déjà pour afficher des citations depuis Bluesky.)\n\nVous pouvez voir le flux d'événements combiné de tous les répertoires connus ici :\n\n<figure>\n  <video src={_jetstream} loop muted autoPlay playsInline aria-label=\"C'est un flux en temps réel de chaque événement du réseau, capturé sur pds.ls\"></video>\n  <details><summary>alt</summary><p>C'est un flux en temps réel de chaque événement du réseau, capturé sur pds.ls</p></details>\n</figure>\n\nC'est un flux en temps réel de chaque événement du réseau. Il est dominé par les enregistrements app.bsky. parce que Bluesky est l'application la plus utilisée, mais vous pouvez le filtrer pour d'autres types d'enregistrement. Ce retransmetteur (appelé « relais ») est opéré par Bluesky, mais vous n'êtes pas obligé d'en dépendre. La communauté Blacksky fait tourner sa propre implémentation de relais à l'adresse wss://atproto.africa, que vous pouvez essayer ici. Peu importe quel relais est utilisé par quelle application — tout le monde « voit » le même web.\n\nUn détail important : les commits sont signés cryptographiquement, ce qui veut dire que vous n'avez pas besoin de faire confiance à un relais ou à un cache de données réseau. Vous pouvez vérifier que les enregistrements n'ont pas été altérés et que chaque commit est légitime. C'est pour cela que « AT » dans « AT Protocol » signifie « authenticated transfer ». Vous êtes censé le prononcer comme « @ » (« at »). Ne dites pas « ay-tee » ou vous me mettrez la honte !\n\nAu fil du temps, nous verrons plus d'infrastructures construites autour des applications open social. Graze vous permet de construire des fils algorithmiques, Quickslice et Tap simplifient l'indexation, Constellation et Slingshot vous permettent d'interroger des backlinks et des enregistrements en cache.\n\nMais tout cela n'est que détail technique.\n\nCe qui compte, c'est la vue d'ensemble.\n\n---\n\nLa vue d'ensemble\n\nLe web pré-social des « sites personnels » a fait le bon choix sur la propriété des données, l'indépendance vis-à-vis de l'hébergement et les liens. Alice et Bob participent pleinement au web :\n\n<Figure src={_img26} bg=\"white\" alt=\"Alice et Bob possèdent leur HTML.\" />\n\nLe web social fermé a innové sur l'échelle et sur les fonctionnalités d'agrégation sociale. Notifications, recherche et fils sont incontournables dans les produits sociaux modernes :\n\n<Figure src={_img27} bg=\"white\" alt=\"En mettant les choses dans une base de données, on peut créer des écrans agrégés.\" />\n\nCependant, le web social fermé nous a aussi exclus nous du web. Le web que nous créons ne nous appartient plus vraiment. Nous ne sommes que des lignes dans la base de données de quelqu'un d'autre.\n\n<Figure src={_img28} bg=\"white\" alt=\"Le contenu ne nous appartient plus. Il vit dans des boîtes fermées appartenant à des entreprises sociales.\" />\n\nL'open social libère le web que nous créons des boîtes de quelqu'un d'autre. Nos profils, likes, abonnements, recettes, scrobbles et autres contenus nous appartiennent vraiment :\n\n<Figure src={_img29} bg=\"white\" alt=\"Alice possède les données d'Alice. Bob possède les données de Bob.\" />\n\nLes données ne vivent plus à l'intérieur des produits ; les produits agrègent nos données :\n\n<Figure src={_img30} bg=\"white\" alt=\"Les produits comme Leaflet écoutent les événements dans les répertoires d'Alice et de Bob pour construire leur base de données.\" />\n\nCela brouille les frontières entre les applications. Chaque application open social peut utiliser, remixer, référencer et improviser sur les données de toutes les autres applications open social.\n\n<Figure src={_img31} bg=\"white\" alt=\"Des enregistrements de différents types circulent dans chaque application.\" />\n\nLe web que nous avons créé subsiste après la disparition des produits que nous avons utilisés pour le créer. Les développeurs peuvent construire de nouveaux produits pour le recontextualiser. Personne ne peut nous le retirer.\n\n<Figure src={_img32} bg=\"white\" alt=\"Alice possède ses données, Bob possède les siennes.\" />\n\nÀ mesure que davantage de produits sont construits sur le paradigme open social, un basculement va se produire.\n\nLes gens ne commenceront peut-être jamais à utiliser des concepts techniques comme « décentralisation », mais ils comprennent quand les données d'une application peuvent s'écouler sans effort dans d'autres applications.\n\nLes gens ne se soucient peut-être pas de la « fédération », mais ils remarquent quand ils se connectent à un produit concurrent et que leurs données sont déjà là, et que leur audience est intacte.\n\nEt les gens comprennent bien quand on se joue d'eux.\n\nPendant longtemps, l'open social reposera sur une communauté de passionnés obstinés qui voient la promesse de l'approche et sont prêts à supporter les peines de la construction (et de l'échec) dans un nouvel écosystème. Mais je ne pense pas que cela condamne l'effort. C'est l'histoire de tout grand changement porté par une communauté. Il faut bien que quelqu'un règle les problèmes. Comme pour l'open source, l'open social est un effort qui se cumule. Chaque application open social qui rencontre un semblant de succès porte toutes les applications open social. Chaque brique d'infrastructure partagée peut bénéficier à quelqu'un d'autre. À un moment donné, l'ouvert finira forcément par gagner.\n\nJ'espère juste que ça ne prendra pas trente-cinq ans.",
  "title": "Open Social"
}