Validation d’un eQMS : une approche fondée sur les risques pour les petites équipes qualité

Vous avez acheté, ou êtes sur le point d’acheter, un système électronique de management de la qualité, et quelqu’un vous a demandé le plan de validation. L’équipe qualité compte trois personnes. La dernière validation d’un système informatique que quelqu’un ici a vue consistait en un classeur à levier rempli de captures d’écran d’un instrument de laboratoire, et personne ne souhaite recommencer pour un système qui hébergera toutes vos procédures opératoires normalisées, vos CAPA et vos dossiers de formation. Cet article présente une méthode proportionnée de validation d’un eQMS : ce qu’exigent réellement l’annexe 11 des BPF de l’UE et la norme ISO 13485, comment la deuxième édition de GAMP 5 et les principes d’assurance des logiciels informatiques réduisent la charge de travail, dans quelle mesure vous pouvez vous appuyer sur les propres tests du fournisseur, les conséquences de la configuration et de la personnalisation, ce que vous devez tester vous-même et comment maintenir le système validé une fois qu’il est opérationnel.

Ce qu’exigent réellement les textes

Pour les fabricants de dispositifs médicaux, la clause 4.1.6 de la norme ISO 13485:2016 exige des procédures documentées pour valider l’application des logiciels informatiques utilisés dans le système de management de la qualité. La validation doit être réalisée avant la première utilisation et, le cas échéant, après des modifications apportées au logiciel ou à son application. L’approche doit être proportionnée aux risques liés à l’utilisation du logiciel. Les enregistrements des travaux doivent être conservés. Le rapport technique ISO/TR 80002-2:2017 fournit des recommandations spécifiques sur la validation des logiciels utilisés dans les systèmes qualité des dispositifs médicaux et constitue une ressource utile pour disposer d’un cadre concret.

Pour les médicaments, l’annexe 11 des BPF de l’UE s’applique à chaque système informatisé utilisé dans le cadre d’activités régies par les BPF. La section 1 demande une gestion des risques tout au long du cycle de vie du système, l’étendue de la validation devant être définie sur la base d’une évaluation des risques justifiée et documentée. La section 4 porte sur la validation : exigences des utilisateurs fondées sur les risques et l’incidence sur les BPF, traçables tout au long du cycle de vie (4.4) ; évaluation du fournisseur (4.5) ; et preuves de méthodes et de scénarios de test adaptés (4.7). La section 3 traite des accords formels avec les fournisseurs et la section 11 de l’évaluation périodique. Une version révisée de l’annexe 11 a été soumise à consultation publique en 2025. Au moment de la rédaction, le texte de 2011 est toujours la version publiée sur la page EudraLex de la Commission. Planifiez donc en fonction de cette version et restez attentif à la nouvelle.

Aucun de ces textes ne vous demande de tester chaque bouton. Tous deux vous demandent de comprendre le rôle du système dans vos processus, de déterminer ce qui pourrait mal tourner et de consacrer vos efforts à ces aspects. L’ICH Q9(R1) exprime le même principe de manière générale : les efforts, le niveau de formalité et la documentation de la gestion des risques qualité doivent être adaptés au niveau de risque.

La deuxième édition de GAMP 5 et l’assurance des logiciels informatiques en pratique

L’ISPE a publié la deuxième édition de GAMP 5 en juillet 2022. Ses catégories de logiciels restent utiles : la plupart des produits eQMS sont des logiciels configurés (catégorie 4), et tout logiciel développé spécifiquement pour vous relève de la catégorie 5, personnalisée. Les changements les plus utiles concernent l’orientation générale. La deuxième édition privilégie l’esprit critique des personnes qui connaissent le processus, s’attend à ce que les entreprises réglementées tirent pleinement parti des connaissances, des tests et de la documentation du fournisseur, et tient compte du développement itératif et des services cloud.

