Vibe coding avec l'IA : 10 bonnes pratiques pour coder vite (sans perdre le controle)

Vous avez surement deja entendu le terme vibe coding. Si ce n’est pas le cas, c’est un terme invente par Andrej Karpathy (une reference dans le monde de la data, du machine learning et de l’IA) pour designer la pratique de programmer avec l’assistance d’un LLM, “au rythme de l’IA” (c’est la traduction la plus proche du terme vibe).

Attention au mot “assistance”. La bonne facon de faire du vibe coding, de mon point de vue, c’est de coder en etant assiste par l’IA, pas de deleguer 100 % du developpement.

Qui n’a pas essaye de developper une app de zero a partir d’un seul prompt ? “Je veux une app pour agences immobilieres qui aide l’administrateur a calculer les mises a jour de prix de loyers, elle doit avoir un look & feel moderne et minimaliste et tourner sur toutes les plateformes.” L’IA vous a surement repondu “Oui patron, aucun probleme” et vous avez passe le reste de votre apres-midi a resoudre des erreurs, ou plutot, a demander a l’IA de les resoudre (cas vecu).

Pour eviter ce type de situations qui menacent la scalabilite du projet (et votre sante mentale), on vous recommande de suivre les conseils ci-dessous.

La philosophie “on fonce et on verra bien” ne devrait pas s’appliquer quand on travaille avec l’IA.

1. Commencez par un document technique auditable

Avant d’ecrire le premier prompt, commencez par ecrire votre objectif en langage naturel, dans votre propre langue. Si vous faites une application (c’est l’un des cas les plus courants), commencez par dire clairement et precisement ce que cette application doit faire, et enregistrez-le dans le readme du repo (plus a ce sujet au point suivant). Ca permet a n’importe quel humain d’auditer le projet, de donner un cap clair au LLM sur l’objectif general et de versionner tous les changements au fur et a mesure.

Les choses que vous devez absolument clarifier : l’objectif fonctionnel, les colonnes attendues et types de donnees, les regles metier et considerations speciales, les formules necessaires pour calculer les variables metier, etc.

Astuce : Utilisez une IA pour generer ce document lui-meme. Vous pouvez lui demander de se mettre dans le role d’un Product Owner et de rediger le document de specifications fonctionnelles. Vous pouvez faire de meme pour les exigences techniques ou la stack technologique.

2. Adoptez le developpement pilote par les tests (ecrits aussi en langage naturel)

Maintenant les modeles peuvent aussi vous aider a generer des tests et a les utiliser comme un outil fondamental du developpement. Dites-lui explicitement et en langage naturel ce que chaque test doit faire. Exemple : “Si le loyer est de 300 000 et la mise a jour est de 15 %, le prix actualise doit etre de 345 000”. Comme vous le voyez, le test doit etre 100 % interpretable et auditable par un humain.

Personnellement, je trouve utile de preparer un document a part avec la liste de tous les tests, en langage naturel, que je veux voir transformes en tests Python. La aussi, vous pouvez utiliser l’IA pour vous suggerer des tests.

Important : Verifiez que les changements de fonctionnalites ne modifient pas les tests existants. C’est justement le but des tests. Parfois l’IA “se croit maligne” et nous modifie les tests pour que son code passe les controles.

3. Appliquez des changements petits et incrementaux

En introduction, je vous ai deja raconte comment ca s’est passe quand j’ai essaye de faire une app de zero a partir d’un seul prompt. Ce n’est pas la bonne approche.

La cle est de faire une modification a la fois : ca reduit le contexte, ameliore la precision et minimise le nombre d’hallucinations (ou en tout cas, leur impact potentiel sur le projet).

En lien avec le point precedent sur les tests, accompagnez chaque changement incremental d’un mini test qui s’ajoute a la batterie existante, sans modifier les tests precedents.

4. Quand le perimetre de la tache change, reinitialisez le chat

La memoire des LLM finit par s’epuiser et quand on travaille intensement, le modele commence a trainer des hypotheses qui ont evolue au fil des iterations. C’est pourquoi on recommande de reinitialiser le chat de temps en temps : ce qui a ete discute ne se perd pas, mais se compacte (ce qui vous fait economiser en reduisant les tokens utilises) et passe dans une memoire a plus long terme. Et dans la meme veine…

5. Readme veut aussi dire “remember me”

