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

Vous avez sûrement déjà entendu le terme vibe coding. Si ce n’est pas le cas, c’est un terme inventé par Andrej Karpathy (une référence dans le monde de la data, du machine learning et de l’IA) pour désigner 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 façon de faire du vibe coding, de mon point de vue, c’est de coder en étant assisté par l’IA, pas de déléguer 100 % du développement.

Qui n’a pas essayé de développer une app de zéro à partir d’un seul prompt ? “Je veux une app pour agences immobilières qui aide l’administrateur à calculer les mises à jour de prix de loyers, elle doit avoir un look & feel moderne et minimaliste et tourner sur toutes les plateformes.” L’IA vous a sûrement répondu “Oui patron, aucun problème” et vous avez passé le reste de votre après-midi à résoudre des erreurs, ou plutôt, à demander à l’IA de les résoudre (cas vécu).

Pour éviter ce type de situations qui menacent la scalabilité du projet (et votre santé 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’écrire le premier prompt, commencez par écrire 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 précisément ce que cette application doit faire, et enregistrez-le dans le readme du repo (plus à ce sujet au point suivant). Ça permet à n’importe quel humain d’auditer le projet, de donner un cap clair au LLM sur l’objectif général et de versionner tous les changements au fur et à mesure.

Les choses que vous devez absolument clarifier : l’objectif fonctionnel, les colonnes attendues et types de données, les règles métier et considérations spéciales, les formules nécessaires pour calculer les variables métier, etc.

Astuce : Utilisez une IA pour générer ce document lui-même. Vous pouvez lui demander de se mettre dans le rôle d’un Product Owner et de rédiger le document de spécifications fonctionnelles. Vous pouvez faire de même pour les exigences techniques ou la stack technologique.

2. Adoptez le développement piloté par les tests (écrits aussi en langage naturel)

Maintenant les modèles peuvent aussi vous aider à générer des tests et à les utiliser comme un outil fondamental du développement. Dites-lui explicitement et en langage naturel ce que chaque test doit faire. Exemple : “Si le loyer est de 300 000 et la mise à jour est de 15 %, le prix actualisé doit être de 345 000”. Comme vous le voyez, le test doit être 100 % interpretable et auditable par un humain.

Personnellement, je trouve utile de préparer un document à part avec la liste de tous les tests, en langage naturel, que je veux voir transformés en tests Python. La aussi, vous pouvez utiliser l’IA pour vous suggérer des tests.

Important : Vérifiez que les changements de fonctionnalités 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 contrôles.

3. Appliquez des changements petits et incrémentaux

En introduction, je vous ai déjà raconté comment ça s’est passé quand j’ai essayé de faire une app de zéro à partir d’un seul prompt. Ce n’est pas la bonne approche.

La clé est de faire une modification à la fois : ça réduit le contexte, améliore la précision et minimise le nombre d’hallucinations (ou en tout cas, leur impact potentiel sur le projet).

En lien avec le point précédent sur les tests, accompagnez chaque changement incremental d’un mini test qui s’ajoute à la batterie existante, sans modifier les tests précédents.

4. Quand le périmètre de la tache change, réinitialisez le chat

La mémoire des LLM finit par s’épuiser et quand on travaille intensément, le modèle commence à traîner des hypothèses qui ont évolué au fil des itérations. C’est pourquoi on recommande de réinitialiser le chat de temps en temps : ce qui a été discuté ne se perd pas, mais se compacte (ce qui vous fait économiser en réduisant les tokens utilises) et passe dans une mémoire à plus long terme. Et dans la même veine…

5. Readme veut aussi dire “remember me”

À chaque nouvelle conversation, vous devriez rappeler au LLM le contexte de ce qu’il fait. La meilleure façon de le faire est de maintenir un readme structuré, assertif et constamment mis à jour. Les chemins des dossiers, comment exécuter le code, comment lancer les tests, etc. : ces modèles sont excellents pour écrire et générer de la documentation, alors utilisez-le à votre avantage (le revers de la médaille, 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 ça fait de travailler avec moi tous les jours. Sois honnête et brutal”

6. Ne tardez pas à 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’idée minimale que vous aviez en tête) est fonctionnel même dans les grandes lignes. À ce moment-là, 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 à tout moment mais surtout ici : qu’il vous explique toujours la logique avant d’exécuter un changement dans le code. En lien aussi avec le point sur les changements incrémentaux, essayez que ce plan de migration soit un ensemble de petites étapes auditables, n’abordez pas un refactoring d’un seul coup.

7. Choisissez l’IA qui résout le mieux votre problème

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

Chez deployr, mes collègues sont fans de Cursor et Windsurf, tandis que je suis fan de Copilot (j’écris ma thèse de master avec cet outil, pour vous donner une idée).

En résumé : testez-en plusieurs et voyez lequel fonctionne le mieux.

8. Utilisez l’IA pour apprendre, pas pour répondre en automatique

Quand le LLM réussit enfin à résoudre ce point complexe que vous ne saviez pas par quel bout prendre, ne vous contentez pas de la réponse, demandez aussi une explication. Demandez-lui une code review explicative et détaillée, pour comprendre la logique et apprendre en cours de route, ligne par ligne, et n’hésitez pas à demander des ressources supplémentaires. 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-même.

Personnellement, j’aime aussi lire comment l’IA raisonne en résolvant l’instruction que je lui ai donnée, où elle trouve des inconsistances, quelle partie du code elle attaque. Je trouve ça divertissant et j’ai le sentiment d’apprendre. Et entre-temps, je me suis préparé un maté.

9. Le contrôle 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 dépôt git, vous êtes paré pour éviter que les choses dégénèrent si le LLM commence à halluciner (ou plutôt, quand il commencera à halluciner). Rappelons qu’il est courant que l’IA fasse des siennes, alors quand ça arrive, il suffit de réinitialiser le chat, revenir à la version précédente et c’est réglé.

10. Transparence avant tout

Si quelqu’un vous demande, prenez votre meilleure poker face et dites que vous avez utilisé l’IA. Pourquoi ne le feriez-vous pas ? Ça vous a permis d’accélérer vos délais de livraison, de produire un code correct et documenté et vous avez même appris en chemin. La confiance se construit en montrant le processus de manière transparente et vous ne devriez pas avoir peur de montrer comment vous êtes arrivé au résultat.

Par contre : vous seul êtes 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 résoudre un problème donné, personne ne peut rien vous reprocher.

En résumé…

Votre métier de dev n’a pas disparu, mais il va évoluer. Vous allez passer de “casser des cailloux” à concevoir des solutions, auditer et enseigner (et apprendre) grâce à une IA.

C’est pour ça qu’il faut être 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 responsabilité et un objectif clair. En combinant documentation et jugement humain, tests et bonnes pratiques, l’IA devient une machine à efficacité et non une usine à bugs.