Les risques cachés du vibe coding : failles de sécurité, clés exposées et code que personne ne peut réparer

Laissez-moi vous raconter l'appel téléphonique le plus fréquent de mon année. Ce n'est plus « pouvez-vous construire ceci ? ». C'est un fondateur, légèrement gêné, qui dit une variante de : « Alors, j'ai construit cette application avec l'IA. Elle marche. Les gens l'utilisent. Et la semaine dernière, il s'est passé quelque chose qui m'a fait réaliser que je n'ai aucune idée si elle est sûre — ni de ce que je ferais si elle cassait. »

Rien dans cet appel ne me gêne, et il ne devrait pas gêner ceux qui le passent. Le vibe coding est une façon légitime et puissante de construire — j'utilise ces outils tous les jours et je propose le vibe coding comme un service moi-même. Mais il y a un fossé entre le marketing (« tout le monde peut créer une application ! ») et la réalité d'ingénierie, et les fondateurs y tombent en masse. Ce texte est la carte de ce fossé : les vrais risques du vibe coding, en langage clair, à peu près dans l'ordre où ils blessent.

Risque n° 1 : des failles de sécurité invisibles

Voici le chiffre qui devrait être imprimé sur la page d'accueil de chaque outil de code IA : lors des tests de sécurité menés par Veracode en 2025 sur plus de 100 modèles d'IA, le code généré par IA a échoué aux tests de sécurité dans 45 % des cas — et quand l'IA avait le choix entre une approche sécurisée et une approche non sécurisée, elle choisissait la non sécurisée dans 45 % des cas aussi. Les modèles plus récents et plus gros n'étaient pas significativement plus sûrs.

Pourquoi ? Parce que l'IA est entraînée à faire fonctionner les choses, et que la sécurité est en grande partie l'art de faire en sorte que les choses ne fonctionnent pas pour les mauvaises personnes. Concrètement, les échecs que je retrouve dans les applications construites par IA, encore et encore :

• Des secrets exposés. Clés API, identifiants de paiement et mots de passe de base de données rangés dans le code front-end, où n'importe quel visiteur peut les lire. Le directeur de recherche de Gartner a qualifié la fuite de secrets codés en dur via des applications « vibe codées » de risque numéro un du moment pour les entreprises. Les scans d'applications « vibe codées » publiques trouvent des centaines de secrets vivants dans des dépôts publics.

• Des bases de données grandes ouvertes. Les règles d'accès qui décident qui peut lire quoi sont la première chose que les constructeurs IA bâclent. Résultat classique : n'importe quel utilisateur connecté peut récupérer les données de tous les autres avec une requête légèrement modifiée. L'application « fonctionne » dans chaque démo — et fuit pendant tout ce temps.

• Une validation des entrées absente. Des formulaires et des champs qui acceptent n'importe quoi, ouvrant la porte aux attaques XSS et aux injections — exactement les catégories où le code IA échoue le plus souvent aux tests.

• Un théâtre d'authentification. Des écrans de connexion qui ont l'air réels, mais dont les flux de réinitialisation, la gestion des sessions ou les contrôles de permissions laissent passer un attaquant compétent en un après-midi.

Rien de tout cela n'est visible depuis le fauteuil de l'utilisateur. C'est ce qui le rend dangereux : l'application a l'air terminée.

Risque n° 2 : ça marche jusqu'au moment de grandir

Les outils IA construisent pour la démo qu'ils ont sous les yeux. Ils récupèrent des tables entières pour afficher dix lignes. Ils re-rendent des pages entières pour un mot qui change. Ils choisissent la structure de base de données la plus facile aujourd'hui, qui devient un mur quand vous ajouterez la fonctionnalité évidente le mois prochain.

