Ce qu'est le vibe coding
Le terme s'est popularisé en 2025 et décrit une façon de programmer où l'on dit à un modèle ce que l'on veut, où l'on essaie le résultat et où on l'accepte sans lire tout le code écrit. L'intérêt, c'est la vitesse : en une après-midi, quelque chose tourne et se montre.
Ce n'est pas un problème en soi. Cela en devient un quand ce code passe de la démo à la production sans que personne d'expérimenté n'ait regardé quelles données il touche, ce qu'il laisse ouvert et ce qui arrive quand mille personnes arrivent au lieu de trois.
Le vibe coding, bon ou dangereux ?
Ni l'un ni l'autre : c'est un outil, et tout dépend de l'usage. Pour une maquette, une preuve de concept ou un outil interne, il y a peu de choses plus rapides. Pour ce qui stocke des données clients, encaisse des paiements ou reçoit un vrai trafic, cette vitesse devient un risque si personne ne relit ce qui a été écrit.
Les avantages sont réels : une idée se teste en quelques heures, ceux qui ne codent pas peuvent montrer ce qu'ils veulent et l'équipe technique part d'une base qui fonctionne. Les dangers aussi : un code que personne ne comprend entièrement, des droits ouverts par défaut, des dépendances choisies au hasard et des erreurs silencieuses. Tout se joue entre la démo et la production.
Où casse le code écrit par l'IA
L'IA écrit du code qui marche sur le chemin heureux, celui que la démo essaie. Ce qui manque, c'est en général l'invisible : le contrôle de la valeur qui arrive mal, la permission que personne n'a revue, la requête qui traîne quand la table grossit et le secret resté dans le dépôt.
C'est mesuré. 45% du code généré par IA en laboratoire présentait des vulnérabilités connues quand aucune consigne de sécurité n'était donnée.
Les outils de vibe coding et ce qui change entre eux
Il y a deux familles. Les éditeurs et assistants qui travaillent dans le code, comme Cursor, GitHub Copilot ou Claude Code, et les plateformes qui génèrent une application entière à partir d'une description, comme Lovable, Bolt, Replit ou Google AI Studio. Les premiers laissent le code sous les yeux d'une équipe technique ; les secondes en cachent davantage et le publient souvent elles-mêmes.
Pour la revue, l'outil change l'endroit où l'on regarde d'abord, pas ce qu'il faut vérifier. Sur les plateformes qui publient seules, les clés et les droits de la base de données passent en premier ; dans les éditeurs, les dépendances et les routes ajoutées sans que personne ne les demande.
Quoi revoir avant la mise en production
Six choses, dans cet ordre : secrets et identifiants hors du code ; routes et permissions, pour que personne ne voie ce qui n'est pas à lui ; données personnelles, dans les réponses et dans les logs ; performances avec le volume réel, pas avec trois lignes de test ; dépendances et versions ; et ce qui se passe quand quelque chose casse, car c'est là que l'on voit si le système prévient ou se tait.
Aucune des six ne se vérifie en survolant le code : elles se mesurent. C'est pour cela qu'une revue sert et qu'une lecture rapide non.
Comment nous le revoyons
Avec des outils d'IA qui s'adaptent à votre projet et regardent d'abord les points où l'IA casse, et avec une personne expérimentée qui revoit chaque constat. Nous ne laissons jamais un outil travailler seul : ce que nous livrons porte les preuves de chaque point, avec la mesure à côté.
Si le projet est un site, cette revue est celle des sites web ; si c'est une app, celle des apps mobiles ; si c'est le serveur, celle du backend et de son API.