Le vibe coding, c'est-à-dire créer des applications en dialoguant avec une intelligence artificielle plutôt qu'en écrivant le code soi-même, a ouvert la création logicielle à des personnes qui n'auraient jamais imaginé s'y mettre. C'est une excellente nouvelle. Mais elle vient avec un piège : comme les premiers résultats arrivent vite, on croit que la méthode est optionnelle.
Elle ne l'est pas. La quasi-totalité des projets de débutants qui s'enlisent butent sur les mêmes sept erreurs. Elles n'ont rien de technique : ce sont des erreurs de posture et d'organisation, à la portée de n'importe qui, et heureusement toutes évitables.
Les voici, avec pour chacune la scène typique, ce qu'elle coûte, et le réflexe qui vous en protège.
Erreur 1 : tout demander d'un coup
La scène : porté par l'enthousiasme, vous écrivez à votre agent de code un paragraphe de quinze lignes décrivant l'application complète, avec les comptes utilisateurs, les statistiques, les notifications et le mode sombre. Vous appuyez sur Entrée et vous attendez le miracle.
La conséquence : l'agent produit une grosse masse de code dont la moitié correspond à peu près à votre idée, l'autre pas du tout. Comme tout est arrivé en même temps, impossible de savoir quelle partie corriger en premier. Vous passez la soirée à colmater au lieu de construire.
Le bon réflexe : demandez le socle, la version la plus simple qui rend déjà service, puis ajoutez une seule fonctionnalité à la fois. Chaque demande courte donne un résultat court, facile à vérifier et facile à corriger. On monte un mur brique par brique, pas en projetant le camion de béton d'un coup.
Erreur 2 : ne jamais sauvegarder son travail
La scène : votre application fonctionne, vous enchaînez les améliorations depuis trois soirées. Sauvegarder ? Vous le ferez « quand ce sera fini ». Puis une modification tourne mal, l'agent tente de réparer, aggrave les choses, et plus rien ne fonctionne.
La conséquence : sans point de restauration, vous n'avez aucun moyen de revenir à la version qui marchait. Trois soirées de travail à refaire, et souvent, la motivation qui s'en va avec.
Le bon réflexe : sauvegardez sur GitHub (le coffre-fort de votre code, qui conserve un historique de toutes vos versions) après chaque étape réussie. La sauvegarde n'est pas une corvée de fin de projet, c'est le filet de sécurité qui vous autorise à expérimenter. Avec elle, la pire catastrophe se règle en revenant à la version précédente.
Erreur 3 : ne pas tester après chaque changement
La scène : l'agent annonce « c'est fait, la fonctionnalité est ajoutée ». Vous le croyez sur parole et vous enchaînez la demande suivante, puis la suivante. Après cinq changements, vous ouvrez enfin l'application : le formulaire principal ne répond plus.
La conséquence : le problème peut venir de n'importe lequel des cinq changements. Ce qui aurait été une correction de deux minutes devient une enquête d'une heure.
Le bon réflexe : après chaque changement, ouvrez l'application dans votre navigateur et utilisez-la vraiment : cliquez, saisissez des données, vérifiez le résultat. Deux minutes de test par étape, c'est le prix, dérisoire, pour toujours savoir exactement quelle demande a cassé quoi.
Erreur 4 : accepter du code qu'on ne comprend même pas dans les grandes lignes
La scène : l'agent propose une solution, vous validez sans lire son explication. Après tout, c'est lui l'expert. Des semaines plus tard, un comportement bizarre apparaît et vous êtes incapable de dire à l'agent où chercher, car vous ne savez pas comment votre propre application est organisée.
La conséquence : vous devenez spectateur de votre projet. Chaque problème vous laisse démuni, et vos demandes deviennent vagues, donc mal exécutées.
Le bon réflexe : personne ne vous demande de lire le code ligne par ligne. Mais exigez de toujours comprendre les grandes lignes : quelles sont les parties de l'application, où sont rangées les données, que fait le changement qui vient d'être appliqué. Demandez à l'agent de vous l'expliquer en langage courant, il le fait très bien. Vous êtes le chef de projet : un chef de projet ne pose pas les briques, mais il sait lire le plan.
Erreur 5 : changer d'idée en plein milieu sans finir la boucle en cours
La scène : l'agent est en train d'ajouter la recherche par mot-clé quand une idée géniale vous traverse : et si on ajoutait plutôt des favoris ? Vous interrompez tout et lancez la nouvelle demande, laissant la recherche à moitié construite.
La conséquence : l'application se retrouve avec des fonctionnalités en chantier qui se marchent dessus. Ni la recherche ni les favoris ne fonctionnent vraiment, et le code accumule des restes de travaux abandonnés qui compliquent tout le reste.
Le bon réflexe : notez la nouvelle idée sur une liste (elle sera toujours là dans vingt minutes) et terminez la boucle en cours : construire, tester, corriger, sauvegarder. Ensuite seulement, ouvrez le chantier suivant. Une boucle commencée est une boucle fermée, c'est la règle qui garde votre projet sain.
Erreur 6 : négliger la description initiale du besoin
La scène : pressé de voir du résultat, vous démarrez avec « fais-moi une application de gestion de stock ». L'agent, obligé de deviner, invente : des champs dont vous n'avez pas besoin, un vocabulaire qui n'est pas le vôtre, une organisation pensée pour un entrepôt alors que vous gérez un atelier.
La conséquence : vous passez plus de temps à détricoter les suppositions de l'IA qu'il ne vous en aurait fallu pour décrire votre besoin correctement. Et certaines suppositions, enfouies profondément, ressurgissent pendant des semaines.
Le bon réflexe : avant la première demande, écrivez dix lignes en français simple : qui utilise l'application, pour faire quoi, avec quelles informations, et qu'est-ce qui rendra l'outil réussi à vos yeux. Ces dix minutes d'écriture sont l'investissement le plus rentable de tout votre projet : tout ce que vous ne précisez pas, l'IA l'inventera.
Erreur 7 : croire que l'IA a toujours raison
La scène : un résultat vous semble étrange, mais l'agent affirme avec une parfaite assurance que tout est correct. Vous doutez de vous, pas de lui, et vous continuez sur cette base bancale.
La conséquence : les agents de code se trompent, et ils se trompent avec aplomb. Une affirmation erronée acceptée tôt devient une fondation pourrie sur laquelle tout le reste s'appuie.
Le bon réflexe : l'assurance de l'IA n'est pas une preuve. La preuve, c'est votre test dans le navigateur. Si quelque chose vous semble étrange, dites-le, décrivez ce que vous observez, demandez une explication en langage courant. Vous avez le droit, et même le devoir, de contredire votre agent : c'est vous qui connaissez votre besoin, lui ne fait que construire.
Le point commun de ces sept erreurs
Vous l'avez peut-être remarqué : aucune de ces erreurs ne demande un savoir technique pour être évitée. Toutes se résument à une même posture : rester le pilote. Avancer par petites boucles, vérifier de ses propres yeux, sauvegarder à chaque étape, comprendre les grandes lignes, et ne jamais déléguer son jugement.
Cette posture, et l'environnement de travail qui la rend naturelle, s'acquièrent bien plus vite avec un cadre guidé qu'en accumulant les leçons douloureuses. C'est précisément ce que propose la formation Construction de votre environnement Vibe Coding : monter un environnement complet et prendre, dès vos premiers projets personnels, les réflexes qui font la différence entre une application qui aboutit et une idée qui s'enlise.