Le Piège de la Vitesse dans le Développement IA

Soyons honnêtes : on a tous craqué. Un dimanche après-midi à prompter Lovable, Bolt ou Cursor, et hop, à l'heure du dîner on a une URL qui fonctionne. Ça ressemble à de la magie. Le hosting est inclus, le SSL arrive tout seul, et notre petit projet secondaire devient soudain réel.

Mais voici la vérité qui me revient sans cesse : livrer vite ne veut pas dire livrer sécurisé. Et en tant que témoin de cette révolution du "vibe coding", je pense qu'on devrait parler de ce que ce pipeline "après-midi → URL" laisse vraiment derrière lui.

Une étude récente a scanné 155 applications "vibe codées" lancées publiquement par leurs créateurs. Quatre-vingt-dix-neuf étaient encore en ligne et analysables. Les résultats ? Équilibrés entre encourageant et préoccupant — et ils devraient changer notre façon d'aborder les checklists de pré-lancement.

La Bonne Nouvelle : Les Secrets Restent Cachés

Ce qui m'a agréablement surpris : seulement 1% des applications scannées exposaient de vraies clefs secrètes au navigateur.

Pas de clefs API OpenAI qui grillent le budget de quelqu'un d'autre. Pas de credentials AWS flottant dans du JavaScript côté client. Pas de clefs Stripe en production prêtes à vider un compte en banque.

Ça m'apprend quelque chose d'important : les plateformes de coding IA modernes ont vraiment amélioré leurs paramètres par défaut. Quand tu crées un nouveau projet dans Bolt ou Replit, la plateforme te guide vers des edge functions pour les secrets au lieu de les balancer dans le bundle navigateur. C'est du design UX orienté sécurité, et c'est sincèrement bien fait.

Mais un pourcent, c'est encore trop. Une seule clef exposée, c'est une facture OpenAI à 50 000€, un compte AWS compromis, ou un litige Stripe qui coule ta startup avant même qu'elle démarre. Ne sois pas ce pourcent.

Le Problème Supabase Que Personne Ne Voit

Là où ça se corse vraiment.

37% des applications vibe codées en ligne incluent une clef anonyme Supabase dans leur code frontend. Et avant de paniquer — c'est en fait attendu. Supabase est conçu comme ça. La clef anon est faite pour être publique ; ta sécurité des données est censée venir des politiques RLS (Row Level Security).

Voici le problème : RLS est opt-in. Les tables commencent entièrement ouvertes. Et quand tu fais du vibe coding à 23h, à fond pour respecter ta deadline de lancement, il est terriblement facile de zapper cette case à cocher.

Chaque table avec RLS désactivé — ou pire, une politique paresseuse en using (true) — c'est une porte grande ouverte à n'importe qui avec cette clef anon publique. Un attaquant n'a même pas besoin de pirater quoi que ce soit. Il... interroge ta base de données, parce que t'as oublié un paramètre.

Je ne peux pas insister suffisamment : un scan passif ne peut pas détecter les erreurs de config RLS. Le scanner ne voit que le frontend. La vulnérabilité vit dans ta base de données. Tu dois vérifier ça manuellement, table par table, avant de passer en prod.

Le même conseil s'applique à Firebase (présente dans 4% des applications scannées). Les security rules ne sont pas des options. Elles constituent le modèle de sécurité entier.

Les Headers de Sécurité : La To-Do Invisible

Si t'as jamais pensé aux headers HTTP de sécurité, t'es pas seul. 91% des applications scannées n'ont pas de Content-Security-Policy, et 88% peuvent être embed dans des iframes depuis n'importe quel site (bonjour le clickjacking).

Ce ne sont pas des vulnérabilités exotiques. Ce sont des étapes de durcissement standard qui sont meilleures pratiques depuis des années. Le pipeline du vibe coding ne les inclut simplement pas par défaut.

Voici le détail du scan :

