Systèmes pré-validés : vérité ou fiction ?

La validation n'est pas pour les âmes sensibles. La plupart des professionnels des secteurs réglementés apprennent la validation des systèmes informatisés dans le cadre du programme qualité de leur propre organisation. Au fil du temps, certains changent d'entreprise, tandis que d'autres accompagnent leurs clients en tant que consultants. Une chose devient très vite évidente : il n'y a pas deux organisations qui abordent la validation exactement de la même manière. Même avec l'adoption croissante des plateformes infonuagiques, des stratégies basées sur les risques et une implication plus forte des fournisseurs, les équipes de validation continuent d'être confrontées à la même question récurrente. Peut-on vraiment acheter un système « pré-validé » ? À première vue, l'idée semble séduisante, surtout lorsque les fournisseurs présentent leurs solutions comme conformes ou pré-validées. Pour les chefs d'entreprise, ces affirmations peuvent sembler rassurantes et pratiques. Cependant, dans le domaine des sciences de la vie, la validation ne peut pas être simplement intégrée et transférée comme une fonctionnalité du produit. Les organismes de réglementation soulignent régulièrement que la responsabilité de garantir la conformité incombe à l'entreprise réglementée, et non au fournisseur [1].   

Qualification vs validation : une différence essentielle 

Une source majeure de confusion réside dans l'hypothèse selon laquelle la qualification et la validation sont interchangeables. Ce n'est pas le cas. 

•    La qualification confirme qu'un système répond aux spécifications définies par le fournisseur. 

•    La validation démontre que le système fonctionne comme prévu dans le cadre des processus et du contexte opérationnel spécifiques de l'utilisateur. 

Par exemple, un fournisseur peut fournir des documents relatifs à la qualification de l'installation (IQ), à la qualification opérationnelle (OQ) et à la qualification des performances (PQ). Bien que ces documents puissent être utiles, ils sont généralement conçus pour s'appliquer de manière générale à de nombreux clients et secteurs d'activité. 

Cela crée une limitation importante : les documents fournis par les fournisseurs reflètent rarement la réalité de votre environnement. 

Les inconvénients à long terme des systèmes « pré-validés » 

Bien que l'assistance fournie par les fournisseurs puisse réduire la charge de travail initiale, le fait de trop s'appuyer sur une solution dite pré-validée peut entraîner des difficultés importantes à long terme. 

1. La validation ne peut pas être entièrement transférée 

Un système n'est pas validé de manière isolée. La validation doit confirmer que l'application fonctionne correctement dans le cadre de votre organisation : 

•    Flux de travail 

•    Pratiques de gouvernance des données 

•    Procédures qualité 

•    Engagements réglementaires 

•    Utilisation prévue 

C'est pourquoi les régulateurs s'attendent à ce que la validation soit directement liée à la manière dont le système est réellement utilisé, et pas simplement à la manière dont il a été testé par un fournisseur [2]. 

2. Les tests des fournisseurs sont généralement génériques  

La plupart des packs de tests des fournisseurs suivent un modèle standard. Ils sont conçus pour satisfaire une large clientèle, et non les besoins spécifiques d'un fabricant pharmaceutique, d'une entreprise de biotechnologie ou d'un laboratoire clinique.  

Dans la pratique, cela signifie que des contrôles essentiels spécifiques à l'activité font souvent défaut, tels que les : 

• Exigences en matière de libération des lots 

• Processus d'examen des résultats de laboratoire 

• Flux de travail pour les signatures électroniques 

• Intégrations avec les systèmes existants 

Ce qui semble complet sur le papier peut présenter des lacunes importantes dans les opérations réelles. 

3. Les exigences des utilisateurs sont souvent négligées 

L'un des obstacles les plus courants est l'inadéquation entre les spécifications du fournisseur et les attentes des utilisateurs. Un protocole fournisseur peut vérifier qu'une procédure de sauvegarde existe, mais la validation doit confirmer que : 

• Les sauvegardes fonctionnent correctement pour ce système. 

• Les restaurations sont efficaces dans des scénarios réalistes. 

• Les objectifs de temps de récupération sont atteints. 

• Les procédures sont conformes aux normes de l'entreprise. 

Les scripts génériques ne peuvent pas démontrer pleinement que vos exigences sont satisfaites. 

4. Le « raccourci » peut s'avérer plus coûteux 

