Retour au blog
Design Inclusif

Audio First — Ce que cela veut vraiment dire, et ce que cela change

Manassé A. AKPOVI··10 min de lecture

Imaginez une salle de classe. L'enseignant parle dans une langue que vous ne maîtrisez pas. Personne ne vous exclut. Personne ne vous interdit d'entrer. Mais vous ne comprenez rien. Vous êtes là — mais absent.

C'est ce que vivent chaque jour des millions de personnes face au numérique. Pas parce qu'elles manquent d'intelligence. Pas parce qu'elles refusent la technologie. Mais parce que nos interfaces ont été conçues sans elles.

Ce texte raconte comment j'ai construit BibleFon — une plateforme d'histoires bibliques en langue fon pour les enfants et les familles du Bénin — en prenant au sérieux une seule question : qu'est-ce que cela veut dire de concevoir une interface vraiment audio-first ? Pas audio-friendly. Pas audio-possible. Audio-first.

Audio-first ne signifie pas « avoir un bouton play ». Cela signifie que le son est le mode de communication primaire.

1. Le problème que le numérique ne voit pas

En 2024, lors d'une conférence sur l'IA multimodale et les langues locales — le SENIA — j'ai travaillé sur un projet lié aux langues africaines. Une phrase prononcée ce jour-là par la Ministre béninoise du Numérique, Mme Aurélie I. ADAM SOULÉ, a planté quelque chose que je n'ai pas réussi à ignorer :

« Nos langues, au lieu d'être une source d'incompréhension, deviendraient un élément d'union. »

— Mme Aurélie I. ADAM SOULÉ, Ministre du Numérique, Bénin, SENIA 2024

Cette phrase dit tout. Nos langues — les langues locales d'Afrique, parlées par des millions de personnes, transmises oralement depuis des générations — sont traitées comme des obstacles dans le numérique. Comme des exceptions à gérer.

Pourtant, selon l'UNESCO, près de 500 millions d'adultes en Afrique subsaharienne sont en situation d'analphabétisme fonctionnel. Ces personnes ne sont pas exclues du numérique par choix. Elles en sont exclues par conception.

L'impensé de nos interfaces

Quand on conçoit une interface numérique, on fait inconsciemment des hypothèses sur l'utilisateur. On suppose qu'il sait lire. Qu'il maîtrise une langue dominante — souvent le français ou l'anglais. Qu'il dispose d'une connexion stable. Et qu'il est habitué à naviguer dans des menus hiérarchiques.

Ce ne sont pas des hypothèses universelles. Ce sont des hypothèses sur un profil particulier d'utilisateur — celui qui ressemble aux personnes qui ont conçu les outils. Pour tous les autres, nos interfaces sont une salle où tout le monde parle une langue qu'ils ne comprennent pas.

La langue fon comme cas concret

La langue fon est parlée par plusieurs millions de personnes au Bénin et dans les pays voisins. C'est une langue orale, vivante, portée par une culture riche. En 2022, Google Traduction l'a intégrée — une belle avancée sur le papier. Mais une traduction écrite ne suffit pas là où l'écrit est lui-même une barrière. Ce qu'il faut, c'est une voix. Du son. Une interface qui parle avant même qu'on ne touche quoi que ce soit.

2. Qu'est-ce qu'Audio First veut vraiment dire ?

Le terme « audio-first » existe dans le monde du podcast et du contenu audio. Il désigne des plateformes où l'audio est le format principal. Mais dans le domaine de la conception d'interface — et en particulier pour les contextes d'oralité en Afrique — la notion n'a pas été formalisée. Voici la distinction que j'ai construite en travaillant sur BibleFon :

Audio-first cosmétiqueAudio-first réel
L’audio est une fonctionnalité ajoutéeL’audio est le mode de communication primaire
Lire est l’action principale, écouter est optionnelÉcouter est l’action principale, lire est un support
L’interface est muette jusqu’au clicL’interface parle avant qu’on clique quoi que ce soit
Le texte explique ce que l’audio faitL’audio fait, le texte confirme pour ceux qui lisent
On ajoute un bouton play à une interface existanteOn conçoit l’interface entière depuis le son

