Le malentendu qui génère des findings « gratuits »

« C’est une méthode officielle, donc elle fonctionne. »
En audit, cette phrase est une invitation au finding. Le guide souligne que l’absence de method verification fait partie des observations les plus fréquentes (« compendial methods not verified »), car une méthode — même compendiale — peut se comporter différemment dans votre laboratoire (équipements, réactifs, matrice, analystes, conditions environnementales).

Verification vs Validation : comment l’expliquer en 30 secondes (sans s’enliser)

En audit, il faut une distinction claire (pratique, non académique) :

• Method validation : vous démontrez qu’une méthode (souvent développée en interne ou significativement modifiée) est adaptée à son usage prévu.
• Method verification (compendiale) : vous démontrez que la méthode compendiale adoptée est exécutable et performante dans votre contexte réel (produit/matrice, équipements, set-up).

Quand la verification est pratiquement « non négociable »

D’un point de vue inspectif, le besoin de verification augmente lorsque :

• la matrice est complexe (huileuse, forte teneur en excipients, etc.) ;
• vous changez d’équipement/colonne/kit par rapport au contexte typique ;
• la méthode est critique pour le release (assay, impuretés, dissolution, microbiologie) ;
• vous avez apporté même de petites modifications opérationnelles (qui touchent néanmoins des paramètres critiques).

Structure du dossier « audit-proof » : ce qu’il doit contenir

Si vous voulez que la verification réponde immédiatement à la question de l’inspecteur, construisez-la comme un mini-dossier standardisé :

1) Page de garde + objectif + références

Produit/matériau, essai, référence compendiale (chapitre/monographie), version appliquée.
Déclaration d’intention : « Vérifier l’aptitude de la méthode compendiale dans les conditions du laboratoire ».

2) Gap assessment par rapport au compendium

• Ce que vous appliquez as is.
• Ce qui diffère (même s’il ne s’agit que d’une colonne équivalente, d’un réactif différent, d’un logiciel différent).
• Justification technique + risk statement.

Ce point est essentiel car le guide signale les écarts non documentés et les SOP génériques comme red flags.

3) Design expérimental (risk-based)

Le guide suggère une approche lean : répéter les études clés comme la précision/spécificité et, lorsque pertinent, la linéarité.

Exemple de set minimal (à adapter à l’essai) :

• Précision (repeatability) : réplicats sur échantillon réel (et/ou standard dopé).
• Spécificité : interférences de matrice/impuretés connues lorsque applicable.
• Linearity/range : si la méthode est quantitative et que le risque l’exige (par exemple assay).
• System suitability : démontrer que les critères compendiaux sont atteints et enregistrés (SST records toujours disponibles).

4) Acceptance criteria « défendables »

Règle d’or : définir les critères avant d’exécuter l’étude, et non après.
Si l’inspecteur entend « nous avons regardé et cela semblait correct », la probabilité d’un finding augmente.

5) Exécution + raw data + déviations

• Raw data complètes (chromatogrammes, intégrations, calculs, logs instrument).
• Gestion des déviations (si quelque chose se produit pendant l’étude, cela doit être tracé).

6) Rapport + conclusion + approbations

• Conclusion claire : « Méthode adaptée / adaptée avec limitations / non adaptée ».
• Approbation QA.
• Formation des analystes et date de go-live.

Les 5 red flags qui déclenchent des questions en cascade

D’après le guide, les plus fréquents sont :

• Déviations non documentées (« nous avons changé la phase mobile/la colonne parce que cela fonctionne comme ça »).
• Version pharmacopéique non à jour.
• SST non enregistrée ou non archivée.
• SOP trop générique (non reproductible).
• Personnel non formé (incapable d’expliquer les différences et la justification).

« Nous avons dû adapter la méthode » : comment le dire sans marquer contre son camp

Si vous avez modifié quelque chose, le guide est clair : sans justification et sans données comparatives, c’est un finding typique.

En audit, la formule la plus sûre est :

• Je déclare la différence (transparence).
• Je montre la justification (scientifique).
• Je montre les données (comparability/verification/validation).
• Je montre la gouvernance QA (change control + approbations).
• Je montre que l’impact réglementaire a été géré (si applicable).

Mini-script : questions d’inspection et « bonnes » réponses

Q : « Où est la verification de la méthode USP/Ph. Eur. ? »
R : « Nous avons un dossier de verification pour chaque méthode compendiale critique : voici le protocole, les raw data et le rapport approuvé par le QA. Nous avons vérifié les paramètres les plus à risque dans notre contexte. »

Q : « Pourquoi utilisez-vous une colonne différente ? »
R : « C’est une colonne équivalente ; nous avons documenté l’évaluation et démontré que la SST et la performance sont comparables. Voici les données comparatives et le change control. »

Checklist rapide (à afficher dans le laboratoire)

• J’ai identifié la version compendiale correcte et en vigueur
• J’ai réalisé le gap assessment et documenté les différences
• J’ai défini les acceptance criteria avant l’exécution
• J’ai archivé raw data + SST + calculs
• Le QA a approuvé le rapport et le go-live
• La formation est terminée et enregistrée

Si vous souhaitez un support prêt à l’emploi pour construire des dossiers défendables (structure, checklists et logique d’inspection), le guide complet contient la feuille de route et des exemples pratiques pour se préparer aux inspections multi-région.