Articles réservés aux abonnés : les mettre en audio sans ouvrir le verrou
Un article payant pose deux questions à un outil audio : où trouve-t-il le texte complet, puisque la page publique n'en montre que le chapô, et à qui sert-il le son ? Ce que fait WeDispatch dans les deux cas, lu dans le code, et ce qu'aucun verrou ne protège.
Un site de presse qui vit de l'abonnement a, en général, deux catégories d'articles : ceux qu'il laisse en accès libre pour se faire trouver, et ceux qu'il réserve à ses abonnés parce que ce sont eux qui justifient le prix. Le jour où il veut proposer l'écoute, c'est presque toujours sur la seconde catégorie qu'il y tient le plus. C'est aussi là que les choses se compliquent.
Un article réservé pose deux questions distinctes à un outil de mise en audio. D'abord : où trouve-t-il le texte, puisque la page que voit un visiteur anonyme s'arrête après le chapô ? Ensuite : une fois l'audio fabriqué, à qui le sert-il ? Si l'outil répond mal à la première, il sonorise trois lignes. S'il répond mal à la seconde, il offre à tout le monde, en version audio, ce que le site fait payer en version écrite.
Première question : d'où vient le texte complet
Coller l'adresse ne suffit pas, et l'outil doit le dire
Le chemin le plus simple pour essayer un outil consiste à coller l'adresse d'un article. Sur un article payant, ce chemin ne peut pas marcher : l'outil lit la page comme un visiteur anonyme, et un visiteur anonyme ne reçoit que l'introduction.
Ce qui compte, c'est la façon dont l'échec est annoncé. Pendant un temps, nous répondions « aucun article lisible détecté à cette adresse », ce qui laissait croire que l'outil ne savait pas lire la page. Depuis le 29 juillet 2026, la réponse est juste : « Cet article est réservé aux abonnés du site : sa page publique ne contient que l'introduction. » La détection ne repose pas sur l'apparence de la page mais sur ce que l'éditeur déclare lui-même dans ses données structurées : la propriété isAccessibleForFree à false, que la presse payante publie parce que Google la demande pour le contenu masqué, ou la balise article:content_tier à locked, metered ou paid. Nous avons écarté volontairement la détection par noms de classes CSS : elle change à chaque refonte, et un faux positif annoncerait un mur payant là où la lecture a simplement échoué.
Le texte doit venir de l'intérieur
La bonne source, c'est le site lui-même, qui possède l'article entier. Avec le module WordPress, le texte envoyé à la fabrication est le contenu de l'article tel qu'il est enregistré dans WordPress, pas la page rendue au visiteur : le mur payant posé par une extension d'abonnement n'entre donc pas dans le jeu. Sur un autre CMS, c'est le serveur qui envoie le texte par l'API, avec sa clé. Dans les deux cas, le texte complet ne transite jamais par le navigateur d'un lecteur.
Une précision qui évite une mauvaise surprise : un article WordPress publié mais protégé par un mot de passe est traité comme un article retiré. Son audio est dépublié, comme celui d'un article repassé en brouillon. Le mot de passe de WordPress n'est pas un système d'abonnement, et nous ne le traitons pas comme tel. Le détail du retrait est dans notre article sur ce que devient l'audio d'un article dépublié.
Seconde question : à qui l'audio est servi
Trois réglages, et un extrait taillé dans le même son
Dans l'espace client, l'écran « Qui peut écouter » propose trois modes : tout le monde, les visiteurs inscrits, les abonnés. Hors du mode ouvert, celui qui n'a pas le droit entend un extrait, puis le lecteur l'invite à aller plus loin. L'extrait dure 30 secondes par défaut et se règle jusqu'à cinq minutes.
Il n'est pas refabriqué : c'est le début de l'audio complet, découpé au moment de la fabrication, sans un caractère de synthèse en plus. Il est produit pour tous les articles, même sur un compte en accès ouvert, pour une raison pratique : un éditeur qui active le verrou un jour donné doit trouver un extrait prêt sur tous ses articles déjà publiés, pas un lecteur cassé.
Le verrou est sur le fichier, pas sur le bouton
Masquer un bouton n'a jamais protégé un fichier. En mode extrait, la page du lecteur reçoit l'adresse du fichier d'extrait, et l'adresse du MP3 complet n'entre jamais dans le HTML. Le calage mot à mot, qui sert au surlignage, n'est pas servi non plus : il contiendrait le texte que le verrou protège. Et le flux du podcast d'un compte restreint ne publie que les extraits. Un article réservé ne ressort donc pas en entier par la porte des applications de podcast.
Qui décide qu'un visiteur est abonné
Pas nous. Nous ne savons pas qui lit une page, et nous ne voulons pas le savoir. C'est le serveur du site qui atteste le statut de chaque visiteur, en signant un jeton court : il dit « ce visiteur est abonné », jamais qui il est. Le jeton est lié à un seul article et expire au bout de 30 minutes, il ne peut donc ni servir sur tout le site ni circuler durablement.
Sur WordPress, ce travail est fait par le module. Vous cochez le ou les rôles qui correspondent à vos abonnés payants ; un utilisateur connecté sans l'un de ces rôles compte comme simple inscrit. Si vos abonnements ne sont pas des rôles (MemberPress, WooCommerce Subscriptions, un système maison), un filtre unique, wedispatch_visitor_status, permet de brancher votre propre règle. Le jeton est demandé par le lecteur à une route de votre site plutôt qu'écrit dans la page : les extensions de cache enregistrent le HTML d'un visiteur et le resservent à tous, et le jeton d'un abonné se serait retrouvé chez les anonymes. Un bouton de test, dans les réglages du module, signe un jeton et nous demande s'il est accepté : c'est le seul moyen de distinguer une signature fausse d'un problème de droits, deux pannes qui se présentent par le même symptôme (« mes abonnés n'entendent que l'extrait »).
Un point de vigilance pour ceux qui intègrent par le bloc composé côté serveur : ce bloc est appelé par votre serveur sans jeton de visiteur, il sert donc ce qu'un anonyme recevrait. Pour réserver l'audio, c'est le chemin par l'API depuis votre CMS qu'il faut prendre.
Ce qu'aucun verrou ne protège
Un abonné qui écoute l'article en entier peut l'enregistrer, exactement comme il peut copier le texte qu'il lit. Le verrou empêche un non-abonné d'obtenir le fichier complet ; il ne contrôle pas ce que fait un abonné légitime de ce qu'il a reçu. Aucun outil audio sur le web ne le fait, et un fournisseur qui le promet décrit autre chose qu'un lecteur dans une page.
Reste la question de fond : faut-il réserver l'audio ? Certains éditeurs ouvrent l'écoute de tous les articles pour en faire une porte d'entrée ; d'autres en font un avantage de l'abonnement. Le mur d'inscription sert la première stratégie, le mode « abonnés » la seconde. Les deux se règlent dans le même écran et se changent sans refabriquer un seul audio, ce qui permet d'essayer l'un, de comparer dans les statistiques les écoutes complètes et les écoutes d'extrait, puis de trancher sur des chiffres.
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