Intégrer l'audio de vos articles dans une application mobile

Beaucoup d'éditeurs ont un site et, en plus, une application mobile. Le site a déjà sa version audio, et la question tombe vite : comment retrouver la même écoute dans l'appli, sans réécrire une couche audio maison ? La réponse honnête est qu'il n'y a pas de bouton unique, mais deux chemins bien identifiés, et le choix entre les deux ne se joue pas sur la difficulté technique. Il se joue sur ce que vos lecteurs attendent d'une écoute mobile.

Il n'existe pas de SDK mobile dédié, et c'est assumé

Commençons par ce qu'on ne fait pas. WeDispatch n'expose pas de bibliothèque native iOS ou Android à glisser dans votre projet. Ce serait une surface de plus à maintenir, à faire vieillir au rythme des versions d'OS, pour un gain discutable : tout ce dont une appli a besoin, un player web embarqué ou un simple fichier audio le fournit déjà. Plutôt qu'un SDK fragile, nous avons donc deux briques stables et documentées. C'est le même parti pris que pour les sites : on décrit précisément ce que fait chaque brique, on ne vend pas une boîte noire.

Chemin 1 : la WebView, pour retrouver le player tel quel

Une application mobile peut afficher une page web dans une WebView, ce composant qui embarque un navigateur à l'intérieur de l'écran. Si vos articles s'affichent déjà en WebView dans l'appli (c'est très courant pour les contenus éditoriaux), le player audio y apparaît exactement comme sur le site, sans travail supplémentaire. Le code d'intégration que vous utilisez sur le web fonctionne à l'identique.

C'est le chemin le plus rapide, et souvent le bon pour commencer. Sa limite est précise et il faut la connaître : une WebView est soumise aux règles du navigateur embarqué. Selon la plateforme et sa configuration, la lecture peut s'interrompre quand l'utilisateur quitte l'article ou verrouille son téléphone, et les commandes de l'écran verrouillé (lecture, pause, avance) ne sont pas garanties. Pour une écoute rapide, sur un article ouvert, c'est sans conséquence. Pour une écoute longue, pendant un trajet, c'est le point qui fera la différence.

Chemin 2 : l'API, pour lire le fichier nativement

Le second chemin sépare la génération de la lecture. Votre appli demande l'audio d'un article via l'API et l'intégration CMS, récupère l'adresse du fichier généré, puis le confie au lecteur audio natif du système (AVPlayer sur iOS, le lecteur média d'Android). À partir de là, l'audio n'est plus une page web : c'est un média que le système d'exploitation connaît et gère comme n'importe quel podcast.

Cela change tout sur l'expérience : la lecture continue quand l'utilisateur revient à la liste des articles ou verrouille l'écran, les commandes apparaissent sur l'écran de verrouillage et dans le centre de contrôle, et le fichier peut être mis en cache pour une écoute hors ligne. C'est plus de travail côté appli, puisqu'il faut brancher le lecteur natif et gérer la file de lecture, mais c'est le seul chemin qui offre une vraie écoute d'arrière-plan.

La question qui tranche : l'arrière-plan

Tout se ramène à une seule décision. Si vos lecteurs écoutent un article en le gardant à l'écran, quelques minutes, la WebView suffit et vous êtes en production dès aujourd'hui. Si vos lecteurs écoutent en faisant autre chose, téléphone en poche, écran éteint, il faut passer par l'API et le lecteur natif, sans exception. Aucun réglage de WebView ne rend l'écoute d'arrière-plan aussi fiable qu'un vrai lecteur média système, parce que ce n'est pas la même couche logicielle.

C'est aussi ce qui distingue une simple lecture d'un usage réellement mobile, celui que nous décrivons dans notre article sur l'écoute audio hors ligne : dès qu'on sort du cadre « page ouverte, écran allumé », c'est le fichier qui compte, pas la page.

React Native, Flutter et les applis hybrides

Les deux chemins valent quel que soit le cadre de développement. Une application en React Native ou en Flutter peut afficher une WebView (chemin 1) ou appeler l'API et confier le fichier à un module de lecture audio natif de son écosystème (chemin 2). La logique ne change pas : c'est toujours l'arbitrage entre l'écoute rapide en page et l'écoute longue en arrière-plan qui commande le choix, pas la technologie de l'appli.

Un point de vigilance commun aux deux mondes : ne montez le player, en WebView comme en natif, qu'après la vérification d'accès si vos contenus sont réservés aux abonnés. Le même principe vaut sur le web, et il évite d'exposer l'audio d'un article payant à un utilisateur non connecté.

Par où commencer

Le plus sage est de valider l'usage avant d'investir. Activez la version audio sur vos articles, laissez-la vivre en WebView dans l'appli pendant deux ou trois semaines, et regardez qui écoute et combien de temps. Si l'écoute est courte et en page, vous avez fini. Si les durées d'écoute grimpent et que les retours parlent d'écoute en déplacement, vous saurez que l'investissement dans le lecteur natif est justifié, chiffres à l'appui. C'est la même démarche progressive que pour un site statique ou généré : commencer simple, mesurer, puis automatiser ce qui le mérite.

Pour les détails du lecteur audio et de son comportement, ou pour brancher l'API dans votre pipeline de publication, la documentation donne le niveau de précision dont a besoin une équipe technique.

Testez avant de coder une ligne

Vous n'avez pas besoin de votre appli pour savoir ce que donnera l'audio : faites le test sur vos articles depuis le web, écoutez le rendu, puis décidez du chemin mobile en connaissance de cause.

À 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
• Un lecteur audio dans la page ou dans une iframe : ce que ce choix décide