Ce qu'une chips m'a appris sur le design sonore des interfaces

Design sonore UI pour le web : pourquoi les sites sont muets, comment le feedback sonore améliore l'UX, les règles d'accessibilité et la Web Audio API.

En 2004, deux chercheurs d'Oxford ont installé des volontaires dans une cabine, leur ont mis un casque sur les oreilles et posé devant eux un tas de chips. La question était simple : à quel point celle‑ci est croustillante ?

Les chips étaient toutes identiques. La seule chose qui changeait, c'était ce que les gens entendaient en croquant. Massimiliano Zampini et Charles Spence captaient le croquant avec un micro et le renvoyaient dans le casque en temps réel, parfois plus fort, parfois avec les aigus amplifiés. Quand le croquant était plus fort ou plus brillant, les gens jugeaient la même chips plus croustillante et plus fraîche. L'étude a reçu un prix Ig Nobel en 2008, la récompense des recherches qui font d'abord rire, puis réfléchir.

Je repense à ces chips chaque fois qu'on me dit que le son sur un site web, c'est un gadget.

Parce qu'une interface aussi a son croquant. Vous appuyez sur un bouton, et quelque chose doit vous dire que ça a marché. Les designers appellent ça le feedback. Sur la plupart des sites, ce quelque chose est purement visuel. La couleur change, une icône tourne, et votre oreille ne reçoit rien. Puis, pour un projet d'école, j'ai conçu un concept de borne pour le Musée parasitologique de Meguro, à Tokyo, et l'oreille s'est révélée être la moitié du travail.

Pourquoi le web est devenu muet

Si vous avez navigué sur Internet dans les années 2000, vous savez pourquoi les sites ont arrêté de faire du bruit. Un lecteur de musique qui démarrait tout seul. Une pub qui hurlait depuis un onglet introuvable. Le son arrivait sans qu'on le demande, alors les gens ont appris à chercher le bouton muet en premier.

Les navigateurs ont compris le message. Depuis 2018, Chrome n'autorise une page à jouer du son qu'après une interaction du visiteur, et depuis Chrome 71 cette règle s'applique aussi à la Web Audio API (la politique d'autoplay de Chrome). Les utilisateurs, eux, ont continué à couper le son. En 2016, des éditeurs expliquaient à Digiday que jusqu'à 85 % de leurs vues vidéo sur Facebook se faisaient sans le son.

L'industrie en a donc tiré une conclusion : les gens détestent le son sur le web.

Mais relisez ces histoires. Les gens détestaient un son qu'ils n'avaient pas demandé, à un volume qu'ils n'avaient pas choisi, sans moyen de l'arrêter. C'est un reproche fait à un comportement. Le média a pris les coups par accident, et le design sonore d'interface en paie le prix depuis.

Ce que le son d'interface fait et que les pixels ne font pas

Côté UX, le son a deux atouts : il est rapide, et il n'a pas besoin de vos yeux. Vous pouvez regarder le mauvais coin de l'écran et savoir quand même que le fichier est parti. Ce serait déjà suffisant, mais je l'ai vu faire trois autres choses en pratique.

Il confirme sans réclamer l'attention. En 1986, le chercheur William Gaver a proposé les icônes auditives : des sons d'interface conçus comme des caricatures de sons réels, pour qu'un fichier qui arrive dans un dossier sonne un peu comme quelque chose qui atterrit. Pas besoin d'apprendre ce qu'ils veulent dire. Vos oreilles le savent déjà. Trois ans plus tard, Meera Blattner et ses collègues ont décrit l'autre famille, les earcons : de courts motifs abstraits qu'on apprend, comme le carillon d'un message envoyé. La plupart des designs sonores d'interface mélangent aujourd'hui les deux.

Il donne une matière aux choses. C'est la leçon des chips. Un glisser‑déposer qui se termine par un petit bruit sourd paraît plus lourd que le même geste en silence. Mêmes pixels, même animation, objet différent.

Il donne à un mouvement sa fin. Les game designers ont un mot pour ça : le juice. Dans leur conférence de 2012, Juice it or lose it, Martin Jonasson et Petri Purho ont pris un clone de Breakout tout nu et y ont ajouté du retour jusqu'à ce qu'il paraisse vivant, et le son faisait partie de la liste. Tout est une question de timing. Le cerveau colle un son à un mouvement quand les deux arrivent ensemble, et il est plus tolérant quand l'image précède légèrement le son que l'inverse (Vroomen & Keetels, 2010). Déclenchez donc le son au moment du contact, jamais au début de l'animation.

Le problème du musée

Le Musée parasitologique de Meguro existe bel et bien, et c'est le seul musée au monde entièrement consacré aux parasites. Ma borne, elle, n'existe pas : c'est un projet d'école, un concept que le musée n'a jamais commandé. L'exercice consistait à imaginer une couche interactive devant ses vitrines. Quatre expositions, un mini‑jeu dans chacune, et des spécimens que les visiteurs feraient glisser pour les collectionner dans une boîte virtuelle. Le brief visait les enfants, sans perdre les spécialistes présents dans la même salle.

Même sur le papier, cette salle, c'est tout le problème. Une borne n'est pas un téléphone dans votre poche. Dans une galerie comme celle‑ci, d'autres visiteurs liraient en silence à un mètre, donc tout ce qui était bruyant ou façon arcade était exclu avant même d'être un choix de design. Le son devait donner à la borne l'allure d'un jeu sans en avoir le bruit.

