Sonoriser vos articles par API : le chemin pour un CMS maison ou headless
Vous n'êtes pas sous WordPress. Voici comment une API REST transforme un article en audio par une requête : envoi du texte, réponse synchrone ou webhook, lecteur en une ligne. Le parcours réel, sans magie.
Les guides d'intégration supposent presque toujours un CMS du commerce : WordPress, Drupal, un thème à ne pas casser. Mais beaucoup d'éditeurs tournent sur autre chose : un CMS maison, un back-office headless, le framework du groupe. Pour eux, un plugin fermé n'est pas la bonne brique. Ce qu'il leur faut, c'est une API claire, prévisible, qui prenne un article et rende un audio, sans imposer de dépendance côté rédaction. C'est exactement ce que fait l'API pour tout CMS, et cet article décrit le parcours réel, étape par étape, sans rien enjoliver.
Le geste de base : une requête, une réponse
Le point d'entrée est une seule route : un POST /api/v1/podcasts avec le texte de l'article, son titre, et un identifiant à vous (external_id), celui que porte déjà l'article dans votre base. L'authentification passe par une clé API en en-tête (Bearer), comme n'importe quelle API REST moderne. Pas de compte à créer côté serveur, pas de SDK propriétaire à installer : un appel HTTP suffit, quel que soit votre langage.
Ce choix a une conséquence pratique agréable : vous testez l'intégration depuis un terminal avant d'écrire la moindre ligne dans votre CMS. Un curl avec un paragraphe, une clé, et vous voyez revenir la réponse. C'est le genre de vérification qu'on recommande toujours de faire d'abord, parce qu'elle sépare nettement « l'API répond » de « mon template affiche bien ».
Synchrone ou asynchrone : deux rythmes, deux besoins
L'API expose deux modes, et le bon dépend de votre chaîne de publication.
En mode synchrone, vous ajoutez wait: true à la requête : la réponse n'arrive qu'avec l'audio prêt, en général en cinq à quinze secondes pour un article. C'est le mode des rédactions qui veulent publier l'article et son audio d'un seul tenant : au moment où l'auteur clique sur « publier », l'audio existe déjà et part avec le reste. Le coût est une requête qui tient la connexion le temps de la fabrication, ce qui convient parfaitement à un article unitaire.
En mode asynchrone, vous ne bloquez rien : l'API répond immédiatement, la fabrication se fait derrière, et un webhook signé vous prévient quand l'audio est prêt. Chaque appel de webhook porte un horodatage et une signature HMAC-SHA256 calculée avec votre secret : vous la recalculez de votre côté et vous comparez avant d'accepter, ce qui garantit que l'appel vient bien de nous et pas d'un tiers. C'est le mode des files d'attente et des gros volumes, où l'on préfère traiter les notifications à son propre rythme. Si vous découvrez les flux et les webhooks, le flux RSS est une autre porte d'entrée, plus simple, pour publier vos articles en podcast automatique sans écrire de code.
Les archives : jusqu'à 25 articles par requête
Un site qui existe depuis des années n'a pas qu'un article à sonoriser, il en a des centaines. L'API accepte un envoi par lot, jusqu'à 25 articles par requête, aux mêmes règles que l'unitaire. Vous rattrapez un fonds existant sans marteler l'API d'un appel par article, et vous gardez le contrôle du débit. Pour une estimation de durée et de coût sur un fonds important, le calcul complet est détaillé dans combien de temps pour sonoriser un blog existant.
Afficher le lecteur : une ligne dans votre template
Une fois l'audio fabriqué, il faut l'entendre. Le lecteur s'insère avec une seule ligne (player.js) portant l'identifiant de l'article, à l'endroit de votre template où vous le voulez, en général avant le premier paragraphe. Il apporte les chapitres, le lien horodaté à la seconde et le thème automatique qui s'aligne sur les couleurs de votre page, sans que vous ayez à styler quoi que ce soit. Vous ne touchez pas au rendu de votre article : vous ajoutez un composant, et rien d'autre de votre gabarit ne bouge.
Les mises à jour : le piège de la double facturation, évité
La question qui vient toujours en production : que se passe-t-il quand un article corrigé repart ? Vous renvoyez le même external_id. L'audio en place continue d'être servi, et l'article passe en état « périmé » (stale) : vous savez qu'il a changé, mais rien ne se régénère tout seul. Vous déclenchez la nouvelle version quand le texte est stabilisé, pas à chaque virgule corrigée. C'est un choix délibéré : la synthèse vocale se paie au caractère, et une régénération accidentelle à chaque sauvegarde coûterait cher pour rien. L'API est pensée pour la production, avec idempotence et déduplication, précisément pour que ce genre d'accident n'arrive pas.
Ce que l'API ne fait pas à votre place
Soyons honnêtes sur les limites. L'API vous rend un audio et un lecteur : elle ne décide pas pour vous où placer le lecteur dans votre gabarit, ni quand déclencher une régénération, ni comment gérer votre file d'attente en asynchrone. Ce sont des décisions d'intégration qui restent chez vous, et c'est voulu : une brique propre se branche, elle ne s'impose pas. Si votre besoin est au contraire de ne rien coder, ce n'est pas le bon chemin, et l'intégration par flux ou par extension sera plus directe, comme décrit dans intégrer l'audio par API ou par flux RSS sous WordPress.
La qualité de lecture, elle, ne dépend pas du mode d'intégration : que vous passiez par l'API, par un flux ou par une extension, c'est la même normalisation du français qui s'applique en amont, celle qu'on défend sur la page text to speech français. L'API change la façon dont l'audio entre dans votre site, pas ce qui sort du haut-parleur. Et pour un CMS headless précis, le cas Strapi, Sanity ou Contentful est traité à part dans intégrer l'audio à un CMS headless.
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