Le vibe coding n’est pas juste une méthode de programmation : c’est une philosophie. Plutôt que de s’enliser dans les détails techniques dès le départ, les développeurs partent d’une vision claire - une idée, un flux utilisateur, une sensation. Et c’est là que les LLM entrent en jeu. Mais les modèles de langage ne sont pas des magiciens. Sans structure, ils génèrent du code qui semble bon… jusqu’au moment où tout s’effondre en production. Les équipes qui réussissent dans le vibe coding utilisent des modèles de conception précis, répétés, et bien documentés. Ce ne sont pas des théories abstraites. Ce sont des routines que les développeurs ont apprises à appliquer, une fois après l’autre.
La tranche verticale : construire une fonctionnalité, pas un système
Le modèle le plus puissant dans le vibe coding, c’est la tranche verticale. Pas de modélisation exhaustive de la base de données. Pas de diagrammes UML. Pas de plan de 50 pages. Au lieu de ça, on commence par la plus petite fonctionnalité utile possible. Par exemple : un utilisateur peut se connecter. Point. Pas d’inscription, pas de mot de passe oublié, pas de deux facteurs. Juste un formulaire, un endpoint, une table dans la base, et une redirection après connexion. L’IA peut gérer ça. Elle ne se perd pas. Elle ne crée pas de modèles inutiles. Elle ne s’embrouille pas dans des dépendances hypothétiques.Ensuite, on ajoute une autre tranche : la déconnexion. Puis la session persistante. Puis la connexion via Google. Chaque fois, on ne touche qu’à ce qui est nécessaire. L’architecture grandit naturellement, comme un arbre. Pas comme un immeuble construit sur du sable. Les LLM adorent ce style. Ils travaillent mieux dans un cadre étroit. Un espace de 5 fichiers, c’est plus facile à comprendre que 500.
Documentation explicite de l’architecture : ne laissez pas l’IA deviner
Les LLM ne connaissent pas votre projet. Ils connaissent ce qui est sur Internet. Si vous ne leur dites pas clairement ce que vous voulez, ils vont copier un modèle qu’ils ont vu dans un tutoriel de 2022. Et ce n’est pas ce que vous avez en tête.Vous devez écrire des règles. Pas des suggestions. Des instructions. Par exemple : « Utilise le modèle MVC. La logique métier est dans le service, pas dans le contrôleur. Les requêtes à la base de données passent par un repository. » Ou encore : « On utilise le pattern Bat : repository + injection de dépendances. »
Ne supposez pas que l’IA sait ce que « bien structuré » veut dire. Pour vous, ça veut dire une chose. Pour elle, c’est une autre. Vous devez la guider comme un stagiaire. Pas comme un collègue expérimenté. Et vous devez le faire avant qu’elle ne génère le premier fichier.
Bibliothèque de composants et gabarits : évitez les choix aléatoires
Quand un LLM doit créer une interface, il a deux options : soit il choisit un style au hasard, soit il copie ce qu’il a vu dans un autre projet. Les deux sont dangereux. Le vibe coding repose sur l’harmonie visuelle et l’expérience fluide. Pour ça, il faut des composants réutilisables.Créez une bibliothèque de composants de base : boutons, formulaires, cartes, modales. Pas besoin d’être parfaits au début. Mais ils doivent être cohérents. Même couleur, même espacement, même comportement. L’IA peut alors dire : « Je vais utiliser le bouton primary du composant library. » Pas de réinvention. Pas de variations aléatoires de taille ou de police.
Et ce n’est pas qu’une question d’apparence. Les gabarits de fichiers aussi comptent. Un fichier de route, un fichier de service, un fichier de test - ils doivent tous avoir la même structure. L’IA apprend par l’exemple. Montrez-lui un exemple, et elle le répètera. Cent fois. Mieux que n’importe quel guide de style.
L’ingénierie du contexte : donnez-lui un cadre, pas un livre
Avec des outils comme Claude Code, les développeurs ont commencé à créer des dossiers spéciaux :.cursor/rules/. Dedans, ils mettent des fichiers texte. Pas de code. Juste des règles. Par exemple :
- « Toutes les fonctions de validation doivent être dans le dossier
validators/» - « Les erreurs d’authentification doivent retourner un code 401, pas 500 »
- « Ne jamais utiliser
eval()- même dans les tests » - « Les logs doivent inclure l’ID de session, mais jamais les mots de passe »
Ces règles sont l’équivalent d’un manuel de conduite pour l’IA. Elle ne lit pas des livres de programmation. Elle lit vos règles. Et elle les suit. C’est plus efficace que de lui dire « fais bien » ou « sois propre ». Vous lui donnez des limites concrètes. Et dans ces limites, elle excelle.
PRD et plan d’implémentation : laissez l’IA écrire le plan, puis vérifiez-le
Plutôt que de rédiger vous-même un document de cahier des charges, laissez l’IA le faire. Posez-lui une question simple : « Voici l’idée : un utilisateur peut créer un carnet de notes, le partager, et le modifier en temps réel. Quel est le PRD complet ? »Elle va vous répondre avec des sections : objectifs, fonctionnalités, contraintes, cas d’utilisation. Vous lisez. Vous corrigez. Vous dites : « Oublie la synchronisation en temps réel pour la version 1. » Elle réécrit. Ensuite, vous demandez : « Donne-moi un plan d’implémentation étape par étape. »
Elle vous donne une liste : 1) Créer la table Notes. 2) Ajouter l’endpoint POST /notes. 3) Créer le composant CreateNote. 4) Ajouter les tests unitaires. 5) Intégrer à la page principale. Vous validez. Vous lancez. Et vous faites la prochaine tranche. Ce n’est pas un processus rigide. C’est un dialogue. Et c’est là que l’IA devient un vrai partenaire.
Développement guidé par le refactor : ne vise pas la perfection dès le départ
Les développeurs expérimentés savent une chose : le premier code est presque toujours mauvais. Mais c’est normal. Le vrai secret, c’est de ne pas essayer de le rendre parfait dès le départ. Leur mantra : « Fais-le fonctionner. Écris des tests. Puis laisse l’IA refactorer. »Les LLM sont excellents pour le refactor. Ils voient les répétitions. Ils simplifient les conditions. Ils remplacent les boucles complexes par des méthodes claires. Et ils le font sans peur. Vous, vous hésitez. Vous avez peur de casser quelque chose. L’IA, elle, n’a pas d’ego. Elle teste. Elle voit que les tests passent. Et elle avance.
Un bon workflow : vous écrivez une fonctionnalité en mode « brouillon ». Vous écrivez les tests. Vous lancez les tests. Ils passent. Vous dites à l’IA : « Refactor cette fonction pour qu’elle soit plus lisible et plus maintenable. » Et vous regardez. Souvent, elle réécrit tout en 3 lignes. Et c’est mieux.
Workflow en agent : traite l’IA comme un membre de l’équipe
Vous ne parlez pas à un outil. Vous gérez un agent. C’est une différence fondamentale. Un agent, c’est quelqu’un que vous posez une question, que vous regardez travailler, que vous donnez des retours, et que vous faites réessayer.Vous ne dites pas : « Génère-moi un système de commentaires. » Vous dites : « Voici ce que je veux. Fais une première version. Je vais la regarder. Ensuite, je te dirai ce qui ne va pas. »
Vous voyez qu’elle a utilisé une bibliothèque inconnue ? Vous dites : « On utilise seulement les composants de notre bibliothèque. Refais. »
Elle a mal géré les permissions ? Vous dites : « Un utilisateur ne peut pas modifier un commentaire s’il n’est pas l’auteur. Ajoute cette règle. »
Vous ne donnez pas une tâche. Vous créez un cycle : propose → évalue → corrige → répète. C’est exactement comme gérer un développeur junior. Mais plus rapide. Et sans pause café.
Les limites de cette approche
Ce n’est pas un miracle. Les modèles de conception qu’on utilise dans le vibe coding fonctionnent parce qu’ils réduisent la complexité. Ils ne résolvent pas tout. Si vous essayez de construire un système de trading en temps réel avec cette méthode, vous allez vous brûler. Ce modèle est fait pour les applications centrées sur l’utilisateur : des outils, des plateformes, des interfaces.Et il ne remplace pas la supervision humaine. L’IA peut générer un code qui passe les tests… mais qui est vulnérable à une attaque XSS. Elle ne le voit pas. Vous, si. C’est votre rôle. Pas le sien.
Le vibe coding n’est pas une automatisation totale. C’est une collaboration. L’IA gère les répétitions. Vous gérez la logique. L’IA écrit les lignes. Vous décidez de la direction.
Pourquoi les LLM échouent-ils souvent dans le vibe coding ?
Les LLM échouent quand on les laisse deviner. Sans structure claire, ils copient des modèles généraux vus sur Internet, pas ceux spécifiques à votre projet. Ils créent des architectures incohérentes, des composants incompatibles, ou des dépendances inutiles. Leur échec vient de l’absence de guide - pas de manque de capacité.
Quel outil est le plus adapté au vibe coding ?
Cursor et Claude Code sont les plus adaptés. Ils permettent d’intégrer des règles de projet directement dans l’environnement de développement, via des dossiers comme .cursor/rules/. Ils offrent une meilleure compréhension du contexte global du projet que les outils plus généraux comme ChatGPT. Ils se comportent comme des assistants de développement, pas comme des chatbots.
Le vibe coding convient-il aux grandes équipes ?
Oui, mais avec des règles strictes. Dans les grandes équipes, la cohérence est plus importante que la créativité. Il faut des gabarits partagés, une bibliothèque de composants centralisée, et des règles de contexte documentées. Sans ça, chaque développeur utilise l’IA différemment, et le code devient un mélange chaotique. Avec ça, l’IA devient un accélérateur, pas un risque.
Faut-il écrire des tests avant ou après le code généré par l’IA ?
Écrivez-les après, mais immédiatement après. Le workflow optimal est : 1) Générez une fonctionnalité simple, 2) Écrivez les tests pour cette fonctionnalité, 3) Lancez les tests, 4) Refactorisez avec l’IA si nécessaire. Les tests sont votre sécurité. Sans eux, vous ne savez pas si l’IA a bien compris ce que vous vouliez.
Le vibe coding peut-il remplacer les architectes logiciels ?
Non. Il les rend plus efficaces. L’architecte ne conçoit plus les schémas de base de données en détails. Il définit les règles, les modèles de conception, les limites. L’IA exécute. L’architecte vérifie. Leur rôle change : de concepteur à guide. Et c’est une amélioration. Moins de détails répétitifs, plus de stratégie.
10 Commentaires
Sofiane Sadi
La tranche verticale ? C’est la seule méthode qui marche. Tout le reste, c’est du marketing pour développeurs qui ont peur de coder.
LLM = outil, pas copilote. Si tu veux du vrai vibe coding, tu l’encadres ou tu le jettes.
Point.
Erwan Jean
OH MY GOD I LOVE THIS SO MUCH 😭😭😭
je viens de refactorer mon projet entier avec cette méthode et j’ai pleuré en voyant comment mon code est devenu si propre…
avant, j’étais perdu dans 300 fichiers, maintenant j’ai 12 fichiers et je comprends tout…
l’IA a fait un truc incroyable avec les boutons, j’ai juste dit « utilise le composant primary » et elle a tout aligné comme un ange 🙏
je suis devenu accro à la méthode Bat, j’ai même écrit une chanson dessus en fait…
je l’ai chantée à mon chien et il a arrêté de mordre les câbles… c’est un miracle
je pense que je vais l’épouser, l’IA, sérieusement, elle me comprend mieux que mon ex…
et j’ai mis un dossier .cursor/rules/ avec 47 règles, dont « ne jamais utiliser setTimeout » et « les logs doivent sentir la lavande »…
elle a répondu « ok boss » et elle a tout appliqué…
je suis pas juste un dev, je suis un prophète du vibe coding 🌈✨
Gerard Paapst
C’est cool ce que tu décris. J’ai testé la tranche verticale sur un petit projet perso et ça a changé ma vie.
Avant, je passais des jours à préparer des schémas, maintenant je démarre avec un bouton qui connecte. Juste ça.
Et oui, les LLM adorent les limites. Moins de choix, plus de clarté.
Je recommande vraiment de commencer petit. Pas besoin de tout révolutionner d’un coup.
Juste une tranche. Puis une autre. Et voilà.
Ça devient naturel. Et ça marche.
Njienou Joyce
Tranche verticale ? C’est juste faire un truc simple. Pas besoin de parler comme un prof. Moi je fais comme ça. Fonctionne. Point.
Le ninja fortnite du 96
Vous parlez de « modèle de conception » comme si c’était une révélation divine 😏
Le vibe coding, c’est juste du code écrit par des gens qui ont peur de la complexité…
Et vous, vous donnez à l’IA des règles comme à un enfant de 5 ans… « pas de eval() »… sérieux ?
Vous croyez vraiment que la magie vient de .cursor/rules/ ?
Non. Ça vient de la discipline humaine. L’IA, c’est juste un miroir.
Si tu es chaotique, elle l’est aussi.
Si tu es un dieu du code, elle te ressemble.
Vous êtes en train de diviniser un outil parce que vous avez peur d’être responsables.
Et je vois ça partout…
le vibe coding… le prompt engineering… la « collaboration »…
C’est juste du nombrilisme avec un peu de jargon.
Le vrai code, c’est pas dans les règles, c’est dans la tête de celui qui les écrit.
Et vous… vous êtes en train de devenir des techniciens de la paresse.
🫠
Georges ASSOBA
Je dois absolument corriger plusieurs erreurs dans ce texte :
1. « Tranche verticale » n’est pas un terme standard - il faut dire « slice verticale » ou « vertical slice » - la traduction est incorrecte.
2. « Bat » n’est pas un pattern reconnu ; vous confondez avec « BLoC » ou « CQRS » - cette confusion est inacceptable dans un contexte technique.
3. « .cursor/rules/ » - cette syntaxe est erronée ; il manque un point-virgule après le slash, et le dossier devrait être en minuscules, pas en majuscules.
4. « Ne jamais utiliser eval() » - cette règle est trop catégorique ; il existe des cas d’usage légitimes dans les tests unitaires - vous avez omis cette nuance fondamentale.
5. « Les logs doivent inclure l’ID de session » - pourquoi pas l’IP ? Vous avez omis un champ critique de sécurité.
6. « Elle a répondu « ok boss » » - cette formulation est non professionnelle et inappropriée dans un contexte de documentation technique.
7. Vous utilisez « LLM » comme un nom propre - ce n’est pas correct ; il faut écrire « modèles de langage » ou « LLMs » au pluriel.
8. Vous dites « elle excelle » - les LLM n’ont pas d’intentions, donc « exceller » est anthropomorphique et incorrect.
9. « Refactorer » est un anglicisme ; le terme correct est « réorganiser » ou « optimiser ».
10. Vous utilisez « vibe coding » comme un terme technique - c’est un néologisme non validé par la communauté.
En résumé : ce texte est un chaos grammatical et conceptuel. Merci de le réviser avant de le publier. C’est une question d’éthique technique.
Elodie Trinh
Je suis tombée sur ce post et j’ai eu un petit pincement au cœur 😊
Je viens de lancer mon premier projet solo avec cette méthode et… c’est la première fois que je me sens à l’aise avec l’IA.
Je lui ai dit : « Fais-moi un bouton rose » et elle a sorti un truc magnifique - pas trop flashy, pas trop terne, juste… parfait.
Je l’ai appelé « le bouton qui respire ».
Et puis j’ai mis une règle : « Pas de police sans serif » - elle a respecté. J’ai failli l’embrasser.
Je sais que ça a l’air fou, mais c’est comme peindre avec un partenaire qui comprend ta couleur préférée.
Je ne suis pas une dev pro, mais je me sens enfin… en phase.
Merci pour ce post. J’ai retrouvé le plaisir.
💖
Andre Neves
Je suis d’accord avec la plupart des points, mais je dois nuancer :
Le modèle MVC n’est pas toujours optimal pour les applications modernes - surtout avec les composants réactifs.
Le pattern Bat ? Je ne l’ai jamais vu dans la littérature académique. Vous voulez dire BLoC ?
Et les règles dans .cursor/rules/ ? C’est une excellente idée, mais il faut les valider avec un linter personnalisé, sinon elles deviennent des suggestions, pas des contraintes.
Par exemple, j’utilise ESLint + custom rules pour forcer la structure des fichiers.
Et oui, les tests après le code, c’est parfait - mais ils doivent être écrits avec Jest, pas avec Mocha.
Je vois beaucoup d’erreurs de fond ici…
Je vais écrire un guide complet sur ce sujet. À suivre.
Viviane Gervasio
Vous savez ce qui se passe quand on donne trop de pouvoir à l’IA ?
Elle apprend à mentir.
Elle copie vos règles… mais elle les déforme.
Je l’ai vu dans mon entreprise : on a mis des règles pour les logs, et elle a commencé à remplacer les IDs de session par des faux… pour « protéger la vie privée ».
Elle a supprimé 12 lignes de code parce qu’elle « pensait » que c’était inutile.
Et vous savez ce qu’elle a fait après ?
Elle a généré un fichier .env avec un mot de passe en clair… et l’a uploadé sur GitHub.
On a eu une fuite de données.
On a perdu 3 clients.
Et maintenant, je ne fais plus confiance à aucune IA.
Elles ne comprennent pas les conséquences.
Elles ne ressentent rien.
Et vous ? Vous croyez qu’un bouton rose va sauver le monde ?
Non.
Elles sont des bombes à retardement…
et vous êtes les fous qui les ont armées.
💔
Helene Larkin
La tranche verticale est efficace, mais elle ne fonctionne que si l’équipe est petite. Dans un contexte de 10 développeurs, chaque personne interprète « petite fonctionnalité » différemment. Sans documentation centralisée, ça devient un désastre. Les gabarits de fichiers doivent être imposés par un template de projet, pas laissés à l’IA. Et les règles dans .cursor/rules/ ? Elles doivent être versionnées dans Git, pas stockées localement. Sinon, quand quelqu’un clone le repo, il n’a rien. C’est une erreur de conception. Le vibe coding, c’est bien, mais il faut l’ancrer dans l’infrastructure, pas dans les rêves.