Vous êtes dans : Accueil > Dossiers SIH > Sécurité des SI

Pour en finir avec les failles logicielles

DSIH, publié dans le DSIH N°9 - Avril 2013

Les bugs logiciels sont inévitables… et coûteux, voire dangereux pour les patients. Comment en améliorer la détection et la correction ? Début de réponses avec les 4 experts réunis par DSIH.

Propos recueillis par Delphine Guilgot

 

« Si l’on veut éviter un « Mediator électronique », il faut tester, tester et encore tester »

 

DSIH : La FEHAP alerte les pouvoirs publics, depuis quelque temps déjà, sur les dangers des bugs informatiques. Quel est le problème ?

 

Jean-François Goglin : Hormis pour quelques éditeurs qui ont instauré des phases de tests industrielles avancées, les tests mis en place sur les logiciels du marché sont insuffisants. Le fond du problème tient à l’évolution rapide des contraintes règlementaires : DMP compatibilité, FIDES, CSARR[2], prérequis Hôpital numérique… Les éditeurs n’arrivent plus à suivre le rythme. Lorsqu’ils répondent à un appel d’offres, il leur est difficile d’avouer que le logiciel demandé ne pourra être complètement livré et testé dans les délais impartis.

 

Bernard D’Oriano : Le législateur est en cause, pris par une frénésie de demandes plus urgentes les unes que les autres. Les parlementaires ne pensent pas aux conséquences opérationnelles de leurs décisions en chambre. Échec ou délais non tenus pour le DMP, Hôpital numérique, modification de nomenclatures et des tarifs, PMSI… on voit aujourd’hui le résultat !

 

Dominique Gougerot : Aujourd’hui, par exemple, il nous est demandé de reprendre toute la philosophie du PMSI SSR dans des délais plus que serrés. Inutile ensuite d’exiger des procédures de tests approfondies !

 

Germain Zimmerlé : De fait, les fournisseurs s’engagent trop souvent sur des délais, alors que le produit n’existe pas. C’est là que commencent les problèmes. Ils n’ont évidemment plus le temps de développer correctement. Il en résulte que les logiciels de production de soins, déjà intrinsèquement complexes, sont souvent immatures.

 

J.-F. G. : D’ailleurs, pour les éditeurs qui tiendraient un discours honnête, l’appel d’offres serait perdu d’avance.

 

DSIH : Cela signifie-t-il que les établissements ont leur part de responsabilité dans cette course au délai ?

 

J.-F. G. : Oui et non. La première responsabilité concerne l’État, qui doit négocier des délais réalistes avec les éditeurs. Bien souvent, les établissements n’ont pas une connaissance fine de ces problématiques de tests et des complications qui vont en découler, d’où un nombre important de litiges avec les éditeurs. À leur décharge, les établissements cherchent souvent le mouton à 5 pattes : une solution mature, avec des développements spécifiques. Ces développements spécifiques sont à éviter et des consignes claires devraient être données par la puissance publique. Ils sont bien souvent le signe de lacunes dans le cahier des charges ou d’un mauvais choix de prestataires.

 

D. G. : Il serait souhaitable que les formations à l’EHESP insistent sur ce point.

 

G. Z. : Les professionnels de santé doivent en effet évoluer d’une « culture du sur-mesure » pour aller vers « la confection ». Mais utiliser un seul logiciel de dossier patient par établissement est impensable, surtout pour les gros hôpitaux, qui ont de multiples spécialités. Le logiciel unique idéal n’existe pas. Au mieux, il répondra à 70 voire 80 % de la demande. Les logiciels de spécialités restent indispensables pour certaines disciplines, comme la néphrologie, la réanimation, ou la gynécologie-obstétrique.

 

DSIH : Ces failles logicielles ne sont pas une nouveauté. Pourquoi lancer aujourd’hui une telle alerte ?

 

B. D’O. : Non seulement ce n’est pas une nouveauté, mais je me permets de rappeler que les SI de santé n’ont pas le monopole des bugs informatiques. Les secteurs bancaire, des transports, des administrations y sont sensibles. En témoignent les projets en souffrance à Bercy, ou le facétieux système de paye des militaires. Le bug est à l’informatique ce que l’oxygène est au poumon. Sans les ignorer, il faut donc apprivoiser et contenir les failles logicielles, d’autant plus s’agissant de la santé des patients.

 

