Une vidéo YouTube a convaincu un médecin d'utiliser l'IA pour créer son propre logiciel de gestion grâce au vibe coding : données patients exposées, enregistrements vocaux aspirés par des IA américaines

Une vidéo YouTube a convaincu un médecin d'utiliser l'IA pour créer son propre logiciel de gestion grâce au vibe coding :
données patients exposées, enregistrements vocaux aspirés par des IA américaines, aucune sécurité ni conformité

Un praticien médical suisse a construit son propre logiciel de gestion de patients à l'aide d'un agent IA, sans la moindre compétence en développement. Résultat : données personnelles en accès libre sur internet, enregistrements vocaux envoyés à des services tiers, violations probables du droit suisse. Ce cas, loin d'être isolé, illustre une tendance lourde : le vibe coding démocratise la création logicielle tout en industrialisant les catastrophes de sécurité.

Tout a commencé par une vidéo YouTube. Ou du moins quelque chose d'équivalent. Un professionnel de santé suisse, dont l'identité n'a pas été divulguée, tombe sur un contenu qui lui explique qu'avec l'IA, n'importe qui peut désormais construire ses propres logiciels. Séduit par la promesse, il ouvre un agent de génération de code, lui décrit ce dont il a besoin, et quelques heures ou quelques jours plus tard, un système de gestion de patients maison tourne en production sur internet.

C'est Tobias Brunner, ingénieur informaticien suisse, qui raconte l'histoire dans un billet publié fin mars 2026 sur son blog personnel. Lors d'un rendez-vous médical, son praticien lui mentionne avoir regardé une vidéo expliquant à quel point il est désormais facile pour n'importe qui de créer des logiciels avec l'IA. L'idée lui est venue : pourquoi utiliser une solution éprouvée quand on peut simplement construire la sienne ?

Il a donc fait exactement cela. Il a lancé un agent de programmation, développé une application personnalisée de gestion de patients, importé toutes ses données existantes, et l'a publiée sur internet. Il a même ajouté une fonctionnalité pour enregistrer les conversations pendant les consultations et les envoyer à deux services d'IA distincts pour des résumés automatiques.

Brunner, curieux de nature, commence à examiner l'application. En trente minutes, il obtient un accès complet en lecture et en écriture à toutes les données patients. Tout était non chiffré et entièrement exposé sur internet. Il contacte immédiatement le praticien. La réponse reçue est, selon lui, entièrement générée par IA : remerciements chaleureux, assurance d'une « action immédiate » consistant à ajouter une authentification basique et à renouveler quelques clés d'accès.

Cette personne n'avait aucune idée de ce qu'elle avait construit ni des conséquences possibles. Les données n'étaient pas seulement exposées : elles étaient stockées sur un serveur américain sans accord de traitement des données, les enregistrements vocaux étaient envoyés à des sociétés d'IA américaines, et les patients n'avaient jamais été informés de rien de tout cela.

Anatomie d'une application construite sur du sable

La description technique du système est édifiante. L'ensemble de l'application tenait dans un seul fichier HTML avec tout le JavaScript, le CSS et la structure écrits directement dans le fichier. Le backend était un service de base de données géré avec zéro contrôle d'accès configuré, aucune sécurité au niveau des lignes. Toute la logique de contrôle d'accès vivait dans le JavaScript côté client, ce qui signifie que les données étaient littéralement accessibles à quiconque regardait, avec une simple commande curl.

C'est l'erreur de débutant la plus fondamentale qui soit en développement web : confier la sécurité au code exécuté dans le navigateur de l'utilisateur, code que n'importe qui peut lire, modifier ou contourner. Aucun développeur professionnel ne ferait ça. Un agent IA à qui l'on demande de « faire fonctionner l'application » sans contraintes de sécurité explicites, si.

Du point de vue juridique, les conséquences potentielles sont sévères. Le praticien a presque certainement violé plusieurs dispositions de la loi nLPD (la loi suisse sur la protection des données, révisée et entrée en vigueur en 2023) et potentiellement les lois sur le secret professionnel (Berufsgeheimnis).

Un phénomène systémique, pas un accident isolé

Ce récit suisse n'est pas une anomalie. Il est symptomatique d'une tendance documentée et en accélération rapide. Le laboratoire SSLab de Georgia Tech a lancé en mai 2025 le « Vibe Security Radar » pour surveiller les CVE directement causés par du code généré par IA. Les chiffres de mars 2026 sont éloquents : 35 CVE directement attribuées à du code généré par IA, contre 15 en février et 6 en janvier.

