Gestion des Déviations GMP : le processus audit-proof qui résiste réellement lors d’une inspection

Les déviations ne sont pas de la bureaucratie : elles sont le test de résistance de votre Pharmaceutical Quality System (PQS). Lors d’un audit, un inspecteur n’évalue pas seulement « si vous avez ouvert une déviation », mais si vous avez démontré la maîtrise, la capacité d’apprentissage et, surtout, la protection du patient.

S’il y a un principe directeur à retenir, c’est celui-ci :

Une déviation mal gérée n’est pas un événement isolé : c’est un indicateur du système.

Dans ce guide pratique, nous verrons comment construire un processus end-to-end pragmatique et défendable, avec des checklists et des formulations qui fonctionnent lors d’un audit, ainsi que celles qui peuvent vous faire perdre en crédibilité.

Table des matières

• Déviation, événement, non-conformité : ce qui compte vraiment
• Les 5 phases de la gestion des déviations
• Classification de la sévérité et escalade : la logique risk-based
• Impact assessment : décider du lot sans « espérer »
• Investigation : ce qu’il faut collecter immédiatement avant que les données disparaissent
• Quand une déviation devient systémique
• Comment présenter une déviation lors d’un audit : le script en 90 secondes
• Checklists opérationnelles
• FAQ sur la gestion des déviations GMP

Déviation, événement, non-conformité : ce qui compte vraiment

Dans une entreprise, vous entendrez des termes comme « événement », « incident », « déviation » ou « non-conformité ». Les définitions aident, mais elles ne vous sauvent pas lors d’un audit.

Ce qui compte pour l’inspecteur est simple :

• Quelque chose d’inattendu s’est-il produit par rapport à une procédure approuvée, une spécification ou une exigence GMP ?
• Existe-t-il un impact réel ou potentiel sur la qualité du produit, la data integrity, la sécurité du patient ou la compliance ?
• Avez-vous réagi rapidement, de manière proportionnée et documentée ?

Un système mature peut avoir une catégorie telle que « incident » ou « near miss » pour les événements sans impact. C’est parfaitement acceptable, mais uniquement si :

• la logique est définie à l’avance dans la SOP ;
• la décision « ce n’est pas une déviation » est justifiée, et non supposée ;
• la donnée alimente tout de même le trending afin d’identifier les patterns.

Red flag typique

Reclasser comme « incident » un événement qui aurait pu avoir un impact, uniquement pour éviter l’ouverture formelle d’une déviation.

Les 5 phases de la gestion des déviations

Phase 1 — Signalement immédiat et culture

La première véritable barrière est culturelle : si l’opérateur a peur de signaler, le système perd des informations — et vous perdez le contrôle.

L’objectif opérationnel est de signaler immédiatement, même avec des informations incomplètes, puis de compléter les détails par la suite.

Ce qui fonctionne lors d’un audit

« Nous préférons sur-signaler, puis classifier selon une approche risk-based. »

Ce qui ne fonctionne pas lors d’un audit

« Nous attendons de comprendre si c’est grave avant de l’enregistrer. »

Phase 2 — Containment : sécuriser la situation avant d’investiguer

Avant même la root cause analysis, vous devez démontrer que vous avez :

• isolé les produits, intermédiaires ou matières potentiellement impliqués ;
• arrêté ou mis en hold la phase critique du processus, si nécessaire ;
• bloqué toute libération ou expédition potentielle ;
• préservé les preuves telles que logs, échantillons et données brutes.

Règle pratique : si quelqu’un vous demande plus tard « Qu’avez-vous fait dans les 2 premières heures ? », vous devez avoir une réponse documentée.

Phase 3 — Classification de la sévérité

La classification n’est pas un exercice esthétique : elle pilote les priorités, l’escalade, les ressources et les délais.

Un modèle robuste utilise une logique risk-based fondée sur :

• la sévérité, c’est-à-dire l’impact potentiel ;
• la probabilité, c’est-à-dire la récurrence ou la probabilité d’occurrence ;
• la détectabilité, c’est-à-dire la capacité du système à détecter le problème avant qu’il n’ait un impact.

Il n’est pas nécessaire de tout transformer en mathématiques. En revanche, il faut de la cohérence et une justification claire. Si vous utilisez un RPN ou des matrices, très bien : l’essentiel est que la classification soit défendable et non opportuniste.

Red flag typique

« Tout est Minor » avec de nombreuses déviations répétées est un signal faible lors d’un audit : l’inspecteur comprend que le système joue avec les étiquettes.

Phase 4 — Investigation proportionnée au risque

C’est ici que se décide la crédibilité du PQS. Clôturer une déviation avec « human error » sans investiguer plus profondément est une invitation à recevoir une observation.

Une approche correcte inclut :

• la reconstruction chronologique des faits ;
• la collecte de données objectives ;
• des hypothèses générées et vérifiées ;
• une root cause contrôlable, ou plusieurs causes si cela est réaliste.

Phase 5 — Clôture : CAPA, effectiveness et trending

Clôturer ne signifie pas « remplir tous les champs ». Cela signifie démontrer que :

• le risque a été géré ;
• les actions ont été mises en œuvre avec des preuves ;
• l’efficacité sera vérifiée ou a déjà été vérifiée ;
• le système surveille les récurrences via le trending.

Classification de la sévérité et escalade : une logique qui ne vous trahit pas lors d’un audit

Une classification audit-proof doit être claire, proportionnée et cohérente avec le risque.

Déviation critique

Elle nécessite l’implication immédiate du QA Head/QP, d’une équipe cross-functional, une décision concernant d’éventuels lots déjà distribués et une évaluation des communications réglementaires, si applicable.

