Embauché pour une refonte de produit. Dès le premier mois, l'analyse terrain a révélé un enjeu plus large : faire du logiciel le maillon d'une suite connectée où la donnée suit le patient à travers tous les processus hospitaliers.
Sortir d'une refonte cosmétique pour mener une transformation produit complète : nouvelles fonctionnalités, modernisation des approches métier, alignement sur les flux cliniques réels plutôt que sur les contraintes TI héritées.
« La donnée doit suivre le patient à travers tous les processus hospitaliers, pas l'inverse. C'est le contrat de base d'une suite connectée. »
Élargir le périmètre sans dérailler le projet. Désosser un legacy sans casser l'écosystème. Prouver une vision produit avant qu'elle ne soit construite. Trois exigences qui s'affrontent — toutes non négociables.
Redéfinir le périmètre avec le PM dès l'analyse terrain : passer d'une refonte UI à une transformation produit complète, où chaque module devient un nœud d'une suite hospitalière intégrée. Données qui suivent le patient, fonctionnalités analysées par leur impact écosystème.
Découpage du logiciel existant en epics avec l'aide de l'IA — identification de ce qu'on garde, ce qu'on modifie et ce qu'on élimine. Analyse des impacts utilisateurs propagés à travers toute la chaîne hospitalière, pas seulement au niveau du module.
Création d'un prototype interactif codé via IA, branché sur les règles d'affaires et fonctionnelles refondues. Pas une maquette statique : un outil qu'on peut faire vivre, tester avec les utilisateurs cliniques et confronter aux contraintes réelles avant la moindre ligne de code de production.
Passage explicite d'une refonte UI à une transformation produit complète : nouvelles fonctionnalités, modernisation métier, alignement sur les flux cliniques réels plutôt que sur les contraintes TI héritées.
Réflexion fonctionnelle pour aligner le logiciel sur la pratique hospitalière observée plutôt que sur les processus hérités du legacy. Chaque règle remise en question avant d'être modélisée.
Identification des KPI réellement actionnables côté clinique et opérationnel, puis conception d'un design system orienté par ces indicateurs — l'interface qui rend la performance lisible, pas l'inverse.
Intégration des normes HL7 FHIR, contraintes du legacy et besoins de la refonte conjugués dans un même modèle. La donnée modélisée comme actif central de la suite, pas comme sous-produit du logiciel.
Trois artefacts qui structurent la suite des décisions : ce qu'on livre d'abord pour valider, comment on emmène l'existant sans casser l'écosystème, où on veut être à terme. Chaque arbitrage produit s'y rattache.
Trois temps qui s'enchaînent : désosser l'existant pour comprendre, mesurer l'impact écosystème de chaque nouveauté, projeter la trajectoire produit en MVP / migration / cible.
Découpage en epics avec l'aide de l'IA. Pour chaque module : on garde, on modifie, on élimine. Et surtout, on cartographie l'impact utilisateur à travers toute la chaîne hospitalière.
Chaque nouvelle fonctionnalité analysée par sa consommation de microservices : ce qui existe déjà, ce qu'il faut créer, ce qui doit être refactoré pour servir le reste de la future suite intégrée.
Trois jalons explicites : ce qu'on livre d'abord pour prouver la valeur, comment on emmène les utilisateurs et la donnée legacy sans rupture, où on veut amener la suite à 24 mois.
On ne refait pas un
logiciel hospitalier.
On orchestre la donnée
autour du patient.