Intégrer l'audio à un site Jekyll
Jekyll construit vos pages au build et les sert en fichiers plats, souvent sur GitHub Pages où les plugins sont bridés. Voici les deux chemins propres pour y ajouter une version audio de vos articles, l'extrait Liquid exact du lecteur, et le piège à éviter.
Jekyll a une logique simple et solide : il lit vos fichiers Markdown, applique vos gabarits Liquid au moment du build, et produit un dossier de pages HTML servies comme de simples fichiers. Pas de base de données, pas de serveur applicatif qui tourne à chaque visite. C'est ce qui rend un site Jekyll rapide et durable, et c'est aussi ce qui pose une vraie question dès qu'on veut ajouter une version audio des articles : où générer l'audio, et où le brancher, quand rien ne tourne côté serveur au moment où le visiteur clique ?
Ce guide traite le cas de Jekyll en particulier. Pour la vue d'ensemble des générateurs statiques (Next.js, Hugo, Astro), l'article ajouter l'écoute audio à un site statique pose le cadre commun ; ici, on descend dans les détails propres à Jekyll.
La contrainte qui décide de tout : GitHub Pages
Beaucoup de sites Jekyll sont hébergés sur GitHub Pages, et GitHub Pages ne construit votre site qu'avec une liste fermée de plugins approuvés. Vous ne pouvez pas y ajouter un plugin maison qui appellerait une API de synthèse pendant le build. Cette seule contrainte écarte l'approche « je génère l'audio dans le build Jekyll lui-même » pour la majorité des sites, et elle oriente vers deux chemins qui ne dépendent pas du build hébergé.
Si vous construisez votre site vous-même (build local, ou une action d'intégration continue qui publie le résultat), la contrainte tombe et le troisième chemin, celui du build, redevient possible. Sachez seulement lequel des deux cas est le vôtre avant de choisir.
Chemin 1 : le flux RSS, aucun code à écrire
Jekyll produit un flux RSS complet dès que le plugin jekyll-feed est actif, et ce plugin fait partie de la liste autorisée par GitHub Pages. Vous avez donc, sans rien coder, un flux qui annonce chaque nouvel article. Il suffit de le donner à WeDispatch : le service surveille le flux, détecte les articles publiés, génère l'audio correspondant une fois, et vous récupérez le lecteur à insérer. Aucune modification de votre chaîne de build, aucune clé exposée. Le fonctionnement du flux comme déclencheur est détaillé sur la page flux RSS. C'est le chemin recommandé pour un site Jekyll sur GitHub Pages, précisément parce qu'il ne touche pas à ce que GitHub verrouille.
Chemin 2 : l'appel d'API à la publication
Si vous voulez décider vous-même du moment exact où l'audio est produit, un appel d'API explicite dans votre script de publication (ou dans votre workflow d'intégration continue, avant le déploiement) génère l'audio et vous rend l'URL du fichier. Vous stockez cette URL dans le front matter de l'article, une variable comme audio_url, et votre gabarit l'utilise. La page API et CMS décrit cette voie. Elle demande un peu de travail initial et un endroit où exécuter le script hors de GitHub Pages, mais elle vous laisse un contrôle total.
L'extrait Liquid du lecteur
Quel que soit le chemin, le lecteur s'insère dans votre gabarit d'article. Créez un fichier _includes/lecteur-audio.html qui contient le code du lecteur fourni, puis appelez-le dans votre _layouts/post.html, juste après le titre :
{% if page.audio_url %}{% include lecteur-audio.html src=page.audio_url %}{% endif %}
Le test if page.audio_url est le point important : un article sans audio n'affiche aucun lecteur, et le jour où l'URL est renseignée, le lecteur apparaît sans autre changement. C'est le comportement à viser, et il se vérifie en deux minutes sur un article de brouillon.
Le piège à éviter : générer dans le navigateur
La tentation, sur un site sans serveur, est d'appeler une API de synthèse au moment où le visiteur clique sur lecture. À proscrire. Vous exposeriez vos clés dans le HTML public, vous paieriez une génération à chaque écoute au lieu d'une seule, et vous ajouteriez une latence à chaque lecture. Le modèle sain est le même que pour vos images : produire une fois à la publication, servir un fichier ensuite, mis en cache par le CDN. L'audio devient un asset comme un autre, et il épouse la philosophie de fichiers plats qui vous a fait choisir Jekyll. C'est d'ailleurs sur cette même logique, sans base de données, que repose le text to speech français tel qu'on le conçoit : le travail se fait une fois, en amont, pas à chaque visite.
Essayez sur vos propres articles
La formule gratuite de WeDispatch vous laisse sonoriser vos contenus dès aujourd'hui, avec vos vrais textes : essayez maintenant. Les forfaits 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