Lorsque le code peut tuer ou guérir

Classé dans : Logiciel libre | 12

Temps de lecture 11 min

image_pdfimage_print

La technologie a fait faire à la santé d’extraordinaires progrès. Mais libre ou propriétaire  ? Dans le domaine des appareils médicaux pilotés par des logiciels ce choix peut avoir de très lourdes conséquences.

Ici plus qu’ailleurs, sacrifier l’humain sur l’autel du business model ne peut plus être une solution durable dans le temps[1].

Patrick - CC by-nc

Lorsque le code peut tuer ou guérir

When code can kill or cure

Technology Quarterly – 2 juin 2012 – The Economist
(Traduction  : balsamic, moala, Isammoc, Otourly, Mnyo, HgO, elquan)

Appliquer le modèle open source à la conception d’appareils médicaux permet d’accroitre la sécurité et stimule l’innovation.

Les pompes SMART délivrent des médicaments parfaitements dosés pour chaque patient. Des défibrilateurs faciles à utiliser peuvent ramener des victimes d’attaque cardiaque d’entre les morts. Les pacemakers et coeurs artificiels maintiennent les gens en vie en s’assurant que la circulation sanguine se déroule sans problème. Les appareils médicaux sont une merveille du monde moderne.

Alors que ces appareils sont devenus de plus en plus efficients, ils deviennent cependant de plus en plus complexes. Plus de la moitié des appareils médicaux vendus aux Etats-Unis (le plus grand marché de la santé) s’appuient sur du logiciel, et souvent en grande quantité. Ainsi le logiciel dans un pacemaker peut nécessiter plus de 80.000 lignes de code, une pompe à perfusion 170.000 lignes et un scanner à IRM (Imagerie à Résonance Magnétique) plus de 7 millions de lignes.

Cette dépendance grandissante vis à vis du logiciel cause des problèmes bien connus de tous ceux qui ont déjà utilisé un ordinateur  : bugs, plantages, et vulnérabilités face aux attaques. Les chercheurs de l’université de Patras en Grèce ont découvert qu’un appareil médical sur trois vendu aux États-Unis entre 1995 et 2005 a été rappelé pour défaillance du logiciel. Kevin Fu, professeur d’informatique à l’université du Massachusetts, estime que ce phénomène a affecté plus de 1,5 millions d’appareils individuels depuis 2002. En avril, les chercheurs de la firme de sécurité informatique McAfee ont annoncé avoir découvert un moyen pour détourner une pompe à insuline installée dans le corps d’un patient en injectant l’équivalent de 45 jours de traitement d’un seul coup. Enfin, en 2008, Dr Fu et ses collègues ont publié un article détaillant la reprogrammation à distance d’un défibrillateur implanté.

Or le disfonctionnement du logiciel d’un appareil médical a des conséquences beaucoup plus désastreuses que d’avoir seulement à faire redémarrer votre ordinateur. Durant les années 1980, un bug dans le logiciel des machines de radiothérapie Therac-25 a provoqué une overdose de radiations administrées à plusieurs patients, en tuant au moins cinq. L’Organisation américaine de l’alimentation et des médicaments, l’America’s Food and Drug Administration (FDA), s’est penchée sur le cas des pompes à perfusion qui ont causé près de 20.000 blessures graves et plus de 700 morts entre 2005 et 2009. Les erreurs logicielles étaient le problème le plus fréquemment cité. Si, par exemple, le programme buggé interprète plusieurs fois le même appui sur une touche, il peut administrer une surdose.

En plus des dysfonctionnements accidentels, les appareils médicaux sans fils ou connectés sont également vulnérables aux attaques de hackers malveillants. Dans le document de 2008 du Dr Fu et de ses collègues, il est prouvé qu’un défibrillateur automatique sous-cutané peut être reprogrammé à distance, bloquer une thérapie en cours, ou bien délivrer des chocs non attendus. Le Dr Fu explique que lors des phases de test de leur logiciel, les fabricants d’appareils manquent de culture de la sécurité, culture que l’on peut trouver dans d’autres industries à haut risque, telle que l’aéronautique. Insup Lee, professeur d’Informatique à l’Université de Pennsylvanie, confirme  : «  Beaucoup de fabricants n’ont pas l’expertise ou la volonté d’utiliser les mises à jour ou les nouveaux outils offerts par l’informatique  ».

