Qualification des logiciels : cas pratique

Retour d’expérience sur la qualification des logiciels, une nouveauté de la norme ISO 13485:2016 et un enjeu considérable pour tous les fabricants de dispositifs médicaux.

Contexte : qualification des logiciels, une obligation pour tous les fabricants

Contexte réglementaire et normatif

La validation des logiciels (hors logiciels qui sont des DM à part entière ou qui sont inclus dans un DM) doit être réalisée afin d’être en conformité avec :

• la Norme ISO 13485:2016
  • 4.1.6 logiciel QMS
  • 6.3 logiciel infrastructure ou maintenance
  • 7.5.6 logiciel production sauf si intégré dans une machine, il sera qualifié avec la machine
  • 7.6 logiciel ECME
• les exigences FDA
  • 21 CFR part 820 logiciel production et QMS
  • 21CFR part 821 logiciel de traçabilité

Pour rappel la norme IEC 62304 n’est pas applicable, car elle concerne les logiciels qui sont des DM ou qui sont intégrés à des DM, vous pouvez par contre utiliser le guide ISO TR 80002-2 dédié à la validation des logiciels du SMQ.

Quel intérêt ?

A part satisfaire aux exigences règlementaires et normatives, la validation des logiciels permet d’assurer la conception, la conformité, l’identification et la traçabilité du produit livré. Cela permet également d’assurer les exigences en cas de rappel ou de retrait de produit et d’assurer le bon fonctionnement du SMQ de l’entreprise.

La qualification d’un ERP en 10 étapes-clés

Ce retour d’expérience qui est de loin la qualification la plus compliquée dans une entreprise tant le projet global est structurant. Ce projet qui a débuté en septembre 2017 (décision du changement d’ERP), pour une mise en service partielle en octobre 2018 et finale en mai 2019.

1. Ouverture du change control

Dès la prise de décision de changer d’ERP (le nôtre datait de 2003) nous avions décidé d’ouvrir une action de “change control“ (gestion des modifications) afin de déterminer le plus en amont possible les impacts sur l’ensemble du fonctionnement de la société et pas seulement du SMQ.

En effet, le projet de changement avait plusieurs objectifs :

• De remplacer notre ancienne GPAO (une émulation dos sous windows !) dont la maintenance devenait difficile et dont l’interface n’était plus en phase avec les attentes des utilisateurs.
• De regrouper plusieurs outils externes au sein d’un même logiciel
• D’accélérer la récupération de données pour faciliter l’analyse et la traçabilité

À cette occasion, une première version de l’analyse des risques a été initiée, cela nous à permis d’évaluer l’ampleur du projet, mais aussi de commencer à rédiger le cahier des charges.

Par la suite, une méthode de qualification QC QI QO QP a été mise en oeuvre.

2. Définition du cahier des charges

Lors de la rédaction du cahier des charges (QC), nous avions pris en compte le fait que nous sommes une petite société (30 personnes à l’époque), par conséquent nous ne pouvions avoir une solution développée sur mesure, il fallait composer avec une solution « sur étagère », à adapter à notre métier : la production de dispositifs électro-médicaux.

Ce cahier des charges nous à permis de passer à la phase suivante : la consultation de sociétés spécialisées dans la mise en place d’ERP.

3. Lancement de l’appel d’offre et Sélection du prestataire

Trois prestataires ont été présélectionnés,  ils sont venus nous présenter leurs ERP, nous avons ensuite confronté leurs produits avec notre cahier des charges, ceci nous a permis d’établir un classement des ERP, pondéré par les possibilités d’adaptation des logiciels à nos besoins.

Cette analyse nous a finalement permis de sélectionner le prestataire.

4. Pré installation & Transfert de données

Une première installation du logiciel a eu lieu sur le serveur informatique de l’entreprise, l’occasion de rédiger un premier rapport d’intégration.

Nous avons ensuite installé le logiciel sur quelques postes, l’occasion de rédiger le second rapport d’intégration (QI).

À partir de ce moment nous avons entamé une phase très longue de récupération, de transformation et de transfert de données, entre l’ancien et le nouveau logiciel.

Nous avons décidé de conserver l’historique de l’ancien logiciel pour être en conformité avec les exigences de conservation des documents de la directive 93/42/CE et ce même si nous avions un archivage papier des documents.

Ce transfert de données et les vérifications associées ont constitué les rapports d’intégration et de tests, poursuivis dans l’étape suivante.

5. Actions de formation des utilisateurs

En parallèle nous avons commencé de former les utilisateurs ayant à se servir de l’ERP. Ces actions de formation, mise en place à l’occasion du transfert des données, ont permis de détecter les bugs d’imports.

L’enregistrement des feuilles de présences aux formations constituent les preuves de formation des opérateurs (incluses dans la QP)

6. Fin de transfert des données

Nous avons ensuite réalisé des tests permettant de valider à la fois le transfert de données, mais aussi la formation des utilisateurs.