L’assurance des logiciels informatiques (CSA) va dans le même sens. Elle a été exposée par la FDA américaine dans des recommandations finalisées en septembre 2025 et mises à jour en février 2026. Bien qu’il s’agisse d’un document américain, ses quatre étapes constituent une structure solide pour toute petite équipe. Déterminez l’usage prévu de chaque fonctionnalité. Décidez si une défaillance de cette fonctionnalité présenterait un risque élevé pour le processus. Choisissez des activités d’assurance adaptées : des tests scriptés, avec des étapes détaillées et des résultats attendus, lorsque le risque est élevé, et des méthodes non scriptées, comme les tests exploratoires ou la recherche d’erreurs, lorsqu’il ne l’est pas. Conservez des enregistrements suffisants pour prouver que le travail a été réalisé, sans aller au-delà.

Ensemble, ces principes vous permettent de cesser de produire des preuves dont personne ne se sert. Ils ne vous dispensent pas de réfléchir.

Commencer par l’usage prévu

Rédigez une page indiquant à quoi sert l’eQMS sur votre site. Quels processus prend-il en charge (maîtrise documentaire, formation, déviations, CAPA, audits internes) et lesquels ne prend-il pas en charge (libération des lots, déclaration des réclamations aux autorités, par exemple) ? Qui l’utilise, et quels enregistrements qu’il contient relèvent des BPF ou de la norme ISO 13485 ? Ajoutez le système à votre inventaire des systèmes informatisés, que l’annexe 11, section 4.3, vous demande de tenir à jour.

Rédigez ensuite des exigences utilisateurs correspondant à vos propres processus, avec vos propres termes. « Une révision de procédure opératoire normalisée entre en vigueur à sa date d’application et la révision précédente est retirée à cette même date » est une exigence que vous pouvez tester. « Le système doit prendre en charge la maîtrise documentaire » n’en est pas une. Pour une petite entreprise, quelques dizaines d’exigences suffisent généralement pour un eQMS. Attribuez un niveau de risque à chacune : une défaillance pourrait-elle avoir une incidence sur la qualité du produit, la sécurité des patients ou l’intégrité d’un enregistrement BPF ? La plupart présenteront un risque faible. Les autres — par exemple le passage à la date d’application, les signatures électroniques, la piste d’audit, les autorisations par rôle et l’attribution de formations lors d’une révision — sont les points que vous devrez tester vous-même.

Évaluer le fournisseur et s’appuyer sur ses tests

L’annexe 11 indique que la compétence et la fiabilité du fournisseur sont des facteurs clés, que la nécessité d’un audit doit être déterminée en fonction des risques (3.2) et que les informations relatives au système qualité et aux audits des fournisseurs doivent être mises à la disposition des inspecteurs sur demande (3.4). Pour la plupart des petites entreprises qui achètent un système cloud configuré, une évaluation à distance fondée sur un questionnaire et des documents est proportionnée. Un audit sur site se justifie si les réponses soulèvent des doutes.

Demandez une description de leur cycle de développement et de leur système qualité, de leur processus de mise en production et de notification des changements, un résumé de leurs propres tests des fonctions essentielles, des modalités de fonctionnement de la piste d’audit et des signatures électroniques, de l’emplacement de l’hébergement des données, des méthodes de test des sauvegardes et des restaurations, ainsi que de leur processus de sortie et d’exportation. Notre liste de vérification pour l’achat d’un eQMS contient la liste complète des questions.

Voici toutefois la limite à ne pas dépasser. Les recommandations de la MHRA sur l’intégrité des données GxP (section 6.19) précisent qu’il n’est pas acceptable d’accepter isolément des données de validation fournies par le fournisseur, sans tenir compte de la configuration du système et de l’usage prévu par l’utilisateur, car les tests du fournisseur, effectués hors de votre processus, se limiteront vraisemblablement à une vérification fonctionnelle. Les tests du fournisseur peuvent couvrir le produit de base : le moteur de piste d’audit enregistre les modifications, les signatures sont liées aux enregistrements et les autorisations sont appliquées conformément à la configuration. Vos tests portent sur votre configuration dans le cadre de votre processus. Consignez cette répartition dans une brève déclaration de reliance, en indiquant les documents du fournisseur que vous avez examinés et les conclusions que vous en avez tirées.

Configuration ou personnalisation

La configuration consiste à mettre en place le produit au moyen des outils qu’il fournit : flux de travail, circuits d’approbation, rôles, systèmes de numérotation, champs de formulaires et règles de formation. La personnalisation consiste à écrire ou modifier du code pour vous. Cette distinction a une grande incidence sur la charge de validation.