Les problèmes de performance sont la version aimable de ce risque. La version désagréable est architecturale : quand chaque fonctionnalité a été générée isolément, le code devient trois demi-systèmes dans un trench-coat. Ajouter des rôles utilisateurs, ou des paiements, ou une deuxième langue, signifie soudain négocier avec les contradictions que l'IA a laissées dans quarante fichiers. C'est ce que les développeurs appellent la dette technique, et les applications « vibe codées » l'accumulent à la vitesse de l'IA.

Risque n° 3 : personne ne peut le maintenir — pas même vous

Voici le risque silencieux. Avec du code écrit classiquement, quelqu'un l'a compris au moins une fois : le développeur. Avec une application « vibe codée », potentiellement personne ne l'a jamais compris — pas vous (vous ne l'avez jamais lu) et pas l'IA (elle ne conserve pas un modèle de votre système entier entre les sessions ; elle le re-dérive et parfois se contredit).

Les conséquences pratiques arrivent vite :

• Un bug apparaît et chaque correction casse autre chose, parce que personne ne connaît les dépendances.

• Vous engagez un développeur, et sa première semaine est de l'archéologie, pas du progrès.

• L'outil IA d'origine change ses prix ou supprime une fonctionnalité, et vous découvrez quelle part de « votre » produit vivait dans sa plateforme.

Je développe ce qui se passe ensuite — et comment un sauvetage fonctionne concrètement — dans comment réparer une application « vibe codée » et la rendre prête pour la production.

Risque n° 4 : conformité et confiance

Si votre application touche des données personnelles — et au Maroc, en Europe ou ailleurs, les e-mails et numéros de téléphone sont des données personnelles — vous avez des obligations légales sur leur stockage et leur protection. « C'est l'IA qui l'a construit comme ça » n'est pas une défense que vos utilisateurs, vos partenaires ou les régulateurs acceptent. Une seule fuite depuis une application non auditée peut terminer la réputation d'une jeune entreprise avant même que son marketing ait eu une chance.

La check-list que j'applique à chaque application construite par IA

Quand un fondateur m'apporte un produit « vibe codé », voici le premier passage — et c'est un auto-audit correct si vous êtes assez technique pour regarder :

1. Cherchez dans tout le code et son dépôt public les clés, jetons et mots de passe. Faites tourner tout ce qui est trouvé.

2. Testez les règles de la base de données : l'utilisateur A peut-il lire les enregistrements de l'utilisateur B en changeant un identifiant ? Ce seul test attrape la pire des blessures.

3. Vérifiez l'authentification pour de vrai : réinitialisation du mot de passe, expiration des sessions, et si les pages d'administration sont protégées côté serveur, pas seulement cachées du menu.

4. Cherchez les fonctionnalités dupliquées et le code mort — les signes révélateurs que l'IA a reconstruit au lieu de réutiliser.

5. Faites un test de charge élémentaire : quelques centaines d'enregistrements dans les tables principales, puis utilisez réellement l'application.

6. Confirmez que vous pouvez tout exporter — code et données — dans des comptes qui vous appartiennent.

Si vous ne pouvez pas dérouler cette liste vous-même, c'est normal, et c'est précisément le vide que mes audits vibe coding existent pour combler : vous gardez la vitesse à laquelle vous avez construit, je trouve ce que l'IA a manqué.

Alors, faut-il arrêter le vibe coding ?

Non — et je me méfie des développeurs qui disent oui, parce que cela signifie généralement qu'ils défendent leurs tarifs, pas votre produit. Le vibe coding est une superbe façon de créer des prototypes, des outils internes et des premières versions. Le risque n'est pas l'outil ; c'est de sauter le moment où un professionnel regarde le résultat avant que de vrais utilisateurs, de l'argent réel et des données réelles en dépendent.

Construisez avec les vibes. Lancez avec de la vérification. Cette combinaison est, honnêtement, la façon sûre de livrer un logiciel la plus rapide qui ait jamais existé. Si vous avez construit quelque chose et que vous voulez cette vérification avant de passer à l'échelle, envoyez-moi le lien — l'audit est rapide, et il coûte beaucoup moins cher que l'alternative.