• 91% sans Content-Security-Policy
• 88% sans X-Frame-Options / frame-ancestors
• 37% sans X-Content-Type-Options
• 38% sans Referrer-Policy
• 8% sans Strict-Transport-Security
• Seulement 5% avaient tous les headers de sécurité configurés

Le point positif ? Les plateformes de hosting gèrent HSTS automatiquement, donc ça, c'est couvert. Mais le gap CSP est significatif. Quand un composant écrit par IA affiche du contenu utilisateur ou intègre des scripts tiers, une CSP, c'est ta dernière ligne de défense. Sans, les attaques XSS n'ont nulle part où se cacher.

Le Manque de Finitions au Lancement

Voici un résultat que je ne m'attendais pas à trouver important, mais qui m'a totalement convaincu : 30% des applications vibe codées lancent sans tags Open Graph.

Ça veut dire que quand quelqu'un partage ton produit sur X (Twitter), Discord ou LinkedIn, ça apparaît comme une URL nue sans aperçu, sans image, sans description. Juste... du texte. En 2024, ça fait amateur et ça tue les taux de clic.

D'autres oublis de jour-J trouvés dans le scan :

• 11% sans meta description
• 77% sans sitemap.xml
• Les notes de sécurité moyennes : B-moins (84/100), avec seulement 13% décrochant un A

Les apps n'étaient pas des désastres — elles avaient juste besoin de polish. La même vitesse qui te mène au lancement est celle qui te fait oublier <meta property="og:title">.

Ma Checklist de Pré-Lancement en 5 Minutes

Après avoir lu cette recherche, j'ai mis à jour ma checklist personnelle de lancement. Voici ce qui compte vraiment avant que tu postes ce thread Show HN :

1. Cherche les secrets dans ton bundle Fouille ton output compilé pour sk-, sk_live_, service_role, ghp_. Tout ce qui match doit être rotationné immédiatement et déplacé vers une edge function ou une variable d'environnement. Une seule clef exposée, c'est tout qu'il faut.

2. Audite chaque table Supabase ou Firebase Ouvre ton dashboard. Chaque table publique a besoin de RLS activé. Chaque politique doit être spécifique — jamais using (true). Un accès lecture sur une table mal configurée peut exposer ta base utilisateurs entière.

3. Ajoute ces headers de sécurité

Content-Security-Policy: frame-ancestors 'none'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Commence avec Content-Security-Policy-Report-Only si tu veux tester sans contrainte. Mais déploie-le.

4. Désactive les source maps en prod Tes fichiers *.map sont de l'or pour le debug — et pour les attaquants. La plupart des plateformes ont un toggle. Bascule-le avant le lancement.

5. Ajoute tes métadonnées Open Graph Au minimum : og:title, og:description, og:image. Ta publication de lancement mérite d'être belle dans un fil.

6. Génère un sitemap.xml La version SEO de toi dans le futur t'en remerciera. La plupart des plateformes génèrent ça automatiquement — vérifie si la tienne l'a fait.

Le Grand Tableau

Voici mon analyse : le vibe coding n'est pas le problème. Le problème, c'est le gap entre "ça marche sur ma machine" et "c'est prêt pour la prod". Les développeurs traditionnels ont appris ce gap à travers des années de déploiements douloureux. Les vibe codeurs l'apprennent plus vite — et c'est en fait une bonne chose.

Les plateformes s'améliorent. Les paramètres par défaut progressent. Mais tant que le durcissement de sécurité n'est pas aussi automatique que les certificats SSL, la responsabilité nous incombe en tant que builders d'ajouter cette checklist de cinq minutes avant le lancement.

La vitesse du vibe coding, c'est un superpouvoir. La sécurité n'a pas à être le prix à payer pour l'utiliser.

Quelle est ta routine de sécurité pré-lancement ? Partage tes ajouts à la checklist dans les commentaires — je suis toujours preneur pour m'améliorer.