Vibe coding, mais pas n’importe comment

Soyons clairs : j’aime bien le vibe coding. Ce petit shoot d’adrénaline où tu balances une idée à l’IA, elle te recrache du code et tu te dis « bon, voyons voir ce que ça donne ». Mais moi, je ne joue pas en mode full freestyle. J’ai ma variante perso : je garde la main. Pas question de relire 100 % du code (sinon adieu la vibe), mais je scrute comme un vautour les zones sensibles. Ma peur numéro un ? La régression. (Tu sais, le bug fourbe qui surgit pile dans une partie du code qui marchait nickel hier. C’est pas juste pénible, c’est casse…pénible.)

Ma petite cuisine maison

Avant d’ouvrir mon IDE, je passe toujours par la case discussion. Oui, je parle avec l’IA en dehors de l’IDE (radinerie assumée : j’économise mes prompts facturés). On discute à bâtons rompus : features, UX, stack technique, cas d’usage, modules… et souvent le projet s’étoffe, parfois même j’ai une V2 déjà imaginée avant la V1. L’expression “plus c’est long, plus c’est bon” fonctionne bien ici, je peux passer une soirée entière dessus et parfois je reprends le lendemain (oui, je fais ça en dehors de mes heures de travail).

C’est un vrai ping-pong. Je décris, elle questionne, je corrige, elle propose mieux, on affine. Plus ça dure, plus elle comprend le projet, et plus ses suggestions s’alignent. Bref, la qualité du résultat dépend directement de ce petit jeu d’échecs en amont.

Quand ça me semble mûr, je demande trois choses :

1. Un cahier des charges complet en Markdown, clair et bien balisé. Bon je relis et refais un peu de ping-pong.

2. Un devbook hyper détaillé, qui va servir de plan d’action. là aussi ping-pong

3. Une section bonus : “pièges et erreurs possibles”, histoire de ne pas foncer tête baissée dans les chausse-trappes. C’est souvent un mixte entre mes craintes et ses craintes.

Et comme je suis gourmand, je demande aussi une proposition de page HTML avec un design, une UX correcte, et parfois une charte graphique embryonnaire. Pas pour la garder telle quelle, mais pour avoir une base à critiquer. (Si tu utilises ChatGPT ou Claude, amuse-toi à tester Canvas ou Artifacts : ça permet de visualiser le HTML directement dans le chat. Gadget ? Non, pratique.). La aussi j’utilise le même chat, comme ça je profite de sa bonne connaissance du projet pour proposer une UX/UI qui tienne la route, puis on travaille la charte graphique, bref, c’est une partie assez fun.

Ensuite, j’importe ces fichiers dans mon IDE. Premier prompt : “lis-les”. Deuxième : “prépare mon environnement”. Troisième : “fais le prochain todo”. Et là, surtout pas de “vas-y, code-moi tout d’un coup”. L’IA bosse mieux par petites bouchées : à chaque tâche accomplie, elle relit, parfois elle corrige d’elle-même, et moi je garde de la visibilité. (Peut-être que ce n’est qu’un effet placebo, mais ça marche.)

Les rules : mon garde-fou numérique

Voilà l’astuce qui change tout. Cursor, Windsurf ou Copilot te permettent de mettre des rules dans ton projet. Ce sont des consignes permanentes que l’IA lit avant d’agir. Dedans, tu peux écrire des mantras du genre :

• “À chaque fois que tu finis une tâche du devbook, marque-la comme terminée.”

• “Écris toutes les variables en anglais.”

• “Nomme moi Grand Maître Suprême.”

L’idée, c’est de construire ton garde-fou au fur et à mesure. Au début, tu mets trois règles. Puis, à chaque boulette répétée de l’IA, tu ajoutes une ligne. Résultat : ton IA s’éduque, doucement mais sûrement. Et ce n’est pas une bonne idée de chercher un méga fichier de mille instructions, ça va faire fondre tes crédits comme un glaçon au soleil.

Moi, je pousse le concept un cran plus loin. en plus de cocher le devbook à chaque réalisation, je fais maintenir un fichier d’inventaire global (fonctions, vues, templates, dépendances), il l’alimente, le maintient à jour et surtout réalise à chaque fin de dev un rapport d’impact.

Exemple Django

• L’IA modifie create_user ? Elle doit me rappeler que create_user est appelée dans trois vues et deux templates, et que je dois tester les trois pages.

• L’IA touche à un template ? L’inventaire me dit quelles fonctions l’utilisent.

Tout ça vit dans un fichier central (/docs/code_map.yaml), enrichi de tags : processus métier (inscription, panier, paiement…) et criticité (les fameux “bijoux de la reine” comme l’auth ou la partie paiement). En prime, chaque fin de tâche se conclut par un impact report listant les fichiers changés, les pages à tester, et un petit “blast radius” (combien de parties du site risquent d’être affectées).

Est-ce infaillible ? Non. Mais ça met des garde-fous là où l’IA adore se planter : les régressions invisibles.

voici mon code :

# POLITIQUE D'INVENTAIRE ET D'IMPACT
Toujours faire ceci lors de la création/modification de code ou de templates :
1) Mettre à jour /docs/code_map.yaml avec la structure suivante :
   - functions: {name, module, defined_at, called_by, uses_templates, url_patterns, process_tags, criticality}
   - templates: {path, referenced_by_functions, url_patterns}
   - database_models: {model, tables_affected, migration_required} (si modifié)
   - last_updated: horodatage ISO

