Retour au blog
Logiciels & ISO 13485 ISO 13485 21 CFR Part 11 Validation

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.

16 min de lecture

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 couranteCe 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érentielNatureQuand il s'appliqueCe qu'il apporte sur les enregistrements
ISO 13485Norme 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 FDAIdentification 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/746Règlements européensSelon la nature de vos dispositifs : MDR pour les DM, IVDR pour les DIVIdentification 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 QMSRRéglementation FDA, effective depuis le 2 février 2026Pour les fabricants concernés par le marché américain — elle a remplacé l'ancienne Quality System RegulationIncorpore 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 11Réglementation FDA à champ spécifiquePour les enregistrements électroniques relevant d'une predicate rule FDA, et certaines soumissions électroniques à l'agenceValidation 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 2026Pour les logiciels utilisés en production ou dans le système qualité, dans le périmètre FDAApproche 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 GxPGuides de bonnes pratiques de l'industrieSelon 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 telsMé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.

  1. É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.
  2. É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.
  3. 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.
  4. 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.
  5. 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.
  6. 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 ?
Avec Arianis

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
Interface du module Magasin Arianis : suivi des stocks avec classe, localisation et date de péremption
Questions fréquentes

Conformité et validation : les questions qui reviennent

Un logiciel peut-il être « certifié ISO 13485 » ?
Non, et c'est un abus de langage courant. L'ISO 13485 est une norme de système de management de la qualité : une certification selon cette norme porte sur le QMS d'une organisation et est délivrée par un organisme de certification — pas par l'ISO, et pas sur un logiciel en tant que produit. Un éditeur peut donc être certifié en tant qu'organisation, et un logiciel peut être conçu pour répondre aux exigences que la norme fait peser sur vos enregistrements. Si un fournisseur annonce un logiciel « certifié ISO 13485 », la formulation est imprécise : demandez le périmètre exact du certificat.
Que demande l'ISO 13485 à propos des logiciels utilisés dans le système qualité ?
Elle demande de documenter des procédures de validation de l'application des logiciels utilisés dans le système de management de la qualité, avec une approche proportionnée au risque associé à leur usage. Autrement dit : plus le logiciel pèse sur la conformité du produit, plus la validation doit être approfondie. Un outil qui porte les dossiers de lot n'est pas au même niveau d'exigence qu'un outil de planification interne.
Qui est responsable de la validation : l'éditeur ou le fabricant ?
Le fabricant. L'éditeur peut fournir la documentation de son propre développement, des protocoles de test, des matrices de traçabilité et un accompagnement méthodologique — cela réduit considérablement votre charge, et GAMP 5 encourage explicitement à s'appuyer dessus. Mais la validation porte sur votre usage, dans votre environnement : c'est à vous qu'il revient de la conduire et de la documenter, quelle que soit la part de preuves fournie par l'éditeur.
Quand le 21 CFR Part 11 s'applique-t-il ?
Son champ ne dépend pas uniquement du pays de commercialisation. Part 11 concerne certains enregistrements électroniques requis par les réglementations FDA applicables — les « predicate rules » — ainsi que certaines informations soumises électroniquement à l'agence. Le périmètre se détermine donc à partir des enregistrements et des obligations FDA concernés : le seul fait de vendre un dispositif aux États-Unis ne rend pas automatiquement tous vos systèmes électroniques soumis à Part 11, et la FDA indique elle-même qu'une lecture trop large de ce champ est inappropriée. Cela dit, plusieurs de ses caractéristiques — contrôle des accès, conservation des enregistrements, audit trail lorsqu'il est requis, signatures électroniques — restent de bonnes questions à poser en évaluant un système. Elles ne constituent pas pour autant des exigences génériques du MDR ou de l'ISO 13485, et l'annexe 11 EudraLex relève quant à elle du cadre GMP des médicaments.
Combien de temps prend une validation de système informatisé ?
Cela dépend du périmètre et surtout de la qualité de l'URS. Un cahier des besoins précis, écrit avant le choix de l'outil, réduit la validation à une exécution de tests. Un URS écrit après coup, pour justifier un outil déjà en place, transforme la validation en négociation avec vous-même — et c'est là que les délais s'allongent.
Faut-il revalider après chaque mise à jour du logiciel ?
Pas systématiquement, et pas intégralement. L'approche attendue est proportionnée au risque : on évalue ce que la mise à jour modifie, on identifie les fonctions critiques touchées, et on rejoue les tests correspondants. C'est pourquoi il est utile que l'éditeur documente clairement le contenu de chaque version.
Un tableur peut-il porter des enregistrements réglementés ?
Techniquement, oui, à condition de le valider et de maîtriser les accès, les versions et l'historique des modifications — ce qui coûte souvent plus cher que d'utiliser un outil conçu pour cela. Le problème pratique du tableur n'est pas qu'il soit interdit : c'est qu'il ne fournit pas nativement la plupart des propriétés attendues en matière d'intégrité des données. Certains attributs restent atteignables, mais le contrôle des accès, l'historique des modifications et l'impossibilité de réécriture demandent alors des mesures compensatoires.
Contact

Une validation à cadrer ? Parlons de votre périmètre et de votre niveau de risque.