J.-F. G. : Sauf qu’aujourd’hui, les logiciels ne sont plus seulement des outils de gestion de l’information liée au patient, mais deviennent des outils de soins. Ils interagissent avec le patient, par exemple via la prescription électronique branchée à un pousse-seringue électrique. Si l’on veut éviter un « Mediator électronique », il faut tester, tester et encore tester, jusqu’à être sûrs d’avoir écarté tout risque d’erreur susceptible de créer un risque patient. Notre responsabilité à tous, éditeurs, établissements, pouvoirs publics, est engagée !

 

G. Z.  : Il y a quelque temps, nous avions été informés d’un bug susceptible de générer des erreurs dans le suivi des prescriptions dans une spécialité très sensible. Face à ce dysfonctionnement, la seule recommandation du fournisseur a été de nous demander d’attendre quelques semaines la livraison d’une version corrigée et de vérifier toutes les prescriptions manuellement. Une telle réponse n’est évidemment pas acceptable avec le déploiement à grande échelle de la prescription informatisée.

 

DSIH : Aujourd’hui, où en est la réflexion ?

 

J.-F. G. : La puissance publique essaie de prendre en considération ce problème, notamment au travers des travaux menés par la DSSIS[3], auxquels participe la FEHAP.

 

D. G.  : Un groupe miroir composé des différentes fédérations d’industriels a été mis en place par la DSISS, en parallèle du groupe de travail que vous évoquez. J’y représente le LESSIS. Cette organisation à deux niveaux est symptomatique d’un climat de défiance vis-à-vis des industriels. Il aurait été plus efficace de nous laisser dialoguer directement. Je peux vous affirmer que les éditeurs ont un souci profond de leurs responsabilités envers le patient.

 

B. D’O. : Si le projet est louable sur le fond, la méthode n’est pas bonne. Elle cloisonne les acteurs, ce qui ne peut qu’alimenter le climat de suspicion.

 

G. Z. : Le cœur du sujet tient aux moyens nécessaires à de tels déploiements. La masse des besoins à satisfaire, associée à la complexité des SIH, requiert nettement plus de moyens que ce que l’on y consacre aujourd’hui – ou, devrais-je dire, que l’on peut y consacrer ? Sur le plan des ressources, à la nécessité d’une architecture robuste s’ajoute celle de moyens humains hautement qualifiés. Pour mener à bien ces chantiers, l’hôpital a besoin d’experts SI de haut niveau, à double compétence technique et fonctionnelle.

 

B. D’O. : Les SIH sont, dans notre pays, dans un très mauvais état, pour des raisons que l’on connaît depuis 25 ans. Ils ne constituent pas une priorité stratégique, ni pour les responsables politiques ni pour les donneurs d’ordres. Mis à part quelques visionnaires, ils considèrent les SI uniquement comme un poste de coûts. Faiblesse de la maîtrise d’ouvrage, insuffisance des financements, absence de portage politique… Les bugs et les difficultés rencontrés, qui mettent la vie des patients en jeu, en sont évidemment les conséquences.

 

J.-F. G. : Il faut reconnaître que la DSISS dispose de trop peu de moyens eu égard aux changements nécessaires. Ceci mis à part, nous pensons que l’homologation serait un premier pas vers la résolution du problème, si seulement elle comportait ce caractère obligatoire, qui me paraît indispensable. Avec la « labellisation », on en est encore loin. On ne doit pas faire peser le choix technologique ou le respect des normes par l’éditeur sur l’établissement. Ce serait comme demander à un client de vérifier, avant d’acheter une cafetière, qu’elle se branche bien sur du 220 V ! Le contexte économique actuel explique certainement cela. De plus, il est évident que plus on va instaurer des critères d’homologation élevés, plus les éditeurs auront à assumer des investissements qui peuvent les mettre en danger. Ce serait un coup dur pour un marché déjà en pleine restructuration.

 

DSIH : Quelle est la position des industriels sur cette question de certification ou d’homologation ?

 

D. G. : Il existe déjà une démarche obligatoire de certification avec les LAP[4]. Elle est applicable au 1er janvier 2015 et extrêmement exigeante. À ce jour, aucun éditeur n’est vraiment prêt. On en connaît les critères, mais pas encore les moyens pour y parvenir. Comment aller encore plus vite ? Laissons du temps aux éditeurs, mais aussi à la DSISS…

 

B. D’O. : Si la certification des applications critiques est nécessaire, il faut veiller à ne pas imposer un carcan administratif, qui sclérose l’innovation. La labellisation à outrance est non seulement irréaliste, mais contre-productive. Pour trouver le bon équilibre, nous recommandons aux services de l’État de se rendre dans les pays où les SI fonctionnent harmonieusement, sans sur-règlementation inefficace.

 

