Dépublier un article : que devient sa version audio ?

Une rédaction retire un article plus souvent qu'on ne le croit. Une erreur de fait qu'on préfère dépublier plutôt que corriger, une personne citée qui demande à ne plus apparaître, un courrier d'avocat, un contenu partenaire dont le contrat a pris fin. Dans le CMS, le geste prend une seconde : on repasse l'article en brouillon, ou on l'envoie à la corbeille. La page disparaît. La question que presque personne ne se pose à ce moment-là : et la version audio ?

Elle vit ailleurs. Le fichier est hébergé par le service qui l'a fabriqué, il a sa propre adresse, il figure peut-être dans un flux de podcast. Si rien ne prévient ce service, l'article dépublié continue d'être lu à voix haute à qui connaît le chemin. C'est précisément le cas où la dépublication était le but.

Le défaut que nous avions, et pourquoi il est courant

Nous l'avons constaté chez nous, en relisant le module WordPress le 1er octobre 2026 : un article repassé en brouillon, rendu privé, mis à la corbeille ou supprimé gardait son audio. Il restait écoutable par son adresse directe, présent dans le flux du podcast, et proposé dans les suggestions « à écouter ensuite » d'autres sites du même compte. L'API savait pourtant retirer un audio depuis le mois d'août ; simplement, rien ne l'appelait au bon moment.

Ce défaut n'a rien d'exotique. Un service de mise en audio reçoit les articles quand ils paraissent, parce que c'est là qu'on lui demande de travailler. Il n'est presque jamais branché sur l'événement inverse. Si vous évaluez un outil, c'est une question à poser telle quelle, au même titre que celles de notre questionnaire de sécurité : « que se passe-t-il quand je dépublie ? »

Ce que fait le module WordPress, aujourd'hui

Le module écoute deux choses dans WordPress. La première est le changement de statut : dès qu'un article publié (ou programmé) passe en brouillon, en attente de relecture, en privé, à la corbeille, ou reste publié mais derrière un mot de passe, il planifie le retrait de son audio. La seconde est la suppression définitive sans passage par la corbeille, celle que font une corbeille désactivée, une commande en ligne ou une autre extension : aucun changement de statut n'est annoncé dans ce cas, et seul le crochet de suppression le voit. Les deux chemins sont couverts.

Le retrait ne se fait pas pendant que vous cliquez sur « Mettre à jour ». Un appel réseau à cet endroit retiendrait l'enregistrement de l'article. Il part dans une tâche de fond, quelques instants après, avec les identifiants d'audio emportés dans la tâche : après une suppression définitive, WordPress a déjà effacé les informations de l'article au moment où la tâche s'exécute, il fallait donc les garder avec elle.

Deux cas particuliers sont traités. Si vous republiez l'article avant que la tâche passe, elle constate qu'il est de nouveau public et ne retire rien. Si une fabrication est en cours au moment du retrait, le service refuse poliment (il ne supprime pas un audio sous les pieds de celui qui le fabrique) et le module réessaie plus tard, avec un délai croissant. Tant que le retrait n'a pas abouti, l'écran Contenus du module continue d'afficher l'audio : il ne prétend pas qu'il a disparu.

Le guide de la page WordPress décrit l'installation ; ce comportement est actif dès que le module est relié à votre compte, sans réglage à cocher.

Ce que le retrait efface, et ce qu'il garde

Côté service, le retrait efface l'audio complet, l'extrait, le fichier des horodatages mot à mot et le résumé parlé s'il existait, pour toutes les versions de l'article, et dans les deux espaces de stockage (public et protégé). Ce dernier point n'est pas un détail : un compte peut avoir changé de mode d'accès entre deux fabrications, et ses anciens fichiers être restés de l'autre côté. Les fichiers partent avant les lignes de la base. Dans l'ordre inverse, un échec de stockage aurait laissé des fichiers toujours servis avec une base affirmant qu'il n'y a plus rien, la pire combinaison parce qu'elle est silencieuse.

Sans versions, l'article disparaît aussi du flux du podcast, qui ne liste que les épisodes ayant une version servie.

Le retrait garde trois choses, et le dit dans sa réponse : la fiche de l'article, son historique d'écoutes et son texte. Les statistiques passées vous appartiennent et ne s'effacent pas parce qu'un billet est parti à la corbeille ; le texte permet de refaire l'audio si l'article revient ; et la fiche fait le lien entre l'identifiant de votre CMS et ce qui a été consommé, ce qui répond aux questions de facturation.

Il ne rend pas de crédit. La synthèse a eu lieu, elle a été payée. Nous préférons l'écrire ici que de laisser quelqu'un supprimer un audio en espérant récupérer son quota.

Sans WordPress : l'API

Sur un CMS maison, un site statique ou un outil headless, rien ne surveille vos statuts à votre place. Le retrait existe sous la forme d'un appel d'API, DELETE /api/v1/podcasts/{article_id}, qui fait exactement ce qui est décrit plus haut et renvoie ce qu'il a gardé. C'est à votre intégration de l'appeler au moment où l'article quitte la publication. La page API pour CMS décrit le reste des appels. L'espace client, lui, n'a pas aujourd'hui de bouton « retirer l'audio » : c'est l'API ou le module.

Corriger n'est pas retirer

Une demande d'anonymisation se traite souvent en corrigeant l'article plutôt qu'en le retirant : on remplace un nom par une initiale, on enlève une précision. Dans ce cas, l'audio se refait sur le nouveau texte, et la nouvelle version remplace l'ancienne dans le lecteur et dans le flux, comme pour toute correction d'un article déjà publié.

Mais remplacer n'est pas effacer. Les versions précédentes restent dans l'historique de l'article ; elles ne sont plus servies, et leur adresse n'est publiée nulle part. Si l'enjeu est juridique et que le nom ne doit plus exister nulle part, la démarche sûre est en deux temps : retirer l'audio (ce qui efface toutes les versions), puis le refaire sur le texte corrigé.

Ce qu'aucun outil ne rappelle

Soyons nets sur la limite. Un retrait côté service supprime ce que le service héberge. Il ne rappelle pas les copies déjà parties :

• les épisodes qu'une application de podcast a téléchargés sur le téléphone d'un abonné, qu'elle garde jusqu'à ce que l'abonné les efface ou qu'elle relise le flux à son rythme ;
• un fichier qu'un auditeur a enregistré, ou qu'un navigateur a gardé en mémoire ;
• un extrait partagé sur un réseau social sous forme de vidéo, qui vit désormais chez ce réseau.

C'est la même limite que pour le texte, qu'une capture d'écran ou un cache de moteur de recherche peut prolonger. Elle n'enlève rien à l'intérêt d'un retrait rapide : plus il intervient tôt, moins il y a de copies.

En pratique

Si vous utilisez le module WordPress, dépublier suffit : le retrait suit. Vérifiez seulement que l'écran Contenus ne montre plus l'audio quelques minutes plus tard. Si vous passez par l'API, branchez l'appel de retrait sur votre événement de dépublication avant d'en avoir besoin, pas le jour où une mise en demeure arrive. Et si un article doit être réécrit pour des raisons juridiques, retirez puis refaites, plutôt que de compter sur une simple régénération.

À lire aussi

• « Citation, fin de citation » : faut-il annoncer une citation dans un article lu à voix haute ?
• Changer de volume audio en cours d'abonnement : ce qui arrive à vos crédits et à votre facture
• Une voix de synthèse pour un jeune public : ce qui marche, ce qui ne marche pas