Service audio en panne : ce que voit le visiteur de votre site, et ce qui reprend tout seul

Tout service en ligne finit par tomber un jour, au moins un peu. Le nôtre aussi. La question utile, pour un responsable de site ou de rédaction, n'est donc pas « est-ce que ça peut arriver », mais : si ça arrive un mardi à 7 heures, qu'est-ce que mes lecteurs voient sur la page de l'article, et qu'est-ce que je dois faire ?

C'est une question qu'on pose rarement avant de signer, et qu'il vaut mieux poser. Elle figure d'ailleurs dans tout questionnaire de sécurité sérieux. Voici notre réponse, lue dans le code du lecteur et de la fabrication, sans promesse de disponibilité que nous ne mesurons pas.

Une panne n'est pas une panne : il y a plusieurs briques

Un service de mise en audio n'est pas un bloc. Il y a le site et son API, la base de données, le stockage des fichiers audio, la préparation du texte, la génération de la voix, la facturation, et le traitement automatique qui relève vos flux. Chacune peut tomber sans les autres, et les conséquences n'ont rien à voir.

Si la génération audio est en panne, les audios déjà fabriqués continuent d'être servis normalement : seuls les nouveaux articles attendent. Si c'est le stockage des fichiers qui tombe, c'est l'inverse : la fabrication pourrait tourner, mais l'écoute des audios existants est touchée. Si c'est la facturation, vos lecteurs ne voient rien du tout.

C'est pour cela que notre page de statut ne montre pas un voyant unique mais une ligne par brique. Chaque brique y reçoit un appel réel, et non une vérification que sa configuration existe : une clé révoquée ou un quota épuisé passeraient ce second contrôle sans difficulté, et la page resterait verte pendant toute la panne. Le résultat est mémorisé une minute, pour qu'une page consultée par tout le monde pendant un incident n'aggrave pas l'incident.

Ce que voit le visiteur quand le lecteur ne reçoit rien

Le lecteur se pose sur votre page par un petit script chargé en différé (defer). Il ne bloque donc pas l'affichage de l'article : si notre serveur ne répond pas, votre texte s'affiche exactement comme d'habitude. Ce point est développé dans l'article sur le poids du lecteur et la vitesse de chargement.

Ensuite, deux cas, selon la façon dont le lecteur a été installé.

En mode automatique par adresse (un seul script posé sur le gabarit d'article, qui retrouve l'audio de la page tout seul), le script demande d'abord à notre API s'il existe un audio pour cette adresse. Si la réponse ne vient pas, ou vient en erreur, rien n'est inséré. Pas de cadre vide, pas de bouton mort, pas de message d'erreur au milieu de votre article : la page ressemble à une page sans audio. C'est un choix délibéré, écrit en toutes lettres dans le code du script.

En mode par article (le script porte l'identifiant de l'audio), la place est réservée dès le premier affichage, avec une esquisse animée aux dimensions du lecteur, pour que la page ne sursaute pas à son arrivée. Si le lecteur n'annonce jamais sa hauteur (réseau coupé, origine bloquée, serveur muet), l'esquisse s'efface au bout de cinq secondes au lieu de clignoter indéfiniment. Le visiteur voit alors ce que le navigateur a pu charger, sans animation qui fait croire à un chargement en cours.

Dans les deux cas, ce que nous voulions éviter est le pire scénario pour un éditeur : un composant tiers qui casse la mise en page de l'article ou qui le retient.

Les audios déjà fabriqués

Un audio terminé est un fichier MP3 servi avec une durée de cache d'un an. Concrètement, un visiteur qui l'a déjà écouté, ou un relais réseau qui l'a déjà servi, peut le relire sans revenir chez nous. Ce n'est pas une garantie d'écoute pendant une panne du stockage, et nous ne le présentons pas comme tel : c'est ce qui limite l'effet d'une panne courte sur les articles les plus lus.

Si vous voulez ne dépendre de personne pour la diffusion, la voie existe : récupérer les fichiers et les servir vous-même, avec votre propre lecteur. Vous perdez alors ce que notre lecteur apporte (statistiques, chapitres, couleurs du site), et c'est un arbitrage à faire en connaissance de cause.

Les articles publiés pendant la panne

C'est là que le comportement compte le plus, parce que c'est là qu'on perd des audios sans le savoir.

Une fabrication qui échoue n'est pas abandonnée au premier essai. Le travail repasse en attente et il est repris, jusqu'à trois tentatives pour une erreur ordinaire. Une réponse « trop de demandes » du moteur de voix, elle, n'est pas comptée comme un échec : le travail attend, sans consommer de tentative, et repart quand le moteur répond de nouveau, dans une limite de vingt reprises pour qu'un quota qui ne revient jamais ne tourne pas sans fin. Ce qui avait déjà été préparé avant l'échec est gardé pour la tentative suivante, plutôt que d'être refait.

Certains échecs ne sont pas repris, parce que réessayer donnerait la même réponse : une voix qui n'existe plus chez le fournisseur, par exemple. Le travail échoue alors tout de suite, avec sa cause.

Quand un audio échoue pour de bon, deux choses se passent. Aucun crédit n'est décompté pour un audio qui n'a pas abouti. Et vous recevez un courriel, dans votre langue, qui ne recopie pas l'erreur technique brute ; s'il y en a d'autres dans les heures qui suivent, ils sont listés au même endroit, et le message ne se répète pas plus d'une fois toutes les six heures. Il ne reste alors qu'à relancer la fabrication depuis Mes audios, une fois la brique revenue.

Ce que la page de statut ne dit pas

Nous n'affichons aucun taux de disponibilité. Le mesurer honnêtement demande une sonde externe historisée, que nous n'avons pas encore. Un « 99,9 % » calculé de mémoire serait précisément le chiffre qu'un client reprendrait dans son propre cahier des charges, et il l'engagerait lui, pas nous.

Le registre des incidents, lui, est daté : il a été ouvert le 6 août 2026 et il le dit. « Aucun incident consigné » y signifie « depuis cette date », pas « depuis toujours ».

En revanche, la route publique /api/health répond avec un code HTTP 503 quand une brique est en panne, et pas seulement avec un champ dans le corps. Si votre équipe technique surveille déjà ses dépendances avec un outil de supervision, elle peut y ajouter cette adresse et être prévenue en même temps que nous.

En résumé, ce que vous avez à faire

Presque rien, et c'est le but. Pendant une panne, vos articles s'affichent normalement, le lecteur s'efface au lieu de se casser, et les fabrications en attente sont reprises. Après la panne, un coup d'œil à Mes audios pour relancer ce qui a échoué, si un courriel vous l'a signalé.

Et avant de choisir un outil, quel qu'il soit, posez-lui la même question qu'ici : qu'est-ce que mes lecteurs voient quand vous tombez ? La réponse en dit plus long sur sa conception que n'importe quelle plaquette.

À 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