Un ERP généraliste gère des commandes, des factures, des stocks. Dans l’industrie des dispositifs médicaux, ces fonctions ne couvrent qu’une fraction du besoin réel. La question n’est pas « quel ERP choisir ? » mais « quel ERP peut prouver, lors d’un audit de l’ANSM ou d’un organisme notifié, que chaque implant, chaque équipement de diagnostic, chaque consommable chirurgical livré est traçable depuis sa matière première jusqu’au patient, que son Dossier Technique est à jour, et que chaque modification de configuration du système a fait l’objet d’une validation documentée ? »
Le Règlement (UE) 2017/745, entré pleinement en vigueur le 26 mai 2021 pour les dispositifs de classe III et implantables (JOUE L 117, 5.5.2017, EUR-Lex), a durci le cadre réglementaire européen : dossiers techniques renforcés, UDI obligatoire, EUDAMED comme registre central, suivi clinique post-marché structuré. Pour un fabricant, ces exigences ne sont pas de simples cases à cocher : elles redessinant l’architecture de son système d’information et, au premier chef, de son ERP.
Pourquoi les dispositifs médicaux ont besoin d’un ERP spécialisé
Dispositif médical vs médicament : deux cadres réglementaires distincts
L’industrie pharmaceutique et celle des dispositifs médicaux sont souvent confondues sous l’étiquette « life sciences ». Leurs cadres réglementaires sont pourtant distincts et leurs exigences sur le système d’information divergent sur plusieurs points clés.
En pharmacie, la conformité pivot est la GMP (Bonnes Pratiques de Fabrication), le 21 CFR Part 11 de la FDA pour les États-Unis et l’Annexe 11 des GMP européennes pour l’Europe. En dispositifs médicaux, le pivot est l’EU MDR 2017/745 côté conformité produit, et ISO 13485:2016 côté système qualité. Ces deux textes ont des implications directes sur ce que l’ERP doit faire nativement.
Autre distinction : là où le médicament est un produit de masse identique par lot, le dispositif médical peut être un implant personnalisé fabriqué à l’unité (classe III) ou un consommable produit à des millions d’exemplaires (classe I). L’ERP doit s’adapter à ces deux extrêmes tout en maintenant une traçabilité sans faille.
Il faut également distinguer deux sous-cadres dans les dispositifs médicaux eux-mêmes : l’EU MDR 2017/745 couvre les dispositifs médicaux classiques (implants, instruments chirurgicaux, équipements d’imagerie diagnostique), tandis que le Règlement (UE) 2017/746 (IVDR) couvre les dispositifs de diagnostic in vitro (tests de laboratoire, réactifs). Ce guide se concentre sur l’EU MDR ; les fabricants d’IVD font face à des exigences similaires avec des délais de transition différents.
Les cinq obligations EU MDR 2017/745 qui impactent directement l’ERP
Le Règlement (UE) 2017/745 impose cinq obligations qui affectent directement le périmètre fonctionnel de l’ERP :
- Identification unique des dispositifs (UDI) : chaque dispositif mis sur le marché de l’UE doit porter un identifiant unique (Article 27) et ses données doivent être enregistrées dans EUDAMED.
- Dossier Technique (DT) : le fabricant doit constituer et maintenir un dossier technique complet (Annexe II) incluant la description du dispositif, sa conception, sa fabrication et son évaluation clinique.
- Système de management de la qualité (QMS) : le fabricant doit mettre en place un QMS documenté (Article 10(9)) couvrant l’ensemble du cycle de vie du dispositif.
- Suivi post-marché (PMS) : collecte et analyse systématique des données post-marché avec rapports périodiques de sécurité (PSUR) et mise à jour du dossier technique.
- Traçabilité des dispositifs implantables : les établissements de santé implantant des dispositifs de classe III doivent conserver les données UDI dans le dossier patient (Article 27(7)).
ISO 13485 : le système de management qualité spécifique medtech
ISO 13485:2016 est la norme internationale de référence pour les systèmes de management de la qualité dans l’industrie des dispositifs médicaux (ISO, ISO 13485:2016). Elle a remplacé la version 2003 et s’aligne sur les exigences de l’EU MDR et de la FDA 21 CFR Part 820 (Quality System Regulation).
La certification ISO 13485 n’est pas obligatoire au sens strict de l’EU MDR, mais elle constitue une présomption de conformité aux exigences qualité de l’Article 10. En pratique, tous les fabricants sous EU MDR travaillent avec un organisme notifié certifié ISO 17065, qui vérifie la conformité ISO 13485 comme prérequis à la certification CE.
Les sections de la norme les plus impactantes pour l’ERP sont :
- Section 4.2 : Exigences de documentation — l’ERP ou son DMS intégré doit gérer les niveaux documentaires (politique qualité, procédures, enregistrements)
- Section 7.3 : Conception et développement — nécessite un contrôle des modifications documenté, que l’ERP doit refléter dans son module Change Control
- Section 7.5 : Production et prestation de service — traçabilité des matières premières, gestion des équipements de mesure, contrôle de la non-conformité
- Section 8.5.2 : Actions correctives et préventives (CAPA) — workflow CAPA documenté avec enregistrements dans l’ERP
UDI (Unique Device Identification) : traçabilité obligatoire dans l’ERP
Structure d’un UDI : DI (Device Identifier) et PI (Production Identifier)
L’UDI est composé de deux éléments complémentaires, tous deux à gérer dans l’ERP :
- DI (Device Identifier) : identifie la catégorie de produit. Il est fixe pour un modèle donné et un même fabricant. Il est attribué par un organisme émetteur agréé (GS1, HIBCC, ICCBBA) et enregistré dans EUDAMED. Le DI est l’équivalent du GTIN dans la nomenclature GS1.
- PI (Production Identifier) : identifie une instance de production spécifique. Il contient, selon le type de dispositif, le numéro de lot (LOT), le numéro de série (SN), la date de fabrication et la date de péremption. Le PI est généré dynamiquement à la fabrication.
Dans l’ERP, le DI est typiquement géré comme un attribut de la fiche article, tandis que le PI est généré et tracé au moment de la production ou du conditionnement. L’UDI complet (DI + PI) doit figurer sur l’étiquette du dispositif sous forme lisible et sous forme de code Datamatrix 2D (ou code-barres linéaire pour certains dispositifs de classe I).
EUDAMED : la base de données EU et comment l’ERP alimente le registre
EUDAMED (European Database on Medical Devices) est la plateforme centralisée de la Commission européenne qui agrège les données sur les dispositifs médicaux mis sur le marché de l’UE (EUDAMED, Commission européenne). Le fabricant doit y enregistrer ses DI avant la mise sur le marché.
L’obligation d’enregistrement des UDI/DI dans EUDAMED suit le calendrier de mise en oeuvre de l’EU MDR, tel que défini à l’Article 123(3)(f) du règlement :
- Classe III et dispositifs implantables : depuis le 26 mai 2021
- Classe IIa et IIb : depuis le 26 mai 2023
- Classe I : depuis le 26 mai 2025
Dans la pratique, l’ERP doit être capable d’exporter les données produit au format attendu par EUDAMED (import via API REST ou fichier CSV structuré). Cette interface n’est pas native dans tous les ERP : elle nécessite souvent un développement spécifique ou un middleware de transformation de données.
Traçabilité lot-to-patient : pourquoi l’ERP doit tracer chaque composant
Pour les dispositifs implantables, l’EU MDR Article 27(7) impose que l’identifiant UDI figure dans le dossier médical du patient. Cette exigence crée une chaîne de traçabilité que l’ERP doit supporter de bout en bout : de la réception de la matière première jusqu’à l’hôpital destinataire.
Concrètement, un ERP medtech doit permettre de répondre en quelques minutes à deux questions critiques :
- Traçabilité descendante : quels patients ont reçu des dispositifs contenant le lot de composant X rappelé par mon fournisseur ?
- Traçabilité ascendante : dans quelles matières premières a été fabriqué l’implant Y livré à l’hôpital Z le 15 mars dernier ?
Cette traçabilité bidirectionnelle n’est pas simplement une exigence réglementaire : c’est une capacité opérationnelle critique en cas de Field Safety Corrective Action (FSCA).
Configuration UDI dans les principaux ERP industriels
Les ERP industriels positionnés life sciences ont intégré la gestion UDI dans leurs modules dédiés :
- SAP S/4HANA : la gestion UDI est couverte par le module SAP Extended Warehouse Management (EWM) combiné à SAP Batch Management. SAP propose des templates de configuration pré-validés via son Industry Cloud for Life Sciences.
- Oracle Cloud ERP : l’intégration UDI passe par Oracle Product Information Management (PIM) pour le DI et Oracle Manufacturing Cloud pour la génération des PI en production.
- Infor LN : la traçabilité lot et sériel est native dans Infor LN Manufacturing, qui propose un module Quality Management certifiable ISO 13485.
Dossier Technique (DT) et gestion documentaire dans l’ERP
Contenu obligatoire du Dossier Technique EU MDR
L’Annexe II de l’EU MDR 2017/745 définit le contenu du Dossier Technique. Il comprend : la description et la spécification du dispositif, les informations de conception et de fabrication, les exigences générales de sécurité et de performance (GSPR), l’analyse bénéfice-risque, la vérification et la validation produit, et l’évaluation clinique.
Ce dossier doit être maintenu et mis à jour tout au long du cycle de vie du dispositif. Toute modification significative de conception, de matériau ou de procédé de fabrication nécessite une révision documentée et une évaluation de l’impact réglementaire.
Gestion des versions et révisions dans l’ERP
L’ERP doit gérer un système de contrôle documentaire strict : chaque document dispose d’un numéro de version, d’une date d’approbation, d’une liste de diffusion contrôlée et d’un historique de révision. Les documents obsolètes doivent être retirés de l’accès opérationnel tout en restant archivés.
La durée minimale de conservation est définie à l’Article 10(8) de l’EU MDR : au moins la durée de vie du dispositif, avec un minimum de 10 ans après la mise sur le marché du dernier dispositif fabriqué (15 ans pour les dispositifs implantables). Pour les implants à durée de vie indéterminée, cela peut représenter des contraintes d’archivage sur 20 à 30 ans.
Lien avec le PLM : ERP seul ou ERP + PLM ?
Pour les fabricants de dispositifs complexes (implants actifs, équipements d’imagerie, robots chirurgicaux), la gestion de la conception et du Dossier Technique dépasse souvent les capacités d’un ERP standard. Un PLM (Product Lifecycle Management) — Siemens Teamcenter, PTC Windchill, ou Dassault Systèmes ENOVIA — prend en charge la partie conception, tandis que l’ERP gère la fabrication, les stocks et les ventes.
L’interface entre PLM et ERP est critique : une modification de nomenclature validée dans le PLM doit se propager automatiquement dans l’ERP sans ressaisie manuelle. Cette intégration bidirectionnelle doit être incluse dans le périmètre du projet ERP dès le départ, avec une validation GAMP 5 de l’interface elle-même.
Pour les PME-ETI fabriquant des dispositifs moins complexes (classe I ou IIa), un ERP avec module DMS (Document Management System) intégré peut suffire, à condition que ce module supporte le versioning, le contrôle d’accès documentaire et l’archivage long terme.
Contrôle des modifications (Change Control) : workflow dans l’ERP
Le Change Control est le processus formel d’évaluation, d’approbation et de documentation de toute modification affectant le produit, le procédé ou le système qualité. En environnement EU MDR, ce processus doit suivre une séquence tracée dans l’ERP :
- Demande formelle (Change Request) avec description de la modification proposée
- Évaluation par un responsable qualité pour l’impact réglementaire (re-certification nécessaire ?)
- Approbation par les fonctions pertinentes (R&D, production, qualité, affaires réglementaires)
- Mise en oeuvre selon un plan de vérification et de validation documenté
- Clôture avec preuve d’efficacité et mise à jour du Dossier Technique
L’ERP doit supporter ce workflow avec des enregistrements non modifiables après clôture et un audit trail de chaque étape d’approbation.
Gestion des non-conformités et des rappels produits
CAPA (Corrective and Preventive Action) dans l’ERP : workflow standard
Le système CAPA est le coeur opérationnel de l’ISO 13485:2016 (section 8.5.2). Tout incident, non-conformité produit ou réclamation client doit déclencher une analyse de cause racine documentée et un plan d’action corrective et préventive, tracé dans l’ERP.
Un workflow CAPA standard dans l’ERP medtech comprend :
- Enregistrement de la non-conformité (source : production, client, audit interne)
- Analyse de la cause racine (méthode Ishikawa, 5 Pourquoi, ou autre méthode documentée)
- Définition des actions correctives et préventives avec responsables et délais
- Mise en oeuvre et suivi
- Vérification de l’efficacité avec critères mesurables
- Clôture avec enregistrement immuable
Matériovigilance : signalement des incidents graves à l’ANSM
L’EU MDR Article 87 impose au fabricant de signaler à l’autorité compétente nationale (ANSM en France, BfArM en Allemagne, MHRA au Royaume-Uni) tout incident grave ou toute Field Safety Corrective Action (FSCA) dans les délais définis : 15 jours pour la plupart des incidents graves, 2 jours pour les incidents mettant immédiatement en jeu la vie du patient.
L’ERP doit permettre d’identifier rapidement l’étendue d’un incident : quels lots sont concernés, quelle est la quantité mise sur le marché, quels distributeurs et hôpitaux ont été livrés. Cette capacité de réponse rapide est directement liée à la qualité de la traçabilité lot-to-client dans le système.
Rappel de lot et Field Safety Corrective Action (FSCA)
Le FSCA est l’action corrective déclenchée par le fabricant sur les dispositifs déjà mis sur le marché pour réduire un risque de blessure ou de décès. L’ERP doit permettre de localiser rapidement tous les dispositifs d’un lot donné et de générer automatiquement les listes de destinataires par client, par hôpital ou par distributeur.
La rapidité de cette réponse n’est pas seulement une obligation réglementaire : elle est un impératif éthique et commercial. Un fabricant incapable de localiser ses produits dans les heures suivant la détection d’un incident risque une mise en demeure réglementaire et une dégradation durable de sa réputation auprès des acheteurs hospitaliers.
Validation informatique GAMP 5 : que valider et comment ?
Les cinq catégories GAMP 5 et où se situe un ERP
GAMP 5 (Good Automated Manufacturing Practice, 5e édition, ISPE) est le référentiel de validation des systèmes informatisés utilisés en environnement réglementé GxP et, par extension, en environnement ISO 13485. Il classe les logiciels en cinq catégories selon leur niveau de complexité et de risque (ISPE, GAMP 5 Guide) :
- Catégorie 1 : Infrastructures (systèmes d’exploitation, machines virtuelles) — validation allégée sur l’infrastructure
- Catégorie 3 : Logiciels non configurés à usage fixe
- Catégorie 4 : Logiciels configurés — c’est ici que se situe la majorité des ERP standard déployés avec des paramètres métier spécifiques. La validation porte sur la configuration, pas sur le code source.
- Catégorie 5 : Logiciels sur mesure ou modules personnalisés — code source développé spécifiquement, validation exhaustive requise
Un ERP standard comme SAP S/4HANA ou Oracle Cloud déployé avec des paramètres métier est typiquement catégorie 4. Les modules de connecteurs ou développements spécifiques (interface EUDAMED, générateur UDI, formulaires personnalisés) peuvent être catégorie 5 et nécessitent une validation plus rigoureuse portant sur le code source.
Plan de validation du système informatisé (VSI) : documents obligatoires
La validation d’un ERP en environnement ISO 13485 et GAMP 5 repose sur un corpus documentaire structuré :
- Validation Plan : périmètre de la validation, approche risque-bénéfice, ressources, calendrier
- User Requirements Specification (URS) : exigences utilisateur fonctionnelles et non fonctionnelles
- Functional Specification (FS) : comment le système répond aux URS
- Design Specification (DS) : architecture technique, configuration
- Traceability Matrix : matrice de traçabilité URS/FS/Tests
- Test Scripts IQ/OQ/PQ : protocoles de test détaillés
- Validation Summary Report : synthèse des tests, non-conformités et acceptation formelle
Tests IQ/OQ/PQ : installation, opérationnelle, performance
Les tests de validation suivent trois niveaux :
- IQ (Installation Qualification) : vérifie que le système est installé correctement (version logicielle, paramètres d’infrastructure, intégrité des données de configuration)
- OQ (Operational Qualification) : vérifie que le système fonctionne conformément aux spécifications dans des conditions d’utilisation définies (tests par fonction critique : gestion des lots, traçabilité, audit trail, gestion des accès, CAPA)
- PQ (Performance Qualification) : vérifie que le système fonctionne de manière continue et reproductible dans les conditions réelles d’utilisation
Ces tests doivent être exécutés dans un environnement de qualification distinct de la production, avec des données de test représentatives des cas d’usage réels.
Gestion des changements post-validation : patch, upgrade ERP et re-validation
Tout changement apporté à un ERP validé doit suivre un processus d’évaluation d’impact avant mise en production :
- Impact Assessment : le changement affecte-t-il une fonction critique validée ?
- Si oui : re-test des fonctions impactées (re-validation partielle), mise à jour de la documentation
- Approbation QA avant déploiement en production
Un patch correctif de sécurité appliqué sans évaluation d’impact préalable peut invalider l’état de validation du système. Les équipes informatiques des fabricants de dispositifs médicaux doivent intégrer ce principe dans leur processus de patch management et de gestion des changements IT.
Audit trail : configuration dans l’ERP (EU MDR et FDA 21 CFR Part 11)
L’audit trail est une exigence centrale de l’EU MDR (Article 10(9)(d)) et de la FDA 21 CFR Part 11 pour les marchés export. Il doit enregistrer, de manière non modifiable et horodatée, toute création, modification ou suppression d’enregistrement critique dans le système.
Un audit trail conforme dans l’ERP doit capturer : l’identité de l’opérateur, la date et l’heure de l’action (horodatage serveur, non modifiable), les valeurs avant et après modification, et la justification de la modification lorsqu’elle est requise. Il doit être accessible en lecture aux auditeurs sans être modifiable par les utilisateurs, y compris les administrateurs système.
Comparatif : les ERP les mieux positionnés pour les fabricants medtech
SAP S/4HANA + Life Sciences : points forts et positionnement
SAP S/4HANA est l’ERP de référence pour les grandes ETI et groupes internationaux du medtech. Son module Life Sciences intègre nativement la gestion des lots, l’audit trail, le CAPA et le Change Control. SAP propose des templates de configuration Industry Cloud for Life Sciences, réduisant le travail de validation initial pour les fonctions standard.
Le principal point de vigilance : le coût total de possession (TCO) est élevé et la mise en oeuvre d’un projet SAP S/4HANA qualité pour un fabricant medtech dure typiquement 18 à 36 mois. SAP est adapté aux fabricants dont les opérations atteignent un niveau de complexité justifiant cet investissement (multi-sites, multi-pays, portefeuille de dispositifs diversifié).
Oracle Cloud ERP : adapté aux ETI internationales
Oracle Cloud ERP, couplé aux modules Oracle Health Sciences, offre une plateforme cloud native avec des capacités de traçabilité, gestion des incidents et reporting réglementaire. La migration vers le cloud Oracle permet de bénéficier d’environnements de test isolés, ce qui simplifie la qualification OQ/PQ et la gestion des mises à jour post-validation.
Oracle convient particulièrement aux fabricants présents à la fois aux États-Unis et en Europe, soumis simultanément à la FDA 21 CFR Part 820 (Quality System Regulation) et à l’EU MDR.
Infor LN / CloudSuite Industrial : spécialiste manufacturing réglementé
Infor LN est un ERP conçu pour le manufacturing complexe, notamment dans les secteurs aéronautique (AS9100), défense et médical. Son module Quality Management est certifiable ISO 13485 et gère nativement les workflows CAPA, le Change Control et la traçabilité bidirectionnelle par lot et par numéro de série.
Infor LN est particulièrement adapté aux fabricants medtech de taille intermédiaire produisant des dispositifs complexes avec des gammes opératoires longues.
SYSPRO : alternative PME pour medtech de taille modeste
SYSPRO est un ERP manufacturier dont la version medtech intègre des modules de gestion de la qualité, de traçabilité et d’audit trail compatibles avec ISO 13485. Son positionnement PME et son modèle de licence plus accessible en font une alternative crédible aux grandes plateformes SAP et Oracle pour les fabricants de dispositifs de classe I et IIa.
SYSPRO a publié des guides de validation GAMP 5 et propose un support documentaire pour l’IQ/OQ/PQ, ce qui réduit la charge de travail de validation pour les équipes qualité.
Odoo : avec des limitations importantes pour le medtech réglementé
Odoo Community et Odoo Enterprise sont parfois envisagés par les startups medtech pour leur coût d’entrée faible et leur flexibilité. Deux points de vigilance importants s’imposent :
- Audit trail natif limité : en version standard, Odoo ne génère pas un audit trail conforme 21 CFR Part 11 sans développement additionnel significatif
- Validation GAMP 5 : la nature open source et la cadence de mise à jour régulière d’Odoo rendent la validation et la gestion des changements post-validation plus complexes et plus coûteuses qu’avec un ERP à cycle de release contrôlé
Odoo peut convenir pour les fabricants de dispositifs de classe I faiblement réglementés, mais il est déconseillé pour tout dispositif nécessitant une validation complète GAMP 5 ou un audit trail rigide.
Tableau comparatif : fonctionnalités clés pour le medtech
| Critère | SAP S/4HANA | Oracle Cloud | Infor LN | SYSPRO | Odoo |
|---|---|---|---|---|---|
| ISO 13485 natif | Oui | Oui | Oui | Oui | Partiel |
| Gestion UDI native | Oui | Oui | Partiel | Partiel | Non |
| CAPA intégré | Oui | Oui | Oui | Oui | Module tiers |
| Audit trail conforme | Oui | Oui | Oui | Oui | Dev requis |
| Support GAMP 5 documenté | Oui | Oui | Oui | Oui | Non |
| Profil cible | ETI/Groupe | ETI internationale | ETI manufacturing | PME | Startup classe I |
Checklist : les 12 exigences ERP pour un fabricant de dispositifs médicaux
- Traçabilité bidirectionnelle par lot et par numéro de série jusqu’au niveau composant acheté
- Gestion UDI native (DI géré sur la fiche article, PI généré à la production)
- Interface ou export EUDAMED (API REST ou fichier CSV) pour l’enregistrement des DI
- Module CAPA avec workflow configurable, enregistrements non modifiables, clôture documentée
- Change Control intégré au système qualité avec Impact Assessment et approbation QA
- Document Management System intégré ou connecté (versioning, accès contrôlé, archivage long terme)
- Audit trail complet sur les données critiques (QMS, production, libération) conforme EU MDR et 21 CFR Part 11
- Gestion des accès basée sur les rôles (RBAC) avec journalisation des connexions et tentatives d’accès
- Module rappel de lot permettant d’identifier rapidement tous les destinataires d’un lot
- Environnements séparés (production, qualification, développement) pour la gestion des changements post-validation
- Documentation de validation fournie ou supportée par l’éditeur (templates IQ/OQ/PQ, traceability matrix)
- Qualification des fournisseurs dans l’ERP, avec enregistrement des audits fournisseur et certificats d’analyse
Pour approfondir les spécificités réglementaires dans les industries connexes, consultez notre guide ERP santé et pharma et notre comparatif ERP chimie et sciences de la vie. Pour les DSI qui gèrent simultanément des enjeux de conformité et de cybersécurité sur leur ERP industriel, notre article ERP et cybersécurité couvre les bonnes pratiques de protection du système de gestion.
