VMP Risk-Based et Lifecycle : intégrer ICH Q9/Q10 et Change Control pour maintenir l’état validé

VMP risk-based et lifecycle : comment rendre la validation durable et défendable

Un Validation Master Plan (VMP) efficace ne doit pas seulement décrire ce qui a été validé. Il doit expliquer comment l’entreprise décide ce qui doit être validé, avec quel niveau de profondeur, et comment l’état validé est maintenu dans le temps.

Le point central est le suivant : l’approche risk-based n’est pas une tendance. C’est la seule manière durable et défendable de gouverner la validation.

Deux erreurs opposées conduisent souvent à des inspections difficiles :

• under-validation, c’est-à-dire des gaps sur des assets, processus ou systèmes critiques ;
• over-validation, c’est-à-dire tout valider de la même manière, avec une documentation et des tests excessifs, jusqu’à ne plus être capable de maintenir le plan.

L’approche moderne, cohérente avec l’Annex 15 et avec la logique d’ICH Q9/Q10, pousse à utiliser le Quality Risk Management pour définir le scope, l’étendue des activités et le maintien de l’état validé tout au long du lifecycle.

Table des matières

• Pourquoi risk-based est la seule approche durable et défendable
• Step 1 — Formaliser clairement la Risk Policy dans le VMP
• Step 2 — Traduire le risque en stratégie de validation
• Step 3 — Lifecycle : validé une fois ne signifie pas validé pour toujours
• Step 4 — Change Control : le point où l’on gagne ou l’on perd
• Step 5 — Systèmes informatisés : de la CSV documentaire à l’assurance basée sur le risque
• Step 6 — KPI de validation pour les sites matures
• Roadmap d’implémentation 30–60–90 jours
• FAQ sur le VMP risk-based
• Voulez-vous réellement appliquer risk-based et lifecycle à votre VMP ?

1. Pourquoi risk-based est la seule approche durable et défendable

Un système de validation ne peut pas tout traiter de la même manière.

Un autoclave critique, une utility stérile, un système informatisé GxP et un equipment à faible impact ne peuvent pas exiger le même niveau de testing, de preuves et de review.

L’approche risk-based permet d’éviter deux extrêmes dangereux :

• en faire trop peu lorsque le risque est élevé ;
• en faire trop lorsque le risque est faible.

1.1 Under-validation

L’under-validation se produit lorsque des assets, systèmes ou processus critiques ne sont pas qualifiés ou validés avec une profondeur suffisante.

Exemples typiques :

• système GxP non inclus dans le scope ;
• utility critique qualifiée de manière superficielle ;
• change impactant clôturé sans validation impact assessment ;
• equipment utilisé en production sans preuve adéquate ;
• cleaning validation non proportionnée au risque réel.

Lors d’un audit, cela génère immédiatement des questions sur la capacité de l’entreprise à contrôler la qualité produit, la sécurité du patient et la data integrity.

1.2 Over-validation

L’over-validation est l’erreur opposée : tout valider avec le même niveau de détail, même lorsque le risque est faible.

Le résultat est un système lourd, lent et difficile à maintenir.

Signaux typiques :

• trop de protocoles qui ne sont pas réellement nécessaires ;
• tests répétitifs sans rationnel ;
• requalification time-based sur tout, sans considérer les trends ou la criticité ;
• backlog d’activités overdue ;
• documentation énorme mais peu utile ;
• perte de crédibilité parce que le plan n’est pas maintenu.

Une approche risk-based bien décrite dans le VMP permet de démontrer que l’entreprise ne fait pas « moins de validation », mais qu’elle fait la bonne validation là où elle est réellement nécessaire.

2. Step 1 — Formaliser clairement la Risk Policy dans le VMP

La première étape consiste à déclarer clairement dans le VMP comment l’entreprise applique le Quality Risk Management à la validation.

Il ne suffit pas d’écrire « risk-based approach ». Vous devez expliquer comment cette approche fonctionne.

2.1 Ce que la Risk Policy doit déclarer

Dans le VMP, vous devriez indiquer :

• quelle méthode d’évaluation du risque vous utilisez ;
• comment vous définissez les risques élevés, moyens et faibles ;
• quels critères vous utilisez pour la sévérité, la probabilité et la détectabilité ;
• comment vous reliez le risque au niveau de testing ;
• comment vous reliez le risque au niveau de preuve ;
• quand une review QA indépendante est requise ;
• quand une requalification ou une revalidation est requise ;
• comment le risque est réévalué en cas de change, déviation ou trend.

2.2 Exemples de méthodes utilisables

Vous pouvez utiliser différentes méthodes, à condition qu’elles soient définies et cohérentes.

Exemples :

• matrice Sévérité / Probabilité / Détectabilité ;
• FMEA ;
• impact assessment ;
• criticality assessment ;
• risk ranking Low / Medium / High ;
• stratégie de testing risk-based.

