Choisir un CDS : exigences, architecture et preuves au laboratoire

Le CDS est souvent choisi selon les instruments compatibles et la présentation du rapport. Les difficultés apparaissent ensuite : une séquence interrompue est mal gérée, un réviseur ne voit pas l’historique du traitement ou un second site dépend d’une connexion non évaluée. La sélection doit examiner tout le parcours, du signal à la décision.

1. Décrire le travail que le CDS doit soutenir

Définir instruments, modèles, modules, méthodes, techniques, utilisateurs, sites et charge attendue. Distinguer les instruments installés des extensions futures et préciser celles qui sont confirmées. Indiquer qui acquiert, traite, révise et approuve, quels résultats soutiennent des décisions BPF et quelles activités restent dans d’autres systèmes.

La compatibilité annoncée avec une famille instrumentale ne démontre pas celle de la combinaison réelle de modèle, module, version et fonction. Demander des preuves relatives à la configuration proposée : pilotage, acquisition des canaux nécessaires, gestion des séquences et comportement en cas d’erreur. Éviter les seuils universels de capacité ; définir une charge représentative du laboratoire et son critère d’évaluation.

Utiliser la cartographie des LIMS, ELN, CDS et SDMS pour préciser les frontières. Le CDS ne doit pas devenir implicitement responsable du cycle de l’échantillon ou de l’archive lorsque ces fonctions sont attribuées ailleurs.

2. Séparer acquisition, traitement et revue

Représenter les objets et responsabilités du flux : demande analytique, séquence, injection, signal original, méthode de traitement, résultat, revue et approbation. Vérifier les modules et licences nécessaires à chaque étape. Un poste qui affiche un rapport ne permet pas forcément de revoir le jeu de données et ses pistes d’audit.

Les contrôles doivent identifier utilisateurs et versions des méthodes, préserver les traitements pertinents et expliquer pourquoi un résultat a changé. Examiner séparation des rôles, droits, signification de l’approbation et lien avec l’enregistrement approuvé. Une mention « conforme à Part 11 » ne remplace pas l’évaluation de l’usage, de la configuration et des procédures du laboratoire.

Demander la démonstration d’un événement complet : modification autorisée, motif, nouvelle version, comparaison avec la précédente et revue ultérieure. Un bouton de piste d’audit est insuffisant si le réviseur ne peut relier les événements au résultat examiné.

3. Comparer architectures et dépendances

Décrire où se déroulent pilotage instrumental, acquisition, stockage, traitement et revue. Une architecture locale, centralisée ou distribuée peut convenir selon le contexte ; aucune n’est automatiquement conforme ou préférable. Identifier serveurs, postes, réseau, gestion des identités, services partagés et connexions aux LIMS ou SDMS.

Pour chaque dépendance, évaluer les conséquences de son indisponibilité : l’acquisition continue-t-elle ou s’arrête-t-elle ? Où restent les données ? Comment l’interruption est-elle signalée et le retour du service rapproché ? Démontrer les réponses sur la configuration proposée, sans supposer que tout CDS dispose d’une collecte locale indépendante.

La continuité concerne aussi les personnes : qui intervient, qui évalue l’impact analytique et qui autorise la remise en service. Prévoir les essais de panne dans des environnements isolés et autorisés. Une démonstration commerciale ne justifie pas d’interrompre des systèmes de production.

4. Utiliser une matrice exigence–risque–preuve

Comparer les offres avec les mêmes scénarios et jeux de données synthétiques. Convenir préalablement des conditions initiales, du résultat attendu et du critère d’acceptation. Enregistrer version, configuration, résultat et limites de la démonstration. Distinguer fonction existante, configuration nécessaire, personnalisation proposée et promesse future.

Cette matrice est un exemple opérationnel original, pas un cahier des charges validé. Une exigence essentielle non démontrée reste ouverte : une bonne note moyenne ne compense pas la perte de données originales. Pondérations et critères de choix doivent être justifiés par le laboratoire, sans classement universel.

5. Cas simulé et décision sur le cycle de vie

Deux sites CQ comparent une solution avec postes locaux et une autre avec services centralisés. Les deux démontrent acquisition et rapports courants. La première exige une gouvernance cohérente de plusieurs configurations ; la seconde introduit une dépendance réseau entre sites. Il ne s’agit pas d’avantages ou de défauts absolus : les essais et responsabilités changent.

L’équipe CQ–AQ–IT ajoute une séquence interrompue, une revue depuis l’autre site et la récupération d’un jeu historique. Si l’offre centralisée ne démontre pas son comportement lors d’une perte de connexion, ce point reste ouvert. Si l’offre locale ne démontre pas la distribution maîtrisée des méthodes, cet autre point reste ouvert. Le cas ne désigne aucun vainqueur et n’invente aucun coût : le choix suit les preuves et les exigences non négociables.

Avant de s’engager, examiner la faisabilité de la validation, la documentation, la formation, l’assistance, les mises à jour, la compatibilité future et l’export en fin de contrat. Préciser qui conservera formats natifs, relations et dépendances de lecture : la présence des fichiers ne prouve pas une restitution exploitable.

La démonstration aide à sélectionner ; elle ne remplace pas la validation du système installé pour l’usage prévu. Transmettre au projet exigences approuvées, preuves évaluées, risques résiduels et conditions à lever avant la mise en service. Maintenir la traçabilité des changements ultérieurs de configuration et de périmètre.

6. Références et limites

Sources vérifiées le 1er octobre 2026 ; rédaction le 2 octobre. Contexte : laboratoire BPF pour médicaments humains. Les critères de conception doivent être adaptés au processus et n’imposent aucune architecture particulière.

• Commission européenne — Annexe 11, révision de janvier 2011, principe et §§3–4, 7, 9–12, 16–17 : fournisseurs, usage prévu, contrôles et cycle de vie. Applicable depuis le 30 juin 2011 ; la révision de 2025 est une proposition consultative, non une exigence adoptée.
• FDA — Data Integrity and Compliance With Drug CGMP, version finale de décembre 2018, Q1 et Q3 : contexte des données et validation de l’usage prévu. Recommandations américaines non contraignantes à lire avec les règles applicables.