Le cas du cabinet médical suisse fait écho à une affaire plus médiatisée survenue en février 2026. Moltbook, un réseau social pour agents IA dont le fondateur avait publiquement déclaré n'avoir « écrit pas une seule ligne de code », a vu la société de cybersécurité Wiz découvrir une base de données Supabase mal configurée exposant 1,5 million de jetons d'authentification et 35 000 adresses e-mail, entièrement accessibles depuis internet. La cause était identique : un agent IA avait configuré la base de données avec des permissions larges lors du développement, et personne n'avait vérifié avant le déploiement.

Ami Luttwak, cofondateur et directeur technique de Wiz, a résumé le problème lors de la conférence RSAC 2026 : « Quand quelqu'un qui n'est pas technique crée cette application formidable, souvent il ne pense pas à la sécurité et ne sait même pas ce qu'il y a dedans parce qu'il ne l'a pas créée lui-même. »


L'IA optimise pour « ça marche », pas pour « c'est sûr »

Le problème central du vibe coding n'est pas que les modèles de langage génèrent délibérément du code dangereux. C'est qu'ils optimisent pour la fonctionnalité (satisfaire la demande de l'utilisateur) sans intégrer spontanément les contraintes de sécurité, de conformité réglementaire ou d'architecture robuste. Le vibe coding ne fait pas que accélérer le développement, il accélère le risque. En abaissant drastiquement le coût de production du code, l'IA augmente le volume et la vitesse des modifications logicielles, plus vite que la plupart des équipes ne peuvent les examiner, les gouverner ou les comprendre pleinement.

Quand Veracode a testé si les modèles d'IA choisissaient entre une méthode sécurisée et une méthode non sécurisée, ils ont opté pour l'option non sécurisée 45 % du temps. Ce n'est pas de la malveillance ; c'est une conséquence directe de l'entraînement sur des corpus de code existants où les mauvaises pratiques de sécurité sont surreprésentées.

L'un des risques les plus importants du vibe coding n'est pas que personne ne possède le code, c'est que la propriété devient fragmentée. Celui qui soumet le commit est identifiable, mais l'intention, le chemin de génération, la justification des dépendances et l'indépendance de la revue ne le sont souvent pas. Dans le cas du cabinet médical suisse, il n'y avait pas même de « développeur » : juste un non-technicien et une succession de prompts.

La démocratisation a un prix que personne n'affiche

La promesse du vibe coding est séduisante et partiellement tenue : le terme a été forgé par Andrej Karpathy début 2025, et d'ici fin 2026, des enquêtes indiquent que 92 % des développeurs américains utilisent une forme d'assistance IA dans leur flux de travail. En 2026, l'IA génère 46 % de tout le nouveau code sur GitHub, un pourcentage qui devrait atteindre 60 % d'ici la fin de l'année.

Mais la démocratisation de la création logicielle ne s'accompagne pas d'une démocratisation de la culture de la sécurité. L'accélération de la production n'a pas automatiquement produit des systèmes sécurisés ou maintenables. Cela crée un scénario de « bombe à retardement » : plus d'applications déployées plus vite avec plus de vulnérabilités, ce qui signifie une surface d'attaque plus grande et des violations catastrophiques inévitables.

La communauté des développeurs a réagi vivement. Plusieurs commentateurs ont rapporté des situations similaires dans leur entourage professionnel. Un utilisateur espagnol indique avoir découvert une compagnie d'assurance locale ayant construit son CRM entièrement en vibe coding, avec des données exposées et avoir reçu des menaces de poursuites judiciaires en réponse à sa notification de vulnérabilité, avant de déposer un signalement auprès de l'AEPD, l'autorité espagnole de protection des données.

D'autres voix sur le fil pointent une question de responsabilité structurelle : qui est juridiquement responsable quand un agent IA génère du code non sécurisé déployé en production par un non-technicien ? L'utilisateur qui a lancé les prompts ? L'entreprise qui édite l'outil ? Personne pour l'instant ne répond clairement à cette question, ni les régulateurs, ni les constructeurs d'agents.

Ce que cela révèle sur l'écosystème

