Réalisation d’un logiciel médical, de la conception au produit
Je conçois et je réalise votre logiciel de dispositif médical, avec une équipe que je constitue et que je dirige, jusqu’à un produit qui tient devant l’usage clinique et devant le dossier.
Ce que je conçois et réalise
Le point de départ varie. Parfois c’est une page blanche et un besoin clinique bien identifié. Souvent c’est un prototype de recherche qui fonctionne en démonstration, entre les mains de son auteur, et qui ne survivra pas au premier utilisateur réel ni à la première question d’un évaluateur. Je prends la conception d’ensemble : ce que fait le logiciel, ce qu’il ne fera pas, comment il se découpe en éléments, où passent les frontières avec le dispositif, avec le système d’information hospitalier et avec les traitements les plus sensibles. Puis la réalisation : le back‑end, les traitements d’images ou les modèles d’apprentissage quand le produit en dépend, les interfaces d’utilisation, l’intégration et la chaîne de livraison. Les choix techniques suivent le besoin, jamais l’inverse. Un logiciel de classe de sécurité élevée impose une discipline de vérification qu’une fonction de confort ne justifie pas ; à l’inverse, sur-contraindre un module secondaire consomme un temps qui manquera là où le risque est réel. Une bonne architecture de logiciel médical, c’est d’abord une bonne répartition de la contrainte.
L’équipe, constituée et dirigée
Je n’arrive pas seul avec un forfait et une équipe anonyme derrière. Selon votre situation, je dirige vos développeurs, je constitue une équipe autour d’eux, ou je monte une équipe complète pour la durée du projet. Recruter pour le médical demande un tri particulier. Le niveau d’ingénierie ne suffit pas : il faut des personnes qui acceptent qu’une fonctionnalité soit spécifiée, tracée, vérifiée et documentée avant d’être considérée comme faite, et qui ne vivent pas cette exigence comme une brimade. C’est autant une question de tempérament que de compétence, et cela se détecte en entretien quand on sait quoi chercher. Une fois l’équipe en place, je la dirige comme un CTO dirige la sienne : revues de conception, relecture de code, rituels courts, décisions écrites. Vous avez un interlocuteur unique et un accès direct à ce qui se passe — dépôt de code, suivi des tâches, avancement réel plutôt que rapport d’avancement. Je n’ai jamais vu un projet médical se dégrader parce que le client en savait trop ; l’inverse, en revanche, arrive constamment.
La conformité, intégrée dès la première ligne
La conformité n’est pas une phase finale. Elle est soit construite dans le produit, soit reconstituée à la fin — et reconstituer coûte toujours plus cher que construire, en argent comme en crédibilité. Concrètement, les exigences vivent dans un système relié aux tests et aux risques, pas dans un tableur mis à jour la veille d’une revue. Le cycle de vie logiciel de l’IEC 62304 est appliqué au rythme du développement : planification, spécification, conception détaillée pour les éléments qui l’exigent, vérification et gestion des versions. L’analyse des risques au sens de l’ISO 14971 avance avec la conception et redescend en exigences vérifiables, ce qui est sa seule utilité réelle ; une analyse de risques qui ne change jamais le logiciel n’est qu’un document. Les logiciels d’origine non maîtrisée sont identifiés, justifiés et suivis dès leur introduction, parce que les découvrir tard est une des façons les plus sûres de perdre un trimestre. Je ne promets ni délai d’évaluation ni résultat auprès d’un organisme notifié : cela ne dépend pas de moi seul. Je m’engage sur la qualité du dossier que vous présenterez et sur sa cohérence avec le logiciel réellement livré.
Le transfert vers vos équipes
Un logiciel de dispositif médical vit longtemps après sa première mise sur le marché. Corrections, évolutions, changement de version d’un composant tiers, surveillance après commercialisation : tout cela retombe sur quelqu’un. Le projet doit être conçu pour ce quelqu’un, dès le premier jour. Je documente donc pour l’équipe qui reprendra, pas pour l’auditeur. Les décisions d’architecture sont écrites avec leurs raisons et leurs alternatives écartées, l’environnement de développement se reconstruit à partir du dépôt, la chaîne de construction et de test est reproductible d’une machine à l’autre. Le transfert lui-même se fait en recouvrement : vos développeurs travaillent sur le produit pendant que mon équipe est encore là, avec des tâches réelles et non un tutoriel. C’est le seul moyen de vérifier que le passage de relais fonctionne pendant qu’il est encore possible de le corriger. Si vous n’avez pas encore d’équipe interne, la sortie s’organise autrement : recrutement accompagné pendant le projet, ou maintien d’une partie de l’équipe sous votre contrat. Nous en parlons au cadrage, pas à la livraison.
Parlons de votre produit
Un pair crédible, en comité de direction comme au bloc.