La pré-validation est souvent présentée comme une option économique. En réalité, les entreprises finissent souvent par payer deux fois : d'abord pour les dossiers de documentation des fournisseurs, puis pour les retouches internes, les tests supplémentaires et les corrections. 

Au moment où l'organisation complète les exigences manquantes et aligne les livrables sur les normes de qualité internes, l'efficacité promise peut disparaître. 

5. Risque de conformité lié à une terminologie trompeuse 

La plus grande préoccupation est peut-être la fausse confiance créée par le langage marketing.  

Des expressions telles que « conforme à la partie 11 dès la sortie de l'emballage » peuvent être dangereusement trompeuses. La conformité ne dépend pas uniquement des fonctionnalités du logiciel, mais également de la gouvernance, de la configuration, des procédures et du contrôle continu.  

Les régulateurs continuent de mettre en avant leurs attentes concernant : 

• L'examen des pistes d'audit. 

• La gestion des accès. 

• Le contrôle des modifications. 

• L'intégrité des données. 

• La supervision du cycle de vie. 

L'absence de mise en place de ces contrôles peut entraîner des conclusions d'inspection et une exposition réglementaire à long terme [3]. 

6. Les plateformes cloud ajoutent une complexité supplémentaire 

Dans les environnements IaaS (Infrastructure as a Service), PaaS (Platform as a Service) et SaaS (Software as a Service), les fournisseurs gèrent une grande partie de l'infrastructure et du cycle de publication.  

Cela entraîne des défis supplémentaires, tels que : 

• Mises à jour fréquentes du système 

• Visibilité limitée sur les tests effectués par les fournisseurs 

• Configurations en constante évolution 

• Limites des responsabilités partagées 

Un système qui a été « validé » lors de sa mise en œuvre peut devenir non conforme si les contrôles du cycle de vie ne sont pas activement maintenus. 

7. La validation doit être maintenue, et non achetée une seule fois 

Même si la documentation du fournisseur prend en charge la mise en œuvre initiale, les organisations doivent tout de même prévoir :  

• Des examens périodiques.  

• Des mises à niveau et des correctifs. 

• Des changements dans les processus opérationnels.  

• La préparation aux inspections.  

• Une validation et une maintenance continues.  

La validation n'est pas un événement ponctuel, mais une responsabilité permanente

Y a-t-il des avantages ?  

Pour être honnête, les livrables de validation des fournisseurs peuvent s'avérer extrêmement utiles, en particulier lorsqu'ils comprennent :  

• Des spécifications de base solides  

• Des protocoles de qualification structurés  

• Des preuves des tests effectués par les fournisseurs  

• Un soutien aux activités de qualification des fournisseurs  

Toutefois, ces documents doivent être considérés comme des contributions et non comme une preuve définitive de conformité. 

Alors, pouvez-vous acheter un système validé ?   

Vous pouvez certainement acheter la documentation du fournisseur, l'assistance aux tests et des supports de qualification structurés. Cependant, vous ne pouvez pas acheter la responsabilité ou la propriété réglementaire. Dans les environnements des sciences de la vie, la validation doit toujours démontrer que le système fonctionne correctement pour l'usage auquel il est destiné dans le cadre des processus et contrôles propres à l'organisation. Une solution dite prévalidée peut constituer un point de départ utile, mais elle ne remplace pas la nécessité d'une validation par l'utilisateur. Une confiance excessive dans les affirmations des fournisseurs peut créer des lacunes qui apparaîtront plus tard lors d'inspections, d'audits ou de modifications du système. L'approche la plus sûre consiste à privilégier la transparence, les pratiques rigoureuses des fournisseurs en matière de qualité et le contrôle du cycle de vie plutôt que les promesses marketing. À long terme, la conformité est maintenue grâce à une surveillance continue, et non à un achat ponctuel. 

Références: 

[1] U.S. Food and Drug Administration (FDA). General Principles of Software Validation; Final Guidance for Industry and FDA Staff. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-principles-software-validation 

[2] ISPE. GAMP® 5: A Risk-Based Approach to Compliant GxP Computerized Systems. https://ispe.org/publications/guidance-documents/gamp-5 

[3] European Commission. EudraLex Volume 4 – Annex 11: Computerised Systems. https://health.ec.europa.eu/medicinal-products/eudralex/eudralex-volume-4_en