Personne ne peut évaluer avec certitude l’étendue réelle des dégâts. Les logiciels utilisés dans la majorité des appareils médicaux sont propriétaires et fermés. Cela empêche les firmes rivales de copier le code d’une autre entreprise, ou simplement de vérifier des infractions à la propriété intellectuelle. Mais cela rend aussi la tâche plus ardue pour les experts en sécurité. La FDA, qui a le pouvoir de demander à voir le code source de chaque appareil qu’elle autorise sur le marché, ne le vérifie pas systématiquement, laissant aux constructeurs la liberté de valider leurs propres logiciels. Il y a deux ans, la FDA offrait gratuitement un logiciel «  d’analyse statique  » aux constructeurs de pompes à perfusion, dans l’espoir de réduire le nombre de morts et de blessés. Mais aucun constructeur n’a encore accepté l’offre de la FDA.

Ouvert à l’étude

Frustrés par le manque de coopération de la part des fabricants, certains chercheurs veulent maintenant rebooter l’industrie des appareils médicaux en utilisant les techniques et modèles open source. Dans les systèmes libres, le code source est librement partagé et peut être visionné et modifié par quiconque souhaitant savoir comment il fonctionne pour éventuellement en proposer une version améliorée. En exposant la conception à plusieurs mains et à plusieurs paires de yeux, la théorie veut que cela conduise à des produits plus sûrs. Ce qui semble bien être le cas pour les logiciels bureautiques, où les bugs et les failles de sécurité dans les applications open source sont bien souvent corrigés beaucoup plus rapidement que dans les programmes commerciaux propriétaires.

Le projet d’une pompe à perfusion générique et ouverte (Generic Infusion Pump), un effort conjoint de l’Université de Pennsylvanie et de la FDA, reconsidère ces appareils à problèmes depuis la base. Les chercheurs commencent non pas par construire l’appareil ou écrire du code, mais par imaginer tout ce qui peut potentiellement mal fonctionner dans une pompe à perfusion. Les fabricants sont appelés à participer, et ils sont plusieurs à le faire, notamment vTitan, une start-up basée aux Etats-Unis et en Inde «  Pour un nouveau fabricant, c’est un bon départ  » dit Peri Kasthuri, l’un de ses co-fondateurs. En travaillant ensemble sur une plateforme open source, les fabricants peuvent construire des produits plus sûrs pour tout le monde, tout en gardant la possibilité d’ajouter des fonctionnalités pour se différencier de leur concurrents.

Des modèles mathématiques de designs de pompes à perfusion (existantes ou originales) ont été testés vis à vis des dangers possibles, et les plus performantes ont été utilisées pour générer du code, qui a été installé dans une pompe à perfusion de seconde main achetée en ligne pour 20$. «  Mon rêve, dit Dave Arnez, un chercheur participant à ce projet, est qu’un hôpital puisse finalement imprimer une pompe à perfusion utilisant une machine à prototypage rapide, qu’il y télécharge le logiciel open source et que l’appareil fonctionne en quelques heures  ».

L’initiative Open Source Medical Device de l’université Wisconsin-Madison est d’ambition comparable. Deux physiciens médicaux (NdT : appelés radiophysiciens ou physiciens d’hôpital), Rock Mackie et Surendra Prajapati, conçoivent ainsi une machine combinant la radiothérapie avec la tomographie haute résolution par ordinateur, et la tomographie par émission de positron. Le but est de fournir, à faible coût, tout le nécessaire pour construire l’appareil à partir de zéro, en incluant les spécifications matérielles, le code source, les instructions d’assemblages, les pièces suggérées — et même des recommandations sur les lieux d’achat et les prix indicatifs. La machine devrait coûter environ le quart d’un scanner commercial, la rendant attractive pour les pays en voie de développement, déclare le Dr Prajapati. «  Les appareils existants sont coûteux, autant à l’achat qu’à la maintenance  » rappelle-t-il, là ou les modèles libres sont plus durables. «  Si vous pouvez le construire vous-même, vous pouvez le réparer vous-même.  »

