Un lecteur audio dans la page ou dans une iframe : ce que ce choix décide

Quand on ajoute un composant tiers à un site, un lecteur audio par exemple, la voie la plus rapide est souvent l'iframe : un cadre isolé, chargé depuis le domaine du fournisseur, qu'on colle dans la page. Deux minutes, et le lecteur apparaît. Le problème n'est pas qu'elle soit mauvaise, c'est qu'elle décide en silence de trois choses qui comptent pour un éditeur, et qu'on ne mesure ces choses que plus tard. Cet article regarde ce que change, concrètement, un lecteur rendu dans la page par rapport à un lecteur enfermé dans une iframe.

Ce qu'est une iframe, et pourquoi c'est commode

Une iframe est une page dans la page : un document autonome, servi depuis un autre domaine que le vôtre, affiché dans un cadre. Pour un fournisseur, c'est l'intégration idéale : il maîtrise tout ce qui s'affiche, il n'a aucune dépendance à votre code, et une seule ligne suffit à poser le cadre. Pour vous, la pose est effectivement rapide. C'est ce qui explique que tant de widgets, de lecteurs et de modules passent par là. Le coût n'apparaît pas à la pose : il apparaît à l'usage.

Premier coût : l'indexation

Un moteur de recherche traite une iframe comme ce qu'elle est, une autre page. Le contenu qu'elle affiche n'appartient pas à votre page : il appartient au document du fournisseur. Si votre lecteur audio embarque une transcription, des chapitres, un texte synchronisé, tout cela vit dans l'iframe, donc hors de votre page aux yeux du moteur. Vous avez du texte riche, cherchable, pertinent, et il ne compte pas pour votre référencement parce qu'il n'est pas chez vous. Un lecteur rendu dans la page fait l'inverse : son balisage est votre balisage, et ce qu'il contient est indexé avec le reste de l'article. C'est le même raisonnement que pour le balisage schema.org d'un contenu audio : ce qui est déclaré dans votre page travaille pour vous, ce qui est délégué ailleurs ne travaille pour personne.

Deuxième coût : la vitesse

Une iframe charge une page entière, avec son propre code, ses propres feuilles de style, ses propres appels réseau, en parallèle de la vôtre. Sur une connexion confortable, la différence se remarque peu ; sur mobile, sur un réseau lent, elle se paie en secondes d'affichage et en indicateurs de performance dégradés. Un lecteur rendu dans la page ne charge pas une seconde page : son rendu s'appuie sur ce que votre site sert déjà. Nous avons détaillé ailleurs le rapport entre le lecteur audio et la vitesse de chargement ; le point essentiel tient ici en une phrase : un cadre isolé chargé d'ailleurs est une page de plus à télécharger, un composant intégré ne l'est pas.

Troisième coût : la propriété de l'audience

C'est le moins visible et le plus lourd. Dans une iframe, les écoutes, les clics, le comportement de l'auditeur se passent dans le document du fournisseur. Vos propres outils de mesure, votre régie, votre orchestration ne voient rien de ce qui se joue dans le cadre, parce que le navigateur isole justement l'iframe du reste de la page. Vous hébergez le lecteur, mais vous ne possédez pas ce qu'il produit. Un lecteur dans la page reste sous votre toit : la mesure d'écoute remonte dans vos rubriques, l'auditeur reste votre auditeur, et rien n'est cloisonné derrière une frontière que vous ne contrôlez pas.

Deux façons de rester dans la page

Il y a deux manières d'obtenir un lecteur dans la page, selon votre plateforme. La première est un composant qui s'insère par une ligne de script, servie une fois, et qui rend le lecteur là où vous l'appelez : c'est le chemin de la plupart des sites, y compris sous WordPress, et il évite l'iframe sans demander d'effort technique. La page pilier WordPress décrit ce chemin pour ce cas précis. La seconde vise les grandes rédactions dont la plateforme compose ses pages côté serveur et dont les règles internes interdisent tout script tiers. Pour elles, le bloc de composition serveur fournit non pas un cadre, mais un contrat : un gabarit, des paramètres, une politique de cache, que votre moteur lit et rend lui-même. Aucune iframe, aucun script chargé depuis notre domaine à l'exécution, et le lecteur emprunte vos propres classes et vos propres couleurs. Le lecteur ressemble à votre site parce que c'est le vôtre.

Il faut être honnête sur la limite de cette seconde voie : parce que le bloc est appelé par votre serveur, sans jeton du visiteur, il ne peut pas connaître les droits de la personne qui lit la page. Un contenu réservé aux abonnés ne passe donc pas par lui, mais par l'API, où votre serveur atteste du statut de chaque visiteur. Une iframe ne résout pas mieux ce problème ; elle le déplace simplement là où vous ne le voyez plus.

Ce qu'il faut en retenir

L'iframe n'est pas un mauvais outil, c'est un outil qui optimise le confort du fournisseur, pas le vôtre. Elle pose vite et coûte lentement : un texte qui n'est pas indexé chez vous, une page de plus à charger, une audience qui se joue derrière une cloison. Un lecteur rendu dans la page renverse chacun de ces trois points, au prix d'une intégration à peine plus exigeante. Avant d'accepter un composant audio, la bonne question n'est pas « en combien de temps se pose-t-il », mais « ce qu'il affiche et ce qu'il mesure, est-ce chez moi ». C'est ce principe qui guide notre travail sur l'intégration, et la page text to speech français en expose la logique d'ensemble.

À lire aussi

• Notes de bas de page et appels de note : ce que la synthèse vocale en fait
• Légendes et crédits de photos : ce que la synthèse vocale en fait
• WCAG 2.2 et version audio : ce que le standard exige, et ce qu'il n'exige pas