Plugin WordPress text to speech français : ce qu'il installe, ce qu'il ne touche pas
La liste exacte de ce que le module WeDispatch écrit dans votre WordPress quand vous l'activez : quelques réglages, une empreinte par article, aucune ligne dans votre thème et aucune donnée sur vos lecteurs.
Avant d'installer une extension sur un site en production, une question honnête se pose : qu'est-ce qu'elle va réellement écrire dans mon WordPress, et qu'est-ce qu'elle va me laisser à nettoyer si je la retire ? Pour un module qui transforme vos articles en audio, la réponse compte double, parce qu'il touche à la publication. Voici la liste précise de ce que le plugin WeDispatch met dans votre installation, sans rien arrondir.
Ce qu'il écrit, réglage par réglage
Le module range ses réglages généraux dans les options de WordPress, à l'endroit prévu pour ça. On y trouve votre clé de service (celle qui relie le site à votre compte WeDispatch), la position du lecteur (avant l'article, après, ou nulle part si vous le placez vous-même), le mode d'accès (ouvert à tous ou réservé à vos abonnés), et le catalogue de voix mis en cache pour ne pas le redemander à chaque écran. Ce sont des réglages de site, pas de contenu : quelques lignes, lisibles, qui vivent là où WordPress attend ses options.
Le routage des voix ajoute deux réglages ciblés. Une voix peut être fixée par rubrique, et elle est alors rangée dans les données de la catégorie ; une voix peut être fixée par auteur, et elle est rangée dans le profil de l'utilisateur. C'est ce qui permet à la rubrique Sport de ne pas sonner comme les nécrologies, et à un chroniqueur d'avoir sa voix, sans jamais toucher au texte de ses articles.
Ce qu'il écrit sur chaque article
Sur un contenu sonorisé, le module pose une poignée d'informations, et pas une de plus. Il enregistre l'identifiant de l'article correspondant côté service, une empreinte du texte (pour savoir si le texte a changé depuis la dernière génération), et, si vous les avez réglés au niveau de l'article, un mode et une voix propres à ce contenu. C'est tout. Cette empreinte est exactement ce qui permet de ne pas regénérer un audio pour une correction de virgule : tant que le texte n'a pas bougé, l'audio en ligne reste servi, et l'article n'est marqué à regénérer que quand son texte a réellement changé.
Ce que le module n'écrit pas dans l'article mérite d'être dit aussi. Il ne modifie pas le corps de votre contenu. Le bloc de l'éditeur et le raccourci [wedispatch] ne gravent rien dans le texte enregistré : ils posent un repère lu au moment de l'affichage, et l'identifiant de l'audio est retrouvé à l'affichage, jamais figé à l'enregistrement. Un article régénéré change d'identifiant côté service, et un repère qui aurait mémorisé l'ancien pointerait vers un audio disparu. Cette précision technique est ce qui rend le mécanisme sûr, et nous la détaillons dans notre article sur le lecteur qui s'insère sans toucher au thème.
Ce qu'il n'écrit nulle part : la donnée de vos lecteurs
Le point qui rassure le plus les éditeurs est celui-là. Le module n'enregistre aucune donnée personnelle sur vos visiteurs. La liste « à écouter ensuite » dépend de l'article affiché, jamais de qui l'écoute. Quand vous réservez l'audio à vos abonnés, votre site atteste d'un statut (« abonné »), jamais d'une identité, et aucune donnée sur le lecteur ne quitte votre serveur. Il n'y a donc pas de journal de lecture à purger, pas de profil d'auditeur qui s'accumule dans votre base : il n'y en a jamais eu.
Ce qu'il installe côté visiteur, et comment
Le lecteur audio n'est pas une balise injectée à la va-vite dans votre page. Il passe par la file d'attente officielle des scripts de WordPress, en pied de page et en chargement différé, exactement comme n'importe quel autre script bien élevé. Concrètement, cela veut dire que vos extensions de cache et les réglages de performance de votre hébergeur le gèrent comme le reste, au lieu de buter dessus. Le lecteur lui-même est servi par WeDispatch, qui gère sa propre mise en cache : le module ne fige pas une version du lecteur dans votre site.
Pourquoi cette sobriété est un choix, pas un manque
On pourrait croire qu'un module qui écrit peu en fait peu. C'est l'inverse. Le travail lourd (lire le texte, fabriquer l'audio, tenir le catalogue de voix, produire le transcript) se fait côté service, pas dans votre base de données. Votre WordPress ne porte que ce dont il a besoin pour savoir quel audio va avec quel article et avec quelle voix. C'est ce qui rend le module léger à installer, propre à retirer, et lisible à auditer. Si vous voulez voir tout ce que ce parti pris ouvre côté fonctionnalités, la page WordPress le détaille, et notre article sur ce que veut dire la qualité à la française explique pourquoi nous préférons en écrire peu, mais le dire exactement.
Sonorisez vos articles avec WeDispatch
Ce blog sera lui-même sonorisé par WeDispatch. Envie de voir ce que ça donne sur vos contenus ?
Demandez une démo