La note précédente défendait le cas général. Celle-ci est concrète : voici des plateformes construites ainsi, ce qui leur est arrivé, et ce que leurs défaillances avaient en commun.
J'ai écarté l'incident que tout le monde cite. La fuite de l'application Tea, en juillet 2025, a exposé environ 72 000 images, dont quelque 13 000 pièces d'identité et selfies, depuis un bucket Firebase non sécurisé. On l'invoque sans cesse comme le désastre emblématique du vibe coding. Le communiqué de Tea précise que le code concerné est antérieur à février 2024, avant que cette façon de travailler ne soit viable pour un système de ce type. C'était une erreur de configuration, et une grave, mais ce n'est pas une preuve pour l'argument développé ici, et je ne vais pas prétendre le contraire.
Les quatre suivants, si.
EnrichLead : mort une semaine après le tour d'honneur
En mars 2025, le fondateur d'EnrichLead a annoncé publiquement que son produit SaaS avait été bâti avec « zéro ligne écrite à la main », intégralement via un éditeur IA. La publication est devenue virale.
En deux jours, l'application était attaquée. Les clés d'API se trouvaient dans le frontend. Aucune autorisation sur les points d'entrée, aucune limitation de débit, aucune validation des entrées, et la base de données était joignable. Les attaquants ont contourné l'abonnement, manipulé les données et épuisé les quotas d'API payants. Le produit a été fermé définitivement en une semaine.
Notez ce qui ne s'est pas produit : personne n'a eu besoin d'un exploit astucieux. Chacun de ces points est un contrôle qu'un ingénieur qui relit ajoute sans qu'on le lui demande, parce qu'il sait que le point d'entrée est joignable depuis l'internet ouvert. Personne n'a demandé, donc personne ne les a ajoutés.
Lovable : CVE-2025-48757 et 170 applications en ligne
Lovable est un constructeur d'applications par IA très répandu. En 2025, la référence CVE-2025-48757 lui a été attribuée pour avoir généré des applications dont la Row Level Security était absente ou insuffisante sur leurs bases Supabase.
Conséquence : la clé publique cliente livrée au navigateur permettait d'interroger directement les tables. Listes complètes d'utilisateurs, enregistrements de paiement et identifiants stockés pouvaient être lus sans la moindre connexion. Un scan de 1 645 applications Lovable en a trouvé 170 avec des bases exposées — plus de dix pour cent — sur 303 points d'entrée vulnérables.
C'est le cas important, parce qu'aucun de ces 170 créateurs n'a commis une erreur individuelle. Ils ont hérité du réglage par défaut de la plateforme. Le code généré paraissait terminé et se comportait correctement à tous les tests que son auteur aurait songé à faire. La pièce manquante était une politique de base de données à laquelle personne ne l'a invité à penser, dans une couche qu'il n'a jamais vue.
Base44 : une authentification qu'on pouvait simplement sauter
Base44 est une plateforme de création d'applications par IA, rachetée par Wix en 2025. En juillet 2025, Wiz Research y a révélé une faille : deux points d'entrée d'API — l'inscription et la vérification du code à usage unique — n'exigeaient aucune authentification, et l'identifiant d'application nécessaire pour les atteindre était publié dans l'URL et le manifeste de l'application elle-même.
Cela suffisait à se créer un compte vérifié sur l'application privée d'un tiers. Wiz a confirmé que le contournement fonctionnait contre des applications d'entreprise hébergeant des chatbots internes, des bases de connaissances, des opérations RH et des données personnelles — des applications que leurs propriétaires croyaient restreintes au SSO de leur société.
Wix a corrigé en 24 heures et n'a trouvé aucune trace d'exploitation, ce qui est une réaction réellement bonne. La leçon est ailleurs : les clients n'avaient aucun moyen de savoir. Ils avaient configuré le SSO. La plateforme leur disait que l'application était privée. Elle ne l'était pas, et rien dans leur propre code n'était fautif.
SaaStr et Replit : la base qu'il ne fallait pas toucher
En juillet 2025, Jason Lemkin, de SaaStr, a passé neuf jours à construire publiquement sur l'agent IA de Replit. Pendant un gel du code explicite, avec des instructions répétées en langage naturel de ne pas toucher à la production, l'agent a supprimé la base de données de production — les enregistrements de plus de 2 400 dirigeants et entreprises.
Il a ensuite généré des données fabriquées à la place de ce qu'il avait détruit et a annoncé que la restauration était impossible. C'était faux ; les données étaient récupérables. Replit a livré en quelques jours la séparation dev/production, un mode planification seule et la restauration en un clic.
La suppression est la moitié la moins grave de l'histoire. La plus grave est que l'agent a affirmé avec assurance quelque chose de faux sur l'état du système, sans qu'aucun moyen indépendant permette de le vérifier. Si votre seul modèle de votre propre plateforme est celui que l'agent vous raconte, vous ne pouvez pas auditer cette affirmation.
Le motif récurrent
Trois de ces quatre cas sont des défaillances d'autorisation, et le quatrième une opération destructrice sans garde-fou. Pas des bogues exotiques. La catégorie la plus élémentaire qui soit.
Ils ont la même forme. L'application fonctionnait. Elle passait tous les tests que son auteur exécutait, parce que son auteur testait le chemin qu'il avait décrit. Ce qui manquait, c'est la couche située sous la description — qui peut lire cette ligne, qu'est-ce qui est joignable sans session, qu'est-ce qui ne doit jamais s'exécuter en production — et cette couche est invisible précisément parce que personne ne l'a spécifiée.
Un modèle ne sait pas que votre point d'entrée est exposé à internet, que votre fichier clients est votre actif le plus précieux, ou que cette table relève du RGPD. On ne le lui a pas dit. Il ne le demandera pas.
Où passe la limite
Rien de tout cela n'est un argument contre l'IA en développement. J'utilise ces outils tous les jours et ils m'ont rendu bien plus rapide.
La limite, c'est la propriété intellectuelle du système. Quelque part, il faut une personne capable de répondre, de mémoire, qui peut lire chaque table, ce qui se passe quand chaque intégration tombe, et ce qui s'exécute quand deux requêtes arrivent ensemble. Cette personne peut tout à fait avoir généré l'essentiel du code. Ce qu'elle ne peut pas, c'est ignorer les réponses.
Si votre plateforme détient des données clients, encaisse des paiements ou vous mettrait dans l'embarras le jour d'une fuite, cette personne doit exister et doit être nommée. Demandez à n'importe quel prestataire de qui il s'agit. Si la réponse est l'outil, vous avez le montage qu'avait EnrichLead le jour de sa publication triomphale.