Lorsqu’une startup développe un dispositif médical, elle doit mettre en place un système de management de la qualité suffisamment tôt pour encadrer ses activités de conception, de gestion des risques et de conformité réglementaire.
Pour une petite équipe, le choix semble souvent se limiter à deux possibilités :
- construire un QMS manuel avec des documents Word, des feuilles Excel et des dossiers partagés ;
- investir dans un eQMS spécialisé, parfois complexe et coûteux.
Ces deux approches peuvent convenir dans certaines situations. Elles présentent néanmoins chacune des limites importantes pour une entreprise MedTech en phase de développement.
Il existe une troisième voie : mettre en place un QMS structuré dans un environnement collaboratif que l’équipe connaît et utilise peut-être déjà, comme Confluence.
Pourquoi les startups commencent-elles souvent avec un QMS manuel ?
Une entreprise de cinq ou dix personnes n’a généralement pas besoin des mêmes outils qu’un fabricant international possédant plusieurs sites et des centaines d’utilisateurs.
Le recours à des documents Word, des feuilles Excel et une arborescence de dossiers paraît donc logique. Cette solution est accessible, flexible et peu coûteuse. Elle permet aussi à l’équipe de découvrir progressivement ses propres processus.
Cependant, un QMS manuel ne reste simple que si sa structure a été correctement définie dès le départ.
À mesure que le projet avance, l’entreprise doit notamment gérer :
- les versions et les approbations des documents ;
- les responsabilités et les formations ;
- les exigences des utilisateurs et du produit ;
- les activités de conception et de développement ;
- les risques et les mesures de maîtrise ;
- les vérifications et validations ;
- les fournisseurs et sous-traitants ;
- les modifications du produit et du QMS ;
- les non-conformités et les CAPA ;
- les audits et les revues de direction ;
- les activités de surveillance après commercialisation.
Les difficultés apparaissent lorsque ces informations sont réparties entre différents documents, tableurs, répertoires et messageries électroniques.
L’information existe, mais les liens entre les différents éléments deviennent difficiles à établir et à maintenir.
Le principal risque : devoir reconstruire la traçabilité
Pour un fabricant de dispositifs médicaux, le problème ne se limite pas au classement des documents.
L’entreprise doit pouvoir démontrer la cohérence et la traçabilité entre, notamment :
- les besoins des utilisateurs ;
- les exigences de conception ;
- les risques identifiés ;
- les mesures de maîtrise des risques ;
- les spécifications techniques ;
- les activités de vérification et de validation ;
- les modifications du produit ;
- les décisions prises pendant le développement.
Dans un système reposant uniquement sur des documents et des tableurs indépendants, cette traçabilité dépend largement de la discipline de l’équipe.
Elle peut fonctionner pendant les premières étapes du projet, mais devenir plus difficile à maintenir lorsque le nombre de documents, de versions, d’utilisateurs et de modifications augmente.
Attendre que le QMS manuel ne soit plus maîtrisable avant de changer de système peut également créer un problème supplémentaire. La migration intervient alors souvent au moment où l’entreprise prépare une soumission réglementaire, une certification ISO 13485, un audit ou une levée de fonds.
Il faut alors transférer les documents, vérifier les versions, retrouver les approbations et parfois reconstruire une partie de l’historique du développement.
Un eQMS spécialisé est-il toujours la meilleure solution ?
Un eQMS spécialisé peut apporter des avantages importants :
- automatisation des workflows ;
- contrôle des versions ;
- signatures et approbations électroniques ;
- gestion des formations ;
- suivi des CAPA et des non-conformités ;
- tableaux de bord et indicateurs ;
- piste d’audit ;
- gestion centralisée des enregistrements.
Pour une entreprise mature ou une organisation complexe, ces fonctionnalités peuvent justifier l’investissement.
Pour une startup, la situation est différente. Certains eQMS ont été conçus pour des organisations plus grandes et peuvent entraîner :
- des abonnements importants ;
- un coût par utilisateur ;
- des frais d’implémentation et de validation ;
- une formation spécifique ;
- des workflows trop complexes ;
- une dépendance vis-à-vis d’un fournisseur ;
- la coexistence avec d’autres outils déjà utilisés par l’équipe.
Une petite entreprise peut ainsi se retrouver à adapter son fonctionnement à l’outil, alors que le système devrait avant tout soutenir ses activités réelles.
Une troisième voie : construire le QMS dans un environnement collaboratif
Entre le QMS entièrement manuel et l’eQMS d’entreprise, une troisième approche consiste à utiliser une plateforme collaborative existante pour structurer les processus qualité.
Confluence constitue un exemple particulièrement pertinent pour les équipes qui l’utilisent déjà pour leur documentation technique, leurs projets ou leur développement logiciel.
Un QMS construit dans Confluence peut réunir dans un même environnement :
- les procédures et instructions ;
- les formulaires et enregistrements ;
- les responsabilités ;
- la documentation de conception ;
- les dossiers de gestion des risques ;
- les plans et rapports de vérification et validation ;
- les CAPA et modifications ;
- les documents fournisseurs ;
- les audits ;
- les activités de surveillance après commercialisation.
Des applications complémentaires peuvent également être utilisées pour organiser les workflows de révision, d’approbation et de signature, selon les besoins de l’entreprise.
Cette approche permet de conserver un environnement familier tout en apportant davantage de structure, de collaboration et de traçabilité qu’un ensemble de fichiers indépendants.
« Commencer simplement » ne signifie pas commencer sans structure
Une startup n’a pas besoin d’automatiser immédiatement tous ses processus qualité.
Elle doit néanmoins établir suffisamment tôt les processus qui encadrent les activités critiques. Pour un dispositif déjà en développement, cela concerne en particulier :
- le contrôle des documents et des enregistrements ;
- la conception et le développement ;
- la gestion des risques ;
- la maîtrise des fournisseurs ;
- les compétences et les formations ;
- la gestion des modifications ;
- les non-conformités et les actions correctives ;
- la préparation des activités réglementaires et post-commercialisation.
Le QMS doit rester proportionné à la taille de l’organisation, à la nature du dispositif, à sa classe de risque et au stade de développement.
Il peut ensuite évoluer progressivement avec l’entreprise.
L’objectif n’est donc pas de reproduire dès le premier jour le système d’un grand fabricant. Il s’agit de créer une structure suffisamment robuste pour éviter de perdre l’historique, les justifications et la traçabilité du projet.
ReadySet for Confluence : une base structurée pour les équipes MedTech
ReadySet for Confluence a été développé pour les startups et les petites entreprises MedTech qui souhaitent éviter à la fois :
- la charge de travail nécessaire pour rédiger un QMS complet à partir de zéro ;
- la complexité et le coût d’un eQMS d’entreprise.
ReadySet fournit une structure de système de management de la qualité directement exploitable dans Confluence. Il comprend un ensemble organisé de procédures, de formulaires et de documents de référence couvrant les principaux processus d’un fabricant de dispositifs médicaux.
Des versions adaptées aux dispositifs médicaux, aux dispositifs médicaux de diagnostic in vitro et aux logiciels dispositifs médicaux sont disponibles.
ReadySet constitue une base de départ. Il ne s’agit pas d’un QMS automatiquement conforme ou prêt à être certifié sans intervention de l’entreprise.
Chaque fabricant reste responsable :
- d’adapter les procédures à son organisation ;
- de définir les responsabilités ;
- de sélectionner les exigences réglementaires applicables ;
- de documenter ses propres activités ;
- de former les utilisateurs ;
- d’implémenter et de maintenir le système ;
- de valider les outils informatisés lorsque cela est nécessaire.
Cette distinction est essentielle : ReadySet fournit la structure, mais le fabricant construit et maîtrise son propre QMS.
Comment choisir la bonne approche ?
Avant de choisir entre un QMS manuel, un eQMS spécialisé ou un QMS intégré dans une plateforme collaborative, l’entreprise devrait se poser les questions suivantes :
- Le dispositif est-il déjà en phase de développement ?
- Combien de personnes doivent créer, réviser ou approuver des documents ?
- L’équipe utilise-t-elle déjà Confluence ou un outil comparable ?
- Comment la traçabilité entre exigences, risques, conception et vérification sera-t-elle maintenue ?
- Une certification ISO 13485 ou une soumission réglementaire est-elle prévue ?
- Le système pourra-t-il évoluer sans migration majeure ?
- Les coûts et les fonctionnalités sont-ils proportionnés aux besoins actuels ?
- Qui sera responsable de l’implémentation et du maintien du QMS ?
La meilleure solution n’est pas nécessairement celle qui propose le plus de fonctionnalités. C’est celle qui permet à l’entreprise de maîtriser efficacement ses processus, ses documents et ses enregistrements, tout en accompagnant son évolution.
Conclusion
Une startup MedTech ne doit pas nécessairement choisir entre un QMS artisanal et un eQMS d’entreprise.
Un QMS structuré dans un environnement collaboratif tel que Confluence peut représenter une solution intermédiaire : plus organisé et traçable qu’un ensemble de fichiers indépendants, mais plus flexible et proportionné qu’une plateforme d’entreprise.
L’essentiel est de mettre en place la bonne structure au bon moment.
Plus cette structure est établie tôt, moins l’entreprise risque de devoir reconstruire son historique de développement à l’approche d’une certification, d’un audit ou d’une soumission réglementaire.
Vous souhaitez découvrir comment ReadySet peut être adapté à votre entreprise et à votre dispositif médical ?
Contactez AZ Biotech Consulting pour obtenir davantage d’informations ou organiser une présentation de ReadySet for Confluence.