D. G. : Sans compter qu’une démarche d’homologation trop liée à l’urbanisation fonctionnelle des SI pourrait représenter un danger. En segmentant trop finement des fonctions, elle risque de créer des points de passage intermédiaires obligés, qui vont créer des blocages supplémentaires. Seule la fonction finale importe, pas le chemin pour l’atteindre. Compte tenu de la variabilité des processus, de la taille des établissements et de leur vocation, cette approche ne me semble pas adaptée.

 

DSIH : Dominique Gougerot, en tant qu’éditeur, avez-vous été confronté au problème de bugs chez l’un de vos clients ? Si oui, quelle a été votre réaction ?

 

D.G. : Bien sûr. Tous les éditeurs ont été un jour confrontés à cette situation. Nous réagissons très vite en corrigeant le bug. La nouvelle version est alors directement téléchargeable par le client sur notre site web, avec la mention des améliorations apportées.

 

B. D’O. : Nous préférons la recherche de solutions à la quête de bouc émissaire, d’autant plus que la complexité fonctionnelle des SI de santé va croissant. Trouvons ensemble des solutions réalistes, et n’imposons pas aux éditeurs et donneurs d’ordre une limitation simpliste de versions, qui ne fera qu’aggraver la situation.

 

 

DSIH : Germain Zimmerlé, sur le terrain, quelles solutions avez-vous mises en place ?  

 

G. Z. : Depuis 2006 et le lancement de l’informatisation de la production des soins au CHU de Strasbourg, nous avons mis en place, en plus de la plate-forme de production, des environnements dédiés, avec une plate-forme de test, une autre de formation et une d’intégration. Ces dispositifs sont indispensables et nous permettent de suppléer aux manques, voire à l’absence de tests menés par les éditeurs avant les livraisons. Cela ne règle malheureusement pas tous les problèmes. Nous ne sommes pas à l’abri de bugs constatés durant l’utilisation du logiciel.

 

D. G. : Le test des programmes est une affaire très complexe. Les tests unitaires, appelés également de non-régression, sont généralement très bien faits par les éditeurs. Chez Berger-Levrault, par exemple, nous les développons depuis 3 ans avec l’atelier Team Fondation Serveur. Ils sont automatiquement intégrés à nos nouveaux développements. Évidemment, il nous reste encore à réécrire nos anciens produits. Il faut nous en laisser le temps. Les tests fonctionnels, qui permettent de vérifier le fonctionnement du logiciel au sein même de l’établissement, sont, eux, beaucoup plus difficiles à mettre en œuvre. Le niveau de paramétrage est très élevé et il n’est pas aisé pour l’éditeur de se projeter dans l’usage que le client aura de son programme. C’est donc aux établissements de les réaliser. D’ailleurs, comme le confirme Germain Zimmerlé, des plates-formes de tests ont été mises en place dans la plupart des grands hôpitaux.

 

DSIH : Ce procédé semble difficile à appliquer aux petites structures…

 

D. G. : Chez Berger-Levrault, nous travaillons principalement avec de petits centres hospitaliers et des maisons de retraite. Nous pouvons évidemment rester à leurs côtés pendant ces phases de tests, selon les modalités prévues dans le contrat d’assistance. Pour cela, nous mutualisons nos compétences : nos experts suivent ainsi chacun une centaine de clients. Mais si nos tests fonctionnels sont moins poussés, c’est aussi que, plus l’établissement est petit, moins la situation est complexe.

 

DSIH : Jean-François Goglin, quelles autres solutions prône la FEHAP ?

 

J.-F. G. : Il faut aider les éditeurs à mettre en place des phases de tests sérieuses et approfondies. Pour cela, ils ont besoin de scenarii de tests dotés de données pertinentes issus de procédures terrain : prise en charge aux urgences, consultations, prise en charge au bloc, prise de rendez-vous… Or, il n’existe pas aujourd’hui de référentiel national de processus, de procédures, et donc de scénarii. C’est pourtant indispensable si l’on veut faire les choses dans le bon ordre. Ce référentiel de processus devrait être instauré par la puissance publique. La FEHAP a d’ailleurs proposé de participer à son alimentation. Mettre en place ce dispositif prendra forcément du temps, mais c’est un prérequis indispensable à toute autre démarche d’amélioration. Passer outre en toute connaissance de cause, c’est promouvoir une mauvaise gestion des risques et la dilapidation des fonds publics.

 

