- Les anciens systèmes de commentaires (Disqus, auto-hébergement, GitHub Issues, etc.) ne sont pas utilisés à cause de problèmes de performance, de tracking, de maintenance et de limites utilisateurs.
- Bluesky convient aux commentaires de blog car il n’exige pas de maintenance d’infrastructure, prend en charge le contenu riche, utilise des comptes à identité réelle et autorise des conversations cross-platform.
- La méthode d’implémentation consiste à publier l’article du blog, à le partager sur Bluesky, à ajouter l’AT URI aux métadonnées du post, puis à charger et afficher le thread de commentaires de ce post.
- Les composants sont séparés en 3 : affichage global des commentaires, affichage des commentaires avec leurs réponses, et traitement des embeds (images, liens, etc.).
- Les réponses imbriquées sont affichées en récursif, jusqu’à une profondeur maximale de 5 niveaux ; les images utilisent une grille et un affichage modal, les liens une carte dédiée, et les embeds non pris en charge affichent un message de remplacement.
- Intégration Astro + React avec chargement côté client via
client:load; l’activation se fait en ajoutant le DID et le postCid au frontmatter. - Utilisation des types TypeScript de
@atcute/clientpour la sûreté du typage, avec une logique de progressive enhancement où le contenu de l’article reste affiché même si le JavaScript est désactivé. - Performance assurée en exploitant l’API Bluesky et le CDN, sans serveur ni base de données.
- Cette approche garantit l’évolutivité et l’indépendance en se connectant à la plateforme déjà utilisée par les utilisateurs, plutôt que de réimplémenter les fonctionnalités sociales site par site.
Pourquoi choisir Bluesky comme système de commentaires
- Pas de maintenance d’infrastructure nécessaire
- Prise en charge de contenus enrichis comme les images, les liens et les posts cités
- Fiabilité et responsabilité grâce aux comptes Bluesky
- Trafic croisé possible entre blog et réseaux sociaux
- Propriété du contenu séparée (article détenu par l’éditeur, commentaires détenus par leurs auteurs)
Comprendre le protocole AT
- DID : identifiant utilisateur décentralisé
- CID : identifiant du contenu
- AT URI : adresse de forme
at://did:.../app.bsky.feed.post/... - Récupération du thread de commentaires possible via l’appel API
getPostThread, sans authentification
Structure des composants
- Composant principal des commentaires
- Composant de rendu d’un commentaire et de ses réponses imbriquées
- Composant de gestion des embeds (images, liens, etc.)
Gestion des commentaires imbriqués
- Rendu récursif, profondeur maximale limitée à 5 niveaux
- Représentation hiérarchique par indentation visuelle
Gestion du contenu enrichi
- Images : fournies par un CDN, vue grille pour plusieurs images et modal
- Liens externes : rendu de cartes avec miniature et description
- Autres embeds : affichage d’un texte de remplacement
Intégration à Astro
- Composants React + utilisation de
client:load - Activation des commentaires via ajout du DID et du postCid de Bluesky dans le frontmatter
Retour d’expérience de développement
- Stabilité grâce au support des types TypeScript
- Grâce au progressive enhancement, l’article reste intact même en cas de panne de l’API
- Utilisation de l’infrastructure Bluesky sans charge serveur ou base de données
Conclusion
- Éviter les limites des systèmes de commentaires existants en se connectant à une plateforme déjà utilisée par les utilisateurs
- Hausse potentielle du nombre de participants avec la croissance de Bluesky
- Basé sur ATProto, la transition vers d’autres AppView ou implémentations propres est facilitée
1 commentaires
Avis sur Hacker News
J’aimerais qu’ils exposent une vision d’ensemble de la manière dont Bluesky monétisera à l’avenir. C’est une architecture technique complexe, mais au final, si quelque chose devient payant, je me demande par quel modèle cela se fera.
Je trouve l’article intéressant, et j’aime personnellement lire comment les gens construisent et exploitent un site web de manière autonome. L’article évoque le problème des systèmes de commentaires et mentionne quatre alternatives, mais je veux dire que la cinquième méthode m’a également bien convenu. J’ai essayé plusieurs systèmes de commentaires tiers, puis j’ai fini par créer et utiliser un système de commentaires simple (form.lisp) ; chaque commentaire est stocké dans un fichier texte, donc je n’ai pas à m’inquiéter du spam, du XSS ou des commentaires sans valeur, et je les vérifie manuellement les week-ends avant de les ajouter au blog. Les commentaires sont stockés sous forme de fichiers HTML classiques, et le générateur de site statique (site.lisp) crée aussi une page de commentaires (exemple de commentaires) avec l’article, donc il fonctionne fondamentalement comme un générateur de commentaires statique. Il ne respecte pas les cinq propriétés mentionnées dans l’article (pas d’infrastructure dédiée, contenu riche, identité réelle, etc.), mais il me convient très bien et je l’utilise avec satisfaction depuis plus de 4 ans.
Recevoir des commentaires via un formulaire e-mail, puis les ajouter soi-même en bas de l’article en tant qu’admin, c’est aussi une bonne option.
Cette méthode convient aussi très bien à un blog à faible trafic. Mais personnellement, la voix d’autrui sur mon site me met mal à l’aise, donc j’ai retiré les commentaires et je me sers du blog uniquement comme espace d’expression personnelle ; je préfère laisser une rétroaction par e-mail aux autres blogueurs qui m’inspirent.
Ça rappelle la rubrique «articles des lecteurs» dans les journaux.
Ma recommandation est cactus.chat ; c’est basé sur Matrix et le mode invité est supporté, donc on peut commenter sans compte Matrix. Si l’on utilise son propre compte, on rejoint une room Matrix par publication.
Bluesky est très utile pour stocker des informations avec des comptes utilisateurs existants. Actuellement, le projet open source de cartographie web cartes.app développe un système d’avis basé sur Bluesky. Ça n’est pas simple : il faut créer un lexicon, et maintenir une DB en fonction du flux Bluesky.
En réalité, on peut aller assez loin sans DB ; même avec scrapboard.org, on pouvait déjà interroger beaucoup de données client en ne s’appuyant que sur l’API getRecord (documentation).
Une proposition était d’utiliser mangrove.reviews à la place. Ce service applique une licence CC-BY-SA claire, et MapComplete.org l’utilise aussi. Bluesky peut aussi rencontrer des problèmes un jour.
Je suis sceptique sur la pérennité du modèle de revenu de Bluesky. Le fait qu’on puisse l’utiliser gratuitement aujourd’hui tient en grande partie aux investissements des VC (venture capital). Je suis donc prudent avant de l’adopter, avec l’inquiétude qu’une fermeture d’API ou une panne du système de commentaires arrive assez tôt.
Du point de vue de l’architecture, Bluesky fonctionne via le PDS (Personal Data Server) de l’utilisateur. N’importe qui peut changer de PDS, et le serveur d’app officiel Bluesky n’a qu’un rôle d’agrégation. Un app server ou un app view créé par un tiers peut aussi accéder aux mêmes données, donc il n’est pas nécessaire de dépendre de l’API officielle : l’ouverture est élevée sur plusieurs points.
Je crois beaucoup au concept de POSSE. Un point positif du «enshittification cycle» est de pouvoir profiter pendant un moment d’une expérience communautaire en ligne agréable, puis de déménager ailleurs. Comme pour les bons clubs disparus, je pense qu’il ne faut pas trop s’accrocher. J’ai aussi un résumé de ma réflexion sur Mastodon : explication théorique.
Bluesky finira probablement par passer à la monétisation, mais l’IA et d’autres services fonctionnent tous de la même manière sur des fonds de VC. Comme pour Twitter, Uber, DoorDash, etc., l’atmosphère se dégrade inévitablement, mais tant que les VC injectent de l’argent en rêvant d’une nouvelle richesse, c’est aussi assez amusant de profiter de cette «abondance».
Je trouve vraiment que l’écosystème Bluesky est super. J’ai déjà vu auparavant un cas d’usage de cette méthode (système de commentaires basé sur Bluesky). Petit bémol : il faut poster séparément sur Bluesky pour chaque page web afin que le système de commentaires fonctionne ; avoir un webcomponent, par exemple, serait encore mieux.
Vous avez écrit qu’il y avait «pas de vrai système de commentaires sur le blog depuis plusieurs années», mais sur l’ensemble du blog, seuls deux articles de 2025 sont visibles (dont celui-ci).
C’est intéressant comme manière d’interagir avec les réseaux sociaux sans avoir à faire face au flux social. Je pourrais ajouter cette fonctionnalité à mon blog pour que les gens laissent directement des commentaires, et n’interagir avec Bluesky ou d’autres réseaux sociaux que via ce type d’interface. Ouvrir le feed mène souvent au doomscrolling ou à une perte de temps ; cette approche permet d’éviter ce cercle vicieux tout en permettant une certaine connexion au social.
J’ai l’impression que Bluesky recrée un environnement où l’on peut faire émerger de nouvelles idées sur Internet de manière libre.
En réalité, ça pourrait être vu comme une option d’intégration plus ouverte ajoutée à Threads ; peut-être que l’expression «innovation ouverte» convient mieux à ATProto.
Je ne veux pas trop accorder d’attention aux entreprises ou à un seul groupe, mais la communauté Bluesky est intéressante pour l’instant. J’étais fan de l’ancien Twitter, et il me semble que la base d’utilisateurs principale de Bluesky comporte beaucoup de ces profils ; on verra bien ce qu’il adviendra ensuite.
Je suis convaincu par le slogan «protocol not platform» ; on parle aussi de «build mode», mais au fond, il s’agit de créer quelque chose de difficile à s’approprier ou à détourner.
Si l’on gêne l’équipe Bluesky ou certains groupes d’utilisateurs, ou si l’on se fait signaler par un groupe donné, son compte peut être banni immédiatement, ou disparaître silencieusement avant même d’en avoir parlé si son nom figure déjà sur une liste noire partagée. Au fond, cela ressemble à une tentative de recréer un environnement encore plus dur que l’ancien Twitter, avec des luttes de pouvoir un peu puériles, comme à la cantine d’un lycée.
En m’appuyant sur Bluesky plutôt qu’en auto-hébergeant mon blog, c’est en pratique Bluesky qui le gère. On dit qu’il n’y a pas de lock-in plateforme, mais je me demande quel plan prévoir si demain Bluesky bloque mon compte ou si la société fait faillite. Je peux sans doute basculer vers une stack compatible AT, mais j’ai peur que beaucoup de données ne disparaissent.
Si ce sujet vous intéresse, https://whtwnd.com/bnewbold.net regroupe des informations et des outils concrets sur la construction d’un réseau de relais, la migration de données, etc. basé sur Bluesky et ATProto ; il y a des avancées sur la migration, la portabilité et le support de relais alternatifs. Le lien associé est également disponible. (À noter : l’auteur de ce blog est un employé de Bluesky ; je suis indépendant.)
On peut sauvegarder ses données personnelles dans un fichier CAR (au format tarball) utilisé avec IPFS. Ensuite, via le document did:plc du compte ou un enregistrement DNS, on peut restaurer vers n’importe quel PDS. Si le PDS actuel est en panne ou bloqué, on peut basculer immédiatement sur un autre serveur. Il existe des implémentations open source et des hébergeurs pour les relais (gossip node), PDS, clients et app views (backend de l’app web Bluesky). Même si Bluesky disparaissait demain, il serait possible d’auto-héberger facilement ou de reprendre l’app existante via un autre prestataire, par exemple zeppelin.social. Le PLC Directory est encore géré par Bluesky mais en cours de transfert vers une fondation indépendante, et on peut en faire des copies si nécessaire ; en mode did:web, la dépendance repose uniquement sur le DNS, ce qui augmente l’autonomie.
Par ailleurs, Bluesky exclut clairement les utilisateurs libertariens ou de droite, tandis que l’ambiance reste correcte pour les profils de gauche ou politiquement indifférents.