L'idée évidente, c'était des bruits de créature visqueux à chaque prise. Dans un musée des parasites, la blague s'écrit toute seule. C'est justement pour ça que je l'ai écartée : elle aurait lassé dès le deuxième spécimen, et elle se serait moquée du sujet même du musée. J'ai choisi des textures organiques, assez tactiles pour donner l'impression de manipuler quelque chose de réel, en les gardant agréables plutôt que dégoûtantes.

Voici ce que ce système m'a appris.

Commencer par un fond, pas par des effets

Dans le prototype, le système repose sur une boucle d'ambiance calme, faite de tonalités sous‑marines, qui tourne à bas volume sous toute la borne. Avec elle, chaque effet a quelque chose sur quoi se poser. Sans elle, chaque clic tombe dans une pièce vide et paraît plus fort qu'il ne l'est.

Un bouton, un son

Chaque tap de navigation utilise le même clic grave et calme, dans la barre latérale comme partout ailleurs. Les recommandations de Material Design disent que le son convient rarement aux actions que l'on répète souvent, et en principe je suis d'accord. Mais sur un écran tactile, le doigt ne reçoit rien en retour de la vitre, et un clic discret est la seule preuve que le tap a été pris en compte. Je l'ai donc gardé, rendu discret, et identique à chaque fois, pour qu'il fasse partie du bouton au lieu d'être un événement.

Ne pas punir l'erreur

Les mini‑jeux jouent un son léger en cas de réussite et une tonalité douce en cas d'échec. Se tromper devant ses parents est déjà assez gênant. La borne n'a pas besoin de buzzer en plus.

Garder le moment fort pour une seule fois

Il y a exactement un son dans tout le système qui n'est pas calme. Quand la boîte de spécimens est complète, une petite fanfare retentit pendant qu'une bande de papier se déchire pour révéler le coupon du musée, le son et le mouvement se déchirant ensemble. Il n'arriverait qu'une fois par visite, et c'est pour ça qu'il a le droit d'être grand. Material appelle ça des hero sounds et recommande de les garder rares et cohérents. Je le dirais plus simplement : si tout célèbre, plus rien ne célèbre. La même règle vaut pour les récompenses en général, comme je l'explique dans ce qu'est vraiment la gamification.

Le code est la partie facile

Le côté technique est plus léger qu'on ne le croit. La musique de fond est un simple élément <audio> à 35 % du volume, et celle de l'écran final joue à 20 %. Les effets passent par la Web Audio API, avec quelques détails à reprendre :

let ctx: AudioContext | null = null
const cache = new Map<string, AudioBuffer>()

function getCtx() {
  if (!ctx) ctx = new AudioContext()        // créé au premier geste
  if (ctx.state === "suspended") ctx.resume()
  return ctx
}

export async function play(src: string, gain = 2.5) {
  const c = getCtx()
  let buf = cache.get(src)
  if (!buf) {
    buf = await c.decodeAudioData(await (await fetch(src)).arrayBuffer())
    cache.set(src, buf)                     // téléchargé et décodé une seule fois
  }
  const source = c.createBufferSource()
  const volume = c.createGain()
  source.buffer = buf
  volume.gain.value = gain                  // au-dessus de 1 pour passer au-dessus de la musique
  source.connect(volume).connect(c.destination)
  source.start()
}

Le contexte audio est créé au dernier moment, parce qu'un contexte créé avant toute interaction démarre suspendu à cause des règles d'autoplay. Les sons décodés sont mis en cache, donc la deuxième prise joue instantanément. Et le gain dépasse 1,0 pour que les effets courts restent audibles par‑dessus l'ambiance. Si vous faites pareil, écoutez d'abord votre fichier le plus fort à plein volume : au‑delà de 1,0, un son déjà très fort sature.

Les règles de design sonore que je donnerais à quelqu'un qui débute

Rien de tout ça ne demande un sound designer dans l'équipe. Il faut juste quelques règles qu'on ne casse pas.

• Ne jamais lancer de son au chargement. Attendez un clic ou un tap. Le navigateur vous y obligera de toute façon, et c'est la moindre des politesses.
• Laisser une porte de sortie. Si quelque chose se joue automatiquement plus de trois secondes, les WCAG, les règles d'accessibilité du web, demandent un moyen de le mettre en pause ou un réglage de volume dédié (critère de succès 1.4.2). Un bouton muet visible, qui se souvient de son état, règle la question.
• Ne jamais confier une information au son seul. L'OMS estime que 1,5 milliard de personnes vivent avec une perte auditive, et bien d'autres naviguent téléphone en silencieux. Pour l'accessibilité, chaque son a besoin d'un jumeau visuel.
• Choisir une famille de sons et s'y tenir. Les icônes auditives de Gaver marchaient parce que des événements proches sonnaient de façon proche. À Meguro, tout est organique ou sous‑marin. Un seul bip d'arcade égaré aurait tout cassé.
• Baisser le volume jusqu'à presque ne plus entendre. Puis tester l'interface dans un vrai contexte, avec de vraies personnes autour.

La même chips

L'étude de cas de Meguro, le projet d'école complet, va plus loin sur la mécanique de collection, le contenu bilingue et le développement. Vous pouvez la lire ici.

Mais si je ne devais garder qu'une chose de ce projet, ce seraient les chips. Personne dans cette cabine d'Oxford n'a mangé une chips différente. Ils en ont entendu une différente, et ça a suffi à changer ce qu'ils goûtaient.

Votre interface fonctionne de la même façon. Personne ne se souviendra du son de votre bouton. On se souviendra que la chose paraissait solide.