Conception d’une plateforme de données pour que la recherche consulte enfin ses propres résultats
Rôle:
- product-design
- user-research
2022–2024
Suisse
Résumé
Passage d’un accès réservé au terminal, où 86 % des données publiées restaient inconsultées, à une interface graphique qui relie les données par leur provenance, avec 94 % de données consultées. J’ai demandé à trois ingénieurs backend de mesurer l’usage, défendu une vraie plateforme pour structurer, annoter, relier et partager les données, et prouvé sa faisabilité par un test sur un circuit de 20 neurones. Plus de 2 600 chercheurs y sont désormais actifs chaque mois.
Demandez-moi
- Entreprise
Blue Brain Project, EPFL
- Année
2022 – 2024
- Rôle
Product Design Lead et ingénieur frontend
- Équipe
L’équipe NISE, 3 ingénieurs backend, et les équipes de neuroinformatique computationnelle et de HPC
- Métrique star
Données consultées de 14 % à 94 %
- Problème
86 % des données publiées n’étaient jamais consultées, car elles n’étaient accessibles que par le terminal et un SDK, alors que les scientifiques voulaient surtout voir les liens entre les données.
- Décision
Refuser de réduire le produit à une recherche de bibliothèque avec des points d’accès API, appuyer ce refus sur cinq ans de données d’usage et sur la recherche qualitative, puis prouver la faisabilité par un test sur un circuit de 20 neurones.
- Résultat
Données consultées de 14 % à 94 %, avec plus de 2 600 chercheurs actifs par mois.
01
Le Contexte & la friction business
Des données publiées que presque personne ne consulte
Au Blue Brain Project, un premier diagnostic d’usage montre que 86 % des données publiées de Fusion ne sont jamais consultées. Elles ne s’atteignent que par un SDK ou le terminal, alors que les scientifiques veulent voir les liens entre les données. En interne, certains veulent réduire le produit à une recherche et à des points d’accès API. La plateforme complète se heurte à trois objections : le coût, une priorité jugée plus basse et la qualité des données.
02
L’Arbitrage Majeur
Ce que j’ai imposé, négocié ou refusé
Certains voulaient réduire le produit à une recherche de bibliothèque et à des points d’accès API à copier dans un terminal. J’ai défendu une vraie plateforme, pour structurer, annoter, relier et partager les données. En deux à trois réunions, j’ai appuyé ma position sur les entretiens avec les scientifiques et sur cinq ans de requêtes API, qui montraient que le terminal était rarement utilisé. J’ai aussi refusé de lancer des simulations depuis l’application web : cela demandait une application à part entière, avec ses paramètres et une validation des données avant chaque simulation.
Des séances de test en groupe et des entretiens individuels avec les scientifiques, les preuves derrière ma position.
03
La Transformation
De listes de projets sans repères à une exploration par type de données et par provenance
Avant, Fusion alignait deux longues listes de projets et d’études, où les mêmes entrées se répétaient à l’identique, et un menu d’outils éparpillés : Search, Studio, Workflow, Admin, Kibana…
Après, la recherche se fait par type de données, morphologies, électrophysiologies, simulations…, chacun avec son nombre de jeux de données. Les éléments utiles peuvent être épinglés.
La provenance relie enfin les données entre elles. Un onglet Relations montre une entité, ici un neurone du thalamus, avec son circuit parent au-dessus, ses frères à côté et ses 30 canaux ioniques en dessous, et un curseur de niveau remonte aux circuits qui la contiennent. À côté de l’aperçu du circuit, les blocs « Built from » et « Used in » listent les jeux de données liés, en amont et en aval.
04
Impact Business & Preuves
La valeur mesurable générée pour la recherche
Fusion est enfin consulté : la part de données consultées est passée de 14 % à 94 %, avec plus de 2 600 chercheurs actifs par mois sur l’application web. La plateforme compte plus de 12 000 rapports, 20 000 données expérimentales et 150 studios publiés.
Et la proposition, d’abord contestée, est devenue une preuve de concept approuvée par quatre responsables d’équipe et validée sur des données réelles.
05
Recul critique & rétrospective
Mes apprentissages et mon niveau de maturité
J’aurais ajouté une console de curation des données, utilisée par l’équipe de curation du BBP, pour montrer le cycle de vie d’une donnée plutôt qu’une image figée. Les utilisateurs voulaient savoir quand une donnée avait été créée ou mise à jour, mais le temps et les personnes manquaient, donc je l’ai laissée de côté.
J’ai appris que les données d’usage tranchent mieux que les opinions : cinq ans de requêtes API et la recherche qualitative ont réglé un débat qu’un avis de designer n’aurait pas réglé.
Un point reste ouvert : la faisabilité du module de relations à l’échelle de millions de ressources, et sa mise en production.
