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 qui accompagne le patient à travers tout son séjour hospitalier.
Élargir le mandat initial en une transformation produit systémique : transformer un outil administratif hospitalier en véritable outil d'accompagnement du patient durant tout son séjour.
« La donnée doit suivre le patient, pas l'inverse. C'est le contrat d'une suite hospitalière qui accompagne, au lieu d'administrer. »
Le mandat initial demandait une refonte. L'analyse terrain a redéfini chaque axe — du périmètre aux KPI, en passant par la méthode et l'expérience utilisateur.
É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.
Le terrain a révélé que les hôpitaux contournaient la solution avec leurs propres workarounds — et payaient en plus des licences logicielles tierces exorbitantes pour combler les manquements. Avec le PM, on a basculé : non plus livrer une refonte module par module, mais transformer le produit en suite intégrée qui absorbe ces besoins réels.
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 produit ciblée à une transformation systémique : 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.
Standards d'interopérabilité HL7 FHIR, protection des renseignements de santé (PHI · Loi 25 du Québec) et compatibilité avec l'écosystème legacy 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.
Sous-agents IA avec triangulation dans le code pour cartographier l'architecture, la donnée et la consommation des microservices. Pour chaque module : on garde, on modifie, on élimine — et on prouve comment les nouvelles fonctions s'arriment.
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.
Deux artefacts forment le moteur de la transformation : un pipeline IA qui décortique le legacy, et un prototype React vivant qui le rejoue. Ensemble, ils transforment chaque hypothèse produit en démonstration.
Plutôt qu'un LLM unique qui hallucine sur un système complexe, j'ai orchestré plusieurs sous-agents spécialisés qui s'attaquent en parallèle à l'architecture, la donnée, les microservices et les flux. La triangulation entre leurs lectures sert de garde-fou : on ne retient un découpage que s'il tient sous trois angles différents.
Prototype 100% opérationnel en React, non branché sur le système live. Construit avec deux modes — un pilotage pour faire évoluer règles et données, un utilisateur pour rejouer les parcours. Rien n'est codé en dur ; les flux sont complets et le moteur accepte nativement les migrations du legacy.
Comment une décision propre — nettoyer le tableau des lits — a failli retirer au personnel sa marge de manœuvre, comment un module d'historique l'a sauvée, et comment cette même architecture a ouvert une fonction de santé publique qu'on ne cherchait pas.
Évidence informatique : un seul inventaire fiable des lits, on supprime les « lits fantômes » — ces entrées créées historiquement pour contourner les manquements du système. On nettoie, on standardise.
Sur le terrain, le personnel s'en sert comme amortisseur opérationnel : déplacer un patient pour corriger un dossier, absorber une urgence, compenser un manque système. Les supprimer revient à leur retirer une capacité de manœuvre déjà rare.
Un module d'historique dossier + mouvement préserve la flexibilité ET révèle un usage majeur : générer automatiquement la liste des patients-contacts sur tout un séjour, et tracer les chaînes de propagation virale. Une architecture data devient une fonction de santé publique.
Une décision design pure est devenue, par effet de levier, une capacité épidémiologique intégrée. La donnée modélisée pour protéger la flexibilité du personnel s'est révélée vitale pour la sécurité sanitaire.
On ne refait pas un
logiciel hospitalier.
On orchestre la donnée
autour du patient.
Refonte du dossier médical clinique électronique chez Lgi Healthcare Solutions, éditeur québécois de solutions logicielles pour le réseau de la santé. Objectif : réduire la charge cognitive des cliniciens et sécuriser la prise en charge patient en optimisant les trajectoires de soins numériques.
Mandat en cours, détail volontairement limité (NDA partiel).
Un dossier médical électronique ne se simplifie pas, il se réorganise. La complexité est absorbée par le système — auto-fill contextualisé, hiérarchie d'information stricte, raccourcis pour les 90 % d'actions les plus fréquentes — pas par le clinicien.
La conception démarre par une recherche utilisateur en environnement réel (médecins, infirmières) pour observer les workflows et les contournements existants, avant la moindre maquette. Méthode complète détaillée sur la page Méthode.
+62 % d'adoption clinique mesurée sur les modules refondus. Déploiement en cours sur le réseau hospitalier client.
Détail des métriques cliniques volontairement limité (NDA partiel).