Fabien Bousquet
Menu
Santé · environnements régulés

CTO externalisé pour les organisations santé et les structures régulées.

HDS, RGPD santé, dispositifs médicaux numériques, multi-établissements. Sur ces sujets, un projet tech mal cadré ne coûte pas que de l'argent. Il peut bloquer un essai clinique, casser la conformité, ou exposer la donnée patient.

Je suis le CTO externalisé qui connaît ces contraintes, qui les naviguait déjà chez DI&Care, et qui livre en forfait, en jours plutôt qu'en mois. Solo, sans sous-traitance, avec une stack moderne qui fusionne le cadrage et le build.

HDS RGPD santé MDR / DM numérique Multi-établissements Essai clinique

Pour qui

Quatre profils pour qui ça marche.

Healthtech avec un dispositif médical numérique

Vous préparez la mise sur le marché d'un logiciel classé DM (classe I, IIa, IIb), souvent depuis un POC fait par une agence. La conformité MDR et la rigueur dev qu'elle impose ne sont pas négociables.

Cliniques, EHPAD, labos, cabinets multi-sites

Vous gérez un réseau d'établissements et avez besoin d'outils métier qui isolent les données par site, restent conformes HDS et RGPD santé, et donnent une vision agrégée sans casser la souveraineté de chaque structure.

DSI ou direction tech en sortie de SaaS générique

Vous payez aujourd'hui un SaaS qui ne colle pas à votre métier santé, ou un outil sur-mesure verrouillé chez un prestataire. Vous voulez reprendre la main sans casser la continuité de service.

Structures sous tutelle ou en accélération

Essai clinique en cours, autorisation ANSM, audit HAS, intégration LBO santé : la tech est sur le chemin critique et vous n'avez pas le temps de la rater.

Les enjeux qui changent tout

Ce que la santé impose que le reste du tech ignore.

Quatre sujets où une décision tech mal cadrée se paie en mois de conformité, en blocage commercial, ou en risque patient.

Hébergement

HDS, ce que ça veut vraiment dire.

Toute donnée patient hébergée pour le compte d'un professionnel de santé impose un hébergeur certifié HDS (référentiel ANS). Deux certifications existent : HDS hébergeur (le datacenter) et HDS infogérance (l'admin de l'infra). Concrètement, vous ne pouvez pas mettre votre back-office sur AWS générique ou OVH public cloud standard. Il faut OVH HDS, Outscale, ou Cegedim Cloud. Je vous aide à choisir l'option adaptée à votre échelle et à votre budget, pas l'option à 4 000 € HT/mois quand 150 € suffisent.

RGPD santé

Article 9 du RGPD, ce n'est pas du RGPD standard.

Les données de santé sont en catégorie particulière (art. 9 RGPD). Bases légales restreintes, pseudonymisation obligatoire dans la majorité des cas, durée de conservation cadrée par le Code de la santé publique (20 ans après le dernier acte pour le dossier patient), DPO obligatoire au-delà d'un certain volume. Le droit à l'effacement existe, mais s'efface souvent devant l'obligation de conservation médico-légale. La tech doit naviguer cet équilibre sans erreur.

Dispositif médical

Logiciel = DM dès qu'il aide au diagnostic ou au traitement.

MDR 2017/745 a élargi la définition : un logiciel qui contribue au diagnostic, au monitoring, à la décision médicale ou à la thérapie est un dispositif médical. Classes de risque I, IIa, IIb, III, avec organisme notifié obligatoire dès la IIa. Implications dev : ISO 13485 côté qualité, IEC 62304 côté cycle logiciel, ISO 14971 côté gestion des risques, traçabilité des versions et des bugs. Ce n'est pas du dev startup classique.

Multi-établissements

Isolation par site, vision consolidée pour le siège.

Un réseau de cliniques, de labos ou d'EHPAD n'est pas une multinationale. Chaque établissement reste maître de sa donnée patient. La tech doit isoler strictement par site, gérer un IAM par établissement, et permettre quand même au siège une vision agrégée non nominative (pilotage médico-éco, qualité, indicateurs). C'est un sujet d'architecture, pas une option à activer.

Étude de cas santé

DI&Care, mise sur le marché d'un dispositif médical numérique.

