Le contexte
J'audite des apps codées avec l'IA. De vrais produits, avec de vrais utilisateurs, montés vite et qui marchent. Backend, frontend, base de données : du code largement généré par une IA. Le genre de projet qu'on monte en quelques semaines aujourd'hui.
À chaque fois, je les passe au crible sur les mêmes angles : sécurité, architecture, qualité, déploiement. Et à chaque fois, le même constat revient, celui qui surprend encore beaucoup de fondateurs.
On imagine le cliché habituel : "l'IA code mal, faille partout". C'est l'inverse. Les trucs vraiment durs à bien faire sont souvent bien faits. Et les trucs simples, ceux qu'aucun tuto ne te rappelle, sont absents.
Le risque le plus grave, le seul vraiment irréversible, est souvent le plus bête à corriger. Quelques minutes de travail. Et c'est presque toujours celui que personne n'a pensé à faire.
On va regarder pourquoi, parce que ce schéma, je le vois sur presque toutes les apps vibe codées.
Ce que l'IA a réussi (et qui n'est pas évident)
Commençons par le positif, parce qu'il est réel.
Quand j'ouvre une app pour un audit sécu, il y a une poignée de trucs que je regarde en premier. Ce sont les trucs "dangereux à rater", ceux qui coûtent une fortune à réparer après coup. Et le plus souvent, ils sont propres :
- Les mots de passe sont hashés correctement. Pas stockés en clair, pas avec un vieil algo cassé. Avec bcrypt, et parfois même une protection en plus contre une attaque par chronométrage (je t'épargne le détail, mais c'est au-dessus de ce que font beaucoup d'équipes).
- Les accès sont revérifiés côté serveur. À chaque fois qu'un utilisateur demande une donnée, le serveur revérifie qu'elle lui appartient vraiment. Pas de "je fais confiance à l'URL". C'est LE piège classique, et il est souvent évité.
- La crypto est saine. Pas d'algo bidon, pas de raccourci dangereux.
- Une vraie batterie de tests, au vert sur les chemins critiques.
Si tu ne fais pas de code, retiens juste ça : le cœur du coffre-fort est bien construit. La serrure, les gonds, la porte blindée : du bon boulot. C'est exactement ce qui est le plus dur à rattraper si c'est raté dès le départ.
Pourquoi l'IA réussit ça ? Parce que ce sont des problèmes hyper documentés. "Comment hasher un mot de passe", il y a dix mille bons exemples en ligne, et l'IA les a tous lus. Sur les sujets balisés, elle est solide.
Ce que l'IA a raté (et c'est toujours pareil)
Le problème, ce n'est pas le code. C'est tout ce qui est autour du code.
Une app qui tourne en prod, ce n'est pas qu'un programme. C'est un programme plus un environnement : un serveur, une config, des accès, des sauvegardes, des mises à jour. Et ça, l'IA ne le génère pas. Personne ne lui demande. Ça ne se voit pas dans la démo.
Voilà ce que je trouve, et c'est presque toujours la même liste :
Un mot de passe administrateur écrit en dur dans le code. Le compte le plus puissant de l'app, celui qui peut tout faire, a son mot de passe écrit noir sur blanc dans les fichiers. Souvent même dans l'historique du projet, donc impossible à effacer vraiment. N'importe qui mettant la main sur le code prend le contrôle total.
Aucune protection contre les tentatives de connexion en masse. Un attaquant peut tester des mots de passe à l'infini, à pleine vitesse, sans jamais être bloqué. C'est comme une porte blindée... dont tu peux essayer les codes un par un, autant de fois que tu veux, sans que personne ne s'en aperçoive.
Des dépendances jamais mises à jour. Une app moderne, c'est ton code plus des dizaines de briques toutes faites écrites par d'autres. Plusieurs de ces briques traînent des failles connues et publiées. "Connues et publiées" veut dire que les attaquants ont déjà le mode d'emploi. Personne ne les a mises à jour.
Les conteneurs tournent avec les pleins pouvoirs. Détail technique, mais l'idée est simple : si l'app est compromise, l'attaquant ne reste pas coincé dans l'app, il sort direct sur le serveur entier.
Tu remarques le point commun ? Aucun de ces trucs n'est difficile. Ce ne sont pas des bugs subtils. Ce sont des oublis. Des cases jamais cochées, parce que personne ne savait qu'elles existaient.
Le pire est le plus simple
Et puis, le point qui fait toujours le plus tiquer.
Très souvent, toutes les données (le travail des utilisateurs, la base, tout) vivent sur un seul serveur. Une seule machine. Aucune copie ailleurs. Nulle part.
Pas de sauvegarde. Zéro.
Prends une seconde pour mesurer ce que ça veut dire. Un disque dur qui lâche (ça arrive). Une fausse manip (ça arrive encore plus). Un ransomware qui chiffre tout (ça arrive aux meilleurs). Et là, c'est fini. Pas "fini, on répare en deux jours". Fini définitivement. Les données ne reviennent pas.
C'est la différence énorme avec tous les autres problèmes. Une faille de sécurité, tu la corriges, et c'est réglé. Une donnée perdue, tu ne la "corriges" pas. Elle est partie.
Et le plus fou : c'est le truc le moins cher à régler de toute la liste. Mettre en place une sauvegarde automatique chiffrée, qui part chaque nuit sur un autre serveur, et la tester une fois pour vérifier qu'elle marche, c'est l'affaire de quelques heures. C'est l'assurance la moins chère du monde.
Et personne n'y pense. Pas par négligence. Parce que la sauvegarde, ça ne fait pas partie du code. L'IA construit l'app. Elle ne construit pas le filet de sécurité en dessous. Et quand tu vibe codes en regardant ton app marcher à l'écran, tu n'as aucune raison de penser au jour où le serveur prend feu.
C'est exactement l'analogie de la maison : tu as une serrure connectée dernier cri, une porte blindée, des caméras. Et pas de toit. Tant qu'il fait beau, tout va bien.
Pourquoi c'est toujours ce schéma
Ce n'est pas un hasard. L'IA optimise pour une seule chose : que ça marche maintenant, à l'écran. Tout ce qui ne se voit pas dans la démo (une sauvegarde, une dépendance à jour, ce qui se passe si le disque meurt un dimanche soir) passe à la trappe. Pas par incompétence : parce que personne ne le lui demande.
Ces réflexes-là ne viennent pas d'un tuto. Ils viennent de s'être déjà pris le mur. L'IA, elle, ne s'est jamais pris le mur. Elle te génère du code qui marche, pas du code qui a déjà souffert.
C'est précisément le job qu'un humain doit reprendre. Pas réécrire l'app, elle est souvent bonne. Fermer les portes que personne n'a vues.
La checklist avant de mettre en ligne
Si tu vibe codes une app et que tu t'apprêtes à la mettre entre les mains de vrais utilisateurs, voilà les cases que l'IA n'a quasi certainement pas cochées pour toi. Aucune n'est compliquée.
- Une sauvegarde automatique, qui part ailleurs que sur ton serveur principal, et que tu as testée au moins une fois. Si tu ne dois en faire qu'une, c'est celle-là. Une sauvegarde jamais testée, c'est une sauvegarde qui n'existe pas.
- Aucun mot de passe, aucune clé, aucun secret écrit dans le code. Tout ça se range dans des "variables d'environnement", séparées du code. Si c'est dans le code, considère que c'est public.
- Une limite sur les tentatives de connexion. Au bout de quelques essais ratés, on bloque. Sinon ta porte blindée se fait tester à l'infini.
- Les dépendances à jour. Ces briques toutes faites, il faut les rafraîchir régulièrement. Un attaquant qui cherche une faille connue, c'est le minimum d'effort pour lui.
- Un coup d'œil sur les permissions du serveur. L'app ne doit pas tourner avec les pleins pouvoirs sur la machine. En cas de pépin, ça limite les dégâts.
Tu remarqueras qu'aucune de ces cases ne parle de "réécrire ton app". Ce sont des heures de travail, pas des semaines. C'est ça, la bonne nouvelle des apps vibe codées bien construites : le gros œuvre tient, il reste à poser le toit.
Le problème n'est jamais l'IA
Le problème, c'est de croire que "ça marche à l'écran" veut dire "c'est prêt pour la vraie vie". Une app, ce n'est pas juste du code qui tourne le jour de la démo. C'est du code qui survit à un dimanche soir, à une fausse manip, à un disque qui meurt. Et pour l'instant, l'humain reste important.
Tu veux savoir ce qui se cache dans ton app ?
Si tu as vibe codé un produit et que tu t'apprêtes à le mettre en prod (ou qu'il y est déjà), je peux faire le même genre de passage : je lis le code et la config, je te liste les vrais risques classés par gravité, et je te donne un plan de correction priorisé. Pas de la théorie, des actions concrètes. Découvre l'offre Audit.
Et si tu veux d'autres retours d'audit dans ce style, inscris-toi à la newsletter. Juste les pièges qui valent la peine d'être évités, sans spam.
