Comment un eQMS soutient-il les exigences du MDSAP ?
Par Vaclav Vlcek, MD
En bref :
La partie 1 a exposé les trois domaines de maîtrise de l'Audit Approach du MDSAP qui concernent particulièrement un système électronique de management de la qualité : la maîtrise des documents et des enregistrements, la compétence du personnel et la validation du logiciel pour son utilisation prévue. Cet article suit un document unique à travers notre propre eQMS au regard de ces exigences. Une seule version est en vigueur à tout moment, la version remplacée est conservée et non écrasée, les signatures sont rattachées à une personne nommément identifiée, et une modification est traitée selon qu'elle a ou non une incidence sur le travail des personnes. Le système soutient l'organisme dans la satisfaction de ces exigences. Il ne peut pas y satisfaire à sa place.
La partie 1 a exposé ce que l'Audit Approach du MDSAP en vigueur demande à un auditeur de confirmer. La version en vigueur est la version AU P0002.011, révisée le 3 août 2026.
Cet article en montre l'autre moitié.
Satisfaire aux critères d'audit constitue le point de départ. Exploiter un système que l'équipe peut utiliser chaque jour, sans qu'il la ralentisse, est ce qui détermine si un système qualité tient dans la durée ou devient une charge.
Nous avons conçu notre eQMS pour soutenir le système qualité ISO 13485 d'un organisme, et c'est le système sur lequel nous menons notre propre travail qualité. Ce qui suit décrit ce système tel que nous l'utilisons. La version d'un client est configurée selon ses processus et selon les marchés qu'il vise, de sorte que le détail diffère ; les mécanismes de maîtrise décrits ici sont ceux qui valent dans les deux cas.
Nous y suivons ici un document unique, afin de montrer comment ces mécanismes de maîtrise tiennent et comment le système est conçu pour être utilisé.
La structure du système
Le système est organisé en hiérarchie, et chaque niveau hérite de celui qui le précède. Comprendre cette structure est la clé de ce qui suit.
Il existe trois niveaux.
Category est le niveau de regroupement le plus élevé sous lequel les documents sont classés ; c'est lui qui donne à chaque document son numéro.
QMS Document est l'enregistrement parent qui porte tout ce qui est partagé sur la durée de vie d'un document : son nom, son type et les paramètres d'accès qui déterminent qui en est l'auteur, qui en fait la revue, qui l'approuve et qui doit y être formé.
Document Version est un fichier individuel créé sous cet enregistrement parent ; une seule version est en vigueur à un instant donné.
C'est l'héritage qui rend cette structure exploitable.
Les paramètres d'accès et les règles sont définis une seule fois, sur l'enregistrement parent, et chaque version créée en dessous en hérite. Une nouvelle version n'exige pas de ressaisir qui peut l'approuver ni qui doit y être formé. Cela se décide une fois et s'applique de manière uniforme, ce qui supprime une source d'erreur courante : une nouvelle révision diffusée silencieusement sous de mauvais approbateurs ou vers un mauvais public.
L'accès et la responsabilité sont le plus souvent attribués par rôle.
L'auteur, les réviseurs et les approbateurs d'un document sont le plus souvent des Rôles plutôt que des personnes nommément désignées. L'auteur peut être le responsable de la gestion des risques, le réviseur le responsable qualité. Des personnes nommément désignées peuvent être attribuées lorsque c'est ce que souhaite une entreprise, même si les rôles restent la norme en pratique. Comme un rôle est porté par un groupe, l'accès et la formation associés à un document se gèrent en un seul endroit, et lorsqu'une personne arrive ou change de rôle, ses accès et ses obligations suivent le rôle.
La maîtrise des documents et des enregistrements
La maîtrise des documents suppose que la version courante soit disponible là où elle est nécessaire, que les modifications soient approuvées avant que le document ne soit utilisé, et que les versions remplacées soient retirées et conservées. Le système impose cela au moyen d'une diffusion maîtrisée.
Un document commence par une version créée à partir d'un modèle, avec le statut Draft. Lorsqu'elle est prête, l'auteur lance la diffusion.
La diffusion se déroule dans une boîte de dialogue guidée unique. Elle réunit en un seul endroit la version du document et le plan de diffusion, avec une barre d'étapes indiquant où en est la diffusion et un bandeau nommant l'action suivante attendue, par exemple définir un approbateur avant que la diffusion puisse commencer. Chaque partie porte son propre statut. Un plan de diffusion peut être enregistré alors qu'il est encore incomplet, et la diffusion elle-même ne peut pas être lancée tant que ce qu'elle exige n'est pas en place.
Les réviseurs, les approbateurs et le public cible proviennent des paramètres du document lui-même, de sorte que personne ne ressaisit qui fait quoi. Le lancement de la diffusion est lui-même une action signée.
Là où des réviseurs sont attribués, ils font la revue et signent en premier. L'approbateur approuve ensuite, confirme l'attestation et signe.
À l'étape de diffusion, la date d'entrée en vigueur et la date de prochaine revue sont définies. La date de prochaine revue est calculée à partir du Criticality Index du document et peut également être saisie manuellement. Le document peut être diffusé immédiatement ou programmé pour entrer en vigueur à la date prévue.
Le mécanisme de maîtrise qui compte le plus pour un audit intervient au moment où la nouvelle version entre en vigueur. La version qu'elle remplace passe automatiquement au statut Obsolete.
Il n'existe pas d'étape distincte pour retirer l'ancien document, ni de fenêtre pendant laquelle deux versions seraient en vigueur simultanément. Le document courant ne prête jamais à doute.
La version remplacée est conservée et non écrasée
La partie 1 a exposé la règle de conservation : au moins un exemplaire obsolète de chaque document maîtrisé, conservé pendant une durée au moins équivalente à la durée de vie du dispositif et jamais moins de deux ans à compter de la date de libération du produit.
C'est là que le modèle de versions justifie sa place. Une version remplacée est marquée comme obsolète et conservée comme un enregistrement à part entière, aux côtés de l'enregistrement d'approbation qui l'a diffusée. Le système conserve l'historique et non le seul état courant.
Un document accumule des versions au fil de sa vie, et chacune peut être retrouvée avec les éléments de preuve indiquant qui l'a approuvée et à quelle date. Ce que fait le système, c'est conserver et restituer les versions remplacées et permettre de les gérer selon les règles de conservation qu'une entreprise a définies. Les durées de conservation elles-mêmes, ainsi que les mécanismes de maîtrise déterminant qui peut supprimer quoi que ce soit, restent à définir par l'organisme, puisqu'ils dépendent du dispositif et des marchés concernés.
Les statuts de document qui commandent ce fonctionnement, de Draft et Approved à Effective et Obsolete, sont définis par le système au fil du processus de diffusion et ne peuvent pas être modifiés manuellement. Un statuts de travail distinct permet aux équipes d'étiqueter leur propre avancement, sans effet sur le cycle de vie maîtrisé. Le statut sur lequel s'appuie un auditeur est celui que définit le système.
La liste des QMS Documents fait aussi office de liste courante de ce qui est approuvé et en vigueur, ce que plusieurs marchés demandent expressément. Le Brésil, comme l'a relevé la partie 1, exige une liste des documents approuvés et en vigueur, ainsi que des enregistrements de modification et des sauvegardes des enregistrements électroniques. Déterminer ce à quoi le système répond directement et ce qui dépend de sa configuration relève d'une mise en œuvre précise plutôt que d'une affirmation générale.
Une limite de cette présentation mérite d'être nommée. L'audit couvre les documents et les enregistrements d'origine interne comme externe. Ce qui suit porte principalement sur les documents qu'une entreprise rédige et maîtrise elle-même, et sur les enregistrements que produisent ses diffusions.
Les enregistrements et les signatures
Les enregistrements maîtrisés doivent rester identifiables, lisibles, protégés et accessibles, et être conservés aussi longtemps que les règles l'exigent. Pour un enregistrement de diffusion, les décisions doivent en outre être traçables jusqu'à une personne. Cette section montre les éléments de preuve que produit une diffusion, ce qui constitue une partie de la maîtrise des enregistrements et non son ensemble.
Chaque action de signature est confirmée par un PIN de signature personnel, une signature électronique simplifiée. Le PIN tient lieu de signature de la personne. Il est défini par elle et destiné à n'être connu et utilisé que par elle, et chaque utilisation s'accompagne d'une déclaration selon laquelle elle répond de la signature et n'a pas partagé ses identifiants. Cela rattache la signature à une seule personne nommément identifiée. Tant qu'un utilisateur n'a pas défini son PIN, il ne peut effectuer aucune action exigeant une signature.
Chaque diffusion produit un enregistrement d'approbation. Il indique ce qui a été soumis et par qui, le statut de revue et l'identité de la personne qui a fait la revue, ainsi que le statut d'approbation avec la date et les éventuels commentaires.
Ces champs sont en lecture seule. Les décisions ont été prises au fil du processus de diffusion, de sorte que l'enregistrement constitue la piste d'audit de la diffusion. Dataverse, la couche de données sous l'application, contient les enregistrements eux-mêmes : les tables, les journaux d'audit, les approbations et les signatures. L'étendue de la journalisation et sa durée dépendent de la configuration de l'environnement, qui fait partie de ce qu'un organisme configure et valide.
Les questions soulevées pendant une diffusion sont enregistrées comme consultations et restent attachées à la diffusion, de sorte qu'une question trouve sa réponse au regard de la diffusion elle-même plutôt que par courriel. La personne qui en a soulevé une peut la supprimer tant qu'elle est sans réponse ; dès lors que des réponses existent, elle ne peut plus qu'être clôturée. Ces fils font partie de la même piste.
Il en résulte qu'une large part des éléments de preuve que demande un auditeur existe déjà. Qui a approuvé un document, à quelle date, sur quelle version et avec quelle signature est enregistré au fil du travail plutôt que rassemblé après coup.
La compétence et les deux types de modification
La partie 1 a exposé ce qui a changé dans l'Audit Approach en vigueur : la tâche relative au personnel a été recentrée de la formation vers la compétence, et l'audit ne s'arrête pas à la participation. Il examine si l'action engagée a conduit à l'acquisition de la compétence requise, avec une vérification proportionnée au risque du travail.
Décider de ce qu'exige une modification incombe à l'organisme, qui consigne cette décision au titre de son propre système qualité. Ce que fait le logiciel, c'est soutenir le travail qui en découle.
Le système distingue deux types de modification.
Une révision qui modifie le document lui-même donne lieu à une nouvelle Document Version. Elle passe par la revue, l'approbation et la diffusion, et là où une formation est requise et configurée, la diffusion crée ou attribue une formation au Target Audience du document, hérité de l'enregistrement parent.
La modification d'une valeur ou d'un renvoi utilisé dans plusieurs documents se traite de manière centralisée dans le Content Manager. Y modifier la valeur répertorie tous les documents qui l'utilisent, avec un indicateur signalant ceux qui ne correspondent plus, et la nouvelle valeur peut ensuite être propagée vers ceux qui ne sont plus à jour.
La limite de ce mécanisme est ce qu'il faut en retenir. Une propagation ne peut atteindre une version en vigueur, obsolète ou déjà engagée dans une diffusion. Elle n'atteint que les versions au statut Draft. Un document diffusé se modifie comme se modifie tout document diffusé : en créant une nouvelle version et en la faisant passer par la revue, l'approbation et la diffusion.
Des éléments de preuve au-delà de la participation
Une formation se réalise de deux manières, et la différence compte pour ce que montre l'enregistrement.
Une formation de type Read & Understood enregistre qu'une personne a confirmé avoir lu le document. Une formation de type Questionnaire lui demande de répondre à des questions, avec un Pass threshold défini comme le nombre de bonnes réponses requis sur le total, exprimé en pourcentage. Une personne qui n'atteint pas le seuil suit à nouveau la formation.
L'enregistrement qui en résulte est une réussite ou un échec au regard du seuil, plutôt que les réponses individuelles. Il va plus loin qu'une confirmation de lecture et de compréhension, et il constitue un élément parmi plusieurs. La compétence elle-même repose sur la formation initiale, la formation, le savoir-faire et l'expérience pris ensemble, de sorte qu'un résultat de questionnaire apporte un élément de preuve sans trancher à lui seul la question.
Le contenu de formation est lui-même maîtrisé. Là où l'approbation est requise, une version de formation passe par la revue et l'approbation avant d'entrer en vigueur. Les questions auxquelles les personnes répondent constituent un contenu approuvé plutôt qu'un contenu assemblé sur le moment.
Le Dashboard de chaque personne n'affiche que la version en vigueur des documents qui lui sont attribués, regroupés par catégorie, à côté des formations qu'elle doit réaliser : en retard, à échéance proche, en attente ou terminées.
Comme la vue est construite à partir de ses attributions, la personne est orientée vers la version courante et voit ce qu'il lui reste à réaliser.
Une vue Coverage Gaps répertorie les versions de documents sans formation, ou dont la formation est refusée ou obsolète. Elle existe pour rendre une lacune visible afin que quelqu'un puisse y remédier. Elle ne bloque pas une diffusion : si une version est diffusée sans qu'aucune formation ait été créée, le système avertit et demande s'il faut poursuivre malgré tout, la décision revenant à la personne qui diffuse.
La validation du système lui-même
La partie 1 a exposé une exigence facile à survoler. L'Audit Approach attend que le logiciel utilisé dans le système de management de la qualité soit validé pour son utilisation prévue, selon un protocole écrit, et cela vaut pour un logiciel acquis auprès d'un fournisseur plutôt que développé en interne.
C'est le point où la répartition des responsabilités doit être énoncée clairement.
Nous construisons et fournissons le système, et nous pouvons fournir ce sur quoi une validation s'appuie : ce que fait le logiciel, le comportement des mécanismes de maîtrise décrits dans cet article, ce qu'une diffusion a modifié et nos propres éléments de preuve d'essai. La validation elle-même appartient à l'organisme. Il définit sa propre utilisation prévue et ce qu'il attend du système, décide à l'avance de ce que constitue un résultat satisfaisant, exécute le protocole sur sa propre configuration et conserve les enregistrements.
Ce qui est validé est le système configuré, et non le produit dans l'abstrait. Cela comprend les flux de travail en usage, la répartition des autorisations, les éventuelles connexions à d'autres systèmes, les paramètres de signature, ce que l'environnement journalise et pendant combien de temps, ainsi que les dispositions de conservation et de sauvegarde. Lorsque l'un de ces éléments change, la modification passe par la maîtrise des modifications et fait l'objet d'une revalidation lorsque la modification le justifie.
Aucun fournisseur ne peut livrer avec un produit la conformité au MDSAP ou à l'ISO 13485. Un auditeur examine l'usage que le fabricant fait du système, y compris la question de savoir s'il a été validé pour l'usage que le fabricant en fait.
Il s'agit d'un travail ordinaire de validation des systèmes informatisés, et c'est la raison pour laquelle la dernière section de cet article compte autant que les mécanismes de maîtrise qui précèdent. Un système simple à décrire est plus simple à valider.
La logique de conception
Les mécanismes de maîtrise décrits ci-dessus soutiennent l'exigence. La conception, elle, détermine si les personnes utilisent le système.
Le choix fondateur est que l'eQMS complète l'environnement du client plutôt que de le remplacer.
Il repose sur la Microsoft Power Platform et sur l'écosystème Microsoft plus large, de sorte qu'il prolonge les outils qu'un organisme exploite déjà : SharePoint, Dataverse, Power Automate, Teams. C'est le principe que QMLogic applique partout : utiliser ce qui fonctionne, étendre ce qui ne fonctionne pas et adapter l'outil à l'organisme. C'est aussi ce qui facilite l'adoption, parce qu'il y a moins à apprendre et moins à démonter.
À partir de là, l'orientation directrice est la simplicité.
Un système qualité ne fonctionne que si les personnes qui en dépendent supportent de l'utiliser au quotidien. L'objectif de conception est donc la solution la plus simple qui satisfasse à l'exigence. Un système que les personnes évitent n'aide pas une entreprise, si complet paraisse-t-il sur le papier.
L'ISO 13485 laisse place à cette approche. Elle énonce les mécanismes de maîtrise qui doivent exister et laisse à l'organisme l'essentiel des choix quant à leur construction.
La maîtrise des documents et la maîtrise des enregistrements, les deux exigences qu'un système de maîtrise documentaire touche le plus, disposent qu'un document est approuvé, tenu à jour et retiré lorsqu'il est remplacé, et que les enregistrements restent lisibles, accessibles et conservés. Elles ne disent pas comment construire le système qui le fait. La mise en œuvre est laissée à l'organisme, et la plus simple qui satisfasse à l'exigence est généralement la meilleure, car il est possible d'ajouter davantage plus tard, lorsqu'un besoin réel apparaît.
L'écart entre ce que la norme spécifie et ce qu'exige un système opérationnel est plus large qu'il n'y paraît.
La validation du logiciel sur lequel repose un système qualité en est un exemple. La norme la traite brièvement : une approche documentée, proportionnée au risque encouru, le logiciel étant validé avant sa première utilisation puis de nouveau lorsqu'une modification l'impose, et des enregistrements conservés. Elle dit ce qui doit être vrai et laisse la construction à l'organisme. Établir le processus réel a supposé de partir de la manière dont une entreprise avait effectivement procédé et d'ajouter des mécanismes de maîtrise là où ils étaient nécessaires.
Travailler sur l'écosystème Microsoft signifie aussi qu'une large part de ce dont un système qualité a besoin est déjà présente.
La plateforme fournit un enregistrement de qui a créé et modifié chaque élément, un historique des versions et un cadre pour les vues, les formulaires et la collaboration. Une bonne partie de la mécanique qu'exige un SMQ sur le papier vient avec l'environnement, de sorte que le travail consiste à la configurer judicieusement. Maintenir cette couche mince garde le système simple à exploiter, plus simple à valider et rapide à faire évoluer à mesure que les besoins changent.
La même orientation se retrouve dans les décisions plus modestes.
Nous déduisons la nécessité d'une revue de l'attribution ou non d'un réviseur au document. C'était auparavant un paramètre distinct à activer ou à désactiver. Nous l'avons changé parce que ce paramètre distinct constituait une chose de plus à se tromper : un document pouvait être marqué comme exigeant une revue sans qu'aucun réviseur soit nommé, ou l'inverse. Déduire l'étape de l'attribution supprime cette contradiction. S'il y a un réviseur, il y a une revue ; s'il n'y en a pas, il n'y en a pas.
Nous avons renommé l'enregistrement parent. Il s'appelait à l'origine Master Document, et nous avons constaté que le terme prêtait à confusion ; c'est désormais le QMS Document. L'enregistrement n'a pas changé, seul le nom a changé, et un nom que les personnes lisent correctement participe de l'utilisabilité d'un système.
Nous permettons qu'une seule formation couvre plusieurs versions de documents. Lorsque des documents liés changent ensemble, les personnes concernées réalisent une formation unique plutôt qu'une série de formations quasi identiques. Les éléments de preuve de formation restent enregistrés par personne, et la charge de rester formé ne se multiplie pas à chaque petite modification liée.
Aucune de ces décisions ne change ce que le système maîtrise. Chacune change l'effort qu'exige son exploitation correcte, ce qui fait la différence entre un système qualité que les personnes suivent et un système qu'elles contournent.
Ce que cela montre
Suivi d'un bout à l'autre, un système électronique de management de la qualité construit sur l'ISO 13485 soutient les trois domaines de maîtrise exposés par la partie 1, au fil du travail ordinaire.
Une seule version est en vigueur et disponible. La version remplacée est conservée et non écrasée, et peut être retrouvée. Les signatures sont rattachées à une personne nommément identifiée, et la piste se crée au fil du travail. Là où une modification appelle une formation, l'enregistrement montre une réussite ou un échec au regard d'un seuil défini plutôt qu'une seule confirmation de lecture et de compréhension.
La validation du logiciel appartient à l'organisme, et un système simple à décrire est plus simple à valider.
Cette présentation couvre la maîtrise des documents, des enregistrements et de la formation. D'autres parties de l'audit, telles que les actions correctives et préventives, le traitement des réclamations et la revue de direction, se situent en dehors de ce qui est décrit ici. La manière dont un système s'étend pour les couvrir constitue un sujet distinct, sur lequel nous reviendrons.
Questions fréquentes
Comment QMLogic eQMS maîtrise-t-il la version d'un document en vigueur ?
Par une diffusion maîtrisée. Lorsqu'une nouvelle version entre en vigueur, la version qu'elle remplace est automatiquement marquée obsolète. Une seule version est en vigueur à tout moment, de sorte que le document courant ne prête jamais à doute.
Que se passe-t-il dans QMLogic eQMS lorsqu'un document est mis à jour ?
Il est automatiquement marqué obsolète au moment où la nouvelle version entre en vigueur, et conservé comme enregistrement aux côtés de l'enregistrement d'approbation qui l'a diffusé. Rien n'est écrasé. Le système conserve et restitue les versions remplacées ; la durée de leur conservation et les personnes autorisées à supprimer quoi que ce soit sont définies par l'organisme selon les règles de conservation qui lui sont applicables.
Comment QMLogic eQMS traite-t-il les signatures électroniques ?
Chaque action de signature est confirmée par un Signature PIN personnel, une signature électronique simplifiée définie par la personne elle-même et destinée à n'être connue que d'elle, assortie à chaque utilisation d'une déclaration de responsabilité. Cela rattache chaque signature à une personne nommément identifiée.
D'où provient la piste d'audit de diffusion dans QMLogic eQMS ?
Elle est produite par le travail ordinaire. Chaque diffusion crée un enregistrement d'approbation en lecture seule indiquant qui a soumis, revu et approuvé le document, et à quelle date. Les questions soulevées pendant la diffusion sont enregistrées comme consultations conservées avec la diffusion ; la personne qui en a soulevé une peut la supprimer tant qu'elle est sans réponse, et dès lors que des réponses existent, elle ne peut plus qu'être clôturée. L'étendue de la journalisation de l'environnement et sa durée dépendent de sa configuration.
Toute modification de document exige-t-elle une nouvelle formation ?
Non. Décider de ce qu'exige une modification relève du jugement de l'organisme, consigné au titre de son propre système qualité. Dans le logiciel, une révision du document donne lieu à une nouvelle version maîtrisée, et là où une formation est requise et configurée, la diffusion la crée ou l'attribue. La modification d'une valeur partagée ou d'un renvoi peut se traiter de manière centralisée dans le Content Manager, qui indique quels documents ne correspondent plus et peut propager la nouvelle valeur vers les versions au statut Draft. Il ne peut pas modifier une version en vigueur, obsolète ou engagée dans une diffusion.
Quels éléments de preuve de formation QMLogic eQMS produit-il ?
Une formation de type Questionnaire demande à une personne de répondre à des questions au regard d'un seuil de réussite, le nombre de bonnes réponses requis sur le total. Une personne qui reste en dessous du seuil suit à nouveau la formation. L'enregistrement est une réussite ou un échec au regard de ce seuil, plutôt que les réponses individuelles. Il va plus loin qu'une confirmation de lecture et de compréhension, et il constitue un élément contribuant à la compétence plutôt qu'une preuve de celle-ci à lui seul.
Un eQMS doit-il être validé pour le MDSAP ?
Oui. L'Audit Approach du MDSAP attend que le logiciel utilisé dans le système de management de la qualité soit validé pour son utilisation prévue, y compris lorsqu'il est acquis auprès d'un fournisseur plutôt que développé en interne. Le fournisseur peut fournir ce sur quoi une validation s'appuie ; l'organisme définit sa propre utilisation prévue, décide à l'avance de ce que constitue un résultat satisfaisant, exécute le protocole sur sa propre configuration et conserve les enregistrements. Ce qui est validé est le système configuré, y compris les flux de travail, les autorisations, les connexions, les paramètres de signature, la journalisation et la conservation, avec une revalidation lorsqu'une modification le justifie.
L'utilisation d'un eQMS conforme rend-elle notre système qualité conforme ?
Non. La conformité appartient à l'organisme. Un auditeur examine la manière dont le fabricant utilise le système, y compris la question de savoir s'il a été validé pour l'usage qu'il en fait. Aucun produit ne peut transférer la conformité.