Ce que cela veut dire concrètement : sur un site classique, le parcours est « arriver sur la page → lire le titre et la description → trouver le bouton play → cliquer → écouter ». Chaque étape avant « écouter » est une barrière pour quelqu'un qui ne lit pas couramment.

Sur une interface vraiment audio-first : arriver sur la page → l'ambiance sonore commence → voir une image et un bouton play → appuyer → l'histoire se raconte, les pages avancent seules. Zéro lecture obligatoire. L'image et le son font tout le travail.

3. Ce que la recherche dit — et que le design ignore

Les études sur les interfaces pour publics peu alphabétisés existent. Elles sont claires. Elles sont ignorées par la quasi-totalité des concepteurs.

ACM CHI — Interfaces for Low-Literacy Users

Les participants peu alphabétisés préfèrent et fonctionnent mieux avec de grands boutons et icônes qu'avec des menus textuels. Les structures de navigation hiérarchiques sont incomprises par la majorité des utilisateurs peu alphabétisés.

Ce résultat a des implications directes : pas de menus déroulants, pas d'arborescences, des icônes grandes et des actions directes. Sur BibleFon : pas de menu de navigation, une seule page, des cartes avec des images, un bouton play.

Microsoft Research — Voice interfaces for emerging markets

Les interfaces textuelles sont inutilisables par les utilisateurs peu alphabétisés sans expérience préalable. Et voici le chiffre qui change tout : l'audio comme modalité primaire augmente l'engagement de 3x par rapport au texte seul dans les contextes d'oralité. Ce n'est pas un problème de motivation ou d'intelligence. C'est un problème de conception.

WhatsApp comme modèle involontaire

WhatsApp est probablement l'application la plus utilisée par le public cible de BibleFon. Les messages vocaux fonctionnent parce que le public sait appuyer play sans lire un seul mot. La barre de progression est un geste universel, compris sans explication.

WhatsApp n'a pas enseigné à ces millions de personnes à utiliser le numérique — il s'est adapté à la façon dont elles communiquent déjà : oralement. C'est exactement la philosophie audio-first.

4. BibleFon — Appliquer concrètement

En mars 2026, j'ai lancé BibleFon v2. L'objectif : transformer un flipbook avec audio en une vraie expérience audio-first. Voici les quatre décisions concrètes que j'ai prises, et pourquoi.

Décision 1 — Inverser la hiérarchie des actions

Sur la v1, le bouton principal était « Lire ». La description textuelle en français supposait que l'utilisateur lisait couramment. Sur la v2 : le bouton play est le seul élément d'action principal.

Ce changement déclare quelque chose fondamental : l'utilisateur par défaut de ce site est quelqu'un qui écoute, pas quelqu'un qui lit.

Comparaison V1 vs V2 de BibleFon : la carte David. V1 : bouton Lire en CTA principal avec description longue en français. V2 : bouton play seul, zéro description textuelle.
V1 : « Lire » est le CTA principal avec description longue. V2 : bouton play, zéro description. Le choix du bouton principal est une déclaration sur qui est l'utilisateur par défaut.

Décision 2 — L'interface parle en premier

Au survol d'une carte (desktop) ou au tap d'une icône musicale (mobile), une voix en fon commence à décrire l'histoire. L'utilisateur n'a pas encore cliqué pour entrer. L'interface l'accueille dans sa langue.

Sur desktop : une rich card apparaît à côté de la carte avec titre, extrait et citation. Sur mobile : un panneau monte depuis le bas avec le même contenu. Dans les deux cas, la voix en fon joue avant que l'utilisateur ne demande quoi que ce soit.

BibleFon Décision 2 : Desktop hover avec rich card et voix en fon. Mobile tap avec bottom sheet qui monte depuis le bas.
Desktop (hover) : rich card + voix en fon. Mobile (tap) : bottom sheet qui monte depuis le bas. L'interface parle avant qu'on lui demande.

Décision 3 — Éliminer les étapes et unifier image et son

Sur la v1 : le player était en mode slide. Le texte français s'affichait en gros plan, l'image était secondaire. Navigation manuelle, plusieurs étapes avant l'audio.

