Cahier Pratique – Évaluation des fournisseurs en SI (Systèmes Informatisés)

Les textes réglementaires les plus récents mettent en évidence le rôle crucial des fournisseurs de produits et services informatiques dans la conformité réglementaire des systèmes informatisés et la nécessité de leur évaluation préalable et continue.

Devant la complexité et les modifications du paysage informatique actuel (externalisation d’infrastructure, logiciels fournis en mode SaaS – Software as a Service-…), comment évaluer au mieux et à moindre coût ces fournisseurs dont les référentiels qualité sont souvent éloignés de nos textes réglementaires ?

Une approche basée sur le respect des textes réglementaires applicables et privilégiant une approche d’évaluation basée sur le risque permet de dégager une méthode applicable à tous les types de fournisseurs de produits et/ou de services informatiques : éditeur de logiciel, intégrateur de solutions, société réalisant de la Tierce Maintenance Applicative (TMA), hébergeur d’infrastructure informatique ou de solutions, fournisseurs de logiciel SaaS, fournisseur de services de validation…

Le contexte réglementaire
En considérant l’annexe 11 des Bonnes Pratiques de Fabrication (1) comme premier référentiel sur ce sujet, celle-ci précise dans son article 3.2 que “ La compétence et la fiabilité d’un fournisseur sont des facteurs essentiels à prendre en compte lors de la sélection d’un produit ou d’un prestataire de service. La nécessité d’un audit doit être basée sur une évaluation du risque.”

Puis dans l’article 3.4 : “Les informations relatives au système qualité et à l’audit des fournisseurs ou des développeurs de logiciels ainsi que les systèmes installés doivent être disponibles, à la demande des inspecteurs de l’agence chargée de l’évaluation de la conformité aux BPF.”

Enfin, un peu plus loin, dans l’article 4.5, il est précisé : “L’utilisateur soumis à la réglementation pharmaceutique doit prendre toutes les mesures raisonnables permettant de s’assurer que le système informatisé a été développé conformément à un système approprié de gestion de la qualité. Le fournisseur doit être évalué de manière adéquate.”

Le document du PIC/S (PI011(2)) qui est en partie à l’origine de la révision de l’annexe 11, donne, quant à lui, les éléments suivants :
“5.1 : The assurance of the reliability of a Supplier’s software products is attributable to the quality of the software engineering processes followed during development…In order for customers to have confidence in the reliability of the products, they should evaluate the quality methodology of the supplier for the design, construction, supply and maintenance of the software…This should be documented in a Supplier Audit Report.”

Ce guide mentionne également les certifications dont peut disposer un fournisseur sans toutefois y accorder une importance majeure :
“11.4 : Confidence in the structural integrity may be based to some extent on the recognition of relevant certification of a company’s software and hardware development methodology and QMS to ISO 9001 standard, such as (for example) TickIT certification and utilisation of ISO 9000 related guidance.
11.5 : However, an assessment of the supplier’s QMS and recognised certification alone is unlikely to be the final arbiter for critical systems. The certification may very well be inadequate, or inappropriate.”

Des référentiels annexes (3) donnent des éclairages intéressants sur les attendus des évaluations fournisseurs :
“29. For vendor-supplied systems it is likely that much of the documentation created during the development is retained at the vendor’s site. In this case, evidence of formal assessment and/or vendor audits should be available at the test facility.
32. Suppliers need not conform to GLP regulations, but must operate to a documented quality system verified as acceptable by the quality assurance unit of the regulated user. The test facility should have proper documentation or regulate by contract if documentation is kept at the vendor’s site.”

Ce document se penche sur une tendance forte du marché qui est l’hébergement de solutions et des risques associés :
“33. Hosted services (e.g. platform, software, archiving, backup or processes as a service) should be treated like any other third party service and require written agreements. It is the responsibility of the regulated user to evaluate the relevant service and to estimate risks to data integrity and data availability. The regulated user should be aware of potential risks resulting from the uncontrolled use of hosted services.”

Enfin l’évaluation des risques est privilégiée :
“36. Efforts in evaluating a service provider should be linked to the complexity and criticality of a system (e.g. a LIMS or any bespoke software provided from external sources might need greater attention). It is the regulated user’s responsibility to justify the type of the audit of a service provider or the omission of an audit, based on a risk assessment. An audit that covers technical as well as compliance issues requires the involvement of competent validation personnel (e.g. system owner and/or validation director) and quality assurance.”

Enfin un document récent de l’OMS(4) sur la “data integrity” donne des indications intéressantes sur l’aspect contractuel et les qualifications nécessaires des auditeurs :
“To fulfill this responsibility (for the integrity of all results reported), …outsourcing organizations should verify the adequacy of comparable systems at the contract acceptor and any significant authorized third parties used by the contract acceptor.”
“The personnel who evaluate and periodically assess the competence of a contracted organization or service provider should have the appropriate background, qualifications, experience and training to assess data integrity governance systems and to detect validity issues. The evaluation and frequency and approach to monitoring or periodically assessing the contract acceptor should be based upon documented risk assessment that includes an assessment of data processes.”
“The expected data integrity control strategies should be included in quality agreements and written contract and technical arrangements, as appropriate and applicable, between the contract giver and the contract acceptor.”

