Reprendre un projet santé en cours de dérive technique.
Une medtech française qui prépare la mise sur le marché d'un dispositif numérique. Un essai clinique en cours, une appli iOS, une équipe dirigeante non-tech. L'agence dev choisie au départ a sur-architecturé le projet et hébergé hors HDS. Reprise de la tech en 7 mois, autonomie restaurée, infra HDS sous 150 €/mois.
Le contexte
Un dispositif médical numérique en essai clinique.
DI&Care développe un dispositif médical numérique destiné à l'accompagnement de patients dans un cadre clinique. Le produit est en essai clinique au moment où je reprends le dossier, avec une mise sur le marché à préparer en parallèle.
La direction est non-tech. L'équipe a confié le développement à une agence externe, sans pilote technique côté client capable de challenger les choix d'architecture, de stack, ou d'hébergement.
Le problème
Trois problèmes qui se cumulaient.
Conformité
Hébergement hors HDS.
L'agence avait choisi son propre hébergeur, hors agrément HDS, sur un dispositif médical qui traite de la donnée patient. Conformité bancale, souveraineté inexistante, dépendance commerciale au prestataire.
Architecture
Microservices prématurés.
L'API avait été découpée en microservices côté Node.js, "pour scaler". Sur un produit sans utilisateurs en prod, c'est de la dette immédiate : chaque service ajoute du déploiement, du monitoring, du contrat d'interface. Aucune valeur, beaucoup de coût.
Réglementaire
Pas de droit à l'erreur sur l'essai.
En essai clinique, vous ne pouvez pas livrer un MVP puis ajouter des fonctionnalités : ça rend l'essai caduque. La V1 testée en clinique doit être identique à la V1 commercialisée. L'approche agile classique ne s'applique pas.
Ce que j'ai fait
7 mois, en 4 phases.
Pas une refonte. Une reprise progressive : auditer pendant que l'agence livrait encore, sécuriser le périmètre réglementaire, puis dérisquer la dépendance et stabiliser l'API.
- 01
Audit & conseil pendant la phase agence
Reprise du dossier en cours. Audit de l'architecture livrée, lecture du code, challenge des choix techniques avec l'agence. Sécurisation de l'ISO essai clinique vs mise sur le marché : impossible de livrer un MVP qui évolue, les fonctionnalités évaluées en essai doivent être identiques à celles commercialisées.
Mois 1, 2
- 02
Reprise de l'hébergement & CI/CD
Migration depuis l'infra de l'agence vers OVH public cloud sous agrément HDS, sous contrôle direct du client. Mise en place Coolify, logs avec offuscation patient, monitoring Grafana. Pipeline CI/CD avec isolation stricte des environnements staging et prod, pour ne plus livrer à la main.
Mois 3
- 03
Dérisquage des dépendances agence
Récupération du code, transfert des repos, des accès, de la doc. Stabilisation des API critiques côté Node.js, là où l'agence laissait des bugs sur l'architecture en microservices. Le client devient autonome sur sa stack.
Mois 4, 5
- 04
Stabilisation produit pour les vrais utilisateurs
Renforcement de l'API pour permettre l'inclusion de patients dans l'essai clinique. Logs exploitables avec offuscation HDS, back-office utilisable pour la gestion de l'essai. Le produit passe d'un état démo à un produit utilisable en contexte réglementaire.
Mois 6, 7
Les résultats
Ce qui tourne aujourd'hui.
Infra
< 150 €/mois
Hébergement HDS sous contrôle du client, à un coût bien en dessous des offres santé du marché. Plus de dépendance commerciale à l'hébergeur de l'agence.
Conformité
Logs offusqués
Système de logs exploitable pour le debug, sans exposer la donnée patient. Conforme aux exigences santé, utilisable au quotidien par l'équipe.
Produit
Back-office stable
Outil interne de gestion de l'essai clinique opérationnel. L'équipe peut suivre les inclusions, gérer les patients, sortir des données cliniques sans assistance technique externe.
Autonomie
Stack reprise
Code, repos, accès, doc : tout est sous le contrôle du client. Plus besoin de passer par un intermédiaire pour modifier, déployer ou changer de prestataire.
L'app livrée
Côté patient, ce que ça donne.
L'application iOS pour les patients inclus dans l'essai. Suivi de progression, séances guidées, gamification adaptée au contexte thérapeutique. Données patient hébergées sous HDS, offusquées dans les logs.
La stack
Avec quoi ça tourne.
- iOS SwiftUI.
- API Node.js avec NestJS, architecture microservices héritée de l'agence (à simplifier sur la suite).
- Back-office ReactJS, TypeScript, NestJS. Outil interne pour la gestion de l'essai clinique.
- Infra OVH public cloud sous agrément HDS, orchestration via Coolify, sous contrôle direct du client.
- CI/CD Pipeline automatisé avec isolation stricte des environnements staging et prod.
- Logs & monitoring Grafana, avec offuscation des données patients.
01
Leçon n°1
Le conflit d'intérêts agence est structurel.
Les agences sont rémunérées au projet et vivent de la TMA récurrente ensuite. Leurs incitations sont structurellement désalignées avec les vôtres : aller vite, garder les clés (hébergement, stack maison, doc minimale) et vendre la maintenance derrière.
Pas de conseil réellement neutre possible quand celui qui conseille a intérêt à ce que la complexité augmente. Ça ne veut pas dire que les agences sont mauvaises. Ça veut dire qu'il vous faut quelqu'un côté client pour arbitrer les choix structurants.
02
Leçon n°2
Le chef de projet sans compétences produit, c'est un téléphone arabe.
Sans pilote tech côté client, l'agence vous assigne un chef de projet qui gère des urgences, pas votre roadmap. Les développeurs tournent, les choix techniques deviennent opaques, vous payez 20 à 30% pour une coordination qui ne produit pas de code.
Ce qui change aujourd'hui, c'est qu'une seule personne, équipée d'un stack moderne (Claude Code, agents IA en pair-programming), livre le travail qu'il fallait une équipe agence pour livrer il y a deux ans. Pas d'intermédiaire, pas de téléphone arabe, pas de coût de coordination.
C'est exactement ce qui m'a permis de reprendre seul le dossier DI&Care.
03
Leçon n°3
Le sur-design technique, ça se paie en mois.
L'architecture en microservices a été choisie sur DI&Care "pour scaler". Au stade essai clinique, vous ne scalez pas, vous validez. Chaque microservice ajoute du déploiement, du monitoring, du contrat d'interface, du log à corréler.
C'est de la dette qu'on rembourse en mois de stabilisation. Le bon design technique, c'est celui qui se justifie aujourd'hui, pas celui qui anticipe un futur hypothétique.
Vous êtes dans une situation similaire ?
Projet santé coincé, dépendance à une agence, conformité HDS bancale, décision tech structurante à prendre sans pilote interne. Si l'un de ces sujets vous parle, on peut en parler en 30 minutes.