Gestion du changement dans les projets CSV : assurer le contrôle, la conformité et la continuité tout au long du cycle de vie du système
La gestion du changement dans les projets CSV est le processus contrôlé d’évaluation, de documentation, de test et d’approbation de chaque modification apportée à un système informatique validé, afin qu’il continue de répondre aux exigences GxP après le changement. Dans les environnements réglementés, même un changement mineur et apparemment routinier peut affecter l’intégrité des données, la qualité du produit et, en fin de compte, la sécurité des patients.
Les exigences évoluent, de nouveaux risques apparaissent, les processus mûrissent et la technologie progresse. Le changement est inévitable dans tout système informatique et dans son projet de validation de système informatique (CSV). Ce qui diffère entre les organisations, c’est si ce changement est contrôlé ou s’il passe par des pratiques informelles ou non contrôlées.
La gestion du changement dans les environnements réglementés par les GxP est régie par plusieurs cadres établis :
- Annexe 11 des BPF de l’UE : qui définit les attentes pour les systèmes informatisés utilisés dans les activités réglementées par les BPF, y compris l’application de la gestion des risques tout au long du cycle de vie d’un système informatisé, comme c’est le cas pour les changements.
- FDA 21 CFR Part 11 : qui régit les enregistrements électroniques et les signatures électroniques et exige des contrôles pour garantir l’intégrité du système, la fiabilité des données et le maintien de l’état validé des systèmes informatisés.
- FDA Guidance for Industry : Computerized Systems Used in Clinical Trials, qui comprend une section dédiée au contrôle des changements et souligne la nécessité de procédures documentées pour gérer les modifications du système, maintenir le contrôle des versions et préserver l’intégrité des données.
- ICH Q10 Système de qualité pharmaceutique : l’un des piliers réglementaires clés du système de qualité pharmaceutique, qui établit la gestion du changement comme un élément essentiel du système de qualité pharmaceutique (PQS) et exige que les changements soient évalués, documentés, approuvés et mis en œuvre selon une approche basée sur le risque.
- ICH Q9 (Gestion des risques liés à la qualité) : qui fournit l’approche basée sur le risque utilisée pour évaluer l’impact du changement.
- GAMP 5 Deuxième Édition : qui offre des conseils pratiques sur l’application d’une approche basée sur le risque pour la conformité des systèmes informatisés.
Ces cadres exigent que les modifications apportées aux systèmes validés soient contrôlées, évaluées, documentées et mises en œuvre de manière à préserver l’état validé. Sans un processus robuste, les organisations peuvent être confrontées à des incohérences, des observations d’audit, des risques de conformité et des perturbations opérationnelles.
Cet article présente les composantes essentielles de la gestion du changement au sein des projets CSV et fournit des conseils pratiques sur le maintien du contrôle tout au long du cycle de vie du système, sur la base de la vaste expérience de Rephine acquise au fil des années en accompagnant les entreprises des sciences de la vie dans leurs services de CSV et de conformité.
Pourquoi la gestion du changement est importante dans la CSV
Les systèmes informatisés fonctionnant dans des environnements réglementés par les GxP ne sont pas statiques. Les exigences commerciales évoluent, les éditeurs de logiciels publient des mises à jour, des modifications d’infrastructure sont mises en œuvre et de nouvelles attentes réglementaires apparaissent. Chacune de ces modifications est susceptible d’affecter la fonctionnalité du système, l’intégrité des données, la sécurité et la conformité.
Sans un processus formel de gestion du changement, les organisations peuvent introduire, entre autres, les risques suivants :
- Perte de l’état validé du système informatisé, entraînant une documentation de validation obsolète ou incomplète et une traçabilité réduite entre les exigences, la conception et les tests.
- Non-conformité réglementaire menant à des observations d’audit.
- Problèmes d’intégrité des données.
- Défaillances du système ou fonctionnalités imprévues.
- Désalignement entre la configuration du système et les documents, procédures et dossiers de validation approuvés.
Un processus de gestion du changement structuré et efficace garantit que toutes les modifications proposées sont évaluées, documentées, approuvées, testées et mises en œuvre de manière contrôlée.
Il permet aux organisations d’évaluer l’impact potentiel d’un changement sur la sécurité des patients, la qualité du produit, l’intégrité des données et la conformité réglementaire avant sa mise en œuvre.
Composantes essentielles d’un processus de gestion du changement efficace
1. Gouvernance et rôles
Une gouvernance forte apporte clarté et responsabilité. Les rôles typiques incluent :
- Demandeur du changement (initiateur) : identifie le besoin d’un changement et soumet la demande de changement pour évaluation et approbation.
- Propriétaire du système (System Owner) : responsable de la performance et de la conformité du système, il évalue l’impact commercial et approuve la mise en œuvre.
- Propriétaire métier (Business Owner) : assure l’alignement avec les besoins de l’entreprise.
- Responsable informatique (IT Owner) : responsable de la mise en œuvre technique.
- Assurance Qualité (QA) : garantit la conformité et approuve les changements.
- Responsable de la validation CSV : évalue l’impact sur la validation et les exigences de test.
- Utilisateur final : effectue ou soutient les tests d’acceptation par les utilisateurs.
Un comité consultatif sur les changements (CAB) ou un forum de gouvernance similaire aide à prioriser et à approuver les changements en fonction du risque et de l’impact commercial.
Enfin, le cas échéant, l’expert métier (SME) : fournit une expertise métier ou technique spécialisée pour soutenir les évaluations d’impact, examiner les exigences, contribuer aux activités de test et s’assurer que les changements répondent aux besoins opérationnels et de conformité.
2. Initiation de la demande de changement
Chaque changement commence par une demande de changement (CR) claire et complète, couvrant la description du changement, sa raison et sa justification, sa source (écart, audit, amélioration, incident ou mise à jour réglementaire), sa classification (mineur, majeur, critique) et les premières considérations sur les risques.
Responsabilités : une CR est généralement émise par la personne qui identifie en premier le besoin d’une modification. Il peut s’agir du propriétaire du processus ou du métier, lorsque les exigences du processus évoluent ; du propriétaire du système, lorsqu’un problème fonctionnel ou une amélioration est détecté ; de l’informatique, lorsque des mises à jour techniques ou des correctifs sont nécessaires ; ou de la QA, lorsqu’une lacune de conformité, un écart ou une observation d’audit doit être traité.
Bénéfice : quelle que soit son origine, une CR clairement décrite et formellement documentée pose les bases d’une évaluation cohérente, d’une traçabilité et d’une exécution contrôlée tout au long du processus de changement.
3. Évaluation d’impact
Une évaluation d’impact est l’évaluation structurée de la manière dont un changement proposé affecte un système validé. C’est un élément clé du processus de gestion du changement dans la CSV, et elle détermine :
- Quelles exigences validées sont affectées
- Si les spécifications fonctionnelles, techniques ou de conception nécessitent des mises à jour
- L’impact sur l’intégrité des données, les interfaces et les intégrations du système
- Les tests requis (ex. : non-régression, fonctionnels, intégration)
- L’impact sur les SOP, la formation et les processus métier
- Si une revalidation partielle ou totale est requise
- Les risques associés et les mesures d’atténuation correspondantes
Responsabilités : le propriétaire du système et le responsable de la validation évaluent comment le changement affecte les exigences validées, la configuration du système, les flux de données et les exigences de test. La QA examine les implications en matière de conformité et d’intégrité des données, tandis que l’informatique fournit des informations techniques sur l’infrastructure, les intégrations ou les mises à jour logicielles.
Bénéfice : une approche basée sur le risque garantit que l’effort est proportionnel à l’impact potentiel sur les processus GxP.
4. Planification et exécution
Une fois approuvé, le changement est planifié et exécuté de manière contrôlée : les spécifications (URS, FS, CS, DS) sont mises à jour, les activités de configuration ou de développement sont préparées, les preuves de mise en œuvre sont documentées, et l’informatique, le métier et la QA se coordonnent pour s’aligner sur les cycles de publication.
Responsabilités : la planification est généralement dirigée par le propriétaire du système et le responsable informatique, qui définissent les activités techniques et fonctionnelles requises. Le responsable de la validation s’assure que les livrables de validation sont mis à jour en conséquence, tandis que la QA supervise la conformité et confirme que les actions prévues s’alignent sur les attentes GxP.
Bénéfice : une attribution claire des responsabilités et une planification structurée réduisent les délais, préviennent les erreurs de communication et garantissent que chaque domaine impacté est correctement traité.
5. Tests et documentation
Les activités de test sont alignées sur l’évaluation d’impact et comprennent généralement des tests de non-régression pour les fonctionnalités non affectées mais liées, des tests fonctionnels pour les composants modifiés et des tests d’intégration pour les interfaces et intégrations potentiellement impactées.
Responsabilités : le responsable de la validation définit le périmètre des tests, l’informatique exécute les tests techniques, les utilisateurs métier peuvent soutenir les tests d’acceptation fonctionnelle, et la QA examine et approuve toutes les preuves.
Bénéfice : une approche de test structurée garantit que les changements n’introduisent pas de nouveaux risques et que l’état validé reste démontrable et prêt pour l’audit.
6. Approbation et déploiement
Avant le déploiement, la QA examine toute la documentation pertinente, le responsable de la validation confirme que les activités de test ont été achevées de manière satisfaisante, le propriétaire du système approuve l’état de préparation du système pour la mise en œuvre, et le CAB confirme la priorisation et le calendrier du déploiement du changement dans l’environnement de production.
Le déploiement est généralement exécuté par l’informatique, en suivant des procédures contrôlées et en assurant la séparation entre les différents environnements.
Responsabilités : le propriétaire du système peut confirmer l’état de préparation fonctionnelle, le responsable de la validation vérifie l’exhaustivité de la validation, la QA donne l’approbation finale de conformité, et le CAB autorise le calendrier de déploiement.
Bénéfice : un déploiement contrôlé garantit que seuls les changements approuvés et entièrement testés atteignent la production, réduisant ainsi le risque opérationnel et protégeant la conformité.
7. Revue post-implémentation
Après la mise en œuvre, une revue structurée vérifie que le changement fonctionne comme prévu, qu’aucun nouveau problème n’a été introduit, que la documentation est complète et exacte, que les mises à jour des formations et des SOP ont été effectivement mises en œuvre, et que les leçons apprises sont consignées pour des améliorations futures.
Responsabilités : le propriétaire du système dirige la revue, le propriétaire métier évalue si le changement répond au besoin de l’entreprise, la QA vérifie la documentation et la conformité, l’informatique soutient la vérification technique, et le responsable de la validation s’assure que les livrables de validation restent exacts.
Bénéfice : cette étape finale boucle la boucle, renforce l’amélioration continue et soutient la stabilité et la conformité du système à long terme.
Rôles et responsabilités tout au long du cycle de vie
Le tableau ci-dessous résume qui dirige et qui soutient généralement à chaque étape du cycle de vie du changement.
| Étape | Dirige | Soutient |
|---|---|---|
| Initiation | Demandeur du changement (propriétaire du système, propriétaire métier, IT ou QA) | QA (conseils sur la documentation et la conformité) |
| Évaluation d’impact | Propriétaire du système, responsable de la validation | QA, IT, experts métiers (SME) |
| Planification et exécution | Propriétaire du système, responsable informatique | Responsable de la validation, QA |
| Tests et documentation | Responsable de la validation | IT, utilisateurs métier, QA |
| Approbation et déploiement | Propriétaire du système, responsable informatique (déploiement), CAB (le cas échéant pour la priorisation) | Responsable de la validation, QA |
| Revue post-implémentation | Propriétaire du système | Propriétaire métier, QA, IT, responsable de la validation |
Types courants de changements dans les projets CSV
- Mises à jour de configuration
- Améliorations fonctionnelles
- Modifications d’intégration
- Correctifs logiciels et mises à niveau de version
- Changements d’infrastructure et de sécurité
- Ajustements du modèle de données
- Changements déclenchés par des CAPA ou des conclusions d’audit
- Améliorations de l’utilisabilité
Chaque type nécessite une approche sur mesure, mais tous doivent suivre le même processus contrôlé.
Meilleures pratiques pour la gestion du changement dans la CSV
- Appliquer une approche basée sur le risque pour évaluer, classifier et prioriser les changements
- Maintenir une traçabilité de bout en bout tout au long du cycle de vie
- Garder la documentation (de validation et opérationnelle) actuelle et à jour
- Utiliser des cycles de publication structurés plutôt que des changements ponctuels
- Impliquer la QA tôt pour minimiser les reprises
- S’assurer que les évaluations d’impact sont documentées, complètes et proportionnées au risque du changement.
- Intégrer la gestion du changement aux processus d’écarts, de CAPA et d’audit
- Encourager les retours continus des utilisateurs et des propriétaires de systèmes
- Revoir périodiquement les changements mis en œuvre pour identifier les leçons apprises et les opportunités d’amélioration.
Pièges courants et comment les éviter
- Mettre en œuvre des changements sans une évaluation d’impact appropriée
- Tests insuffisants ou couverture de non-régression inadéquate
- Documentation obsolète (validation et opérationnelle)
- Manque de communication entre l’informatique, la QA et le métier
- Changements urgents contournant les contrôles formels
- Mauvais contrôle des versions entraînant des incohérences
La connaissance de ces pièges aide les organisations à renforcer leurs processus avant qu’ils ne deviennent des conclusions d’audit.
Le cycle de vie de la gestion du changement dans la CSV
Foire aux questions
Qu’est-ce que la gestion du changement dans les projets CSV ?
Il s’agit du processus contrôlé d’évaluation, de documentation, de test et d’approbation des modifications apportées à un système informatique validé, afin que le système continue de répondre aux exigences GxP après le changement. Il suit généralement un cycle de vie défini, de la demande de changement jusqu’à la revue post-implémentation.
Pourquoi la gestion du changement est-elle importante dans les environnements réglementés par les GxP ?
Parce que même de petits changements sur un système validé peuvent affecter l’intégrité des données, la qualité du produit et la sécurité des patients. Des cadres tels que l’Annexe 11 des BPF de l’UE et le GAMP 5 exigent que les changements soient contrôlés, évalués et documentés pour préserver l’état validé du système.
Qui approuve les changements sur un système validé ?
L’approbation implique généralement la QA, qui examine la documentation et confirme la conformité, le responsable de la validation, qui confirme l’exhaustivité des tests, le propriétaire du système, qui confirme l’état de préparation, et un comité consultatif sur les changements, qui valide la priorisation et le calendrier avant le déploiement.
Qu’est-ce qu’une évaluation d’impact dans la gestion du changement ?
Une évaluation d’impact est une évaluation structurée de la manière dont un changement proposé affecte les exigences validées, la configuration du système, les données, les interfaces et les besoins de test. Elle détermine si une revalidation est nécessaire et quels risques doivent être atténués avant de procéder au changement.
Quels sont les pièges les plus courants dans la gestion du changement CSV ?
Les pièges les plus fréquents incluent l’omission d’une évaluation d’impact appropriée, des tests de non-régression insuffisants, une documentation de validation obsolète, une mauvaise communication entre l’informatique, la QA et le métier, et des changements urgents qui contournent les contrôles formels.
Conclusion
La gestion du changement est une pierre angulaire du maintien des systèmes validés dans les environnements réglementés. Un robuste, basé sur le risque et bien gouverné processus garantit que chaque modification est de manière appropriée évaluée, contrôlée, documentée, testée et alignée sur les attentes de conformité.
En combinant une gouvernance efficace, une évaluation d’impact approfondie, des tests structurés et une amélioration continue, les organisations peuvent préserver l’état validé de leurs systèmes, sauvegarder l’intégrité des données, maintenir la stabilité opérationnelle et rester prêtes pour l’inspection tout au long du cycle de vie du système.
Transformez la gestion du changement en un avantage stratégique
Chez Rephine, nous aidons les organisations à atteindre précisément ce niveau d’excellence.
Notre expertise dans les environnements GxP, combinée à notre perspective mondiale, renforce les processus de gestion du changement, améliore la prise de décision basée sur le risque et garantit que chaque changement contribue à un écosystème technologique plus sûr, plus efficace et pleinement conforme.
Contactez notre équipe pour découvrir comment nous pouvons aider à transformer la gestion du changement d’une exigence réglementaire en un levier stratégique de qualité, de conformité et d’excellence opérationnelle.
Maialen Serna
Technicienne Validation & BPF
À propos de l’auteur :
Maialen Serna est l’une de nos consultantes en validation et BPF chez Rephine, un leader mondial de la conformité GxP et de l’assurance qualité.
Nous ne nous contentons pas de fournir des audits ou des services de conseil, nous nous associons à nos clients à chaque étape de leur parcours qualité, en offrant des solutions de bout en bout qui inspirent confiance et conformité.
Avec plus de 25 ans d’expérience, Rephine s’est forgé une réputation enviable en tant que référence dans l’industrie, opérant à partir de quatre sites principaux : Stevenage au Royaume-Uni, Barcelone en Espagne, l’Inde et Shanghai en Chine.
Elle s’engage à aider les entreprises pharmaceutiques, biotechnologiques et de dispositifs médicaux à atteindre les normes les plus élevées en matière de fabrication et d’intégrité de la chaîne d’approvisionnement.