Les rapports de tests constituent la QO et la QP.

7. Paramétrage du logiciel

À la suite de ces tests, nous avons mis en place le paramétrage du logiciel en fonction de nos besoins (en particulier la gestion des équivalences) et avons relancé des tests sur les modules d’achat et de sortie magasin. Cela nous a conduit à faire une mise à jour du Cahier des charges : QC et QO-QP

8. Test d’intégration + qualification du soft

Une fois toutes les étapes précédentes réalisées, nous avons mis à jour notre analyse des risques, découpée selon les modules du logiciel.

Dans notre cas, nous avons décidé (dans un premier temps) de remplacer uniquement notre GPAO et donc les modules d’enregistrement des commandes client, d’achat et de gestion du magasin et de livraison. Nous avons relégué dans un second temps toute la partie production (gestion des employés, du pointage sur OF, planification…)

Ce découpage issu de notre analyse des risques avait pour but de pouvoir être plus réactifs en cas de bug lors et de ne pas impacter les activités de production.

La mise en route de ces premiers modules a fait l’objet de rapport de qualification (QP).

9. Mise en route du logiciel

À la suite de ces premiers tests, nous avons déployé la solution auprès des utilisateurs et officialisé son utilisation.

C’est à ce moment que la pratique terrain s’est confrontée à la théorie des formations et aux rapports de qualification : il s’est avéré que certaines situations n’étaient pas envisagées, l’occasion de mettre à jour nos dossiers de gestion des risques et rapports de tests (QC+ fiches NC)

10. Suivi d’installation

En lien avec l’intégration du logiciel, la société responsable de l’installation nous a mis à disposition un consultant pour répondre aux problématiques non envisagées et ressorties suites aux premières semaines de pratiques.

Ces séances consistaient en un mix de formations (rappel et approfondissement) et paramétrage / corrections de l’installation du logiciel.

8 mois après la première mise en route, nous avons mis en fonctionnement le reste de l’ERP et notamment les modules de production (planification, pointage des salariés…) sur le même modèle de mise en route que précédemment.

Que penser de cette validation d’ERP ?

Petite conclusion, à froid, plus d’un an après la mise en route du dernier module.

Le transfert des données a été très complexe et n’est pas accessible à toutes les sociétés ; sans informaticiens virtuoses des fichiers Excel, cela peut s’avérer très compliqué tant le volume de données est important et les tests d’intégration nombreux à effectuer. Il faut noter que cela nécessite de la disponibilité pour ces acteurs et surtout de la compétence. Les sociétés spécialistes de l’intégration ne font en fait qu’un accompagnement à l’installation et à la formation des salariés.

Comme toute formation à l’utilisation, on ne retient pas l’intégralité des données transmises, il est donc primordial de prendre en compte dès le départ un accompagnement de la société formatrice afin de planifier dans le temps un suivi sur 6 à 12 mois.

L’utilisation de l’ERP est à ce jour complète et la qualification terminée. Notre Organisme Notifié, dans le cadre de ses audits périodique, a suivi la qualification du logiciel. Nous continuons de faire évoluer nos pratiques en fonction de celui-ci (attention, un certain nombre de nos procédures internes ont dû être actualisées).

Un module ne sera pas utilisé : celui concernant toute la partie qualité. En effet il est quasiment impossible de faire correspondre les exigences de l’ISO 13485, de la directive 93/42, du règlement 2017/745 et les exigences canadiennes et américaine (FDA).

D’une manière plus globale concernant la qualification des logiciels dans l’entreprise,  je considère qu’il y a un risque à suivre à la lettre les exigences règlementaires et normatives : un risque de scléroser l’entreprise avec la lourdeur des validations logicielles, et des réflexions du genre « j’avais pensé qu’on pourrait se faire un excel pour vérifier les mesures effectuées avant la libération finale… mais non, il va falloir faire une gestion des risques, un CDC, un dossier de test, … laisse tomber ».

Bonne pratique : encourager l’utilisation d’outils logiciels, dans un cadre adapté

Pour contrer ce genre de réflexions et donc de comportements qui peuvent empêcher la numérisation des activités de l’entreprise, nous avons adopté la démarche suivante :

• Inscrire dans la politique qualité de l’entreprise la notion d’intelligence individuelle et collective afin de garder à l’esprit que la finalité de notre travail n’est pas de suivre à la lettre un SMQ pour faire plaisir à un ON mais bien de concevoir et fabriquer des produits dans le but de soigner des patients.
• Sensibiliser l’ensemble des salariés au fait que toute idée d’amélioration est bonne à prendre et qu’en matière informatique tout est possible à partir du moment où une tache est répétable.
• Informer les informaticiens qu’ils sont libres de développer, la seule contrainte que nous mettons concerne la mise en service du logiciel dans l’entreprise
• Le service qualité affaire règlementaire est responsable du suivi de la qualification du logiciel et donc de son déploiement dans l’entreprise.