Il me semble que beaucoup d'idées et d'opinions sont mélangées de telles manières à ce que l'ensemble de la discussion devienne stérile.

1/ Je comprends les questions de Karen, qui sont d'ailleurs tout à fait légitimes. Pour ma part, j'ai posé des questions similaires à mon concessionnaire, lorsque j'ai eu ma première "soft car".

2/ Je suis tout à fait d'accord sur le fait que le nombre de paires d'yeux n'est pas gage de la capacité à trouver les erreurs dans le code.

3/ Karen pointe un vrai problème de certification des dispositifs médicaux. Même avec une réglementation un peu plus stricte aux USA qu'en Europe, le manque de compétence technique des évaluateurs et des inspecteurs représente un véritable problème.

4/ Je reste quelque peu utopiste, mais la plupart des personnes impliquées dans le développement de systèmes embarqués pour des dispositifs médicaux sont des personnes consciencieuses qui ont parfaitement intégré le fait qu'un bug peut, le cas échéant, tuer.

5/ Les bugs "historiques" mentionnés par les uns et les autres sont d'abord le fait de vraies faiblesses d'ingénierie système avant d'être des problèmes logiciels. Les Bonnes Pratiques d'Ingénierie ne peuvent être mises en oeuvre avec succès sans une solide gestion du risque.

5a/ Therac 25: défaut d'ergonomie du logiciel, défaut de conception du logiciel du fait qu'une protection matérielle avait été supprimée. Absence d'une gestion du risque pertinente.

5b/ Ariane Vol 501: défaut de conception et absence de test (pas besoin de tester puisque cela marche déjà sur Ariane 4), gestion du risque inadéquate. Le domaine d'utilisation du code ayant changé, il était nécessaire de répéter des tests aux limites, selon les nouvelles limites induites par le nouveau domaine de vol.

5c/ Mariner: défaut d'intégrité logicielle. Une gestion du risque des procédures de chargement des programmes et de l'initialisation du système aurait très probablement permis d'éviter un tel défaut.

5d/ Mars Climate Obiter (non cité): défaut de conception, référentiel d'ingénierie incohérent (impérial vs. métrique), tests d'intégration logicielle insuffisant voire absent. Gestion du risque projet insuffisante.

Pour en revenir au problème soulevé par Karen:
a/ Oui, cela doit être angoissant de se faire poser un appareil vital dont on ne comprend pas le fonctionnement. Pourtant, je ne suis pas sûr que la solution se situe dans l'ouverture du code. De plus, le code représente la véritable valeur ajoutée du dispositif. Si le code n'est plus protégé, il est à craindre qu'il n'y ait plus de recherche et développement et par voie de conséquence plus d'innovation dans ce domaine.

b/ Comme pour tout système, en particulier pour les systèmes embarqués, il est nécessaire d'avoir des processus d'ingénierie établis, matures et maîtrisés. La conception de système embarqué ne s'improvise pas, une gestion pertinente du risque est indispensable, les différentes batteries de tests - revue de code, tests unitaires, tests d'intégration, tests de régression, tests de stress, etc - sont des outils cruciaux pour délivrer des dispositifs fiables (cf. GAMP 5 et le Good Practice Guide concernant les tests de systèmes GxP, version 2 en cours de publication).

c/ Karen mentionne aussi les problèmes de cyber-sécurité. Ces problèmes sont systématiquement sous-estimés par tous les intervenants. Le comportement des banques déployant la technologie NFC sans aucun scrupule en est le meilleur exemple. A ma connaissance, il y a un groupe de travail / de réflexion à la FDA sur cette thématique. En revanche, je n'ai aucune idée de ce que seront les résultats de ces réflexions. Je suis aussi tout à fait d'accord sur le principe que l'obscurantisme n'est en aucun cas une protection contre des accès indésirables.

En conclusion
- Quoique l'on vous dise, il est indispensable d'être "parano" lorsque l'on est en charge de l'intégrité des systèmes ou des données. Les plus grands problèmes découlent la plupart du temps d'un amateurisme naïf, voire minimaliste.

- Lorsque l'on demande d'écrire des spécifications, il ne faut pas rechigner, ni crier à l'injustice (pourquoi moi?), mais il faut réaliser ce travail d'élaboration et de revue des spécifications avec exactitude et de la manière la plus complète et la plus cohérente possible. Cela prend du temps, cela demande de l'acharnement, mais c'est à mon humble avis la seule garantie significative pour d'avoir un code fiable et maintenable.

---
PS: je suis tout à fait favorable au logiciel libre et à l'ouverture du code source. Néanmoins, je ne suis pas persuadé que l'ouverture du code soit la seule et unique approche possible pour améliorer la qualité et la fiabilité des dispositifs médicaux.
Il ne faut pas non plus oublier qu'il existe des processus obligatoires de matério-vigilance qui servent à assurer une amélioration continue des dispositifs.
N'hésitez pas à vous abonner aux messages de l'ANSM, c'est une information libre.
--