Le choix de l’outil est moins important que la cohérence d’application.

2.3 Exemple de mini-matrice 3×3

Une matrice simple peut être suffisante si elle est bien documentée.

Sévérité

Évalue l’impact potentiel sur :

• qualité produit ;
• sécurité du patient ;
• data integrity ;
• compliance GMP ;
• capacité de contrôle du processus.

Probabilité

Évalue dans quelle mesure le failure mode est plausible, en considérant :

• complexité du système ;
• historique des déviations ;
• fréquence d’utilisation ;
• criticité opérationnelle ;
• expérience précédente ;
• niveau d’automatisation ou d’intervention manuelle.

Détectabilité

Évalue avec quelle facilité l’erreur peut être détectée avant d’impacter le produit ou la libération.

Exemples de facteurs :

• alarmes ;
• interlocks ;
• contrôles in-process ;
• review QA ;
• audit trail ;
• double vérification ;
• monitoring routinier.

L’output peut être classé comme :

• risque faible ;
• risque moyen ;
• risque élevé.

Il n’est pas nécessaire d’être sophistiqué. Il faut être cohérent, documenté et défendable.

3. Step 2 — Traduire le risque en stratégie de validation

La vraie valeur d’un VMP risk-based est de transformer le risque en stratégie opérationnelle.

De nombreux VMP déclarent le Quality Risk Management, mais n’expliquent pas ce qui change concrètement dans la pratique.

3.1 Risque élevé

Pour les systèmes, processus ou assets à risque élevé, la stratégie devrait prévoir :

• qualification ou validation complète ;
• testing sur worst case ;
• preuves robustes ;
• review QA indépendante ;
• critères d’acceptation stricts ;
• déviations gérées avec un niveau d’attention élevé ;
• periodic review structurée ;
• éventuelle requalification ou revalidation event-based ;
• lien fort avec le change control.

Exemples :

• utilities critiques ;
• systèmes informatisés GxP avec impact sur la libération ou la data integrity ;
• procédés stériles ;
• cleaning validation pour produits à haut risque ;
• equipment critique pour CPP/CQA.

3.2 Risque moyen

Pour les assets ou processus à risque moyen, la stratégie peut être plus ciblée.

Exemples d’approche :

• tests focalisés sur les paramètres critiques ;
• rationalisation des essais ;
• vérification des contrôles principaux ;
• review QA proportionnée ;
• documentation complète mais non excessive ;
• attention aux points sensibles ;
• periodic review basée sur les données et les trends.

L’objectif est de maintenir la maîtrise sans créer une documentation inutile.

3.3 Risque faible

Pour les éléments à faible risque, une vérification plus légère peut suffire.

Exemples :

• vérification de base ;
• contrôles procéduraux ;
• confirmation documentaire ;
• commissioning documenté, si approprié ;
• exclusion justifiée du scope GMP, si applicable ;
• review uniquement en cas de change pertinent.

Attention : risque faible ne signifie pas « aucun contrôle ». Cela signifie contrôle proportionné.

3.4 Le pont entre QRM et le plan opérationnel

La partie la plus importante consiste à relier chaque niveau de risque à une décision pratique.

Exemple de logique :

• risque élevé → testing complet et review robuste ;
• risque moyen → testing ciblé sur les paramètres critiques ;
• risque faible → vérification de base et contrôle procédural.

C’est le pont entre Quality Risk Management et le plan de validation. Et c’est précisément ce pont que de nombreux VMP ne parviennent pas à construire.

4. Step 3 — Lifecycle : validé une fois ne signifie pas validé pour toujours

Une erreur fréquente consiste à considérer la validation comme un événement ponctuel.

En réalité, un système validé aujourd’hui peut ne plus être sous contrôle demain si le processus change, si le logiciel change, si les composants changent ou si les trends se dégradent.

La validation doit être gérée tout au long du lifecycle.

4.1 Ce que le VMP doit expliquer

Le VMP doit décrire comment l’entreprise :

• maintient l’état validé ;
• surveille les performances ;
• évalue les trends et les déviations ;
• décide s’il faut requalifier ;
• décide s’il faut revalider ;
• intègre CPV, PQR/APR et periodic review ;
• relie change control et validation impact assessment ;
• gère l’obsolescence, les upgrades et les decommissionings.

4.2 Equipment critiques

Pour les equipment critiques, une policy durable peut être basée sur :

• periodic review ;
• triggers event-based ;
• trends de performance ;
• déviations pertinentes ;
• maintenances extraordinaires ;
• calibrations hors tolérance ;
• changes impactants ;
• utilisation du système.

Cette approche est souvent plus défendable qu’une requalification tous les 12 mois « quoi qu’il arrive », si le rationnel est bien documenté.

4.3 Processus de production

