Validation des systèmes informatiques (CSV) vs. Assurance des systèmes informatiques (CSA) : quelles sont les principales différences ?

Si vous travaillez dans l’industrie pharmaceutique ou des dispositifs médicaux, vous avez probablement entendu les termes CSV et CSA circuler fréquemment ces derniers temps. Et si vous avez déjà essayé de les rechercher, vous avez peut‑être eu l’impression de vous heurter à des murs de langage réglementaire plus déroutants qu’utiles. 

Décomposons donc cela en termes simples : ce que signifient réellement ces deux approches, en quoi elles diffèrent et pourquoi cela importe pour votre organisation.

Qu’est‑ce que la validation des systèmes informatiques (CSV) ?

Validation des systèmes informatiques, ou CSV, est l’approche standard dans les secteurs réglementés depuis des décennies. Au cœur, la CSV est un processus documenté qui garantit qu’un système informatique fait exactement ce pour quoi il a été conçu, de façon cohérente et répétée. L’objectif est d’assurer l’intégrité des données, la qualité du produit et la conformité aux réglementations GxP applicables.

La FDA a publié pour la première fois sa ligne directrice sur la CSV en 2003, parallèlement à la célèbre réglementation 21 CFR Part 11, qui régit les enregistrements électroniques et les signatures électroniques. Depuis lors, la CSV est devenue le cadre de référence pour les entreprises pharmaceutiques, les organisations de recherche clinique et les fabricants de dispositifs médicaux lors de la mise en place ou de la mise à niveau d’un système informatisé.

Les quatre questions qui guident le processus CSV

Dans une approche CSV, le processus de validation suit un cycle de vie structuré. Avant le début de tout test, une équipe doit répondre à quatre questions fondamentales : 

• Qu’est‑ce qui sera validé ? 
• Quels sont les critères d’acceptation ? 
• Comment cela sera‑t‑il validé ? 
• Et qui effectuera la validation ? 

Ces questions orientent l’ensemble de la stratégie documentaire et aident à définir le périmètre du travail.

Les trois documents de spécification clés

La validation elle‑même s’appuie sur trois documents de spécification principaux. Le Cahier des charges utilisateur (URS) décrit ce que le système doit faire du point de vue de l’utilisateur ; par exemple, un système de laboratoire pourrait devoir suivre les dossiers de formation des analystes, affecter automatiquement des tâches et se conformer à 21 CFR Part 11. 

Le Spécification fonctionnelle (FS) décrit comment le système répondra à ces besoins utilisateurs, y compris la conception de l’interface et le traitement des données. La Spécification de conception (DS) approfondit l’architecture technique, la conception de la base de données, les mesures de sécurité, les exigences réseau et les configurations d’interface.

Comment fonctionnent les tests : IQ, OQ et PQ

Une fois ces documents en place, les tests suivent le modèle en V classique (également appelé approche linéaire).Installation Qualification (IQ) vérifie que le système a été installé correctement conformément aux spécifications de conception. Qualification opérationnelle (OQ) vérifie que le système fonctionne comme décrit dans la spécification fonctionnelle. Et Qualification de performance (PQ) confirme que le système fonctionne conformément aux exigences utilisateurs dans des conditions réelles. En bref, chaque spécification a un test correspondant, ce qui entraîne un volume important de documentation.

Les forces et les critiques de la CSV

Cette nature très documentée de la CSV a toujours été à la fois sa force et sa principale critique. Oui, elle est rigoureuse. Oui, elle crée une trace documentaire solide. Mais elle est aussi chronophage, coûteuse, et conduit parfois les organisations à produire des montagnes de papiers qui apportent peu de valeur réelle à la sécurité des patients ou à la qualité du produit.

Qu’est‑ce que l’assurance des logiciels informatiques (CSA) ?

C’est là qu’intervient Assurance des logiciels informatiques (CSA) . La FDA a introduit la CSA via un document d’orientation provisoire intitulé "Assurance des logiciels informatiques pour les logiciels de production et de système qualité," publié le 13 septembre 2022. L’idée directrice derrière la CSA est simple : au lieu de valider tout avec le même niveau de rigueur indépendamment du risque, concentrez vos efforts là où ils comptent le plus.

La CSA est une approche fondée sur le risque qui vise à établir et maintenir la confiance que le logiciel est adapté à son usage prévu. Plutôt que de produire une documentation exhaustive pour chaque fonctionnalité système, la CSA invite les équipes à réfléchir de manière critique à ce qui pourrait mal tourner et à la gravité des conséquences. Plus le risque pour la sécurité des patients ou la qualité du produit est élevé, plus les tests doivent être rigoureux. Pour les fonctionnalités logicielles à moindre risque, une documentation réduite et des méthodes de test plus simples sont parfaitement acceptables.

Étape 1 : Identifier l’usage prévu

