Ce que vous constatez
Le produit fonctionne et les premiers utilisateurs sont là. Il a été construit vite, avec un assistant de code ou un outil qui génère l'application, parfois par un prestataire parti depuis. Les choix ont servi à démontrer le service, et les contraintes propres à la santé sont restées de côté : hébergement des données, droits d'accès des professionnels, traçabilité des consultations, sauvegarde.
Puis un médecin ou un établissement vous confie les données de ses patients. Vous devenez responsable de leur hébergement et de leur protection, et c'est à vous qu'il demande où elles sont, qui y accède et comment le service reprend après une panne. Les réponses ne sont ni dans le code ni dans la documentation.
Tout réécrire coûte des mois que la startup n'a pas. Garder le code en l'état engage votre responsabilité sur un socle construit sans ces contraintes.
Les causes que je rencontre
- Des secrets dans le dépôt ou dans le code envoyé au navigateur : clés d'API, identifiants de base de données.
- Des droits vérifiés à l'écran et pas sur le serveur. Un utilisateur connecté qui change un identifiant dans l'adresse lit le dossier d'un autre patient.
- Aucun test automatisé, ou des tests générés avec le code, qui vérifient ce que le code fait plutôt que ce qu'il doit faire.
- Des dépendances ajoutées par l'assistant sans que personne les ait choisies ni ne les suive : versions anciennes, paquets abandonnés, licences inconnues.
- Aucun journal des consultations, aucune sauvegarde testée, et un hébergement choisi pour aller vite, hors du cadre prévu pour les données de santé.
L'endroit où se trouvent l'adresse, le code et la base dépend de l'outil qui a servi à construire le produit : les trois architectures du vibe coding en santé.
Le CERT Santé et le CERT-FR ont publié le 2 octobre 2026 un retour d'expérience sur les vulnérabilités des produits du secteur santé. Les secrets mal protégés et le contrôle d'accès défaillant figurent parmi les défauts qu'ils ont relevés chez des éditeurs en exploitation.
Comment je trouve la cause
J'audite le code, l'architecture et l'infrastructure avec votre équipe, je pars de l'état réel de vos parcours, mesuré avec elle, je trouve la cause et j'aide l'équipe à la corriger.
Je commence par la carte du produit : ses composants, le trajet des données de santé, les services tiers et ce que chacun reçoit. Je lis ensuite le code là où il touche ces données : authentification, contrôle des droits, stockage, appels aux modèles d'IA. Je reconstruis le produit depuis un poste neuf, pour vérifier qu'il se construit sans la machine de son auteur. Je confronte enfin ce que je trouve aux textes qui s'appliquent au produit, HDS en tête dès que vous hébergez des données de santé pour le compte de professionnels (ce que HDS demande au logiciel).
Ce que votre équipe obtient
- Les défauts qui bloquent la mise en production, classés par risque et par effort, chacun rattaché au composant qui le porte.
- La part du code à garder, celle à reprendre et celle à réécrire, avec la raison de chaque choix.
- Les premiers contrôles posés avec l'équipe dans la chaîne d'intégration continue : secrets, dépendances, droits d'accès, tests des parcours qui touchent aux données de santé.
- Les questions d'hébergement à trancher, quand elles se posent.
- Pour vos utilisateurs, des données de patients qui restent à leur place, et un service qui repart après un incident.
Une partie du code ne vaut parfois pas la reprise, quand le modèle de données ou l'authentification sont à refaire. Le diagnostic le dit tôt, avant que l'équipe corrige un socle qu'il faudra remplacer.
Ce que j'ai déjà traité
- Serenaid, système IA pour les parents d'enfants neuroatypiques, dont je suis co-fondateur et dont je pilote seul la partie technique : 9 agents d'audit et 797 exigences et critères suivis en continu, dont RGESN, HDS, RGPD et éthique IA ANS.
- Serenaid : l'accessibilité est contrôlée à chaque mise en production. Des tests RGAA automatisés (axe-core) sur les parcours critiques bloquent le déploiement en cas d'anomalie grave. La déclaration d'accessibilité est publiée.
- Chez Kereval, de 2007 à 2011 : qualité et test de logiciels, applicatifs et embarqués.
Questions fréquentes
Faut-il tout réécrire ?
Pas d'emblée. Le diagnostic sépare ce qui tient de ce qui ne tient pas, et l'équipe reprend d'abord ce qui expose les données de santé.
Un code généré par une IA pose-t-il problème en soi ?
Il se relit, se teste et se maintient comme un autre code. Le risque vient de ce qu'il a été écrit sans les contraintes de la santé, puis accepté plus vite que l'équipe ne pouvait le relire.
Et l'hébergement HDS ?
Si c'est la première question, Sonar HDS la cadre en cinq jours. Un hébergement certifié ne retire pourtant ni un secret du dépôt ni un contrôle d'accès absent, les deux chantiers se mènent ensemble.
Mes documents restent-ils confidentiels ?
Oui. Je propose un accord de confidentialité dès le premier échange.
Écoute, cinq à dix jours sur ce problème
Écoute traite un problème précis du produit. Si le diagnostic montre qu'il faut regarder le produit en entier, Sonar prend la suite.
Un blocage qui dure depuis des semaines ? Blocage technique →
À lire aussi : Vibe coding et santé : bien ou pas bien ?
Tout ce qui bloque dans un produit → · Facture d'IA qui dérive