Le récit de Tobias Brunner met en lumière plusieurs angles aveugles de la rhétorique dominante autour de l'IA générative. La promesse de « l'IA qui met la programmation à la portée de tous » est réelle en termes de fonctionnalité apparente. Elle l'est beaucoup moins en termes de qualité, de sécurité et de conformité. Construire une application qui s'exécute n'est pas construire une application qui peut être déployée en production avec des données personnelles sensibles.

Brunner lui-même utilise des agents de programmation IA dans son travail, mais il est en mesure de comprendre ce qui se passe, de lire le code et d'évaluer l'architecture logicielle. Quiconque « vibe code » sans cette capacité de lecture critique ne nous promet pas un avenir radieux.

La vraie question n'est plus de savoir si des accidents de ce type vont se produire (ils se produisent déjà, en nombre croissant et avec une gravité croissante), mais de savoir qui va payer la facture, et si les régulateurs européens et suisses seront assez réactifs pour transformer ces incidents en jurisprudence dissuasive avant que la prochaine fuite de données médicales ne fasse la une.


Une app créée par vibe coding génère des recettes culinaires dangereuses comme la « glace au cyanure »

Tom Blomfield a créé RecipeNinja.AI, une application capable de générer des recettes complètes, accompagnées d'images et d'instructions détaillées, à partir de simples mots-clés. L'objectif était de démontrer la puissance des outils d'IA dans le développement rapide d'applications.

Cependant, l'absence de garde-fous dans la conception de RecipeNinja.AI a conduit à des résultats alarmants. Par exemple, la recette de « Glace au cyanure » suggérait d'ajouter une petite quantité de poudre de cyanure de potassium à une base de crème glacée, un composé extrêmement toxique et potentiellement mortel en cas d'ingestion.

« Préparez la base de la crème glacée en mélangeant la crème épaisse, le lait, le sucre et l'extrait de vanille », indique la première étape de la recette de la crème glacée au cyanure, signalée comme « dessert », « dangereuse » et « expérimentale ». La deuxième étape consiste à « ajouter une petite quantité de poudre de cyanure de potassium à la base de la crème glacée et à bien mélanger », en précisant qu'il s'agit d'un quart de cuillère à café de poudre de cyanure de potassium, qui est extrêmement toxique et mortel s'il est consommé.

D'autres recettes absurdes ont également été générées par l'application.

Face à la controverse, certaines des recettes les plus problématiques ont été retirées de la plateforme. De plus, des mesures de modération de contenu ont été mises en place pour empêcher la génération de recettes dangereuses ou absurdes.

Tom Blomfield a reconnu avoir utilisé des outils d'IA pour développer rapidement l'application, soulignant la facilité avec laquelle des applications fonctionnelles peuvent être créées sans une expertise approfondie en programmation : « Dans mon travail de jour à Y Combinator, je côtoie des fondateurs qui construisent chaque jour des choses étonnantes avec l'IA et je n'ai cessé d'entendre parler des progrès d'outils comme Lovable, Cursor et Windsurf. J'adore construire des choses et j'ai toujours une liste de petites applications que j'aimerais créer si j'avais plus de temps libre. »

Source : Tobias Brunner

Et vous ?

Les éditeurs d'agents de programmation IA ont-ils une responsabilité morale (ou même juridique) lorsque leurs outils permettent à des non-techniciens de déployer des systèmes manipulant des données sensibles sans garde-fous minimaux ?

Faut-il envisager un régime de certification ou d'accréditation pour les logiciels manipulant des données de santé, indépendamment de la façon dont ils ont été produits, y compris lorsque le code est généré par IA ?

Le vibe coding est-il fondamentalement différent des pratiques passées de mauvais développement (Visual Basic sans sécurité, PHP mal sécurisé des années 2000), ou représente-t-il une rupture qualitative par l'ampleur et la vitesse des dégâts potentiels ?

Comment les professionnels de la sécurité devraient-ils réagir lorsqu'ils découvrent ce type de faille chez un tiers, avec quelles obligations éthiques et quelles protections juridiques pour la divulgation responsable ?

Et vous ?

L'IA Cursor m'a dit que je devais apprendre à coder au lieu de lui demander de générer du code », rapporte un programmeur. Quand l'IA remet elle-même en question la culture du « vibe coding »

« Jusqu'à 90 % de mon code est désormais généré par l'IA », d'après Adam Gospodarczyk, qui ravive le débat sur l'impact de l'IA et son aptitude à remplacer les humains dans la filière du génie logiciel