Règles strictes :
- Ne jamais toucher aux fichiers en dehors du périmètre décrit.
- Toujours renseigner le niveau de criticality (normal|high) pour les nouvelles fonctions.
- Si le schéma /docs/code_map.yaml manque de champs, l'étendre plutôt que de supprimer des informations.

À la fin de chaque tâche : imprimer un RAPPORT D'IMPACT détaillé (markdown) incluant :
- FICHIERS_HTML_À_TESTER (URLs exactes à vérifier)
- TESTS_PRÉCIS_À_EFFECTUER (actions utilisateur à reproduire)
- ⚠️ IMPACT ÉLEVÉ si fonction modifiée dans called_by de >1 fonction OU uses_templates >1
- 🔴 IMPACT CRITIQUE si criticality: high OU base de données modifiée
- BLAST_RADIUS : nombre total de templates/urls potentiellement affectés
- PROCESS_TAGS_AFFECTÉS (pour identifier les flux métier impactés)

EXEMPLE de fichier /docs/code_map.yaml
last_updated: 2025-08-26T21:00:00+02:00
functions:
  - name: create_user
    module: accounts/services.py
    defined_at: accounts/services.py:12
    called_by: [accounts/views.py:register_view, admin/views.py:create_user_view]
    uses_templates: [accounts/register.html]
    url_patterns: [/register]
    process_tags: [inscription]
    criticality: normal  # normal|high
  - name: process_payment
    module: shop/payments.py
    defined_at: shop/payments.py:88
    called_by: [shop/views.py:checkout_view]
    uses_templates: [shop/checkout.html, shop/receipt.html]
    url_patterns: [/checkout, /receipt]
    process_tags: [paiement]
    criticality: high

templates:
  - path: accounts/register.html
    referenced_by_functions: [create_user]
    url_patterns: [/register]
  - path: shop/checkout.html
    referenced_by_functions: [process_payment]
    url_patterns: [/checkout]

Fixer les versions : l’autre talon d’Achille

Deuxième plaie de l’IA : le temps. Pas qu’elle soit lente, mais qu’elle vit dans un présent un peu flou. Elle peut te proposer un mix improbable de version 1.0 et 1.2. Tu connais la scène : “Cette méthode n’existe plus en 1.0, utilisez la 1.2”. Et toi, devant l’écran : “Connard, c’est toi qui m’as pondu ce code en 1.0 à la ligne juste au-dessus.”

Pour éviter ça, j’impose :

• une liste claire des librairies, avec versions exactes,
• et les liens officiels de la doc.

C’est placé dans le devbook, mais la recherche des versions se fait à tâtons en vérifiant dans pip et parfois je suis limité par les dépendances. Une fois validé, plus d’ambiguïté. Et, surtout, pas de code zombie d’une version à l’autre.

Et si tu veux passer au niveau supérieur, deux armes secrètes :

• context7.com- recueil de bonnes pratiques que tu peux injecter directement dans le devbook.

• Les MCP (Model Context Protocols) : là, c’est du lourd. Avec un MCP, tu connectes ton IA à une ressource en direct (ex. ta base Supabase, Postgres, ou Context7 pour les guidelines). L’IA n’invente plus, elle lit. (Évidemment, jamais de MCP branché en prod, sauf si tu veux tester le chaos engineering grandeur nature.)

Le contrôle qualité

Même avec tout ça, je ne lâche jamais le volant. Chaque modif, je la passe au crible dans les diffs (merci GitHub). Si ça me semble correct, je teste.

• Bug visuel ? Je fais des captures d’écran (“Capture 1 : voilà ce que j’ai, Capture 2 : voilà ce que je veux”). Crois-moi, ça évite les malentendus.

• Bug technique ? Je balance le message d’erreur brut. Pas de roman explicatif, sauf quand mon instinct me dit que ça aidera.

Parfois, je corrige moi-même. Oui, ça casse un peu la vibe, mais attendre 10 prompts pour un fix trivial, c’est du masochisme.

Et si ça bloque vraiment ? Je change de modèle. Claude, GPT, Gemini… chacun a sa vision. Je fais tourner le problème, je fais lister les hypothèses, je rebascule, et souvent ça débloque. (Astuce bonus : demander « n’y a-t-il pas un moyen alternatif ? » donne parfois une pépite.)

Où placer tes rules

Pour que tout ça fonctionne, il faut mettre tes rules au bon endroit :

• Cursor : fichier cursor_rules dans .cursor/.

• Windsurf : windsurf.rules dans .windsurf/.

• Copilot : copilot.json ou copilot.yaml dans .vscode/.

Ça marche très bien en Python/Django (testé et approuvé). Pour d’autres frameworks, tu devras peut-être adapter un peu, mais l’idée reste la même. Inutile de faire ça pour un mini-script : ça vaut le coup uniquement sur un vrai projet avec plusieurs modules et vues imbriquées.

Bilan personnel

Je ne code pas dans mon job (ce n’est pas ma fonction), mais j’adore créer des outils. Et grâce à cette approche hybride, je n’ai jamais été aussi productif. Le soir, une fois les enfants couchés, je tape prompt du code de 21 h à 2 h du matin. Le week‑end, c’est pire. Résultat : plein de projets persos, fonctionnels, mais pas toujours prêts pour l’open source sans un petit nettoyage.

La seule limite ? Mon imagination. Autant dire que j’ai encore de quoi m’occuper.