Le jour de l’inspection, la question n’est pas de savoir si votre logiciel est conforme. On vous demande qui a créé le compte qui a signé, et qui a revu la piste d’audit le mois dernier.
Un instrument acheté « 21 CFR Part 11 » arrive et mesure bien. Dix-huit mois plus tard, l’auditeur trouve un seul compte, partagé, avec le mot de passe écrit sur l’armoire. Le logiciel est conforme, mais le système n’est pas défendable. L’écart est organisationnel, et il se découvre tard.
Ce que nous fournissons, ce que vous portez
| Nous fournissons | Vous approuvez et portez |
|---|---|
| L’analyse de la déclaration du logiciel retenu : ce qui est natif, ce qui se configure, ce qui manque | La décision d’achat |
| La configuration : comptes nominatifs, profils, séparation des rôles, piste d’audit | La gestion des comptes, la revue de la piste d’audit |
| Les protocoles de qualification | Leur approbation et leur exécution dans votre système qualité |
| Le dossier de la méthode et du modèle | Son intégration à votre système documentaire |
Nous consultons votre service de validation informatique dès le cadrage. Consulté tôt, il oriente. Consulté au déploiement, il bloque.
Montrez-nous la déclaration que vous avez reçue : nous vous dirons ce qu’elle couvre. Prendre rendez-vous.
Ce qu’une déclaration de conformité couvre réellement
Une déclaration de conformité de fabricant, quand elle est bien faite, est un document sérieux : signée, datée, référencée. Et son périmètre est exact, encore faut-il le lire.
Une version de logiciel, pas une gamme
La déclaration nomme un logiciel dans une version précise, parfois avec sa référence article. La version que vous installerez trois ans plus tard n’est pas couverte par ce document-là. La mise à jour et sa requalification se traitent dès l’achat, pas au moment de la migration.
Un référentiel cité nommément
Les bonnes déclarations citent leurs textes : 21 CFR Part 11, annexe 11 des bonnes pratiques de fabrication européennes. Une mention générique du type « conforme aux enregistrements et signatures électroniques », sans référentiel nommé, n’engage rien et ne se défend pas devant un inspecteur.
Une classification GAMP 5
Le logiciel est rangé dans une catégorie, et cette catégorie détermine l’effort de validation qui vous incombe. C’est l’information la plus utile du document, et la plus souvent sautée.
La catégorie 3 mérite une explication, parce que son intitulé induit en erreur. On la traduit par « produits non configurables », ce qui laisse croire qu’un logiciel paramétrable en serait exclu. Ce n’est pas le cas. Un logiciel peut offrir de nombreux réglages et rester en catégorie 3, à deux conditions. Qu’il soit toujours utilisé avec une configuration standard établie à l’installation et à la qualification. Et que ces réglages soient des paramètres d’exécution, non du développement de fonctions nouvelles.
La conséquence est directe : en catégorie 3, on ne valide pas le code, on qualifie l’installation et l’usage. L’effort se déplace de l’éditeur vers vous.
Ce qui reste à votre charge, quel que soit le logiciel
Ce n’est pas une opinion de notre part. Les déclarations de conformité sérieuses le disent elles-mêmes. La conformité d’ensemble dépend aussi des contrôles procéduraux de l’exploitant : notification, formation, procédures, administration. Cette réserve figure noir sur blanc dans les documents les mieux rédigés du marché, et c’est tout à leur crédit. Un fabricant qui l’écrit vous rend service. La mention seule, elle, ne dit pas où s’arrête la responsabilité du logiciel et où commence la vôtre.
Voici ce qui reste de votre côté, quelle que soit la qualité du logiciel :
- La gestion des comptes. Un compte nominatif par personne, une politique de mots de passe, une procédure de départ. Le logiciel offre le mécanisme. C’est vous qui décidez de l’utiliser.
- Vos procédures. Qui a le droit de créer une méthode, qui la vérifie, qui l’approuve, et ce qui se passe quand un résultat est écarté. Rien de cela ne se paramètre dans un menu.
- Votre plan de formation. Une signature électronique n’a de valeur que si la personne qui signe a été formée et si cette formation est tracée. C’est une des premières choses vérifiées : la formation des équipes n’est pas un supplément de confort.
- Votre gouvernance des données. Où sont stockées les données brutes, qui y accède, comment elles sont sauvegardées, combien de temps elles sont conservées, comment on les relit dans dix ans.
- La qualification de votre installation. Le fabricant qualifie son produit dans son atelier. Votre installation (cette sonde, sur cet équipement, avec ce câblage) n’a jamais été qualifiée avant vous. C’est le cœur d’un projet d’intégration.
Les questions à poser avant de signer un bon de commande
Cette liste tient sur une page et fait gagner des mois. Posez-la par écrit : la qualité de la réponse vous renseigne autant que son contenu.
Pour chaque exigence, une seule question : natif, configurable, ou à développer ? La réponse change tout. Natif, la fonction est dans le logiciel livré et couverte par sa déclaration. Configurable, elle existe mais dépend d’un paramétrage que vous devrez spécifier, tester et documenter. À développer, elle n’existe pas encore : elle a un coût, un délai, et sort du périmètre de la déclaration.
| Exigence | Ce qu’il faut obtenir | Natif, configurable ou à développer ? |
|---|---|---|
| Piste d’audit | Nominative, horodatée, non modifiable, et lisible sans outil de l’éditeur | À demander par écrit |
| Signature électronique | Liée à l’enregistrement signé : signataire, date, signification du geste | À demander par écrit |
| Séparation des tâches | Celui qui crée une méthode n’est pas celui qui l’approuve, et le logiciel l’impose au lieu de le suggérer | À demander par écrit |
| Profils et droits | Des rôles définis par vous, pas une liste figée par l’éditeur | À demander par écrit |
| Versions des modèles et des méthodes | Chaque résultat rattaché à la version qui l’a produit | À demander par écrit |
| Données brutes | Export dans un format ouvert, relisible sans le logiciel | À demander par écrit |
La séparation des tâches est la ligne qui fait le plus souvent la différence en audit. Un logiciel qui propose des profils sans empêcher qu’une même personne crée et approuve ne répond pas à l’exigence : il la laisse à votre procédure.
- Existe-t-il une matrice de conformité ? Un tableau qui reprend chaque exigence du référentiel et indique en face comment le logiciel y répond. Sans matrice, une déclaration reste une affirmation.
- Sur quelle version porte-t-elle ? Et quelle version allez-vous recevoir. Les deux ne coïncident pas toujours.
- Quelle politique de comptes est spécifiée ? Comptes nominatifs, rôles, privilèges, expiration : ce qui figure dans les exigences fonctionnelles, non ce qui est possible en théorie.
- La signature électronique est-elle spécifiée ou seulement revendiquée ? Une signature conforme suppose un lien indissociable entre le signataire, le document, la date et la signification du geste. Demandez où c’est écrit.
- Quel mécanisme verrouille une méthode ? Une méthode approuvée doit devenir non modifiable, ou toute modification doit créer une version tracée. Demandez le comportement, pas la case à cocher.
- L’émission des événements vers un système tiers est-elle identique à la piste d’audit locale ? Si le flux exporté vers la supervision ou l’historisation est plus pauvre que la trace locale, votre archive réglementaire est la plus pauvre des deux.
Attention aux références réglementaires qui n’en sont pas
Une fiche produit peut citer le 21 CFR 1040.10, la norme de performance des produits laser : c’est une référence de sécurité, distincte du 21 CFR Part 11. Les deux appartiennent au même code fédéral. Vérifiez de quel texte parle la fiche avant de la joindre à une qualification.
Le serveur de communication qui reste ouvert
Beaucoup d’instruments exposent un serveur de communication industrielle pour dialoguer avec l’automate ou la supervision. Question à poser : ce serveur reste-t-il actif après la fermeture du logiciel principal, et accepte-t-il des écritures de clients tiers ? Si oui, le contrôle d’accès du logiciel est contourné par une porte latérale, ce qui se concilie mal avec la notion de système fermé. C’est une caractéristique d’architecture, courante et souvent utile, qu’il faut documenter et encadrer. Encore faut-il l’avoir demandée.
Ce qui va changer
L’annexe 11 en vigueur date de janvier 2011. Elle est en cours de révision, et le projet ne circule pas seul. Du 7 juillet au 7 octobre 2025, la Commission européenne a mis en consultation trois textes rédigés conjointement par le groupe des inspecteurs de l’EMA et le PIC/S : un chapitre 4 révisé, une annexe 11 révisée, et une nouvelle annexe 22 consacrée à l’intelligence artificielle. La consultation est close. Rien n’est adopté à ce jour : l’annexe 11 applicable reste celle de 2011, et l’annexe 22 n’existe qu’à l’état de projet.
Pourquoi le projet d’annexe 22 vous concerne même si vous ne faites pas d’intelligence artificielle
Son périmètre est explicite, et il surprend. Le projet s’applique là où des modèles sont employés dans des applications critiques ayant un impact direct sur la sécurité du patient, la qualité produit ou l’intégrité des données, « e.g. to predict or classify data ». Il vise les modèles qui ont acquis leur fonctionnalité « through training with data, rather than being explicitly programmed », les modèles statiques — ceux qui n’adaptent pas leur performance en service — et les modèles à sortie déterministe.
Et il écarte des applications GMP critiques les modèles dynamiques auto-apprenants, les modèles à sortie probabiliste, l’IA générative et les grands modèles de langage.
Un modèle chimiométrique coche les quatre critères d’inclusion. Une régression PLS tire sa fonctionnalité d’une calibration sur données et non d’une programmation explicite ; elle est figée après validation ; elle rend une sortie déterministe ; et elle sert à prédire une grandeur qui décide. Le projet ne contient aucune exclusion pour la chimiométrie.
La plupart des exigences du projet recouvrent ce qu’une pratique sérieuse fait déjà : critères d’acceptation prédéfinis, performance au moins égale à celle de la méthode remplacée, prétraitement spécifié et justifié, explicabilité de la prédiction, score de confiance, surveillance de la performance et du maintien des entrées dans le domaine du modèle. C’est le sujet de la surveillance d’un modèle dans le temps.
Un point, en revanche, n’a pas d’équivalent dans la pratique chimiométrique courante : l’indépendance du jeu de test. Le projet demande que les personnes ayant développé et entraîné le modèle « have never had access to the test data », que ce jeu soit protégé par contrôle d’accès et piste d’audit, et qu’à défaut de séparation des personnes on applique un principe des quatre yeux. Or c’est le plus souvent le même chimiométricien qui construit le modèle et qui le teste.
Notre lecture, et nous la donnons comme telle : le débat ouvert par la consultation porte sur l’admission éventuelle des modèles génératifs, pas sur le retrait des modèles statiques. Un assouplissement pour la chimiométrie nous paraît donc peu probable, et l’écart à combler se situe dans la gouvernance des données de test plutôt que dans la modélisation. Rien de tout cela n’est opposable aujourd’hui — mais un projet d’installation qui vivra cinq ans gagne à être conçu en le sachant. Statut vérifié le 20 septembre 2026.
ALCOA+, la piste d’audit et la revue des données
Les principes ALCOA+ tiennent en quelques mots : une donnée doit être attribuable, lisible, contemporaine de l’événement, originale et exacte, et, pour le « plus », complète, cohérente, pérenne et disponible. C’est la définition de ce qui fait qu’une donnée soutient une décision.
Une mesure en continu les met à l’épreuve : un capteur produit un flux, pas un résultat. Que conserve-t-on, le spectre brut, le spectre prétraité, la valeur prédite ? Notre réponse est constante : conservez le spectre brut, horodaté et attribué. C’est la seule donnée originale au sens du texte, et la seule qui permette de rejouer un calcul le jour où un modèle est révisé. Une prédiction dont on a perdu le spectre source n’est plus vérifiable.
La piste d’audit, elle, ne vaut que si quelqu’un la lit. L’exigence n’est pas de l’enregistrer mais de la revoir, à une périodicité définie, avec une trace de cette revue. C’est un écart souvent constaté : la piste existe, elle est complète, elle n’a jamais été ouverte. Prévoyez qui la revoit et ce qui déclenche une investigation, exactement comme pour la surveillance des dérives de modèle. Ce que devient un modèle avec le temps.
Ce qui manque entre les deux
Un logiciel conforme est une condition nécessaire : il vous évite de compenser par des procédures ce qu’un produit mal conçu ne sait pas faire. Mais entre lui et un système validé, il reste un espace que rien n’achète.
Cet espace contient une analyse de risque, une spécification de vos besoins, un plan de validation, des protocoles de qualification écrits et exécutés, des procédures, un plan de formation, une gouvernance des comptes et la gestion des changements. Rien de cela ne se livre en caisse. C’est un travail de cadrage puis de déploiement, mené avec vos équipes qualité, et il commence avant l’arrivée de l’instrument.
Entre un logiciel conforme et un système validé, ce qui manque est un travail, pas un produit. Le nommer tôt, c’est le budgéter. Le découvrir en audit, c’est le payer deux fois.
Questions fréquentes
« 21 CFR Part 11 ready » et « système validé », quelle différence exactement ?
La première décrit un produit : le logiciel offre les mécanismes attendus, comptes, traçabilité, signature, verrouillage. La seconde décrit un état de votre installation : ces mécanismes sont configurés, qualifiés, documentés, utilisés par des personnes formées et maintenus dans le temps. Il faut les deux, et seule la seconde moitié dépend de vous.
Qui est responsable en cas d’écart constaté en inspection ?
L’exploitant, sans ambiguïté. La réserve figurant dans les déclarations de conformité n’est donc pas une précaution d’avocat : elle décrit le partage réel des rôles. Le fabricant répond de son produit. Vous répondez de votre système, y compris de la façon dont vous utilisez ce produit.
Faut-il valider le modèle chimiométrique lui-même ?
Oui, et c’est un dossier distinct. Un modèle de prédiction est une méthode analytique : il se valide comme telle. La conformité du logiciel qui l’héberge ne dit rien de la justesse de ce qu’il prédit.
Un instrument non conforme peut-il quand même servir ?
Oui, en développement, en preuve de concept ou en pilotage sans effet sur une libération. Le point à tenir est simple : quand un usage exploratoire devient réglementé, on refait le point. Nommez l’usage visé dès le départ : il détermine le reste, budget compris.
Par où commencer si rien n’est encore fait ?
Par l’inventaire de l’existant : la déclaration du fabricant, sa version, sa matrice si elle existe, la configuration réellement installée, la liste des comptes, les procédures en vigueur. Cet inventaire suffit à savoir ce qui manque. Le doublement d’une ligne ajoute une question : deux appareils du même modèle ne produisent pas forcément la même donnée.
Montrez-nous la déclaration que vous avez reçue. Nous vous dirons ce qu’elle couvre et ce qu’elle laisse à votre charge.
Quarante-cinq minutes suffisent : lire un document de conformité, repérer les questions qui n’ont pas été posées au fournisseur et situer l’effort qui vous reste : qualification, procédures, formation, gouvernance des données.