Discord n’est pas de la documentation
(shkspr.mobi)- Discord est utile pour obtenir de l’aide en temps réel et partager son travail, mais il est structurellement inadapté à remplacer la documentation durable d’un projet
- Il est naturel qu’un projet open source échange là où se trouvent ses utilisateurs, mais Discord est fondamentalement un outil conçu pour des conversations éphémères
- La plateforme de développement Watchy pousse à poser sur Discord les questions qui dépassent le guide de configuration de base, ce qui oblige les utilisateurs à fouiller eux-mêmes dans les messages en l’absence de documentation d’API
- Même lorsqu’on retrouve une question via la recherche, il est difficile d’en comprendre le contexte et la pertinence, si bien qu’une même commande ou option peut être interprétée de travers
- Si l’on ne rassemble pas les questions fréquentes et leurs réponses en un seul endroit, les utilisateurs continueront à subir des frictions inutiles dans leur apprentissage et leur usage du produit
Ce que Discord aide à faire, et ce qu’il ne peut pas remplacer
- Discord permet d’obtenir une aide en temps réel sur un problème, et de voir immédiatement ce que les autres fabriquent ou là où ils bloquent
- La difficulté d’inscription n’est pas très différente de celle d’autres outils de communication comme Slack, Matrix, Gitter ou IRC
- Il est aussi naturel qu’un projet open source suive le principe consistant à « aller là où sont les utilisateurs »
- L’auteur prend l’exemple suivant : si tout le monde est sur Facebook, cela n’a aucun sens de ne publier que sur MySpace
- Le fait que Discord ne soit pas open source pose un certain problème, mais il fonctionne correctement même ouvert dans Firefox
- L’essentiel est que Discord convient aux conversations éphémères, mais ne remplace pas la documentation
Le vide documentaire mis en évidence par Watchy
- Le démarrage avec la plateforme de développement Watchy devient une source de frustration croissante
- Le mode de fonctionnement ressemble à : « le guide de base pour la configuration est ici, pour le reste demandez sur Discord »
- En l’absence de documentation d’API, trouver l’information nécessaire oblige les utilisateurs à faire défiler eux-mêmes une grande quantité de messages
- Quand l’information ne subsiste que dans les conversations Discord, on perd le point de référence structuré qu’apporte une documentation
Le problème de contexte que la recherche ne résout pas
- La recherche dans Discord est difficilement une vraie solution si les gens n’utilisent pas correctement les fils de discussion
- On peut retrouver les questions, mais il est difficile de retrouver les réponses qui vont avec
- Même lorsqu’on trouve une réponse, il est compliqué de savoir si elle répond à la question en cours ou à une autre conversation
- Dans l’exemple cité, une question sur la commande fullscreen, une question sur le formatage du disque et une réponse sur le flag
-fsont mélangées, ce qui rend le contexte visé de la réponse ambigu - Dans une telle structure, une même commande ou option peut être lue avec un sens totalement différent
Les frictions pour les débutants et les questions répétées
- Quand l’information est dispersée dans Discord, les débutants reposent des questions déjà posées très souvent
- Certaines personnes réagissent avec agacement à ces questions de débutants
- S’il y a beaucoup de questions répétées, rassembler les questions courantes et leurs réponses en un seul endroit est une solution plus directe
- Une FAQ n’est peut-être pas la forme finale adéquate d’une documentation complète, mais elle reste nécessaire au minimum comme mise en ordre de l’information
La documentation minimale qu’il faut au moins centraliser
- Il n’est pas obligatoire de suivre le modèle des quatre documents
- Ce modèle a aussi fait l’objet de critiques
- Malgré cela, il est difficile de comprendre qu’on ne rassemble pas au moins les questions fréquentes et leurs réponses
- Une FAQ ne peut pas, à elle seule, résoudre la question d’une documentation exhaustive, mais un projet qui ne va même pas jusqu’à créer une FAQ devrait reconsidérer la publication même de son produit
1 commentaires
Avis sur Hacker News
Il y a une tendance chez les startups à tout pousser sur Discord, support compris, et pour les raisons évoquées dans l’article, cela devient une expérience horrible du point de vue des utilisateurs et des clients.
Il faut beaucoup trop de temps pour comprendre la structure des canaux et savoir où poster, et il est difficile de chercher si une solution a déjà été publiée. On ne sait même pas qui répondra vraiment. Si vous dirigez une startup et envisagez de tout déplacer sur Discord, il faut sérieusement reconsidérer cette décision.
Au lieu de laisser des informations publiques trouvables via Google ou en parcourant un portail d’aide / un site de documentation, on oblige tout le monde à entrer dans un salon de discussion pour reposer des questions qui ont très probablement déjà reçu une réponse. On se crée aussi davantage de travail. Je sais que beaucoup de gens posent des questions sans lire l’aide ou la documentation, mais si le support en libre-service permet d’en résoudre ne serait-ce que 10 %, cela vaut la peine de maintenir cette documentation à jour.
Le sujet avait déjà été abordé sur Hacker News : « Discord is a black hole for information »
https://knockout.chat/thread/33251/1
https://news.ycombinator.com/item?id=30311982
Du moins dans mon cas, le public est très jeune et tout le monde veut être sur Discord. Si de bons membres de la communauté proposent de modérer, cela tourne pratiquement sans effort. D’après mon expérience, c’est la communauté qui a d’abord tiré vers Discord, et l’idée de le lancer ne venait même pas de moi. Même si j’essaie de pousser d’autres plateformes, personne n’en veut. Je ne sais pas pourquoi ça marche, mais ça marche tout simplement.
Il prend en charge la voix, la vidéo et le texte, ainsi que les interactions en temps réel, différées et automatisées. Il fonctionne aussi sur le web, desktop et mobile. On comprend qu’on veuille standardiser sur un seul outil pour simplifier les procédures de support et la formation. Si l’accessibilité et l’ergonomie pouvaient être améliorées, Discord pourrait représenter un grand progrès à bien des égards. Réduire le nombre de canaux et leur donner des noms clairs serait un bon premier pas, et un court message d’accueil avec quelques conseils pourrait aussi aider.
Les paramètres de notification par défaut sont complètement aberrants : tout est toujours non lu, tout est important, et des badges rouges apparaissent partout. À chaque fois que l’on rejoint un nouveau « serveur », il faut d’abord faire un clic droit et choisir « supprimer @everyone et @here », puis « supprimer les mentions de rôle ». Malgré cela, les messages @everyone, @here et @role restent surlignés en jaune comme s’ils vous mentionnaient personnellement. Les mentions de diffusion sont une fonctionnalité forcément vouée aux abus ; elles n’auraient jamais dû exister.
La zone de saisie des messages essaie aussi d’être trop intelligente tout en étant beaucoup trop stupide. Elle a cassé le remplacement de texte natif de macOS, et il me semble qu’elle avale certains caractères quand un message commence par certains symboles. Pourtant, si vous tapez @username à la main sans sélectionner l’autocomplétion qui apparaît, la mention ne fonctionne pas.
L’UI pour ajouter des réactions emoji est aussi ridiculement mauvaise. Elle affiche d’abord les emojis récents, puis une liste interminable d’emojis personnalisés de tous les serveurs, que l’on ne peut même pas utiliser sans abonnement, avant d’arriver enfin aux emojis Unicode.
Les pop-ups, bannières et tooltips qui font la promotion de l’abonnement payant sont extrêmement agaçants. Les pop-ups « nouveautés » aussi. Si j’utilise l’offre gratuite depuis des années sans payer, il faudrait considérer que la probabilité de conversion est déjà faible, et arrêter de me brûler les yeux avec de l’upsell dans l’espoir de faire de moi un client payant.
Les fichiers sont aussi trop souvent bloqués comme étant « too powerful », sans même proposer une option pour laisser le serveur les compresser comme il le souhaite. Et ce alors qu’il est rarement nécessaire d’envoyer une image ou une vidéo bit pour bit à l’identique. Un jour, comme prochain projet, je pense créer une messagerie desktop moderne multiprotocole, et Discord figurera tout en haut de la liste des services à prendre en charge.
Les réactions immédiates de HN à certains sujets deviennent de plus en plus fatigantes.
Beaucoup de gens qui commentent maintenant semblent ne même pas avoir lu de quoi parle l’article, et veulent surtout exprimer leur nostalgie des anciennes mailing lists et de documentations à moitié faites. Ces documentations avaient, au mieux, un exemple de code, et en moyenne n’étaient finalement qu’une sorte de « table des matières » du code source qu’il fallait lire de toute façon. Personnellement, j’aimerais que ce genre de projets ait aussi un BBS en plus de Discord, mais c’est vraiment agréable de pouvoir simplement discuter avec les gens qui créent ce qui m’intéresse, et de se faire des amis au passage.
Dans le cas de Watchy, la documentation était un bon point de départ : https://watchy.sqfmi.com/docs/getting-started
Il y a un diagramme d’architecture, quelques exemples de code pour des cas d’usage courants, et elle montre assez bien que ce projet a un large périmètre et relève du projet « d’aventure ». Un jour, ils pourraient ajouter des liens vers des articles ou projets créés par d’autres, mais je ne sais pas s’il y aura beaucoup de ressources de ce genre. C’est un produit assez de niche.
Il y a ici quelques sujets qui déclenchent beaucoup de gens, et peu importe la soumission réelle : ils postent des commentaires préparés à l’avance sans même lire l’article. Le simple fait de voir quelqu’un créer un compte jetable du genre « discordsucks » pour commenter en dit assez long.
En plus, ce ne sont pas des « serveurs », ce sont des canaux.
Nous avons nous aussi commencé à utiliser https://www.answeroverflow.com/ pour miroiter le contenu de Discord sur le Web
On pourrait faire quelque chose de similaire soi-même, mais AnswerOverflow a de bonnes fonctionnalités et gère bien les questions de consentement. Si vous lancez un nouveau Discord, je recommande fortement d’indiquer dès le départ que le contenu pourra être miroité ailleurs, même si vous ne le faites pas tout de suite. Ce sera beaucoup plus difficile à faire plus tard
La meilleure solution serait de ne pas utiliser Discord, mais à cause des frictions liées aux alternatives, de l’opposition des collègues et de la crainte de fragmenter la communauté, c’était ce qu’il y avait de mieux pour nous. Ne pas utiliser Discord dès le départ est peut-être l’idéal, mais il a au moins l’avantage d’être familier pour certaines communautés. Nous maintenons aussi une « vraie » documentation, mais il est difficile d’y tout inclure, et Discord contient des informations précieuses qui ne sont consignées nulle part ailleurs
C’est-à-dire placer les échanges principaux sur quelque chose d’ouvert comme XMPP MUC, Matrix Spaces, IRC, ou bien Zulip, Mattermost. Même si l’outil de chat à la mode de la semaine change, le camp de base ne sera pas exploité par une grande entreprise qui peut couper le service avec des sanctions ou un nouveau paywall
Dans ma précédente entreprise, nous utilisions Discord pour le support, et c’était excellent
Construire une communauté au départ prend du temps, mais une fois qu’elle existe, c’est un atout majeur. Les plus grands avantages sont le feedback utilisateur en temps réel, la rétention des utilisateurs, la collaboration entre utilisateurs et l’aide portée par la communauté. Discord étant conversationnel, quand on reçoit un retour produit, on peut rapidement discuter du problème exact rencontré et proposer une solution pour voir la réaction. Quand les utilisateurs ont un accès immédiat aux développeurs du produit, ils ont le sentiment que leur avis sert à quelque chose, et la rétention augmente aussi. Quand la communauté devient assez grande, les utilisateurs réfléchissent ensemble à des améliorations ou aident les nouveaux, ce qui réduit le temps que les développeurs consacrent au support
Personnellement, je trouve un peu ridicule la critique selon laquelle « ce n’est pas indexé ». Combien de fois a-t-on cherché une erreur obscure et atterri sur une mailing list ? Le plus souvent, les mails indexés n’ont pas de réponse, et même quand il y en a une, elle ne résout souvent pas le problème. Fouiller dans l’historique des conversations n’est pas un moyen efficace de documenter. Nous utilisons le feedback de la communauté comme signal pour repérer ce qui manque dans la documentation, puis nous la mettons à jour en conséquence. Si 10 utilisateurs demandent cette semaine comment fonctionne la fonctionnalité X, cela signifie qu’il faut mettre à jour la documentation
Il y a maintenant des fils de discussion, certes, mais encore faut-il que tout le monde les utilise. Si vous trouvez quelqu’un qui a posé la même question mais qu’il n’y a pas de réponse, vous ne savez pas si elle est restée sans réponse ou si quelqu’un a répondu hors fil 1 000 messages plus bas. Sans threading, c’est une catastrophe
J’ai souvent cherché des erreurs obscures et atterri sur des mailing lists, mais les forums étaient meilleurs. Sur Discord ou Slack, j’ai rarement eu des réponses, et quand j’en avais, elles n’étaient pas bonnes. Quand une question remonte dans l’historique, plus personne ne la voit, et si quelqu’un répond, c’est souvent un débutant enthousiaste qui n’a pas compris le problème
Avant, je postais beaucoup sur des forums, et je montrais précisément le problème avec un exemple de reproduction bien vérifié. Je pratiquais aussi le « poser une question, répondre à une question » : je parcourais la première page ou les deux premières pages de questions sans réponse et je répondais quand je savais quelque chose
Presque tous les canaux de « support » Discord ou Slack étaient médiocres. C’est une façon pour les entreprises de réduire le support en déplaçant les attentes vers l’idée qu’elles peuvent ignorer les utilisateurs. Drone (CI) l’a fait récemment aussi, et son canal Slack était rempli uniquement de questions d’utilisateurs
Je pense que la vraie raison de la popularité de Discord et consorts, c’est le faible coût en effort. On ne s’attend pas à ce que les gens arrivent avec un exemple complet ; comme c’est une conversation, on peut lâcher une question à moitié formulée et attendre que quelqu’un vous guide et vous tienne la main. Le prix à payer, c’est de perdre les personnes qui veulent participer à une communauté demandant de l’effort plutôt qu’à un espace rempli d’emojis et de mèmes
Le Web lui-même est devenu un espace presque impossible à rechercher. À cause du spam SEO, de la baisse de qualité de Google Search, de la tendance à tout enfermer derrière des murs, et de la hausse des prix des API et de la rétention des données face aux LLM
De manière générale, je pense que la mort progressive du Web recherchable favorise le déplacement vers Discord. Ce n’est pas tant la faute des développeurs individuels : pour eux, comme dit plus haut, le bénéfice net est important. Ce qu’il faut, c’est un « Web ozempic » : conserver l’échelle de 2023, mais avec un Web plus léger, indexable, sans jardins clos, avec moins de remplissage inutile et moins de monétisation par captation de l’attention. D’ici là, on aura beau critiquer les joueurs, c’est le jeu lui-même qui est biaisé
Mais c’est un biais de sélection. Les conversations auxquelles le propriétaire participe se passent évidemment bien. Alors qu’en est-il des autres conversations ? Si une question restée sans réponse est enterrée par une autre discussion trois heures plus tard, l’entreprise ne la voit pas. L’entreprise ne peut pas voir ce qu’elle ne voit pas, et c’est ainsi que naît le biais de sélection
Discord retire l’information de ces lieux ouverts. Parfois, on découvre même un projet grâce à ce genre de réponses. Cela dit, je m’intéresse davantage au FLOSS qu’aux startups au code propriétaire, donc le cœur de cible client peut être différent
Premièrement, vous avez réussi à intégrer Discord au processus de documentation. Quand vous recevez du feedback sur X, vous mettez à jour la documentation pour couvrir X. Eden, lui, dit que beaucoup de projets répondent à X sur Discord puis ne mettent pas la documentation à jour
Deuxièmement, l’équipe répond rapidement aux messages Discord. Beaucoup d’équipes laissent traîner ou ne répondent pas du tout
Le chat n’est pas de la documentation
Quand je bloque quelque part, je commence par parcourir rapidement l’implémentation, mais comme je ne connais pas bien la base de code, ça ne marche pas vraiment. Je consulte la documentation et je n’y trouve qu’un lien « Rejoignez la communauté Discord ». J’ouvre donc Discord, j’installe la mise à jour, je passe une authentification à deux facteurs personnalisée basée sur l’e-mail, j’accepte les conditions modifiées, je ferme la bannière Nitro, j’accepte les règles du serveur, puis j’arrive dans #general. Je pose ma question en donnant autant de contexte que possible, mais je n’obtiens pas de réponse. Au final, je lance le débogueur et je suis la bibliothèque ou le framework ligne par ligne pour comprendre ce qui se passe. Je crée une copie modifiable, j’ajoute du logging et j’essaie quelques correctifs ; quelques heures plus tard, je découvre que X ne prend pas en charge Y, ou qu’il faut encoder la valeur en Base 47 ou en Latin 1 avant de la transmettre. Et trois jours plus tard, à 1 h du matin, je reçois sur Discord une réponse d’un ton dédaigneux me disant d’aller voir une conversation qui a eu lieu deux semaines avant mon arrivée
Le chat fait peser lourdement sur les utilisateurs la charge de comprendre les problèmes par eux-mêmes et de s’entraider. Surtout dans un monde de travail asynchrone, il ne peut pas remplacer la documentation. On pourrait penser que c’est adapté au travail asynchrone parce qu’on peut répondre de manière asynchrone, mais ce n’est pas le cas, car on ne peut pas débloquer quelqu’un de manière asynchrone
Sur environ 8 des 12 dernières années passées à travailler avec Django, les seules fois ou presque où j’ai utilisé un débogueur dans le code de Django, c’était pour découvrir une faille de sécurité et vérifier des détails de très bas niveau. À l’inverse, sur un projet qui recommande Discord à la place de la documentation, j’ai passé environ 5 jours en un mois sur un projet perso, et j’ai dû utiliser le débogueur 3 fois juste pour comprendre ce qui se passait
Il existe ici une vraie solution culturelle et procédurale qui aide vraiment : transformer soigneusement les questions posées sur Discord en mises à jour de la documentation
Si on fait cela, Discord peut devenir un accélérateur puissant de la qualité de la documentation d’un projet. Mais cela demande une discipline équivalente
Si je dois faire mon travail mais que je dois surveiller Slack, Discord et Mattermost toute la journée, alors je ne peux pas faire mon travail. Sauf si mon travail, c’est le support. C’est encore un exemple où le développement logiciel absorbe un autre domaine métier, le support, parce que les développeurs sont globalement naïfs, très attachés à leurs opinions et désireux de satisfaire les autres. Avec l’agile, ils ont pris en charge la gestion de projet ; avec DevOps, ils ont pris en charge l’administration système. Cela peut dépendre du contexte
J’ai l’impression que quelqu’un l’a déjà implémenté, mais la dernière fois que j’ai cherché, je n’ai rien trouvé
En tant qu’utilisateur d’un produit, je n’ai pas envie de rejoindre une communauté de personnes au hasard et de me retrouver entraîné dans des conversations improductives
Je n’ai pas non plus envie de rafraîchir un chat quasi synchrone, ni de rater des informations importantes parce que j’ai manqué une journée. J’aimerais que les entreprises respectent mon temps et mon attention
La recherche de Discord est étonnamment mauvaise. Les utilisateurs s’en plaignent depuis des années, mais elle ne s’améliore pas
Rien que pour cela, il n’a pas les qualités requises pour servir de documentation
Si un utilisateur quitte le serveur, on ne peut plus rechercher spécifiquement ce qu’il a publié. Même si l’utilisateur est encore sur le serveur, la recherche Discord ne semble pas toujours connaître l’ensemble des utilisateurs actuels, ce qui peut rendre difficile de retrouver ce qu’il a posté. Quand on recherche un terme qui donne beaucoup de résultats et qu’on essaie de revenir à la première page, c’est-à-dire aux résultats les plus anciens, ça casse. Par exemple, sur un serveur, je ne peux pas sauter jusqu’à mon premier message. On ne peut pas non plus rechercher dans un thread précis. La méthode de recherche textuelle elle-même m’avait déjà agacé auparavant, mais je n’arrive plus à trouver un bon exemple de ce qui posait problème
Dans ce type d’entreprise, l’engagement — autrement dit, le temps perdu — tend à être considéré comme une qualité souhaitable
Pour la même raison, Slack non plus n’est pas de la documentation
Je travaille actuellement à améliorer la documentation dans toute l’entreprise. Nous sommes une vieille startup, dans un secteur où la mise sur le marché prend énormément de temps, et le trimestre dernier j’ai dirigé deux projets où nous avons passé des semaines à répondre à des questions sur du vieux code. Parfois, l’auteur d’origine avait déjà quitté l’entreprise et il n’y avait aucune documentation ; parfois, l’auteur d’origine était encore là, mais ne se souvenait littéralement même pas d’avoir écrit ce code, et là encore il n’y avait pas de documentation. À chaque fois, des gens disaient qu’il devait y avoir quelque part une conversation Slack qui expliquait tout. Non, ce n’est pas le cas. Chaque projet et chaque application a besoin d’un document de conception en amont, puis d’un manuel utilisateur après coup, et ceux-ci doivent réellement être maintenus
Il est déroutant de voir la communauté au sens large s’enthousiasmer à ce point pour Discord
Comme quelqu’un d’autre l’a dit, fondamentalement, c’est de l’IRC avec du multimédia. Pourquoi en faire autant la promotion ? Même si l’on accepte l’idée très controversée de « se faire aider sur Discord », le produit lui-même n’a rien de spécial. Il n’est qu’un peu meilleur que les produits similaires qui existaient déjà. Sans parler des préoccupations très réelles sur la manière dont les données des utilisateurs seront utilisées à l’avenir
Et beaucoup d’utilisateurs n’ont jamais utilisé IRC. Le fait qu’il existe une application portant le même nom que le service compte aussi beaucoup. Cela en fait donc une seule et même « chose », comme Instagram ou TikTok. Il est assez surprenant de voir combien de personnes n’ont jamais réfléchi au fait que l’application reddit et le service/site reddit sont distincts. Même la communauté IT au sens large reste encore assez proche d’une petite niche, et nous l’oublions souvent
À l’exception de Slack, Discord a créé le produit de meilleure qualité parmi les applications de chat et de voix grand public basées sur navigateur. Il est bien conçu, stable, et dispose d’une interface utilisateur globalement simple
IRC et les nombreuses alternatives souvent mentionnées restent souvent bloqués dès cette première étape, même pour un chat purement textuel, sans parler du multimédia. Les concurrents qui l’ont compris ont échoué dans l’implémentation ou sont arrivés trop tard. Les préoccupations liées à la vie privée sont tellement basses dans les priorités des utilisateurs qu’elles ont peu de chances de faire tomber l’avantage du premier entrant de Discord
Rien que cela suffit. Mais à bien des égards, c’est aussi nettement mieux qu’IRC. Bien sûr, on peut faire tourner soi-même un bouncer IRC pour Libera sur un « compte shell » ou sur une micro-instance AWS toujours allumée, mais qui a envie de faire ça, à part les plus geeks ? Et malgré tout, quand on rejoint un nouveau canal, on ne peut pas voir les anciens messages, et même avec un bot de journalisation ou une page d’archives, cela reste rudimentaire. Sans oublier le rituel NickServ à accomplir sur chaque réseau. Et il n’y a pas non plus de bon multimédia, que la plupart des utilisateurs attendent aujourd’hui comme norme de communication courante
À cela s’ajoutent une UI correcte, des aperçus de liens où l’expéditeur sait exactement ce que le destinataire verra, une mise en forme des messages façon Markdown, assez de métadonnées pour relier les réponses, des réactions emoji concises qui ne transforment pas le canal en spam, ainsi que des conférences audio et vidéo qui fonctionnent bien sans configuration supplémentaire. Mis à part la recherche et son interface, l’UI est également bonne par rapport aux alternatives, à l’exception peut-être de Zulip
Autrefois, j’utilisais IRC tous les jours, je maintenais un bouncer avec archivage et j’administrais des canaux communautaires, mais aujourd’hui je ne m’en préoccupe plus. Pendant une période où j’ai été occupé et malade, mon nom d’utilisateur NickServ enregistré a expiré, ce qui a même cassé l’administration des canaux, et cela m’a aussi découragé. Quand tout le monde a quitté Freenode pour Libera, j’ai simplement arrêté d’utiliser IRC
En même temps, je suis tout à fait d’accord avec la critique selon laquelle les projets utilisent Discord d’une manière qui fait qu’ils produisent sans cesse de la documentation utile tout en la perdant de fait. Il faut reconnaître que Discord a créé un produit de qualité, bien fini, avec des effets de réseau compréhensibles. Mais il est regrettable qu’il soit difficile pour un projet de rendre ses canaux publiquement archivés et consultables, et regrettable aussi que ce ne soit ni un réseau ouvert ni un produit open source. Le fait que la recherche et son interface soient médiocres l’est tout autant
Étant donné que la plupart des projets que je vois utiliser Discord, y compris des projets commerciaux, sont open source, il reste possible que Matrix finisse un jour par le remplacer, à moins que Discord n’ouvre son réseau d’une manière ou d’une autre. Cela dit, les projets existants ne peuvent pas déplacer leur historique de chat ni leurs utilisateurs, et les nouveaux projets doivent aller à la rencontre des utilisateurs là où ils se trouvent déjà, c’est-à-dire sur des réseaux comme Discord, Slack ou Telegram, ce qui crée beaucoup de friction