Bien pour une démo, tant qu'aucune donnée réelle n'y entre. Plus assez dès qu'un professionnel de santé y saisit les données de ses patients. Entre les deux, la réponse dépend de l'endroit où se trouvent l'adresse, le code et la base de l'application.
Le vibe coding s'installe en santé
En février 2026, un cardiologue interventionnel en exercice a fini troisième d'un concours mondial de programmation avec une application de suivi des patients après consultation. La revue NEJM AI, qui rapporte le fait le 4 novembre 2026, note que beaucoup des premiers du classement étaient des experts de leur domaine, sans formation d'ingénieur.
Le mouvement dépasse ce cas. Un groupe de cliniciens a publié en avril 2026 une revue qui présente le vibe coding à leurs confrères. Une équipe de recherche en informatique de santé relève dans Frontiers in Artificial Intelligence, en 2026, des outils pédagogiques et un nomogramme chirurgical construits ainsi puis publiés dans des revues médicales. Elle décrit une adoption en grande partie invisible.
De quoi parle-t-on ?
Le terme vient d'Andrej Karpathy, en février 2025. Il désignait une façon de programmer où l'on décrit ce que l'on veut à une IA et où l'on accepte le code produit sans le lire. Le dictionnaire Collins en a fait son mot de l'année 2025.
Le mot recouvre aujourd'hui des pratiques très différentes. Un médecin qui décrit un tableau de suivi à un générateur d'applications vibe code. Un développeur qui confie l'écriture à un assistant, relit et teste, vibe code aussi. Sur Serenaid, dont je pilote seul la partie technique, je travaille de cette façon.
Deux questions séparent ces pratiques mieux que le mot : qui vérifie ce que l'IA a écrit, et où l'application tourne ensuite. La suite de l'article porte sur la seconde.
Ce que le vibe coding apporte
Les soignants et les spécialistes d'un métier connaissent le besoin et ce qui fait perdre du temps au quotidien. Ils sont bien placés pour décrire un logiciel utile. La revue des cliniciens le dit à sa façon : leurs problèmes d'organisation sont souvent trop particuliers pour intéresser un éditeur.
Les cycles raccourcissent aussi. Une fonctionnalité arrive en quelques jours, et une erreur signalée par un utilisateur se corrige dans la semaine. Pour une startup, c'est le moyen de montrer un service à ses premiers utilisateurs avant d'avoir une équipe.
Ces gains sont réels au stade de la démonstration. NEJM AI rappelle qu'entre une démo qui marche et un produit sûr, prêt pour un usage clinique, il faut encore des ingénieurs, des spécialistes de la sécurité et de la réglementation. C'est la situation d'un MVP santé codé vite, à industrialiser.
Plusieurs usages du vibe coding en santé
Le vibe coding sert à des gens différents, et chaque usage appelle sa propre réponse.
Le premier se passe dans un établissement. Un soignant, un cadre ou une équipe informatique d'un CHU fabrique un outil pour son service, en dehors des circuits habituels. On parle d'informatique de l'ombre, ou de shadow IA quand l'outil est une IA. Le dossier de réanimation de l'exemple Grok en relève. La réponse revient à l'établissement : savoir quels outils sont utilisés, retrouver leurs applications, fixer ce qui peut y entrer.
Le second est celui d'un éditeur. Une équipe construit un produit de santé pour des clients, avec ces mêmes outils ou avec un assistant de code. Elle choisit son socle, et la suite de cet article s'adresse à elle.
Un fondateur passe parfois du premier au second sans s'en apercevoir, le jour où la maquette montrée à un médecin reçoit ses vrais patients.
Où sont l'adresse, le code et la base ?
Les outils se rangent en trois familles, et la réponse change de l'une à l'autre.
Le même contenu en tableau :
| Application hébergée par l'outil | Générateur relié à un backend | Assistant de code | |
|---|---|---|---|
| Exemples | Grok Build, Replit | Lovable, Bolt | Claude Code, Cursor, Codex |
| Adresse | un nom sous le domaine de l'outil | un nom sous le domaine de l'outil, ou le vôtre | votre domaine |
| Code | chez l'outil | chez l'outil ou dans votre dépôt | votre dépôt |
| Base de données | créée et hébergée par l'outil | un service à part, souvent Supabase | chez l'hébergeur que vous choisissez |
| Ce qui ferme l'accès | un réglage de partage | des règles d'accès écrites dans la base | votre code et vos tests |
Dans la première famille, tout dépend d'un réglage, et l'hébergement est celui de l'outil.
Dans la deuxième, la clé de la base est livrée au navigateur, par conception. La protection de chaque ligne repose sur les règles d'accès de la base. La vulnérabilité CVE-2025-48757, publiée en 2025, décrit des projets générés par Lovable dont ces règles manquaient ou ne suffisaient pas.
Dans la troisième, rien n'est exposé d'office et rien n'est fourni : l'authentification, les droits, la sauvegarde et le journal sont à demander un par un. C'est aussi la seule où l'outil ne décide pas de l'hébergement.
Une application passe ensuite par quatre états : brouillon dans la conversation, publiée par lien, adresse relevée par des tiers, puis porteuse de données réelles. Le troisième arrive sans que son auteur ait rien fait.
Demander « sécurisé » dans le prompt suffit-il ?
L'exemple de Grok répond. L'outil avait ajouté une connexion sans qu'on la lui demande, et cette connexion laissait entrer tout le monde. Une consigne générale produit un code qui a l'apparence de la sécurité.
Ces outils sont faits pour publier et partager vite, et leurs réglages vont dans ce sens. Le générateur d'applications de ChatGPT, que Claroc a testé aussi, règle le partage sur « Only me » : l'ouverture par défaut est un choix de produit.
Il faut donner à l'outil de vraies règles, précises et vérifiables, dès le premier jour, dans le prompt ou dans le fichier d'instructions du projet. Par exemple : chaque route vérifie le droit sur le serveur, aucun secret ne part dans le code envoyé au navigateur, aucune table n'existe sans règle d'accès. Chaque règle a son test, lancé à chaque version.
C'est là que l'ingénierie logicielle et la connaissance des domaines font la différence : sécurité, sobriété, souveraineté. Une règle ne se demande que si on la connaît, et une équipe sans développeur expérimenté ne saura pas lesquelles poser.
À quel moment changer de socle ?
Je raisonne par paliers. Ce découpage est le mien, faute de seuil publié sur lequel m'appuyer.
La démo. Des données inventées, quelques personnes qui regardent. Tous ces outils conviennent, à une condition : aucune donnée réelle, même pour essayer, et un accès réglé sur soi seul ou sur invitation.
La bêta. De vrais utilisateurs, donc des données personnelles. Les droits se vérifient sur le serveur, l'accès est fermé par défaut, les secrets sortent du code, et l'équipe sait chez qui se trouve la base. Si un professionnel de santé y saisit les données de ses patients, vous les hébergez pour son compte, quel que soit le nombre de comptes : ce que HDS change à l'architecture d'un MVP. Sonar HDS cadre ce choix d'hébergement en cinq jours.
Les premiers clients, autour d'une centaine d'utilisateurs. Le produit doit repartir après une panne et répondre aux questions d'un établissement. Il lui faut des tests automatisés sur les parcours qui touchent aux données, un journal des consultations, une sauvegarde restaurée au moins une fois et un hébergement choisi pour durer.
Le nombre d'utilisateurs compte moins que la nature des données. La première donnée de santé réelle fait changer de palier, même avec dix comptes.
Vous avez un MVP, que faire maintenant ?
Trois vérifications tiennent en une heure. Relisez le réglage d'accès de chaque application publiée. Ouvrez son adresse dans une fenêtre privée, sans compte. Cherchez chez qui se trouve la base, et lisez le certificat de cet hébergeur.
La suite dépend de votre produit et du palier où il se trouve. On en discute : Réserver 30 minutes.
Sources
- NEJM AI, « Vibe Coding versus Clinical Reality », 4 novembre 2026.
- Ong et al., « Vibe coding for clinicians: democratising bespoke software development for digital health innovation », arXiv 2604.22604, 24 avril 2026.
- Alqheedan et Alzughaibi, « The VIBE-HI framework », Frontiers in Artificial Intelligence, 2026.
- Claroc, « GhostShares » sur les applications Grok Build, 10 novembre 2026.
- The Decoder, « Grok-built apps exposed patient data, plaintext passwords, and SpaceXSI's own sales pipeline », 11 novembre 2026.
- CVE-2025-48757, règles d'accès insuffisantes dans des projets générés par Lovable, 2025.