Il ressort de ces principaux textes que l’évaluation des fournisseurs informatiques de tout type est considérée comme nécessaire mais que celle-ci doit se réaliser en tenant compte du risque et de la complexité du système sur lequel ces fournisseurs peuvent intervenir aux différentes phases de son cycle de vie.
L’aspect contractuel est fondamental et implique également une évaluation des risques encourus avant contractualisation, ce qui se traduit généralement par un audit ou “due diligence” dans les cas les plus critiques (externalisation d’infrastructure par exemple).

Les démarches d’évaluation
Les démarches d’évaluation fournisseurs s’inscrivent généralement dans un processus d’audit externe dont disposent la plupart des industriels réglementés ; toutefois, le standard industriel GAMP 5(5) définit une démarche d’évaluation à dimension variable en fonction du niveau du système considéré :

 

Systèmes Informatisés : Tab 1

 

Par ailleurs, ce document préconise l’utilisation d’un audit postal, c’est à dire l’envoi d’un questionnaire succinct permettant, à partir des réponses fournies, d’évaluer la qualité du fournisseur considéré. Cette méthode, si elle a l’avantage d’un moindre coût, ne peut à elle seule être suffisante dans le cas d’un système critique car elle ne se base que sur des affirmations du fournisseur vérifiables que par un audit sur site.

La norme ISO 19011(6) propose une démarche structurée et rationnelle de l’évaluation des systèmes de management au sens large ; elle intègre la démarche d’audit dans un processus coordonné aux autres processus qualité de l’entreprise et insiste particulièrement sur l’amélioration continue du programme d’audit, la nécessaire compétence des auditeurs et la démarche d’évaluation basée sur des critères d’audit objectifs qui doivent être la référence vis-à-vis de laquelle les preuves d’audit sont évaluées.

Pour une entreprise réglementée, ce processus d’évaluation doit avant tout être intégré dans l’ensemble du cycle vie d’un système informatisé depuis la phase de recherche de solution (Request For Proposal ou RFP) jusqu’au retrait (“decommissioning”) du système.

 

Systèmes Informatisés schéma

 

Sur le diagramme ci-dessous, on constate que le processus d’évaluation d’un fournisseur peut être réalisé aux différentes phase du cycle de vie d’un système : l’appel d’offres généralement associé à un cahier des charges peut être suivi d’un audit sur site, puis lors de la mise en oeuvre du système, des audits peuvent être réalisés notamment dans les phases projet, puis sur un système en production en cas de dysfonctionnements ; enfin, dans le cadre des revues périodiques, des compléments d’évaluation peuvent s’avérer nécessaires sur certains points (cas des hébergeurs de solutions notamment).

On voit ainsi que ces évaluations multiples revêtent des motivations différentes et d’approches variables mais que celles-ci ont toutes pour objectif d’approfondir la connaissance des pratiques des fournisseurs de façon à en limiter les risques sur les systèmes et processus du client réglementé.

Systèmes Informatisés schéma 2

 

En pratique
Une des difficultés rencontrées dans l’évaluation des fournisseurs de produits et/ou services informatiques consiste dans le caractère technique de certaines prestations (développement informatique, gestion d’infrastructure…) mais également des différences non négligeables entre les référentiels connus des auditeurs des sociétés réglementées (BPx…) et les référentiels adoptés par ces fournisseurs.

En effet, ceux-ci disposent de plusieurs référentiels à géométrie variable et dont l’intérêt reste à vérifier en fonction des activités réalisées ; citons notamment :

• NF EN ISO 9001 : Systèmes de management de la qualité – Exigences (version 2015)
• FD Z67-910 Décembre 1998 : Ingénierie et qualité du logiciel – Introduction au référentiel ISO/SPICE (ISO/CEI TR 15504) et à son utilisation pour le management de la qualité des processus du logiciel
• NF ISO/CEI 2000x -1 Juin 2012 : Technologies de l’information – Gestion des services
• NF ISO/CEI 2700x Janvier 2015 : Technologies de l’information – Techniques de sécurité – Systèmes de management de la sécurité de l’information

Enfin ces fournisseurs disposent également de “bonnes pratiques” dont certaines peuvent faire l’objet d’une certification de leur personnel (ITIL, PRINCE2(7) notamment).

La démarche préconisée dans ce cahier pratique consiste donc à tenir compte des exigences applicables tout en préservant une souplesse nécessaire dans l’évaluation des différents types de fournisseurs présents sur le marché, de leurs niveaux d’implication respectifs dans la vie d’un système et enfin de l’importance de l’évaluation basée sur une analyse de risques préalable.

La démarche proposée procède donc par une méthode progressive et itérative qui vise à enrichir progressivement la connaissance du fournisseur ; dans une première phase, généralement lors de la soumission d’un cahier des charges, un questionnaire qualité est envoyé aux différents soumissionnaires pour une évaluation rapide de leur capacité ou niveau de maturité dans les différents processus pour lesquels le client les a sollicités : développement logiciel, support, hébergement…