A chaque nouvelle conversation, vous devriez rappeler au LLM le contexte de ce qu’il fait. La meilleure facon de le faire est de maintenir un readme structure, assertif et constamment mis a jour. Les chemins des dossiers, comment executer le code, comment lancer les tests, etc. : ces modeles sont excellents pour ecrire et generer de la documentation, alors utilisez-le a votre avantage (le revers de la medaille, c’est qu’il n’y a plus d’excuses pour ne pas livrer du code clair et impeccable).

“Fais une image de ce que ca fait de travailler avec moi tous les jours. Sois honnete et brutal”

6. Ne tardez pas a modulariser le code (et faites-vous assister par le LLM)

Dites adieu au app.py de 500 lignes le plus vite possible. Un bon moment pour le faire, c’est quand le MVP (l’idee minimale que vous aviez en tete) est fonctionnel meme dans les grandes lignes. A ce moment-la, demandez au LLM de proposer une structure et un plan de migration pour diviser la logique en dossiers (models/, data/, tests/, etc.).

Et ce point s’applique a tout moment mais surtout ici : qu’il vous explique toujours la logique avant d’executer un changement dans le code. En lien aussi avec le point sur les changements incrementaux, essayez que ce plan de migration soit un ensemble de petites etapes auditables, n’abordez pas un refactoring d’un seul coup.

7. Choisissez l’IA qui resout le mieux votre probleme

Ce point est un peu plus confus par moments : que choisir parmi les alternatives du marche ? Il n’y a pas de reponse standard, mais notre recommandation serait d’essayer plusieurs options et de garder celle qui resout le mieux votre probleme.

Chez deployr, mes collegues sont fans de Cursor et Windsurf, tandis que je suis fan de Copilot (j’ecris ma these de master avec cet outil, pour vous donner une idee).

En resume : testez-en plusieurs et voyez lequel fonctionne le mieux.

8. Utilisez l’IA pour apprendre, pas pour repondre en automatique

Quand le LLM reussit enfin a resoudre ce point complexe que vous ne saviez pas par quel bout prendre, ne vous contentez pas de la reponse, demandez aussi une explication. Demandez-lui une code review explicative et detaillee, pour comprendre la logique et apprendre en cours de route, ligne par ligne, et n’hesitez pas a demander des ressources supplementaires. Et pour des points bonus : vous pouvez stocker ces documents aussi dans un dossier du projet et les utiliser comme support pour le LLM lui-meme.

Personnellement, j’aime aussi lire comment l’IA raisonne en resolvant l’instruction que je lui ai donnee, ou elle trouve des inconsistances, quelle partie du code elle attaque. Je trouve ca divertissant et j’ai le sentiment d’apprendre. Et entre-temps, je me suis prepare un mate.

9. Le controle de version, plus important que jamais

Ce n’est pas propre au vibe coding, mais ça ne fait pas de mal de le rappeler. Tout ce dont on a parlé (tests, documents fonctionnels, code modulaire, changements incrémentaux, etc.) doit être versionné. Chaque changement, chaque test, chaque fonctionnalité ajoutée au README doit être commité et poussé dans le repo une fois qu’on a vérifié que tout fonctionne.

Avec un bon vieux depot git, vous etes pare pour eviter que les choses degeneret si le LLM commence a halluciner (ou plutot, quand il commencera a halluciner). Rappelons qu’il est courant que l’IA fasse des siennes, alors quand ca arrive, il suffit de reinitialiser le chat, revenir a la version precedente et c’est regle.

10. Transparence avant tout

Si quelqu’un vous demande, prenez votre meilleure poker face et dites que vous avez utilise l’IA. Pourquoi ne le feriez-vous pas ? Ca vous a permis d’accelerer vos delais de livraison, de produire un code correct et documente et vous avez meme appris en chemin. La confiance se construit en montrant le processus de maniere transparente et vous ne devriez pas avoir peur de montrer comment vous etes arrive au resultat.

Par contre : vous seul etes responsable du code. C’est pourquoi il est absolument critique de toujours comprendre ce que le LLM vous dit : si vous comprenez, si vous pouvez le justifier et expliquer pourquoi c’est la meilleure option pour resoudre un probleme donne, personne ne peut rien vous reprocher.

En resume…

Votre metier de dev n’a pas disparu, mais il va evoluer. Vous allez passer de “casser des cailloux” a concevoir des solutions, auditer et enseigner (et apprendre) grace a une IA.

C’est pour ca qu’il faut etre prudent : le vibe coding, ce n’est pas de la magie, c’est utiliser l’IA avec du bon sens. Il est crucial d’utiliser ces outils avec responsabilite et un objectif clair. En combinant documentation et jugement humain, tests et bonnes pratiques, l’IA devient une machine a efficacite et non une usine a bugs.