B. D’O. : N’attendons pas de la puissance publique ce qu’elle n’est pas formée à produire. Sans préjudice de leur bonne volonté, les 20 années écoulées ont en effet montré les limites des instances spécialisées de l’État dans la fourniture de référentiels applicables.

 

G. Z. : Certification et référentiels seraient évidemment des plus, même si je pense que leur mise en œuvre est complexe. La définition de scenarii pourrait éventuellement être envisageable plus rapidement pour des petites et moyennes structures. Au fond, je crois qu’il n’y a malheureusement pas de solution miracle. Cela se saurait !

 

D. G. : La fourniture de scenarii de tests pourrait être une bonne idée. Mais attention à leurs implications sur l’urbanisation fonctionnelle. Encore une fois, on prend le risque de scléroser les SI sur des hypothèses ni optimales ni souhaitées par les établissements eux-mêmes.

 

G. Z. : On est loin d’en avoir fini avec les failles logicielles. Faut-il rappeler que la particularité d’un système d’information hospitalier est avant tout d’être un système de communication et d’échange, et non de calcul, comme dans d’autres secteurs d’activité ? Cela le rend, par essence, complexe tant dans sa construction que dans sa mise en œuvre et son évolution. De surcroît, le système d’information médical implique principalement des acteurs, médecins et personnels soignants, dont le métier n’est pas de gérer de l’information. Ce ne sont pas des « informationnels ». Je milite plutôt pour la mise en place de systèmes de logicio-vigilance, comme l’a fait le CHU de Brest.

 

D. G. : Je reste méfiant vis-à-vis de ce type de structure qui s’octroierait le pouvoir de juger et de censurer ex nihilo, sans connaître les contextes propres à chaque situation sur le terrain.

 

B. D’O. : Évidemment, il faut minimiser les risques, mais cela ne se fera pas avec une énième loi. Travaillons plutôt tous ensemble, dans une véritable concertation qui associe donneurs d’ordres et industriels. Imaginons, par exemple, l’impact d’une action commune auprès des parlementaires pour leur faire prendre conscience des enjeux du secteur. Nous avons tous à y gagner, et le patient en premier lieu !

 

DSIH : Les industriels ont lancé en juin dernier la charte BP6, censée répondre à cette problématique…

 

J.-F. G. : De notre point de vue, elle engageait trop les établissements, dont certains n’ont pas d’équipe informatique ni même de responsable du système d’information pour juger.

 

D. G. : Cette charte met chacun face à ses responsabilités. Les établissements doivent assumer leur rôle de maître d’œuvre et respecter les cadres d’interopérabilité de l’ASIP Santé et d’Interop’Santé. On peut difficilement envisager moins.

 

J.-F. G. : Au final, une nouvelle charte est en élaboration par la DSSIS. Elle s’appuie sur les différentes contributions déjà faites.

 

B. D’O. : Pourquoi élaborer une nouvelle charte ? Pourquoi refaire ce que des acteurs de la société civile ont construit avec la charte BP6 ? Rendez-vous compte : l’idée de cette charte est née en 2009 ; elle a nécessité 3 années de travail avec nos partenaires, l’Asinhpa, Syntec Numérique et la Fédération Hospitalière de France, pour aboutir en juin dernier à une première plate-forme commune. Appuyons-nous sur elle ! Elle est dans le domaine public. Nous invitons évidemment la FEHAP, la FHP, la FNEHAD et toutes les autres bonnes volontés à la rejoindre, entre autres pour aider la DSISS dans sa difficile mission.

 

DSIH : Quelles sont les prochaines échéances ?

 

B. D’O. : D’un point de vue purement opérationnel, le projet avance rapidement, même si, pour l’heure, la décision collégiale est de ne pas communiquer sur le sujet. Nous avons rassemblé de nouveaux partenaires, et le site internet dédié BP6 devrait ouvrir avant l’été.

 

DSIH : Et pour la FEHAP ?

 

J.-F. G. : Aujourd’hui, les prérequis n’étant pas en place, on est déjà en retard puisque le programme Hôpital numérique, FIDES, les Contrats du Bon usage des Médicaments… sont déjà lancés. Les établissements seront les premiers pénalisés car ce sont eux qui doivent se faire certifier. C’est une incohérence. Si l’on certifie les établissements, alors on doit certifier les logiciels et les matériels utilisés par l’établissement, sachant que ceux-ci entrent dans les critères d’évaluation.

 