Les appareils open source sont littéralement à la pointe de la science médicale. Un robot chirurgien open source nommé Raven, conçu à l’Université de Washington à Seattle fournit une plateforme d’expérimentation abordable aux chercheurs du monde entier en proposant de nouvelles techniques et technologies pour la chirurgie robotique.

Tous ces systèmes open source travaillent sur des problématiques diverses et variées de la médecine, mais ils ont tous un point commun  : ils sont encore tous interdit à l’utilisation sur des patients humains vivants. En effet, pour être utilisés dans des centres cliniques, les appareils open source doivent suivre les mêmes longues et coûteuses procédures d’approbation de la FDA que n’importe quel autre appareil médical. Les réglementations de la FDA n’imposent pas encore que les logiciels soient analysés contre les bugs, mais elles insistent sur le présence d’une documentation rigoureuse détaillant leur développement. Ce n’est pas toujours en adéquation avec la nature collaborative et souvent informelle du développement open source.

Le coût élevé de la certification a forcé quelques projets open source à but non lucratif à modifier leur business model. «  Dans les années 90, nous développions un excellent système de planning des traitements de radiothérapie et avions essayé de le donner aux autres cliniques, explique le Dr Mackie, mais lorsque la FDA nous a suggéré de faire approuver notre logiciel, l’hôpital n’a pas voulu nous financer.  » Il a fondé une société dérivée uniquement pour obtenir l’approbation de la FDA. Cela a pris quatre ans et a couté des millions de dollars. En conséquence, le logiciel a été vendu en tant qu’un traditionnel produit propriétaire fermé.

D’autres tentent de contourner totalement le système de régulation américain. Le robot chirurgical Raven (Corbeau) est destiné à la recherche sur les animaux et les cadavres, quant au scanner de l’Open Source Medical Device, il est conçu pour supporter des animaux de la taille des rats et des lapins. «  Néanmoins, déclare le Dr Mackie, rien n’empêche de reprendre le design et de lui faire passer les procédures de certification dans un autre pays. Il est tout à fait envisageable que l’appareil soit utilisé sur des humains dans d’autres parties du monde où la régulation est moins stricte, avance-t-il. Nous espérons que dans un tel cas de figure, il sera suffisamment bien conçu pour ne blesser personne.  »

Changer les règles

La FDA accepte progressivement l’ouverture. Le Programme d’interopérabilité des appareils médicaux Plug-and-Play, une initiative de 10 millions de dollars financé par le NIH (l’Institut National de la Santé) avec le support de la FDA, travaille à établir des standards ouverts pour interconnecter les appareils provenant de différents fabricants. Cela signifierait, par exemple, qu’un brassard de pression artérielle d’un certain fabricant pourrait commander à une pompe à perfusion d’un autre fabricant d’arrêter la délivrance de médicament s’il détecte que le patient souffre d’un effet indésirable.

Le framework de coordination des appareils médicaux (Medical Device Coordination Framework), en cours de développement par John Hatcliff à l’Université de l’État du Kansas, est plus intrigant encore. Il a pour but de construire une plateforme matérielle open source comprenant des éléments communs à beaucoup d’appareils médicaux, tels que les écrans, les boutons, les processeurs, les interfaces réseaux ainsi que les logiciels pour les piloter. En connectant différents capteurs ou actionneurs, ce cœur générique pourrait être transformé en des dizaines d’appareils médicaux différents, avec les fonctionnalités pertinentes programmées en tant qu’applications (ou apps) téléchargeables.

