Intégrer l'audio à un CMS headless (Strapi, Sanity, Contentful)
Quand le contenu vit dans un CMS headless et l'affichage dans un frontend séparé, où et quand sonoriser les articles ? Les schémas d'intégration réalistes, sans réécrire votre stack.
Les architectures headless se sont imposées chez beaucoup d'éditeurs : le contenu vit dans un CMS comme Strapi, Sanity ou Contentful, et l'affichage se fait dans un frontend séparé, souvent en Next.js, Nuxt ou Astro. Cette séparation apporte de la souplesse, mais elle pose une question précise dès qu'on veut ajouter une version audio des articles : à quel étage brancher la sonorisation, et à quel moment la déclencher ? Il n'y a pas une seule bonne réponse, mais quelques schémas clairs, chacun avec ses compromis.
Le problème propre au headless
Dans un site monolithique classique, contenu et rendu sont au même endroit, et l'audio se greffe au moment de l'affichage. En headless, la source de vérité (le CMS) et la couche de présentation (le frontend) sont distinctes. L'audio doit donc trouver sa place sans casser cette séparation, et surtout sans obliger la rédaction à sortir de son outil habituel pour produire un fichier son à la main. Le bon design est celui où le journaliste ne fait rien de plus qu'aujourd'hui.
Schéma 1 : sonoriser à la publication via webhook
C'est l'approche la plus propre. La plupart des CMS headless émettent un webhook à chaque publication ou mise à jour d'un article. Vous branchez ce webhook sur un traitement qui récupère le texte, en génère la version audio, et stocke le résultat (ou son URL) là où votre frontend saura le lire. L'audio est ainsi prêt au moment où l'article part en ligne, sans intervention humaine.
L'avantage est double : la production suit exactement le rythme éditorial, et rien ne change pour la rédaction. Le point d'attention est la gestion des mises à jour : si un article est corrigé après publication, le webhook doit redéclencher la sonorisation pour éviter un décalage entre le texte lu et le texte affiché. C'est la même logique que celle décrite pour les flux de publication dans intégrer l'audio à vos articles WordPress, API ou flux RSS, transposée au monde headless.
Schéma 2 : appel API à la demande, côté frontend
Une variante consiste à demander l'audio au moment où un lecteur ouvre l'article, via un appel API, puis à mettre le résultat en cache. On ne sonorise alors que les contenus réellement consultés, ce qui évite de traiter des articles que personne ne lira. C'est intéressant pour un très gros catalogue à longue traîne, où produire l'audio de tout serait du gaspillage.
Le compromis est la première écoute, légèrement retardée le temps de la génération, avant que le cache ne prenne le relais pour les visiteurs suivants. Pour un site à fort trafic sur peu d'articles, le schéma 1 reste plus confortable. Pour un catalogue immense à consultation dispersée, le schéma 2 est plus économe.
Schéma 3 : champ audio piloté depuis le CMS
Troisième voie, plus intégrée : exposer dans le modèle de contenu du CMS un champ dédié à l'audio, que la rédaction peut consulter et, au besoin, régénérer d'un clic. L'audio devient alors un attribut de l'article au même titre que son image de couverture, versionné et gouverné dans l'outil éditorial. Cette approche plaît aux rédactions qui veulent garder la main, par exemple pour revérifier la prononciation d'un nom propre sensible avant mise en ligne.
Elle demande un peu plus de travail de modélisation initial, mais offre le meilleur contrôle. Le pilotage fin, y compris par des agents automatisés, rejoint ce que nous avons décrit dans piloter la sonorisation par des agents IA et MCP.
Ce qu'il faut décider avant de coder
Trois questions tranchent le choix. Quel est le volume et sa distribution de trafic ? Un petit nombre d'articles très lus penche pour le schéma 1, une longue traîne pour le schéma 2. La rédaction veut-elle valider l'audio avant publication ? Si oui, le schéma 3 s'impose. Enfin, où stocker et servir les fichiers pour que le frontend les charge sans alourdir la page ? Ces réponses posées, l'intégration se résume à un branchement, pas à une refonte.
Dans tous les cas, la sonorisation elle-même reste externalisée : votre stack ne gère ni voix, ni synthèse, ni mise à jour des modèles. Le rôle de l'intégration est seulement de déclencher au bon moment et d'afficher au bon endroit. Le fonctionnement côté API et CMS est détaillé sur notre page API et CMS.
Testez l'intégration sur votre stack
La formule gratuite de WeDispatch vous permet d'essayer la sonorisation dès aujourd'hui, avec vos vrais contenus : essayez maintenant. Les forfaits, de 69 à 419 euros HT par mois, sont détaillés sur la page tarifs.
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