Ce questionnaire basé sur des questions ouvertes, c’est à dire n’indiquant pas un choix ou une orientation particulière dans la réponse, permet au fournisseur de présenter avec un minimum d’effort et de contraintes, les caractéristiques de son offre de services, de son système qualité…etc.

Ce questionnaire une fois complété par le fournisseur est revu et, en fonction des réponses apportées et du niveau de risque associé au produit/service que l’on souhaite contracter, une décision de qualification ou de disqualification du fournisseur peut être prise ; si des compléments d’information sont nécessaires pour valider certaines réponses, un audit sur site ou à distance (par vidéo conférence) peut être décidé.

Dans ce dernier cas, le processus suivi est similaire à un processus d’audit classique avec l’information au fournisseur d’un agenda détaillé mentionnant l’objectif, le périmètre, les intervenants, les référentiels utilisés et le déroulement chronologique de l’audit.

La préparation de l’audit implique la création d’un référentiel pratique pour l’auditeur, notamment par la formalisation des critères d’audit argumentés qui vont être la référence des observations éventuelles.

Ces observations doivent faire l’objet d’une évaluation de leur criticité au regard du critère d’audit ; il est alors possible de réaliser un profil qualité du fournisseur tenant compte de la valorisation des écarts en critique, majeur et mineur.

Dans la plupart des cas, un plan d’actions correctives proposé par le client sera soumis au fournisseur pour action ; le suivi de ce plan d’actions peut être intégré dans la gestion des CAPA de la société réglementé ou sous-traité au prestataire en charge de l’audit.

Sujet ID QuestionDocument souhaitéRéponse fournisseur
ProduitEL-01Décrire le produit faisant l’objet de la proposition : nom, version proposée, historique des versions
ProduitEL-02Le produit est-il standard (ne requiert aucune configuration), configurable, modifiable par des développement spécifiques ?
ProduitEL-03Le produit est il la propriété de la société depuis sa création ou a-t-il été intégré suite au rachat d’une autre société ?
Produit EL-04Quel part du chiffre d’affaires représente le produit dans le chiffre d’affaires global de la société ?
Produit EL-05Comment ce chiffre d’affaires se décompose -t-il en revenus de licences (vente, location), maintenance applicative, hébergement, services, …
Produit EL-06Le développement du logiciel est-il externalisé (sous-traitance) ?
ProduitEL-07Quelle est la périodicité typique de mise à jour de l’apllication ?
Cycle de vieEL-08A quel méthode générale correspond la méthode de développement utilisée par la société ( cycle en V, agile, …) ?
Cycle de vieEL-09Cette méthode ou cycle de vie est-elle documentée ? Descriptif du cycle de vie

 

Systèmes Informatisés : audit agenda

 

Systèmes Informatisés graphique

 

Systèmes Informatisés : Tab 2

 

Cette approche à la fois simple et pratique permet un enrichissement progressif de la connaissance du fournisseur au travers des différentes phases d’évaluation auxquelles il aura été soumis tout au long de sa relation avec le client.

Il convient toutefois de réactualiser périodiquement cette connaissance par des revues et audits périodiques qui permettent également d’entretenir les échanges sur les pratiques et la confiance nécessaire à un partenariat réussi.

Image par défaut

Michèle LAFAY – PIERRE FABRE

michele.lafay@pierre-fabre.com

Image par défaut

Jean-Louis JOUVE – COETIC

jean-louis.jouve@coetic.com

Partager l’article

LinkedinEnvoyer par mail

Bibliographie

(1) AGENCE NATIONALE DE SÉCURITÉ DU MÉDICAMENT ET DES PRODUITS DE SANTÉ,
Bonnes pratiques de fabrication, Bulletin officiel No2015/12 bis Fascicule spécial http://
social-sante.gouv.fr/IMG/pdf/sts_20150012_0001_p000.pdf
(2) PHARMACEUTICAL INSPECTION COOPERATION SCHEME PI 011-3 25 September
200 http://www.picscheme.org/pdf/27_pi-011-3-recommendation-on-computerisedsystems.
pdf
(3) OECD DRAFT ADVISORY DOCUMENT 161, THE APPLICATION OF GLP PRINCIPLES TO
COMPUTERISED SYSTEMS, September 2014 http://www.oecd.org/chemicalsafety/testing/
Draft-OECD-GLP-Guidance-Document-computerised-systems.pdf
(4) WHO QAS/15.624 GUIDANCE ON GOOD DATA AND RECORD MANAGEMENT
PRACTICES http://www.who.int/medicines/areas/quality_safety/quality_assurance/
Guidance-on-good-data-management-practices_QAS15-624_16092015.pdf
(5) GAMP® 5: A Risk-Based Approach to Compliant GxP Computerized Systems –
February 2008 http://www.ispe.org/gamp-5
(6) ISO 19011:2011 Lignes directrices pour l’audit des systèmes de management,
novembre 2015 http://www.iso.org/iso/fr/catalogue_detail?csnumber=50675
(7) https://www.axelos.com/