Audit technique et réglementaire de votre logiciel médical
Un regard extérieur d’ingénieur sur votre logiciel et sur son dossier : ce qui tient, ce qui ne tiendra pas devant l’organisme notifié, et dans quel ordre le reprendre.
Ce que je regarde
Un audit utile porte sur trois plans à la fois, parce que les défaillances du logiciel médical se logent presque toujours à leur jonction. Le logiciel lui-même : architecture, découpage en éléments, dépendances externes et logiciels d’origine non maîtrisée, qualité et couverture des tests, chaîne de construction et de livraison, gestion des versions. Je lis le code. Un audit qui se contente d’entretiens produit un rapport qui reflète ce que l’équipe croit avoir fait, ce qui n’est presque jamais ce qui est livré. Le dossier ensuite : plan de développement logiciel, spécification des exigences, matrice de traçabilité entre exigences, tests et risques, analyse des risques au sens de l’ISO 14971, classification de sécurité des éléments logiciels et sa justification. La question n’est pas de savoir si les documents existent, mais s’ils décrivent le logiciel réellement livré ou une version idéalisée qui n’a jamais tourné. L’organisation enfin : qui décide, qui vérifie, comment une modification traverse le processus, et si le système qualité est vécu ou reconstitué avant chaque audit. Un écart de processus se répare ; un système qualité que personne n’applique se paie beaucoup plus cher, et toujours au pire moment.
Comment se déroule l’audit
L’audit commence par un cadrage : ce qui entre dans le périmètre, ce qui n’y entre pas, et ce que vous cherchez réellement à savoir. Préparer une première évaluation, reprendre un logiciel hérité d’une acquisition ou éclairer un investisseur ne demandent pas le même angle d’attaque, et un audit qui prétend répondre aux trois à la fois ne répond bien à aucun. Vient ensuite l’accès à la matière : dépôt de code, documentation, système qualité, outillage de suivi des exigences et des anomalies. Puis des entretiens courts avec les personnes qui font le travail — développeurs, qualité, affaires réglementaires, produit — menés séparément. Les écarts les plus instructifs apparaissent quand deux interlocuteurs décrivent différemment le même processus. Je restitue à l’oral avant d’écrire. Cela évite les deux travers classiques du rapport d’audit : la surprise en réunion de direction, et le constat juste posé sur une hypothèse fausse que personne n’a corrigée à temps. Le rapport écrit vient ensuite. Il est rédigé pour être lu par votre comité de direction autant que par vos développeurs : chaque écart y est nommé, situé, expliqué dans ses conséquences, et associé à une reprise possible.
Ce que vous en retirez
Trois choses. Une cartographie honnête des écarts d’abord, classés par gravité réelle et non par ordre d’apparition dans la norme. Tout écart n’a pas le même poids : une traçabilité incomplète bloque une évaluation, une convention de nommage discutable ne bloque rien du tout, et confondre les deux fait perdre un temps considérable à des équipes déjà sous tension. Un chemin ensuite. Pour chaque écart, ce qu’il faut faire, dans quel ordre, et ce qui doit impérativement être traité avant de soumettre. C’est la partie que les audits purement réglementaires laissent souvent de côté : ils constatent la non-conformité sans dire ce qu’elle implique dans le code, dans les tests et dans le planning de vos équipes. Un langage commun enfin. Après l’audit, votre direction, votre qualité et vos développeurs parlent du même produit avec les mêmes mots et la même hiérarchie de priorités. C’est moins spectaculaire qu’une liste d’écarts, et c’est souvent ce qui débloque réellement la situation. Je ne délivre aucune certification et je ne me substitue à aucun organisme notifié : je vous dis ce que je vois, avec la lecture d’un ingénieur qui a déjà mené des logiciels médicaux jusqu’au marché.
Ce qu’un audit ne remplace pas
Un audit n’est pas une mise en conformité. Il donne une image et une trajectoire ; le travail de reprise reste entier, et il se compte en ingénierie, pas en corrections documentaires. Se le dire au départ évite la déception classique du rapport rangé dans un dossier partagé et jamais rouvert. Un audit ne remplace pas davantage votre système de management de la qualité, votre évaluation clinique, ni le travail de votre organisme notifié. Il éclaire la partie logicielle, qui est celle où les écarts se découvrent le plus tard et coûtent le plus cher, parce qu’elle est la seule dont personne à la table ne peut vérifier les affirmations sans ouvrir le code. Enfin, un audit ne vaut que si vous acceptez d’entendre ce qui ne va pas. Je n’écris pas de rapport de complaisance : si le constat est que l’architecture ne portera pas la classe de sécurité visée, c’est ce qui sera écrit, avec ce que cela implique. Si la reprise vous intéresse, elle relève de la mission de transition ou de la réalisation produit. L’audit reste indépendant de cette suite : rien ne vous engage à me la confier.
Parlons de votre produit
Un pair crédible, en comité de direction comme au bloc.