Bistrot Web Bistrot Web — accueil
Façade de restaurant élégante dont la porte de service entrouverte révèle une arrière-cuisine en désordre
← Vibe coding 🔐 Sécurité

Votre app est belle. Est-elle solide ?

Le vibe coding produit des applications qui marchent et qui plaisent. La sécurité, elle, ne se voit pas à l'écran — c'est précisément le problème. Voici les six pièges qui reviennent, et comment vérifier chez vous.

Ce n'est pas un procès de l'IA

Disons-le d'emblée : rien de ce qui suit n'est un argument contre le vibe coding. Les pièges décrits ici sont exactement ceux d'un développeur débutant — l'IA a appris sur le code existant, y compris ses mauvais exemples, et elle reproduit les patterns les plus fréquents, pas les plus sûrs.

La différence est ailleurs : là où un débutant mettait six mois à produire sa première application, l'IA la produit en une heure. Le volume d'applications mises en ligne sans revue explose — et avec lui le nombre de clés exposées, de bases de données ouvertes et de formulaires injectables. Ce n'est pas une question de talent, c'est une question de vérification : personne n'a regardé derrière le décor.

Les six pièges classiques

Six familles de problèmes reviennent dans la quasi-totalité des applications vibe-codées que nous examinons. Aucune n'est visible en utilisant l'application normalement.

🔑Clés API et secrets en dur

L'IA a besoin d'une clé pour brancher un service (paiement, cartes, envoi d'emails) — et la met souvent là où c'est le plus simple : dans le code. Si ce code est servi au navigateur ou poussé sur un dépôt public, la clé est publique. Des robots scannent les dépôts en continu ; une clé exposée est typiquement exploitée en quelques minutes, avec votre carte bancaire derrière.

🚪Authentification maison

Un écran de connexion qui fonctionne n'est pas une authentification sûre. Les classiques du code généré : mots de passe stockés mal hachés (voire en clair), sessions prévisibles, page d'administration accessible à qui devine l'adresse, et vérifications faites côté navigateur seulement — c'est-à-dire contournables par n'importe qui ouvre les outils de développement.

💉Injections (SQL, XSS)

L'application fait confiance à ce que tape l'utilisateur : un champ de recherche qui aboutit tel quel dans une requête SQL, un commentaire affiché sans échappement. Ce sont les attaques les plus anciennes du web — et elles reviennent dans le code généré, parce que l'IA reproduit aussi les mauvais exemples de son entraînement.

📦Dépendances gelées

Une application générée embarque souvent des centaines de paquets tiers, figés à la date de génération. Personne ne les mettra à jour spontanément. Les failles découvertes ensuite dans ces paquets — il y en a chaque semaine — restent ouvertes dans votre application, silencieusement.

⚖️Données personnelles sans cadre

L'app collecte des emails, des noms, parfois plus — parce que c'était dans la description. Mais qui a consenti à quoi ? Où est la politique de confidentialité ? Comment supprimer un compte ? Le RGPD s'applique dès le premier utilisateur réel, et l'IA ne le mentionnera pas si vous ne le demandez pas.

💾Aucune sauvegarde

La base de données vit sur la même machine que l'application, sans copie ailleurs. Un disque qui meurt, une commande de trop, un piratage — et tout disparaît : les données de vos clients comme le fruit de votre travail. Une sauvegarde jamais testée en restauration compte pour zéro.

Auto-diagnostic en sept questions

Avant d'ouvrir votre application à de vrais utilisateurs, prenez dix minutes pour répondre honnêtement à ces sept questions :

Une seule réponse incertaine suffit pour mériter une vérification — c'est souvent la question qu'on n'arrive pas à trancher soi-même qui cache le vrai problème.

La suite logique

Un regard de pro, avant les vrais utilisateurs.

Notre audit d'application vibe-codée passe en revue les six familles ci-dessus sur votre code réel : secrets, authentification, entrées utilisateur, dépendances, données personnelles, sauvegardes et hébergement. Vous recevez un rapport priorisé en français clair, les corrections des points critiques, et un plan chiffré pour le reste — dès 799 € HT, avec validation en staging avant toute mise en production.

Questions fréquentes

Comment savoir si mon application expose des données ?

Trois vérifications rapides donnent déjà un bon signal : ouvrir le code source de la page dans le navigateur (clic droit → afficher la source) et chercher des chaînes ressemblant à des clés (« sk- », « api_key », « secret ») ; tenter d'accéder aux adresses d'administration évidentes (/admin, /dashboard) depuis une navigation privée, déconnecté ; et vérifier si votre dépôt de code est public. Ces trois tests ne prouvent pas que tout va bien, mais s'ils échouent, il faut agir avant toute mise en ligne.

L'IA peut-elle auditer son propre code ?

Elle y contribue utilement — demander une revue de sécurité à un assistant détecte une partie des problèmes évidents. Mais elle garde en revue les mêmes angles morts qu'en écriture : elle ne connaît ni votre contexte (qui utilise l'app, quelles données, quelles obligations légales), ni votre hébergement réel, ni ce qui se passe en dehors du code (sauvegardes, DNS, comptes). Un audit professionnel combine l'outillage automatisé et l'expérience de ce qui casse réellement en production.

Que coûte une fuite de données pour une petite entreprise ?

Au-delà du dommage commercial — la confiance des clients ne se répare pas avec un correctif — le RGPD impose de notifier la CNIL sous 72 heures et, selon la gravité, d'informer chaque personne concernée. S'ajoutent le temps de gestion de crise, la remise en état, et le risque de sanction. Le déséquilibre est frappant : les vérifications qui évitent la plupart des fuites se comptent en heures, leurs conséquences en mois.