RFCs on the Atmosphere<\/a> publi\u00e9 le 30 mai 2026. <\/p>\n\n\n\n Je travaillais r\u00e9cemment sur une RFC dans le cadre d\u2019un projet open source et je ne savais pas vraiment o\u00f9 la publier. Google Docs n\u2019est pas pratique pour tout ce qui est technique, et un d\u00e9p\u00f4t Git, c\u2019est trop lourd si on n\u2019en a pas d\u00e9j\u00e0 un en place avec un processus pr\u00eat \u00e0 l\u2019emploi.<\/p>\n\n\n\n Ce que je cherchais, c\u2019\u00e9tait un site Web sp\u00e9cialis\u00e9 qui permette simplement de publier des documents au format Markdown sur lesquels les gens peuvent laisser des commentaires.<\/p>\n\n\n\n J\u2019ai donc cr\u00e9\u00e9 requested.fyi<\/a>, un site Web qui r\u00e9pond exactement \u00e0 ce besoin.<\/p>\n\n\n\n Ce qui est g\u00e9nial : mon site Web n\u2019h\u00e9berge ni les documents ni les commentaires. Requested est une application Atmospheric; les documents r\u00e9sident donc sur le PDS atproto<\/a> de l\u2019auteur, qu\u2019il contr\u00f4le1<\/a><\/sup>Notez que \u00ab contr\u00f4l\u00e9 \u00bb ne signifie pas que vous devez le g\u00e9rer vous-m\u00eame. Lorsque vous vous inscrivez pour obtenir un compte Bluesky (ou Blacksky, Eurosky, etc.), vous recevez gratuitement un PDS g\u00e9r\u00e9 par Bluesky <\/strong>qui stocke toutes vos donn\u00e9es. Ce qui est g\u00e9nial avec atproto, c\u2019est que le protocole facilite le transfert de la gestion de votre PDS \u00e0 quelqu\u2019un d\u2019autre quand vous le souhaitez.<\/span>, et les commentaires sont h\u00e9berg\u00e9s sur le PDS de la personne qui les a publi\u00e9s (avec un lien vers le document et, au choix, vers une ligne sp\u00e9cifique).<\/p>\n\n\n\n C\u2019est \u00e0 peu pr\u00e8s tout! L\u2019application Requested n\u2019a pas de backend compliqu\u00e9. Elle se contente d\u2019interroger et de mettre en cache les enregistrements de documents provenant du PDS de l\u2019auteur, puis utilise constellation<\/a> pour trouver les commentaires li\u00e9s.<\/p>\n\n\n\n Essayez-la si vous avez des documents sur lesquels vous souhaitez obtenir des commentaires!<\/p>\n\n\n\n \u00c0 ce propos, si vous souhaitez apporter votre aide, j\u2019ai r\u00e9dig\u00e9 un document expliquant comment ajouter une phase de pr\u00e9production<\/a> \u00e0 Requested. Jetez-y un coup d\u2019\u0153il et laissez un commentaire si vous avez des suggestions!<\/p>\n\n\n\n Traduction de An Atmospheric Website<\/a>, paru le 23 avril 2026<\/p>\n\n\n\n Notes sur la cinqui\u00e8me et derni\u00e8re migration.<\/p>\n\n\n\n J\u2019ai migr\u00e9 ce blogue quatre fois au cours des 20 derni\u00e8res ann\u00e9es2<\/a><\/sup>Mon premier billet date de 2006 environ, mais il s\u2019est perdu lors d\u2019une migration en cours de route. Heureusement, m\u00eame Internet Archive n\u2019a pas trace de mes premiers billets, lol<\/span>. WordPress, Jekyll, Hugo, Eleventy. Tous les quelques ann\u00e9es, je troquais une s\u00e9rie de compromis contre une autre en me disant que c\u2019\u00e9tait la derni\u00e8re fois.<\/p>\n\n\n\n Il s\u2019agit de la cinqui\u00e8me migration. C\u2019est aussi la derni\u00e8re. Non pas parce que j\u2019ai enfin trouv\u00e9 le g\u00e9n\u00e9rateur de site statique parfait, mais parce que le blogue n\u2019est plus vraiment d\u2019actualit\u00e9. Mon site Web est d\u00e9sormais une vue<\/em> sur un d\u00e9p\u00f4t que je contr\u00f4le sur le r\u00e9seau ouvert, et le blogue n\u2019est qu\u2019un des \u00e9l\u00e9ments que cette vue peut afficher.<\/p>\n\n\n\n Dans la communaut\u00e9 atproto, les applications construites sur le protocole sont appel\u00e9es \u00ab Atmospheric \u00bb. Ainsi : mon site web est d\u00e9sormais Atmospheric, et cet article explique ce que cela signifie concr\u00e8tement.<\/p>\n\n\n\n Chaque plateforme de blogue que j\u2019ai utilis\u00e9e a \u00e9t\u00e9 un compromis.<\/p>\n\n\n\n WordPress m\u2019offrait un CMS, mais me liait \u00e0 une pile technique que je ne souhaitais pas entretenir. Jekyll, Hugo et Eleventy m\u2019offraient le contr\u00f4le et des fichiers Markdown simples, ce que j\u2019adorais, mais ils liaient discr\u00e8tement la publication \u00e0 mon ordinateur portable. Pour publier quelque chose, je devais me trouver devant la bonne machine, dans le bon environnement, avec les bons fichiers, dans la bonne branche Git. Si une id\u00e9e me venait sur mon t\u00e9l\u00e9phone, elle devait attendre.<\/p>\n\n\n\n Et les donn\u00e9es (articles, \u00e9bauches, liens que je voulais partager, livres que je lisais) \u00e9taient \u00e9parpill\u00e9es entre un dossier sur mon ordinateur portable, un compte Bluesky, une application de lecture et une application de notes. Mon site Web \u00ab personnel \u00bb ne montrait qu\u2019une infime partie de moi, car la plupart de mes donn\u00e9es se trouvaient ailleurs.<\/p>\n\n\n\n Je voulais une configuration o\u00f9 la source de v\u00e9rit\u00e9 ne soit pas un dossier sur un seul ordinateur, et o\u00f9 mon site Web puisse puiser dans tous les endroits o\u00f9 je passe r\u00e9ellement du temps en ligne.<\/p>\n\n\n\n Au cours des derniers mois, je me suis plong\u00e9 dans atproto<\/a>, le protocole derri\u00e8re Bluesky<\/a> et un \u00e9cosyst\u00e8me grandissant d\u2019autres applications. J\u2019ai d\u00e9j\u00e0 lanc\u00e9 quelques projets dessus : Skyreader<\/a> (un lecteur RSS), Skyboard<\/a> (un tableau Kanban) et SembleIt<\/a> (un client alternatif pour Semble<\/a>, un outil permettant de recueillir et de partager des liens de recherche).<\/p>\n\n\n\n Ce qui m\u2019a s\u00e9duit chez atproto, c\u2019est la fa\u00e7on dont il inverse la relation habituelle entre les applications et les donn\u00e9es.<\/p>\n\n\n\n Dans une application Web classique, vos publications, vos signets, vos notes et vos t\u00e2ches constituent des lignes dans la base de donn\u00e9es de quelqu\u2019un d\u2019autre. Sur atproto, vos donn\u00e9es r\u00e9sident dans votre propre d\u00e9p\u00f4t, h\u00e9berg\u00e9 sur un serveur qui, de par sa conception, peut \u00eatre d\u00e9plac\u00e9. Les applications \u00e9crivent dans votre d\u00e9p\u00f4t en utilisant des sch\u00e9mas partag\u00e9s. Les publications Bluesky, les partages Skyreader, les fiches Semble et tout ce qui viendra ensuite peuvent tous coexister dans le m\u00eame \u00e9cosyst\u00e8me, affich\u00e9s par diff\u00e9rents clients3<\/a><\/sup>Si cela vous semble abstrait, \u00ab The Social Filesystem \u00bb de Dan Abramov<\/a> est l\u2019explication la plus claire que j\u2019aie lue.<\/span>.<\/p>\n\n\n\n Cela signifie que mon site n\u2019est plus un amoncellement de fichiers Markdown qui sont convertis en HTML au moment de la compilation. C\u2019est une application SvelteKit qui lit directement \u00e0 partir de mon d\u00e9p\u00f4t atproto et affiche ces donn\u00e9es sur le site public.<\/p>\n\n\n\n Mes articles de blogue se trouvent d\u00e9sormais dans mon d\u00e9p\u00f4t sous forme d\u2019enregistrements site.standard<\/a>, le m\u00eame sch\u00e9ma utilis\u00e9 par Leaflet<\/a>, pckt<\/a>, Offprint<\/a> et d\u2019autres applications de r\u00e9daction de longs formats. Un enregistrement ressemble \u00e0 peu pr\u00e8s \u00e0 ceci :<\/p>\n\n\n\n Les quelque 50 articles ont tous \u00e9t\u00e9 enti\u00e8rement import\u00e9s, et les nouveaux articles sont publi\u00e9s directement dans le m\u00eame syst\u00e8me.<\/p>\n\n\n\n J\u2019avais besoin d\u2019un endroit pour r\u00e9diger mes articles; j\u2019ai donc cr\u00e9\u00e9 un petit panneau d\u2019administration priv\u00e9 que j\u2019appelle le \u00ab studio \u00bb, accessible uniquement par moi-m\u00eame via OAuth atproto.<\/p>\n\n\n\n Il s\u2019agit d\u2019une poign\u00e9e de routes SvelteKit accessibles apr\u00e8s connexion : un tableau de bord, un \u00e9diteur Markdown, un bouton de publication. Pas de base de donn\u00e9es, pas de serveur API, pas de backend d\u2019administration. Enregistrer un brouillon \u00e9crit un enregistrement de brouillon directement dans mon d\u00e9p\u00f4t. La publication \u00e9crit un enregistrement de type `site.standard.document` dans le m\u00eame d\u00e9p\u00f4t que celui \u00e0 partir duquel le site public lit ses donn\u00e9es. Tout le cycle de cr\u00e9ation repose sur des jetons OAuth et des appels XRPC.<\/p>\n\n\n\n L\u2019avantage int\u00e9ressant, c\u2019est que le \u00ab studio \u00bb n\u2019est pas le seul \u00e0 pouvoir \u00e9crire dans mon d\u00e9p\u00f4t. N\u2019importe quelle autre application qui utilise le lexique `site.standard.document` pourrait publier directement dans ce d\u00e9p\u00f4t, et l\u2019article s\u2019afficherait sur mon site de la m\u00eame mani\u00e8re. Si quelqu\u2019un cr\u00e9e un meilleur \u00e9diteur demain, je pourrai changer sans avoir \u00e0 migrer un seul article. Le CMS n\u2019est pas soud\u00e9 au site Web.<\/p>\n\n\n\n Voici ce qui m\u2019enthousiasme le plus : comme le site est un moteur de rendu bas\u00e9 sur mon d\u00e9p\u00f4t, il peut afficher tout ce que j\u2019y place.<\/p>\n\n\n\n La nouvelle page d\u2019accueil en est le reflet. Outre le blogue, on y trouve des sections consacr\u00e9es \u00e0 ce que j\u2019ai partag\u00e9 via Skyreader et aux liens de recherche provenant de ma biblioth\u00e8que Semble. Je ne g\u00e8re pas ces sections manuellement. Je partage un article dans Skyreader ou j\u2019ajoute une fiche \u00e0 une collection dans Semble, et cela s\u2019affiche automatiquement sur le site.<\/p>\n\n\n\n Le blogue se trouve toujours \u00e0 l\u2019adresse Je vois cela comme des fen\u00eatres. Chaque application que j\u2019utilise est une fen\u00eatre donnant sur une partie de mon d\u00e9p\u00f4t. Skyreader est la fen\u00eatre pour le partage d\u2019articles. Semble est la fen\u00eatre pour la collecte de liens de recherche. Le studio est la fen\u00eatre pour la r\u00e9daction des articles. Le site Web n\u2019est qu\u2019une autre fen\u00eatre, celle destin\u00e9e au public, qui rassemble tous ces \u00e9l\u00e9ments pour quiconque le visite.<\/p>\n\n\n\n Cette fa\u00e7on de penser change la perception de ce que signifie \u00ab ajouter une fonctionnalit\u00e9 \u00bb au site. Il n\u2019y a pas de migration de sch\u00e9ma, pas d\u2019importation de donn\u00e9es, pas de scraping de l\u2019API de quelqu\u2019un d\u2019autre. Si je veux une nouvelle section, j\u2019ajoute un itin\u00e9raire, j\u2019interroge le lexique appropri\u00e9 \u00e0 partir de mon<\/em> d\u00e9p\u00f4t, et je l\u2019affiche. Les donn\u00e9es sont d\u00e9j\u00e0 l\u00e0 parce qu\u2019une autre fen\u00eatre les y a plac\u00e9es. Le site s\u2019adapte \u00e0 ma vie plut\u00f4t que de me demander de les copier manuellement.<\/p>\n\n\n\n Si je cr\u00e9e ou adopte une nouvelle application Atmospheric demain, le site web lui consacrera une nouvelle interface d\u00e8s le lendemain. C\u2019est pourquoi il s\u2019agit de la derni\u00e8re migration. Le site a cess\u00e9 d\u2019\u00eatre ce que je construisais. Il est devenu une fen\u00eatre sur une vie qui existait d\u00e9j\u00e0.<\/p>\n\n\n\n
\n\n\n\nUn site Web Atmospheric<\/h1>\n\n\n\n
Le cycle sans fin des migrations<\/h2>\n\n\n\n
C\u2019est l\u00e0 qu\u2019intervient atproto<\/h2>\n\n\n\n
Alors, que signifie \u00ab Atmospheric \u00bb pour un site Web?<\/h2>\n\n\n\n
{<\/code><\/pre>\n\n\n\n \"$type\": \"site.standard.document\",<\/code><\/pre>\n\n\n\n\"title\": \"Mon site Web est maintenant Atmospheric\",<\/code><\/pre>\n\n\n\n \"createdAt\": \"2026-04-22T10:00:00Z\",<\/code><\/pre>\n\n\n\n \"body\": \"J\u2019ai migr\u00e9 ce blogue quatre fois...\"<\/code><\/pre>\n\n\n\n}<\/code><\/pre>\n\n\n\nR\u00e9daction dans le \u00ab studio \u00bb<\/h2>\n\n\n\n
Le site en tant que vue<\/h2>\n\n\n\n
\/blog<\/code><\/a>, g\u00e9n\u00e9r\u00e9 \u00e0 partir des enregistrements site.standard.document<\/code>. \/reading<\/code><\/a> affiche les liens que j\u2019ai partag\u00e9s via Skyreader, et \/library<\/code><\/a> r\u00e9cup\u00e8re les fiches et les collections de Semble.<\/p>\n\n\n\n
\n\n\n\n