Comment connecter les auteurs aux lecteurs ?

Lorsque j’ai débuté l’écriture de TNBS, je savais que la publication allait être une tâche complexe. Lorsque j’ai terminé l’écriture de TNBS, j’ai appris douloureusement qu’atteindre les lecteurs sans l’aide de grands moyens publicitaires était quasiment impossible.

Demander directement sur des forums de lecture ? Ça ne se fait pas ; on se fait jeter. L’autopromotion, c’est banni. Limite, les lecteurs devraient être rémunérés pour lire nos œuvres, qui sont de toute manière nulles ou non finies car elles n’ont pas trouvé d’éditeur « respectable ».

Partager sur les sites d’entraide d’auteurs ? C’est une fausse piste pour moi. On n’y est pas pour lire, mais pour écrire. Certains sites demandent même tacitement ou expressément aux auteurs de lire pour bien se faire voir par les membres de la communauté. Déjà qu’il peut être ennuyeux de lire des livres déjà publiés, lire le travail en cours des autres, ça ne peut que l’être encore plus, à moins que ce ne soit son métier, ou une énorme passion.

Naviguer sur l’océan des plateformes de publication en ligne ? Pourquoi pas. Mais il faut s’accrocher très dur au gouvernail, à en briser les poignées, pour remonter les classements créés par les algorithmes. Les tops des classements restent des tops des classements, parce qu’ils sont visibles. Et à moins d’un miracle qui se produit toutes les nouvelles lunes, les fonds de classement restent dans les fonds. Et quand on observe les tops lecture dans les suggestions, je ne sais pas pour vous, mais ça me déprime.

Vendre sur Amazon via KDP et Kobo ? Je crois que là, sans stratégie de communication préalable et une communauté de base enthousiaste, c’est juste de la perte de temps. Comment construire cette communauté en partant de rien ? À moins de faire le buzz d’une manière ou d’une autre, c’est un processus long, difficile, avec beaucoup d’investissement personnel.

Quand on voit tout cela, on se dit que le web, c’est de l’entre-soi, des sites inadaptés, ou des sites qui sont faits pour nous enfermer dans leurs systèmes… En tous cas, je pourrais me résoudre à ce constat. Mais je n’ai pas encore abandonné ma vision d’un web qui relie les gens plus qu’il ne les divise.

Ma proposition : un service de mise en relation indirecte

Ma piste de réflexion actuelle est la suivante :

• En tant qu’auteur, on veut trouver des lecteurs.
• En tant que lecteur, on veut rechercher des nouveautés hors du circuit traditionnel de l’édition.
• Il faudrait donc une sorte d’index de lecteurs.
• Il faudrait donc que ces lecteurs s’inscrivent quelque part.
• Il faudrait que ces lecteurs puissent indiquer leurs préférences.
• Il faudrait que ces lecteurs indiquent leur temps qu’ils peuvent accorder à la lecture, sous forme de seuil de nombre de caractères (ou autre moyen de quantification de longueur d’une œuvre).
• Il faudrait que chaque lecteur ait un compteur individuel de caractères, afin de connaitre l’état actuel de sa pile à lire, pour que l’on sache s’il a le temps de lire.
• Il faudrait que les lecteurs puissent bloquer des auteurs néfastes (spam, hackers). Peut-être aussi que les auteurs puissent ignorer des lecteurs ?

La notion de temps est importante. Nos vies sont limitées. Nous ne passons pas tout notre temps ni notre énergie à lire. Et puis, nous n’avons pas le temps de nous préoccuper des spams et des hackers.

L’indicateur de temps disponible est donc un premier moyen simple de juguler le flux de demandes qui peut arriver. L’autre moyen repose sur des mécanismes de blocage, par utilisateur, voire par domaine, lorsqu’il s’agit de flux indésirables.

Exemple de flux d’échanges :

• Un auteur propose son œuvre, en indiquant le titre, le nombre de caractères qu’il contient ainsi que les genres parmi une liste prédéfinie (ou alors système de tags).
• Une information de nouvelle œuvre est envoyée à tous les lecteurs enregistrés dans l’index dont les genres ou tags correspondent.
• Pour chaque utilisateur, on regarde si le compteur de caractères additionné au nombre de caractères de la nouvelle œuvre est supérieure au seuil qu’il a déterminé.
  • Si supérieur, alors l’utilisateur ne reçoit aucune notification.
  • Si inférieur, une demande de lecture est envoyée au lecteur.
• Le lecteur décide quoi faire de la demande :
  • Il le rejette. Rien d’autre ne se passe.
  • Il l’approuve : Le compteur de caractères est augmenté du nombre de caractères de l’œuvre approuvée.
• Le lecteur termine ou arrête la lecture.
• Le lecteur envoie une notification de fin de lecture.
  • Le compteur de caractères est diminué du nombre de caractères de l’œuvre terminée.

Techniquement parlant, le système pourrait-il se baser sur les mécanismes du fédivers et ActivityPub ?

On aurait donc une instance, qui fait office de cercle de publication, qui pourrait rassembler des lecteurs ayant des intérêts similaires. On ne s’y inscrirait pas directement dessus, mais on s’abonnerait ou se désabonnerait via un système de messages privés à un bot de configuration, directement depuis Mastodon et tous les services compatibles avec ActivityPub.

Quand un auteur veut publier une œuvre, il soumet une demande au bot de l’instance. Et ce bot effectue toutes les vérifications mentionnées plus haut avant d’envoyer éventuellement un message privé au lecteur qui a souscrit au service. Et optionnellement, le lecteur pourrait choisir de notifier l’auteur que sa proposition a été approuvée, parce que c’est toujours sympa de savoir qu’on va être lu·e !

Que pensez-vous de cette idée ? Il y a certainement quelques trous dans la raquette qui méritent une réflexion poussée, et je ne sais pas exactement comment fonctionne le fédivers, mais je pense que le concept est viable.

Le concept s’appuie sur le fait que ce sont des humains derrière les comptes d’auteurs et de lecteurs. Il permet de bloquer des utilisateurs, voire des instances entières en cas de problème. Il limite les demandes de lecture sur un critère physique, notre temps libre. Zéro algorithme qui privilégie une demande sur une autre en fonction de paramètres obscurs. Et évidemment : gratuit (hors cout de l’hébergement du serveur).