Pour les processus de production, le lifecycle devrait inclure :

• PPQ ;
• Continued Process Verification ;
• trends des paramètres critiques ;
• trends des déviations ;
• PQR/APR ;
• évaluation des CAPA ;
• monitoring de la capabilité du processus ;
• évaluation d’éventuels signaux de drift.

Le PQR/APR et le CPV doivent devenir de véritables inputs pour décider si le processus reste dans l’état validé.

4.4 Utilities critiques

Pour les utilities critiques, la stratégie peut inclure :

• qualification initiale ;
• monitoring routinier ;
• trends microbiologiques/chimiques/physiques ;
• periodic review ;
• deviation management ;
• preventive maintenance ;
• évaluation des changes ;
• éventuelle requalification ciblée.

Ici aussi, le principe est toujours le même : les données et le risque doivent guider les décisions.

5. Step 4 — Change Control : le point où l’on gagne ou l’on perd

Le change control est souvent le point où l’état validé est maintenu ou perdu.

Un change apparemment mineur peut avoir un impact sur les paramètres critiques, le logiciel, le data flow, les recettes, les matériaux, le cleaning ou les contrôles de processus.

5.1 Validation Impact Assessment

Un change control robuste doit toujours inclure une section de Validation Impact Assessment.

Cette section doit répondre à des questions telles que :

• Le système est-il validé ?
• Le change touche-t-il des paramètres critiques ?
• Le change touche-t-il des set-points ou recettes ?
• Le change modifie-t-il le data flow ou la data integrity ?
• Le change modifie-t-il des matériaux, composants ou configurations ?
• Le change impacte-t-il le cleaning, le processus ou les contrôles ?
• Des tests sont-ils nécessaires ?
• Une requalification est-elle nécessaire ?
• Une revalidation est-elle nécessaire ?
• Quels documents doivent être mis à jour ?
• Le VMP ou la master list doivent-ils être mis à jour ?

5.2 Bon exemple : décision proportionnée

Cas : remplacement d’une sonde de température sur un equipment validé.

Risk assessment :

• spécifications équivalentes ;
• aucune modification du principe de fonctionnement ;
• aucun impact sur la recette ou la logique de contrôle ;
• composant critique mais remplacé like-for-like.

Action proportionnée :

• calibration ;
• vérification fonctionnelle ;
• mise à jour des records ;
• évaluation documentée ;
• pas d’OQ complète si le rationnel démontre qu’elle n’est pas nécessaire.

C’est un exemple de décision proportionnée et défendable.

5.3 Mauvais exemple : finding presque certain

Cas : upgrade logiciel GxP réalisé par IT sans implication de QA/Validation.

Problèmes :

• aucun validation impact assessment ;
• aucune évaluation data integrity ;
• aucun testing documenté des fonctions critiques ;
• aucune audit trail review ;
• aucune mise à jour documentaire ;
• aucune preuve de l’état validé post-change.

Lors d’un audit, c’est un finding presque certain, car vous ne pouvez pas démontrer que le système est resté sous contrôle après le changement.

6. Step 5 — Systèmes informatisés : de la CSV documentaire à l’assurance basée sur le risque

Pour les systèmes informatisés GxP, le VMP doit éviter deux erreurs :

• traiter la CSV comme un dossier documentaire séparé du PQS ;
• tester tout de la même manière, sans distinguer les fonctions critiques et non critiques.

L’approche la plus mature repose sur l’assurance, le risque et la data integrity.

6.1 Identifier les fonctions critiques

Dans le VMP ou le CSV plan, il doit être clair comment les fonctions critiques sont identifiées.

Exemples :

• libération du produit ;
• calculs GMP ;
• gestion des recettes ;
• audit trail ;
• access management ;
• signatures électroniques ;
• data flow ;
• acquisition des données ;
• backup et restore ;
• interfaces avec d’autres systèmes ;
• rapports utilisés pour les décisions GMP.

6.2 Réaliser un testing robuste là où c’est nécessaire

Le testing le plus robuste doit se concentrer sur les fonctions qui peuvent impacter :

• qualité produit ;
• sécurité du patient ;
• data integrity ;
• compliance réglementaire ;
• décisions GMP.

Pour les fonctions à faible impact, la documentation peut être plus légère, à condition que le rationnel soit clair.

6.3 Simplifier sans perdre le contrôle

Une approche moderne ne signifie pas réduire le contrôle.

Elle signifie :

• éliminer les tests redondants ;
• utiliser les supplier evidence lorsque applicables ;
• focaliser le testing interne sur les fonctions critiques ;
• documenter le rationnel ;
• maintenir sous contrôle la data integrity, l’audit trail, les accès et les backups.

Le VMP doit montrer cette logique de manière claire et défendable.

7. Step 6 — KPI de validation pour les sites matures

