Logiciel QMS / SMQ ISO 13485 : numériser le système qualité sans confondre l'outil et l'exigence
Un eQMS peut rendre un système qualité plus fiable et plus visible. Il ne crée ni la responsabilité de la direction, ni les critères de décision, ni la conformité à votre place. Pour choisir correctement, il faut d'abord séparer ce que les référentiels exigent du SMQ et ce qu'un logiciel peut réellement automatiser.
Le SMQ est un système d'organisation, pas un catalogue de modules
Le piège le plus fréquent consiste à transformer une liste commerciale de fonctionnalités en liste d'exigences réglementaires. Les règlements raisonnent en responsabilités et en processus.
| Composante du QMS | Question qualité | Outillage logiciel possible |
|---|---|---|
| Responsabilités et gouvernance | Qui décide, qui approuve, qui escalade ? | Rôles, droits, circuits d'approbation, visibilité des responsabilités |
| Stratégie réglementaire | Quels marchés et exigences s'appliquent au dispositif ? | Registre ou liens documentaires ; l'analyse réglementaire reste une expertise humaine |
| Maîtrise des documents et enregistrements | Quelle version est applicable et quelles preuves doivent être conservées ? | GED, versioning, approbations, historique, archivage selon l'outil choisi |
| Réalisation du produit | Comment le dispositif est-il conçu, acheté, produit et contrôlé ? | PLM, ERP, MES ou outils métier selon l'étape |
| Événements qualité | Que s'est-il passé et quelle décision a été prise ? | Non-conformités, réclamations, incidents, écarts et workflows associés |
| CAPA et amélioration | Quelle cause traiter et comment vérifier l'effet de l'action ? | Investigation, plan d'actions, échéances, preuves et contrôle d'efficacité |
| Surveillance après commercialisation | Quels signaux arrivent du terrain et que changent-ils ? | Collecte, qualification, tendances, PMS, vigilance et liens vers CAPA |
| Mesure et analyse | Le système est-il efficace et où dérive-t-il ? | Indicateurs, tableaux de bord, tendances et données de revue |
Les outils peuvent être réunis dans une suite ou répartis entre plusieurs systèmes. Le besoin réglementaire est la maîtrise de l'ensemble et des interfaces, pas l'unicité de l'éditeur.
MDR et IVDR : le QMS couvre tout le cycle de vie
Les règlements européens décrivent un périmètre très large. Il faut le lire comme une architecture de responsabilités, pas comme l'obligation de disposer d'un logiciel monolithique.
Stratégie et conformité réglementaire
Identifier les procédures de conformité, les dispositifs couverts, les obligations applicables et les responsabilités associées.
Responsabilités, ressources et fournisseurs
Définir l'organisation, les compétences et la maîtrise des ressources et partenaires nécessaires à la conformité.
Réalisation du produit
Planification, conception, développement, production et service doivent être maîtrisés selon les activités qui s'appliquent à l'organisation.
Identification et traçabilité
Le QMS organise les identifiants, la traçabilité applicable et le raccordement aux exigences UDI et aux autres obligations du règlement.
PMS, vigilance et communication
Les données du terrain doivent être collectées, analysées et reliées aux décisions de sécurité, aux actions et aux mises à jour nécessaires.
CAPA et vérification d'efficacité
Le MDR et l'IVDR citent explicitement la gestion des actions correctives et préventives et la vérification de leur efficacité dans le périmètre du système qualité.
Cette portée explique pourquoi il est dangereux de demander « quel logiciel couvre ISO 13485 ? ». Aucun écran ne couvre à lui seul un système aussi large. La bonne question est : quel processus voulons-nous rendre plus fiable, quelles preuves devons-nous produire, et quelles interfaces devront rester maîtrisées avec les autres outils ?
Numériser d'abord les workflows où le temps et la preuve se perdent
Le meilleur premier module n'est pas celui que les éditeurs mettent en premier dans leur brochure. C'est celui dont la défaillance vous coûte le plus en délai, en risque ou en reconstitution.
| Symptôme | Processus à examiner | Donnée qu'il faut rendre visible |
|---|---|---|
| Les CAPA dépassent leurs échéances | CAPA / actions | Responsable, délai, dépendances, preuves et contrôle d'efficacité |
| On ne sait pas si deux incidents ont la même cause | Événements qualité | Catégorie, produit, cause, criticité et historique de recherche |
| Une action est « terminée » sans preuve | Gestion des actions | Livrable attendu, pièce jointe ou enregistrement de vérification |
| Les réclamations restent dans les emails | Réclamations / PMS | Date de connaissance, dispositif, lot, qualification, investigation et décisions |
| Un changement est appliqué avant son analyse | Change control | Impact produit/processus/réglementaire, approbations et actions préalables |
| La direction découvre les retards en revue annuelle | Pilotage | Indicateurs, charges, retards, récurrences et tendances |
Ce qu'un workflow qualité doit conserver de bout en bout
Un ticket n'est utile que s'il permet de comprendre la chronologie de la décision sans ouvrir une série d'emails et de fichiers locaux.
- Créer l'événement avec son contexteSource, date, produit ou processus concerné, lot lorsque pertinent, description factuelle et pièces initiales.
- Qualifier et prioriserAppliquer les critères définis par votre procédure : type d'événement, criticité, risque, besoin d'escalade ou de notification.
- Attribuer une responsabilité et une échéanceLa responsabilité doit être visible. Une boîte mail collective ou une ligne sans propriétaire transforme facilement le retard en responsabilité partagée par personne.
- Conserver l'investigation et les décisionsHypothèses, données examinées, cause retenue ou justification de l'absence d'investigation approfondie selon le risque.
- Relier les actions à leur raison d'êtreUne action doit rester rattachée au problème ou au risque qui l'a déclenchée, avec son responsable, son délai et la preuve attendue.
- Vérifier l'efficacité avant de fermer définitivementLa clôture administrative d'une action ne prouve pas qu'elle a empêché la récurrence. La méthode et le délai du contrôle d'efficacité doivent être adaptés au phénomène observé.
- Réutiliser la donnéeLes catégories, causes, produits, fournisseurs et délais deviennent des données de tendance pour la revue de direction, le PMS et l'amélioration du système.
États-Unis : le QMSR a changé le vocabulaire réglementaire en 2026
Les fabricants qui maintiennent des procédures ou matrices FDA historiques doivent faire attention aux références devenues obsolètes.
Depuis le 2 février 2026, le 21 CFR Part 820 est le Quality Management System Regulation. Il incorpore l'ISO 13485:2016 par référence et comporte désormais principalement les exigences générales du QMSR ainsi que quelques dispositions FDA supplémentaires sur les enregistrements et l'étiquetage. La FDA a également cessé d'utiliser le QSIT comme méthode d'inspection.
Pour un système qualité international, cette évolution rapproche fortement la structure américaine de l'ISO 13485, sans rendre les exigences FDA identiques aux exigences européennes. Les obligations FDA additionnelles et les autres réglementations applicables restent à traiter séparément.
Suite eQMS ou outil spécialisé : choisir par le périmètre de preuve
Les deux architectures peuvent être pertinentes. Le risque vient surtout des zones grises entre les outils.
| Architecture | Avantage | Point de vigilance |
|---|---|---|
| Suite eQMS large | Référentiels et workflows regroupés | Projet de configuration plus vaste, validation et gouvernance de nombreux modules |
| Outil qualité spécialisé | Déploiement ciblé sur les événements et actions prioritaires | Maintenir clairement les interfaces avec GED, ERP, MES ou autres systèmes |
| Outils existants interfacés | Préserve les investissements et les processus déjà maîtrisés | Définir le système maître de chaque donnée et les contrôles d'échange |
| Système hybride avec supports manuels | Peut suffire à faible volume | Charge de rapprochement, versioning et production de preuves augmente avec l'activité |
Comparer un logiciel QMS / SMQ ISO 13485
La démonstration doit partir d'un événement réel et aller jusqu'à sa clôture, plutôt que d'additionner des cases fonctionnelles.
- Le périmètre fonctionnel réellement couvert est décrit sans prétendre que le logiciel constitue à lui seul le SMQ
- Les rôles et droits peuvent refléter les responsabilités définies dans vos procédures
- Chaque événement conserve sa source, sa date, le produit ou processus concerné et les pièces associées
- Les responsables, échéances, retards et statuts sont visibles sans recompilation
- Les investigations et décisions restent liées à l'événement initial
- Les actions conservent leur responsable, leur échéance et la preuve attendue
- La vérification d'efficacité peut être planifiée, enregistrée et distinguée de la simple clôture d'action
- Les récurrences peuvent être recherchées par produit, cause, catégorie, fournisseur ou autre dimension pertinente
- L'historique permet de retracer les modifications et changements de statut pertinents
- Les données peuvent alimenter des tendances, la revue de direction ou le PMS sans ressaisie
- Les interfaces avec production, GED, ERP ou autres systèmes ont un système maître clairement défini
- L'éditeur fournit la documentation nécessaire pour soutenir la validation du logiciel selon votre usage
- Les mises à jour sont documentées et permettent une analyse d'impact ciblée
- Les données et pièces peuvent être exportées dans un format exploitable
Praeventis structure les événements, CAPA et actions qualité
Praeventis couvre le suivi opérationnel des incidents, écarts, CAPA, changements et actions : responsables, statuts, échéances, preuves et historique restent reliés dans un même workflow. Il complète votre système qualité ; il ne remplace pas les responsabilités, procédures ou outils documentaires que votre organisation maintient par ailleurs.
- Tickets qualité avec projet, catégorie, responsable, statut et échéances
- Suivi des CAPA avec criticité, actions et analyse après mise en œuvre
- Actions reliées à l'événement qui les a déclenchées
- Pièces et preuves conservées dans le dossier concerné
- Comptes nominatifs et droits configurables selon les responsabilités
- Historique des changements et exports pour l'analyse ou l'audit
QMS, SMQ et ISO 13485 : les questions qui reviennent
L'ISO 13485 impose-t-elle d'acheter un logiciel QMS ?
Un eQMS rend-il une entreprise conforme ISO 13485 ?
Le MDR et l'IVDR exigent-ils un système qualité même sans certification ISO 13485 ?
Quelles fonctions faut-il absolument trouver dans un logiciel QMS ?
Praeventis est-il un eQMS complet ?
Que change le QMSR FDA depuis février 2026 ?
Un QMS doit-il être conforme au 21 CFR Part 11 ?
Les logiciels Cerebellis liés à ce sujet
À lire aussi
CAPA et non-conformités en dispositif médical : de l'écart à l'efficacité
Correction, investigation, cause, action corrective et vérification d'efficacité : structurer un processus CAPA proportionné au risque sans ouvrir une CAPA pour chaque écart.
Traçabilité des dispositifs médicaux : reconstituer un lot en quelques secondes
Ce que l'ISO 13485 et le MDR exigent réellement d'une traçabilité de lot, où elle casse en pratique, et un test en six étapes pour situer la vôtre.
Logiciel de production réglementé : ISO 13485, MDR et 21 CFR Part 11
Aucun logiciel n'est « certifié ISO 13485 » : ce que les référentiels exigent porte sur vos enregistrements et sur une validation dont vous restez responsable.