La configuration est testée par rapport à vos exigences. Si le circuit d’approbation de vos procédures opératoires normalisées prévoit deux réviseurs et un approbateur AQ, testez ce circuit, y compris ce qui se passe lorsqu’un réviseur rejette le document. La personnalisation relève de la catégorie 5 et implique notamment la conception, la revue de code et les tests requis. Elle doit être retestée à chaque nouvelle version du fournisseur. Pour une petite équipe, la stratégie de validation la moins coûteuse consiste à configurer le système en fonction de votre processus et à modifier le processus lorsqu’il est incompatible avec le produit. Toute demande de personnalisation doit être justifiée par écrit.

Maîtrisez également la configuration elle-même. La section 10 de l’annexe 11 exige que les modifications de configuration suivent une procédure définie. Consignez donc la configuration de référence au moment de la mise en service et soumettez les modifications ultérieures à une gestion des changements assortie d’une évaluation d’impact.

Ce que vous devez tester vous-même

Concentrez les tests scriptés sur les fonctions dont une défaillance pourrait endommager les enregistrements ou permettre qu’un document incorrect soit utilisé sur le terrain. Voici une répartition type pour un eQMS :

Les tests exploratoires doivent eux aussi être consignés : qui a testé, quand, quelle zone, ce qui a été essayé et les résultats obtenus. Une demi-page par session suffit. La migration des données nécessite une vérification spécifique, car l’annexe 11, section 4.8, exige que les données migrées ne soient pas modifiées quant à leur valeur ou leur signification.

Terminez par un rapport récapitulatif de validation qui répertorie les exigences, les preuves associées à chacune (vos tests, les preuves du fournisseur ou les deux), les écarts relevés pendant les tests et la manière dont ils ont été résolus (annexe 11, section 4.2), ainsi qu’une déclaration claire confirmant que le système est adapté à son usage prévu.

Maintenir le système validé

Un eQMS cloud évolue plusieurs fois par an. Rédigez une brève procédure relative aux mises en production : comment vous en êtes informé, qui lit les notes de version, comment l’incidence est évaluée au regard de vos exigences et dans quels cas une modification déclenche de nouveaux tests. Une modification de la logique de signature ou d’approbation nécessite un nouveau test ciblé. Ce n’est pas le cas d’une nouvelle mise en page de rapport.

La section 11 de l’annexe 11 prévoit une évaluation périodique pour confirmer que le système demeure dans un état validé, en examinant ses fonctionnalités, les déviations, les incidents, l’historique des mises à niveau, les performances, la sécurité et l’état de validation. Pour une petite entreprise, une revue annuelle d’une ou deux pages suffit : ce qui a changé, ce qui a mal fonctionné, si les accès des utilisateurs sont toujours appropriés, si une restauration de sauvegarde a été vérifiée et si le dossier de validation correspond toujours à l’utilisation réelle du système. Profitez-en pour examiner la piste d’audit d’un échantillon d’enregistrements.

Rester proportionné

Pour un petit fabricant, un dossier de validation d’eQMS défendable tient dans un seul répertoire : usage prévu, exigences évaluées en fonction des risques, évaluation du fournisseur et déclaration de reliance, configuration de référence, scripts de test et comptes rendus de tests exploratoires, rapport récapitulatif, procédure de mise en production et d’évaluation périodique. Un inspecteur le lira en une heure. Si le vôtre est beaucoup plus volumineux, demandez-vous quelles parties ont servi à prendre une décision.

À retenir

Validez la configuration que vous avez mise en place pour le processus que vous exécutez, appuyez-vous sur le fournisseur pour le produit de base après avoir examiné ses preuves, et maintenez le système validé grâce à l’évaluation des mises en production et à une revue annuelle.

Si vous êtes en train de définir ces travaux, la page plateforme InnoQualis présente les modules de maîtrise documentaire, de formation, de gestion des déviations, des CAPA et des audits que vous devrez valider, avec des signatures électroniques conçues pour répondre aux exigences de la 21 CFR Part 11 et de l’annexe 11 des BPF de l’UE, ainsi qu’une piste d’audit en ajout uniquement.