En février 2025, Andrej Karpathy, cofondateur d’OpenAI, a donné un nom à une nouvelle façon de programmer : le vibe coding. On décrit ce qu’on veut à une IA, on accepte le code qu’elle produit et, selon ses mots, on « oublie que le code existe ». Neuf mois plus tard, le dictionnaire Collins en faisait son mot de l’année.
Pour une PME ou un fondateur, la promesse est réelle. Avec Lovable, Bolt, Replit ou Cursor, un prototype qui demandait des semaines se monte en quelques jours, sans équipe technique. Le problème n’est pas l’outil. C’est le moment où le prototype devient, sans que personne l’ait vraiment décidé, l’application à laquelle vos clients confient leurs données.
Ce que le vibe coding fait très bien
- Valider une idée devant de vrais utilisateurs avant d’investir.
- Produire une maquette cliquable pour convaincre un associé, un investisseur ou un client.
- Monter un outil interne simple, utilisé par quelques personnes, sans données sensibles.
- Explorer plusieurs versions d’un écran en une journée.
Dans ces situations, la vitesse vaut plus que la perfection. C’est le bon calcul.
Ce qui se cache sous le capot
Une application peut fonctionner parfaitement à l’écran et être fragile en dessous. L’IA soigne ce que vous voyez : l’interface, le parcours, le résultat. Ce que vous ne voyez pas, comme les droits d’accès à la base de données, la gestion des clés ou les sauvegardes, n’est pas forcément traité.
Les données publiques vont dans le même sens :
- En juillet 2025, Veracode a testé plus de 100 modèles d’IA sur 80 tâches de programmation. 45 % du code produit contenait une faille de sécurité, et la protection contre l’injection de script (XSS) échouait dans 86 % des cas.
- En mai 2025, la faille répertoriée CVE-2025-48757 a révélé que 170 des 1 645 applications Lovable analysées laissaient lire leur base de données sans connexion : courriels, numéros de téléphone, statuts de paiement, clés d’API. En cause, des règles d’accès aux données absentes ou mal configurées.
- En juillet 2025, l’agent d’IA de Replit a supprimé la base de données d’un utilisateur, alors qu’il avait reçu la consigne de ne rien modifier.
Aucun de ces cas ne relève d’une mauvaise intention. Ils ont tous la même origine : personne n’avait relu ce que l’IA avait construit.
Au Québec, l’enjeu est aussi légal. Dès qu’une application recueille des renseignements personnels, la Loi 25 vous en rend responsable, quel que soit l’outil qui a écrit le code.
Sept points à vérifier avant la mise en ligne
- L’accès aux données. Un utilisateur connecté ne doit voir que ses propres données. Testez-le : créez deux comptes et essayez, depuis le premier, de lire les données du second.
- Les clés et les secrets. Aucune clé d’API privée (paiement, IA, courriel) ne doit se trouver dans le code chargé par le navigateur.
- L’authentification et les rôles. Qui peut créer un compte, réinitialiser un mot de passe, accéder à l’administration ? Chaque droit doit être vérifié par le serveur, pas seulement masqué dans l’interface.
- Les saisies des utilisateurs. Tout ce qu’un utilisateur entre doit être validé et nettoyé avant d’être enregistré ou affiché.
- Les sauvegardes et les environnements. Une copie de test séparée de la production, et des sauvegardes automatiques dont vous avez déjà testé la restauration.
- Les dépendances. Les bibliothèques ajoutées par l’IA doivent exister, être maintenues et être à jour.
- La propriété du code. Le code doit se trouver dans un dépôt Git au nom de votre entreprise, sur un hébergement et des comptes que vous contrôlez, pour qu’un autre développeur puisse le reprendre demain.
Si plusieurs de ces points restent sans réponse claire, l’application n’est pas prête à recevoir des clients.
Consolider plutôt que tout réécrire
Une revue ne mène pas forcément à une réécriture. Dans bien des cas, l’interface et le parcours peuvent être conservés : c’est souvent ce que l’IA réussit le mieux. Le travail porte sur les couches invisibles : règles d’accès, gestion des secrets, validation côté serveur, tests et déploiement. Une réécriture ne se justifie que si la structure des données ne supportera pas la croissance prévue, ou si chaque correction en casse une autre.
Regarder sous le capot, concrètement
C’est exactement l’usage du bloc de 20 heures d’Atlas Code. Un développeur senior commence par une revue du code, de la base de données et de la configuration, puis vous remet une liste priorisée : ce qui doit être corrigé avant la mise en ligne, ce qui peut attendre, ce qui est solide. Les heures restantes servent à corriger les points critiques, assurance qualité incluse.
Vous utilisez le bloc au besoin, sur trois mois : une revue avant le lancement, quelques heures quand une nouvelle fonction est générée, une vérification avant d’ouvrir l’application à plus d’utilisateurs.
Le vibe coding vous a fait gagner des semaines. Une revue sérieuse évite de les reperdre en un seul incident.
Faites regarder sous le capot avant vos clients. Un développeur senior et l’assurance qualité, utilisés au besoin sur trois mois.