Le processus CSA commence par l’identification de l’usage prévu du logiciel. La FDA distingue les logiciels utilisés directement dans le cadre de la production ou d’un système qualité, tels que les outils qui automatisent les processus de fabrication ou collectent des données qualité, et les logiciels utilisés pour soutenir ces systèmes, tels que les outils de test ou les applications de tenue de dossiers générales. Les logiciels utilisés pour des fonctions commerciales générales, comme le courrier électronique ou la comptabilité, sont entièrement hors de portée.

Étape 2 : Évaluer le risque

Une fois l’usage prévu clarifié, l’étape suivante consiste à évaluer le risque. Une fonctionnalité logicielle est considérée comme à haut risque lorsque sa défaillance pourrait entraîner un problème de qualité compromettant la sécurité des patients.

Par exemple, un logiciel qui maintient des paramètres de procédé critiques tels que la température ou la pression, ou un logiciel qui analyse l’acceptabilité du produit sans revue humaine supplémentaire, relèverait généralement de la catégorie à haut risque. En revanche, les logiciels utilisés pour le routage des CAPA, le suivi des plaintes ou la gestion du changement sont généralement considérés comme non à haut risque.

Étape 3 : Déterminer le type de test approprié

Le niveau de risque détermine ensuite le type de tests requis. Les fonctionnalités à haut risque nécessitent des tests scriptés rigoureux, structurés, documentés et traçables aux exigences. Les fonctionnalités à risque moyen peuvent utiliser des tests scriptés limités, qui sont un hybride de méthodes structurées et flexibles.

Pour les fonctionnalités à faible risque, des méthodes de test non scriptées telles que les tests exploratoires, les tests ad hoc ou la conjecture d’erreurs sont parfaitement adéquates. Le testeur utilise ses connaissances et son jugement pour explorer le système sans besoin de scripts de test formels.

Étape 4 : Conserver les bons enregistrements

Des enregistrements doivent toujours être conservés dans le cadre de la CSA, mais ils sont plus concis et mieux ciblés. Un enregistrement CSA doit consigner l’usage prévu de la fonctionnalité logicielle, le niveau de risque déterminé, une description des tests effectués, les problèmes identifiés et la manière dont ils ont été résolus, une conclusion quant à l’acceptabilité des résultats, la date des tests et le nom de la personne qui les a réalisés.

CSV vs. CSA : les principales différences

CSV et CSA existent tous deux pour garantir que les systèmes informatisés dans les industries réglementées sont fiables, conformes et adaptés à l’usage. Les deux impliquent la planification, les tests, la documentation et le reporting. Et tous deux s’appliquent aux systèmes qui influent sur la sécurité des patients, la qualité des produits et l’intégrité des données. Mais les similitudes commencent à s’estomper lorsque l’on examine les philosophies sous-jacentes à chaque approche.

CSV : axé sur la conformité par nature

Le CSV est fondamentalement axé sur la conformité. Il valide qu’un système répond à un ensemble prédéfini de spécifications, et il le fait avec la même exhaustivité pour toutes les fonctionnalités du système. Le fardeau documentaire est important, et le processus est en grande partie identique que vous testiez un système d’acquisition de données critique pour la mission ou une simple fonctionnalité de gestion documentaire.

CSA : axé sur l’assurance par conception

La CSA, par contraste, est axée sur l’assurance. Elle demande aux équipes de réfléchir de manière critique au risque et d’appliquer l’effort de test proportionnellement à ce qui est réellement en jeu. Elle remplace la mentalité « taille unique » du CSV par une approche ciblée, flexible et plus intelligente. On passe moins de temps à rédiger des scripts de test pour les fonctionnalités à faible risque et plus de temps à fournir une assurance significative pour les domaines qui pourraient réellement nuire aux patients ou compromettre la qualité du produit.

Ce que la CSA signifie en pratique

D’un point de vue pratique, la CSA réduit les délais de création, de révision et d’approbation des tests. Elle diminue le nombre de documents générés. Elle permet aux organisations de tirer parti des preuves de test fournies par les fournisseurs plutôt que de répéter le même travail de validation. Et elle soutient les entreprises qui se dirigent vers l’automatisation et les pratiques de développement agile, où les modèles de validation rigides et linéaires créent souvent des goulots d’étranglement.

La CSA remplace-t-elle le CSV ?

Une distinction importante à noter :La CSA n’élimine pas le besoin de CSV.Elle redéfinit plutôt la manière dont la validation est réalisée. Certains systèmes fortement réglementés peuvent encore bénéficier de la structure complète que fournit le CSV. Le choix de l’approche à utiliser, ou de la combinaison des deux, dépend de la nature du logiciel, du niveau de risque impliqué et des obligations réglementaires de l’organisation.

Passer du CSV à la CSA

