Ma méthodologie de Vibe Coding : développer des logiciels avec l'IA en 2026

Il y a quelques mois, j'ai commencé à repenser complètement ma façon de développer. Non pas parce que je voulais coder moins - mais parce que je voulais coder mieux, plus vite, et avec moins de friction entre une idée et sa mise en production. Ce que j'appelle le vibe coding, c'est une méthodologie structurée où l'IA devient un vrai partenaire de développement, pas juste un moteur d'autocomplétion.

Cet article est un retour d'expérience concret sur tout ce que je mets en place : de la phase amont d'un projet jusqu'au déploiement en production, en passant par les GitHub Actions qui me permettent de déléguer une partie du travail à un agent complètement autonome.

Partie 1 - Développement supervisé au quotidien

Avant même d'écrire la première ligne

Le setup en amont d'un projet conditionne tout ce qui suit. Si cette phase est bâclée, l'IA part dans tous les sens et produit du code générique, mal adapté à la stack et aux contraintes du projet. Voici ce que je mets systématiquement en place.

Brainstorming avec l'IA pour cadrer le projet

Avant de choisir quoi que ce soit techniquement, je fais un brainstorming avec l'IA pour clarifier l'objectif du projet, identifier les contraintes, et surtout définir la stack adaptée. Ce n'est pas une étape que je délègue entièrement - c'est un dialogue. L'IA propose, je questionne, je pousse, et on converge vers quelque chose de cohérent.

Installer les bons Skills

