Concevoir et développer une application de visualisation de données de santé auprès d’utilisateurs non spécialistes

Développer un MVP en mode “startup data” Notre équipe – Mathilde, coach, Clément, tech lead, et Inès, UX/UI designer – a été intégrée à l’équipe initiale du projet, composée de spécialistes de la mortalité de l’ARS Ile de France (chefs de projet data et spécialiste en épidémiologie) et de la Direction générale de la santé (spécialiste de la certification des décès). Plusieurs étapes ont rythmé cette première intervention :

• Prise de connaissance du projet : des travaux avaient été initiés autour de l’expression du besoin utilisateurs et de l’accès à la base de données. Nous avons ainsi rencontré plusieurs membres de l’équipe projet et nous nous sommes documentés sur les pratiques actuelles en matière de visualisation de données “complexes” dans le domaine de la santé
• Phase de conception : pendant un mois, nous avons mené une “investigation” pour imaginer le service cible pour atteindre les objectifs de l’ARS.
  • Lors d’entretiens utilisateurs, nous avons interrogé médecins et référents pathologies sur leurs pratiques, le lien entre leurs missions et l’interprétation des données de mortalité, leurs besoins en restitution de données. Cette étape nous a permis de construire des maquettes d’interfaces que nous avons restituées à notre panel d’utilisateurs pour itérer. Les trois cas d’usages prioritaires ont été de réelles inspirations pour imaginer un service générique à l’ensemble des pathologies : l’application propose à l’utilisateur de sélectionner sa cause d’intérêt, filtrer selon plusieurs critères (âge, sexe, lieu de décès, département de résidence), de paramétrer différentes visualisations possibles en fonction de son besoin (carte, histogramme, courbe, donut, tableau) et d’exporter un fichier CSV correspondant à sa requête
  • Nous avons également exploré des enjeux plus techniques, autour de la structure de la base de données, afin d’identifier les technologies les plus compatibles avec la donnée et les besoins utilisateurs
• Phase de construction : pendant trois mois, nous avons organisé plusieurs sprints de développement pour traduire les maquettes en un service numérique. Plusieurs défis se sont présentés à nous, parmi lesquelles :
  • Les données : pour sécuriser la phase de développement, nous avons créé un jeu de données fictives, correspondant au schéma des données réelles. Cela nous a également permis de faire tester l’application aux utilisateurs
  • La simplicité utilisateurs et la pertinence épidémiologique : le vocabulaire utilisé dans l’application ainsi que le parcours de filtrage doit correspondre au besoin métier tout en respectant des principes en matière d’épidémiologie. Nous avons beaucoup travaillé sur ce volet, tant sur la formulation des fonctionnalités que sur des règles spécifiques de visualisation en fonction du parcours.
  • La conformité : nous avons configuré l’application (authentification et affichage des données) et ses infrastructures d’hébergement pour respecter les contraintes juridiques et techniques liées aux données de santé

Mettre en production le produit et assurer sa passation auprès de l’équipe de l’ARS Une fois le MVP consolidé et ses principales fonctionnalités testées par les utilisateurs, nous avons mis en production CM2D sur des données de mortalité réelles. Homologué pour l’utilisation de données de santé, le produit déployé permet d’explorer les données de mortalité à l’échelle de chacune des régions. Pour accompagner les équipes de l’ARS dans la prise en main de la plateforme, des techniques utilisées en back (NextJS, Elastic Search) et concevoir les évolutions, notre tech lead a assuré un coaching hebdomadaire. Ces sessions de formation ont conduit à stabiliser une solide documentation technique, disponible sur github. Le principal enjeu pour les équipes de l’ARS est d’assurer la pérennité de CM2D à moindre coût. Dans cette logique, nous avons développé une proof of concept (PoC) d’intelligence artificielle afin d’automatiser l’encodage des causes médicales de décès. L’encodage permet notamment d’avoir une donnée uniformisée et de fait d’assurer le bon fonctionnement de la plateforme. Le CépiDC, une branche de l’INSERM, est en charge de cet encodage qui prend entre trois et quatre mois compte tenu du volume de traitement. Pour permettre le fonctionnement de la plateforme sur des données en quasi temps réel, ou “données fraîches”, l’ARS a pris un prestataire de service externe API-sé assurant l’encodage temporaire. Notre PoC a pour objectif de se substituer au SaaS du prestataire : conçu et entraîné en moins d’une dizaine de jours, il atteint 85% d’accuracy. En le perfectionnant et en l’industrialisant, cela permettrait à l’ARS de réaliser des économies non négligeables sur le fonctionnement de CM2D.