À terme, les appareils médicaux devraient évoluer vers des ensembles d’accessoires spécialisés (libres ou propriétaires), dont les composants primaires et les fonctionnalités de sécurité seraient gérés par une plateforme open source. La FDA travaille avec le Dr Hatcliff pour développer des processus de création et de validation des applications médicales critiques.

Dans le même temps, on tend à améliorer la sécurité globale et la fiabilité des logiciels dans les appareils médicaux. Le NIST (Institut national des États-Unis des normes et de la technologie) vient juste de recommander qu’une seule agence, probablement la FDA, soit responsable de l’approbation et de la vérification de la cyber-sécurité des appareils médicaux, et la FDA est en train de réévaluer ses capacités à gérer l’utilisation croissante de logiciels.

De tels changements ne peuvent plus attendre. «  Quand un avion s’écrase, les gens le remarquent  », dit le Dr Fu. «  Mais quand une ou deux personnes sont blessées par un appareil médical, ou même si des centaines sont blessées dans des régions différentes du pays, personne n’y fait attention.  » Avec des appareils plus complexes, des hackers plus actifs et des patients plus curieux et impliqués, ouvrir le cœur caché de la technologie médicale prend vraiment ici tout son sens.

Notes

[1] Crédit photo  : Patrick (Creative Commons By-Nc)

