Concevoir un accompagnement auditif sans le médicaliser

Si vous construisez une application qui touche à l’audition, vous entrez aussitôt dans un champ de mines réglementaire. L’étiquette « dispositif médical » est floue sur les bords, et la position la plus sûre est de supposer que tout ce que vous dites sur l’« amélioration » ou le « traitement » de l’audition vous fait atterrir dans le carnet d’un régulateur. C’est le bon réglage par défaut, mais c’est aussi une contrainte de conception, pas seulement une contrainte juridique.

HearLab est explicitement une application compagnon non médicale. Ce positionnement est réel, et pas un simple avertissement. Il façonne ce que nous construisons et ce que nous ne construisons pas.

Le cadre : « que vient-il de se passer ? »

Les aides auditives, les implants cochléaires et les dispositifs d’écoute assistée existent déjà. La couche clinique est dotée en personnel. Ce qui manque à beaucoup d’utilisateurs, c’est un moyen de consigner et de se rappeler ce qui vient de se passer dans un environnement donné : le restaurant qui était ingérable, la réunion qui s’est étonnamment bien déroulée, le casque qui sonnait étrangement maigre dans le train.

Une application compagnon non médicale peut faire exactement cela sans revendiquer le moindre rôle diagnostique. La mission est de :

• Capter le contexte (type de lieu, sources de signal, niveaux sonores, fatigue).
• Rendre la consignation peu coûteuse (deux taps, note vocale facultative).
• Faire émerger des tendances chaque semaine.
• Remettre à l’utilisateur un récapitulatif qu’il peut montrer à son audioprothésiste.

C’est réellement utile, et cela ne touche à aucune décision clinique.

Les aiguilles à enfiler

1. Réglementaire

Évitez tout ce qui implique traitement, diagnostic, appareillage ou correction. Même une formulation comme « calibrez votre aide auditive » est risquée. Tenez-vous-en à la consignation, à la prise de conscience, aux sous-titres et à la visibilité du routage. En cas de doute, cadrez-le comme l’expérience de l’utilisateur plutôt que comme le comportement de l’appareil.

2. Sociale

Une « application auditive » qui hurle handicap échoue. Beaucoup de personnes qui en bénéficieraient ne s’identifient pas encore à la catégorie, ou ne veulent pas l’afficher. Les affordances doivent donc être discrètes : le check-in ne doit pas avoir l’air médical, les sous-titres ne doivent pas avoir l’air clinique, et le tableau de bord ne doit pas ressembler à un dossier patient informatisé.

3. Technique

Sur Android, la couche de routage (AAudio, MediaRouter, BluetoothAdapter) masque une grande partie de ce que les utilisateurs veulent voir. Faire apparaître « votre audio est actuellement routé vers votre aide auditive via LE Audio » est plus utile qu’on ne le croit, et ce n’est exposé proprement dans aucune application grand public aujourd’hui.

4. Économique

La plus difficile. Les utilisateurs finaux ne paient pas de façon fiable pour les applications d’accessibilité. Le modèle qui fonctionne est une couche B2B2C : une application compagnon gratuite ou peu coûteuse pour les utilisateurs, et une couche tableau de bord pour les audioprothésistes et les centres auditifs qui veulent des informations anonymisées issues de leur patientèle.

Ce que nous ne faisons pas

• Nous n’appareillons pas, n’ajustons pas et ne recommandons pas d’aides auditives.
• Nous ne notons pas l’audition.
• Nous ne faisons pas de marketing auprès des acheteurs cliniques avec un langage clinique.
• Nous ne traitons pas les sous-titres comme une « fonctionnalité » ; ils constituent un socle.

Ce que nous faisons

• Nous aidons les gens à remarquer leur expérience auditive.
• Nous les aidons à la décrire.
• Nous rendons peu coûteux son partage avec le professionnel de leur entourage qui détient le contexte clinique.
• Nous traitons l’accessibilité auditive comme une véritable surface produit guidée par le design, et non comme un projet RSE.

Si ce cadre correspond à un problème sur lequel vous travaillez, nous cherchons des partenaires de conception.