Live Caption sur Android : ce qu’’il fait et ce qu’’il ne fait pas

Live Caption d’Android est une fonction à l’échelle du système qui transcrit l’audio lu sur l’appareil. Elle fonctionne hors ligne grâce à la reconnaissance vocale embarquée (une version quantifiée des modèles ASR de Google). Elle est utilisée chaque jour par des dizaines de millions de personnes et constitue probablement la livraison d’accessibilité la plus marquante de la dernière décennie.

Elle est aussi souvent mal comprise. Voici le point de vue de l’ingénieure de terrain sur ce qu’elle fait, ce qu’elle ne fait pas et ce que cela implique si vous concevez des outils de soutien auditif.

Ce que Live Caption capte

• L’audio acheminé via les flux media ou VoiceCall d’Android.
• L’audio des sons système, des onglets de navigateur, des applis vidéo et de la plupart des applis musicales.
• En temps réel, sur l’appareil, sans aller-retour réseau.

C’est un large filet. Regarder YouTube, passer un appel, écouter un podcast, ouvrir un TikTok avec du son : tout cela est sous-titré automatiquement.

Ce qu’elle ne capte pas

• Le microphone. Live Caption ignore le micro. Il s’agit de ce que votre téléphone joue, pas de ce qui se passe autour de vous.
• Les indices audio spatiaux. Elle transcrit des mots. La musique, l’ambiance d’une pièce, les sons d’environnement : tout est écarté ou simplement étiqueté (“[Musique]”, “[Applaudissements]”).
• Les langues hors de l’ensemble pris en charge. La liste prise en charge s’est élargie, mais ne représente encore qu’une fraction des langues parlées dans le monde.
• L’identité des interlocuteurs dans les appels de groupe. Elle transcrit, mais ne fait pas de diarisation. Vous ne verrez pas “Alex :” ou “Mia :” ; vous ne voyez que du texte.

Le manque côté microphone est le point majeur. Si vous voulez sous-titrer le monde qui vous entoure (un restaurant, une réunion), il vous faut un flux distinct, généralement une appli tierce avec une autorisation micro explicite, parfois en s’appuyant sur de l’ASR cloud pour la précision.

Ce que cela signifie pour HearLab

Le mode sous-titres de HearLab est explicitement un mode de sous-titres microphone. Nous ne cherchons pas à remplacer Live Caption ; Google l’a fait mieux que nous ne le ferons jamais pour la lecture de médias. Nous essayons de faire ce que Live Caption ne fait pas : sous-titrer la pièce autour de l’utilisatrice.

Ce choix a des implications :

1. Il nous faut l’autorisation du micro, ce qui suppose un consentement explicite de l’utilisatrice et une UX claire autour de cela.
2. L’ASR cloud est envisageable. Les modèles embarqués peuvent faire beaucoup, mais l’ASR cloud (Whisper, Deepgram, l’API STT de Google) reste nettement meilleur pour l’audio bruyant du monde réel.
3. Le cadrage de la confidentialité compte. Une appli au micro actif qui envoie de l’audio vers un cloud doit être très claire sur ce qu’elle fait, quand et pendant combien de temps. Désactivé par défaut et une interface d’enregistrement explicite ne sont pas négociables.

Ce que Live Caption réussit et dont nous devrions nous inspirer

• Latence : le modèle embarqué fournit un premier jet de texte en moins d’une seconde. Tout ce qui est plus lent brise l’illusion de « sous-titres ».
• Faillir avec élégance : lorsque la confiance est faible, Live Caption affiche un texte plus clair et plus petit. L’utilisatrice voit qu’il s’agit d’une supposition. Nous faisons de même dans HearLab : les résultats provisoires s’affichent en italique, les résultats finalisés dans la graisse normale.
• Correction en ligne : à mesure que davantage de contexte arrive, les mots précédents peuvent être mis à jour. Cela exige une interface qui ne pénalise pas les utilisatrices lisant du texte « en direct » : le curseur reste à peu près là où se porte le regard, et non là où le texte est de nouveau rendu.

Construire un mode sous-titres dans le navigateur

Pour la démo HearLab Companion, nous utilisons la Web Speech API (SpeechRecognition). Il s’agit pour l’essentiel de l’ASR cloud de Google exposé via Chrome/Edge, avec un certain repli embarqué dans Safari. C’est le bon point de départ pour le prototypage parce que :

• La configuration tient en une ligne.
• Elle gère les résultats provisoires et finaux d’emblée.
• Elle prend en charge le mode continu.

C’est le mauvais point d’arrivée pour la production parce que :

• C’est une voie gratuite, médiée par le navigateur, sans SLA.
• Le cycle de vie est fragile : sur certaines plateformes, le moteur de reconnaissance s’arrête silencieusement après quelques minutes.
• Vous ne contrôlez pas quel modèle est utilisé.

Pour un companion HearLab en production, Whisper (exécuté sur un backend) ou Deepgram est le bon choix. La Web Speech API nous fait traverser la phase de prototype sans avoir à prendre de décisions d’infrastructure avant qu’elles ne soient nécessaires.

Connexe

• Concevoir un soutien auditif sans le médicaliser
• Routage des aides auditives via l’Android Audio Framework