Sur la v2 : 1 tap pour lancer l'audio, les pages avancent automatiquement, l'image est grande et centrale, le mot actuellement prononcé est surligné en temps réel — le karaoké. Pour les enfants qui apprennent à lire : aide pédagogique. Pour les parents peu alphabétisés : beau à regarder sans contrainte.

BibleFon Décision 3 : V1 mode slide avec texte français en gros plan. V2 player immersif avec image dominante, karaoké doré et auto-pagination.
V1 : mode slide avec texte français en gros plan. V2 : player immersif, image dominante, karaoké en doré, auto-pagination. L'image et le son font tout le travail.

Décision 4 — L'ambiance avant le contenu

Quand l'utilisateur descend vers la bibliothèque, une musique africaine commence doucement — Whimsy Groove de Kevin MacLeod (CC BY 4.0). Tambours, oiseaux, atmosphère de conte.

Ce n'est pas de la décoration. C'est un signal : tu entres dans un espace d'histoires. Le son prépare l'écoute avant que l'histoire commence.

  • Volume bas — 0.3 maximum au démarrage, fade in sur 2-3 secondes
  • Bouton son visible dès que la musique démarre
  • Mémoire localStorage : le choix de l'utilisateur est conservé
  • Ducking automatique : quand un aperçu audio joue, la musique baisse

5. Ce que cela démontre — et ce qui reste

Ce que BibleFon prouve

BibleFon n'est pas un produit fini. C'est une démonstration.

  • Qu'une interface audio-first est techniquement réalisable avec des outils accessibles
  • Que Meta MMS-TTS-FON permet de synthétiser de la voix en langue fon de qualité suffisante
  • Que les patterns UX des apps les plus utilisées peuvent être adaptés à des contextes d'oralité
  • Qu'une expérience numérique peut être pensée depuis le son, sans sacrifier la beauté

Ce qui reste à construire

  • Une vraie voix humaine pour le conteur — un locuteur fon natif enregistré. Cette voix serait l'âme du projet.
  • Des enfants béninois qui répondent en chœur — le call-and-response du conte africain traditionnel.
  • Plus d'histoires : La Fournaise, Noé, Abraham sont en préparation.

Ce que cela implique pour le design en général

La notion d'audio-first appliquée aux contextes d'oralité ouvre des questions que le design habituel ne pose pas :

  • Comment conçoit-on une action sans texte ?
  • Comment indique-t-on un état sans écrire de message ?
  • Comment structure-t-on une bibliothèque pour quelqu'un qui ne lit pas les catégories ?

Ces questions n'ont pas de réponses définitives. Mais les poser sérieusement, c'est déjà commencer à concevoir pour tous.

Conclusion

Audio-first, dans le sens où je l'entends, ce n'est pas un format de contenu. C'est une philosophie de conception.

C'est décider que l'utilisateur par défaut de ton interface n'est pas forcément quelqu'un qui lit couramment. C'est construire depuis le son — et laisser le texte pour ceux qui veulent aller plus loin.

BibleFon est ma première réponse concrète à cette question. Les principes — inverser la hiérarchie des actions, éliminer les étapes superflues, faire parler l'interface avant le clic — valent pour bien d'autres contextes.

Le numérique parle à des gens qui savent lire. Il est temps de lui apprendre à parler à tout le monde.

Références

  • Medhi, I. et al. — Usability of Text-Free Interfaces for Low-Literate Users — ACM CHI
  • Medhi, I. et al. — A Comparison of Mobile Money-Transfer UIs for Non-Literate and Semi-Literate Users — Microsoft Research India
  • UNESCO — Literacy Report 2023 — Analphabétisme fonctionnel en Afrique subsaharienne
  • GSMA — Mobile Economy Sub-Saharan Africa 2024
  • Meta AI — Scaling Speech Technology to 1,000+ Languages — MMS-TTS-FON
  • Kevin MacLeod — Whimsy Groove — incompetech.com — CC BY 4.0

Manassé A. AKPOVI

Développeur web · IA & Inclusion numérique · Créateur de BibleFon

Béninois, étudiant en ingénierie web à l'ESGI Paris. Je construis des interfaces pour ceux que le numérique habituel ignore — à commencer par les locuteurs fon au Bénin.

Audio First — Ce que cela veut vraiment dire | Manassé AKPOVI