Déviation majeure

Elle nécessite une investigation approfondie, une CAPA formelle, une information à la site leadership et une évaluation de l’extension à d’autres lots, produits ou processus.

Déviation mineure

Elle nécessite une correction documentée, un impact assessment et un trending. Si elle est récurrente, elle doit être escaladée.

Point clé

Une déviation mineure récurrente ne reste pas mineure. Elle devient un symptôme.

Impact assessment : décider du lot sans « espérer »

C’est ici que beaucoup d’entreprises échouent. L’inspecteur veut voir que vous n’avez pas « interprété » l’impact : vous l’avez démontré.

Un impact assessment robuste répond à ces questions :

• Quels lots, intermédiaires ou matières sont potentiellement impliqués ?
• Quel est le worst case réaliste ?
• Existe-t-il des barrières qui rendent l’impact improbable ? Quelles preuves le démontrent ?
• Des tests supplémentaires, des échantillonnages ciblés ou des évaluations des hold times sont-ils nécessaires ?
• Le lot peut-il être libéré, rejeté ou retraité ? Avec quelle justification ?

Ce qui fonctionne lors d’un audit

« Nous avons défini le scénario, les données disponibles, les gaps et les actions pour clôturer ces gaps. »

Ce qui ne fonctionne pas lors d’un audit

« Selon nous, il n’y a pas d’impact. »

Investigation : ce qu’il faut collecter immédiatement avant que cela disparaisse

Les premières 24 heures déterminent la qualité de la root cause analysis. Plus vous attendez, plus vous risquez de perdre des données, la mémoire des opérateurs et la traçabilité.

Checklist des données typiques à collecter

• batch record et annotations originales, non recopiées ;
• machine logs et alarmes ;
• tendances des paramètres critiques ;
• données EM/cleanroom, si pertinentes ;
• déviations récentes liées ;
• entretiens courts avec les opérateurs, tant que la mémoire est encore fraîche ;
• échantillons conservés ou matière suspecte, si pertinent.

Conseil pratique

Créez un « evidence pack » standard par type de déviation : production, QC, stérile, data integrity. Cela vous fera gagner des jours et rendra le processus beaucoup plus robuste lors d’un audit.

Quand une déviation est le symptôme d’un problème systémique

Une déviation ne doit pas être lue uniquement comme un événement isolé. Dans de nombreux cas, la vraie valeur consiste à comprendre ce qu’elle révèle sur le système.

Indicateurs typiques d’un problème systémique

• récurrence du même failure mode ;
• trop de root causes concluant à « human error » ;
• même pattern dans différents départements ;
• causes éloignées du point d’occurrence, par exemple procédure ambiguë, formation inefficace, maintenance insuffisante ou supplier quality faible ;
• nombreuses déviations mineures similaires qui, ensemble, révèlent un problème plus important.

Lorsque vous voyez ces signaux, la bonne réponse n’est pas « rappel + training ». C’est une CAPA de système.

Comment présenter une déviation lors d’un audit : le script en 90 secondes

Utilisez toujours cette séquence. Elle fonctionne parce qu’elle suit la manière naturelle dont raisonne un inspecteur.

1. Ce qui s’est passé

Décrivez les faits, pas les opinions.

2. Comment vous l’avez découvert

Montrez quel contrôle a fonctionné.

3. Ce que vous avez fait immédiatement

Expliquez le containment, la protection du patient et les actions immédiates.

4. Ce que vous avez investigué

Décrivez la méthode, les données collectées et les hypothèses vérifiées.

5. Root cause

Présentez une cause contrôlable, non vague.

6. Actions

Distinguez correction, corrective action et preventive action.

7. Efficacité

Expliquez comment vous mesurerez l’efficacité des actions.

8. Résultat

Montrez les tendances, l’absence de récurrence ou le follow-up planifié.

Checklists opérationnelles

Checklist « Premières 2 heures »

• Signalement enregistré, même préliminaire
• Produit ou lot mis en hold et ségrégué
• Processus arrêté ou mis en hold en cas de risque potentiel
• QA informée et ownership défini
• Preuves préservées : logs, données brutes, échantillons
• Impact assessment préliminaire documenté
• Décision d’escalade documentée : qui doit être informé et pourquoi

Checklist « Avant clôture »

• Root cause décrite avec preuves
• Actions liées à la cause, avec traçabilité claire
• Evidence of completion disponible
• Plan d’effectiveness check défini
• Évaluation des tendances et récurrences mise à jour
• Change control ouvert et lié, si nécessaire

FAQ sur la gestion des déviations GMP

Une déviation peut-elle être clôturée sans root cause certaine ?

Oui, mais c’est une zone sensible. Vous devez démontrer que vous avez investigué autant que raisonnablement possible et que vous avez tout de même mis en place des mesures préventives proportionnées aux risques résiduels.

Quand une déviation Minor nécessite-t-elle une CAPA ?

Lorsqu’elle est récurrente, lorsqu’elle révèle un gap de système ou lorsque le trending montre un pattern. La sévérité ne se limite pas à l’événement : elle dépend aussi de l’historique de cet événement dans le temps.

Quelle est l’erreur la plus fréquente lors d’un audit ?

Sous-estimer l’impact et la récurrence, clôturer avec un training générique et ne pas disposer de preuve d’efficacité.

Voulez-vous transformer ce processus en un système prêt pour l’inspection ?

Voulez-vous transformer ce processus en un système prêt pour l’inspection, avec des templates, des checklists opérationnelles, des exemples réels et des red flags déjà traduits en contre-mesures ?

Téléchargez la guide premium sur GuideGxP :

QA Manager Operational Guide – Deviation, CAPA, and Audit Readiness