Les KPI de validation ne sont pas toujours obligatoires, mais ils représentent un signe de maturité du site.

Si un inspecteur demande :

« Comment mesurez-vous l’efficacité du système de validation ? »

disposer de KPI bien choisis peut faire la différence.

7.1 KPI utiles

Exemples de KPI utiles :

• pourcentage de change controls avec validation impact assessment complété ;
• temps moyen de clôture des déviations de validation ;
• backlog de requalifications overdue ;
• pourcentage de periodic reviews complétées on-time ;
• trend des déviations par catégorie : equipment, IT, utilities, cleaning ;
• pourcentage de CAPA validation-related clôturées on-time ;
• nombre de requalifications générées par des changes ou des déviations ;
• nombre de gaps détectés pendant la periodic review.

7.2 Comment utiliser les KPI

Les KPI doivent conduire à des décisions.

Ils doivent être utilisés pour :

• identifier les backlogs ;
• assigner les priorités ;
• activer les escalades ;
• justifier les ressources ;
• améliorer la stratégie de maintien ;
• alimenter la Management Review ou le Quality Council.

Un KPI sans décision n’est qu’un chiffre. Un KPI qui guide des actions démontre la gouvernance.

8. Roadmap d’implémentation 30–60–90 jours

Si vous souhaitez rendre le VMP plus risk-based et lifecycle-oriented, vous pouvez suivre une roadmap progressive.

8.1 De 0 à 30 jours

Objectif : aligner la base documentaire.

Actions :

• aligner asset list, VMP, maintenance et calibrations ;
• vérifier la cohérence entre VMP et master list ;
• identifier les assets ou systèmes manquants ;
• formaliser la matrice de risque et les critères ;
• définir les catégories High / Medium / Low ;
• identifier les éventuels gaps critiques ;
• établir un owner pour chaque action.

8.2 De 31 à 60 jours

Objectif : intégrer le risque dans les processus opérationnels.

Actions :

• intégrer le validation impact assessment dans le change control ;
• mettre à jour les SOP de qualification et validation ;
• construire ou mettre à jour la Validation Master List ;
• assigner status et dates aux assets ;
• définir l’escalade pour les changes à haut impact ;
• relier change control, déviations et CAPA à la stratégie de validation.

8.3 De 61 à 90 jours

Objectif : rendre le système durable dans le lifecycle.

Actions :

• définir une policy de maintien de l’état validé ;
• établir les critères pour CPV, review, requalification et revalidation ;
• créer un package audit evidence par catégorie ;
• définir les KPI essentiels ;
• mettre en place la periodic review ;
• préparer des exemples réels de décisions risk-based ;
• intégrer le VMP avec la Management Review ou le Quality Council, si applicable.

9. FAQ sur le VMP risk-based

9.1 Quand dois-je revalider après un change ?

Vous devez revalider lorsque le change impacte des paramètres critiques, le contrôle du processus, le cleaning, la data integrity ou les stratégies de contrôle.

La décision doit être risk-based et documentée dans le change control via un validation impact assessment.

9.2 Risk-based signifie-t-il faire moins de tests ?

Non.

Risk-based signifie réaliser les bons tests là où le risque est réel, en évitant à la fois les gaps et la documentation inutile.

L’objectif n’est pas de réduire le travail, mais de le rendre proportionné, défendable et durable.

9.3 Puis-je utiliser la supplier documentation pour réduire le testing interne ?

Oui, mais uniquement si la documentation fournisseur est applicable, évaluée et reliée à votre usage spécifique.

Vous devez vérifier :

• scope du document ;
• version du système ou du composant ;
• conditions testées ;
• fonctions couvertes ;
• criticité GxP ;
• éventuels gaps par rapport à votre processus.

9.4 Comment démontrer que le lifecycle est sous contrôle ?

Vous pouvez le démontrer via :

• change control avec validation impact assessment ;
• periodic review ;
• CPV ;
• PQR/APR ;
• trending ;
• déviations/CAPA ;
• requalification ou revalidation documentées ;
• master list à jour ;
• KPI, si implémentés.

9.5 Comment éviter l’over-validation ?

Pour éviter l’over-validation, vous devez :

• définir des critères de risque clairs ;
• relier le risque au niveau de testing ;
• distinguer les fonctions critiques et non critiques ;
• utiliser les supplier evidence lorsque applicables ;
• éviter les tests redondants ;
• revoir périodiquement les backlogs et les activités non nécessaires.

10. Voulez-vous réellement appliquer risk-based et lifecycle à votre VMP ?

Si vous souhaitez réellement appliquer une approche risk-based et lifecycle-oriented avec des modèles prêts à l’emploi, tels que risk matrix, impact assessment, master list, lifecycle tracker et cas réels d’audit, vous trouverez tout dans la guide premium GuideGxP :

Validation Master Plan (VMP): Govern Validation and Defend It During Audits