Intégrer l'audio sans iframe ni script tiers : le bloc composé par votre serveur, contrat à l'appui

Certaines rédactions n'assemblent pas leurs pages dans le navigateur. Leur plateforme les compose côté serveur, à partir de blocs fournis par des services externes, et chaque fournisseur doit respecter un contrat écrit, validé par l'équipe plateforme avant toute mise en ligne. Dans ce modèle, l'iframe est généralement interdite par règle : elle échappe au référencement, à la régie et à l'orchestration des scripts. Un lecteur audio livré en iframe y est donc inéligible, quelle que soit sa qualité.

Pour ces plateformes, nous fournissons un bloc. Voici ce que son contrat contient vraiment, pour que votre équipe technique juge sur pièce.

Ce que vous lisez d'abord : un contrat public

Le contrat se lit à une adresse publique, /api/blocs/contrat, sans clé. C'est voulu : un contrat est une description, pas une donnée client, et votre outil de validation doit pouvoir le vérifier sans nous. La réponse est mise en cache cinq minutes côté navigateur et une heure côté réseau, puisqu'elle ne change jamais sans changer de version.

Il déclare deux blocs, de type « Display » (ils montrent un contenu, ils ne mènent pas ailleurs) :

• le lecteur, à poser dans le gabarit d'article à l'endroit choisi ;
• le texte synchronisé, qui porte le surlignage mot à mot, à poser dans le corps de l'article.

Les deux lisent la même adresse de données. Ils ne se parlent pas : le script du lecteur cherche les conteneurs du texte dans la page. Si vous ne posez que le premier, il fonctionne seul.

Les paramètres : votre identifiant, pas le nôtre

L'adresse de données accepte deux manières de désigner un article :

• article, notre identifiant au format UUID ;
• ou externe accompagné de site : votre propre identifiant d'article, celui que vous avez envoyé à la génération, et l'identifiant du compte.

La seconde est celle qu'on emploie en pratique : votre gabarit connaît déjà l'identifiant de l'article qu'il compose, il n'a rien à stocker de plus. Si aucun paramètre n'est utilisable, la réponse n'est pas une erreur mais un bloc vide et valide. Votre gabarit ne rend alors rien, et votre journal n'enregistre pas notre incident sur une page qui n'a rien demandé.

Le gabarit et les feuilles de style : les vôtres

Les gabarits sont déclarés en Mustache, au format HTML, en position « placeholder ». Le balisage s'appuie sur les composants de votre propre système de design : le lecteur ressemble à votre site parce qu'il est construit avec vos classes.

C'est le point sur lequel nous avons été le plus stricts. Le bloc lecteur ne déclare aucune feuille de style. Le bloc texte en déclare une seule, courte, dont toutes les règles sont préfixées et aucune couleur n'est écrite en dur : votre système de design ne prévoit pas le surlignage du mot en cours de lecture, et c'est la seule chose qu'elle ajoute. Aucune police n'est déclarée.

Côté script, un seul fichier. Votre plateforme le concatène avec les autres et l'entoure d'une fonction anonyme : aucune variable globale ne survit, et le script démarre seul en lisant le DOM. Il est versionné avec le contrat.

La version est immuable

Le contrat porte une version (aujourd'hui 1.1.1). Toute modification d'un gabarit, du script ou d'un paramètre impose une nouvelle version, que votre équipe valide à nouveau. Nous ne corrigeons pas un bloc discrètement en production. C'est une contrainte dans notre rythme de livraison, et c'est la contrepartie de l'indépendance que ces plateformes recherchent : ce que vous avez validé est ce qui tourne.

Le budget de rendu : cent cinquante millisecondes

Les plateformes de composition n'attendent pas un bloc lent : au-delà du budget, il n'est simplement pas rendu, sans erreur ni message. Ce que nous avons mesuré, et ce que nous en avons fait :

• une première version, sur une fonction serveur classique, rendait 645 ms à froid. La cause n'était pas la base mais le chargement d'une bibliothèque ; la route interroge désormais la base par simple requête HTTP, en une seule lecture qui ramène l'article, sa version audio et le réglage du compte ;
• passée à 145 ms à froid, elle restait dans le budget avec cinq millisecondes de marge, ce qui n'en est pas une. Elle tourne donc au bord du réseau, épinglée à Paris puis Dublin, à côté de la base : un premier essai sans épinglage avait rendu 455 ms depuis Washington ;
• la réponse est servie par le cache du réseau, fraîche deux minutes, puis encore cinq minutes pendant qu'elle se rafraîchit en arrière-plan. Après le tout premier appel sur un article, le budget est tenu quoi qu'il arrive ;
• l'en-tête Last-Modified est fourni et un 304 est rendu quand vous avez déjà la bonne version ;
• l'en-tête Server-Timing sépare le travail de la réponse du démarrage de l'instance, pour que votre exploitation sache laquelle des deux causes ralentit.

Conséquence pratique pour une rédaction : une correction de prononciation est entendue sur la page en deux à sept minutes, jamais en heures. C'est le même souci que pour un article corrigé après publication.

Les deux cas que le bloc refuse

Le contenu réservé aux abonnés. Le bloc est appelé par votre serveur, sans jeton de visiteur : il ne peut pas savoir qui lira la page. Il sert donc exactement ce qu'un visiteur anonyme recevrait : l'audio complet si le compte est en accès libre, l'extrait sinon. Si vous réservez l'audio à vos abonnés, c'est le chemin par l'API depuis votre CMS qu'il faut prendre, où votre serveur atteste du droit de chaque visiteur.

Le compte sous embargo. Un compte qui protège tous ses fichiers par adresse signée n'est pas servi du tout : remettre une adresse signée à un serveur tiers, sans savoir pour qui, serait une porte dérobée sur le compte qui en veut le moins. Le bloc rend vide plutôt qu'une demi-mesure.

Est-ce le bon chemin pour vous ?

Probablement pas si votre site tourne sous un CMS courant : le composant inséré dans la page évite déjà l'iframe sans travail technique, et la page WordPress décrit ce chemin. Pas non plus si vous voulez votre propre lecteur sans contrainte de plateforme : c'est le rôle de la boîte à outils de rendu. La comparaison des voies est faite dans lecteur dans la page ou dans une iframe.

Le bloc vise un cas précis : une plateforme qui compose ses pages côté serveur, une règle écrite contre l'iframe et les scripts tiers, un système de design maison. Dans ce cas, le travail se compte en heures : déclarer le bloc, le poser dans un gabarit. La fiche bloc de composition serveur résume le tout ; le contrat, lui, se lit directement, et c'est par lui qu'il vaut mieux commencer.

À 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