Validation des LIMS et CDS : risques, tests et mise en service

Le fournisseur remet un dossier de tests complet, mais le laboratoire a modifié le circuit d’approbation et connecté un nouvel instrument. Quelles preuves restent valables ? Il faut comparer usage prévu, configuration réelle et couverture des tests. La validation des LIMS et CDS doit soutenir une décision documentée sur l’adéquation du système du laboratoire à son usage.

1. Délimiter le système et les décisions soutenues

Partez du processus : réception de l’échantillon, acquisition, traitement, transfert, revue, approbation et conservation. Identifiez enregistrements et métadonnées, utilisateurs, instruments, interfaces et services nécessaires. La distinction entre LIMS, CDS, ELN et SDMS aide à répartir les responsabilités sans laisser d’étape sans contrôle.

Enregistrez versions et configurations, modules, règles locales et dépendances d’infrastructure. Définissez les responsables du processus, de la maintenance du système, du support technique et de l’approbation des preuves selon le système qualité. La validation logicielle ne remplace ni la qualification de l’instrument ni la validation de la méthode analytique : ces activités sont liées, avec des objets et preuves différents.

Évaluez l’applicabilité réglementaire selon produits, activités, enregistrements et marchés. L’Annex 11 concerne les systèmes informatisés utilisés dans des activités GMP ; les exigences américaines applicables ne découlent pas de la seule présence d’un ordinateur. La guidance FDA CSA finale de février 2026 vise les logiciels de production et du système de management de la qualité des dispositifs médicaux : elle n’abolit pas la CSV pharmaceutique et n’étend pas automatiquement son champ à chaque LIMS.

2. Relier exigences, risques et preuves du fournisseur

Rédigez des exigences vérifiables : résultat ou comportement requis, conditions et critère d’acceptation. Évaluez les conséquences de résultats incorrects, données incomplètes, approbations non autorisées ou enregistrements irrécupérables. La priorité découle du risque pour le produit, le patient et l’intégrité des données, non du nombre d’écrans.

Examinez compétences et système qualité du fournisseur, documentation disponible, versions testées, environnement, couverture et défauts connus. Pour réutiliser un test, indiquez l’exigence couverte, la fiabilité des preuves et l’influence possible des configurations ou dépendances locales. Un certificat générique ou une déclaration de conformité ne démontre pas le flux particulier du laboratoire.

Documentez ce qui peut être accepté, complété ou doit être vérifié localement. Il n’est pas nécessaire de répéter sans raison chaque test fiable ; reprendre un résultat au seul motif qu’une fonction porte le même nom n’est pas davantage justifié. Configurations, code personnalisé, interfaces et contrôles opérationnels peuvent nécessiter des vérifications différentes.

3. Construire une matrice menant à la décision

Cette matrice originale est un exemple à adapter au périmètre. Chaque test possède données et critères prédéfinis ; comparez le résultat réel à l’attendu, conservez les preuves et traitez les écarts. Les activités se déroulent dans des environnements autorisés avec des données de test identifiables.

Ne testez pas seulement le parcours favorable. Éprouvez erreurs, interruptions et combinaisons plausibles pouvant produire une mauvaise décision. Pour les interfaces, la vérification doit couvrir le sens des données chez le destinataire : la correspondance et réconciliation instruments–LIMS fait l’objet d’un article dédié.

4. Traiter les déviations et autoriser la mise en service

Documentez les tests exécutés avec exigence, version, environnement, données, exécutant, résultat et référence aux preuves. Le nombre de captures d’écran ne mesure pas la couverture. Le comportement vérifié et sa contribution à l’acceptation doivent pouvoir être reconstitués ; l’adéquation des outils de test et de l’environnement doit également être évaluée.

Un échec aux critères ne devient pas acceptable en supprimant le test ou en modifiant rétrospectivement l’attendu sans justification. Documentez déviation, cause évaluée, impact, correction et vérifications suivantes. Reliez un nouveau test favorable à l’échec initial sans l’effacer.

Avant la mise en service, examinez couverture des exigences, déviations et risques résiduels, configuration finale, procédures, formation, support, accès et récupération. La fonction autorisée précise périmètre approuvé, restrictions éventuelles et responsabilités. L’autorisation conditionnelle de passer à une étape suivante ne permet pas automatiquement l’usage courant d’une fonction critique non démontrée.

5. Cas simulé : le flux personnalisé modifie la couverture

Le dossier fournisseur démontre qu’un réviseur peut approuver un résultat complet dans le flux standard. Le laboratoire ajoute une importation instrumentale et un état « en attente de vérification ». Lors d’un test local, un message incomplet laisse l’unité vide mais permet le passage à l’état approuvé.

Le test standard reste utile pour ce qu’il démontre ; il ne couvre pas cette combinaison. L’équipe enregistre la déviation, vérifie les règles du nouvel état et l’interface, corrige le comportement et teste les messages complets, incomplets et répétés avec les rôles prévus. Elle vérifie aussi la reconstitution des événements, de la version et des décisions. La mise en service dépend du résultat documenté, non du volume du dossier fournisseur.

En exploitation, les changements de configuration, versions, interfaces, rôles et usage prévu nécessitent analyse d’impact et contrôles pertinents. La revue périodique considère aussi incidents, performances, sécurité et récupérabilité. Fréquence et profondeur doivent être justifiées : la validation initiale ne maintient pas seule l’état validé.

6. Sources et applicabilité

Sources vérifiées le 2 octobre 2026. Contexte GMP des médicaments à usage humain ; matrice et scénario originaux, sans tests sur des systèmes de production.

• Commission européenne — GMP Annex 11, révision 1, janvier 2011, applicable depuis le 30 juin 2011, principe et §§1–4, 7, 9–14 : validation, fournisseurs, tests et état de maîtrise.
• Commission européenne — GMP Annex 15, révision de mars 2015, applicable depuis le 1 octobre 2015, principe et §§1–2 : planification, preuves externes, déviations et autorisations ; renvoi à l’Annex 11 pour les systèmes informatisés.
• FDA — Data Integrity and Compliance With Drug CGMP, version finale de décembre 2018, Q2–Q3 : contrôles proportionnés et fonctions validées pour l’usage pertinent ; recommandations non contraignantes.
• FDA — Computer Software Assurance for Production and Quality Management System Software, version finale du 3 février 2026, sections I et III : dispositifs médicaux et 21 CFR Part 820 ; remplace la version de septembre 2025, non les exigences GMP des médicaments.