B. D’O. : Justement, pour répondre aux inquiétudes concernant la disparité des phases de tests chez les éditeurs, la Charte BP6 envisage la mise en place des process de tests modélisés, permettant de vérifier le bon fonctionnement des logiciels, entre autres dans le domaine de l’interopérabilité. Il faut sortir du tout coercitif ! Si nous nous retrouvons tous autour de cette charte, elle aura valeur de recommandation ; l’adhésion d’un éditeur sécurisera le choix du donneur d’ordres et deviendra un avantage commercial.

 

DSIH : Aujourd’hui et d’ici à ce qu’une solution soit trouvée, comment les établissements réagissent-ils ? Comment les aider ?

 

J.-F. G. : Certains établissements montent au créneau, le plus souvent directement avec les éditeurs. Parfois, ils signalent les difficultés rencontrées à la DGOS ou lors des revues Hôpital 2012. Prochainement, la FEHAP va mettre en ligne sur son nouveau portail web un formulaire destiné à faire remonter les alertes et les problèmes rencontrés sur les logiciels, ce qui permettra à chacun de nos adhérents d’être informé et d’agir en conséquence, à la fois dans le repérage des bugs au sein de leur établissement mais aussi, en amont, dans le choix de leur prestataire. Aujourd’hui, les soucis rencontrés ne sont connus que des clubs utilisateurs. Nous espérons créer une plus grande transparence et éviter aux établissements des erreurs de casting.

 

G. Z.  : Si je peux ajouter quelques considérations à ne pas négliger, je mettrais l’accent sur quelques points critiques de chaque phase d’un projet. Avant l’acquisition, l’établissement doit exiger de l’éditeur qu’il lui fournisse la roadmap fonctionnelle et, si possible, technologique du produit. Pendant la phase de mise en œuvre du projet, le client doit être, entre autres, attentif au respect desengagements de service ainsi qu’au contrôle et à la traçabilité des livrables. En production, enfin, le processus et le planning de prise en compte des incidents et l’articulation avec la stratégie de versioning sont essentiels. C’est à ce niveau que le risque est fort de tomber dans le cycle des itérations sans fin.

 

 


Limiter le nombre de versions

 

Jean-François Goglin a fait l’évaluation du coût de non-productivité due aux bugs pour les établissements au plan national : près d’un demi-milliard d’euros ! « Le problème n’est pas tant de chiffrer le coût des bugs que de gérer des risques patients, souligne-t-il cependant. Le véritable sujet est de changer de paradigme : il est de notre devoir de citoyen de réduire au maximum les risques et de penser avant tout à la santé de nos concitoyens. Même si la santé a un coût, la vie n’a pas de prix. »

La FEHAP a donc demandé aux pouvoirs publics que soit listées les fonctions critiques pour le patient et de limiter les industriels à une version majeure d’un logiciel par an et pas plus de 7 versions intermédiaires dans l’année.

« Certains éditeurs font en effet évoluer leur logiciel au fil des retours clients, créant ainsi parfois plusieurs dizaines de versions intermédiaires en seulement quelques mois, remarque-t-il. Compte tenu des prérequis du programme Hôpital numérique, ce n’est plus acceptable. Parallèlement, nous demandons que les éditeurs fournissent à leurs clients, en même temps que le logiciel livré, les cahiers de tests, qui feront preuve de leur qualité. »

« Certains éditeurs vont jusqu’à livrer une nouvelle release presque chaque semaine, ajoute Germain Zimmerlé. Cela laisse supposer qu’ils ont les plus grandes difficultés à assurer la maîtrise de leur produit et de son versioning. »

Sceptique, Dominique Gougerot note : « Dans un contexte d’urgence, il me paraît impossible de limiter le nombre de releases. Si des bugs mettent véritablement en danger la sécurité du patient, il faut les corriger au plus vite. »

 

Photos :

Jean-François Goglin, Conseiller SIS, FEHAP

Germain Zimmerlé, DSI, CHU de Strasbourg

Bernard D’Oriano, Président Fédération LESISS[1]

Dominique Gougerot, Directeur du développement et de la stratégie Santé, Berger-Levrault




[1] Les Entreprises des Systèmes d'Information Sanitaires et Sociaux.

[2] Catalogue Spécifique des Actes de Rééducation et Réadaptation.

[3] Délégation à la Stratégie des Systèmes d’Information de Santé.

[4] Logiciels d’Aide à la Prescription.

VIDAL