Industrialiser une plateforme de télésurveillance pour dispositifs médicaux connectés
Yes We Dev, agence HealthTech en Bretagne, a conçu et déployé une plateforme multi-tenant de télésurveillance médicale pour dispositifs connectés dans 4 pays européens. Hébergement HDS, scoring de risque, cloisonnement strict des données par centre, SSO entreprise, pentest avec zéro vulnérabilité résiduelle. Stack Laravel, architecture sécurisée dès la conception.
Dernière mise à jour : mars 2026
Une scale-up européenne commercialise un dispositif médical connecté pour le suivi à domicile de patients atteints de pathologies chroniques sévères. Le dispositif collecte des données physiologiques en continu. Une équipe médicale centralisée les interprète, génère des scores de risque et déclenche des alertes cliniques — avec un impact direct sur les décisions thérapeutiques.
Le service fonctionnait. Mais il reposait sur un assemblage d’outils non intégrés : exports manuels, analyses sur tableur, alertes par email. Suffisant pour quelques centres pilotes. Insuffisant pour un déploiement multi-pays.
Les besoins rencontrés
Absorber le volume de données
Les dispositifs transmettent des séries temporelles continues — plusieurs milliers de points par jour et par patient. Sans plateforme d’agrégation sécurisée, les données transitaient par email ou clé USB. Aucune traçabilité, aucun historique exploitable.
Automatiser les calculs métier
Les scores de risque et les seuils d’alerte étaient calculés manuellement sur Excel. Chaque centre avait ses propres conventions. Les formules de normalisation par cohorte et les seuils configurables par pathologie devaient être standardisés sans perdre la flexibilité clinique.
Cloisonner les données entre centres
Plusieurs centres cliniques sur la même plateforme, avec des patients différents, des protocoles différents, des contraintes réglementaires différentes selon les pays. Le cloisonnement devait être strict — chaque centre ne voit que ses propres données.
Déployer dans 4 pays européens
Quatre pays, trois langues, des politiques de confidentialité différenciées par zone, des exigences de pseudonymisation variables selon les centres. Et une facturation mensuelle automatisée par centre, connectée à l’ERP.
Les étapes de conception
Phase 1 — Cadrage métier et architecture
Immersion dans le workflow clinique : configuration du dispositif → collecte continue → scoring → alerte → ajustement du protocole de soins. Modélisation des 4 rôles métier avec permissions croisées. Choix d’une architecture multi-tenant stricte dès le départ — pas de raccourci.
Phase 2 — Socle technique et sécurité
Stack Laravel / PHP 8.3 avec composants réactifs et Tailwind CSS. Hébergement cloud souverain avec stockage objet, files d’attente asynchrones pour les traitements lourds, et déploiement automatisé par environnement. SSO entreprise pour l’authentification centralisée. Pipeline CI/CD complet : analyse statique SAST, versioning sémantique, tests automatisés.
Phase 3 — Algorithmes et workflow
Implémentation des algorithmes de scoring : normalisation par cohorte, seuils d’alerte configurables par centre et par pathologie, détection d’anomalies. Ingestion sécurisée des données volumineuses via URLs signées temporaires et traitement asynchrone. Pseudonymisation obligatoire pour les centres soumis à des contraintes renforcées.
Phase 4 — Déploiement multi-pays et durcissement
Mise en production par zone avec instances BDD dédiées par pays. Facturation automatisée avec liaison ERP. Multi-langue. Puis pentest complet avec remédiation : IDOR, CSRF, headers de sécurité, hardening serveur. Zéro vulnérabilité résiduelle.
Notre approche
Le multi-tenant en santé n’est pas un problème technique qu’on résout avec un tenant_id dans la base. C’est un engagement de cloisonnement qui impacte chaque couche : authentification, autorisation, stockage, requêtes, logs, facturation. Nous l’avons intégré dès l’architecture, pas ajouté après coup. Résultat : le déploiement d’un nouveau centre ou d’un nouveau pays ne nécessite aucune modification de code.
Les innovations intégrées
Trois choix techniques font la différence. D’abord, l’architecture en couches stricte (Controller → Repository → Service → Model) qui permet d’isoler la logique métier des calculs de scoring — critique quand les formules évoluent à chaque retour clinique. Ensuite, le pipeline CI/CD avec SAST intégré qui garantit qu’aucune régression de sécurité ne passe en production. Enfin, l’autonomie opérationnelle complète : déploiement, monitoring et maintenance sans intervention du client.
Ce que nous avons appris
Trois enseignements. D’abord, les algorithmes métier en santé ne sont jamais figés — les cliniciens ajustent les seuils, les formules, les critères d’alerte au fil de la pratique. L’architecture doit absorber ces changements sans refonte. Ensuite, le déploiement multi-pays n’est pas qu’un problème de traduction — c’est un problème de conformité, de données, et de facturation qui doit être pensé dès le jour un. Enfin, un pentest n’est pas une formalité : sur ce projet, il a révélé des vulnérabilités réelles (IDOR, CSRF) que nous avons corrigées intégralement avant la mise en production.
Questions fréquentes
Pourquoi choisir un prestataire HealthTech spécialisé pour la télésurveillance ?
La télésurveillance médicale combine données de santé HDS, scoring algorithmique, multi-tenant strict et conformité multi-pays. Un prestataire généraliste découvre ces contraintes en cours de projet. Yes We Dev, agence HealthTech en Bretagne, intègre HDS, cybersécurité applicative et conformité RGPD données de santé dès l’architecture.
Comment sécuriser une plateforme multi-tenant en santé ?
Le multi-tenant en santé exige un cloisonnement à chaque couche : authentification, autorisation, stockage, requêtes, logs, facturation. Ce n’est pas un tenant_id dans la base — c’est une architecture de sécurité complète validée par pentest.
Mission réalisée par Yes We Dev — agence spécialisée HealthTech en Bretagne. Équipe : 3-4 développeurs, 18 mois. Stack Laravel, hébergement HDS, cybersécurité applicative.