ALCOA+ : le fil conducteur de l’intégrité des données
L’intégrité des données cliniques repose sur les principes ALCOA+. Ils permettent d’évaluer si une donnée est compréhensible, fiable, traçable et exploitable tout au long de son cycle de vie.
Principes ALCOA+
| Principe |
Signification |
| Attributable |
La donnée peut être reliée à son auteur ou à son origine. |
| Legible |
La donnée est lisible et compréhensible. |
| Contemporaneous |
La donnée est enregistrée au moment de l'action. |
| Original |
La donnée source ou son équivalent maîtrisé est préservé. |
| Accurate |
La donnée est exacte et fidèle à ce qui a été observé. |
| Complete |
La donnée est complète. |
| Consistent |
La donnée reste cohérente dans le temps et entre systèmes. |
| Enduring |
La donnée reste disponible durablement. |
| Available |
La donnée est accessible en cas de besoin, notamment en audit ou inspection. |
Dans un environnement numérique, ces principes se traduisent par des exigences concrètes : comptes utilisateurs individuels, journal d’audit, horodatage, contrôle des accès, gestion des versions, sauvegardes, exports lisibles et documentation des changements.
Quels référentiels encadrent la validation ?
La validation des systèmes informatisés s’inscrit dans plusieurs cadres réglementaires et méthodologiques. Leur application dépend du type d’étude, des pays concernés, des données collectées et de l’usage réglementaire prévu.
ICH E6(R3), GCP et approche proportionnée au risque
Les bonnes pratiques cliniques imposent une maîtrise des systèmes, des données, des accès et de la documentation associée. ICH E6(R3) renforce cette logique avec une approche qualité par conception, proportionnée au risque.
L’idée est simple : l’effort de validation doit être adapté à la criticité du système. Un outil qui impacte la sécurité des participants, l’intégrité des critères principaux ou la fiabilité des résultats attend un niveau de contrôle plus élevé qu’un outil annexe de reporting interne.
Des référentiels comme GAMP 5 peuvent aider à structurer cette approche, notamment pour calibrer l’effort de validation selon l’usage prévu, le niveau de risque et la complexité du système.
La guideline européenne sur les systèmes informatisés
Adoptée en 2023, la guideline européenne Guideline on computerised systems and electronic data in clinical trials précise les attentes relatives aux systèmes informatisés et aux données électroniques dans les essais cliniques.
Elle couvre notamment la validation, le cycle de vie du système, la gestion des utilisateurs, les rôles et permissions, le journal d’audit, la sécurité, les sauvegardes, la restauration, l’archivage, la gestion des changements et la disponibilité de la documentation en inspection.
Ses principes sont particulièrement structurants pour les essais de médicaments. Ils restent aussi utiles comme référence pour cadrer les systèmes informatisés dans d’autres contextes cliniques, selon les exigences applicables.
Un point mérite d’être souligné : le recours à un fournisseur ou à une solution cloud ne transfère pas la responsabilité du promoteur. Le sponsor doit rester capable de démontrer que le système est adapté à l’usage prévu de l’étude et que les données restent maîtrisées.
Le 21 CFR Part 11 côté FDA
Aux États-Unis, le 21 CFR Part 11 s’applique aux enregistrements électroniques et signatures électroniques utilisés pour répondre à des exigences FDA applicables. Il devient donc central pour les essais soumis à la FDA ou susceptibles d’alimenter un dossier réglementaire américain.
Le texte encadre notamment la validation du système, les contrôles d’accès, le journal d’audit, la protection des enregistrements électroniques, les copies exploitables des données et le lien entre signature électronique et enregistrement signé.
La FDA a aussi finalisé en 2024 une guidance dédiée aux systèmes électroniques, enregistrements électroniques et signatures électroniques dans les investigations cliniques. Elle précise ses attentes sur la fiabilité, l’intégrité et l’équivalence des enregistrements électroniques avec les documents papier lorsque les exigences applicables sont respectées.
Une convergence entre Europe et FDA
Les textes européens et américains ne sont pas identiques, mais ils reposent sur des logiques proches : usage prévu, approche basée sur les risques, intégrité des données, traçabilité, sécurité des accès et maîtrise du cycle de vie du système.
Pour un essai international, il est donc préférable de concevoir l’environnement numérique de manière cohérente dès le départ, plutôt que de traiter chaque référentiel de façon isolée.
Comment valider un système informatisé ?
Une démarche de validation suit généralement une logique progressive. Elle doit rester proportionnée au risque, mais certains blocs reviennent presque toujours.
Les grandes étapes consistent à :
- définir l’usage prévu du système ;
- identifier les exigences utilisateurs, ou URS ;
- réaliser une analyse de risques ;
- évaluer et qualifier le fournisseur ;
- définir le plan de validation ;
- tester le système et sa configuration ;
- documenter les résultats ;
- gérer les anomalies ;
- approuver le rapport de validation ;
- maîtriser les changements ;
- maintenir l’état validé dans le temps.
Trois notions reviennent souvent dans ce processus :
Qualification IQ OQ PQ
| Étape |
Objectif |
IQ
Installation Qualification |
Vérifier que le système est correctement installé ou mis à disposition. |
OQ
Operational Qualification |
Vérifier que les fonctionnalités clés fonctionnent comme prévu. |
PQ
Performance Qualification |
Vérifier que le système répond à l'usage prévu dans les conditions réelles d'utilisation. |
Dans un environnement SaaS, une partie de la documentation peut être fournie par le prestataire. Cela ne suffit pas toujours à couvrir l’usage spécifique de l’étude. La configuration propre au protocole, aux rôles, aux workflows, aux formulaires et aux données attendues doit aussi être maîtrisée.
Sponsor, CRO, fournisseur : qui est responsable ?
L’utilisation d’un fournisseur SaaS ne transfère pas l’intégralité de la responsabilité au prestataire.
Le fournisseur peut proposer une plateforme validée, des procédures qualité, une documentation technique, des rapports de tests, une gestion contrôlée des versions et un support aux audits. Mais le promoteur reste responsable de démontrer que le système est adapté à l’usage prévu de son étude.
La répartition des responsabilités doit être claire entre sponsor, CRO et fournisseur. Elle doit être documentée dans les contrats, les procédures, les plans de validation et les plans de supervision fournisseur.
En pratique, cette supervision doit couvrir les responsabilités de chaque partie, les livrables de validation disponibles, la configuration spécifique de l’étude, les accès utilisateurs, la formation, la gestion des changements et les modalités d’export ou d’archivage.
Le maintien de l’état validé est aussi important que la validation initiale. Une mise à jour, un changement de configuration ou l’ajout d’un module peut modifier le niveau de risque et nécessiter une évaluation documentée.
Les erreurs les plus fréquentes
Certaines erreurs reviennent souvent dans les projets de validation.
La première consiste à considérer qu’un outil SaaS est automatiquement couvert parce qu’il est commercialisé pour les essais cliniques. La deuxième consiste à confondre la documentation fournisseur avec la validation de l’usage réel par le sponsor.
D’autres erreurs sont plus opérationnelles :
- utiliser des comptes partagés au lieu de comptes individuels ;
- ne pas documenter les tests réalisés ;
- négliger la configuration spécifique de l’étude ;
- ne pas contrôler rigoureusement les droits d’accès ;
- ne pas revoir le journal d’audit lorsque cela est nécessaire ;
- ne pas anticiper les exports ou l’archivage ;
- ne pas maîtriser les prestataires cloud impliqués ;
- ne pas évaluer l’impact des mises à jour ;
- maintenir des procédures déconnectées de l’usage réel du système.
Ces écarts ne sont pas toujours visibles au lancement. Ils apparaissent souvent au moment d’un audit, d’une inspection, d’un gel de base ou d’un export final.
Ce qu’une plateforme eClinical doit faciliter
Une plateforme eClinical pensée pour les essais cliniques doit faciliter les fondamentaux : comptes utilisateurs individuels, rôles et permissions, journal d’audit, gestion des versions, exports exploitables, documentation qualité, archivage et gestion contrôlée des changements.
Lorsque le contexte l’exige, elle doit aussi permettre de gérer les signatures électroniques dans un cadre maîtrisé.
L’intérêt n’est pas de promettre qu’un outil rend l’étude “conforme” à lui seul. L’enjeu est de fournir un environnement sécurisé, validé, traçable et documenté, qui aide les sponsors et CRO à démontrer la maîtrise de leurs systèmes selon l’usage prévu.
La validation des systèmes informatisés est une condition structurante des essais cliniques digitalisés. Elle permet de démontrer que les outils utilisés sont adaptés à leur usage prévu, maîtrisés dans le temps et capables de préserver l’intégrité des données.
L’enjeu n’est pas seulement technique. Il concerne la qualité des données, la protection des participants, la responsabilité du promoteur et la capacité à répondre à un audit ou une inspection.
Une bonne démarche de validation repose sur une approche proportionnée au risque, une documentation claire, une supervision fournisseur maîtrisée et un maintien continu de l’état validé.