Pour les organisations qui fonctionnent en CSV depuis des années, la transition vers la CSA peut sembler être un grand changement culturel. Et à bien des égards, c’en est un. La transition exige que les équipes cessent de considérer la validation comme un exercice documentaire et commencent à l’envisager comme un exercice de gestion des risques.

Concrètement, la transition implique d’évaluer les pratiques de validation actuelles pour identifier les domaines où la documentation peut être réduite sans compromettre la conformité. Elle signifie former les équipes qualité et IT aux principes de la CSA et à la pensée basée sur le risque.

Elle suppose d’apprendre à tirer parti plus efficacement de la documentation des fournisseurs et des données de qualification des fournisseurs, plutôt que de dupliquer les efforts de validation en interne. Et elle implique d’adopter des outils et des technologies pouvant automatiser certaines parties du processus d’assurance.

La transition n’a pas besoin d’avoir lieu du jour au lendemain. De nombreuses organisations choisissent d’appliquer les principes CSA aux nouvelles mises en œuvre de systèmes tout en conservant leur approche CSV existante pour les systèmes hérités. Cette stratégie par étapes permet aux équipes d’acquérir de l’expérience et de la confiance avec la nouvelle approche sans perturber les opérations en cours.

Pourquoi cela compte pour votre organisation

Le passage du CSV au CSA reflète un changement plus large dans l’approche de la FDA en matière de qualité. Plutôt que d’assimiler la conformité à de la paperasserie, la FDA encourage une culture où la qualité est intégrée aux processus, où les décisions reposent sur une réflexion fondée sur le risque, et où les efforts de validation se concentrent là où ils créent une réelle valeur.

Pour les entreprises pharmaceutiques et de dispositifs médicaux, c’est finalement une bonne chose. Cela signifie moins de temps passé dans des scripts de test et plus de temps consacré à construire des systèmes véritablement sûrs, fiables et efficaces. Cela se traduit par des délais de mise en œuvre plus courts, une utilisation plus efficiente des ressources et des pratiques de validation qui évoluent réellement avec la complexité des logiciels modernes.

Que vous soyez encore pleinement engagé dans le CSV, que vous exploriez activement le CSA ou que vous soyez quelque part entre les deux, comprendre la différence entre ces deux approches est la première étape pour prendre des décisions plus intelligentes sur la manière dont votre organisation gère et valide les systèmes informatisés.

FAQ

Q1. Quelle est la principale différence entre le CSV et le CSA en pharma ?

Le CSV (Computer System Validation) est une approche axée sur la documentation et la conformité qui valide toutes les fonctionnalités du système avec une rigueur égale. Le CSA (Computer Software Assurance) est une approche basée sur le risque introduite par la FDA qui concentre les efforts de test sur les zones ayant le plus d’impact sur la sécurité des patients et la qualité du produit, réduisant la documentation inutile pour les fonctionnalités à faible risque.

Q2. Le CSA remplace-t-il le CSV dans l’industrie pharmaceutique ?

Le CSA ne remplace pas entièrement le CSV. Il redéfinit plutôt la manière dont la validation est effectuée. La FDA a introduit le CSA pour rendre le processus de validation plus efficace et axé sur le risque. Les organisations peuvent toujours utiliser le CSV pour les systèmes fortement réglementés ou complexes tout en appliquant les principes CSA à d’autres logiciels pour lesquels une approche plus légère est appropriée.

Q3. Quelles réglementations régissent le CSV et le CSA dans les sciences de la vie ?

Le CSV est principalement régi par la FDA 21 CFR Part 11 et les directives GxP, ainsi que par GAMP 5, qui catégorise les systèmes informatisés par risque. Le CSA est guidé par le projet d’orientation de la FDA de 2022 intitulé « Computer Software Assurance for Production and Quality System Software », qui présente un cadre d’assurance basé sur le risque.

Q4. Quels types de tests sont utilisés dans le CSA ?

Le CSA utilise deux principaux types de tests en fonction du niveau de risque. Pour les fonctionnalités logicielles à haut risque, des tests scriptés robustes avec une documentation formelle sont requis. Pour les fonctionnalités à risque faible à moyen, des méthodes de test non scriptées telles que les tests exploratoires, les tests ad hoc et le 'error-guessing' sont acceptables, réduisant la nécessité de scripts de test formels et d’une documentation étendue.

Q5. Comment une entreprise pharmaceutique passe-t-elle du CSV au CSA ?

La transition du CSV au CSA consiste à appliquer une réflexion basée sur le risque aux processus de validation existants, à réduire les tests scriptés pour les fonctionnalités système à faible risque, à tirer parti des preuves de qualification fournies par les fournisseurs et à former les équipes qualité et informatique aux principes du CSA. La plupart des organisations adoptent une approche par phases, en commençant par les nouvelles mises en œuvre de systèmes avant de revoir les systèmes hérités.