Par Cyrille MICHAUD , le vendredi 11 novembre 2022 à 13h24
C’est un peu comme la sortie du nouvel album de votre groupe préféré. Vous l’attendiez depuis des années. Enfin, il est sorti ! Allez-vous être impressionné ou déçu ?
Le projet de recommandations de la FDA concernant l’assurance des logiciels informatiques (Computer Software Assurance – CSA) pour les logiciels des systèmes de production et de qualité a été publié en septembre 2025. Trois ans après la version draft. Enfin !
Premièrement, ce guide ne concerne ni les logiciels utilisés comme dispositifs médicaux (SaMD, également appelés logiciels autonomes pour dispositifs médicaux), ni les logiciels intégrés aux dispositifs médicaux (SiMD, également appelés logiciels embarqués).
Il porte sur les logiciels utilisés dans les processus de systèmes de management de la qualité (SMQ) et les processus de production. Il traite de l’exigence 21 CFR 820.70(i). Du point de vue de la norme ISO 13485, il aborde les clauses 4.1.6 et 7.5.6.
La raison de la publication de ce guide est expliquée dans la section « Contexte » . L’utilisation de logiciels pour automatiser la réalisation ou le suivi des processus est très courante. La FDA a jugé nécessaire de compléter la section 6 du guide existant sur les principes généraux de validation des logiciels (General Principles of Software Validation – GPSV). Il est vrai que ce guide, publié en 2002, est à la longue, obsolète. Il est quelque peu vague quant au processus de validation à établir. Les fabricants devaient se référer à d’autres guides, tels que l’AAMI TIR 36 ou la norme IEC/TR 82002-2, pour définir leurs procédures de validation des logiciels SMQ.
Bien que les lignes directrices de la FDA contiennent de nouvelles recommandations, les lignes directrices de l’AAMI et de l’IEC restent pertinentes. Ce guide de la FDA peut être considéré comme un complément d’information sur la validation des logiciels de systèmes de management de la qualité (SMQ) afin de garantir leur conformité aux exigences réglementaires.
Une section intitulée « Définitions » clarifie les concepts de cloud computing, SaaS, IaaS et PaaS. Ces définitions sont importantes pour comprendre les discussions dans les parties suivantes du document.
La FDA précise notamment que ces logiciels peuvent faire partie d’un système de gestion de la qualité et entrer ainsi dans le champ d’application des logiciels à évaluer en vue de leur validation. De même, et sans surprise, la FDA inclut les systèmes d’intelligence artificielle dans ce champ d’application.
À l’inverse, la FDA précise également que ces logiciels peuvent ne pas faire partie d’un système de management qualité et ne pas entrer dans le champ d’application des logiciels à valider. Il s’agit d’un discours récurrent de la FDA dans ce document. Certains logiciels ne nécessiteront pas de validation car ils ne relèvent pas du champ d’application du SMQ.
Nous retrouvons un exemple de Saas dans la dernière section de ce guide, illustrant l’importance de prendre en compte ces systèmes dans le processus CSA.
Ce guide CSA est assez similaire au guide sur les logiciels pour dispositifs médicaux. Il exige :
C’est là que tout commence, comme pour les logiciels de dispositifs médicaux (MDSW).
Vous pouvez utiliser un logiciel de gestion de la qualité (e-QMS) pour enregistrer vos réclamations clients et vous y fier exclusivement. Toutefois, vous pouvez continuer à conserver des enregistrements papier, en utilisant ce logiciel uniquement pour des raisons pratiques. Même logiciel, usages différents : l’approche de la CSA sera également différente.
Logiquement, le guide précise également que l’article 820.70(i) du titre 21 du CFR ne s’applique pas aux logiciels qui ne sont ni directement utilisés en production, ni ne contribuent à la production ou au SMQ. Autrement dit, aux logiciels qui ne font pas partie du champ d’application de votre SMQ.
Étonnamment, le projet de guide cite un logiciel destiné à assurer la continuité des activités comme exemple de ce type de logiciel. Attention à cet exemple ! La conservation des enregistrements SMQ par un tel logiciel fera que l’article 820.70(i) du titre 21 du CFR est applicable.
Les nouvelles recommandations (qui ne sont pas si nouvelles, cette approche étant déjà appliquée par les fabricants à partir de la version draft de 2023 de ce guide) découlent d’une approche fondée sur les risques. Cette approche repose sur l’utilisation prévue du logiciel.
On retrouve ici une approche similaire à celle adoptée pour les logiciels de dispositifs médicaux dans le guide FDA relatif au contenu des dossiers de pré-commercialisation des fonctions logicielles de dispositif médical ; une approche à deux niveaux :
Il est à noter que la notion de faible risque n’apparaît pas dans les recommandations.
Cela ressemble à ce que le guide FDA préconise pour les logiciels de dispositifs médicaux : une approche à deux niveaux fondée sur l’utilisation prévue de la fonction du logiciel médical.
On assiste ici à l’émergence d’un nouveau paradigme (ou d’une nouvelle mode) avec cette approche binaire de tous les types de logiciels par la FDA.
Finies les classifications en trois niveaux de préoccupation : majeur, modéré et mineur !
Le guide insiste également sur la manière dont les risques doivent être gérés. Les organisations doivent déterminer quelles défaillances sont raisonnablement prévisibles (par opposition à probables). On constate une différence de traitement entre les risques liés aux logiciels de dispositifs médicaux et ceux liés aux logiciels de production ou de systèmes de management de la qualité.
En résumé :
Une approche similaire, basée sur la gravité et la fréquence et inspirée de la norme ISO 14971, peut être utilisée pour évaluer les risques liés aux logiciels de production ou de SMQ.
En prenant la défaillance du logiciel de SMQ / production comme étape initiale de la séquence d’événements, on peut établir plusieurs séquences en fonction de l’utilisation prévue :
Avec un logiciel de SMQ :
Avec les logiciels de production :
Ou logiciel de support technique :
Le guide s’appuie également sur le principe des mesures d’atténuation pour réduire le profil de risque des logiciels de production et des systèmes de management de la qualité (SMQ).
Il n’est pas nécessaire de mettre en place des mesures d’atténuation matérielles, comme c’est le cas pour la plupart des logiciels embarqués dans les dispositifs électromédicaux. Des contrôles ou mécanismes supplémentaires peuvent être mis en œuvre, à condition qu’ils soient efficaces. Par exemple, la sensibilisation ou la supervision humaine est acceptable (sous réserve de la formation des opérateurs, etc., ce qui est un autre sujet).
Ce type de mesure d’atténuation est similaire à celui accepté par la clause 4.3.a de la norme IEC 62304:2006 + Amd1:2015.
Il est possible de diviser un logiciel en plusieurs modules, fonctionnalités ou fonctions. Chaque fonction peut avoir une utilisation prévue différente, avec un profil de risque différent. Le guide fournit un exemple avec une feuille de calcul. L’exemple d’un ERP est probablement plus pertinent. Un ERP comporte plusieurs modules. Certains ne sont pas des logiciels de gestion de la qualité (comptabilité). D’autres sont des logiciels de gestion de la qualité avec diverses fonctions, comme un module CRM. Si ce module est utilisé pour gérer les réclamations clients, un profil de risque élevé est attendu pour le sous-ensemble de fonctions gérant ces réclamations. Ce n’est pas le cas pour les fonctions gérant d’autres aspects du CRM.
Cette logique est similaire au guide FDA « Produits multifonctionnels : politiques et considérations ».
Le guide ne contient aucune précision concernant les logiciels sur mesure, c’est-à-dire les logiciels développés en interne ou sous-traités à une société de développement logiciel.
Il n’est fait aucune mention de la qualification de conception, une étape pourtant courante dans les procédures de validation des logiciels des systèmes de management de la qualité (SMQ). Une solution pratique pour les logiciels sur mesure consiste à suivre un cycle de vie de développement logiciel similaire à celui de la norme IEC 62304 classe A.
Le guide fournit des exemples de logiciels à haut risque et de logiciels à faible risque. La liste des enregistrements pour les logiciels à haut risque est très similaire à celle exigée par la clause 5.7 de la norme IEC 62304.
Cependant, certaines différences existent pour les logiciels à faible risque. La FDA accepte des plans et des rapports de test réduits, voire très abrégés. Elle utilise l’expression « tests non scénarisés » , ce qui est prohibé par la norme IEC 62304.
Le guide aborde également les différents types de stratégies de test. Il est courant d’utiliser des tests scénarisés robustes pour les logiciels à haut risque, des tests scénarisés limités pour les logiciels à risque modéré et des tests non scénarisés pour les logiciels à faible risque. Ces stratégies de test sont fournies à titre informatif. Il n’y a pas lieu de s’inquiéter si vous ne les utilisez pas et que vous avez une stratégie qui est proportionnelle au risque.
Vous ne trouverez pas ces concepts dans ce guide. Inutile de masquer votre processus de validation logicielle derrière une procédure QI/QO/QP modifiée, couramment utilisée pour les équipements matériels ! La plupart des procédures de validation utilisent cet artefact QI/QO/QP. C’est un moyen facile de satisfaire les auditeurs peu versés dans le logiciel (ce genre de procédure a tendance à disparaître).
Grâce à ce guide de la FDA, nous pouvons élaborer un plan de test logiciel et un rapport de test logiciel classiques, en nous débarrassant de ce monstre qu’est la QI/QO/QP !
Le guide rappelle que certaines données (la plupart des données) traitées/stockées par le système de gestion de la qualité/le logiciel de production sont des enregistrements électroniques au sens de la partie 11 du titre 21 du CFR. Ce guide donne comme indication d’utiliser une approche basée sur les risques pour valider les fonctions logicielles relevant du champ d’application de la partie 11.
Nous retrouvons cette recommandation à deux reprises :
Il ne faut pas hésiter à modérer ses efforts relatifs à l’élaboration d’un protocole de validation conforme à la partie 11, suivant l’approche basée sur les risques préconisée par la FDA. En utilisant des tests de scripts robustes et une matrice de traçabilité détaillée pour un risque élevé, et quelque chose de plus simple pour un risque faible.
Tout en reconnaissant que les fabricants peuvent avoir un accès limité aux informations fournies par le fournisseur de logiciels dans le cadre d’une évaluation, la FDA recommande d’évaluer les capacités des fournisseurs à l’aide de méthodes telles que : audits, examen des accréditations ou certifications, examen de leurs pratiques de développement logiciel, etc.
Comme pour toute autre tâche présentée dans ces recommandations, l’évaluation des fournisseurs de logiciels doit s’appuyer sur une approche fondée sur les risques.
Exploitation des enregistrements numériques
La FDA recommande également d’exploiter tout enregistrement numérique existant provenant d’un système logiciel. Par exemple : journaux système, pistes d’audit…
Contrairement aux documents papier et aux captures d’écran traditionnels (qui restent toutefois utiles), la FDA accepte ces enregistrements numériques comme preuves de validation.
Les fabricants peuvent tirer parti de la traçabilité automatisée, des tests et de la saisie électronique des travaux effectués pour documenter les résultats, ce qui réduit le besoin de documentation manuelle ou papier. Cette recommandation participe à la simplification du processus de validation des logiciels SMQ.
Ce guide propose une approche clairement moins contraignante qu’auparavant ! Le précédent guide GPSV laissait le fabricant dans l’incertitude quant à l’étendue de la validation à effectuer pour différents profils de risque des systèmes de gestion de la qualité et des logiciels de production. De plus, les normes AAMI TIR 36 et IEC/TR 82002-2 ne précisaient pas la position de la FDA.
Grâce à ce nouveau guide, nous savons que nous pouvons limiter les validations pour les logiciels à faible risque et utiliser les deux autres guides AAMI TIR 36 et IEC/TR 82002-2 comme sources d’information pour la validation des logiciels à haut risque.
L’intelligence artificielle est toutefois peu abordée dans ce guide. À quand une nouvelle version intégrant des recommandations pour la validation de logiciels SMQ incorporant de l’IA ?
