Logiciel de production en environnement réglementé : ce qu'exigent l'ISO 13485, le MDR et le 21 CFR Part 11
Un éditeur vous présente son logiciel comme « certifié ISO 13485 ». C'est rassurant — et c'est un abus de langage : aucun logiciel ne l'est. Ce que les référentiels exigent porte sur vos enregistrements et sur une validation dont vous restez responsable, quelle que soit la certification de l'éditeur. Voici ces exigences, et ce qu'elles changent au moment de choisir un outil.
Que demande la réglementation ?
Aucun de ces textes ne « certifie » un logiciel. Ils imposent des propriétés sur vos enregistrements et une validation de l'outil pour votre usage. Ils n'ont ni la même nature juridique ni le même champ, et ne s'appliquent pas forcément tous à vous ; trois termes reviennent dans toutes ces discussions.
- VSI / CSV
- Validation du système informatisé (Computerised System Validation) : la démarche documentée par laquelle vous démontrez que le logiciel fait ce dont vous avez besoin, dans votre environnement, pour votre usage. L'organisation réglementée en reste responsable, même quand l'éditeur fournit une part importante des preuves.
- Predicate rules
- Les réglementations FDA de fond qui exigent de créer ou de conserver un enregistrement donné. Ce sont elles qui déclenchent le 21 CFR Part 11 : sans predicate rule applicable, pas d'enregistrement « Part 11 ». C'est le point de départ de toute analyse de périmètre, avant même de parler d'audit trail ou de signature électronique.
- ALCOA+
- Grille de lecture répandue pour l'intégrité des données : Attributable (on sait qui), Legible, Contemporaneous (saisi au moment de l'acte), Original, Accurate, plus complet, cohérent, pérenne et disponible. Un cadre de bonnes pratiques utile pour concevoir vos enregistrements, qui ne remplace pas les exigences propres à votre référentiel.
| Référentiel | Ce qu'il exige, en pratique |
|---|---|
| ISO 13485 | Norme de QMS : la certification porte sur votre organisation, jamais sur un logiciel. Elle demande de valider l'application des logiciels utilisés dans le système qualité, proportionnellement au risque, et de maîtriser l'identification et la conservation des enregistrements. |
| MDR 2017/745 & IVDR 2017/746 | Règlements européens : identification des opérateurs de la chaîne, système UDI, documentation technique tenue longtemps à disposition, surveillance après commercialisation. Des attentes fortes de maîtrise et d'intégrité des enregistrements. |
| FDA — QMSR, Part 11, CSA | Le QMSR (2 février 2026) incorpore l'ISO 13485:2016. Le 21 CFR Part 11 ne vise que les enregistrements relevant d'une predicate rule — pas le seul fait de vendre aux États-Unis. La guidance CSA (2026) concentre l'assurance sur les fonctions les plus critiques. |
Résumé opérationnel : commencez par déterminer lesquels s'appliquent réellement à votre organisation. Il ne remplace ni la lecture des textes, ni l'avis de votre référent affaires réglementaires.
Que devez-vous faire ?
La validation du système informatisé intimide surtout parce qu'on l'aborde dans le mauvais ordre. Dans le bon ordre, elle se résume à quelques décisions — que votre organisation garde, quel que soit le logiciel.
- Écrire l'URS (besoin utilisateur) avant de choisir l'outil : la liste vérifiable de ce que le système doit permettre. C'est l'étape la plus rentable, et la plus souvent sautée.
- Évaluer le risque de l'usage : l'impact d'une défaillance sur la conformité du produit et la sécurité du patient dimensionne tout le reste.
- Récupérer et réutiliser ce que l'éditeur a déjà démontré (documentation de développement, protocoles de test, matrices) plutôt que tout retester.
- Exécuter des activités d'assurance proportionnées au risque — IQ/OQ/PQ ou approche CSA — et tracer chaque besoin jusqu'à son test.
- Maintenir la validation : évaluer l'impact de chaque mise à jour, revoir périodiquement. Une validation figée à la mise en service se périme.
- Garder la responsabilité : l'éditeur fournit des preuves et un accompagnement, mais la validation porte sur votre usage, dans votre environnement — elle vous appartient.
Un outil conçu pour ces exigences, et un accompagnement à la validation
Arianis est conçu pour les environnements ISO 13485, MDR, GxP et 21 CFR Part 11 : il fournit les fonctions permettant de les mettre en œuvre, le périmètre réellement applicable restant à déterminer ensemble. Cerebellis fournit en plus la documentation et la méthode pour qualifier l'outil dans votre système qualité — la validation reste la vôtre, mais vous ne la menez pas seul.
- Audit trail horodaté sur chaque action, comptes nominatifs et droits par module et par utilisateur.
- Écarts justifiés au moment de l'opération, contrôles qualité intégrés aux protocoles.
- Dossiers de lot exportables en PDF, exports CSV natifs de toutes les données ; conçu, développé et hébergé en France, HDS en option.
- Accompagnement VSI : périmètre, analyse de risque, tests et matrices de traçabilité, selon la méthode retenue (IQ/OQ/PQ ou approche par le risque).
Les logiciels Cerebellis liés à ce sujet
À lire aussi
Validation des systèmes informatisés (VSI) selon GAMP 5
Catégories logicielles, modèle en V, analyse de risque et matrice de traçabilité : comment GAMP 5 structure une validation de système informatisé proportionnée au risque.
Traçabilité des dispositifs médicaux : reconstituer un lot en quelques secondes
Ce que l'ISO 13485 et le MDR exigent d'une traçabilité de lot, les six exigences concrètes à remplir, et un test simple pour situer la vôtre.
Réussir ses rapports PMS et PSUR sans reconstruire les données à la main
Un PSUR relie exposition, incidents, tendances et actions. Pourquoi ces données vivent dans deux systèmes — production et qualité — et comment les réunir pour produire le rapport sans ressaisie.