Le vibe coding ne doit pas devenir le far west

Je vais commencer par dire d'où je parle, parce que la suite dépend entièrement de ça. Depuis quelques mois, je construis à nouveau avec le vibe coding. L'IA m'a rendu un truc que j'avais perdu, le plaisir de fabriquer quelque chose et de le voir tourner le soir même. Avec Claude Code, je suis en train de migrer tous mes sites web depuis WordPress de cette manière, je construits des applications qui me servent à titre personnel ou dans des projets clients ou annexes; et ce qui m'aurait pris des semaines me prend désormais quelques heures. Donc non, je ne vais pas vous expliquer que c'est mal. Je le fais, j'aime ça, et je pense que cette démocratisation est une bonne nouvelle.

Sauf que je vois passer énormément d'applications en ce moment, et chez la quasi-totalité des gens qui se lancent, il y a deux trous béants. La conformité et la sécurité. Ce sont deux sujets distincts, que presque tout le monde confond, et l'un comme l'autre peut tuer un projet plus sûrement qu'un concurrent. Le problème n'a jamais été le vibe coding en lui-même. Le problème, c'est qu'on s'installe sur un territoire tout neuf sans la moindre règle. Une frontière qui va se peupler quoi qu'on en dise, parce qu'elle est désirable et que plus personne ne reviendra en arrière. La seule vraie question est de savoir si on la civilise, ou si on s'y fait descendre.

Ce n'est plus une histoire de bricoleur dans son garage

On pourrait croire que je parle de quelques amateurs isolés. C'est l'inverse, et c'est ce qui rend le sujet sérieux. Une enquête de la société RedAccess, relayée et vérifiée en mai par Axios et WIRED, a recensé près de 380 000 applications construites avec des outils comme Lovable, Replit, Base44 ou Netlify, toutes accessibles publiquement sur le web. Environ cinq mille exposaient des données sensibles. Plus de deux mille laissaient fuiter des informations d'entreprise, opérationnelles ou personnelles, posées en clair, sans le moindre contrôle d'accès. Les journalistes ont vérifié des cas bien réels au passage : une compagnie maritime dont l'application listait quels navires arrivaient dans quels ports, les données financières internes d'une banque brésilienne, les conversations client non anonymisées d'un fournisseur de meubles britannique, des essais cliniques d'un acteur de la santé. Beaucoup de ces applications étaient même indexées par Google, donc trouvables par n'importe qui. Aucune attaque sophistiquée là-dedans, aucune exploitation nécessaire. Juste des portes laissées ouvertes.

Et regardez le détail qui dit tout. Sur plusieurs de ces outils, les réglages de confidentialité rendaient l'application publique par défaut, à charge pour la personne de basculer en privé si elle y pensait. La plupart n'y pensaient pas, parce qu'elles ne savaient même pas que le réglage existait.

Surtout, ce ne sont pas que des indépendants. C'est aussi le responsable marketing qui se bricole un tableau de suivi de campagne et le branche sur l'outil de BI où vivent les vrais chiffres. C'est l'équipe finance qui aspire les factures dans un dashboard avant le board du vendredi. Deux populations très différentes, le solo qui shippe son produit et le salarié qui résout un problème plus vite que sa DSI, et exactement les deux mêmes trous chez l'une et chez l'autre. La faille la plus banale que l'enquête a remontée, l'accès administrateur ouvert par défaut à quiconque tombe sur l'URL, c'est mot pour mot le grand classique de la sécurité applicative, l'utilisateur A qui peut lire les données de l'utilisateur B.

Ce qui se joue ici a un nom, c'est l'écart entre savoir construire et comprendre ce qu'on a construit. L'outil a effacé le frottement qui, avant, vous forçait à apprendre avant de déployer. On produit désormais sans avoir jamais eu le modèle mental qui ferait poser la seule question qui compte, qui peut atteindre ça et avec quels droits. La compétence n'a pas disparu, elle a juste cessé d'être un prérequis pour mettre en ligne. C'est précisément là que la frontière devient dangereuse.

La conformité, ce truc que personne ne veut entendre

