Temps nécessaire pour comprendre un dossier patient.
15à30minutes
Étude de cas
Dalvia Santé : utiliser l’IA générative pour créer un produit réellement utile aux médecins
- Rôle
- Product Designer
- Année
- 2024–2025
- Équipe
- Experte Design Santé · Product · Tech · IA
Dalvia Santé est un produit basé sur l’IA générative conçu pour aider les médecins à parcourir plus rapidement des dossiers patients complexes. Il génère des synthèses adaptées au contexte de soin en faisant ressortir les informations pertinentes du dossier patient, et peut également générer une lettre de liaison comme base de travail à relire.
Lorsque j’ai rejoint le projet, le besoin et la technologie existaient déjà, mais l’expérience produit restait largement à construire : quels cas d’usage adresser, quelles informations générer et comment intégrer cette technologie dans les pratiques réelles des médecins ?
Nos utilisateurs principaux étant des médecins hospitaliers, nous devions aussi tenir compte du contexte dans lequel le produit serait réellement utilisé. Leur quotidien alterne entre consultations et visites de patients dans l’hôpital : accéder rapidement aux informations ne pouvait donc pas dépendre d’un poste de travail fixe. Nous avons ainsi fait du mobile l’expérience principale du produit.
J’ai travaillé aux côtés d’une Experte Design Santé et des équipes Product, Tech et IA. Nous avons co-porté la recherche et les principales décisions UX, tandis que j’ai pris un ownership plus direct sur l’UI, l’interaction design, le prototypage haute fidélité, les fondations mobiles et le delivery Design-to-Dev.
LA PROBLÉMATIQUE
Comment réduire le temps nécessaire pour comprendre un dossier patient ?
01Cas d’usage
Définir des usages concrets de l’IA
Dalvia reposait sur une idée claire : utiliser l’IA générative pour aider les médecins à consulter plus rapidement les informations d’un patient grâce à des synthèses générées.
Nous avions déjà une vision assez précise de l’expérience que nous souhaitions construire. Avant d’aller plus loin, nous avons cependant mis en place une phase de recherche auprès d’un panel de dix médecins volontaires.
L’objectif était de comprendre leurs pratiques, leurs besoins et leurs difficultés, mais aussi de confronter nos premières hypothèses produit à la réalité de leur quotidien.
Des besoins différents selon le contexte
Les informations dont un médecin avait besoin pouvaient varier selon sa spécialité, la consultation, le patient et ce qu’il cherchait à comprendre à ce moment précis.
Une synthèse générale pouvait être utile, mais certaines situations demandaient quelque chose de beaucoup plus ciblé.
Nous avons donc fait évoluer l’expérience pour permettre aux médecins de définir leur besoin avant la génération : choisir le type de synthèse puis, si nécessaire, paramétrer la période, les types de documents ou les catégories d’informations que l’IA devait prendre en compte.
Des contextes de travail différents
Les entretiens nous ont également montré que les médecins n’accédaient pas tous aux informations patients dans le même contexte.
Certains préparaient ou réalisaient des consultations, tandis que d’autres suivaient des patients hospitalisés ou se déplaçaient de chambre en chambre pendant leurs visites.
Nous avons directement traduit cette différence dans la structure du produit : depuis l’accueil, les médecins pouvaient rapidement basculer entre les patients hospitalisés et les patients en consultation, plutôt que de parcourir une liste unique quel que soit leur contexte.
02Confiance et contrôle
Donner aux médecins le contrôle sur ce que l’IA génère
Une fois les besoins des médecins mieux compris, une autre question est devenue centrale :
Comment utiliser l’IA générative dans un contexte médical sans demander aux médecins de faire aveuglément confiance à ce qu’elle produit ?
Nous avons conçu l’expérience autour de trois principes : donner du contrôle avant la génération, permettre de vérifier le résultat ensuite et rendre visibles les limites des données disponibles.
Contrôler la génération
Les médecins choisissent le type de synthèse dont ils ont besoin et peuvent définir le contexte ainsi que les informations que l’IA doit prendre en compte avant la génération.
Plutôt que de demander une réponse générique au système, le médecin garde la maîtrise de ce que le résultat doit l’aider à comprendre.
03Prototype et terrain
Tester le produit avant de le développer
Avant le développement, nous devions répondre à deux questions : les médecins pouvaient-ils réellement utiliser l’expérience que nous avions conçue, et celle-ci était-elle suffisamment robuste pour être présentée en dehors de l’équipe Design ?
Un prototype de navigation classique n’aurait pas reproduit suffisamment fidèlement le comportement réel du produit pour répondre à ces questions.
J’ai proposé d’utiliser ProtoPie, défendu ce choix auprès de l’équipe et construit moi-même le prototype haute fidélité. Il intégrait une recherche patient fonctionnelle avec des données fictives réalistes, la saisie clavier, la création de compte et l’OTP, les états de génération, les comportements au scroll et les micro-interactions.
Je l’ai également conçu pour fonctionner hors ligne afin de ne pas dépendre de la connexion internet pendant les démonstrations.
Tests utilisateurs
Tester l’expérience avec des médecins
Nous avons ensuite testé le prototype avec 7 médecins, à travers des scénarios allant de la recherche d’un patient à la génération puis à la consultation d’une synthèse personnalisée.
Les sessions ont été préparées et analysées conjointement par l’équipe Design, ce qui nous a permis d’identifier les éléments qui nécessitaient encore d’être clarifiés ou ajustés avant de poursuivre.
Démo Live
SantExpo 2024
Ce même prototype est ensuite devenu le principal support de démonstration à SantExpo 2024, le grand rendez-vous annuel français de la santé et du médico-social, alors que le produit lui-même n’était pas encore développé.
J’ai contribué au pitch et au scénario de démonstration, puis présenté le produit pendant trois jours à des directeurs d’établissements de santé, des DSI et des médecins. Au total, plus de 80 sessions de démonstration ont été réalisées pendant l’événement.
Ces démonstrations ont également fait émerger un signal d’intérêt clair : plusieurs établissements hospitaliers ont souhaité faire partie des premières structures à tester la solution.
04Fondations & delivery
Construire les fondations mobiles
La Poste Santé & Autonomie était une nouvelle entité de Docaposte, avec sa propre identité visuelle et de nouveaux besoins produit.
Docaposte disposait déjà de Cobalt, son Design System, mais ses fondations étaient alors principalement pensées pour des expériences web et ne couvraient pas encore les besoins mobiles nécessaires à Dalvia.
Plutôt que de créer un Design System séparé pour La Poste Santé & Autonomie, j’ai étendu Cobalt à ce nouveau contexte. J’ai construit les fondations mobiles nécessaires à Dalvia (typographie, tokens et composants mobiles) tout en introduisant un thème La Poste Santé & Autonomie connecté aux fondations existantes de Cobalt.
Cette direction a été revue avec le responsable du Design System Cobalt afin de garantir la continuité avec le système parent.
Ce travail a commencé dès le début du projet, et non une fois l’expérience entièrement conçue. J’ai impliqué très tôt les développeurs iOS et Android ainsi que le PO afin que les contraintes de plateforme, les comportements des composants et les considérations d’implémentation puissent directement nourrir le système au fil de l’évolution du produit.
Système de couleurs
Des tokens de couleur accessibles, adaptés à l’identité santé de Dalvia et aux besoins de l’interface mobile.
Typographie
Des styles typographiques mobiles conçus pour maintenir une hiérarchie claire et une bonne lisibilité dans l’ensemble du produit.
Composants
Des composants mobiles réutilisables, créés et adaptés à partir des fondations du Design System Docaposte.
Grilles
Des règles de mise en page responsive assurant une structure cohérente entre les différents écrans et types de contenus.
Icônes
Un langage iconographique commun, enrichi des éléments spécifiques au domaine de la santé nécessaires au produit.
Accessibilité
Contrastes, états d’interaction et zones tactiles directement pris en compte dans les fondations du système.
Préparer l’expérience pour l’implémentation
Une fois les principaux parcours stabilisés, j’ai préparé un fichier de delivery dédié regroupant les écrans, leurs états et leurs variantes.
Le prototype haute fidélité complétait les spécifications statiques lorsque certains comportements ou interactions étaient difficiles à communiquer uniquement à travers des écrans.
J’ai ensuite travaillé directement avec les développeurs iOS et Android ainsi qu’avec le Product Owner pendant l’implémentation afin de clarifier les comportements, revoir les composants et vérifier l’expérience à mesure qu’elle prenait forme dans le produit réel.
05 Résultats
Moins de temps dans les dossiers. Plus de temps pour les soins.
L’objectif n’était pas simplement de générer des synthèses, mais de réduire l’effort nécessaire pour comprendre la situation d’un patient et préparer certains documents clés.
Après implémentation, le produit a montré une réduction claire du temps nécessaire pour réaliser ces tâches.
- Pour comprendre un dossier patient
- contre 15 à 30 min auparavant
- Pour produire une lettre de liaison
- contre 15 à 30 min auparavant
05Réflexion
Concevoir l’IA sans perdre le contrôle
Dalvia est passé d’une technologie dont l’expérience produit restait encore à définir à une expérience structurée, testée avec des médecins, présentée à son marché et préparée pour son développement.
Le principal apprentissage que je retiens de ce projet est que, dans un domaine aussi sensible que la santé, concevoir une bonne interface autour d’un résultat généré par l’IA ne suffit pas.
Il faut aussi concevoir la relation entre l’utilisateur et l’IA : ce qu’il peut contrôler, la manière dont les limites sont rendues visibles et les moyens dont il dispose pour vérifier les informations avant d’agir.
