06 · Produit & medtech · Étude de cas
Une langue commune pour sept disciplines
Extender réunit sept organisations : laboratoires de robotique, une entreprise de robotique d’assistance, cliniciens et chercheurs en sciences sociales. Tout le monde partageait la mission, mais les réunions de priorisation calaient, car une même capacité voulait dire autre chose pour chaque personne autour de la table. J’ai conçu une méthode pour que chaque discipline exprime ses besoins dans sa propre langue tout en étant comprise des autres, main dans la main avec l’équipe produit d’ORTHOPUS.
- Le problème
- Ce qui ressemblait à un désaccord sur les priorités était en fait un défaut de traduction. Utilisateur, clinicien, ingénieur et chercheur décrivaient chacun correctement une chose différente.
- Mon rôle
- Cadrage produit à l’échelle du consortium : j’ai proposé le modèle, animé les sessions de travail et co-écrit le registre des capacités avec ORTHOPUS.
- Le résultat
- Un registre que le labo et l’entreprise lisent à la fois comme backlog de recherche et backlog produit, où chaque capacité est compréhensible par tous.
Quatre lectures d’une même capacité
Plutôt qu’un plus petit dénominateur commun ou une traduction détenue par l’ingénierie, chaque capacité est écrite quatre fois, en parallèle, par les personnes qui parlent chaque langue.
- Usage
- Personnes en situation de handicap : vécu, capacités, frustrations et envies.
- Clinique
- Ergothérapeutes et médecins : fonctions, limitations, risques et critères cliniques.
- Technique
- Ingénieurs logiciel et matériel : fonctions système, modules, interfaces et contraintes.
- Recherche
- Chercheurs en commande, vision et IHR : méthodes, lois de commande et métriques scientifiques.
- Transversal
- Sociologie, IHR et éthique vérifient l’acceptabilité et la dignité à chaque niveau, et repèrent le poli « ça va » qui veut dire « je ne l’utiliserai jamais ».
Des capacités ancrées dans une phrase d’utilisateur
Les capacités sont regroupées en trois familles, chacune rattachée à une phrase qu’un utilisateur dirait de sa propre journée. Un nom de fonctionnalité se discute sans fin ; une phrase à la première personne ne peut qu’être approuvée ou contredite par des faits sur les utilisateurs.
“Le robot m’aide à faire le bon geste sans me retirer le contrôle.”
“Je peux essayer sans avoir peur.”
“Je peux vraiment agir sur le monde.”
Comment la discussion devient un plan
- Des capacités petites mais parlantesChacune est assez petite pour être portée et démontrée, et assez grande pour avoir du sens pour un utilisateur.
- Le nécessaire avant l’intéressantChaque capacité reçoit un poids et un type : les fondations du produit passent avant la recherche la plus excitante.
- Rien sans raisonLes intentions utilisateur mènent aux user stories, qui mènent aux tâches. Pas de tâche sans story, pas de story sans intention.
- Terminé veut dire validéChaque phase se clôt avec des utilisateurs ou des cliniciens, pas sur la seule preuve technique : tests utilisateurs, validation clinique, puis protocole final.
Les sciences sociales dans la salle
Les partenaires socio-anthropologues ont participé eux-mêmes aux sessions de co-conception, au lieu de rendre compte après coup. Sur un dispositif d’assistance, l’acceptabilité et la dignité échouent en silence : il faut une discipline qui veille, pas une ligne dans une spécification.
La leçon que je garde : quand quelqu’un soulève ce qui ressemble à une préoccupation « douce », c’est souvent une exigence ferme formulée dans un vocabulaire inhabituel.
Ce que je ferais autrement
Proposer tout un cadre d’un coup demande beaucoup à des partenaires très occupés. La prochaine fois, je partirais des quelques capacités dont on débat déjà, j’écrirais la phrase utilisateur de chacune, et je laisserais la structure grandir à partir de ces échanges.