Sommaire de l’article
La Commission européenne a consulté les parties prenantes du 7 juillet au 7 octobre 2025 sur une révision du chapitre 4, de l’Annexe 11 et sur une nouvelle Annexe 22. Au 30 août 2026, la page officielle affiche la consultation comme close et continue de présenter l’Annexe 11 révisée comme un projet. L’actuelle Annexe 11 reste donc le texte publié à appliquer jusqu’à remplacement officiel.
Le projet est néanmoins un signal de supervision précis. Il approfondit la gestion du cycle de vie, les exigences maintenues, les fournisseurs et services externalisés, les alarmes, la validation fondée sur le risque, les transferts et migrations, les identités, audit trails, signatures, revues périodiques, sécurité, sauvegarde et archivage.
La stratégie raisonnable consiste à utiliser ce projet comme scénario de test : identifier les contrôles utiles dans tous les cas, distinguer les écarts par rapport au texte actuel et éviter les investissements irréversibles lorsque la formulation finale peut encore changer.
Partie 1 — Replacer la validation dans le cycle de vie
Le projet décrit des exigences système maintenues à jour comme base de la qualification et de la validation. Il insiste sur la traçabilité entre exigence, conception et cas de test, y compris pour un logiciel configuré, développé de façon itérative ou fourni comme service.
Cette logique déplace la preuve d’un dossier de mise en service vers un système de décisions versionnées. Une modification de configuration, de plateforme, d’interface ou de rôle peut invalider une partie de la preuve initiale. La revue périodique doit donc examiner les changements cumulés, incidents, CAPA, accès, audit trails, contrats, sauvegardes, restaurations et menaces nouvelles.
Partie 2 — Rendre les frontières fournisseur inspectables
Le projet est explicite : faire qualifier ou exploiter un système par un fournisseur, un service cloud ou une équipe IT interne ne transfère pas la responsabilité du détenteur réglementé. Les contrats et procédures doivent couvrir livrables, incidents, niveaux de service, audits, soutien à l’inspection, communication des problèmes qualité et sécurité, versions et stratégie de sortie.
La preuve doit être accessible et explicable depuis l’établissement réglementé. Cela change la question fournisseur : non pas « le service est-il certifié ? », mais « pouvons-nous démontrer la version utilisée, les contrôles dont nous dépendons, les changements qui nous affectent, la récupération de nos données et le soutien disponible pendant une inspection ? »
Une stratégie de sortie n’est pas un paragraphe contractuel. Elle doit être exercée sur un périmètre représentatif : export, métadonnées, audit trail, format lisible, délai, responsabilités et vérification que le système de destination conserve le sens.
Partie 3 — Tester les contrôles qui prouvent l’intégrité
Le projet détaille un audit trail enregistrant qui, quoi, quand et pourquoi, activé et verrouillé, consultable et revu selon le risque. Il propose une revue indépendante et ciblée, généralement avant libération du lot lorsque le risque d’une détection tardive n’est pas justifié. Un export plat non interrogeable est explicitement insuffisant dans le projet.
La sécurité et la continuité deviennent aussi des objets de preuve : authentification forte pour certains accès distants, moindre privilège, journaux d’accès, correctifs, isolement des plateformes non supportées, réplication, plan de reprise et objectifs de temps de récupération. Une sauvegarde déclarée réussie ne démontre pas la restauration ; le projet demande que les revues périodiques considèrent l’adéquation des tests de restauration.
Un système GMP est en état validé lorsque sa version réelle, ses dépendances, ses accès, ses changements et sa capacité de restauration restent reliés à des preuves actuelles.
Contrôle opérationnel — changements à faible regret
- Mettre à jour les exigences système et leur traçabilité vers risques, conception et tests.
- Inventorier services externalisés, responsabilités conservées, preuves accessibles et stratégie de sortie testée.
- Vérifier que les audit trails critiques sont activés, protégés, interrogeables et revus selon une procédure.
- Tester une restauration représentative avec données, métadonnées, droits et journal d’audit.
- Séparer dans le plan les obligations actuelles, les contrôles volontaires et les hypothèses propres au projet 2025.
Graphe de décision — faut-il implémenter un point du projet ?
| Étape | Question | Suite |
|---|---|---|
| 1. Source | Le point existe-t-il déjà dans l’Annexe 11 actuelle ou un autre texte applicable ? | Oui → traiter comme exigence actuelle. Non → continuer. |
| 2. Risque | Le contrôle réduit-il un risque actuel pour produit, patient ou intégrité des données ? | Oui → candidat à faible regret. Non → surveiller. |
| 3. Réversibilité | Peut-il être déployé sans enfermer l’architecture dans une formulation de projet ? | Non → attendre le texte final. Oui → piloter. |
| 4. Preuve | Le pilote produit-il une preuve mesurable de fonctionnement ? | Non → revoir le contrôle. Oui → inscrire au cycle de vie. |
Informations manquantes et limites
- La formulation finale, la date d’adoption et toute période de transition n’étaient pas publiées à la date limite de preuve.
- Le projet doit être lu avec le chapitre 4 révisé et le projet d’Annexe 22, sans anticiper leur adoption inchangée.
- La fréquence et la profondeur des revues restent fondées sur le risque et dépendent du système et du procédé.
Sources primaires citées
- Commission européenne. Consultation on revised Chapter 4, Annex 11 and new Annex 22 — statut et calendrier de consultation
- Commission européenne / PIC/S. Draft revised Annex 11 — Computerised Systems — projet de consultation, juillet 2025
- Commission européenne. Annex 11 — Computerised Systems — version actuellement publiée
Date limite de vérification : 30 août 2026.
The European Commission consulted stakeholders from July 7 to October 7, 2025 on revised Chapter 4 and Annex 11 and a new Annex 22. As of August 30, 2026, the official page marks the consultation closed and still presents revised Annex 11 as a draft. The currently published Annex 11 therefore remains applicable until an official replacement.
The draft is nevertheless a precise supervisory signal. It expands lifecycle management, maintained requirements, suppliers and outsourced services, alarms, risk-based validation, transfer and migration, identity, audit trails, signatures, periodic review, security, backup, and archiving.
A reasonable strategy uses the draft as a challenge scenario: identify controls that are useful under any final wording, distinguish gaps against current text, and avoid irreversible investment where final language may still change.
Part 1 — Put validation back into the lifecycle
The draft describes maintained system requirements as the basis for qualification and validation. It stresses traceability between requirement, design, and test case, including for configured software, iterative development, and software provided as a service.
This logic moves evidence from a commissioning binder into a system of versioned decisions. A configuration, platform, interface, or role change can invalidate part of the original evidence. Periodic review therefore examines cumulative changes, incidents, CAPA, access, audit trails, contracts, backup, restore, and new threats.
Part 2 — Make supplier boundaries inspectable
The draft is explicit: qualification or operation by a vendor, cloud service, or internal IT team does not transfer the regulated user’s responsibility. Contracts and procedures cover deliverables, incidents, service levels, audits, inspection support, quality and security communication, versions, and exit strategy.
Evidence should be accessible and explainable from the regulated site. This changes the vendor question from “is the service certified?” to “can we demonstrate the version used, the controls we rely on, changes that affect us, recovery of our data, and support available during inspection?”
An exit strategy is not a contract paragraph. Exercise it on a representative scope: export, metadata, audit trail, readable format, timing, responsibilities, and verification that the receiving system preserves meaning.
Part 3 — Test the controls that prove integrity
The draft details an audit trail that records who, what, when, and why; remains enabled and locked; can be searched; and is reviewed according to risk. It proposes independent, targeted review, generally before batch release unless later detection is justified. A flat, locked, non-searchable export is explicitly insufficient in the draft.
Security and continuity also become evidence objects: strong authentication for certain remote access, least privilege, access logs, patching, isolation of unsupported platforms, replication, disaster recovery, and recovery-time objectives. A successful backup status does not prove restoration; the draft expects periodic review to consider restore-test adequacy.
A GMP system remains validated when its real version, dependencies, access, changes, and restore capability stay connected to current evidence.
Operational control — low-regret changes
- Maintain system requirements and traceability to risks, design, and tests.
- Inventory outsourced services, retained responsibility, accessible evidence, and tested exit strategy.
- Verify that critical audit trails are enabled, protected, searchable, and reviewed under procedure.
- Test a representative restore including data, metadata, permissions, and audit trail.
- Separate current duties, voluntary controls, and assumptions specific to the 2025 draft.
Decision graph — should a draft item be implemented?
| Step | Question | Next action |
|---|---|---|
| 1. Source | Does the item already exist in current Annex 11 or another applicable text? | Yes → manage as a current requirement. No → continue. |
| 2. Risk | Does the control reduce a current product, patient, or data-integrity risk? | Yes → low-regret candidate. No → monitor. |
| 3. Reversibility | Can it be deployed without locking architecture to draft wording? | No → await final text. Yes → pilot. |
| 4. Evidence | Does the pilot produce measurable evidence that the control works? | No → redesign the control. Yes → add it to lifecycle management. |
Missing information and limits
- Final wording, adoption date, and any transition period were not published by the evidence cut-off.
- The draft should be read with revised Chapter 4 and draft Annex 22 without assuming unchanged adoption.
- Review frequency and depth remain risk-based and depend on the system and process.
Primary sources cited
- European Commission. Consultation on revised Chapter 4, Annex 11 and new Annex 22 — consultation status and timetable
- European Commission / PIC/S. Draft revised Annex 11 — Computerised Systems — consultation draft, July 2025
- European Commission. Annex 11 — Computerised Systems — currently published version
Evidence cut-off : August 30, 2026.
Voir aussi
- Pharmaceutical Evidence-to-Decision Assurance Le mandat qui relie donnée régulée, décision et dossier d’inspection.
- Data & outillage Outils systèmes, indexation et persistance vérifiables, écrits pour durer.
- Calculateur de mission Chiffrer l’enveloppe de ce type de mission, calcul local et reproductible.