Année 2022- 2023 N°

THESE

pour l’obtention du Diplôme d’Etat de

DOCTEUR EN PHARMACIE

présentée et soutenue publiquement

par

Antoine SERI

Le 13 juillet 2023

Titre :
Défis et enjeux de la validation des systèmes informatisés dans
l'industrie pharmaceutique : étude de cas - validation d’un CRM

JURY

Pr. Jean-Louis Beaudeux , Président

Mme. Ingrid Elbilia Haiun
Dr Wilford Renaudin
 Remerciements

Je tiens à exprimer ma profonde gratitude à Monsieur le Doyen de la Faculté de Pharmacie de

Paris, Jean-Louis Beaudeux, pour avoir accepté d'être mon responsable universitaire de thèse
et pour m'avoir accompagné et soutenu durant cet exercice difficile.

Je remercie également Madame Ingrid Elbilia Haiun, Consultant Sénior VSI et Responsable
Opérations IDF chez Pharmasys, qui a bien voulu être ma directrice de thèse et qui a apporté
son expertise et son soutien durant ma thèse.

Je n'oublie pas mes amis, Wilford Renaudin, Guillaume Bianconi, Laurence Amchin et Aicha
Nasredine, qui m'ont accompagné lors de mes études de pharmacie et qui ont été présents dans
les moments difficiles comme dans les moments de joie.

Enfin, je dédie cette thèse à ma compagne, Chloé Venezia, qui m'a apporté son soutien
inconditionnel et son amour tout au long de ce processus.

2
 Table des matières

1. Introduction....................................................................................................................... 9
2. Défis et enjeux de la validation des systèmes informatisés dans l'industrie pharmaceutique ... 10
2.1. Importance de la qualité et de la sécurité des médicaments ......................................... 10
2.2. Rôle crucial des systèmes informatisés dans l’industrie pharmaceutique ....................... 11
2.2.1. Définition d’un système informatisé .................................................................... 11
2.2.2. Rôle des systèmes informatisés dans l’industrie pharmaceutique........................... 11
2.3. Défis liés à la complexité des systèmes informatisés..................................................... 14
3. État de l'art sur la validation des systèmes informatisés ....................................................... 15
3.1. Définition de la validation des systèmes informatisés ................................................... 15
3.2. Règlementation et normes en vigueur en matière de systèmes informatisés .................. 16
3.2.1. FDA 21 CFR Part 11 (États-Unis)........................................................................... 16
3.2.2. BPF Annexe 11 (Union européenne) .................................................................... 19
3.2.3. ICH (International Council for Harmonisation) ...................................................... 20
3.2.4. GAMP 5 (Good Automated Manufacturing Practice) ............................................. 22
3.2.5. ISO 9001 : 2015 ................................................................................................. 23
3.3. Approches couramment utilisées pour la validation des systèmes informatisés .............. 24
3.3.1. Modèle cycle en V .............................................................................................. 25
3.3.2. Modèle agile ..................................................................................................... 36
3.4. Processus de support à la validation ........................................................................... 40
3.4.1. Management du risque ...................................................................................... 40
3.4.2. Gestion des changements ................................................................................... 46
3.4.3. Matrice de traçabilité ......................................................................................... 47
3.4.4. Gestion de la documentation .............................................................................. 49
3.4.5. Évaluation du fournisseur ................................................................................... 50
3.5. Phase d’exploitation .................................................................................................. 51
3.5.1. Gestion des changements ................................................................................... 51
3.5.2. Maintenance et surveillance du système .............................................................. 51
3.5.3. Revue périodique ............................................................................................... 53
3.5.4. Archivage et récupération des données ................................................................ 53
3.5.5. Formation des utilisateurs................................................................................... 53

3
4. Étude de cas : validation d’un CRM en cycle en V ................................................................ 54
4.1. Présentation du projet et des parties prenantes .......................................................... 54
4.2. Déroulement du projet .............................................................................................. 54
4.2.1. Organisation du projet ....................................................................................... 54
4.2.2. Analyse de risque initiale .................................................................................... 54
4.2.3. Planification de la validation ............................................................................... 55
4.2.4. Résultats de l’analyse des risques fonctionnelle .................................................... 62
4.2.5. Résultats des phases de qualification ................................................................... 64
4.3. Résultats de la validation et leçons apprises ................................................................ 66
4.3.1. Conclusion du rapport final ................................................................................. 66
4.3.2. Leçons apprises .................................................................................................. 66
5. Conclusion ....................................................................................................................... 67
Annexes.................................................................................................................................. 69
Annexe A : Analyse de risque fonctionnelle ............................................................................ 69
Annexe B : Matrice de traçabilité........................................................................................... 71
Références bibliographiques .................................................................................................... 73

4
 Liste des tableaux et figures

Figure 1 Cycle de vie des systèmes informatisés - ISPE GAMP® 5 (Second Édition) .......... 24
Figure 2 Modèle cycle en V ..................................................................................................... 26
Figure 3 Exemple d'URS ......................................................................................................... 29
Figure 4 Modèle agile – Scrum (31) ........................................................................................ 38
Figure 5 - Catégories des systèmes informatisés selon le GAMP 5 ........................................ 41
Figure 6 - Cycle en V des systèmes de catégorie 3 selon le GAMP - - ISPE GAMP® 5
(Second Édition) ...................................................................................................................... 42
Figure 7 Cycle en V des systèmes de catégorie 4 selon le GAMP - ISPE GAMP® 5 (Second
Édition) .................................................................................................................................... 42
Figure 8 - Cycle en V des systèmes de catégorie 5 selon le GAMP - ISPE GAMP® 5 (Second
Édition) .................................................................................................................................... 43
Figure 9 Détermination de la criticité des modes de défaillance ............................................. 44
Figure 10- Priorisation des modes de défaillance selon leur criticité ...................................... 45
Figure 11 Exemple de matrice de traçabilité - ISPE GAMP® 5 (Second Édition) ................. 49
Figure 12 Livrables de validation - rôles et responsabilités .................................................... 59
Figure 13 Liste des risques Low et Medium identifiés pour Salesforce CRM ........................ 63

5
 Liste des abréviations

AMDEC Analyse des Modes de Défaillance de leurs Effets et de leur Criticité

ANSM Agence Nationale de Sécurité du Médicament
BPD Bonnes Pratiques de Distribution
BPF Bonnes Pratiques de Fabrication
BPL Bonnes Pratiques de Laboratoire
BPO Business Process Owner (Responsable du processus métier)
BPx Bonnes Pratiques - où [x] représente le domaine spécifique, par exemple BPF pour
Bonnes Pratiques de Fabrication
CADD Computer aided drug design (Conception de médicaments assistée par
ordinateur)
CAPA Corrective Actions and Preventive Actions (Actions correctives et préventives)
CFR Code of Federal Regulations (Code des Régulations Fédérales)
CI/CD Continuous Integration / Continuous Deployment (Intégration Continue /
Déploiement Continu)
CRM Customer Relationship Management (Gestion de la relation client)
QC Qualification de Conception
EDC Electronic Data Capture (Collecte électronique de données)
EDP Electronic Data Processing (Traitement électronique des données)
EMA European Medicines Agency (Agence Européenne des Médicaments)
ERP Enterprise Resource Planning (Progiciel de Gestion Intégré)
EudraLex European Union Drug Regulatory Authorities Legislative Framework (Cadre
législatif des autorités règlementaires de l'Union européenne pour les
médicaments)
FDA Food and Drug Administration (Agence des médicaments et des produits
alimentaires des États-Unis)
FDD Feature-Driven Development (Développement Piloté par les Fonctionnalités)
FS Functional Specification (Spécifications fonctionnelles)
GAMP Good Automated Manufacturing Practice (Bonnes Pratiques de Fabrication
Assistée par Ordinateur)
GAMP 5 Good Automated Manufacturing Practice version 5
GED Gestion Électronique des Documents