Une medtech française qui prépare la mise sur le marché d'un dispositif numérique. Essai clinique en cours, agence dev qui a sur-architecturé le projet en microservices, hébergement hors HDS. Direction non-tech.

Reprise en 7 mois sans refonte : audit pendant que l'agence livrait encore, migration sur OVH HDS sous contrôle direct du client, récupération du code et des accès, stabilisation de l'API pour les patients de l'essai. L'équipe interne est aujourd'hui autonome.

Hébergement

< 150 €/mois

OVH HDS, sous contrôle direct du client.

Durée

7 mois

Sans interruption de l'essai clinique en cours.

Le retour d'une fondatrice healthtech

Save & Care, accompagnement CTO en healthtech.

Fabien a accompagné le développement de Save & Care en tant que CTO. Fiable et à l'écoute, il a su piloter la partie tech avec rigueur tout en apportant des solutions concrètes et adaptées aux enjeux du projet. Un partenaire de confiance que je recommande.
Manon Leroux Fondatrice · Save & Care · Station F · 100 Start-up où investir 2024

Comment on travaille ensemble

Trois manières, toutes en forfait, toutes sous contraintes santé.

Jamais de régie. NDA et clauses RGPD santé systématiques. Cadrage du périmètre HDS et MDR posé dès le premier call.

FAQ santé

Les questions qu'on me pose sur la santé.

Vous êtes vous-même certifié HDS ?

Non, et c'est volontaire. La certification HDS porte sur l'hébergement ou l'infogérance : ce sont les rôles d'OVH, Outscale, Cegedim Cloud. Mon rôle, c'est d'être le CTO côté client qui choisit le bon hébergeur HDS, qui structure l'architecture pour qu'elle reste conforme, et qui pilote la relation contractuelle avec l'hébergeur. Confondre les deux rôles est un piège classique du marché.

Vous travaillez avec des cliniques, des labos, ou plutôt en healthtech ?

Les trois. Les contraintes de fond (HDS, RGPD santé, traçabilité) sont les mêmes, mais l'angle change : healthtech c'est mise sur le marché et conformité MDR, cliniques c'est gestion patient et intégration métier, labos c'est traçabilité analytique et intégration LIS. Je vous le dis lors du call de cadrage si votre cas est dans ma zone de confort ou s'il vaut mieux que je vous renvoie vers un spécialiste plus pointu.

Comment vous gérez la confidentialité patient dans le dev quotidien ?

Pas de donnée patient réelle en dehors de la prod HDS. Les environnements de dev et de staging tournent sur des jeux de données pseudonymisées. Les logs sont offusqués sur tout ce qui touche au patient (identifiants, dates de naissance, identifiants externes type RPPS ou ADELI). Pas d'export brut, pas de copie locale. C'est cadré dès le démarrage du projet.

Vous signez quoi comme contrat type pour un projet santé ?

NDA systématique, contrat de prestation classique avec clauses RGPD santé spécifiques (sous-traitance article 28, registre des activités de traitement), et le cas échéant un avenant DPA si vous accédez à des données patients via mon intervention. Sur les dispositifs médicaux, on peut ajouter une clause de coopération MDR pour formaliser ma place dans votre documentation technique.

Concrètement, un DM numérique classe IIa, ça change quoi en dev ?

Vous passez d'un dev startup à un dev sous qualité ISO 13485 : revues de code formalisées, traçabilité bug-test-version, gestion des risques ISO 14971 documentée, dossier technique à jour à chaque release. Le rythme de delivery ralentit, mais la dette technique baisse aussi. L'organisme notifié auditera tout ça avant la mise sur le marché. Anticiper le marquage CE dès le MVP économise 6 à 12 mois sur l'agenda commercial.

Vous avez un cas client santé concret ?

Oui, DI&Care. Une medtech française qui préparait la mise sur le marché d'un dispositif numérique en essai clinique. Reprise en 7 mois : sortie d'un hébergement non-HDS, migration sur OVH HDS sous 150 €/mois, stabilisation API pour les vrais utilisateurs cliniques, équipe interne autonome à la sortie. L'étude détaillée est disponible.

On en parle ?

Le call de cadrage est gratuit. 30 minutes pour comprendre votre contexte santé et décider si on est bons pour bosser ensemble.

Je réponds personnellement à tous les messages.