Inspection Readiness GMP : Playbook du QA Manager Pharma
Inspection Readiness GMP : le playbook opérationnel du QA Manager (AIFA/EMA/FDA)
La scène réelle qui décide de l’issue de l’inspection
Si vous avez déjà accueilli une inspection, vous le savez :
ce n’est pas le site qui a le plus de documents qui gagne, mais celui qui sait démontrer la maîtrise.
Les questions qui séparent les sites matures des sites fragiles arrivent souvent dès la première heure :
- « Montrez-moi les tendances des déviations et l’aging des CAPA des 12 derniers mois. »
- « Quel est votre processus d’escalade ? »
- « Qui est propriétaire du PQS et comment est-il revu en Management Review ? »
- « Montrez-moi un exemple de batch disposition avec des points critiques et comment la décision a été prise. »
📌 En audit, le problème le plus fréquent que j’observe est le suivant :
le site est document-ready (tout existe), mais pas inspection-ready (personne ne sait expliquer de manière cohérente pourquoi le système fonctionne et où l’on voit les signaux de maîtrise).
Ce qui suit est un playbook pratique pour les QA Managers, construit autour des points que les inspecteurs testent réellement sur le terrain.
1) L’Inspection Readiness n’est pas un événement : c’est un système
Si une inspection vous oblige à « courir », votre programme d’inspection readiness n’est pas intégré au travail quotidien.
Signes que vous êtes prêt :
- Les self-inspections (EU GMP Chapitre 9) génèrent des CAPA robustes, clôturées avec effectiveness check
- Le PQR/APR n’est pas un exercice de « remplissage », mais conduit à des décisions (changements, formations, investissements)
- Les départements savent expliquer pourquoi une SOP dit ce qu’elle dit (et pas seulement « parce que le QA l’exige »)
- Des evidence packages sont déjà prêts pour les zones à haut risque
✅ À retenir :
L’inspecteur ne cherche pas la perfection. Il cherche la gouvernance :
comment vous identifiez les risques, comment vous les maîtrisez et comment vous apprenez lorsque quelque chose dysfonctionne.
2) Timeline opérationnelle : quoi préparer — et quand
Une timeline réduit le stress et, surtout, évite les « trous » qui deviennent des findings.
Tableau — Timeline Inspection Readiness (prête à intégrer dans un plan)
| Quand | Objectif | Livrables audit-proof | Erreur typique |
|---|---|---|---|
| T-90 / T-60 | Identifier les zones à haut risque | Risk assessment (ICH Q9), heatmap des risques, top-10 gaps | Tout traiter de la même façon (non risk-based) |
| T-45 | Stabiliser les preuves | PQR/APR à jour, tendances de déviations, backlog CAPA, change log | PQR signé mais non « utilisé » |
| T-30 | Simuler l’inspection | Mock inspection, liste de questions, formation « comment répondre » | Mock audit vitrine, sans suivi |
| T-7 | Préparer l’hosting | War room, rôles, request log, set documentaire | Rôles confus, « tout le monde parle » |
| Jours d’inspection | Contrôler le flux | Front room/back room, daily debrief, issue log | Fournir des documents non vérifiés |
| T+15 (typique) | Répondre | CAPA letter / 483 response avec plan crédible | Promettre trop ou délais irréalistes |
| Post-inspection | Exécuter | Clôture des preuves + effectiveness | Clôturer « sur le papier » uniquement |
3) Structure d’hosting : Front Room / Back Room / Request Log
Des rôles qui réduisent les erreurs (et les observations inutiles)
- Lead host (QA) : gère l’agenda, le ton, les priorités et l’escalade
- Scribe (note-taker) : consigne questions et réponses verbatim, numérote les demandes
- Runner : récupère les documents (avec contrôle de version)
- SME (Subject Matter Expert) : répond uniquement dans son périmètre
- Document controller : vérifie la version, l’exhaustivité, les annexes et la redaction minimale
📌 La faille la plus courante en audit est le « document remis dans l’urgence » :
pages manquantes, annexes obsolètes, logbooks avec corrections non expliquées ou, pire, des enregistrements qui ouvrent une déviation « dormante ».
Le Request Log qui « sauve » l’inspection
Un request log bien géré évite :
- les demandes perdues
- les remises en double
- les réponses incohérentes entre départements
Contenu minimal du log :
ID de la demande, heure, inspecteur, description, owner, ETA de remise, remis oui/non, notes de suivi.
4) Gemba walk : comment éviter les « findings de couloir »
De nombreux findings ne naissent pas de la revue documentaire, mais lors des visites terrain.
Là où l’inspecteur « sent » la faiblesse du système :
- étiquetage de statut incohérent (quarantaine/libéré/rejeté)
- line clearance réalisée « de mémoire »
- logbooks avec des trous ou des écritures identiques (red flag)
- ségrégation physique/logique insuffisante (matériaux, déchets, retours)
- gowning et comportements non standardisés (même hors zones stériles)
✅ À retenir :
La production pense opérations.
L’inspecteur pense répétabilité.
Le QA doit aligner les deux.
5) Les 7 règles d’or pour remettre des documents sans se faire mal
- Ne jamais remettre d’originaux : uniquement des copies contrôlées (ou PDF « view-only »).
- Contrôle de version : même révision en salle et sur le terrain.
- Contrôle d’exhaustivité : annexes, références, appendices.
- Pas d’informations supplémentaires non demandées : moins de surface d’attaque.
- Traçabilité : qui a extrait le document, quand et depuis quel système (EDMS/eQMS/LIMS/MES).
- Cohérence narrative : un trend doit être lié à des décisions (CAPA, change, formation).
- Zéro improvisation : si vous ne savez pas, « nous vérifions et revenons » (avec ETA dans le request log).
6) Closing meeting et réponse : comment rédiger une CAPA letter crédible
Une réponse faible n’est pas seulement « mauvaise » : elle est dangereuse, car elle crée des attentes vérifiables.
Une structure qui fonctionne (et résiste à un re-audit) :
- Acknowledge : reconnaître l’observation (sans défense réflexe)
- Immediate containment : actions immédiates pour reprendre le contrôle
- Root cause : systémique, pas « erreur humaine »
- CAPA : actions, responsables, délais, livrables
- Effectiveness check : quand et comment démontrer l’efficacité
- Risk assessment : impact sur lots/patients, escalade si nécessaire
📌 Insight contrarien (mythe à déconstruire) : « Il suffit de répondre vite. »
Répondre vite avec des CAPA génériques (« re-training ») crée des récidives.
Mieux vaut répondre avec peu d’actions, mais mesurables (ex. mise à jour SOP + évaluation des compétences + vérification terrain + audit ciblé).
Checklist « 30 secondes »
- Request log prêt et assigné
- Evidence package : PQR/APR, tendances des déviations, CAPA aging, change log
- Rôles : host / scribe / runner / SME / document control
- Parcours terrain : status labels, ségrégation, logbooks, line clearance
- Plan de réponse : draft de CAPA letter / 483 response
FAQ
- Qui doit parler à l’inspecteur pendant une inspection GMP ?
Idéalement une voix principale (QA host), et des SME uniquement si nécessaire. Trop d’interlocuteurs augmentent les incohérences. - Quelle quantité de matériel montrer ?
Uniquement ce qui est demandé et ce qui est nécessaire pour contextualiser. L’over-sharing augmente les findings. - Qu’est-ce qui rend une CAPA « faible » aux yeux de l’inspecteur ?
Une CAPA non mesurable, sans effectiveness check ou avec une root cause « humaine » non étayée.
Si vous souhaitez transformer ce playbook en toolkit opérationnel (checklists d’hosting, templates de request log, structure de réponse CAPA), la guide complète sur le rôle du QA Manager est la référence interne la plus utile.