Claude Code (et d'autres outils similaires) permet d'installer des skills : des fichiers de contexte qui orientent l'IA vers les bonnes pratiques d'une technologie ou d'un domaine. C'est l'une des étapes les plus sous-estimées.

Ma sélection habituelle :

frontend-design - pour éviter les interfaces génériques et pousser vers un vrai travail de design
improve-codebase-architecture - pour garder une architecture propre au fil des itérations
ui-ux-pro-max - pour des interfaces pensées pour l'utilisateur
vercel-react-best-practices - pour coller aux conventions de l'écosystème Next.js/Vercel
web-design-guidelines, shadcn - pour les composants et la cohérence visuelle
find-skills - pour découvrir de nouveaux skills pertinents au fil du projet
agent-browser - pour les tâches nécessitant une navigation web
Et des skills spécifiques à ma stack : better-auth, prisma, etc.

Sans ces skills, l'IA a tendance à réinventer la roue ou à utiliser des patterns dépassés. Avec eux, elle code dans le bon idiome dès le départ.

Créer un CLAUDE.md (ou plusieurs)

Le CLAUDE.md est le document de référence que l'IA lit à chaque session. C'est là que je pose le contexte du projet, la stack, les objectifs - et surtout les règles de développement que je veux voir respectées :

Développement en TDD (Red → Green → Refactor)
Chaque feature sur une branche dédiée
Vigilance sur la sécurité, priorité aux actions côté serveur
Logs adaptés pour une bonne observabilité en production
Mise à jour du fichier après chaque changement majeur

Une règle que j'ai apprise à la dure : le CLAUDE.md ne doit pas dépasser 300 lignes. Au-delà, il perd en efficacité. L'IA commence à diluer les instructions dans trop de contexte. Je force donc une règle explicite dans le fichier lui-même pour qu'il reste concis et pertinent.

Sur des projets plus conséquents, j'ai plusieurs CLAUDE.md - un à la racine du projet, et d'autres dans des sous-dossiers spécifiques (comme .github/CLAUDE.md pour les instructions propres aux runners CI, que je détaille en partie 2).

MCPs : puissants, mais à doser

Les MCPs (Model Context Protocol servers) permettent à l'IA de se connecter à des sources de données externes. En pratique, c'est extrêmement utile pour déboguer sur des données réelles sans avoir à écrire de scripts ad hoc - je peux demander à l'IA d'interroger directement ma base de données ou mes logs.

Mais attention : chaque MCP consomme des tokens. En mettre trop alourdit inutilement chaque appel et peut dégrader la qualité des réponses. Je n'installe que ceux dont j'ai besoin pour la session en cours.

Partir d'une bonne base

Avant de démarrer, je cherche un template ou une boilerplate propre et bien configurée. L'IA est nettement plus efficace quand elle part d'une codebase existante et cohérente que quand elle scaffolde tout from scratch.

Un détail qui compte : j'installe les composants et les librairies moi-même, via les CLI officiels. Si je délègue cette étape à l'IA, elle a tendance à écrire du code « à la main » au lieu d'utiliser les outils appropriés (npx shadcn add button, npx prisma init, etc.). Le résultat est souvent moins propre et moins conforme aux conventions de la librairie.

Développer une nouvelle feature

Une fois le projet bootstrappé, le cycle de développement d'une feature suit toujours la même structure.

1. Brainstorming initial

Avant tout, un échange rapide avec l'IA pour organiser mes idées, identifier les cas limites, et valider que j'ai bien pensé à tous les aspects de la feature.

2. La commande `/plan`

C'est l'étape qui fait la différence entre une session productive et une session frustrante. La commande /plan demande à l'IA de m'interroger sur certains aspects de la feature avant de se lancer, et de produire un plan de développement détaillé. Cela me permet de vérifier que l'IA va dans la bonne direction avant qu'elle n'écrive une seule ligne de code.

3. Développement conforme au CLAUDE.md

L'IA développe en respectant les règles définies en amont : elle écrit les tests d'abord, les fait passer, puis lance le build et le lint pour valider que tout est propre. Elle ouvre une PR sur la branche dédiée à la feature.

4. Test en local ou en preview

Une fois la feature développée, je la teste manuellement. Selon le projet, c'est soit en local, soit sur un environnement de preview (Vercel, par exemple).

5. Refactor et `/review`

Si le test est concluant, je demande un refactor, puis je lance /review pour que l'IA relise sa propre PR avec un œil critique. En fonction de son retour, il peut y avoir plusieurs allers-retours jusqu'à ce que la PR soit vraiment propre.

6. CI/CD et merge

Une fois que la PR passe tous les checks de la pipeline CI/CD, elle est bonne pour être mergée. L'humain garde le contrôle du merge - toujours.

Résoudre un bug

La résolution de bugs suit un protocole différent, pensé pour éviter les corrections « à l'aveugle » qui règlent un symptôme sans traiter la cause.

1. Récolter les logs. Les logs mis en place lors du développement de la feature sont ma première source d'information. C'est pour ça que l'observabilité est une règle non-négociable dans mon CLAUDE.md.

2. Investigation sans modification. Je demande à l'IA d'investiguer, mais sans toucher au code. L'objectif est d'avoir une ou plusieurs hypothèses vérifiables. Cette étape est cruciale : selon le modèle utilisé, l'IA peut parfois corriger un problème précis sans penser globalement à l'impact de ses changements. Il faut que moi, côté humain, je comprenne clairement le problème avant d'autoriser quoi que ce soit.

3. Prouver ou écarter les hypothèses. Je demande à l'IA de mettre en place des scripts ou des tests pour valider les hypothèses. Pas de fix à l'aveugle.

4. Red → Green. Une fois le problème clairement identifié, l'IA écrit d'abord un test qui échoue (red), puis corrige le code pour le faire passer (green).

5. La suite du pipeline. Build, tests, test en local ou en preview, boucles de review, CI/CD, merge. Même processus que pour une feature.

Partie 2 - Agentic Coding avec GitHub Actions

L'agentic coding, c'est l'étape suivante : l'IA ne se contente plus d'exécuter des tâches que je lui confie en direct. Elle tourne de manière autonome dans un runner CI, déclenche ses propres commandes, ouvre des PRs, et me notifie quand elle a besoin d'un arbitrage humain.

J'ai mis en place deux GitHub Actions : une pour l'exécution des tâches, une seconde dédiée à la review. Quand quelqu'un (moi, un collaborateur, ou moi-même depuis mon téléphone) mentionne l'agent sur une issue GitHub, celui-ci se déclenche et suit un pipeline structuré.

Le pipeline de l'agent

Le pipeline que l'agent suit est défini dans un fichier .github/CLAUDE.md - distinct du CLAUDE.md projet, et spécifique au mode autonome.

Étape 1 - Investigate. L'agent lit l'issue, les commentaires existants, et le contexte du repo.

Étape 2 - Juger la complexité. C'est l'étape de décision critique. Si la tâche est non-triviale (plus de 3 fichiers modifiés, migration de base de données nécessaire, refacto cross-module, nouvelle dépendance, etc.), l'agent poste un plan en commentaire sur l'issue et attend un « go » avant de coder. Si c'est trivial (bug fix 1-2 fichiers, ajout de test, ajustement de copy), il enchaîne directement sur le code.

Étape 3 - Code sur une branche dédiée. La branche suit une convention de nommage stricte : feature/issue-<num>-<kebab-slug>, fix/, ou chore/ selon la nature de la tâche. Les tests sont ajoutés conformément au workflow Red → Green → Refactor.

Étape 4 - Itérer jusqu'au vert, avec un cap dur de 3 essais. À chaque itération, l'agent rejoue toute la chaîne de validation du projet : installation des dépendances, suite de tests, build de production, lint et vérification de types. Si après 3 essais une commande est toujours rouge, l'agent ne pousse pas la PR. Il commente l'issue avec ce qu'il a essayé, les erreurs résiduelles et ce qui le bloque - puis s'arrête. Ce cap est volontaire : une PR rouge serait de toute façon bloquée au merge par les required checks. Mieux vaut signaler honnêtement que pousser du code bancal.

Étape 5 - Self-review légère. L'agent relit son propre diff comme s'il reviewait une PR tierce : bugs évidents, oublis de tests, cas limites, dette technique introduite.

Étape 6 - Fix des points critiques, 1 seul cycle. Si la self-review identifie des bloquants, l'agent les corrige. Un seul cycle review → fix → review. Si des problèmes persistent après ce cycle, il signale et s'arrête plutôt que de boucler indéfiniment.

Étape 7 - Rebase si nécessaire. Si la branche a divergé de main, l'agent rebase. En cas de conflit non-trivial, il commente l'issue et s'arrête - pas de résolution à l'aveugle.

Étape 8 - Push et ouverture de la PR. La PR suit un format précis :

Titre court (< 70 chars), impératif anglais
Fixes #<num> pour l'auto-close de l'issue
Une section Summary avec le « why », pas le « what »
Un Test plan avec des scénarios humains actionnables à tester sur l'environnement de preview
Une liste des Files touched

Les garde-fous

L'autonomie de l'agent est encadrée par des règles dures que je ne négocie jamais :

Jamais committer sur main - toujours une branche dédiée
Jamais merger sa propre PR - le merge reste un acte humain
Jamais approuver sa propre PR - même si la config GitHub le permettrait techniquement
Jamais committer de secrets - aucun .env, token ou credential dans le code
Jamais désactiver un test pour faire passer la CI - si un test casse, on corrige le code ou on explique pourquoi l'ancien comportement n'est plus pertinent
Cap 3 essais sur le pipeline, cap 1 cycle de review → fix → review

Les paths sensibles

Certains fichiers déclenchent automatiquement un second workflow de review orienté sécurité :

Authentification et gestion des sessions
Secrets et variables d'environnement
Migrations et schéma de base de données
API externes, webhooks, crons
Logique exécutée côté serveur

Sur ces paths, l'agent redouble de vigilance : pas de secret dans les logs, tout accès privilégié passe par un contrôle d'autorisation centralisé, tout webhook vérifie son secret de façon timing-safe, toutes les mutations sensibles passent côté serveur.

Base de données isolée par preview

Un détail d'architecture que j'apprécie particulièrement : chaque PR dispose de sa propre base de données isolée, créée automatiquement à partir d'une copie de la prod. L'environnement de preview se connecte à cette copie, jamais à la prod. Cela signifie que l'agent peut tester des migrations sans aucun risque pour les données de production. À la fermeture ou au merge de la PR, cette base éphémère est détruite automatiquement.

Ce que cette méthodologie change vraiment

Le vibe coding, tel que je le pratique, n'est pas une question de délégation totale. C'est une question d'allocation intelligente de l'attention humaine. L'IA gère l'exécution, la répétition, les vérifications mécaniques. Moi, je garde la main sur les décisions architecturales, la validation fonctionnelle, et le merge final.

Le résultat : je livre plus vite, avec moins de bugs, et avec une codebase que je peux relire et comprendre - parce que j'ai été dans la boucle à chaque étape qui compte.

Cet article sera mis à jour au fil de mes expérimentations. Si tu as des questions ou des retours sur cette approche, écris-moi via la page contact.