12 Responses

  1. vvillenave

    Cela m’évoque plusieurs affaires où des systèmes Microsoft ont été liés à des dysfonctionnements graves du système de santé américain : http://techrights.org/2009/05/03/wi

    Cependant, le droit d’auteur est une chose mais le problème majeur de l’accès aux soins est plutôt à chercher du côté des brevets, ce que dénonce le Parti Pirate depuis 2006 (mais il n’est pas le seul) : http://rixstep.com/2/1/20100103,00….

  2. Megagolgoth

    C’est une bonne tendance que l’open source, ou plutôt sa philosophie (plusieurs paires d’yeux sur le même sujet, impossibilité de cacher le code, et ses éventuelles vices) apparaissent dans la conception de systèmes critiques tel que ceux là.
    Néanmoins il faudrait relativiser « les fabricants d’appareils manquent de culture de la sécurité, culture que l’on peut trouver dans d’autres industries à haut risque, telle que l’aéronautique ». L’aéronautique a certe une culture de la sécurité mais l’appréciation du risque « au doigt mouillé » est monnaie courante.
    Le développement logiciel est quasiment tout le temps sous traité a des prestataires payés au lance pierre (code payé au mètre).

  3. Aucune Importance

    « Le développement logiciel est quasiment tout le temps sous traité a des prestataires payés au lance pierre (code payé au mètre). »

    Effectivement. Et c’est bien pour cela que, comme il est indiqué dans l’article, les logiciels dits « critiques » (pas besoin d’expliquer) doivent passer par une phase de certification / validation qui demande en autre de faire le preuve de la compétence du personnel utilisé, sous-traitants compris. Cela comporte une présentation complète de l’organigramme des équipés impliquées, des CVs des postes stratégiques, l’historique des projets précédents, etc

    L’aspect code ouvert ou fermé n’est en définitive que très marginal pour ce type de logiciel car les autorités responsables auront accès à tout (code, documentation, tests). Le code n’est fermé que pour le côté « client ».

    Le modèle open-source pour ce type de logiciel n’émergera qu’en limitant les contributions aux partenaires compétents. Ce sera une sorte de processus libre mais restreint à un cercle de contributeurs (qui auront un intérêt « métier »(*) à se coordonner).

    (*) « métier » et non pas strictement financier car dans ces domaines les intérêts purement économiques restent à la porte des phases de certification menées par des autorités indépendantes. À ce titre, la phrase d’introduction « Ici plus qu’ailleurs, sacrifier l’humain sur l’autel du business model ne peut plus être une solution durable dans le temps » est simplement débile. Cela n’a *jamais été* une solution durable.

    http://www.eyrolles.com/Informatiqu

  4. RSS_AFSSAPS

    ANSM : Agence nationale de sécurité du médicament et des produits de santé – (ex AFSSAPS)
    possèdent un flux RSS sur les dernières informations de sécurité. Et les soucis de matériel médicaux électroniques y reviennent régulièrement. Après je n’ai pas de comparaison pour en tirer des conclusions.
    http://ansm.sante.fr/syndication/rs

  5. Erwann

    Le développement de logiciel embarqué dans des dispositifs médicaux n’est pas « quasiment tout le temps sous traité ».
    Les fabricants sérieux de dispositifs médicaux sont tout à fait conscients des risques et de leur responsabilité. La réglementation les définit d’ailleurs comme pleinement responsables (accountable) même s’ils ont fait appel à des sous traitants.
    Il y a eu des accidents : Therac 25 aux USA, mais aussi de très nombreux incidents connus de radiothérapie en France.
    Le principe de contrôle par plusieurs intervenants est acté dans la réglementation. C’est d’ailleurs le principe même de l’Assurance Qualité en environnement réglementé.
    Le problème se situe à un autre niveau:
    1/ A ce jour, en Europe, les dispositifs médicaux et de diagnostiques ne requièrent aucune Autorisation de Mise sur le Marché (AMM) tandis que cela est un pré-requis pour le médicament. Une simple déclaration du fabricant du dispositif suffit, qui concerne tout à le fois la qualité et l’efficacité du dispositif.
    2/ L’ANSM (ex-AFSSAPS) tout comme les autres Agences réglementaires en Europe ne dispose pas d’un véritable corps d’ingénieur-inspecteur. En France, comme dans de nombreux autres pays, les inspecteurs sont des pharmaciens.

    Quelque soit les imperfections du système actuel, la fonction de Matério-Vigilance est assurée avec sérieux tant par les Agences que par les prescripteurs et les fabricants. Il y a toujours des « moutons noirs », mais il y aussi beaucoup d’entreprises et d’intervenants qui prennent leur rôles et leurs responsabilités au sérieux.

  6. Ginko

    @Erwann,

    joli double langage… tu appartiens à un lobbie des fabricants de matériel médical ?

    Non, on ne peut pas faire confiance à des organismes à but de profit pour se contrôler eux-mêmes. On appelle ça être juge et parti.

    Alors oui, il y a toujours des gens pour être responsables et faire du bon travail. Mais ça ne me suffit en aucun cas pour moi, patient, que : « la plupart du temps, les fabricants sont consciencieux ». Je veux qu’un organisme externe contrôle la production, qui ne soit pas lui-même financé par l’industrie et qui ne soit pas composé de gens de la filière.

  7. Aucune Importance

    @Ginko : « joli double langage… tu appartiens à un lobbie des fabricants de matériel médical ? »

    Et voilà, quelqu’un remet les choses dans leur contexte et il est nécessairement à la solde de … !? On ne va pas aller bien loin comme ça.

    Pour information, relativement au titre du billet (toujours dans la subtilité framablog hein), il ne me semble pas qu’il y ait de mort d’homme reconnue comme ayant été _directement_ causé par un défaut logiciel. Même dans l’accident du Therac25, il n’y a pas eu de mort mais « simplement » des brûlures.

    Si quelqu’un trouve un contre-exemple (donc mort(s) de personne(s) « juridiquement » attribuée(s) à un défaut logiciel), je suis preneur.

  8. Ginko

    @Aucune Importance,

    Ben relis son message : il y dit la chose et son contraire.

    >A ce jour, en Europe, les dispositifs médicaux et de diagnostiques ne requièrent aucune Autorisation de Mise sur le Marché (AMM) tandis que cela est un pré-requis pour le médicament. Une simple déclaration du fabricant du dispositif suffit, qui concerne tout à le fois la qualité et l’efficacité du dispositif.

    Je suis un consommateur pas totalement lobotomisé, je me dit « il y a un problème dans ce système, les industriels sont juges et parti ».

    >Quelque soit les imperfections du système actuel, la fonction de Matério-Vigilance est assurée avec sérieux tant par les Agences que par les prescripteurs et les fabricants. Il y a toujours des « moutons noirs », mais il y aussi beaucoup d’entreprises et d’intervenants qui prennent leur rôles et leurs responsabilités au sérieux.

    Ah, ils sont sérieux ! Très bien, je te crois sur parole.

    Son discours est du type enfumage, celui qu’affectionnent les lobbies.

    Ce n’est pas « remet[tre] les choses dans leur contexte », c’est juste composer l’argument d’autorité en faisant mine de parler avec mesure, sérieux et jargon. Mais ça reste de la rhétorique et rien de plus.

  9. Erwann

    Même si je comprends le désarroi de certains, je reste malgré tout quelque peu choqué par le déni de « conscience professionnelle ».
    Que les choses soient claires, je ne suis pas un lobbyiste des industries de santé. En revanche, c’est un milieu que je connais pour y avoir travaillé et pour conseiller les entreprises de ce secteur depuis de nombreuses années sur tous les aspects liés à la conformité réglementaire des systèmes.
    A titre personnel, je ne suis pas du tout satisfait du cadre réglementaire européen concernant les dispositifs médicaux. A mon sens, il devrait y avoir convergence avec la réglementation du médicament ; selon les types de dispositifs médicaux : nécessité d’études cliniques, d’évaluation et d’une autorisation formelle de mise sur le marché. L’industrie pharmaceutique connait le rôle de « Qualified Person » (QP) – en France le « Pharmacien Responsable » – qui répond à titre personnel de la qualité des produits mis sur le marché.
    Ce rôle n’existe pas aujourd’hui pour les dispositifs médicaux. Personnellement, selon de type de dispositif, il devrait exister un « Pharmacien responsable » ou un « Ingénieur responsable » qui tiendrait le rôle de « Qualified Person ».
    Lorsque je mentionne la « conscience professionnelle » des équipes de développement et de production, ce n’est pas un vain mot ; même s’il existe des incapables et des escrocs. La grande majorité des ingénieurs de développement logiciel pour les industries de santé sont des personnes consciencieuses. Nous savons que notre travail impacte directement ou indirectement la santé du patient. Le cadre réglementaire et les gardes-fous qu’il représente sont justement faits pour établir des contrôles cohérents quant à la qualité des produits. Dans l’industrie pharmaceutique, ce sont les agences réglementaires qui viennent inspecter régulièrement les processus de développement, de production et de contrôle.
    Le problème actuel des dispositifs médicaux – mis en lumière par le scandale PIP (implant mammaire) – tient au fait que les principaux contrôles ne sont pas faits par les agences réglementaires mais par des organismes certificateurs payés par l’entreprise inspectée. De même que les certificats de navigabilité de certains navires sont parfois douteux (cf. Erika), de même les certificats de « conformité » peuvent, selon les organismes, être « légers » (cf. PIP).

    J’ai mentionné dans mon message précédent les accidents liés au Therac 25 (USA, années 80). Oui ! Il y a eu des morts. Lorsqu’un patient est transpercé (trou) par un rayonnement ionisant, je ne parle plus d’une « simple brûlure » mais bien d’un accident ayant entrainé la mort.
    En France, au cours de ces 10 dernières années, nous avons un bien triste palmarès en ce qui concerne les accidents de radio-thérapie : Grenoble, Lyon, Toulouse, Epinal (en l’occurrence près de 3’000 patients sur-irradiés dont certains ont à souffrir de séquelles irréversibles).
    Donc, OUI ! un logiciel mal écrit, mal conçu, mal testé, mis en oeuvre de manière inappropriée peut tuer.
    Un équipement de diagnostique qui ne permet pas de constater l’existence d’une maladie ou d’une infection peut indirectement tuer le patient, car les mesures thérapeutiques ne pourront pas être mises en oeuvre.
    Une pompe d’insuline ne fonctionnant pas correctement, un pacemaker buggé peuvent tuer.
    Un équipement d’analyse biomédicale – par exemple détection de marqueurs infectieux (sida, hépatite, etc) – inversant des résultats suite à un défaut logiciel peut indirectement tuer.

    PS: Il ne me semblait pas avoir utilisé de « jargon » dans mon message précédent. Le terme de « matério-vigilance » est l’équivalent pour les dispositifs médicaux à la « pharmaco-vigilance » pour les médicaments. Cela correspond à suivre ce qu’il se passe sur le marché, à rapporter tout effet indésirable et, le cas échéant, à initier un rappel du produit.
    Cette « vigilance » n’est pas seulement nationale. Les Agences réglementaires de chaque pays coopèrent de manière toujours plus étroite et les fabricants ont obligation d’avertir les autorités des pays concernés. Cette fonction est essentielle pour assurer la sécurité du patient et je ne peux que vous encourager à aller sur le site de l’ANSM pour consulter les (voire vous abonner aux) messages d’alerte. Vous pourrez constater que de très nombreux messages sont d’abord issus des fabricants eux-mêmes.

    Je comprends que l’on puisse se poser des questions. En revanche, je trouve indigne les réactions du type « tous pourris » sans rien connaître au secteur concerné. Avant de critiquer, il faut se renseigner. Je pense d’ailleurs que les médias ne font pas leur travail d’information et « d’éducation ».

  10. Ginko

    @Erwann,

    Tout d’abord merci pour cette réponse.

    Par rapport au « jargon », même si je suis d’accord sur le fait que ce son bien des mots qui ont un sens précis et qu’il serait sans doute stupide de les changer rien que pour ne pas « jargonner », tu utilises tout de même des termes spécifiques à ton domaine. (Ce qui peut être dans certains cas utilisé pour créer l’autorité (dans le sens argument d’autorité)).

    Ensuite, ne te connaissant pas, et avec juste ton premier message qui reste tout de même ambigu (mêlant les constats négatifs à des appréciations positives), je maintiens qu’il peut passer pour une tentative de « manipuler l’opinion ».

    Par contre, avec ta réponse, je ne maintiens évidemment pas cette accusation 😉

    Reste que même dans le cas hypothétique où chaque ingénieur intervenant dans la chaine de conception/qualité des ce matériel est consciencieux, ça ne signifie absolument pas que le produit final soit réellement sur.

    En effet, le but d’une entreprise reste le profit. Dès lors, des impératifs budgétaires peuvent venir déranger cette conscience professionnelle. Lorsque votre hiérarchie insinue que si vous êtes trop minutieux dans vos test, vous pourriez « louper une augmentation »… ou bien que vous même vous auto-restreignez car « ça pourrait être mal vu », etc… il est bien difficile d’incriminer quelqu’un en particulier. De même il s’agit parfois de quiproquo ou d’un flou sur les responsabilités. C’est le collectif qui s’exprime. Les erreurs arrivent bien souvent comme cela.

    Bref, dans les domaines de la santé et de l’alimentaire, il me semble qu’un contrôle externe et indépendant (le plus possible) est nécessaire. Toute la bonne volonté du monde ne suffirait pas à me rassurer tant qu’il s’agit de se contenter de contrôles « internes », basés sur la confiance que je devrais donner à des acteurs purement économiques.

    >En revanche, je trouve indigne les réactions du type « tous pourris » sans rien connaître au secteur concerné.

    Je ne dis pas « tous pourris », je dis qu’en matière de confiance à donner à des acteurs économiques, il faut partir du principe que ceux-ci sont « mauvais », et ce, pour de multiples raisons (pas forcément volontaires ! : erreur humaine, contrainte économique, négligence, etc). Ce n’est nullement une attaque contre les gens eux-même, mais contre les organisations que sont les producteurs de matériel. Il s’agit de prévention des risques dans un domaine critique.

    >Avant de critiquer, il faut se renseigner. Je pense d’ailleurs que les médias ne font pas leur travail d’information et « d’éducation ».

    Les médias mainstream font leur travaille de propagande. L’éducation nationale elle-même, en partie, est intégrée dans la grande machine de propagande.

    J’avoue ne pas avoir spécialement travaillé le sujet. Cependant, si ça peut te rassurer, je ne me fie pas aux médias pour me renseigner. Ici, je prends seulement la posture d’un « consommateur/patient lambda » qui s’inquiète un minimum des conditions de production d’outils médicaux qui pourraient le blesser ou le tuer.

  11. Erwann

    @Ginko: merci pour le dernier message.
    Le principe de l’Assurance Qualité (du moins au sein du secteur réglementé de la santé) est de permettre un accompagnement et un contrôle indépendant (même si c’est au sein de la même entreprise) des département chargés de l’évaluation, de la production, de la distribution et de la vigilance.
    Je ne pense pas que faire appel à des agences extérieures pour effectuer ces contrôles serait plus efficace. En tout état de cause, cela serait au final beaucoup plus coûteux pour le patient/consommateur.
    Aux USA, lorsqu’une entreprise pharmaceutique prouve son incapacité à satisfaire aux exigences réglementaires, la FDA peut devoir assurer « temporairement » cette fonction d’Assurance Qualité : c’est ce que l’on appelle le « concent decree » – on pourrait dire en Français « mise sous tutelle ».
    Une telle pratique est très coûteuse et n’est pas plus efficace qu’un service interne d’Assurance Qualité performant.
    Depuis 2003, les Agences réglementaires acceptent une approche de la Qualité basée sur la « Gestion du Risque Qualité ». Il existe un document de référence harmonisé (USA, Europe, Japon) qui propose une démarche pour une telle gestion du risque (ICH Q9).
    Lorsque tous les intervenants – de la conception jusqu’à la vigilance, y compris la fabrication et la distribution – font correctement leur travail, cette gestion du risque est un excellent outil qui contribue largement à rendre les médicaments plus sûrs. Ce texte de référence est dérivé des normes ISO de gestion du risque (en particulier 14971 ; mais aussi 13485, 62304, …) pour les dispositifs médicaux qui sont contraignantes depuis plus de 10 ans.

    @hasard: les deux articles sont intéressants mais ils soulèvent malgré tout quelques questions:
    – Dans l’environnement particulier du secteur réglementé de la santé, un logiciel ouvert est-il intrinsèquement plus sûr ?
    – Comment financer le développement de nouveaux équipements si tout devait être en « accès libre » ?

    Par exemple: le développement de l’échographie en 3D est une réelle avancée pour les médecins, mais elle a nécessité des investissements conséquents en termes de R&D.
    L’industrie a pu développer de tels équipements parce que les entreprises avaient de l’argent et étaient en mesure d’en gagner. La pression concurrentielle (être plus vite meilleurs que ces compétiteurs) a fait le reste pour ce qui est d’accélérer les développements.
    Bien qu’étant tout à fait favorable aux FLOSS (depuis 1989), il me faut constater qu’aucune entreprise ne peut être viable si elle n’est pas en mesure de gagner de l’argent.

    Il y a de très nombreuses discussions concernant les très contestables « droits d’auteur » et autres brevets logiciels. Il est évident qu’une remise à plat doit avoir lieu et qu’une protection raisonnable des efforts de R&D doit être possible. Il n’existe pour moi aucune justification pour breveter des « évidences » (un clic, un lien, etc.). En revanche, il ne me semble pas indécent de protéger les efforts de R&D.
    Intellectuellement et philosophiquement, une pompe à insuline « open source » est un concept séduisant. Néanmoins, une pompe à insuline ne se réduit pas seulement à un « bout de code » ! L’ensemble de l’équipement matériel doit être fiable, performant et sûr. Cette fiabilité a un coût (matériel et tests associés).

    PS: J’ai conscience en écrivant ces lignes que certains vont « crier au lobbyiste ». Pourtant, je ne suis qu’un ingénieur indépendant qui essaie de vivre (non sans une certaine générosité) de son savoir, de ses connaissances et de ses compétences : ni plus, ni moins !