Commençons par elle, parce que c'est la partie qu'on a envie d'ignorer. Dès que votre application est en ligne, vous collectez des données. Ça démarre avec un simple bandeau cookies, et ça continue avec chaque formulaire, chaque inscription, chaque achat que vous stockez. À partir de là, vous avez des obligations, et l'idée n'est pas de vous transformer en usine à paperasse.

Au fond, la conformité tient en une phrase. Quelqu'un vous a confié ses données, il vous a fait confiance, et votre travail consiste à être à la hauteur de cette confiance et à pouvoir le prouver. Vous n'avez pas besoin du niveau juridique d'une multinationale. Vous avez besoin d'être à la hauteur de ce qu'on vous a confié.

Concrètement, avant de pousser en production, rédigez de vraies mentions légales et une vraie politique de confidentialité, pas un copier-coller ramassé au hasard sur un site qui vous ressemble vaguement. Et sachez répondre à trois questions sans hésiter : quelles données je collecte, où elles sont stockées, combien de temps je les garde. Si l'une des trois vous laisse muet, vous n'êtes pas prêt à lancer, vous êtes prêt à avoir des ennuis. Dernier réflexe, si vous hébergez hors Union européenne, vérifiez ce que ça implique, parce que ça implique beaucoup de choses que vous n'avez pas envie de découvrir après coup.

La sécurité, et la bonne nouvelle qui va avec

La bonne nouvelle, c'est que vous pouvez sécuriser correctement une application sans être expert. Si vous regardez les grandes fuites françaises des derniers mois, les failles exploitées n'étaient presque jamais sophistiquées. C'étaient des classiques de l'OWASP, des erreurs qu'on apprend à éviter dès qu'on accepte d'y passer un minimum de temps. Il faut juste comprendre ce que vous déployez au lieu de recopier aveuglément ce que l'IA vous sort.

Quelques réflexes qui changent presque tout. Ne mettez jamais une clé d'API ou un secret en dur dans votre code, et activez le scan de secrets de GitHub, qui vous alerte si vous le faites malgré vous. Vérifiez vos contrôles d'accès, parce que la fuite la plus courante aujourd'hui reste celle où un utilisateur accède aux données d'un autre, et c'est exactement ce qu'on retrouve à grande échelle dans l'enquête citée plus haut. Ne faites jamais confiance à ce que l'utilisateur envoie, validez tout côté serveur. Et servez-vous de l'IA pour la défense autant que pour la construction. Demandez-lui de relire votre code en cherchant les failles, pas seulement de produire des fonctionnalités. Elle est aussi douée pour traquer un problème de sécurité que pour générer une page, à condition qu'on le lui demande explicitement.

Et le jour où l'application commence à générer un vrai revenu, plusieurs milliers d'euros par mois, faites-la tester par des professionnels de l'offensif. Un test ciblé de trois à cinq jours suffit pour démarrer. Je vois trop d'applications qui encaissent un chiffre d'affaires réel et qui continuent de négliger ça, alors qu'un seul mois de revenu paierait le test. Le calcul est vite fait.

Civiliser la frontière du vide coding, pas la fermer

Une dernière distinction, parce qu'elle vous évitera de tourner en rond. Conformité, sécurité et résilience ne sont pas la même chose. La conformité prouve que vous traitez les données comme vous le devez. La sécurité empêche qu'on vous les prenne. La résilience vous fait tenir debout le jour où quelque chose casse quand même. Les confondre, c'est cocher une case en croyant en couvrir trois, et c'est souvent comme ça qu'on se fait avoir.

Ce qui me rassure, c'est que même les institutions ont compris dans quel sens souffle le vent. Le patron du centre britannique de cybersécurité a profité de la dernière RSA Conference pour appeler l'industrie à rendre ces outils sûrs dès la conception, en reconnaissant ouvertement que l'interdiction n'était pas une option crédible. Autrement dit, on ne ferme pas la frontière, on la rend vivable. Elle finira peuplée de toute façon. La seule inconnue, c'est si elle l'est par des gens qui ont appris à se protéger, ou à la dure, par les fuites et le régulateur.

L'IA vous permet de construire vite. Servez-vous-en aussi pour construire solide. C'est la seule version du vibe coding qui tient dans la durée.