6
GMP Good Manufacturing Practice (Bonnes pratiques de fabrication)
GxP Good [x] Practice (Bonnes Pratiques - où [x] représente le domaine spécifique,
par exemple GMP pour Good Manufacturing Practice)
HDS Hébergeur de Données de Santé
HTS High-Throughput Screening (Criblage à haut débit)
ICH International Council for Harmonisation of technical requirements for
pharmaceuticals for human use (Conseil International pour l'Harmonisation des
exigences techniques pour les produits pharmaceutiques à usage humain)
ICH Q9 International Council for Harmonisation of Technical Requirements for
Pharmaceuticals for Human Use - Quality Risk Management
ISO International Organization for Standardization (Organisation internationale de
normalisation)
ISPE International Society for Pharmaceutical Engineering (Société internationale de
l'ingénierie pharmaceutique)
IT Information Technology (Technologies de l'Information)
ITPM IT Project Manager (Chef de projet informatique)
KPI Key Performance Indicator (Indicateur clé de performance)
MES Manufacturing Execution System (Système d'Exécution de la Fabrication)
NC Non-Conformité
OMS Organisation mondiale de la santé
Part 11 Titre 21 du CFR, Partie 11 (règles de la FDA sur les dossiers électroniques et les
signatures électroniques)
PO Product Owner (Propriétaire du Produit)
PRA Plan de Reprise d'Activité
QAPM Quality Assurance Project Manager (Responsable assurance qualité)
QI Qualification de l'installation
QMS Quality Management System (Système de Management de la Qualité)
QO Qualification Opérationnelle
QP Qualification de Performance
R&D Recherche et Développement
RA Risk Assessment (analyse de risque)
SaaS Software as a Service (Logiciel en tant que Service)
SAP Systems, Applications and Products (Systèmes, Applications et Produits)

7
SI Système informatisé
SLA Service Level Agreement (Accord de niveau de service)
SM Scrum Master (Maître de cérémonie Scrum)
SOP Standard Operating Procedure (Procédure Opérationnelle Standard)
SSO Single Sign-On (Authentification Unique)
SVM System Validation Manager (Responsable de la validation)
TS Technical Specification (Spécifications techniques)
UE Union Européenne
URS User Requirement Specification (Spécification des Exigences Utilisateur)
WMS Warehouse Management System (Système de Gestion d'Entrepôt)
XP Extreme Programming (Programmation Extrême)

8
1. Introduction

L'industrie pharmaceutique, un secteur en perpétuelle évolution, est confrontée à de nombreux

défis pour assurer la qualité la sécurité et l'efficacité des médicaments mis sur le marché. La
validation des systèmes informatisés constitue un élément central pour relever ces défis,
permettant de garantir la conformité aux exigences règlementaires et la qualité des données
produites. Cette thèse d'exercice de pharmacie se penche sur les défis et les enjeux de la
validation des systèmes informatisés dans l'industrie pharmaceutique, en s'appuyant sur l'étude
de cas de la validation d'un CRM, tout en restant conscient de la complexité et de la richesse
du sujet abordé.

Au cours de cette thèse, nous examinerons minutieusement les différentes étapes et les éléments
clés impliqués dans la validation des systèmes informatisés, en mettant l'accent sur l'importance
d'une approche structurée et rigoureuse pour mener à bien ce processus, tout en tenant compte
des spécificités de l'industrie pharmaceutique. Nous évoquerons également les limites et les
défis auxquels sont confrontées les entreprises dans ce domaine complexe, sans prétendre à
l'exhaustivité, mais en cherchant à offrir une vision éclairée et pertinente.

Par ailleurs, cette thèse soulignera l'importance de la collaboration entre les différents acteurs
de l'industrie pharmaceutique, tels que les régulateurs, les fabricants de médicaments et les
fournisseurs de systèmes informatisés, pour relever ensemble les défis et garantir la conformité
aux exigences règlementaires. Nous reconnaissons que cette coopération interdisciplinaire est
essentielle pour s'assurer que les avancées technologiques profitent à tous les acteurs du secteur
de la santé et contribuent à améliorer la qualité de vie des patients.

Dans le même temps, cette thèse mettra en lumière le rôle essentiel de la formation et du
développement des compétences des professionnels de l'industrie pharmaceutique pour assurer
une mise en œuvre réussie et conforme des systèmes informatisés. Nous examinerons les
avantages d'investir dans la formation et de développer une culture de la qualité et de la
conformité, en soulignant l'importance de ces investissements pour les entreprises
pharmaceutiques dans leur quête de relever les défis et les enjeux liés à la validation des
systèmes informatisés.

Tout au long de cette thèse, nous examinerons également l'étude de cas présentée, qui servira
d'exemple pratique pour illustrer les aspects théoriques et pratiques de la validation des
systèmes informatisés. Sans dévoiler trop de détails à ce stade, nous analyserons les résultats

9
obtenus et offrirons des recommandations pertinentes pour les entreprises et les acteurs du
secteur, tout en reconnaissant que chaque situation peut être unique et nécessiter des
ajustements spécifiques.

En somme, cette thèse d'exercice de pharmacie se propose d'aborder un sujet important et

complexe avec rigueur, en reconnaissant ses limites et en cherchant à contribuer au débat sur
la validation des systèmes informatisés dans l'industrie pharmaceutique.

2. Défis et enjeux de la validation des systèmes informatisés dans

l'industrie pharmaceutique

2.1. Importance de la qualité et de la sécurité des médicaments

La qualité et la sécurité des produits pharmaceutiques sont des éléments cruciaux pour garantir
la santé publique et le bien-être des patients. Les médicaments non conformes ou dangereux
peuvent entrainer de graves conséquences sanitaires, telles que des pathologies, des lésions et
même la mort. Un exemple notoire est le retrait du marché du Vioxx par Merck en 2004, un
anti-inflammatoire prescrit pour l'arthrose, après que des études cliniques aient révélé un risque
accru de crise cardiaque suite à un traitement prolongé (1) (2) (3). De même, le scandale de la
Dépakine en France, depuis 2016, implique un antiépileptique prescrit aux femmes enceintes,
associé à des malformations et des troubles du développement chez les enfants. Le fabricant
Sanofi et l'ANSM ont été mis en examen pour négligence concernant la commercialisation et
la distribution du médicament (4–6).

Les enjeux liés à la qualité et à la sécurité des médicaments concernent non seulement les
patients, mais également les communautés et le système de santé dans son ensemble. Les
produits pharmaceutiques inadéquats ou insuffisamment sécurisés génèrent un gaspillage de
ressources, une perte de confiance envers le système de santé et la propagation de maladies (7).
Ainsi, il est impératif de garantir la qualité et la sécurité des médicaments pour préserver la
santé publique et le bien-être des individus.

10
 2.2. Rôle crucial des systèmes informatisés dans l’industrie pharmaceutique

2.2.1. Définition d’un système informatisé

Selon l'annexe 11 des Bonnes Pratiques de Fabrication (BPF), un système informatisé est un
ensemble de matériels et de logiciels qui remplissent ensemble certaines fonctionnalités (8).
Bien que les BPF assimilent un système informatisé à un système informatique, il est essentiel
d'examiner l'intégralité du processus informatisé pour assurer que la qualité du produit ne soit
pas compromise.

La définition de la Food and Drug Administration (FDA) englobe une portée plus large,
incluant le matériel, le logiciel, les équipements périphériques, le personnel et la documentation
(9). Par conséquent, il est crucial de reconnaitre que le système informatisé ne se réduit pas
uniquement au système informatique, mais englobe également la fonction ou le processus
contrôlé.

2.2.2. Rôle des systèmes informatisés dans l’industrie pharmaceutique

L'industrie pharmaceutique intègre de manière croissante les systèmes informatisés et les

technologies de l'information à diverses étapes du processus de développement des
médicaments, notamment la recherche, le développement, la production et la distribution. Ces
systèmes sont indispensables pour assurer la qualité, la sécurité et l'efficacité des produits
pharmaceutiques et la santé des patients.

a. Les rôles des systèmes informatisés dans la conformité règlementaire

L'industrie pharmaceutique est soumise à des règlementations rigoureuses aux échelles

nationale et internationale, visant à garantir la sécurité et l'efficacité des produits
pharmaceutiques et à protéger la santé des patients. Les systèmes informatisés facilitent la
conformité à ces exigences règlementaires en automatisant diverses tâches, telles que la
collecte de données, l'établissement de rapports et l’envoi d'alertes et de notifications en temps
réel.

Par exemple, l'adoption croissante des dossiers électroniques (10) et de signatures électroniques
(11,12) dans l'industrie pharmaceutique permet aux entreprises de stocker et d'accéder aux
données de manière électronique, améliorant ainsi l'efficacité et réduisant les risques d'erreurs.
Les systèmes informatisés peuvent également être employés pour suivre et surveiller la

11
distribution et l'utilisation des produits pharmaceutiques, garantissant ainsi leur usage sécurisé
et approprié.

b. Les rôles des systèmes informatisés en Recherche & Développement

Les systèmes informatisés sont devenus essentiels pour la recherche et le développement

(R&D) dans l'industrie pharmaceutique, permettant un traitement précis et efficace de grandes
quantités de données, ainsi que la simulation et la modélisation de processus biologiques
complexes.

Dans la conception de médicaments, les systèmes informatisés sont utilisés pour créer de
nouveaux composés destinés à interagir avec des cibles protéiques spécifiques. Ceci implique
l'utilisation de logiciels de conception de médicaments assistée par ordinateur (CADD (13,14)
pour prédire la structure tridimensionnelle des cibles protéiques et identifier les sites de liaison
potentiels des candidats médicaments.

En matière de découverte de médicaments, les systèmes informatisés sont employés pour

identifier des candidats médicaments potentiels parmi un ensemble de composés, en utilisant
des technologies de criblage à haut débit (HTS) pour tester rapidement et efficacement la
capacité des composés à se lier à des cibles protéiques spécifiques (15).

Pour la gestion des essais cliniques, les systèmes informatisés sont utilisés pour suivre la
progression des essais et collecter et analyser les données, comme les systèmes de capture
électronique de données (EDC) qui permettent la collecte et la gestion des données des essais
cliniques provenant de plusieurs sites, ainsi que l'analyse en temps réel de ces données (16).

c. Les rôles des systèmes informatisés en production et distribution

Les systèmes informatisés jouent un rôle crucial dans la production et la distribution des
médicaments, en garantissant la sécurité, l'efficacité et la qualité des produits pharmaceutiques.
Ils automatisent et rationalisent divers processus tels que la fabrication, le conditionnement,
l'étiquetage et la distribution, améliorant ainsi l'efficacité, réduisant les coûts et les erreurs.

Parmi les exemples de systèmes informatisés utilisés dans la production de médicaments

figurent les systèmes d'exécution de la fabrication (MES), qui assurent la conformité aux
normes règlementaires en collectant et en analysant des données sur des facteurs tels que la
température, l'humidité et les paramètres du processus (17) et les systèmes de gestion d'entrepôt
(WMS), qui optimisent les niveaux d'inventaire, suivent les mouvements de stock et
garantissent une livraison précise et en temps voulu des produits aux clients (18). Les systèmes

12
informatisés jouent également un rôle important dans la traçabilité et le rappel des médicaments
en utilisant des systèmes de pédigrée électronique (e-pedigree) qui fournissent des données sur
l'historique d'un lot particulier d'un médicament (19).

Les systèmes de gestion de la qualité QMS “quality management system” aident à gérer la
documentation et le reporting des processus et procédures de qualité, ce qui est essentiel pour
la conformité aux normes règlementaires. Enfin, les systèmes de planification des ressources
de l'entreprise ERP “enterprise resource planning” aident à coordonner et à optimiser les
diverses activités et ressources impliquées dans la production et la distribution des
médicaments (20).

d. Contrôle et assurance de la qualité

Les systèmes informatisés constituent un élément important de l'industrie pharmaceutique

lorsqu'il s'agit de contrôle et d'assurance de la qualité. Le contrôle de la qualité implique les
étapes et les procédures mises en place pour s'assurer que les produits répondent aux normes
nécessaires. L'assurance qualité, quant à elle, consiste à surveiller et à évaluer en permanence
ces processus pour s'assurer qu'ils fonctionnent efficacement.

Les systèmes informatisés facilitent le contrôle et l'assurance qualité en automatisant des tâches
telles que la collecte et l'analyse des données, réduisant ainsi les erreurs et augmentant la
précision des résultats. Par exemple, une entreprise peut utiliser un système informatisé pour
surveiller en temps réel le processus de fabrication, identifiant ainsi tout écart par rapport aux
normes et prévenant la production de produits défectueux ou non conformes, pouvant avoir des
conséquences graves pour les patients.

Voici d'autres applications des systèmes informatisés pour le contrôle et l'assurance qualité
dans l'industrie pharmaceutique :

- Surveillance et enregistrement de la température, de l'humidité et d'autres conditions

environnementales dans les zones de fabrication et de stockage, garantissant l'intégrité
des produits face aux conditions extrêmes (21).
- Contrôle qualité des matières premières et des produits finis à l'aide de capteurs et de
technologies avancées pour détecter tout défaut ou impureté (22).
- Réalisation de contrôles qualité à différentes étapes du processus de fabrication afin
d'identifier et de résoudre les problèmes dès leur apparition.

13
 - Analyse des données issues des tests et inspections de contrôle qualité pour identifier
les tendances et les modèles, et utiliser ces informations pour améliorer les processus
et les procédures.
- Génération automatique de rapports et de documentation sur la qualité, réduisant ainsi
le risque d'erreurs liées à la saisie ou à la transcription manuelle des données.

En somme, l'utilisation de systèmes informatisés dans le contrôle et l'assurance qualité

contribue à garantir que les produits pharmaceutiques sont de haute qualité et sûrs pour les
patients.

Les systèmes informatisés revêtent donc une importance cruciale dans l'industrie
pharmaceutique, permettant aux entreprises d'optimiser leurs opérations, d'accroître leur
efficacité et d'améliorer la qualité de leurs produits. Des activités de recherche et
développement de médicaments innovants jusqu'à la fabrication et la distribution de produits
pharmaceutiques, les systèmes informatisés sont employés pour automatiser diverses tâches,
améliorer la précision des résultats et garantir la conformité aux règlementations. L'adoption
de systèmes informatisés devrait donc poursuivre sa croissance dans l'industrie pharmaceutique
dans les années à venir, les entreprises cherchant à exploiter les avantages qu'ils procurent.

2.3. Défis liés à la complexité des systèmes informatisés

L'industrie pharmaceutique repose largement sur des systèmes informatisés pour diverses
opérations, notamment les équipements de laboratoire, les processus de fabrication et le
contrôle qualité. Cependant, elle fait face à une complexité croissante de ses systèmes
d'information (SI) en raison de facteurs tels que la nature vaste et hétérogène des SI, la pression
des changements organisationnels et la poussée vers la dématérialisation.

Cette complexité se manifeste dans la gestion d’un nombre important d'applications et de

serveurs ainsi que d'innombrables transactions et échanges impliquant diverses parties
prenantes telles que les employés, les partenaires, les clients et les fournisseurs. L'expansion
du périmètre des SI entraîne une concentration de risques et de défis dans divers domaines de
la gestion des SI, notamment la gouvernance, l'intégration de grands projets de développement,
le contrôle et la répartition des coûts, la gestion de la performance et de la disponibilité, la
gestion des risques techniques et la sécurité. La nature transversale de ces problèmes les rend
difficiles à traiter, ce qui entraîne des difficultés à maîtriser les coûts et les risques tout en
répondant aux besoins des entreprises dans des délais raisonnables (23).

14
Un autre défi central lié à la complexité de ces systèmes est la validation. La validation permet
de démontrer que le système fonctionne comme prévu et répond aux exigences établies par les
organismes de règlementation, tels que la FDA et l’EMA (9). Mais en raison de la complexité
des systèmes, la validation peut être un processus long et couteux. Elle exige une
compréhension approfondie de la fonctionnalité du système et une méthodologie de test robuste
pour garantir que tous les aspects du système ont été évalués.

Pour relever ces défis, il est essentiel d'adopter une approche structurée et méthodique. Cette
approche doit inclure la mise en place d'une gouvernance claire et de procédures de gestion des
SI pour garantir la conformité règlementaire.

L'utilisation de méthodologies de gestion de projets éprouvés, tels que la méthodologie agile,

peut aider à gérer efficacement des projets informatiques complexes tout en minimisant les
risques de coûts et de délais, à condition que les activités de validation s’adaptent bien aux
étapes de développement agile et qu’une version d’application soit figée entre chaque
validation.

Pour surveiller et optimiser la performance et la disponibilité des systèmes informatisés, il est

également recommandé d'utiliser des outils de suivi et de mesure. Enfin, pour renforcer la
sécurité des SI, il est nécessaire d'appliquer des mesures de protection des données, de former
les employés aux bonnes pratiques de qualité et de cybersécurité et de réaliser des audits
réguliers pour garantir la protection des données des patients conformément aux
règlementations.

3. État de l'art sur la validation des systèmes informatisés

3.1. Définition de la validation des systèmes informatisés

La validation des systèmes informatisés est un processus visant à garantir la conformité d'un
système informatique, d'une application ou d'un logiciel aux exigences définies et à son
fonctionnement prévu. Ce processus est crucial dans de nombreux secteurs tels que les
industries pharmaceutiques, médicales, biotechnologiques et d'autres domaines règlementés,
afin de garantir la qualité, la sécurité et l'efficacité des produits et services.

Dans l’industrie pharmaceutique, la validation est effectuée conformément aux exigences

règlementaires telles que le 21 CFR Part 11 et l'Annexe 11 des BPF.

15
Le 21 CFR Part 11 stipule que la validation des systèmes informatisés doit être effectuée pour
garantir l'exactitude, la fiabilité et la cohérence des performances prévues, ainsi que la capacité
à détecter les enregistrements non valides ou altérés (24).

L’annexe 11 des BPF quant à elle indique que lorsqu'un système informatisé est utilisé dans le
cadre d'activités réglementées par les BPF, il doit être validé et l'infrastructure informatique
doit être qualifiée (8).

Le processus de validation des systèmes informatisés couvre l'ensemble du système, y compris

les logiciels, les équipements, les données traitées, les intervenants, les procédures et la
sécurité. Il s'appuie sur une approche basée sur les risques liés à l'utilisation du système et suit
le cycle de vie du projet. Il comprend plusieurs activités telles que la définition des besoins
utilisateurs, l'analyse des risques, le plan de validation, la revue de conception, les tests
d'intégration et de régression, la qualification d'installation, opérationnelle et de performance.
Il implique également la gestion des modifications et la vérification du maintien de l'état validé.
(25)

Dans l'ensemble, la validation des systèmes informatisés est une étape cruciale pour garantir la
qualité et la fiabilité des systèmes informatisés dans l'industrie pharmaceutique, et elle est
essentielle pour se conformer aux exigences règlementaires.

3.2. Règlementation et normes en vigueur en matière de systèmes informatisés

Les règlementations et normes en vigueur dans l'industrie pharmaceutique visent à garantir

l'intégrité des données, la traçabilité et la fiabilité des systèmes informatisés. Certaines des
principales règlementations et normes en la matière sont :

3.2.1. FDA 21 CFR Part 11 (États-Unis)

La Food and Drug Administration (FDA) des États-Unis a publié le 21 CFR Part 11, un
règlement qui définit les critères pour considérer les enregistrements et signatures électroniques
comme fiables et équivalents à leurs versions papier et manuscrites.

Ce règlement s'applique aux enregistrements électroniques créés, modifiés, conservés,

archivés, récupérés ou transmis en vertu de la Federal Food, Drug, and Cosmetic Act et de la
Public Health Service Act.

Il précise les exigences générales, les composants et les contrôles pour les signatures et
enregistrements électroniques, et se divise en trois domaines principaux : les dispositions

16
générales (sous-partie A), les enregistrements électroniques (sous-partie B) et les signatures
électroniques (sous-partie C).

Le 21 CFR Part 11 a été publié en 1997 pour garantir l'intégrité et l'authenticité des données
électroniques dans les industries réglementées, et pour prévenir la fraude, la falsification,
l'accès non autorisé ou la modification d'enregistrements et signatures électroniques. Il permet
également à la FDA d'inspecter et d'auditer les systèmes et les enregistrements électroniques
pour s'assurer de leur conformité.

Les principales exigences de la 21 CFR Part 11 comprennent (24):

- Validation des systèmes informatisés

Les systèmes doivent être validés pour garantir l’exactitude, la fiabilité, les
performances constantes et la capacité à discerner les enregistrements invalides ou
altérés.

- Génération de copies précises et complètes

Les systèmes doivent être capables de générer des copies précises et complètes des
enregistrements sous forme lisible par l’homme et électronique pour l’inspection,
l’examen et la copie par l’agence.

- Protection des enregistrements

Les enregistrements doivent être protégés pour permettre leur récupération précise et
rapide tout au long de la période de conservation des enregistrements.

- Limitation de l’accès au système

L’accès au système doit être limité aux personnes autorisées.

- Utilisation d’audit trail

Les systèmes doivent utiliser des audits trail horodatés générés par ordinateur pour
enregistrer indépendamment la date et l’heure des entrées et actions de l’opérateur qui
créent, modifient ou suppriment des enregistrements électroniques. Les changements
d’enregistrement ne doivent pas obscurcir les informations précédemment enregistrées.
Ces documentations d’audit trail doivent être conservées pendant une période au moins
égale à celle requise pour les enregistrements électroniques concernés et doivent être
disponibles pour examen et copie par l’agence.

17
- Signatures électroniques
Un document électronique signé doit contenir des informations spécifiques associées à
la signature. Cela comprend le nom imprimé du signataire, la date et l'heure de la
signature, ainsi que la signification associée à la signature, qui peut indiquer l'examen,
l'approbation, la responsabilité ou la paternité du document. En outre, les signatures
électroniques, tout comme les signatures manuscrites sur des documents électroniques,
doivent être solidement liées à leurs documents respectifs. Cette liaison empêche les
signatures d'être retirées, copiées ou transférées pour falsifier un document électronique
par des moyens ordinaires. Enfin, chaque signature électronique est unique à une
personne et ne peut pas être réutilisée ou attribuée à une autre personne, garantissant
ainsi l'unicité et la sécurité de chaque signature.

18
 3.2.2. BPF Annexe 11 (Union européenne)

L'annexe 11 des BPF est une directive complémentaire aux bonnes pratiques de fabrication
(BPF) de la Commission européenne pour les médicaments à usage humain et vétérinaire. Elle
fournit des exigences spécifiques pour les systèmes informatisés utilisés dans le cadre
d'activités réglementées par les BPF.

L'annexe 11 s'applique à toutes les formes de systèmes informatisés, qui sont définis comme
un ensemble de composants logiciels et matériels qui, ensemble, remplissent certaines
fonctions.

Elle couvre des domaines tels que la gestion des risques, le personnel, les fournisseurs et les
prestataires de services, la validation, l'intégrité des données, la sécurité, les audit trails, les
rapports, l'archivage et les signatures électroniques. L'objectif est de garantir que la qualité des
produits, le contrôle des processus et l'assurance qualité ne sont pas compromis lorsqu'un
système informatisé remplace une opération manuelle et qu'il n'y a pas d'augmentation du
risque global du processus.

Les exigences clés de l'Annexe 11 des BPF comprennent :

- Validation et qualification
Le système informatisé doit être validé pour prouver son fonctionnement conforme aux
spécifications et aux exigences de l'utilisateur. L'infrastructure informatique, incluant
le matériel et le logiciel, doit également être qualifiée pour garantir une installation, une
configuration adéquate et la capacité de prendre en charge l'application.

- Gestion des risques

La gestion des risques doit être appliquée tout au long du cycle de vie du système
informatisé, en tenant compte de la sécurité des patients, de l'intégrité des données et
de la qualité des produits. Les décisions sur la validation et les contrôles d'intégrité des
données doivent être basées sur une évaluation des risques justifiée et documentée.

19
 - Personnel
Il est important d'avoir une collaboration étroite entre toutes les parties concernées,
telles que les propriétaires du processus, du système, les personnes qualifiées et
l'informatique. Toutes les parties doivent avoir les qualifications appropriées, le niveau
d'accès et les responsabilités définies pour effectuer leurs tâches.

- Fournisseurs et prestataires de services

Des accords formels doivent être en place entre le fabricant et les tiers utilisés pour
fournir, installer, configurer, intégrer, valider, maintenir, modifier ou conserver un
système informatisé ou un service connexe. La compétence et la fiabilité des
fournisseurs doivent être prises en compte pour déterminer le besoin d'un audit.

- Sécurité
Des contrôles physiques et/ou logiques doivent être en place pour restreindre l'accès au
système informatisé aux personnes autorisées. Les méthodes appropriées pour éviter
l'accès non autorisé peuvent inclure l'utilisation de clés, de codes d'accès, de mots de
passe, de biométrie, etc.

En plus de ces exigences et recommandations clés, l’annexe 11 comprend également des

informations sur d’autres sujets pertinents tels que la gestion, l’exactitude et le stockage des
données, les impressions, les audit trails, la gestion des changements et de la configuration, la
revue périodique, la gestion des incidents, la signature électronique, la libération de lots, la
continuité des activités et l’archivage (8).

3.2.3. ICH (International Council for Harmonisation)

L'ICH ou International Council for Harmonisation of Technical Requirements for

Pharmaceuticals for Human Use, est une organisation mondiale qui vise à harmoniser les
exigences techniques et règlementaires pour l'enregistrement de médicaments destinés à
l'utilisation humaine. Fondée en 1990, l'ICH rassemble des représentants d'autorités
règlementaires, d'industries pharmaceutiques du monde entier, notamment de l'Union
européenne, des États-Unis, du Japon, du Canada, ainsi que d'autres pays et d'organisations
internationales telles que l'OMS (Organisation mondiale de la santé) (26).

L'ICH élabore des lignes directrices pour les industries pharmaceutiques dans les domaines
suivants (27):

20
 - Qualité (série Q)

Ces lignes directrices traitent des questions liées à la qualité des médicaments,
notamment les spécifications, les tests de stabilité, les impuretés et la validation des
procédés de fabrication. Les lignes directrices ICH Q8 à Q12 sont particulièrement
importantes pour la validation des systèmes informatisés, car elles abordent divers
aspects de la qualité, tels que le développement pharmaceutique, la fabrication et le
contrôle de la qualité.

- Sécurité (série S)
Les lignes directrices de cette série abordent les questions liées à la sécurité non clinique
des médicaments, notamment la toxicologie, la pharmacologie et la sécurité des
excipients. Elles visent à garantir que les médicaments sont suffisamment évalués pour
détecter et évaluer les risques potentiels pour la santé humaine.

- Efficacité (série E)
Ces lignes directrices traitent des questions liées à l'efficacité clinique des médicaments,
notamment la conception et l'analyse des essais cliniques, les populations de patients,
les critères d'évaluation et les méthodes statistiques. Elles visent à garantir que les
médicaments sont évalués de manière rigoureuse et scientifique pour démontrer leur
efficacité dans le traitement des conditions médicales.

- Multidisciplinaire (série M)

Les lignes directrices de cette série traitent de questions qui touchent à plusieurs aspects
du développement et de la règlementation des médicaments, tels que la gestion des
risques, la pharmacovigilance, les médicaments orphelins et les produits
biotechnologiques.

En plus d'harmoniser les exigences techniques pour l'enregistrement des médicaments, l'ICH
travaille également sur des initiatives pour améliorer l'efficacité des processus règlementaires
et faciliter l'échange d'informations entre les autorités règlementaires et les industries
pharmaceutiques. L'adoption et la mise en œuvre des lignes directrices de l'ICH contribuent à
réduire les couts de développement et de mise sur le marché des médicaments, tout en
garantissant leur qualité, leur sécurité et leur efficacité pour les patients.

21
 3.2.4. GAMP 5 (Good Automated Manufacturing Practice)

Le Good Automated Manufacturing Practice version 5 (GAMP 5) est un guide développé par
l'ISPE (International Society for Pharmaceutical Engineering) pour aider les entreprises
pharmaceutiques et autres industries règlementées à mettre en place des systèmes informatisés
conformes et validés. Le GAMP 5 fournit un cadre basé sur les risques pour la validation des
systèmes automatisés, en tenant compte des bonnes pratiques de fabrication (GMP) et des
exigences règlementaires telles que la FDA 21 CFR Part 11 et la GMP Annexe 11.

Le GAMP 5 repose sur plusieurs principes clés, dont voici quelques-uns :

- Approche basée sur les risques

Le GAMP 5 encourage l'utilisation d'une approche basée sur les risques pour la
validation des systèmes informatisés, en fonction des risques pour la qualité des
produits, la sécurité des patients et l’intégrité des données. Cette approche implique
d'identifier, d'évaluer et de gérer les risques tout au long du cycle de vie du système, en
se concentrant sur les aspects les plus critiques pour la qualité et la conformité.

- Cycle de vie du système

Le GAMP 5 adopte une approche de cycle de vie pour la validation des systèmes
informatisés, en couvrant toutes les phases du développement, de la conception à la
mise hors service. Le cycle de vie comprend la définition des exigences, la conception,
la construction, l'installation, la qualification et la maintenance du système. Chaque
étape du cycle de vie doit être documentée et vérifiée pour garantir la qualité et la
conformité.

- Catégorisation des systèmes informatisés

Le GAMP 5 propose une classification des systèmes informatisés en fonction de leur
complexité, de leur personnalisation et de leur impact sur la qualité des produits. Les
catégories vont des systèmes standards non configurables (catégorie 1) aux systèmes
hautement personnalisés et configurables (catégorie 5). Cette classification aide à
déterminer le niveau de validation et les activités nécessaires pour chaque système.

22
 - Responsabilités des fournisseurs et des utilisateurs
Le GAMP 5 établit précisément les responsabilités des prestataires de systèmes
informatisés et des entités qui les utilisent. Ces prestataires sont tenus d'assurer la
qualité et la conformité de leurs offres, tandis que les utilisateurs ont pour obligation de
valider et de maintenir les systèmes au sein de leur environnement d'exploitation.
Cependant, pour les systèmes de type 'Software as a Service' (SaaS), hébergés par le
fournisseur, ce dernier assume les tâches de maintenance, y compris les actions de
sauvegarde et de restauration, la mise en œuvre du plan de reprise d'activité (DRP) et
la garantie de la continuité des activités (BCP).

- Bonnes pratiques et documentation

Le GAMP 5 insiste sur l'importance des bonnes pratiques de fabrication (GMP) et des
bonnes pratiques de documentation tout au long du cycle de vie du système. Les
organisations doivent mettre en place des procédures écrites, des registres et des
rapports pour démontrer la qualité et la conformité de leurs systèmes informatisés.

Au cours de l'été 2022, une 2e édition du GAMP 5 a été publiée. Cette nouvelle édition intègre
de nombreux ajouts, mettant l'accent sur les technologies de l'information émergentes telles
que les systèmes cloud, l'intelligence artificielle, le machine learning, les approches innovantes
en matière de développement logiciel, notamment la méthode agile et la modernisation des
infrastructures informatiques (25). Cette deuxième édition met aussi en avant l’utilisation de la
pensée critique pour définir l’approche appropriée et une plus grande implication des
fournisseurs pour tirer parti de leurs connaissances, de leur expérience et de leur
documentation.

3.2.5. ISO 9001 : 2015

Bien que cette norme internationale ne soit pas spécifique aux systèmes informatisés BPx, elle
fournit un cadre général pour la mise en place et le maintien d'un système de management de
la qualité (QMS) dans une organisation. Les systèmes informatisés BPx peuvent être intégrés
dans un QMS conforme à l'ISO 9001 pour garantir la qualité et la conformité des processus et
des produits (28).

23
 3.3. Approches couramment utilisées pour la validation des systèmes informatisés

Dans le secteur des produits pharmaceutiques et des dispositifs médicaux, la méthode de

validation la plus répandue consiste à suivre les guidances GAMP® 5 et à décomposer le
processus en phases du cycle de vie.

Selon le GAMP (Good Automated Manufacturing Practice), il existe quatre phases du cycle de
vie d'un système informatique, qui sont décrites ci-dessous (25):

Figure 1 Cycle de vie des systèmes informatisés - ISPE GAMP® 5 (Second Édition)

- Phase de Conception

La phase de conception consiste en la formulation de l'idée d'un système. Durant cette

étape, on dispose d'une vision générale de ce que devrait réaliser le système. Cette phase
comprend la collecte de données, comme les fournisseurs, les couts, le plan de projet
de haut niveau, les ressources, les délais, les avantages, les restrictions et la justification
de la nécessité du système. Il est recommandé de réaliser une première évaluation des
risques à ce stade, en se posant des questions telles que : quels sont les risques pour
l'entreprise de mettre en œuvre ou de ne pas mettre en œuvre ce système ? Dans quels
cas une évaluation plus approfondie des risques sera-t-elle nécessaire ?

- Phase de Projet

24
 La phase de projet concerne la planification, la conception, le développement et la
validation du système informatisé. Tout au long de cette étape, une gestion des risques,
une gestion des changements et une gestion documentaire appropriée, est essentielle
pour assurer la conformité aux règlementations et aux bonnes pratiques.

- Phase d'Exploitation
Une fois que le système informatisé a été validé et mis en service, il entre dans l'étape
d'opération. Cette étape consiste à utiliser et à maintenir le système dans des conditions
réelles d'utilisation. Les activités clés de cette étape comprennent la formation des
utilisateurs, la maintenance du système, la gestion des incidents et des problèmes, la
gestion des changements et des mises à niveau, et la surveillance continue des
performances et de la conformité. L'évaluation et la gestion des risques doivent être
maintenues tout au long de cette étape pour garantir que le système continue de
répondre aux exigences de qualité et de sécurité.

- Phase de Mise hors service

L'étape de mise hors service (retirement) concerne la fin du cycle de vie du système
informatisé. Les raisons de la mise hors service d'un système peuvent inclure
l'obsolescence, la migration vers un nouveau système ou la fin du support du
fournisseur. Cette étape implique la planification et l'exécution de la mise hors service,
y compris la sauvegarde et l'archivage des données, la désinstallation du matériel et du
logiciel, et la communication aux parties prenantes. Des procédures appropriées doivent
être mises en place pour garantir la protection des données et la conformité aux
règlementations pendant et après la mise hors service.

3.3.1. Modèle cycle en V

Il est courant pour les entreprises et les organisations du secteur pharmaceutique de suivre le
modèle en V du GAMP5 pour valider leurs systèmes, car cela répond aux exigences des
organismes de règlementation du domaine. Ce modèle est utilisé pour visualiser la relation
entre les exigences et les spécifications de l'utilisateur, ainsi que la vérification et les tests
effectués sur ces dernières (voir le diagramme ci-dessous).

25
Figure 2 Modèle cycle en V

Le cycle en V représente les différentes phases du développement et de la validation d'un

système informatisé, depuis l'analyse des besoins jusqu'à la mise en service, en passant par la
conception, le codage, les tests et la qualification. Chaque phase du cycle en V est associée à
un niveau de documentation et à un niveau de test correspondant. Cette approche est à adapter
en fonction de la catégorisation du système, sa complexité, son impact et le niveau
d'externalisation des composants.

Le processus de validation commence par la planification, se poursuit avec la configuration

et/ou le codage, puis remonte vers la droite pour se conclure par un rapport. La branche gauche
du modèle en V décrit les fonctionnalités du système informatique et son mode de
fonctionnement, tandis que la branche droite représente les procédures de test pour vérifier
l'adéquation du système à l'objectif visé, garantissant ainsi que le système informatisé est
conforme aux exigences règlementaires et aux besoins des utilisateurs.

a. Planification

La phase de planification de la validation sert à définir et décrire les étapes et les activités
nécessaires pour définir le périmètre, les objectifs, les responsabilités et les livrables de la
validation. Elle est généralement menée par l'utilisateur final ou le client (25).

Les livrables et activités réalisées au cours de cette étape sont les suivants :

26
 - Description du système

C'est un document unique, clair et concis qui décrit l'objectif et la fonction du système. Ce
document n'est donc pas nécessaire pour les systèmes moins complexes pour lesquels un seul
document de spécification fonctionnelle est disponible.

La description du système est un document utile à présenter lors d'une inspection et doit être
rédigée dans un langage non technique afin d'être compréhensible pour un inspecteur sans avoir
besoin d'une expertise technique. Il doit comprendre :

o Un diagramme indiquant la disposition physique du matériel du système,

o Toutes les interfaces automatisées et manuelles, et les fonctions clés indiquant
les entrées, les sorties et le traitement principal des données.

Ces informations peuvent être incluses dans le plan de validation ou la déclaration de

détermination de la conformité, dans ce cas il n'est pas nécessaire de les dupliquer.

- Plan de validation

Un plan de validation représente un document formel qui expose le champ d'application, les
objectifs, la stratégie, les rôles et responsabilités, les livrables et les critères d'acceptation pour
la validation d'un système informatisé. L'objectif principal d'un tel plan est de garantir que le
système respecte les exigences réglementaires, les normes et les objectifs de qualité établis par
l'entreprise.

Le plan de validation doit être élaboré en tenant compte de l'utilisation prévue du système, des
exigences des utilisateurs, de l'évaluation initiale des risques, de la réglementation et des
normes applicables. Il doit également être en accord avec le plan du projet et le plan qualité.

Le plan de validation doit également prévoir des processus de gestion des écarts et des mesures
correctives et préventives (CAPA) pour s'assurer que tout écart par rapport aux activités
planifiées ou aux résultats attendus est correctement enregistré, examiné, résolu et signalé.

La formation constitue également un aspect crucial du plan de validation. La section consacrée

à la formation doit exposer les exigences en matière de formation pour les membres de l'équipe
de validation et les utilisateurs.(25)

27
 b. Spécifications

- Spécification des Exigences Utilisateur (User Requirement Specification, URS)

La Spécification des Exigences Utilisateur (URS) est un document détaillant les attentes de
l'utilisateur en termes de logiciel et ses modalités d'utilisation. Ce document inclut également
toutes les contraintes, telles que les règlementations, les exigences de sécurité et les exigences
opérationnelles. Les besoins des utilisateurs peuvent être classifiés en deux catégories :
exigences essentielles et exigences souhaitables.

Les exigences essentielles sont indispensables pour assurer la qualité des produits, la santé des
patients, la conformité règlementaire et l'intégrité des données. Ces exigences comprennent
notamment :

o Fonctionnement du système

o Intégrité des données

o Exigences techniques

o Environnement d'exploitation

o Performances

o Disponibilité du système et des informations

o Sécurité de l'information

o Exigences règlementaires

o Restrictions d'utilisation, etc.

Les exigences souhaitables ne sont pas critiques et visent à améliorer le système dans le futur,
modifier l'esthétique du système ou aborder certaines politiques et questions de l'entreprise. Le
risque associé à ces exigences est minime et elles sont acceptables. Elles sont envisagées
comme des options, mais ne sont pas réalisées si l'entreprise n'y est pas engagée. Ces exigences
incluent, entre autres :

o Format de présentation des données

o Interface graphique esthétique

o Optimisation des performances

o Améliorations non urgentes des performances, etc.

28
La Spécification des Exigences Utilisateur doit être élaborée par consensus entre l'utilisateur
final/client et le fournisseur. Les acteurs impliqués dans la rédaction de l'URS comprennent les
propriétaires du processus, les propriétaires du système, les experts techniques, le personnel de
la qualité et le fournisseur, si nécessaire.

Référence Exigence Description Type d’exigence

URS-01 Le système doit être capable Le système doit pouvoir gérer au moins Spécification du
de gérer 10 000 utilisateurs 10 000 utilisateurs connectés en même projet
simultanément. temps sans dégradation des
performances.
URS-02 Le système doit assurer la Le système doit enregistrer l'identifiant Réglementation et
traçabilité des actions de l'utilisateur, l'action effectuée, la conformité
effectuées par les date et l'heure de chaque action.
utilisateurs.
URS-03 Le système doit générer des Les utilisateurs doivent pouvoir créer Besoin
rapports personnalisables. des rapports personnalisés en fonctionnel
sélectionnant les critères souhaités
(période, utilisateurs, actions, etc.).
URS-04 Le système doit être Le système doit fonctionner sous Spécification du
compatible avec les systèmes Windows, macOS et Linux. projet
d'exploitation courants.
URS-05 Le système doit permettre Les utilisateurs doivent saisir un Besoin
l'authentification des identifiant et un mot de passe pour fonctionnel
utilisateurs par mot de passe. accéder au système.
URS-06 Le système doit disposer L'interface doit être intuitive et Spécification du
d'une interface conviviale et ergonomique, permettant une prise en projet
facile à utiliser. main rapide par les utilisateurs.
URS-07 Le système doit permettre la Les administrateurs doivent pouvoir Besoin
gestion des droits d'accès des attribuer des droits d'accès aux fonctionnel
utilisateurs. fonctionnalités du système selon les
rôles des utilisateurs.
Figure 3 Exemple d'URS

- Spécifications fonctionnelles (Functional Specification FS)

Les spécifications fonctionnelles ou FS est un document qui décrit les actions attendues de
chaque élément fonctionnel d'un système informatisé afin de répondre aux besoins des
utilisateurs.

Elles sont utilisées comme base pour réaliser l’analyse de risque du système. Les spécifications
fonctionnelles sont basées sur les besoins des utilisateurs et sur les spécifications techniques
du fournisseur du système.

Elles sont généralement rédigées par le fournisseur ou basées sur des informations techniques
fournies par ce dernier et décrivent en détail les conditions dans lesquelles le système doit
fonctionner de manière adéquate.

Parmi les spécifications fonctionnelles clés, on peut citer la configuration opérationnelle,

l'interface avec d'autres systèmes et dispositifs, la sécurité et l'accès contrôlé, l’audit trail (si

29
nécessaire), les calculs de performance, les capacités opérationnelles/gestion de l'information,
et les sauvegardes.

- Spécifications de conception (Design Specification)

La spécification de conception fournit une description détaillée de la manière dont chaque

fonctionnalité doit être conçue ou configurée. Ce document technique succède à la spécification
fonctionnelle et peut inclure des spécifications de configuration ou du code source. Il est destiné
principalement aux développeurs du système.

Les spécifications de conception représentent la description des éléments nécessaires pour que
le système réponde aux caractéristiques établies à partir des exigences des utilisateurs et/ou des
spécifications fonctionnelles.

Plus technique, ce document succède à la spécification fonctionnelle et peut contenir des

spécifications de configuration ou du code source. Il est principalement destiné aux
développeurs du système.

Habituellement, les spécifications de conception décrivent la structure du système, sa

maintenance, les spécifications matérielles, la conception de l'interface utilisateur, la
conception des programmes, les interfaces, les spécifications de configuration, les paramètres,
la documentation et les logiciels de support. Elles précisent également les conditions
d'utilisation du système.

En fonction du système informatique et du processus concerné, les principales spécifications

de conception peuvent inclure les éléments suivants : formats d'impression, d'affichage et de
saisie de données, modèles de conception, macros et formules de code, documentation requise,
spécifications matérielles et des périphériques, contrôle des versions, logiciels de support, mots
de passe et référentiels d'informations utilisateur, versions des programmes, systèmes
d'exploitation et formats, procédures d'exploitation, de création, de modification et de
réception, entre autres.

c. Configuration et/ou codage

Au cours de cette phase, le logiciel est élaboré, développé ou acquis (en fonction de la catégorie
de logiciel) et configuré afin de satisfaire aux critères établis dans les documents de
spécification précédemment définis. Cette étape est généralement mise en œuvre par le
fournisseur.

30
Les prestataires ont la responsabilité de choisir et d'appliquer les méthodes et les modèles de
développement les mieux adaptés aux exigences de codage et de configuration, en s'appuyant
sur les spécifications approuvées. Ils doivent également veiller à ce que les besoins utilisateur
et les spécifications prennent en considération les impératifs de codage et de configuration du
système pour l'usage prévu, ainsi que la manière dont ces développements et configurations
doivent être consignés dans la documentation.

d. Vérification et phases de tests

La validation des systèmes informatisés BPx implique la vérification du respect des

spécifications établies. Ce processus peut comporter diverses étapes de contrôle et d'essais, en
fonction des risques identifiés dans l’analyse de risque, de la nature du système, de la méthode
de développement employée et de son usage. Le niveau d’effort de test à réaliser est
proportionnel aux niveaux de risques identifiés.

Le test des systèmes informatisés constitue une étape cruciale dans le processus de vérification.
L'objectif des tests est de minimiser les risques de survenu d’une défaillance, d'identifier et
corriger les défaillances, tout en démontrant la conformité du système aux exigences
préétablies.

Les tests doivent être déterminés à travers un ou plusieurs protocoles couvrant les aspects
matériels, logiciels et de configuration du système ainsi que la formation des utilisateurs et la
mise en place des procédures opérationnelles. Ces protocoles exposent clairement la
méthodologie de chaque phase, établissent un but et une portée spécifique pour les tests
effectués, documentent les responsabilités et définissent les critères d'acceptation pour chaque
essai afin de faciliter la comparaison des résultats. La portée et le contenu des protocoles
doivent être proportionnels à la complexité du système à valider.

Il n'est pas nécessaire de créer un protocole distinct pour chaque étape de validation des grands
systèmes ni d'avoir un protocole unique couvrant toutes les étapes pour les systèmes de petite
envergure. La seule contrainte réside dans l'ordre des tests et l'interdépendance des résultats,
de sorte que les phases de qualification soient effectuées de manière séquentielle, suivant cet
ordre : (1) qualification de l'installation (QI), (2) qualification opérationnelle (QO) et (3)
qualification de performance (QP).

Le passage à l'étape suivante n'est normalement possible qu'après la réussite de la phase

précédente, ou lorsque l'absence de non-conformités majeures est démontrée et que l'évaluation

31
et la documentation de l'absence d'impact significatif sur l'étape suivante sont réalisées, mais
selon la complexité du système il est possible que les étapes soient réalisées simultanément
(29).

- Qualification de conception

La qualification de la conception, appliquée aux systèmes informatisés, vise à démontrer que

la conception proposée par le fournisseur (interne ou externe à l’entreprise) répond aux
exigences fonctionnelles et règlementaires et qu'elle est donc apte à être utilisée. Elle est la
première étape de la validation et doit être réalisée avant de commencer la qualification de
l'installation.

L'objectif de cette qualification est de garantir un haut degré de confiance que le système
proposé par le fournisseur, au moins sur le plan documentaire, peut répondre aux exigences de
conception et est adapté à l'utilisation prévue.

Dans le cadre de cette qualification de conception, on vérifie que les exigences utilisateur
(URS) sont couvertes au minimum par les spécifications fonctionnelles (FS), ou par une
spécification technique si le système est trop technique. De plus, il est essentiel de s'assurer que
toutes les exigences réglementaires ont bien été prises en compte dans les URS.

La qualification de la conception est réalisée en préparation du reste de la validation, afin que

les écarts découverts pendant la qualification de la conception puissent être résolus avant les
étapes les plus critiques et les plus coûteuses de la validation. À ce stade, il est même possible
de décider de retirer le système lorsque le risque que le système ne réponde plus aux exigences
actuelles du processus est considéré comme élevé.

La qualification de la conception est une exigence règlementaire qui s'applique uniquement

aux systèmes personnalisés ou sur mesure de catégorie 5 du GAMP.

- Qualification d’installation

La qualification de l'installation a pour but de confirmer que le logiciel ou système est

correctement installé et configuré. Elle vérifie que le système est équipé des composants
matériels et logiciels nécessaires pour fonctionner correctement.

Parmi les éléments vérifiés, on trouve : les logiciels et matériels installés, les interfaces, la
documentation, les spécifications techniques, la topologie, les profils d'utilisateurs et la
conformité aux conditions environnementales.

32
D'autres aspects vérifiés incluent les méthodes d'installation, les diagrammes de processus, la
description du matériel associé, les manuels d'utilisation et les procédures d'exploitation
standards. Des photographies, des rapports d'impression et des captures d'écran sont
recommandés comme preuves lors de la mise en œuvre du protocole de qualification
d'installation (QI).

La qualification de l'installation est une étape importante dans le processus de validation. Elle
doit être réalisée par une équipe qualifiée et expérimentée, en suivant les protocoles établis et
en utilisant des méthodes de test appropriées. En cas de non-conformité, il est crucial de
résoudre rapidement les problèmes et de mettre en place des mesures correctives.

- Qualification opérationnelle

La qualification opérationnelle, aussi appelée test fonctionnel, est un processus permettant de

vérifier que toutes les fonctions d'un système, définies dans les spécifications fonctionnelles,
sont présentes et fonctionnent correctement. Cela inclut la vérification de l'absence de bugs
logiciels pour des logiciels sur mesure.

La qualification opérationnelle est effectuée pour confirmer que le système fonctionne selon
les affirmations du fournisseur. Par exemple, si un système informatisé est responsable du
remplissage de liquide dans des flacons, le processus de qualification opérationnelle
comprendra des tests pour s'assurer que le système lance correctement le processus de
remplissage.

Il est important de noter que les procédures standards ne permettent pas au vendeur ou au
développeur de remplacer les tests sur site effectués par le client par ses propres tests de
qualification. Il est nécessaire de vérifier l'adéquation du système à l'emplacement, au
personnel, aux installations, aux équipements et aux procédures spécifiques de l'organisation.

Pendant la qualification opérationnelle, toutes les fonctions exécutées par le système doivent
être testées, ainsi que tout élément de sécurité présent dans le système. Les étapes de test et les
résultats attendus doivent être documentés. Les principaux éléments à prendre en compte au
cours de cette phase sont le bon fonctionnement des éléments logiciels et matériels, les
procédures opérationnelles standards (SOP), les mesures de sécurité informatique, la formation
aux SOP, le contrôle d'accès et la communication avec les bases de données.

La qualification opérationnelle peut être testée en utilisant les méthodes de test de type « boîte
blanche » ou de type « boîte noire ».

33
Les tests en boîte blanche sont une approche de test logiciel où les testeurs ont accès à la
structure interne du système ou du logiciel testé pour concevoir des cas de test basés sur la
connaissance de cette structure. Ces tests de type « boîte blanche » sont recommandés pour les
logiciels personnalisés.

Les tests en boîte noire, également appelés tests fonctionnels, sont une approche de test logiciel
qui se concentre sur le comportement externe d'un système ou d'un logiciel sans avoir
connaissance de sa structure interne, en évaluant les entrées et les sorties attendues sans se
préoccuper de la manière dont ces résultats sont obtenus. Les tests de type « boîte noire » sont
plus pratiques pour les systèmes standardisés.

Il est recommandé d'utiliser des photographies, des rapports imprimés et des captures d'écran
comme support documentaire lors de la mise en œuvre du protocole de qualification
opérationnelle.

- Qualification de performance

La qualification de performance, également connue sous le nom de "test des exigences de

l'utilisateur", a pour objectif de confirmer que le système informatisé satisfait aux besoins des
utilisateurs et convient à l'usage prévu, tel que défini dans le cahier des charges des exigences
utilisateur (User Requirement Specification, URS). Elle permet de vérifier de manière
documentée que le système est capable de réaliser et de contrôler les activités requises par le
processus, conformément aux spécifications approuvées, avant de fonctionner dans un
environnement opérationnel comprenant le personnel, les installations, les procédures, les
équipements et toutes autres politiques pertinentes pour la mise en œuvre du système au sein
de l'organisation.

La qualification de performance vise à démontrer l'efficacité et la reproductibilité des

opérations effectuées par le système une fois intégré au processus, et à vérifier que les
exigences préalablement définies du processus et les conditions d'utilisation courante sont
respectées, toujours dans les limites de fonctionnement établies.

Les essais de qualification de performance cherchent à simuler le fonctionnement du système

pour déterminer si les procédures et les contrôles de processus répondent aux attentes des
utilisateurs. Ils permettent de vérifier que le système est en mesure de répondre aux exigences
demandées.

L'ensemble des tests de cette qualification doit être renforcé en fonction des procédures et des
contrôles du processus, par rapport aux exigences des utilisateurs établies au début du cycle de

34
validation. Elle doit vérifier la cohérence des résultats à travers des tests incluant des flux de
travail complets et leur application à divers utilisateurs.

La qualification de performance doit être exécutée avec différents utilisateurs et scénarios

variés au sein du processus. L'exécution des sous-processus et leurs résultats doivent être
cohérents avec la satisfaction des exigences établies des utilisateurs. Contrairement à la
qualification opérationnelle, cette qualification teste le système pour les résultats attendus pour
l'ensemble du flux (ou des flux) du processus avec tous les composants intégrés. Les tests sont
définis en référence au flux du processus identifié sous ce processus.

e. Rapports de validation

- Rapports de qualification

À la fin de chaque phase du projet, il est nécessaire de préparer un rapport présentant les
résultats de cette phase. Ce rapport doit résumer les activités de la phase, indiquer s'il y a eu
des déviations par rapport au plan de validation et le statut du système par rapport aux objectifs
du projet et aux exigences précédemment établies. Le format et le contenu de ce rapport doivent
respecter les dispositions du système de gestion de la qualité et des procédures de validation de
chaque organisme, tout en respectant les exigences règlementaires minimales requises.

Il est possible de préparer ce rapport de différentes manières, soit en créant un rapport qui
résume les résultats de chaque phase en cours, soit en créant un rapport général qui regroupe
les résultats de toutes les phases réalisées, notamment pour les systèmes simples à faible risque.

- Rapport final de validation

À la fin de la qualification des performances, nous devons établir si le système peut être déclaré
validé ou non. Pour cela, nous devons préparer un rapport de validation justifiant cette
conclusion et établissant la conformité avec les aspects règlementaires suivants qui ont dû être
démontrés lors des phases de validation : exactitude, fiabilité, fonctionnalité, cohérence et
capacité à distinguer les enregistrements invalides ou modifiés ; protection, intégrité et
sauvegarde des informations ; protection des enregistrements à créer, modifier, maintenir,
archiver, récupérer et/ou transmettre ; système de protection, d'intégrité et de sauvegarde des
informations ; accès contrôlé ; capacité, formation et expérience des personnes développant,
maintenant ou utilisant les systèmes pour accomplir leurs tâches.

Le rapport final doit également indiquer l'existence de tous les documents enregistrés dans le
plan de validation relatif aux produits livrables et montrer la libération de ceux-ci. Enfin, le

35
rapport doit établir clairement que toutes les exigences obligatoires ont été satisfaites pour que
le système soit considéré comme adapté à l'usage auquel il est destiné et donc déclaré « validé »
ou « non validé ».

3.3.2. Modèle agile

a. Principes

La méthode agile est une approche de gestion de projet et de développement logiciel qui met
l'accent sur la collaboration, la flexibilité, la rapidité et l'amélioration continue. Elle est conçue
pour s'adapter rapidement aux changements de besoins ou de priorités, favorisant ainsi la
livraison rapide et la satisfaction du client. La méthode agile se base sur les principes du
Manifeste agile, publié en 2001 par un groupe de développeurs de logiciels.

Les valeurs clés du Manifeste agile sont les suivants (30) :

- La priorité est donnée aux individus et aux interactions plutôt qu'aux processus et aux
outils.
- La réalisation de logiciels fonctionnels est privilégiée par rapport à une documentation
exhaustive.
- La collaboration avec les clients est favorisée plutôt que la négociation contractuelle.
- Être prêt à répondre aux changements, même tardifs, plutôt que de suivre un plan établi.

Il existe plusieurs cadres et méthodologies Agile, parmi lesquels Scrum, Kanban, Extreme
Programming (XP) et Feature-Driven Development (FDD). Chacun de ces cadres à ses propres
pratiques, rôles et processus, mais tous partagent l'objectif commun de créer un environnement
de travail flexible et adaptatif.

b. Le modèle SCRUM

Scrum est l'une des méthodologies Agile les plus populaires. Elle implique des cycles de travail
itératifs appelés sprints, qui durent généralement de deux à quatre semaines. Chaque sprint
commence par une planification et se termine par une revue et une rétrospective. Les membres
de l'équipe travaillent ensemble pour accomplir les objectifs définis pour chaque sprint et
ajustent leurs priorités en fonction des retours d'information et des besoins changeants (31).

Les éléments clés du modèle SCRUM sont les suivants :

- Rôles Scrum

36
 o Product Owner (PO) : Il définit les fonctionnalités et les priorités du produit en
fonction des besoins des utilisateurs et des parties prenantes.
o Scrum Master (SM) : Il facilite le processus Scrum, s'assure que l'équipe suit les
principes de Scrum et aide à résoudre les obstacles rencontrés.
o Équipe de développement : Les membres de l'équipe travaillent ensemble pour
créer le produit en utilisant leurs compétences et leur expertise.
- Artéfacts Scrum
o Product Backlog : il s'agit d'une liste priorisée des fonctionnalités, des
améliorations et des corrections de bugs souhaitées pour le produit. Les
éléments du Product Backlog sont souvent décrits en termes d'Epics, d’User
Stories et de Tasks.
▪ Epic : un grand objectif ou une initiative qui englobe plusieurs User
Stories.
▪ User Story : une description concise d'une fonctionnalité souhaitée,
généralement du point de vue de l'utilisateur final.
▪ Task : une unité de travail spécifique nécessaire pour accomplir une User
Story.
o Sprint Backlog : c'est la liste des éléments sélectionnés du Product Backlog qui
seront développés pendant un sprint, y compris les User Stories et les Tasks
associées.
o Increment : c'est le produit partiellement fonctionnel qui est livré à la fin de
chaque sprint.

- Évènements Scrum
o Sprint : Il s'agit d'une période de temps définie, généralement de 2 à 4 semaines,
au cours de laquelle l'équipe travaille pour accomplir un ensemble d'objectifs
spécifiques.
o Sprint Planning : Au début de chaque sprint, l'équipe se réunit pour planifier les
éléments du Product Backlog à développer pendant le sprint, en décomposant
les User Stories en Tasks si nécessaire.
o Daily Scrum (ou Daily Stand-up) : une réunion quotidienne de 15 minutes au
cours de laquelle les membres de l'équipe font le point sur leur travail, discutent
des obstacles et coordonnent leurs efforts.

37
 o Sprint Review : à la fin du sprint, l'équipe présente les éléments développés
pendant le sprint aux parties prenantes et recueille leurs commentaires.
o Sprint Retrospective : L'équipe se réunit pour réfléchir à la façon dont le sprint
s'est déroulé et discuter des améliorations à apporter au processus.

Figure 4 Modèle agile – Scrum (31)

c. Outils couramment utilisés en projet SCUM

Dans un projet Scrum, plusieurs outils sont couramment utilisés pour faciliter la gestion du
projet, la collaboration entre les membres de l'équipe et le suivi des progrès. Voici quelques-
uns des outils les plus populaires :

- Jira

Jira est un outil de gestion de projet développé par la société Atlassian, spécialement
conçu pour les équipes agiles. Il permet de créer des stories, des tâches et des bugs, de
les assigner aux membres de l'équipe, et de suivre leur progression à travers le tableau
Scrum ou Kanban.
- Confluence
Confluence, également développée par Atlassian, est un outil de collaboration et de
documentation qui permet aux équipes de créer, organiser et partager des documents,
des notes et des idées. Il s'intègre étroitement avec Jira, facilitant le suivi des décisions
et des informations clés liées au projet.
- Asana

38
 Asana est un autre outil de gestion de projet populaire qui offre des fonctionnalités
similaires à celles de Jira et Trello. Il est facile à utiliser et offre des vues de liste, de
calendrier et de tableau pour gérer les tâches.
- GitHub ou GitLab

Ces plateformes offrent des fonctionnalités de gestion de code source, de suivi des
problèmes et d'intégration continue/déploiement continu (CI/CD). Elles sont utiles pour
les équipes de développement qui travaillent sur des projets Scrum, car elles facilitent
la collaboration sur le code et le suivi des problèmes.

d. La validation en projet agile SCRUM

Si elle est utilisée par des professionnels formés et qualifiés, et avec l'appui des outils
appropriés, la méthodologie agile SCRUM convient parfaitement au développement de
systèmes règlementés BPx. Toutefois, il est important d'adopter certaines bonnes pratiques
pour assurer une mise en œuvre correcte.

Il est également crucial d'impliquer les parties prenantes clés tout au long du processus, en
s'assurant que tous les membres de l'équipe comprennent les exigences BPx et que les parties
prenantes concernées, telles que l'assurance qualité, sont impliquées dès le départ.

Pour garantir la conformité aux règlementations BPx tout au long du processus de

développement, il est essentiel d'intégrer les exigences règlementaires dans les users story dès
le début du projet, lors de la phase de planification.

Les activités de validation doivent également être incluses dans le backlog du produit. Les
tâches de validation, telles que la rédaction des protocoles de test, l'exécution des tests de
validation et la documentation, doivent être planifiées en tant que partie intégrante du processus
de développement.

Pour assurer la conformité aux règlementations BPx, il est essentiel que chaque User Story
inclue les exigences de validation correspondantes. Cela devrait inclure la définition des
risques, les tests associés, l'exécution réussie de ces tests et la revue par les parties prenantes
concernées.

Si nécessaire, il peut être judicieux d'organiser des sprints spécifiques à la validation pour se
concentrer sur les activités de validation, telles que l'exécution des tests de validation et la
finalisation de la documentation requise.

39
Il est crucial de mettre en place un système de traçabilité qui permette de relier les exigences
règlementaires à tous les éléments de travail, ce qui facilite grandement les audits et les
inspections. Une matrice de traçabilité est un outil très utile qui permet de lier les User Stories,
les risques identifiés et les tests exécutés aux exigences règlementaires.

Des revues régulières avec les parties prenantes responsables de la validation doivent être
organisées pour s'assurer que les exigences de validation sont correctement prises en compte
tout au long du processus de développement.

L'automatisation des tests de validation et de la génération de la documentation est une option

à considérer pour gagner en efficacité et en fiabilité.

Comme pour tout projet agile, il est important de rester flexible et de s'adapter aux changements
des exigences ou des priorités tout en maintenant la conformité aux règlementations BPx.

Enfin, il est recommandé d'effectuer des audits internes et des revues de projet pour vérifier
que les exigences BPx sont respectées et pour identifier les opportunités d'amélioration.

3.4. Processus de support à la validation

En complément du processus de validation, plusieurs processus de support sont nécessaires

pour garantir la conformité des systèmes informatisés BPx.

Ces processus incluent notamment le management du risque, la revue de conception, le contrôle

des changements, la gestion de la documentation et la gestion de la traçabilité. Chacun de ces
processus est essentiel pour assurer la qualité, la sécurité et l'efficacité des systèmes
informatisés BPx.

3.4.1.Management du risque

La gestion des risques est un aspect important du cycle de vie des systèmes informatisés dans
l'industrie pharmaceutique. Elle implique l'identification, l'évaluation et l'atténuation des
risques qui peuvent survenir lors du développement, de la mise en œuvre et de la maintenance
des systèmes informatisés.

Le GAMP 5 propose plusieurs étapes clés dans la gestion des risques au cours du cycle de vie
d'un système informatisé (25):

40
 a. Étape 1 - Évaluation initiale des risques et déterminer l'impact sur le système

L'évaluation initiale des risques se déroule lors de conception et vise à déterminer si le système
informatisé est soumis aux règlementations BPx et à évaluer son influence sur les processus
opérationnels de l'organisation. Durant cette phase, la classification du système est effectuée,
permettant ainsi d'identifier les activités de validation requises.

Les catégories de systèmes informatisés, conformément au modèle GAMP, sont décrites de

manière approfondie dans la figure ci-après.

Catégorie Description Exemples

Logiciels d'infrastructure utilisés pour gérer Systèmes d'exploitation, moteurs de
1 l'environnement d'exploitation et sur lesquels les bases de données, intergiciels,
applications sont construites. langages de programmation, etc.
Logiciels non configurés permettant de saisir et de stocker Réglage de l'heure sur un smartphone,
3 des paramètres, mais qui ne peuvent pas être configurés applications basées sur un
pour s'adapter au processus métier. micrologiciel, etc.
Logiciels configurés pouvant être modifiés par l'utilisateur
pour répondre aux besoins spécifiques de son processus Système de gestion de l'information
4 commercial, sans modification du code du logiciel lui- des laboratoires, planification des
même. La plupart des logiciels utilisés dans le secteur ressources de l'entreprise, etc.
pharmaceutique/médical sont de cette catégorie.
Applications informatiques
développées en interne ou externe,
Logiciels personnalisés, conçus et codés sur mesure pour
5 applications de contrôle de processus
s'adapter à un processus commercial spécifique.
développées en interne ou externe,
micrologiciels personnalisés, etc.
Figure 5 - Catégories des systèmes informatisés selon le GAMP 5

En tenant compte du contexte et des exigences propres à chaque système informatisé BPx, tels
que la complexité, la catégorie et l'impact du système, ainsi que le niveau d'externalisation de
ses composants, les efforts de validation sont répartis comme suit :

- Validation des systèmes de catégorie 3 selon le GAMP

Les activités de validation pour ces systèmes incluent des tâches spécifiques adaptées à leur
degré de personnalisation limité et à leur faible complexité. Ces activités comprennent
généralement la vérification des spécifications fonctionnelles, la réalisation de tests
d'intégration et la documentation des résultats.

41
Figure 6 - Cycle en V des systèmes de catégorie 3 selon le GAMP - - ISPE GAMP® 5 (Second Édition)

- Validation des systèmes de catégorie 4 selon le GAMP

Les activités de validation pour ces systèmes, plus complexes et personnalisés que ceux de
catégorie 3, englobent l'élaboration de plans de validation détaillés, la revue des spécifications
fonctionnelles et techniques, l'exécution de tests fonctionnels et de régression, ainsi que la
traçabilité des exigences et la documentation appropriée.

Figure 7 Cycle en V des systèmes de catégorie 4 selon le GAMP - ISPE GAMP® 5 (Second Édition)

- Validation des systèmes de catégorie 5 selon le GAMP

42
Les activités de validation pour ces systèmes hautement complexes et personnalisés
comprennent l'identification des risques, la conception de plans de validation spécifiques,
l'évaluation des exigences fonctionnelles et techniques, la réalisation de tests exhaustifs et la
documentation détaillée des résultats pour garantir la conformité avec les règlementations en
vigueur.

Figure 8 - Cycle en V des systèmes de catégorie 5 selon le GAMP - ISPE GAMP® 5 (Second Édition)

b. Étape 2 - Identifier l’impact de chaque fonction du système

Le but de cette étape est de repérer les impacts potentiels des différentes fonctions du système
sur la sécurité du patient, l’intégrité des données et la qualité du produit.

Cela peut être fait en utilisant les informations collectées lors de la première étape du projet,
en consultant les spécifications pertinentes et en prenant en compte l'approche du projet,
l'architecture du système et la catégorisation des composants du système.

c. Étape 3 - Analyse des risques fonctionnelle et identification des contrôles

L’analyse de risques fonctionnelle est un processus utilisé pour identifier et évaluer les risques
potentiels liés aux fonctionnalités et aux composants d'un système.

La méthodologie la plus utilisée est la méthode AMDEC (Analyse des Modes de Défaillance
de leurs Effets et de leur Criticité).

La méthode AMDEC est basée sur une analyse en cinq étapes :

43
- Identification des éléments du système : Cette étape consiste à décomposer le système
BPx en ses principaux éléments, sous-systèmes et composants, puis à identifier les
fonctions et les exigences associées à chacun d'entre eux. Il est également possible de
décomposer le système en processus pour les systèmes de type ERP impliqués dans des
processus multiples.

- Identifier les modes de défaillance : cette étape consiste à identifier les différents modes
de défaillance qui peuvent survenir pour chaque élément, ainsi que les causes
potentielles de ces défaillances. Les principaux modes de défaillance rencontrés sont
les suivants :

o Perte ou altération de données

o Fonctionnalités et utilisation du système non maîtrisées (traitement non
conforme aux exigences des utilisateurs)
o Enregistrements de données indisponibles, incorrects, incomplets ou illisibles
o Source de données non maîtrisé

- Évaluer les impacts et la sévérité de chaque mode de défaillance : cette étape consiste
à évaluer les conséquences potentielles de chaque mode de défaillance, en termes de
sécurité, de qualité et de performance.

- Évaluer la probabilité de survenue de chaque mode de défaillance : cette étape consiste

à évaluer la probabilité de survenue de chaque mode de défaillance, en utilisant des
données statistiques et/ou des expériences antérieures.

Figure 9 Détermination de la criticité des modes de défaillance

- Estimation de la classe du risque : Évaluer la criticité de chaque mode de défaillance en

tenant compte de la probabilité d'occurrence et de la gravité de l'effet sur le système. La
criticité est généralement exprimée par un indice numérique nommé classe du risque.

- Priorisation des modes de défaillance : En combinant la classe du risque déterminée

précédemment avec la probabilité de détection du risque, il est possible de classer les

44
 modes de défaillance en fonction de leur criticité, afin d'identifier les problèmes les plus
critiques qui nécessitent une attention immédiate.

Figure 10- Priorisation des modes de défaillance selon leur criticité

- Définir les actions correctives : cette étape consiste à proposer des actions pour réduire
la probabilité d'occurrence, minimiser les effets du mode de défaillance ou améliorer la
détection des modes de défaillance identifiés. Ces actions peuvent inclure des
modifications de conception, des améliorations de processus, des procédures de
contrôle qualité, etc.

d. Étape 4 - Implémentation et suivi

Mettre en œuvre les actions correctives et préventives, puis surveiller leur efficacité dans le
temps. Il est important de réévaluer régulièrement le risque pour tenir compte des changements
du système, de nouvelles données ou de l'évolution des exigences règlementaires.

e. Étape 5 - Examiner les risques et surveiller les contrôles

Un processus de vérification doit être mis en place afin de démontrer que les contrôles sont
efficaces pour réduire le risque.

L'intensité, la rigueur et la documentation associées à l'activité de vérification doivent être

proportionnelles au niveau de risque identifié.

- Niveau de risque faible

Des tests nominaux sont recommandés pour valider le fonctionnement du système dans
des plages d'opération représentatives, conformément aux spécifications utilisateur. Ces
tests attestent que le système réalise les tâches attendues.

- Niveau de risque moyen

45
 Des tests de défaillance sont suggérés pour évaluer la réaction du système face à des
conditions de fonctionnement anormales. Ces tests démontrent que le système
n'effectue pas d'opérations indésirables.

- Niveau de risque élevé

Des tests aux limites sont préconisés pour vérifier le comportement du système aux
extrémités du fonctionnement standard, c'est-à-dire dans les conditions de
fonctionnement les plus défavorables.

3.4.2.Gestion des changements

Des procédures adéquates de gestion des changements et de la configuration doivent être

instaurées pour garantir l'identification et la définition précises des systèmes informatisés BPx
et de leurs composants à chaque étape de leur cycle de vie.

Il est nécessaire de mettre en place des méthodes de gestion des changements englobant les
aspects logiciels, matériels et documentaires. La phase d'implémentation de ces processus de
gestion des changements doit être clairement spécifiée. De plus, les processus de gestion des
changements doivent être adaptés et appliqués tant aux phases de conception qu'à celles
d'exploitation du système.

Le processus de gestion des changements dans les systèmes informatisés BPx se déroule en
plusieurs étapes cruciales, qui sont les suivantes (25):

- Identification de la nécessité du changement et des bénéfices anticipés

Analyse approfondie de l'impératif du changement et des avantages potentiels qu'il

apportera.

- Évaluation de l'impact potentiel du changement sur le système et les processus associés

Analyse de la manière dont le changement affectera les fonctionnalités du système et
les processus connexes, ainsi que l'identification des conséquences possibles.

- Obtention des approbations requises pour le changement

Assurer que toutes les parties prenantes concernées valident le changement proposé,
conformément aux règlementations et aux politiques internes.

- Mise en œuvre contrôlée du changement

46
 Exécution du changement de manière structurée et supervisée pour minimiser les
perturbations et les risques.

- Vérification du changement
Réalisation de tests rigoureux pour confirmer que le changement produit l'effet
escompté et qu'aucun nouveau risque ou problème n'est introduit dans le système.

- Documentation du changement et des tests associés

Consignation précise des modifications apportées, des résultats des tests effectués et
des justifications pertinentes pour garantir la traçabilité et la conformité règlementaire.

La participation du fournisseur dans ces processus doit être clairement définie et convenue
préalablement, afin d'assurer une collaboration efficace et conforme aux exigences
règlementaires.

3.4.3.Matrice de traçabilité

La traçabilité est un processus qui garantit que les exigences peuvent être retracées jusqu'aux
besoins du processus opérationnel, qu'elles sont traitées et traçables jusqu'aux éléments
fonctionnels et de conception appropriée dans les spécifications, et qu'elles peuvent être
retracées jusqu'à la vérification appropriée. Ce processus permet de démontrer la couverture de
la conception et de la vérification, et facilite également l'évaluation et la gestion du
changement. Il est particulièrement important de se concentrer sur la traçabilité pour les aspects
qui sont critiques pour la sécurité des patients, la qualité des produits et l'intégrité des données.

Pour assurer cette traçabilité, une matrice de traçabilité doit être réalisée. La matrice de
traçabilité est un document qui montre les relations entre les différentes étapes de la validation,
en mettant l'accent sur les exigences de l'utilisateur et en les reliant aux analyses de risque, aux
spécifications de conception ou aux spécifications fonctionnelles, et aux tests de qualification
(QC, QI, QO, QP).

Elle a plusieurs avantages :

- Elle facilite la gestion et le suivi des exigences, des spécifications et de l'analyse de

risque.

- Elle permet de visualiser l'étendue de la qualification et des tests.

- Elle aide à démontrer que la validation est complète.

47
 - Elle permet de rationaliser la gestion des changements et de visualiser leur impact sur
la qualification.

La matrice de traçabilité est particulièrement utile lors des audits et inspections, car elle offre
une vue d'ensemble de la validation.

Pour créer une matrice de traçabilité, il faut d'abord publier les exigences de l'utilisateur et les
relier aux analyses de risque et aux spécifications de conception ou aux spécifications
fonctionnelles. Ensuite, il faut ajouter la matrice dans un document pour chaque test des
différents protocoles de qualification :

- Si la spécification concerne la conception, elle doit être liée à l'exigence de l'utilisateur

et au protocole de qualification de l'installation.

- Si la spécification concerne la fonctionnalité, elle doit être liée à l'exigence de

l'utilisateur et au protocole de qualification opérationnelle.

- Les exigences liées à la conception du système doivent être liées directement au

protocole de qualification de la conception.

- Les exigences liées à la performance du système doivent être liées directement au

protocole de qualification de la performance.

48
Figure 11 Exemple de matrice de traçabilité - ISPE GAMP® 5 (Second Édition)

3.4.4.Gestion de la documentation

La gestion documentaire est un élément clé dans la validation des systèmes informatisés BPx.
Les règlementations BPx, notamment les bonnes pratiques de fabrication (BPF), les bonnes
pratiques de laboratoire (BPL) et les bonnes pratiques de distribution (BPD), imposent des
exigences strictes en matière de documentation pour assurer l'intégrité, la traçabilité et la
transparence des données et des processus.

La gestion documentaire dans la validation des systèmes informatisés BPx implique la création,
la révision, l'approbation, la distribution, l'archivage des documents relatifs à la validation. Ces
documents peuvent inclure des protocoles de validation, des rapports de validation, des plans
de test, des spécifications fonctionnelles et techniques, des diagrammes de flux de processus,
des manuels utilisateur, des enregistrements d'audit, des procédures opérationnelles standards
(SOP).

Les documents doivent être créés et approuvés par des personnes compétentes et qualifiées, et
les modifications doivent être examinées et approuvées par des personnes autorisées avant leur

49
mise en œuvre. Les documents doivent être clairement identifiés et versionnés pour éviter toute
confusion ou perte de données.

La gestion documentaire doit également inclure des mesures de sécurité pour protéger les
documents contre la perte, la modification, la destruction ou l'accès non autorisé. Les systèmes
de gestion de documents doivent être conformes aux exigences de sécurité des données et être
auditables pour garantir l'intégrité des documents.

Enfin, la gestion documentaire doit également inclure des mesures de sauvegarde et de

récupération des documents en cas de panne du système informatisé ou de perte de données.

3.4.5.Évaluation du fournisseur

L'évaluation des fournisseurs constitue une activité cruciale pour assurer la conformité des
systèmes informatisés aux règlementations en vigueur et leur adéquation à l'usage prévu. Cette
évaluation doit être réalisée avant de sélectionner un fournisseur et pendant le cycle de vie du
système, s'inscrivant dans le cadre du processus de gestion des fournisseurs.

Cette évaluation doit reposer sur une approche fondée sur le risque, tenant compte des facteurs
tels que la criticité et la complexité du système ou du service proposé par le fournisseur, le
niveau d'implication et de supervision de l'entreprise règlementée, la maturité et la capacité du
système de gestion de la qualité du fournisseur, ses antécédents et sa réputation dans l'industrie,
ainsi que la disponibilité et la pertinence de sa documentation et des preuves fournies.

L'évaluation du fournisseur doit inclure une revue documentaire et un audit sur site, en fonction
du niveau de risque et de la nature du système ou du service. La revue documentaire vise à
vérifier que le fournisseur dispose de politiques, procédures et normes adéquates pour
développer, tester, fournir et entretenir le système ou le service. L'audit sur site permet d'évaluer
les pratiques et les performances réelles du fournisseur par rapport aux processus et attentes
documentés.

Un rapport d'évaluation du fournisseur doit être rédigé, résumant les résultats, conclusions et
recommandations pour la sélection ou la poursuite de la collaboration avec le fournisseur. Ce
rapport doit également identifier les écarts ou les risques à traiter ou à atténuer par l'entreprise
règlementée ou le fournisseur, et être examiné et approuvé par les parties prenantes concernées
au sein de l'entreprise règlementée.

L'évaluation des fournisseurs n'est pas une activité ponctuelle, mais un processus continu qui
doit être répété périodiquement ou lors de changements significatifs dans le système, le service,

50
le fournisseur ou les règlementations. La fréquence et la portée de l'évaluation des fournisseurs
doivent être déterminées par une approche basée sur le risque, tenant compte des facteurs
précédemment mentionnés. L'évaluation du fournisseur doit également s'aligner sur les
processus de gestion des changements et de la configuration de l'entreprise règlementée et du
fournisseur (25).

3.5. Phase d’exploitation

Une fois que le système a été accepté et mis en service, il est important de maintenir la
conformité et de s'assurer qu'il continue à répondre à l'objectif visé tout au long de sa durée de
vie opérationnelle. Pour ce faire, il est possible d'utiliser des procédures et des formations
établies pour l'utilisation, la maintenance et la gestion.

La phase opérationnelle d'un système peut durer de nombreuses années et peut impliquer des
modifications des services, des logiciels, du matériel, des processus opérationnels et des
exigences règlementaires. Il est essentiel de maintenir l'intégrité du système et de ses données
à tout moment et de procéder à des examens périodiques pour le vérifier. L'utilisation de
systèmes et d'outils de soutien pour numériser et automatiser les processus peut contribuer à
améliorer l'efficacité, la cohérence et le respect des processus.

Les processus suivants doivent être en place avant la mise en service du système et être
respectés tout au long de l'exploitation :

3.5.1.Gestion des changements

La gestion des changements est un élément essentiel de la phase d'exploitation d'un système
informatisé BPx.

L'objectif principal de la gestion des modifications est de contrôler et de documenter de

manière appropriée tout changement apporté au système informatisé, y compris les
modifications matérielles, logicielles et procédurales, afin de garantir la qualité et la conformité
règlementaire du système. Les étapes clés de la gestion des changements sont décrites à la
partie 3.4.2.

3.5.2.Maintenance et surveillance du système

La maintenance et la surveillance sont des éléments essentiels pour assurer la conformité, la

fiabilité et la performance d'un système informatisé BPx tout au long de la phase d'exploitation.

51
Elles comprennent diverses activités et procédures pour garantir le bon fonctionnement du
système et minimiser les risques de défaillance ou de perte de données. Ces activités de
maintenance et de surveillance sont des exigences règlementaires décrites notamment dans
l’annexe 11 des BPF, et doivent être décrites dans une ou des procédures.

a. Maintenance

La maintenance est une activité essentielle pour assurer la qualité, la sécurité et l'efficacité des
systèmes informatisés utilisés dans l'industrie pharmaceutique. Elle consiste à prévenir,
détecter et corriger les anomalies ou les défaillances qui pourraient affecter le fonctionnement
ou la performance des systèmes. La maintenance doit être planifiée, documentée et tracée
conformément aux exigences règlementaires et aux bonnes pratiques de fabrication (BPF). Elle
doit couvrir tous les aspects du cycle de vie des systèmes, de la conception à la mise hors
service, en passant par l'installation, la qualification, l'utilisation et le changement.

Dans le contexte de l'intervention d'un tiers dans la maintenance d'un système informatisé, par
exemple, lorsqu'une entreprise pharmaceutique fait appel à un tiers pour la fourniture,
l'installation, la configuration, l'intégration, la validation, la maintenance (par exemple via un
accès à distance), la modification ou la conservation d'un système informatisé ou de tout service
associé ou pour le traitement de données, un contrat formel doit être établi entre le fabricant et
les tiers. Ces contrats doivent inclure une déclaration claire des responsabilités du tiers. Les
services informatiques doivent être considérés de la même manière (8).

b. Sauvegarde et restauration des données

Des sauvegardes régulières des données pertinentes doivent être effectuées. L'intégrité et
l'exactitude des données sauvegardées, ainsi que la capacité à les restaurer, doivent être
vérifiées lors de la validation et contrôlées périodiquement. Si des modifications importantes
doivent être apportées au système (par exemple, un changement d'équipement informatique ou
de logiciel), la capacité à récupérer les données archivées doit être garantie et testée (8).

c. Surveillance des performances

La surveillance des performances du système permet de détecter les problèmes éventuels et

d'assurer la fiabilité et l'efficacité du système. Des outils de surveillance peuvent être utilisés
pour suivre les indicateurs de performance clés (KPI) tels que la disponibilité du système, la
capacité de stockage et les temps de réponse.

52
 d. Gestion des incidents

La gestion des incidents est un processus qui vise à assurer la conformité des systèmes
informatisés. La gestion des incidents vise à identifier, analyser, résoudre et documenter les
incidents qui affectent le fonctionnement ou la performance des systèmes informatisés. Les
incidents doivent être traités en fonction de leur criticité et de leur impact sur la qualité du
produit, la sécurité du patient ou la conformité règlementaire. Les incidents doivent être
communiqués aux parties prenantes concernées et faire l'objet d'une revue périodique pour
identifier les causes racines et les actions correctives ou préventives à mettre en œuvre (25).

e. Mises à jour et mises à niveau

Les mises à jour et les mises à niveau du matériel et des logiciels sont nécessaires pour
maintenir le système à jour et conforme aux exigences règlementaires et technologiques. Un
processus de gestion des mises à jour doit être mis en place pour évaluer, planifier et mettre en
œuvre les mises à jour nécessaires.

3.5.3.Revue périodique

Des revues périodiques sont nécessaires pour s'assurer qu'un système informatisé reste
conforme aux exigences règlementaires tout au long de sa vie opérationnelle, qu'il est adapté à
l'utilisation prévue et qu'il satisfait constamment aux politiques et procédures de l'entreprise.
La périodicité de ces revues dépend de l’impact et de la criticité du système et doit être définie
dans le plan de validation ou dans le rapport final de validation (8).

3.5.4.Archivage et récupération des données

Les données générées et stockées dans le système informatisé BPx doivent être archivées et
protégées conformément aux exigences règlementaires. Des procédures de récupération des
données doivent être en place pour permettre un accès rapide et fiable aux données en cas de
besoin (8).

3.5.5.Formation des utilisateurs

Les utilisateurs du système doivent recevoir une formation adéquate et actualisée afin de
garantir leur compétence dans l'utilisation du système conformément aux exigences
règlementaires et aux SOP. La formation doit être documentée et périodiquement réévaluée
(8).

53
4. Étude de cas : validation d’un CRM en cycle en V

4.1. Présentation du projet et des parties prenantes

Un laboratoire pharmaceutique international spécialisé dans la production et la distribution de

gaz médicinaux et d'analyse pour diverses utilisations médicales a mis en place un système de
gestion des réclamations qualité et des rappels de produits pour ses filiales française et
allemande en utilisant le CRM Salesforce. Cependant, ce système n'avait pas été reconnu
comme ayant un impact BPx et n'avait donc pas été validé conformément aux règlementations
pharmaceutiques (GMP Annex 11, 21 CFR Part 11).

L'objectif principal du projet était de valider le CRM Salesforce en raison de son impact BPx.
Les parties prenantes clés impliquées dans ce projet comprenaient le responsable du processus
métier (BPO), le chef de projet informatique de la solution CRM, le responsable de la validation
(dont le rôle était occupé par moi-même) et le responsable assurance qualité de la solution
CRM.

4.2. Déroulement du projet

4.2.1.Organisation du projet

Initialement, une évaluation des risques a été menée pour établir l'impact du système, examiner
la documentation existante, identifier les exigences règlementaires pertinentes et déterminer
l'ampleur des efforts de validation requis.

Les activités de validation ont ensuite été effectuées, incluant la planification de la validation,
l'analyse des risques fonctionnels, les qualifications d'installation, opérationnelle et de
performance, l'assurance de la traçabilité des activités et enfin la rédaction du rapport final de
validation.

4.2.2.Analyse de risque initiale

a. Confirmation de l’impact BPx

La société en question fabrique des gaz qui correspondent à la définition du médicament selon
l’article L. 5111-1 du CSP (32). De ce fait, elle est soumise aux Bonnes Pratiques de
Fabrication (BPF). Conformément au chapitre 8 de la partie I des BPF (33), le traitement,

54
l'évaluation, la revue des réclamations et des défauts qualité, les investigations menées et la
mise en œuvre des mesures de réduction du risque nécessitent des moyens suffisants et du
personnel qualifié.

Le CRM Salesforce est utilisé pour gérer les réclamations de cette société, y compris celles
ayant un impact sur la qualité. Cela en fait un système informatisé employé dans le cadre des
activités relevant des BPF et soumis à l'annexe 11 des BPF. Selon cette annexe, lorsqu'un
système informatisé remplace une opération manuelle, il ne doit pas entrainer une baisse de la
qualité du produit, de la maîtrise du processus ou de l'assurance qualité, ni une augmentation
du risque général lié au processus (8).

Ainsi, le CRM Salesforce est un système informatisé utilisé dans le cadre d'activités relevant
des Bonnes Pratiques de Fabrication et doit donc être validé.

b. Catégorisation du système

Le CRM Salesforce, employé pour gérer les réclamations client au sein de l'entreprise
concernée, est une solution logicielle basée sur le cloud et personnalisable. Puisque ce CRM
est configurable et permet à l'utilisateur d'adapter ses fonctionnalités à ses besoins spécifiques
sans modifier le code du logiciel, il a été classé dans la catégorie 4 du GAMP.

4.2.3.Planification de la validation

Conformément aux exigences règlementaires, un plan de validation a été réalisé afin de décrire
le système, présenter la stratégie et les critères d’acceptation de validation, définir les rôles et
responsabilités des parties prenantes du projet, lister les différents livrables de validation ainsi
que des processus support visant à assurer le maintien de l'état validé du système d'information.

a. Description du système
- Hébergement

Le CRM Salesforce est une plateforme basée sur le modèle SaaS (Software as a Service), où
les serveurs et applications sont administrés par le fournisseur Salesforce. Ce système intègre
une base de données centralisée pour toutes les filiales européennes de l'entreprise concernée.

55
 - Fonctionnalités

Le CRM Salesforce englobe les fonctionnalités suivantes :

o Contrôle des accès et des autorisations

o Suivi des évènements et des visites clients
o Administration des contacts clients
o Gestion des opportunités commerciales et des devis
o Traitement des requêtes clients (demandes simples et réclamations)
o Création de tableaux de bord analytiques et rapports de performance
- Environnements

La solution CRM Salesforce est déployée sur deux environnements distincts : préproduction et
production. L'environnement de préproduction sert au contrôle qualité et à la réalisation de
tests préalables au lancement du produit final. Il est essentiel que cet environnement soit en
adéquation étroite avec l'environnement de production en termes de paramètres pertinents. De
plus, toute modification apportée doit être dûment documentée via un système de contrôle des
changements informatiques. L'environnement de production, quant à lui, est destiné à l'usage
des utilisateurs finaux. Par conséquent, chaque changement doit être accompagné d'une
procédure de gestion des changements et soumis au contrôle des changements informatiques.
Les deux environnements sont hébergés sur les serveurs de Salesforce.

- Interfaces

Le CRM Salesforce est interconnecté avec plusieurs autres systèmes informatisés pour faciliter
l'échange de données et la gestion des processus métier. Ces interfaces incluent :

o SAP : Les fichiers numérisés des contrats provenant du système SAP Opera sont
transférés vers Salesforce, permettant ainsi une centralisation et un suivi efficace
des contrats.
o Portail client de l'entreprise : Les interactions des clients, telles que les demandes
d'information et les réclamations soumises via le portail client de l'entreprise, sont
automatiquement intégrées dans Salesforce. Ceci permet une gestion simplifiée et
un suivi cohérent des demandes clients.
o Boîte de réception générique de l'entreprise : Les requêtes et réclamations envoyées
à l'adresse e-mail générique de l'entreprise sont enregistrées directement dans
Salesforce. Cette intégration assure un traitement rapide et efficace des demandes
reçues par e-mail.

56
 b. Rôles et responsabilités
Dans le cadre du plan de validation du CRM Salesforce, les responsabilités et activités clés des
acteurs du projet ont été établies comme suit :

- Responsable du processus métier (BPO)

Chargé de rassembler les exigences métier, de coordonner les tests fonctionnels avec
les experts métier, de vérifier les livrables de validation et de maintenir le dossier de
validation centralisé.

- Chef de projet informatique (ITPM)

Responsable de la gestion des fournisseurs de développement et de système, de la
coordination des services informatiques, de la vérification des livrables de validation,
et de garantir la maintenance, la disponibilité et la sécurité du système.

- Responsable de la validation (SVM)

Chargé de définir la stratégie de validation, de coordonner les activités de validation du
système, de rédiger les livrables de validation et de superviser le processus
d'approbation desdits livrables.

- Responsable assurance qualité (QAPM)

Responsables de l'examen des livrables de validation, de l'assurance de la conformité
aux normes de qualité de l'entreprise et de l'approbation des livrables de validation.

c. Gestion du fournisseur
Dans le cadre de la validation du CRM Salesforce, une évaluation du fournisseur a été réalisée
afin de s'assurer de la conformité du fournisseur aux exigences règlementaires en vigueur.

Le CRM Salesforce, conçu par Salesforce Inc., est une solution standard largement adoptée
dans divers secteurs, y compris l'industrie pharmaceutique. Plusieurs filiales de l'entreprise
concernée emploient cette application.

Un audit de Salesforce Inc. a été mené avant le début du projet de validation de la solution
CRM Salesforce. Les conclusions de l'audit ont révélé que :

- Salesforce Inc. possède un plan de reprise d'activité (PRA) rigoureux pour ses services
et ses produits, garantissant une stratégie solide de continuité des activités. Le PRA est

57
 régulièrement réévalué et mis à jour pour assurer sa pertinence en cas d'interruption ou
de catastrophe.

- Des tests de pénétration et des évaluations de sécurité sont effectués périodiquement

par des experts tiers pour identifier et corriger les vulnérabilités du système.

- Salesforce Inc. détient des certifications conformes aux normes de sécurité de

l'information pertinentes, telles qu’ISO 27001, ISO 27017 et ISO 27018, démontrant
son engagement envers la confidentialité, l'intégrité et la disponibilité de ses systèmes
d'information.

- Les serveurs hébergeant les données de l'entreprise concernée sont situés dans l'Union
européenne et disposent d'une certification HDS ou Hébergeur de Données de Santé,
une accréditation spécifique reconnue dans l'Union européenne, et délivrée aux
fournisseurs de services d'hébergement qui stockent et gèrent des données de santé à
caractère personnel.

- Salesforce Inc. applique un processus de gestion de la qualité rigoureux et formalisé via

des procédures.

- Les employés de Salesforce Inc. travaillant sur la solution CRM Salesforce ont été
formés au 21 CFR part 11 et à la règlementation européenne en vigueur.

- De plus, un contrat incluant un accord de niveau de service (SLA) établi avec Salesforce
a été vérifié et respecte les exigences règlementaires en vigueur.

En conclusion, il a été déterminé que Salesforce présente un niveau de qualité acceptable pour
répondre aux besoins de l'entreprise concernée dans le cadre de l'utilisation du CRM Salesforce.

d. Stratégie de validation

La validation du système de gestion de la relation client (CRM) Salesforce a été réalisée en

suivant la méthodologie du cycle en V du GAMP 5.

Selon la classification du GAMP 5, Salesforce est considéré comme un logiciel de catégorie 4.

Étant donné que le système est déjà en production, une validation rétrospective a dû être
réalisée en prenant en compte de la documentation existante.

58
Ainsi les activités de validation attendues et les livrables associés pour le système Salesforce
CRM de catégorie 4 du GAMP déjà en production sont décrits dans la figure ci-après.

Rôles

Livrables SVM BPO ITPM QAPM

Plan de validation A C C R
Spécification des besoins
I A C R
utilisateurs et fonctionnelles
Analyse de risque fonctionnelle A C C R
Matrice de traçabilité A C I R
QI : Protocole et Rapport A I C R
QI : Exécution des tests C I A I
QO : Protocole et Rapport A C I R
QO : Exécution des tests C A I I
QP : Protocole et Rapport A C I R
QP : Exécution des tests C A I I
Rapport final de validation A C C R
Figure 12 Livrables de validation - rôles et responsabilités

R : Responsable A : Action C : Consultation (revue) I : Information

e. Documentation des spécifications utilisateur et fonctionnelles

Selon l’annexe 11 des BPF : ”Les spécifications utilisateurs (User Requirements Specifications
- URS) doivent décrire les fonctions requises du système informatisé et être basées sur une
évaluation documentée du risque et de l’impact BPF (8).”

Or, vu que Salesforce CRM n’avait pas été identifié comme un système ayant un impact BPF,
aucune URS n’a été rédigée lors de son lancement. Seuls des documents de lancement de projet
étaient disponibles.

Il a donc été demandé au client de rédiger un document comprenant les exigences utilisateurs
pour être conforme aux exigences règlementaires.

59
 f. Analyse des risques fonctionnels

Une évaluation des risques fonctionnels a été conduite conformément à la méthodologie

GAMP 5 pour le système Salesforce CRM.

Les fonctions du système ont été examinées afin d'identifier les conséquences et impacts
potentiels en cas de défaillance.

La criticité de chaque risque identifié a ensuite été évaluée, permettant ainsi de déterminer le
type de test à effectuer.

g. Phases de qualification

- Prérequis pour l’exécution des tests

Les prérequis pour que les tests de qualification puissent être exécutés étaient les suivants :

o Approbation des protocoles et des scripts de test

o Formation des testeurs à l’exécution des tests et au système.
o Disponibilité de l’environnement de préproduction
o Approbation du rapport de qualification de l’étape précédente sans non-conformités
bloquantes.
- Déroulement des tests

L'exécution d’un test ne pouvait commencer que si les conditions étaient remplies.

Un script de test pouvait nécessiter plusieurs exécutions si des non-conformités étaient

rencontrées.

Pendant l'exécution d’un test, les preuves du test étaient collectées et documentées.

- Environnement

L'exécution des tests de qualification a été réalisée en environnement de préproduction.

- Gestion des non-conformités

Lorsqu'une non-conformité était identifiée lors d'une étape de test, celle-ci était détaillée dans
le script de test.
Le responsable de la validation du système examinait alors le formulaire de script de test et
attribuait une criticité à la non-conformité :
o Mineure : lorsque la non-conformité n'affectait pas une fonction critique et/ou
n'avait pas d'incidence sur la qualité du produit, la sécurité du patient ou l'intégrité
des données.

60
 o Majeure : lorsque la non-conformité impliquait une fonction critique, mais le
système pouvait potentiellement être déployé dans un environnement de production
à condition qu'un processus de contournement ait été établi et que les utilisateurs
aient été formés en conséquence.
o Bloquante : lorsque la non-conformité concernait une fonction critique et un
correctif était impératif pour permettre l'installation du système dans
l'environnement de production.

Suite à l'examen et à l'analyse des non-conformités par le responsable de la validation du

système, la liste des éléments nécessitant un correctif était transmise au chef de projet
informatique. Une fois le correctif livré et installé par ce dernier, une nouvelle série de tests
était effectuée, se concentrant uniquement sur les étapes de test présentant des non-conformités.

- Conclusions et critères d’acceptation des étapes de qualification

Les activités de qualification ont été synthétisées dans des rapports de qualification.

Selon les résultats de test, les niveaux suivants ont été attribués aux étapes de qualification :

o Conforme (C) : Aucune non-conformité.

o Conforme avec action (CA) : Présence de non-conformités non bloquantes

(majeures ou mineures) nécessitant des actions correctives.

o Non-conforme (NC) : Présence de non-conformités bloquantes

Les critères d'acceptation pour chaque phase de qualification avant la progression à l'étape
ultérieure ont été établis comme suit :

o Achèvement de tous les tests des scripts de test.

o Complétion, vérification, datation et signature de tous les scripts de test.

o Datation, signature et vérification de toutes les preuves de test requises dans les
scripts.

o Traitement de tous les cas de non-conformité selon la méthode décrite dans le

protocole en vigueur.

o Résolution de toutes les non-conformités bloquantes.

o Établissement d'un plan d'action pour toutes les non-conformités non traitées.

61
 h. Processus de support

- Formation

Les testeurs ont été formés à Salesforce et à la méthodologie d'exécution des tests de validation.
Les preuves de la formation ont été archivées dans le dossier de validation.

- Gestion des changements

Les changements associés à cette validation ont été suivis, si nécessaire, par le biais des
processus internes de gestion des changements

- Gestion des documents

Les documents de validation ont été stockés dans la GED (Gestion Électronique des
Documents) de l’entreprise.

- Gestion des écarts de validation

Les non-conformités découvertes lors de cette validation ont été examinées par le Responsable
Validation Système (SVM) et des déviations ont été ouvertes si nécessaire, selon le processus
de gestion des déviations de chaque filiale.

4.2.4.Résultats de l’analyse des risques fonctionnelle

Conformément au plan de validation, une évaluation des risques fonctionnels a été effectuée
pour identifier les dangers associés au système informatisé BPx Salesforce CRM.

À la suite de cette évaluation, les risques de niveaux élevé et moyen ont été mis en évidence,
comme présentés dans la figure ci-après.

62
 Priorit
Domaine de
ID Évènement de risque ou danger é du
gestion
risque
Gestion de L'URL n'est pas sécurisée et n'est pas réservée aux
RA03 H
l'infrastructure IT utilisateurs
Gestion des accès RA11 Le système permet l'accès à un utilisateur non autorisé H
Le système ne requiert pas d'identifiant ni de mot de passe
Gestion des accès RA12 H
pour les utilisateurs non SSO (Single Sign-On)
Le système ne peut pas bloquer l'utilisateur après plusieurs
Gestion des accès RA16 H
tentatives d'accès erronées
Même si un compte utilisateur est bloqué par l'administrateur,
Gestion des accès RA17 H
l'utilisateur peut se connecter
Après une période d'inactivité, l'utilisateur n'est pas
Gestion des accès RA21 H
déconnecté
Lorsque l'utilisateur est déconnecté par le système après une
Gestion des accès RA22 période d'inactivité, aucun mot de passe n'est requis pour se H
reconnecter au système
Gestion de Les interfaces vers SAP, le portail client et EDP sont non
RA07 H
l'infrastructure IT fonctionnelles
Gestion des accès RA20 N'importe quel utilisateur peut réactiver son compte H
Gestion des accès RA09 L'utilisateur ne peut pas se connecter à son compte M
Examen des
Les données des demandes clients sont perdues ou
réclamations RA77 M
incomplètes
client
Gestion des accès RA14 Il est possible de se connecter avec un mauvais mot de passe M
Les demandes clients provenant de la boîte e-mail générique
Réception des
RA86 interfacée avec Salesforce et envoyées par un e-mail autorisé M
demandes client
ne sont pas automatiquement intégrées dans Salesforce
Réception des Les demandes clients provenant des portails clients ne sont
RA87 M
demandes client pas automatiquement intégrées dans Salesforce
Les données provenant des différents canaux (portail client,
Réception des
RA88 boîte e-mail générique) sont incomplètes ou modifiées dans M
demandes client
Salesforce
L'administrateur ne peut pas identifier un compte utilisateur
Gestion des accès RA19 M
bloqué
Gestion des accès RA24 N'importe quel utilisateur peut administrer les accès M
Gestion des droits
RA32 Mauvaise utilisation du système par l'utilisateur M
des utilisateurs
Gestion des droits Les droits des utilisateurs ne sont pas conformes aux rôles
RA33 M
des utilisateurs configurés dans le système
Figure 13 Liste des risques Low et Medium identifiés pour Salesforce CRM

Des mesures de maîtrise des risques ont été établies pour atténuer ces menaces identifiées et
sont décrites en détail à l’annexe A.

63
 4.2.5.Résultats des phases de qualification

Une matrice de traçabilité mettant en lumière les besoins, les risques associés et les tests a été
réalisée. Un résumé de celle-ci pour les risques moyen et élevé est schématisé à l’annexe B.

a. Résultats de qualification d’installation

Des tests de qualification d’installation ont été réalisés conformément au plan de validation et
à partir des résultats l’analyse de risque.

Étant donné que Salesforce CRM est un système SaaS hébergé sur les serveurs de Salesforce
Inc. et accessible via une connexion internet, la QI s'est focalisée sur les aspects suivants :

- Vérification du processus de sauvegarde et de restauration des données

- Vérification de la disponibilité du système

- Vérification du plan de continuité des activités

- Vérification de la sécurité du site web

- Vérification de la configuration du système

- Vérification de la gestion des accès

- Vérification des environnements

Suite à l'exécution des tests de qualification d’installation, une seule non-conformité a été
révélée : le plan de continuité des activités n’avait pas été approuvé.

L'objectif d'un plan de continuité des activités est de garantir que les fonctions essentielles
opérées par le système puissent être poursuit par les équipes métier pendant et après un sinistre.
Il s'agit notamment de protéger les données critiques de l'entreprise contre les catastrophes en
planifiant à l'avance et en identifiant les effets résultant de la perturbation des fonctions et des
processus de l'entreprise.

Cette non-conformité a été définie de criticité majeure, car il s’agissait d’une déviation par
rapport à plusieurs exigences règlementaires :

- En effet, selon l'annexe 11 des BPF : « Les dispositions nécessaires doivent être prises
afin d'assurer le bon fonctionnement des procédés critiques abrités par des systèmes
informatisés ayant subi une panne (8). »
- De plus, selon les BPF chapitre 4 : « Les documents contenant des instructions doivent
être approuvés, signés et datés par les personnes appropriées et autorisées (33).»

64
Un plan d’action a donc été défini comme suit pour corriger cette non-conformité :
« Approuver le plan de continuité des activités. »

Après correction de cette non-conformité, la qualification d'installation a pu être approuvée et

la qualification opérationnelle a pu être initiée.

b. Résultats de qualification opérationnelle

Des tests de qualification opérationnelle ont été réalisés conformément au plan de validation et
à partir des résultats de l'analyse de risque.

Les tests suivants ont été réalisés au cours de cette qualification opérationnelle :

- Vérification de la gestion des demandes clients

- Vérification du suivi des activités réalisées dans Salesforce
- Vérification de l'attachement des documents dans Salesforce
- Vérification du rapport
- Vérification de la gestion des utilisateurs
- Vérification de la gestion des accès

Aucune non-conformité n’a été révélée lors des tests. La phase de qualification opérationnelle
a donc pu être approuvée et la qualification de performance a pu être initiée.

c. Résultats de qualification performance

Des tests de qualification de performance ont été réalisés conformément au plan de validation
et à partir des résultats de l'analyse de risque.

Les tests suivants ont été réalisés au cours de cette qualification de performance :

- Vérification des interfaces

- Vérification de l'envoi d'e-mails aux clients
- Vérification de la gestion des utilisateurs
- Vérification de la gestion des accès
- Vérification du processus de gestion du changement

Aucune non-conformité n’a été révélée lors des tests. La phase de qualification de performance
a donc pu être approuvée.

65
 4.3. Résultats de la validation et leçons apprises

4.3.1.Conclusion du rapport final

Après avoir rigoureusement suivi le plan de validation et effectué les tests nécessaires, un seul
écart a été identifié, et l'action corrective associée a été mise en œuvre et clôturée avec succès.
Par conséquent, nous avons considéré que le système était validé et apte à être utilisé en
conformité avec les règlementations et normes en vigueur.

4.3.2.Leçons apprises

Au cours de ce projet de validation de Salesforce CRM, nous avons rencontré plusieurs

difficultés. Tout d'abord, il y avait une difficulté d'impliquer les équipes dans la validation en
raison d'une incompréhension du rôle et du processus de validation. Cela a nécessité une
communication claire et une formation adéquate pour expliquer l'importance et les objectifs de
la validation.

Ensuite, nous avons été confrontés à un manque de ressources et d'expertise technique pour la
réalisation des tests. Cela a entraîné des retards et des erreurs dans la mise en œuvre du système.
Enfin, il y avait un manque de communication entre les différentes équipes impliquées, ce qui
a parfois ralenti le projet.

Les leçons apprises de ces difficultés sont les suivantes :

- Sensibiliser et former les équipes sur l'importance et les objectifs de la validation pour
les impliquer activement dans le processus.

- Investir dans la formation et le développement des compétences internes pour renforcer

l'expertise technique et assurer la réalisation efficace des tests.

- Mettre en place des canaux de communication clairs et réguliers entre les équipes pour
faciliter la coordination et éviter les malentendus.

66
5. Conclusion

Cette thèse a exploré les défis et enjeux inhérents à la validation des systèmes informatisés
dans l'industrie pharmaceutique, en se concentrant sur l'étude de cas d'un CRM. L'analyse
approfondie des différentes phases de qualification et de validation a souligné l'importance
cruciale d'une approche méthodique et rigoureuse pour garantir la conformité aux normes et
règlementations du secteur pharmaceutique, ainsi que pour assurer la qualité des processus et
des données.

Dans le contexte de la transformation numérique et de l'évolution rapide des technologies, les

défis liés à la validation des systèmes informatisés sont appelés à se complexifier. Il est donc
essentiel pour les acteurs de l'industrie pharmaceutique de développer et maintenir une
expertise approfondie en matière de validation, afin de répondre efficacement à ces défis.

En conclusion, il convient de souligner plusieurs points clés qui émergent de cette thèse et qui
pourraient constituer des axes d'innovation pour l'avenir de la validation des systèmes
informatisés dans l'industrie pharmaceutique.

L'importance de la formation et de la sensibilisation des équipes impliquées dans la validation

des systèmes informatisés ne saurait être sous-estimée. Des programmes de formation adaptés
et continus permettront de renforcer l'expertise technique et la compréhension des enjeux
règlementaires, favorisant ainsi une mise en œuvre plus efficace et efficiente des processus de
validation.

La collaboration et la communication entre les différentes parties prenantes sont essentielles

pour assurer le succès des projets de validation. Il est important de promouvoir des canaux de
communication clairs et réguliers entre les équipes, ainsi que de développer des partenariats
stratégiques entre les entreprises pharmaceutiques, les fournisseurs de systèmes informatisés et
les organismes de règlementation.

Enfin, l’'intégration des nouvelles technologies et des approches innovantes dans les processus
de validation offre des opportunités considérables pour améliorer l'efficacité et la robustesse
des systèmes informatisés. Il est crucial d'explorer les synergies possibles entre les approches
de validation des systèmes informatisés et les initiatives d'amélioration continue de la qualité,
ainsi que d'évaluer l'impact des technologies émergentes telles que l'intelligence artificielle,
l'Internet des objets et la blockchain. Ces avancées pourraient permettre de créer des méthodes

67
de validation plus rapides, fiables et sécurisées, et ainsi contribuer à l'amélioration de la qualité
des produits pharmaceutiques et des services associés.

En somme, cette thèse a mis en lumière les défis et enjeux de la validation des systèmes
informatisés dans l'industrie pharmaceutique, ainsi que les opportunités offertes par les
nouvelles technologies et les bonnes pratiques. Pour relever ces défis et maximiser les bénéfices
de l'innovation technologique, les acteurs de l'industrie pharmaceutique doivent investir dans
la formation, la collaboration et l'adoption d'approches novatrices. Les efforts concertés en ce
sens permettront non seulement de garantir la conformité aux normes et règlementations, mais
aussi d'optimiser les processus de validation et, in fine, d'améliorer la qualité et la sécurité des
produits pharmaceutiques pour le bien-être des patients.

68
 Annexes

Annexe A : Analyse de risque fonctionnelle

Priorité
Exigence & ID du
Description du risque du Contrôle du risque
Fonctionnalité risque
risque
Gestion de L’URL n’est pas sécurisée et n’est pas réservée Vérifier si le processus en cas de piratage du
RA03 H
l'infrastructure IT aux utilisateurs système est détaillé dans une procédure
Gestion de L’URL n’est pas sécurisée et n’est pas réservée
RA03 H Vérifier si le site Web est en HTTPS
l'infrastructure IT aux utilisateurs
Vérifier que les utilisateurs non SSO ont besoin
L’URL n’est pas sécurisée et n’est pas réservée
Gestion des accès RA03 H d'un identifiant et d'un mot de passe pour se
aux utilisateurs
connecter à Salesforce
Vérifier dans la procédure de gestion des accès
Gestion de L’URL n’est pas sécurisée et n’est pas réservée que l'accès à Salesforce est limité aux
RA03 H
l'infrastructure IT aux utilisateurs utilisateurs actifs et aux utilisateurs autorisés
par un administrateur
Vérifier que les utilisateurs non SSO ont besoin
Le système permet l'accès à un utilisateur non
Gestion des accès RA11 H d'un identifiant et d'un mot de passe pour se
autorisé
connecter à Salesforce
Le système permet l'accès à un utilisateur non Vérifier qu'une procédure décrivant la gestion
Gestion des accès RA11 H
autorisé des accès est disponible
Le système permet l'accès à un utilisateur non Vérifier qu'un utilisateur bloqué ne peut pas
Gestion des accès RA11 H
autorisé accéder à la plateforme
Le système ne requiert pas d'identifiant ni de Vérifier que les utilisateurs non SSO ont besoin
Gestion des accès RA12 mot de passe pour les utilisateurs non SSO H d'un identifiant et d'un mot de passe pour se
(Single Sign-On) connecter à Salesforce
Le système ne requiert pas d'identifiant ni de
Vérifier qu'une procédure décrivant la gestion
Gestion des accès RA12 mot de passe pour les utilisateurs non SSO H
des accès est disponible
(Single Sign-On)
Le système ne peut pas bloquer l'utilisateur
Gestion des accès RA16 H Vérifier le réglage des tentatives de connexion
après plusieurs tentatives d'accès erronées
Le système ne peut pas bloquer l'utilisateur Vérifier que l'utilisateur est bloqué après le
Gestion des accès RA16 H
après plusieurs tentatives d'accès erronées nombre configurable de tentatives de connexion
Même si un compte utilisateur est bloqué par Vérifier qu'un utilisateur bloqué ne peut pas
Gestion des accès RA17 H
l'administrateur, l'utilisateur peut se connecter accéder à la plateforme
Après une période d'inactivité, l'utilisateur n'est Vérifier qu'après une période d'inactivité, le
Gestion des accès RA21 H
pas déconnecté système déconnecte l'utilisateur
Après une période d'inactivité, l'utilisateur n'est Vérifier le réglage de la déconnexion
Gestion des accès RA21 H
pas déconnecté automatique après une période d'inactivité
Lorsque l'utilisateur est déconnecté par le Vérifier que lorsque l'utilisateur est déconnecté
système après une période d'inactivité, aucun par le système après une période d'inactivité,
Gestion des accès RA22 H
mot de passe n'est requis pour se reconnecter au l'authentification est requise pour se connecter
système au système
Gestion de Les interfaces vers SAP, le portail client et EDP Vérifier les documents de configuration
RA07 H
l'infrastructure IT sont non fonctionnelles d'interface
Gestion de Les interfaces vers SAP, le portail client et EDP Vérifier que l'interface avec le portail client est
RA07 H
l'infrastructure IT sont non fonctionnelles fonctionnelle
Gestion de Les interfaces vers SAP, le portail client et EDP Vérifier que l'interface avec la boîte mail
RA07 H
l'infrastructure IT sont non fonctionnelles générique est fonctionnelle
Vérifier que seul un administrateur peut gérer
N'importe quel utilisateur peut réactiver son
Gestion des accès RA20 H les utilisateurs (création, attribution des
compte
permissions, gel et dégel d'un utilisateur)
N'importe quel utilisateur peut réactiver son
Gestion des accès RA20 H Vérifier la matrice des rôles et responsabilités
compte
L'utilisateur ne peut pas se connecter à son Vérifier que la restauration d'un utilisateur est
Gestion des accès RA09 M
compte décrite dans une procédure
Examen des
Les données des demandes clients sont perdues Vérifier que la restauration des demandes est
réclamations RA77 M
ou incomplètes décrite dans une procédure
client

69
 Priorité
Exigence & ID du
Description du risque du Contrôle du risque
Fonctionnalité risque
risque
Vérifier que les utilisateurs non SSO ont besoin
Il est possible de se connecter avec un mauvais
Gestion des accès RA14 M d'un identifiant et d'un mot de passe corrects
mot de passe
pour se connecter à Salesforce
Les demandes clients provenant de la boîte e-
Réception des mail générique interfacée avec Salesforce et Vérifier que l'interface avec la boîte e-mail
RA86 M
demandes client envoyées par un e-mail autorisé ne sont pas générique est fonctionnelle
automatiquement intégrées dans Salesforce
Les demandes clients provenant des portails
Réception des Vérifier que l'interface avec le portail client est
RA87 clients ne sont pas automatiquement intégrées M
demandes client fonctionnelle
dans Salesforce
Les données provenant des différents canaux
Réception des Vérifier que l'interface avec le portail client est
RA88 (portail client, boîte e-mail générique) sont M
demandes client fonctionnelle
incomplètes ou modifiées dans Salesforce
Les données provenant des différents canaux
Réception des Vérifier que l'interface avec la boîte e-mail
RA88 (portail client, boîte e-mail générique) sont M
demandes client générique est fonctionnelle
incomplètes ou modifiées dans Salesforce
L'administrateur ne peut pas identifier un Vérifier qu'un administrateur a la possibilité de
Gestion des accès RA19 M
compte utilisateur bloqué voir quels utilisateurs sont gelés et dégelés
Vérifier que seul un administrateur peut gérer
N'importe quel utilisateur peut administrer les
Gestion des accès RA24 M les utilisateurs (création, attribution des droits,
accès
gel et dégel d'un utilisateur)
Gestion des droits Vérifier que les utilisateurs de Salesforce ont
RA32 Mauvaise utilisation du système par l'utilisateur M
des utilisateurs été formés
Vérifier que seul un administrateur peut gérer
Gestion des droits
RA32 Mauvaise utilisation du système par l'utilisateur M les utilisateurs (création, attribution des droits,
des utilisateurs
gel et dégel d'un utilisateur)
Gestion des droits Les droits des utilisateurs ne sont pas conformes Vérifier la matrice des rôles et des
RA33 M
des utilisateurs aux rôles configurés dans le système responsabilités
Gestion des droits Les droits des utilisateurs ne sont pas conformes Vérifier que la revue des utilisateurs est décrite
RA33 M
des utilisateurs aux rôles configurés dans le système dans une procédure

70
 Annexe B : Matrice de traçabilité

Priorité Phase
Exigence & ID du
Description du risque du Contrôle du risque de Description du test
Fonctionnalité risque
risque test
Gestion de Vérifier que le processus en cas de
Après une période d'inactivité, Vérification du plan de
l'infrastructure RA03 H piratage du système est détaillé dans QI
l'utilisateur n'est pas déconnecté continuité des activités
IT une procédure
Gestion de
L’URL n’est pas sécurisée et Vérification de la sécurité
l'infrastructure RA03 H Vérifier que le site web est HTTPS QI
n’est pas réservée aux utilisateurs du site web
IT
Vérifier que les utilisateurs non SSO
Gestion de
L’URL n’est pas sécurisée et ont besoin d'un login et d'un mot de Vérification de la gestion
l'infrastructure RA03 H QO
n’est pas réservée aux utilisateurs passe corrects pour se connecter à des accès
IT
Salesforce CRM
Vérifier dans la procédure de gestion
des accès que l'accès à Salesforce est
Gestion de
L’URL n’est pas sécurisée et limité aux utilisateurs actifs de Vérification de la gestion
l'infrastructure RA03 H QP
n’est pas réservée aux utilisateurs l’entreprise et aux utilisateurs des accès
IT
externes autorisés par un
administrateur
Gestion de Les interfaces vers SAP, le portail
Vérifier les documents de Vérification de la
l'infrastructure RA07 client et EDP sont non H QI
configuration de l'interface configuration du système
IT fonctionnelles
Gestion de Les interfaces vers SAP, le portail
Vérifier que l'interface avec le portail
l'infrastructure RA07 client et EDP sont non H QP Vérification des interfaces
client est fonctionnelle
IT fonctionnelles
Gestion de Les interfaces vers SAP, le portail Vérifier que l'interface avec la boîte
l'infrastructure RA07 client et EDP sont non H aux lettres électronique générique est QP Vérification des interfaces
IT fonctionnelles fonctionnelle
Vérifier que la restauration d'un Vérification du processus de
Gestion des L'utilisateur ne peut pas se
RA09 M utilisateur est décrite dans une QI sauvegarde et de
accès connecter à son compte
procédure restauration des données
Vérifier que les utilisateurs non SSO
Gestion des Le système permet l'accès à un ont besoin d'un login et d'un mot de Vérification de la gestion
RA11 H QO
accès utilisateur non autorisé passe corrects pour se connecter à des accès
Salesforce
Gestion des Le système permet l'accès à un Vérifier qu'une procédure décrivant Vérification de la gestion
RA11 H QP
accès utilisateur non autorisé la gestion des accès est disponible des accès
Gestion des Le système permet l'accès à un Vérifier qu'un utilisateur bloqué ne Vérification de la gestion
RA11 H QO
accès utilisateur non autorisé peut pas accéder à la plateforme des accès
Le système ne requiert pas Vérifier que les utilisateurs non SSO
Gestion des d'identifiant ni de mot de passe ont besoin d'un login et d'un mot de Vérification de la gestion
RA12 H QO
accès pour les utilisateurs non SSO passe corrects pour se connecter à des accès
(Single Sign-On) Salesforce CRM
Le système ne requiert pas
Gestion des d'identifiant ni de mot de passe Vérifier qu'une procédure décrivant Vérification de la gestion
RA12 H QP
accès pour les utilisateurs non SSO la gestion des accès est disponible des accès
(Single Sign-On)
Vérifier que les utilisateurs non SSO
Gestion des Il est possible de se connecter ont besoin d'un login et d'un mot de Vérification de la gestion
RA14 M QO
accès avec un mauvais mot de passe passe corrects pour se connecter à des accès
Salesforce CRM
Le système ne peut pas bloquer
Gestion des Vérifier le nombre de tentatives de Vérification de la gestion
RA16 l'utilisateur après plusieurs H QI
accès connexion des accès
tentatives d'accès erronées
Le système ne peut pas bloquer Vérifier que l'utilisateur est bloqué
Gestion des Vérification de la gestion
RA16 l'utilisateur après plusieurs H après le nombre configurable de QO
accès des accès
tentatives d'accès erronées tentatives de connexion
Même si un compte utilisateur est
Gestion des Vérifier qu'un utilisateur bloqué ne Vérification de la gestion
RA17 bloqué par l'administrateur, H QO
accès peut pas accéder à Salesforce CRM des accès
l'utilisateur peut se connecter

71
 L'administrateur ne peut pas Vérifier qu'un administrateur a la
Gestion des Vérification de la gestion
RA19 identifier un compte utilisateur M possibilité de voir quels utilisateurs QO
accès des utilisateurs
bloqué sont bloqués et débloqués
Vérifier que seul un administrateur
peut gérer les utilisateurs (création
Gestion des N'importe quel utilisateur peut Vérification de la gestion
RA20 H d'utilisateurs, attribution de QO
accès réactiver son compte des utilisateurs
permissions, blocage et déblocage
d'un utilisateur)
Gestion des N'importe quel utilisateur peut Vérifier la matrice des rôles et des Vérification de la gestion
RA20 H QP
accès réactiver son compte responsabilités des utilisateurs
Vérifiez que le système déconnecte
Gestion des Après une période d'inactivité, Vérification de la gestion
RA21 H l'utilisateur après une période QO
accès l'utilisateur n'est pas déconnecté des accès
d'inactivité
Vérifier la configuration de la
Gestion des Après une période d'inactivité, Vérification de la gestion
RA21 H déconnexion automatique après une QI
accès l'utilisateur n'est pas déconnecté des accès
période d'inactivité
Lorsque l'utilisateur est Vérifier que lorsque l'utilisateur est
déconnecté par le système après déconnecté par le système après une
Gestion des Vérification de la gestion
RA22 une période d'inactivité, aucun H période d'inactivité, l'authentification QO
accès des accès
mot de passe n'est requis pour se est requise pour se connecter au
reconnecter au système système
Vérifier que seul un administrateur
peut gérer les utilisateurs (création
Gestion des N'importe quel utilisateur peut Vérification de la gestion
RA24 M d'utilisateurs, attribution de QO
accès administrer les accès des utilisateurs
permissions, blocage et déblocage
d'un utilisateur)
Gestion des
Mauvaise utilisation du système Vérifier que les utilisateurs de Vérification de la gestion
droits des RA32 M QP
par l'utilisateur Salesforce CRM ont été formés des utilisateurs
utilisateurs
Vérifier que seul un administrateur
Gestion des peut gérer les utilisateurs (création
Mauvaise utilisation du système Vérification de la gestion
droits des RA32 M d'utilisateurs, attribution de QO
par l'utilisateur des utilisateurs
utilisateurs permissions, blocage et déblocage
d'un utilisateur)
Gestion des Les droits des utilisateurs ne sont
Vérifier la matrice des rôles et des Vérification de la gestion
droits des RA33 pas conformes aux rôles M QP
responsabilités des utilisateurs
utilisateurs configurés dans le système
Gestion des Les droits des utilisateurs ne sont Vérifier que la revue des comptes
Vérification de la gestion
droits des RA33 pas conformes aux rôles M utilisateur est décrite dans une QP
des utilisateurs
utilisateurs configurés dans le système procédure
Examen des Les données des demandes Vérifier que la restauration des Vérification du processus de
réclamations RA77 clients sont perdues ou M demandes clients est décrite dans une QI sauvegarde et de
client incomplètes procédure restauration des données
Les demandes clients provenant
de la boîte e-mail générique
Réception des Vérifier que l'interface avec la boîte
interfacée avec Salesforce et
demandes RA86 M aux lettres électronique générique est QP Vérification des interfaces
envoyées par un e-mail autorisé
client fonctionnelle
ne sont pas automatiquement
intégrées dans Salesforce
Les demandes clients provenant
Réception des
des portails clients ne sont pas Vérifier que l'interface avec le portail
demandes RA87 M QP Vérification des interfaces
automatiquement intégrées dans client est fonctionnelle
client
Salesforce
Les données provenant des
Réception des différents canaux (portail client,
Vérifier que l'interface avec le portail
demandes RA88 boîte e-mail générique) sont M QP Vérification des interfaces
client est fonctionnelle
client incomplètes ou modifiées dans
Salesforce
Les données provenant des
Réception des différents canaux (portail client, Vérifier que l'interface avec la boîte
demandes RA88 boîte e-mail générique) sont M aux lettres électronique générique est QP Vérification des interfaces
client incomplètes ou modifiées dans fonctionnelle
Salesforce

72
 Références bibliographiques

1. Vioxx : Merck est condamné à verser 253 millions de dollars à une veuve [Internet]. [cité 26
avr 2023]. Disponible sur: https://www.lemonde.fr/economie/article/2005/08/20/vioxx-
merck-condamne-a-verser-253-millions-de-dollars-a-une-veuve_681452_3234.html

2. Horton R. Vioxx, the implosion of Merck, and aftershocks at the FDA. The Lancet. déc
2004;364(9450):1995‑6.

3. Prakash S, Valentine V. Timeline: The Rise and Fall of Vioxx. NPR [Internet]. 10 nov 2007
[cité 26 avr 2023] ; Disponible sur: https://www.npr.org/2007/11/10/5470430/timeline-the-
rise-and-fall-of-vioxx

4. Scandale de la Dépakine : la justice déboute le groupe pharmaceutique Sanofi [Internet].

[cité 26 avr 2023]. Disponible sur:
https://www.lemonde.fr/sante/article/2021/05/20/scandale-de-la-depakine-la-justice-
deboute-le-groupe-pharmaceutique-sanofi_6080844_1651302.html

5. Scandale de la Dépakine : l’Agence du médicament mise en examen pour « homicides

involontaires » [Internet]. [cité 19 janv 2023]. Disponible sur:
https://www.lemonde.fr/societe/article/2020/11/09/scandale-de-la-depakine-l-agence-du-
medicament-mise-en-examen-pour-homicides-involontaires_6059144_3224.html

6. Dépakine : la responsabilité de Sanofi reconnue par la justice. Le Monde.fr [Internet]. 6 janv

2022 [cité 26 avr 2023]; Disponible sur: https://www.lemonde.fr/police-
justice/article/2022/01/06/depakine-la-responsabilite-de-sanofi-reconnue-par-la-
justice_6108362_1653578.html

7. Produits médicaux de qualité inférieure ou falsifiés [Internet]. [cité 26 avr 2023]. Disponible
sur: https://www.who.int/fr/news-room/fact-sheets/detail/substandard-and-falsified-
medical-products

8. 2004 - The Rules Governing Medicinal Products in the Euro.pdf [Internet]. [cité 1 avr 2023].
Disponible sur: https://health.ec.europa.eu/system/files/2016-11/annex11_01-
2011_en_0.pdf

9. Affairs O of R. Glossary of Computer System Software Development Terminology (8/95).

FDA [Internet]. 17 juin 2019 [cité 1 avr 2023] ; Disponible sur:
https://www.fda.gov/inspections-compliance-enforcement-and-criminal-
investigations/inspection-guides/glossary-computer-system-software-development-
terminology-895

10.Research C for DE and. Electronic Common Technical Document (eCTD). FDA [Internet].
22 mars 2023 [cité 7 avr 2023] ; Disponible sur: https://www.fda.gov/drugs/electronic-
regulatory-submission-and-review/electronic-common-technical-document-ectd

11.Whitman J. Electronic signatures in the pharmaceutical industry – wider issues dominate

over the technical and practical? Rec Manag J. 1 janv 2000;10(1):35‑48.

12.Num F. La signature électronique : un outil devenu incontournable [Internet].

francenum.gouv.fr. Direction générale des entreprises ; [cité 28 avr 2023]. Disponible sur:

73
 https://www.francenum.gouv.fr/guides-et-conseils/pilotage-de-
lentreprise/dematerialisation-des-documents/la-signature

13.Sabe VT, Ntombela T, Jhamba LA, Maguire GEM, Govender T, Naicker T, et al. Current
trends in computer aided drug design and a highlight of drugs discovered via computational
techniques: A review. Eur J Med Chem. nov 2021;224:113705.

14.Yu W, MacKerell AD. Computer-Aided Drug Design Methods. Methods Mol Biol Clifton NJ.
2017;1520:85‑106.

15.Aldewachi H, Al-Zidan RN, Conner MT, Salman MM. High-Throughput Screening

Platforms in the Discovery of Novel Drugs for Neurodegenerative Diseases. Bioeng Basel
Switz. 23 févr 2021;8(2):30.

16.Chakraborty S, Mallick I, Bhattacharyya T, Moses A, Achari RB, Chatterjee S. State of use

of Electronic Data Capture (EDC) tools in randomized controlled trials in India. Health Policy
Technol. 1 sept 2022 ;11(3):100662.

17.Arica E, Powell DJ. Status and future of manufacturing execution systems. In: 2017 IEEE
International Conference on Industrial Engineering and Engineering Management (IEEM)
[Internet]. Singapore: IEEE; 2017 [cité 1 avr 2023]. p. 2000‑4. Disponible sur:
http://ieeexplore.ieee.org/document/8290242/

18.Wei X, Ling N, Ren MM, Fan SH. The Design of Function and Flow for Warehouse
Management System in Pharmaceutical Enterprises -- The Case of NATON. In: 2015
International Conference on Computer Science and Applications (CSA) [Internet]. Wuhan,
China: IEEE; 2015 [cité 1 avr 2023]. p. 264‑7. Disponible sur:
http://ieeexplore.ieee.org/document/7810877/

19.Solanki M, Brewster C. EPCIS Event-Based Traceability in Pharmaceutical Supply Chains

via Automated Generation of Linked Pedigrees. In: Mika P, Tudorache T, Bernstein A, Welty
C, Knoblock C, Vrandečić D, et al., éditeurs. The Semantic Web – ISWC 2014. Cham:
Springer International Publishing; 2014. p. 82‑97. (Lecture Notes in Computer Science).

20.Singh S, Singh S, Misra SC. Post-implementation challenges of ERP system in

pharmaceutical companies. Int J Qual Reliab Manag. 23 mars 2023;40(4):889‑921.

21.Potdar M, Sharif A, Potdar V, Chang E. Applications of Wireless Sensor Networks in

Pharmaceutical Industry. In: 2009 International Conference on Advanced Information
Networking and Applications Workshops [Internet]. Bradford, United Kingdom: IEEE; 2009
[cité 1 avr 2023]. p. 642‑7. Disponible sur: http://ieeexplore.ieee.org/document/5136721/

22.Rodionova OYe, Sokovikov YaV, Pomerantsev AL. Quality control of packed raw materials
in pharmaceutical industry. Anal Chim Acta. mai 2009 ;642(1‑2):222‑7.

23.Ferry JC. Gérer la complexité des SI [Internet]. enioka. 2011 [cité 28 avr 2023]. Disponible
sur: https://blog.enioka.com/2011/01/03/gerer-la-complexite-des-systemes-dinformation/

24.21 CFR Part 11 -- Electronic Records; Electronic Signatures [Internet]. [cité 28 avr 2023].
Disponible sur: https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11

25.ISPE. GAMP® 5: A Risk-Based Approach to Compliant GxP Computerized Systems

(Second Edition). 2022.

26.ICH Official web site : ICH [Internet]. [cité 28 avr 2023]. Disponible sur: https://www.ich.org/

74
27.ICH Official web site : ICH [Internet]. [cité 28 avr 2023]. Disponible sur:
https://www.ich.org/page/ich-guidelines

28.14:00-17:00. ISO 9001:2015 [Internet]. ISO. 2021 [cité 29 avr 2023]. Disponible sur:
https://www.iso.org/fr/standard/62085.html

29.annexe_15-fr-def.pdf [Internet]. [cité 1 mai 2023]. Disponible sur:

https://www.afmps.be/sites/default/files/content/INSP/annexe_15-fr-def.pdf

30.Fowler et Highsmith - Facilitating change is more effective than attempt.pdf [Internet]. [cité
3 avr 2023]. Disponible sur: http://www.hristov.com/andrey/fht-
stuttgart/The_Agile_Manifesto_SDMagazine.pdf

31.What is Scrum? [Internet]. Scrum.org. [cité 3 avr 2023]. Disponible sur:

https://www.scrum.org/learning-series/what-is-scrum

32.Article L5111-1 - Code de la santé publique - Légifrance [Internet]. [cité 2 mai 2023].
Disponible sur: https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000006689867/

33.Bonnes pratiques de fabrication de médicaments à usage humain - ANSM [Internet]. [cité

19 janv 2023]. Disponible sur: https://ansm.sante.fr/documents/reference/bonnes-
pratiques-de-fabrication-de-medicaments-a-usage-humain

75
RESUME :

Le présent travail explore les défis et enjeux de la validation des systèmes informatisés dans
l'industrie pharmaceutique, en s'appuyant sur une étude de cas portant sur la validation d'un
système de gestion des relations client (Customer Relationship Management, CRM).

L'objectif principal de ce travail est d'analyser les processus de validation, les règlementations
en vigueur et les meilleures pratiques afin de mieux comprendre les aspects critiques de la
validation des systèmes informatisés. Pour atteindre cet objectif, l'étude de cas utilise une
approche de gestion de projet spécifique à la validation de système informatisé : la méthode du
cycle en V.

Les résultats présentés de la thèse montrent que le processus de validation a été mené avec
succès, avec un seul écart identifié et résolu. Les connaissances apprises au cours de ce projet
mettent en évidence l'importance de la communication claire entre les différentes équipes
impliquées, de la formation adéquate et du développement des compétences techniques pour
assurer une validation efficace et conforme aux règlementations.

DISCIPLINE :

Pharmacie - Filière Industrie

MOTS-CLEFS :

Validation, Systèmes informatisés, Industrie pharmaceutique, CRM (Customer Relationship

Management), Bonnes Pratiques de Fabrication, Annexe 11, 21 CFR Part 11, GAMP 5

ADRESSE DE L’AUTEUR :

antoine.seri@gmail.com

76