L’erreur à 250 000 euros de Guillaume
Guillaume se souvient encore de ce vendredi après-midi de novembre 2023. Son application de coaching nutritionnel post-cancer venait d’être achevée après 16 mois de développement. Interface magnifique, algorithmes IA sophistiqués, partenariats signés avec trois centres de cancérologie. Il avait même déjà prévendu 50 licences à des oncologues enthousiastes.
Son consultant réglementaire arrive pour la réunion de lancement du processus de certification. Guillaume lui présente fièrement l’application : « On a classé ça en classe I, auto-certification, on devrait avoir le marquage CE dans 3 mois max, non ? »
Le consultant étudie l’application pendant une heure. Il teste les fonctionnalités, lit les algorithmes, examine les recommandations nutritionnelles générées. Puis il lâche le verdict : « Guillaume, cette application n’est pas classe I. C’est une classe IIa, peut-être même IIa borderline IIb. »
Le silence s’abat dans la salle. Guillaume réalise instantanément l’ampleur du problème. Classe IIa signifie organisme notifié obligatoire. Études cliniques probablement nécessaires. Budget multiplié par trois. Délai d’un an minimum. Toute son architecture de données n’est pas compatible avec les exigences d’une classe IIa.
L’erreur de classification lui a coûté 9 mois de refonte et 250 000 euros supplémentaires. Une erreur qu’il aurait pu éviter avec une bonne qualification réglementaire initiale.
Aujourd’hui, je vais vous expliquer exactement comment classifier correctement votre application de santé. Parce que cette décision conditionne tout : votre budget, vos délais, votre architecture technique, votre modèle économique.
Pourquoi la classification est LA décision stratégique de votre projet
Avant de rentrer dans les détails techniques, comprenons pourquoi la classification est si cruciale. Ce n’est pas juste une question administrative. C’est la colonne vertébrale de tout votre projet.
Nathalie développait une plateforme de télésurveillance pour patients diabétiques. Elle hésitait entre deux périmètres fonctionnels :
Option A – Périmètre limité (Classe I) : L’application collecte les glycémies saisies par le patient et les affiche au médecin sous forme de graphiques. Le médecin interprète les données et décide des ajustements thérapeutiques. Pas de recommandation automatique, pas d’analyse prédictive, pas d’alerte automatisée.
Option B – Périmètre étendu (Classe IIa) : L’application collecte les glycémies, analyse les tendances via un algorithme médical, détecte automatiquement les anomalies (hyperglycémies répétées, risque d’hypoglycémie), et envoie des alertes automatiques au médecin. Recommandations automatiques de réglages de dose selon protocole médical intégré.
La différence entre les deux options ? Un petit clic dans l’interface utilisateur. Mais les conséquences sont colossales :
| Critère | Option A (Classe I) | Option B (Classe IIa) |
|———|———————|———————-|
| Budget certification | 85 000 € | 280 000 € |
| Délai certification | 8 mois | 16 mois |
| Organisme notifié | Non | Oui (38 000 €) |
| Étude clinique | Non | Oui (120 000 €) |
| Architecture technique | Standard | Renforcée (HDS obligatoire) |
| Coût développement | 180 000 € | 320 000 € |
| Prix de vente possible | 25 €/patient/an | 120 €/patient/an |
Nathalie a finalement choisi l’option A pour sa version 1. Elle a obtenu son marquage CE classe I en 7 mois pour 92 000 euros. Aujourd’hui, elle génère du chiffre d’affaires qui finance le développement de la version 2 en classe IIa.
La classification, c’est donc un arbitrage entre ambition fonctionnelle et faisabilité réglementaire et économique. Et c’est une décision qu’il faut prendre AVANT de coder la moindre ligne.
Les 4 classes de dispositifs médicaux : une échelle de risque
Le règlement MDR 2017/745 établit une classification en quatre niveaux. Le principe de base est simple : plus le risque potentiel pour le patient est élevé, plus les exigences réglementaires sont strictes.
Voici comment appréhender chaque classe à travers des cas concrets que nous avons rencontrés chez DYNSEO.
Classe I : Les applications à risque faible
Les dispositifs de classe I sont ceux qui présentent le risque le plus faible pour le patient. Typiquement, ce sont des applications qui aident, informent, ou facilitent, mais qui n’influencent pas directement les décisions thérapeutiques.
Caractéristique principale : Si l’application bug ou donne une information erronée, les conséquences pour le patient restent limitées car un professionnel de santé valide toujours in fine.
Prenons l’exemple de l’application développée par Sylvie, une infirmière libérale. Son app permet aux patients de tenir un journal de leurs symptômes (douleur, fatigue, nausées) et de le partager avec leur médecin. C’est tout. Pas d’analyse automatique, pas de recommandation thérapeutique, pas d’alerte. Juste un carnet de bord digital structuré. Classe I validée.
Pourquoi ? Parce que si l’application perd des données ou affiche des informations incorrectes, le médecin s’en rendra compte lors de la consultation. Le patient n’agira pas sur la base exclusive de l’application. Le risque est maîtrisé par la supervision médicale.
Autres exemples typiques de classe I :
→ Application de prise de rendez-vous médical : même avec des fonctionnalités avancées (rappels, visioconférence), si vous ne faites que de la logistique, vous restez en classe I.
→ Carnet de santé numérique : le patient renseigne ses antécédents, ses allergies, ses traitements en cours. C’est informatif, c’est utile, mais ça ne prend aucune décision médicale.
→ Application de suivi d’observance : rappels de prise de médicaments basés sur l’ordonnance saisie. Pas de calcul de dose, pas d’ajustement, juste un aide-mémoire.
→ Plateforme de messagerie sécurisée patient-médecin : même avec chiffrement et HDS, si c’est juste de la communication, c’est classe I.
Avantages de la classe I :
- Auto-certification possible (pas d’organisme notifié obligatoire)
- Délais courts (6 à 9 mois)
- Budget raisonnable (60 000 à 120 000 euros)
- Mise à jour facilitée
- Rapidité de mise sur le marché
- Fonctionnalités limitées (pas d’aide à la décision)
- Valeur ajoutée perçue moindre
- Prix de vente plus bas
- Différenciation concurrentielle faible
- Algorithme d’aide à la décision diagnostique ou thérapeutique
- Détection automatique d’anomalies avec alertes
- Recommandations personnalisées basées sur des règles médicales
- Calcul de scores de risque influençant la prise en charge
- Traitement de données médicales avec analyse prédictive
- Organisme notifié OBLIGATOIRE
- Études cliniques souvent nécessaires
- Budget : 150 000 à 400 000 euros
- Délai : 12 à 18 mois
- Architecture technique renforcée (hébergement HDS obligatoire)
- Processus qualité structuré (ISO 13485)
- Prix de vente justifiés plus élevés (3 à 5x une classe I)
- Organisme notifié hautement spécialisé
- Études cliniques massives obligatoires (souvent >500 patients)
- Budget : 500 000 à 2 000 000 euros
- Délai : 24 à 36 mois
- Expertise scientifique pointue nécessaire
- Partenariats hospitaliers indispensables
- Niveau d’exigence maximal sur tous les aspects (code, tests, documentation)
- Investissements colossaux (>2 millions d’euros)
- Délais de 3 à 5 ans
- Équipe scientifique et médicale de haut niveau
- Publications scientifiques de référence nécessaires
- Hors de portée pour la majorité des startups
- Si le rapport est juste une mise en forme visuelle des résultats (graphiques, historique) sans aucune interprétation → Pas de finalité médicale, pas de dispositif médical
- Si le rapport inclut une interprétation automatique (« valeur anormale », « tendance à la hausse préoccupante ») → Finalité médicale établie, dispositif médical
- Si le rapport va jusqu’à suggérer des diagnostics possibles (« compatible avec une anémie ferriprive », « évocateur d’une insuffisance rénale ») → Finalité diagnostique claire, classe IIa probable
- Si NON → pas de dispositif médical pour cette fonctionnalité
- Si OUI → passez à la question B
- Si NON → probablement classe I (selon contexte)
- Si OUI → passez à la question C
- Risque faible (gêne, inconfort temporaire) → classe I
- Risque modéré (complication réversible, hospitalisation) → classe IIa
- Risque élevé (séquelles, handicap, risque vital) → classe IIb/III
- Analyser en détail chaque fonctionnalité
- Challenger vos hypothèses de classification
- Identifier les zones grises ou ambiguës
- Vous orienter vers des précédents réglementaires similaires
- Vous préparer une argumentation solide pour l’organisme notifié
- Si elle cible le grand public pour information générale → pas de dispositif médical
- Si elle cible les professionnels de santé pour dépister l’obésité et orienter vers une prise en charge → classe I
- Si elle calcule l’IMC ET recommande automatiquement un type de régime ou une consultation spécialisée → classe IIa
- Différenciation maximale
- Prix premium justifiés
- Barrière à l’entrée pour concurrents
- Crédibilité scientifique et médicale
- Budget 250 000 – 400 000€ disponible
- Équipe capable de tenir 18-24 mois sans revenus
- Partenariats médicaux pour études cliniques
- Expertise réglementaire in-house ou externe
- Time-to-market rapide (8-10 mois)
- Budget maîtrisé (80 000 – 120 000€)
- Génération de chiffre d’affaires précoce
- Validation marché avant gros investissements
- Possibilité d’autofinancer la version classe IIa avec les revenus V1
- V1 en classe I : fonctionnalités de base, commercialisation rapide
- V2 en classe IIa : fonctionnalités avancées financées par les revenus V1
- V3 : extension internationale, intégrations avancées
- Règlement MDR 2017/745 : Annexe VIII (règles de classification), disponible sur le site de la Commission Européenne
- MDCG 2019-11 : Guidance document on qualification of medical device software
- Guide ANSM : Qualification des logiciels en dispositif médical ou dispositif médical de diagnostic in vitro
- Jurisprudence MDCG : Décisions de classification pour cas limites
Limites de la classe I :
Classe IIa : Les applications à risque modéré
On monte d’un cran. Les dispositifs de classe IIa présentent un risque modéré pour le patient. Typiquement, ce sont des applications qui influencent les décisions diagnostiques ou thérapeutiques, mais dans des pathologies où les conséquences d’une erreur restent rattrapables.
Caractéristique principale : L’application produit une information médicale qui va directement influencer la prise en charge, mais un professionnel de santé garde la main sur la décision finale.
Julien a développé une application de détection précoce de la dépression. Son algorithme analyse les réponses à un questionnaire validé (PHQ-9), évalue la sévérité, et recommande une consultation psychiatrique si le score dépasse un certain seuil. C’est une aide au dépistage qui oriente vers un professionnel, mais ne pose pas de diagnostic définitif. Classe IIa.
Pourquoi classe IIa et pas classe I ? Parce que l’algorithme produit une recommandation médicale (« consultez un psychiatre », « suivi nécessaire sous 15 jours ») qui va influencer le parcours du patient. Si l’algorithme rate un patient à risque suicidaire (faux négatif), les conséquences peuvent être graves. Le risque est donc plus élevé qu’en classe I.
Exemples typiques de classe IIa que nous avons accompagnés :
→ Plateforme de télésurveillance cardiaque : collecte automatique des constantes (poids, tension, FC) via objets connectés + algorithme de détection d’anomalies + alertes automatiques au cardiologue. Le médecin décide in fine de l’action, mais l’algorithme déclenche l’alerte.
→ Application de calcul de risque cardiovasculaire : intègre les facteurs de risque du patient (âge, tabac, diabète, cholestérol, tension) et calcule un score de risque avec recommandation de niveau de prise en charge. Le médecin utilise ce score pour décider du traitement.
→ Serious game de rééducation cognitive post-AVC : exercices calibrés selon le niveau de déficit, adaptation automatique de la difficulté selon les performances, transmission des résultats au neurologue pour ajustement du programme de rééducation.
→ Application de gestion de la douleur chronique : le patient évalue quotidiennement sa douleur, l’application identifie des tendances et suggère des ajustements de traitement antalgique selon un protocole médical pré-établi. Le médecin valide les suggestions.
→ Plateforme de suivi diabète avec recommandations posologiques : collecte des glycémies, analyse les tendances, suggère des ajustements de doses d’insuline selon des règles médicales. Le patient peut suivre les suggestions, mais un contrôle médical régulier est maintenu.
Ce qui fait basculer en classe IIa :
Conséquences de la classe IIa :
Classe IIb : Les applications à risque élevé
Là, on entre dans le dur. Les dispositifs de classe IIb présentent un risque élevé pour le patient. Ce sont des applications qui prennent ou influencent fortement des décisions thérapeutiques dans des pathologies graves où une erreur peut avoir des conséquences lourdes, voire vitales.
Caractéristique principale : L’application agit directement sur la thérapeutique, avec un niveau d’autonomie élevé, dans des situations à risque vital ou de handicap sévère.
Alexandre travaillait sur une application d’ajustement automatique de doses d’insuline pour pompe à insuline connectée. Son algorithme analysait en continu les glycémies via capteur CGM, prédisait les tendances glycémiques, et ajustait automatiquement les débits de base d’insuline pour maintenir la glycémie dans la cible. Le patient ne validait pas chaque ajustement, le système fonctionnait en boucle fermée.
Classe IIb, voire classe III selon le niveau d’automatisation. Pourquoi ? Parce qu’une erreur de l’algorithme peut provoquer une hypoglycémie sévère (coma) ou une hyperglycémie aiguë (acidocétose). Le risque vital est réel et immédiat.
Alexandre a finalement pivoté son projet vers un système d’aide à la décision (classe IIa) plutôt qu’un système entièrement automatisé. Beaucoup plus atteignable réglementairement et économiquement.
Exemples typiques de classe IIb :
→ Algorithmes d’IA diagnostique autonome : détection automatique de mélanomes sur photos dermatologiques, diagnostic de rétinopathie diabétique sur fond d’œil, détection de fractures sur radiographies. Si le diagnostic influence directement la prise en charge ET qu’une erreur peut avoir des conséquences graves (cancer raté), c’est classe IIb.
→ Systèmes de pilotage de dispositifs implantés : logiciel contrôlant un stimulateur cardiaque, une pompe à insuline implantée, un neurostimulateur. Le risque est directement lié au dispositif implanté.
→ Plateformes de planification chirurgicale : logiciel calculant les trajectoires d’implants orthopédiques, planifiant une résection tumorale, simulant une intervention cardiaque. Une erreur de calcul peut avoir des conséquences graves en per-opératoire.
→ Applications de monitoring vital automatisé : système de télésurveillance en réanimation qui détecte automatiquement les situations critiques et déclenche des alarmes sans validation humaine préalable.
Conséquences de la classe IIb :
Classe III : Le sommet de la pyramide réglementaire
La classe III concerne les dispositifs présentant un risque très élevé, typiquement ceux en contact direct avec le système cardiovasculaire ou nerveux central, ou ceux dont la défaillance peut entraîner la mort ou un handicap irréversible.
Pour le logiciel médical, très peu d’applications tombent directement en classe III. C’est plutôt le domaine des logiciels embarqués dans des dispositifs implantables actifs (pacemakers, défibrillateurs, pompes implantées).
Mais si vous développez un algorithme d’IA qui pilote en temps réel un robot chirurgical cardiaque, ou un système de diagnostic automatique d’AVC avec administration automatique de thrombolyse… vous êtes probablement en classe III. Autant dire qu’on est sur des projets de recherche hospitalière avec des budgets de plusieurs millions d’euros et des équipes pluridisciplinaires.
Conséquences de la classe III :
Chez DYNSEO, nous n’avons jamais accompagné de projet classe III. Notre expertise se concentre sur les classes I, IIa et quelques IIb avec des porteurs de projets qui ont les moyens et l’expertise médicale nécessaire.
La règle 11 du MDR : le cœur du réacteur pour les logiciels
Maintenant que vous avez une vue d’ensemble des classes, entrons dans le détail technique. Comment déterminer précisément la classe de votre application ? C’est la règle 11 du règlement MDR qui s’applique spécifiquement aux logiciels médicaux.
Cette règle est structurée autour de trois critères principaux : la finalité médicale, l’influence sur les décisions, et le niveau de risque de la pathologie.
Critère 1 : La finalité médicale de votre logiciel
Tout part de la question : qu’est-ce que votre logiciel FAIT concrètement ?
Fourniture d’informations pour des décisions à des fins diagnostiques ou thérapeutiques : Si votre logiciel produit une information qui sera utilisée pour poser un diagnostic ou décider d’un traitement, vous êtes dans le périmètre réglementaire.
Exemple concret : Laure a développé une application qui analyse les résultats de bilans biologiques et génère un rapport de synthèse pour le médecin. Elle se demandait si c’était un dispositif médical. La réponse dépend de ce que fait exactement le rapport :
Pilotage ou influence sur l’utilisation d’un autre dispositif médical : Si votre logiciel contrôle, configure, ou optimise un autre dispositif médical (pompe, respirateur, capteur…), vous héritez généralement de la classe du dispositif piloté, voire une classe supérieure.
Monitoring de processus physiologiques : Si vous surveillez en continu des paramètres vitaux avec des alertes automatiques, vous êtes probablement en classe IIa minimum.
Critère 2 : Le niveau d’influence sur les décisions
C’est souvent le critère le plus subtil et le plus déterminant. On distingue plusieurs niveaux d’influence :
Niveau 1 – Information passive : Le logiciel affiche des données brutes ou légèrement transformées. C’est le professionnel qui interprète et décide. Risque : classe I.
Exemple : Application qui affiche l’historique des glycémies sous forme de courbe. Le diabétologue regarde la courbe et décide d’ajuster les doses.
Niveau 2 – Aide à l’interprétation : Le logiciel met en évidence des anomalies, calcule des tendances, rapproche des données. Mais il ne conclut pas. Risque : classe I ou IIa selon la criticité.
Exemple : Application qui surligne en rouge les glycémies hors cible et affiche une alerte « tendance à l’hyperglycémie depuis 3 jours ». Le médecin analyse et décide.
Niveau 3 – Recommandation non contraignante : Le logiciel suggère une action médicale selon des règles ou algorithmes médicaux. Le professionnel peut accepter ou refuser. Risque : classe IIa généralement.
Exemple : Application qui suggère « augmentation de la dose d’insuline basale de 2 unités selon protocole » mais le médecin valide avant transmission au patient.
Niveau 4 – Décision automatisée avec validation a posteriori : Le logiciel prend une décision, l’applique, mais un professionnel peut annuler ou corriger. Risque : classe IIa ou IIb selon la pathologie.
Exemple : Application qui ajuste automatiquement la dose d’anticoagulant selon l’INR, envoie la prescription automatiquement, mais le médecin reçoit une notification et peut modifier.
Niveau 5 – Décision entièrement automatisée : Le logiciel décide et agit sans validation humaine préalable. Risque : classe IIb ou III selon la gravité potentielle.
Exemple : Algorithme qui détecte une arythmie grave sur l’ECG et déclenche automatiquement l’envoi d’une ambulance + alerte SAMU.
Critère 3 : La gravité de la pathologie ou situation
À niveau d’influence égal, la classe va dépendre de la gravité des conséquences potentielles d’une erreur.
Le règlement MDR distingue :
Situations non critiques : Pathologies chroniques stables, gênes fonctionnelles mineures, situations sans risque vital. Une erreur n’a pas de conséquence grave immédiate.
Exemple : Application de rééducation d’une entorse de cheville. Si l’algorithme suggère un exercice inadapté, au pire le patient aura mal et arrêtera. Pas de conséquence durable.
Situations critiques sans risque vital immédiat : Pathologies chroniques graves, situations avec risque de complication à moyen terme, pathologies psychiatriques.
Exemple : Application de suivi de patients diabétiques. Une mauvaise recommandation peut provoquer une hyperglycémie ou hypoglycémie, nécessiter une hospitalisation, mais le patient a généralement le temps de réagir.
Situations à risque vital ou de handicap lourd : Pathologies aiguës graves, états critiques, risques de mort ou séquelles irréversibles.
Exemple : Application de détection d’AVC. Un faux négatif peut faire rater la fenêtre thérapeutique de 4h30 pour la thrombolyse. Le patient garde des séquelles neurologiques définitives. Risque majeur → classe IIb.
La méthode pratique pour classifier votre application
Assez de théorie. Comment faire concrètement pour classifier votre application ? Voici la méthode que nous utilisons chez DYNSEO lors de nos ateliers de qualification réglementaire.
Étape 1 : Cartographier toutes vos fonctionnalités
Listez TOUTES les fonctionnalités de votre application, même celles qui vous semblent anodines. Pour chaque fonctionnalité, décrivez précisément ce qu’elle fait.
Exemple pour une application de suivi cardiaque :
1. Inscription/connexion utilisateur : authentification, création de profil
2. Saisie manuelle de tension artérielle : le patient entre manuellement ses mesures
3. Import automatique depuis tensiomètre connecté : récupération automatique via Bluetooth
4. Affichage historique sous forme de courbes : visualisation graphique des données
5. Détection automatique de tensions anormales : algorithme qui compare aux seuils normaux
6. Alerte au patient en cas de tension élevée : notification push « tension trop élevée, surveillez »
7. Alerte automatique au médecin si seuil critique : email/SMS automatique au cardiologue référent
8. Calcul de score de risque cardiovasculaire : intégration âge + tension + cholestérol + tabac → score
9. Recommandation de consultation selon score : « score élevé, consultez sous 15 jours »
10. Messagerie patient-médecin : chat sécurisé
11. Rappel de prise de traitement : notification quotidienne
12. Export PDF pour le médecin : génération rapport de synthèse
Étape 2 : Qualifier chaque fonctionnalité individuellement
Pour chacune de vos fonctionnalités, posez-vous trois questions :
Question A : Cette fonctionnalité a-t-elle une finalité médicale ?
Question B : Cette fonctionnalité influence-t-elle une décision diagnostique ou thérapeutique ?
Question C : Quel est le niveau de risque si cette fonctionnalité dysfonctionne ?
Reprenons notre exemple d’application cardiaque :
| Fonctionnalité | Finalité médicale ? | Influence décision ? | Risque si erreur | Classe |
|—————-|———————|———————-|——————|——–|
| 1. Authentification | NON | – | – | Pas DM |
| 2. Saisie manuelle TA | OUI (collecte données) | NON (affichage seul) | Faible | Classe I |
| 3. Import auto TA | OUI | NON | Faible | Classe I |
| 4. Historique graphique | OUI | NON (information passive) | Faible | Classe I |
| 5. Détection TA anormale | OUI | OUI (alerte) | Modéré (faux négatif = HTA non traitée) | Classe IIa |
| 6. Alerte patient | OUI | OUI | Modéré | Classe IIa |
| 7. Alerte médecin auto | OUI | OUI (déclenche action médicale) | Modéré/Élevé | Classe IIa |
| 8. Calcul score risque CV | OUI | OUI (aide au diagnostic) | Modéré | Classe IIa |
| 9. Recommandation consult. | OUI | OUI | Modéré | Classe IIa |
| 10. Messagerie sécurisée | NON (c’est de la communication) | – | – | Pas DM |
| 11. Rappel médicament | OUI | NON (pas de calcul de dose) | Faible | Classe I |
| 12. Export PDF | OUI | NON (mise en forme) | Faible | Classe I |
Étape 3 : Déterminer la classe globale de votre application
La règle est simple : votre application prend la classe de sa fonctionnalité la plus risquée.
Dans notre exemple, les fonctionnalités 5, 6, 7, 8 et 9 sont de classe IIa. Donc l’application globale est classe IIa.
Vous avez deux options stratégiques à ce stade :
Option A : Accepter la classe IIa et développer l’application complète avec toutes les fonctionnalités. Conséquences : organisme notifié, étude clinique, budget 250 000€+, délai 16 mois.
Option B : Désactiver les fonctionnalités classe IIa pour la version 1 et sortir une version minimaliste en classe I. Vous gardez uniquement les fonctionnalités 1 à 4, 10, 11 et 12. Conséquences : auto-certification, budget 80 000€, délai 8 mois, mise sur le marché plus rapide.
Il n’y a pas de bonne ou mauvaise réponse. C’est une décision stratégique qui dépend de votre marché cible, votre financement, votre timing, et votre valeur ajoutée perçue.
Chez DYNSEO, nous accompagnons régulièrement des clients dans ce type d’arbitrage. Notre expertise en développement d’applications de santé nous permet de concevoir des architectures modulaires qui facilitent ces évolutions par paliers :
Étape 4 : Valider avec un expert réglementaire
La classification n’est pas une science exacte. C’est une interprétation réglementaire qui peut varier selon les organismes notifiés, les autorités compétentes, et l’évolution de la jurisprudence.
C’est pourquoi nous recommandons TOUJOURS de faire valider votre classification par un consultant réglementaire expérimenté AVANT de démarrer le développement. Ce consultant va :
Cette validation coûte généralement entre 2 000 et 5 000 euros. C’est un investissement dérisoire comparé au coût d’une mauvaise classification découverte après 12 mois de développement.
Les pièges fréquents qui font déraper la classification
Après avoir accompagné des dizaines de projets, nous avons identifié les erreurs récurrentes qui mènent à une mauvaise classification initiale.
Piège 1 : Sous-estimer l’impact des algorithmes
Beaucoup de porteurs de projets pensent qu’un algorithme qui « aide » ou « suggère » sans « décider » reste en classe I. Faux.
Dès que votre algorithme produit une recommandation médicale personnalisée (même avec validation humaine), vous êtes en classe IIa. Ce n’est pas le niveau d’automatisation qui compte, c’est la finalité médicale de l’output.
Exemple vécu : Clément développait une application de prévention des chutes pour personnes âgées. Son algorithme analysait les données d’activité du smartphone (accéléromètre, gyroscope) et détectait une « marche instable ». Il affichait alors un message : « Votre marche est instable, pensez à consulter votre kinésithérapeute ». Il pensait être en classe I car « c’est juste une suggestion ».
Raté. L’algorithme produit un diagnostic fonctionnel (« marche instable ») et recommande une action médicale (« consulter un kiné »). C’est une aide au diagnostic et à la décision thérapeutique. Classe IIa.
Piège 2 : Ignorer la fonction secondaire qui change tout
Votre application peut avoir 10 fonctionnalités classe I et une seule fonctionnalité classe IIa. Résultat : l’application entière est classe IIa.
C’est le cas classique de l’application de téléconsultation. La visioconférence en elle-même n’est pas un dispositif médical. Mais si vous ajoutez une fonctionnalité de prescription électronique avec vérification automatique des contre-indications médicamenteuses, cette fonction-là peut être classe IIa. Et donc l’application globale devient classe IIa.
Certains éditeurs contournent le problème en proposant deux applications distinctes : une app de téléconsultation (pas de DM) et une app de prescription sécurisée (classe IIa). Techniquement, elles communiquent, mais réglementairement, elles sont séparées. Stratégie valable mais complexe à maintenir.
Piège 3 : Négliger le contexte d’utilisation
La même fonctionnalité peut être classe I ou classe IIa selon le contexte d’utilisation.
Exemple : Une application de calcul d’IMC.
C’est votre « usage prévu » (intended use) déclaré qui détermine la classification. Attention donc à bien formuler votre usage prévu dans votre documentation.
Piège 4 : Confondre dispositif médical et application de bien-être
La frontière est parfois ténue. Une règle simple : si votre application vise à prévenir, diagnostiquer, traiter ou atténuer une maladie, c’est un dispositif médical. Si elle vise à maintenir ou améliorer le bien-être général, ce n’est pas un dispositif médical.
Exemples concrets :
Application de méditation pour réduire le stress quotidien → Bien-être, pas de DM
Application de méditation basée sur la MBCT (Mindfulness-Based Cognitive Therapy) pour prévenir les rechutes dépressives → Finalité thérapeutique, dispositif médical classe IIa
Application de suivi de sommeil avec conseils d’hygiène de vie → Bien-être, pas de DM
Application de thérapie cognitive et comportementale pour traiter l’insomnie chronique → Finalité thérapeutique, dispositif médical classe IIa
La différence ? La validation scientifique du protocole, la finalité thérapeutique explicite, la population cible (patients diagnostiqués vs grand public), et les revendications marketing que vous faites.
Piège 5 : Oublier que la classification peut évoluer
Attention : si vous ajoutez de nouvelles fonctionnalités à votre application après la certification initiale, vous devez réévaluer la classification.
Sophie avait obtenu un marquage CE classe I pour son application de carnet de santé numérique. Tout allait bien. Puis elle a ajouté une fonctionnalité de « check-up santé automatique » qui analysait l’ensemble des données du patient et générait un rapport de synthèse avec des alertes (« cholestérol élevé, consultez sous 3 mois », « tension borderline, à surveiller »).
Cette nouvelle fonctionnalité était classe IIa. Sophie aurait dû faire une réévaluation réglementaire et potentiellement re-certifier en classe IIa. Elle ne l’a pas fait. Lors d’un audit de surveillance annuel, l’organisme notifié a découvert la nouvelle fonctionnalité. Suspension du certificat CE. Interdiction de commercialiser pendant 3 mois le temps de régulariser. Perte de plusieurs contrats.
Comment prendre la bonne décision stratégique
Maintenant que vous maîtrisez la classification, comment décider concrètement ? Voici notre cadre de décision stratégique que nous utilisons chez DYNSEO.
Scénario 1 : Vous avez un financement solide et du temps devant vous
Si vous avez levé des fonds significatifs (>500 000€) ou que vous avez des revenus existants qui peuvent financer le développement, ET que vous pouvez vous permettre 18-24 mois avant de commercialiser, alors visez la classe IIa avec toutes les fonctionnalités à forte valeur ajoutée.
Avantages :
Prérequis :
Scénario 2 : Bootstrap, besoin de trésorerie rapide
Si vous autofinancez votre projet ou que votre runway est court (<12 mois), commencez par une version minimaliste en classe I.
Avantages :
Stratégie :
C’est la stratégie qu’a suivie Émilie avec son app de rééducation cognitive. V1 classe I en 9 mois, 150 établissements clients la première année, 180 000€ de CA. V2 classe IIa financée par ces revenus, en cours de certification.
Scénario 3 : Marché B2B établissements de santé
Si votre cible principale est les hôpitaux, cliniques, EHPAD, vous DEVEZ viser au minimum la classe IIa. Les établissements publics ne peuvent pas acheter une application non certifiée dispositif médical pour une utilisation médicale, même si elle est excellente. Les appels d’offres publics exigent systématiquement le marquage CE.
Dans ce cas, pas le choix : investissez dans la classe IIa dès le départ, même si c’est plus long et plus cher. C’est votre ticket d’entrée sur le marché.
Scénario 4 : Marché B2C grand public
Si vous ciblez directement les patients en vente directe (app store, web), vous avez plus de flexibilité. Une application bien conçue en classe I peut parfaitement trouver son marché si vous positionnez bien le produit (aide au suivi, outil de communication, carnet de santé…).
Par contre, vous ne pourrez pas utiliser de vocabulaire médical fort dans votre communication (« diagnostic », « traitement », « thérapie ») sans être un dispositif médical. Restez sur du vocabulaire wellness (« bien-être », « accompagnement », « suivi », « aide »).
DYNSEO : Votre partenaire pour une classification réussie
Vous l’aurez compris, classifier correctement votre application de santé est un exercice subtil qui nécessite expertise réglementaire ET vision stratégique. Une erreur de classification en début de projet peut vous coûter des mois de retard et des centaines de milliers d’euros.
Chez DYNSEO, nous avons accompagné plus de 40 projets d’applications de santé dans leur qualification réglementaire. Notre expertise couvre :
✓ Atelier de qualification réglementaire : 4 heures d’atelier avec votre équipe pour analyser chaque fonctionnalité et déterminer la classe appropriée
✓ Architecture modulaire évolutive : concevoir dès le départ une architecture qui permet d’évoluer de classe I vers classe IIa sans refonte majeure
✓ Stratégie de développement par paliers : définir une roadmap produit alignée avec les contraintes réglementaires
✓ Documentation proactive : constituer le dossier technique au fil de l’eau pour éviter le rush de dernière minute
✓ Validation par experts externes : mise en relation avec nos consultants réglementaires de confiance
Notre approche en développement web et mobile pour la santé intègre systématiquement ces dimensions réglementaires dès la phase de conception :
Vous hésitez sur la classification de votre projet ? Nous vous proposons un atelier de qualification réglementaire gratuit de 2 heures. Au programme :
1. Analyse de votre concept et de vos fonctionnalités clés
2. Cartographie réglementaire préliminaire
3. Identification de la classe probable
4. Recommandations stratégiques (classe cible vs classe initiale)
5. Estimation budgétaire et calendrier réalistes
Cet atelier vous permettra de prendre les bonnes décisions stratégiques avant d’investir massivement dans le développement.
Contactez-nous via agence.dynseo.com ou par téléphone. Parce qu’une bonne classification, c’est la base d’un projet de santé digitale réussi.
—
Ressources complémentaires
—
Article rédigé par l’équipe DYNSEO, spécialiste du développement d’applications de santé certifiées. Plus de 40 qualifications réglementaires réussies depuis 2014.
