Logiciel de production en environnement réglementé : ce qu'exigent l'ISO 13485, le MDR et le 21 CFR Part 11
Aucun logiciel n'est « certifié ISO 13485 ». Ce que les référentiels exigent, ce sont des propriétés sur vos enregistrements et une démarche de validation dont vous restez responsable. Voici lesquelles, et ce que cela change au moment de choisir un outil.
Le malentendu à lever d'abord
« Ce logiciel est-il conforme ISO 13485 ? » est la question la plus fréquente et la moins utile. Reformulée correctement, elle devient actionnable.
| Formulation courante | Ce qu'il faut demander à la place |
|---|---|
| « Votre logiciel est-il certifié ISO 13485 ? » | « Quelles exigences de l'ISO 13485 sur les enregistrements votre outil me permet-il de satisfaire, et comment le démontrez-vous ? » |
| « Êtes-vous conforme 21 CFR Part 11 ? » | « Comment gérez-vous l'audit trail, l'unicité des comptes, l'attribution des actions et la protection des enregistrements ? » |
| « Est-ce validé ? » | « Quelle documentation fournissez-vous pour que je puisse valider l'outil dans mon environnement, et jusqu'où m'accompagnez-vous ? » |
| « C'est un outil qualité ? » | « Que couvre-t-il exactement : la production, les enregistrements, le système documentaire, les CAPA ? » |
Ce que les référentiels demandent réellement à vos enregistrements
Ces référentiels n'ont ni la même nature juridique, ni le même champ d'application : une norme, des règlements, une réglementation à champ spécifique, des guides de bonnes pratiques. Ils ne s'appliquent pas nécessairement tous à votre organisation — mais leurs attentes sur les enregistrements convergent plus qu'on ne le croit.
| Référentiel | Nature | Quand il s'applique | Ce qu'il apporte sur les enregistrements |
|---|---|---|---|
| ISO 13485 | Norme de système de management de la qualité | Lorsque votre QMS est certifié ou construit selon cette norme, et par incorporation dans le QMSR de la FDA | Identification du produit tout au long de la réalisation, étendue de traçabilité définie, maîtrise des enregistrements, validation de l'application des logiciels utilisés dans le système qualité, maîtrise des équipements de mesure. |
| MDR 2017/745 et IVDR 2017/746 | Règlements européens | Selon la nature de vos dispositifs : MDR pour les DM, IVDR pour les DIV | Identification des opérateurs de la chaîne d'approvisionnement, système UDI, documentation technique tenue à disposition des autorités sur des durées longues, surveillance après commercialisation. |
| FDA QMSR | Réglementation FDA, effective depuis le 2 février 2026 | Pour les fabricants concernés par le marché américain — elle a remplacé l'ancienne Quality System Regulation | Incorpore l'ISO 13485:2016 par référence, avec des exigences FDA complémentaires. Son applicabilité s'évalue séparément de celle du 21 CFR Part 11. |
| 21 CFR Part 11 | Réglementation FDA à champ spécifique | Pour les enregistrements électroniques relevant d'une predicate rule FDA, et certaines soumissions électroniques à l'agence | Validation des systèmes, audit trail généré par le système, limitation des accès aux personnes autorisées, contrôles d'autorité, signatures électroniques liées de façon indissociable à leur enregistrement. |
| FDA CSA (Computer Software Assurance) | Guidance FDA, version finale de février 2026 | Pour les logiciels utilisés en production ou dans le système qualité, dans le périmètre FDA | Approche d'assurance basée sur l'usage prévu et le risque, concentrée sur les fonctions les plus critiques. Elle n'impose pas un modèle IQ/OQ/PQ unique et cite les sous-clauses ISO 13485 4.1.6, 7.5.6 et 7.6. |
| GAMP 5 et guides GxP | Guides de bonnes pratiques de l'industrie | Selon vos activités et vos engagements contractuels. L'annexe 11 EudraLex relève des GMP des médicaments, non des fabricants de DM en tant que tels | Méthodes pour structurer une validation proportionnée au risque, s'appuyer sur ce que le fournisseur a déjà démontré, et privilégier une documentation utile plutôt qu'abondante. |
Synthèse à visée opérationnelle : elle ne remplace pas la lecture des textes ni l'avis de votre référent affaires réglementaires. Commencez par déterminer lesquels s'appliquent réellement à votre organisation.
Malgré leurs différences, ces référentiels comportent des attentes relatives à la maîtrise et à l'intégrité des enregistrements. Les contrôles concrets nécessaires varient ensuite selon le référentiel, le type d'enregistrement, son usage et le risque associé. ALCOA+, présentée plus bas, constitue une grille de lecture utile pour raisonner sur ces attentes ; elle ne remplace pas les exigences spécifiques de chaque texte.
ALCOA+ : une grille utile pour raisonner sur l'intégrité des données
Neuf propriétés, à confronter à votre système actuel plutôt qu'à un logiciel hypothétique. ALCOA+ est un cadre de bonnes pratiques, particulièrement répandu en environnement GxP : il aide à concevoir des enregistrements défendables, mais les exigences opposables restent celles du référentiel applicable à votre organisation.
- Attribuable
- On sait qui a saisi ou modifié la donnée. Un compte partagé entre plusieurs opérateurs rend cette propriété impossible.
- Lisible
- La donnée reste lisible et interprétable pendant toute sa durée de conservation, y compris après changement d'outil.
- Contemporain
- La saisie a lieu au moment de l'acte, pas le lendemain de mémoire ni la veille de l'audit.
- Original
- On dispose de la donnée source, ou d'une copie certifiée conforme. Une recopie manuelle n'est pas un original.
- Exact
- La donnée correspond à ce qui s'est réellement passé, écarts compris — pas à ce qui était prévu.
- Complet, cohérent, pérenne, disponible
- Rien ne manque, y compris les corrections et les résultats hors spécification ; la chronologie est cohérente ; le support survit à la durée de conservation ; la donnée est produisible pendant l'audit.
La validation du système informatisé, sans mystère
La VSI intimide surtout parce qu'elle est souvent abordée dans le mauvais ordre. Dans le bon ordre, c'est une suite de six étapes.
- Écrire l'URS, idéalement avant de choisir l'outilCe que le système doit permettre, exprimé en besoins métier vérifiables. C'est l'étape la plus rentable, et la plus souvent sautée.
- Évaluer le risque associé à l'usageQuel impact une défaillance aurait-elle sur la conformité du produit et la sécurité du patient ? C'est cette réponse qui dimensionne tout le reste.
- Récupérer ce que l'éditeur a déjà démontréDocumentation de développement, protocoles de test, matrices de traçabilité. GAMP 5 invite explicitement à s'appuyer dessus plutôt qu'à tout refaire.
- Définir et exécuter des activités d'assurance proportionnées au risqueLes tests doivent avant tout démontrer que les fonctions pertinentes répondent à leur usage prévu dans votre environnement. IQ/OQ/PQ — installation conforme, fonctions conformes aux spécifications, système répondant au besoin réel avec vos données et vos utilisateurs — constitue une méthodologie appropriée selon le contexte, mais ce n'est pas l'unique structure possible : l'approche CSA de la FDA en propose une autre, centrée sur le risque.
- Tracer chaque besoin jusqu'à son testLa matrice de traçabilité est le moyen le plus courant de transformer une validation déclarative en validation démontrable.
- Maintenir la validation dans le tempsGestion des changements, évaluation d'impact des mises à jour, revue périodique. Une validation figée à la mise en service se périme.
Questions à poser à un éditeur avant de signer
Dix questions qui distinguent un outil réellement utilisable en environnement réglementé d'un outil qui coche des cases sur une plaquette.
- L'audit trail est-il généré par le système, ou dépend-il d'une action de l'utilisateur ?
- Une valeur peut-elle être modifiée sans que la valeur précédente reste consultable ?
- Chaque utilisateur a-t-il un compte nominatif, et les comptes partagés sont-ils empêchés ?
- Les droits se règlent-ils par module et par utilisateur, ou seulement par grands profils ?
- Quelle documentation de validation fournissez-vous, et sous quelle forme ?
- Accompagnez-vous les activités de qualification — IQ/OQ/PQ ou approche basée sur le risque — et jusqu'où ?
- Le contenu de chaque mise à jour est-il documenté pour permettre une évaluation d'impact ?
- Puis-je exporter l'intégralité de mes données, dans un format exploitable, à tout moment ?
- Où les données sont-elles hébergées, et sous quel régime ?
- Que se passe-t-il pour mes enregistrements si je mets fin au contrat ?
Un outil conçu pour ces exigences, et un accompagnement à la validation
Arianis est conçu pour les exigences des environnements ISO 13485, MDR, GxP et 21 CFR Part 11 : il fournit des fonctions permettant de les mettre en œuvre, le périmètre réellement applicable à votre organisation restant à déterminer ensemble. Cerebellis fournit en plus la documentation et la méthode pour qualifier l'outil au sein de votre système qualité — la validation reste la vôtre, mais vous n'avez pas à la mener seul.
- Audit trail horodaté sur chaque action, avec l'identité de l'opérateur
- Gestion fine des droits par module et par utilisateur, comptes nominatifs
- Écarts justifiés au moment où ils surviennent, contrôles qualité intégrés aux protocoles
- Dossiers de lot et fiches de production exportables en PDF, exports CSV natifs de toutes les données
- Connexions chiffrées SSL/TLS, instance dédiée et isolée, sauvegardes quotidiennes
- Accompagnement VSI : périmètre, analyse de risque, tests, rapport de qualification et matrices de traçabilité, selon la méthodologie retenue (IQ/OQ/PQ ou approche basée sur le risque)
- Conçu, développé et hébergé en France, avec hébergement HDS disponible en option