Projets GMP : tester selon GAMP 5 sans perdre de temps

Dans un projet pharmaceutique, un système de contrôle n'est pas terminé quand il fonctionne. Il est terminé quand on a démontré qu'il fonctionne — de façon documentée et traçable, par rapport à des exigences approuvées.

GAMP 5 fournit le cadre : une approche de la validation des systèmes informatisés fondée sur les risques, construite autour des spécifications et des tests qui les vérifient. Tout l'enjeu est de l'appliquer sans transformer chaque séance de test en un débogage lent et lourd en papier. Voici notre démarche sur les projets DeltaV et Siemens.

1. Partir des URS, rédiger FS et DS en pensant traçabilité

Le cahier des charges utilisateur (URS) dit ce que le système doit faire. Nous le relisons tôt : une exigence ambiguë ou impossible à tester se corrige à moindre coût avant le début de la conception. La spécification fonctionnelle (FS) et la spécification de conception (DS) sont ensuite rédigées pour que chaque exigence puisse être suivie de bout en bout :

• chaque exigence de l'URS est couverte par des sections identifiées de la FS ;
• la DS décrit comment la configuration les met en œuvre : modules, séquences, alarmes, verrouillages ;
• les identifiants sont stables, pour qu'un test puisse renvoyer à une exigence sans ambiguïté.

La traçabilité se construit beaucoup plus facilement pendant la rédaction qu'après coup. L'approche fondée sur les risques oriente aussi l'effort : les fonctions qui ont un impact sur la qualité du produit et la sécurité du patient reçoivent les spécifications et les tests les plus détaillés.

2. Des protocoles de test rédigés à partir des spécifications

Chaque exigence a besoin d'un test qui la démontre. Les protocoles sont rédigés à partir de la FS et de la DS, avec :

• un objectif clair et la référence de la ou des exigences couvertes ;
• des prérequis et des instructions pas à pas ;
• des résultats attendus objectifs et observables — « XV-101 s'ouvre et son retour ouvert s'affiche », et non « le système fonctionne » ;
• la place pour les résultats obtenus, les preuves et les signatures, selon le système qualité du client.

Un protocole bien écrit peut être exécuté par quelqu'un qui ne l'a pas rédigé. C'est d'ailleurs un bon test du protocole lui-même.

3. Des essais à blanc sur la machine virtuelle

C'est là que nous gagnons le plus de temps. Avant l'exécution formelle, chaque protocole est déroulé de façon informelle — un essai à blanc — sur la machine virtuelle, avec la vraie configuration, les vrais synoptiques et un procédé simulé. L'essai à blanc révèle deux sortes de problèmes :

• des défauts de configuration, corrigés et revérifiés avant le début des tests formels ;
• des défauts de protocole : un résultat attendu erroné, un prérequis manquant, une étape impossible à exécuter telle qu'elle est écrite.

Sans essais à blanc, les tests formels tournent souvent au débogage : des écarts sont ouverts pour des problèmes qu'une simple répétition aurait détectés, et chacun doit être documenté, analysé et clôturé. Avec des essais à blanc, l'exécution formelle confirme un système dont on sait déjà qu'il fonctionne.

4. IQ et OQ avec une matrice de traçabilité complète

La qualification formelle suit ensuite le plan de validation du client. La qualification d'installation (IQ, ou QI) vérifie que le système est installé conformément aux spécifications : matériel, logiciel et configuration. La qualification opérationnelle (OQ, ou QO) vérifie qu'il fonctionne conformément aux spécifications, fonction par fonction. Tout au long, la matrice de traçabilité relie chaque exigence à ses sections de spécification, à ses protocoles de test et à leurs résultats.

À la fin, la matrice répond à la question que pose tout auditeur : chaque exigence a-t-elle été testée, et chaque test est-il conforme — ou l'écart est-il documenté et clôturé ?

5. Maintenir le système à l'état validé

La validation ne s'arrête pas à l'OQ. Chaque modification ultérieure passe par la maîtrise des changements : analyse d'impact, mise à jour des spécifications, retests ciblés et approbation documentée. Là aussi, la machine virtuelle reste utile : les modifications peuvent être répétées hors ligne avant d'être mises en œuvre sur le système validé. Sur DeltaV, les exports de configuration pris avant et après une modification documentent exactement ce qui a changé (voir notre article sur les exports FHX).

En résumé

Des spécifications rédigées en pensant traçabilité, des protocoles écrits à partir d'elles, des essais à blanc sur la machine virtuelle, puis l'IQ et l'OQ avec une matrice de traçabilité complète. Résultat : moins d'écarts, des dossiers de test plus propres et une équipe validation qui fait confiance au système. Nous avons l'expérience du GMP avec DeltaV en production de vaccins (GSK, Wavre). Découvrez nos prestations de validation GAMP 5.