Réflexions
Passer de l’idée au terrain
Comment tester une idée de logiciel de santé sur un cas réel avant de décider quoi construire.
Quand une idée de logiciel me plaît, j’ai vite envie de voir à quoi elle pourrait ressembler. Mon réflexe de développeuse, c’est de commencer à construire. Celui que j’ai acquis avec l’expérience, c’est de demander à voir comment les gens se débrouillent déjà.
Dans les logiciels de santé, une idée peut paraître évidente en réunion et se heurter à un détail très concret le lendemain. Pour le découvrir, je préfère partir d’un épisode de travail récent, avec les personnes et les outils concernés. Voici comment je m’y prendrais.
01
Suivre un cas réel
Si une équipe veut automatiser la traçabilité de ses changements produit, je lui demanderais de reprendre le dernier changement qui a nécessité une revue. Où la demande est-elle apparue ? Qui a retrouvé les exigences concernées ? À quel moment a-t-il fallu ouvrir un autre outil ou demander de l’aide ?
En regardant les tickets, les tests et les documents ensemble, on peut découvrir que les liens existent déjà mais qu’ils sont difficiles à retrouver. On peut aussi découvrir qu’une décision n’a jamais été consignée. Ces deux constats conduisent à des interventions différentes.
02
Réduire l’idée à une hypothèse
Imaginons que les liens existent, mais que leur recherche soit laborieuse. Mon hypothèse serait qu’une vue qui rassemble les exigences, les risques et les tests liés à un changement aide l’équipe à préparer sa revue plus facilement.
Avant de développer une intégration, je préparerais cette vue à la main pour un cas anonymisé. Je demanderais ensuite à une personne qui prépare la revue de s’en servir pour repérer les éléments à réexaminer. Je regarderais ce qu’elle trouve, ce qu’elle doit encore vérifier et les informations qu’elle cherche ailleurs.
03
Décider à partir de ce que l’essai montre
Je définirais à l’avance ce qui me ferait poursuivre. Par exemple, l’équipe retrouve les éléments pertinents avec moins d’allers-retours et sait vérifier d’où viennent les informations. Je chercherais aussi ce qui me ferait changer d’idée. Si la vue est utile mais que personne ne peut tenir les liens à jour, il faut comprendre ce travail de maintenance avant d’automatiser.
Ensuite, je referais l’essai sur un deuxième changement. Si le même besoin revient, on a une raison d’investir dans une première version. Si le problème change d’un cas à l’autre, on a appris où concentrer le prochain essai.
04
Ce que j’aime apporter à ce moment-là
J’aime réunir les personnes qui vivent le problème, rendre l’hypothèse assez précise pour qu’on puisse la tester et aider l’équipe à choisir la suite. Mon parcours en logiciel, en qualité et en réglementation m’aide à voir ce qui manque entre un prototype séduisant et un outil que quelqu’un peut réellement utiliser dans son travail.
Un premier essai peut déboucher sur une fonctionnalité, une règle de travail plus claire ou une idée qu’on laisse de côté. Dans les trois cas, l’équipe dispose d’éléments concrets pour décider où mettre son temps.
