Vibe Coding : mon retour d'expérience
Cela fait plusieurs mois que cet article traîne dans mes brouillons. Pour être précis, depuis novembre 2025. Non pas par manque de matière — au contraire — mais parce que chaque semaine apportait son lot d'annonces, de nouveaux outils, de nouvelles promesses. Difficile de mettre un point final à quelque chose qui ne cesse de bouger. Et puis j'ai compris : ce n'est pas un sujet qu'on clôt, c'est un sujet qu'on traverse. Voilà donc mon récit, volontairement synthétique, parfois décousu, mais entièrement honnête. Un retour d'expérience de développeur du dimanche plongé tête la première dans l'univers du Vibe Coding.
Avant de rentrer dans le vif du sujet, je dois vous présenter mon profil. Je ne suis pas un grand développeur au sens académique du terme. Je programme principalement en PHP et JavaScript, je bidouille un peu de Java et de C, et pour le fun, j'écris des scripts en Lua — un langage de niche que peu de personnes connaissent encore, mais qui a son charme. C'est donc dans cet univers-là, surtout PHP, que j'ai conduit l'essentiel de mes expérimentations. Ce profil modeste est, je crois, une force dans ce récit : si le Vibe Coding fonctionne pour moi, il peut fonctionner pour beaucoup de monde.
Mon article s'articule autour de trois grandes parties : l'interface ou IDE pour le Vibe Coding, le choix du modèle LLM, et enfin mes outils open source pour travailler en local. Bonne lecture.
1. Quelle interface pour coder sans vraiment coder ?
J'ai entendu parler du Vibe Coding pour la première fois en octobre 2025. Ce concept popularisé notamment par Andrej Karpathy — ancien directeur de l'IA chez Tesla et chercheur chez OpenAI — décrit une nouvelle façon de programmer : on décrit ce que l'on veut en langage naturel, et l'IA se charge d'écrire le code à notre place. On n'est plus vraiment développeur ; on est directeur artistique de son propre projet logiciel.
Ce que j'ai réalisé à ce moment-là, c'est que je pratiquais déjà quelque chose de proche sans lui donner de nom.
Mon IDE de prédilection est ZED (zed.dev). Je ne suis jamais vraiment accroché à Visual Studio Code ni à ses dérivés comme Cursor — peut-être une allergie latente à Microsoft, peut-être le souvenir des années Eclipse où l'on passait plus de temps à configurer l'outil qu'à l'utiliser. ZED, c'est tout l'inverse : minimaliste, rapide, efficace. Il a très tôt intégré l'IA directement dans le flux de travail, notamment via des modèles Ollama exécutés en local (on y reviendra). Son seul vrai point noir reste sa prise en main : beaucoup d'opérations passent par des raccourcis clavier qu'il faut apprendre, et la configuration initiale demande un peu d'investissement. Heureusement, la communauté est active, et il est même possible d'importer ses configurations depuis VSCode pour retrouver ses automatismes.
À l'époque, j'utilisais l'IA de ZED pour me générer des petites fonctions ou des classes que je n'avais pas envie de coder moi-même. Des tâches basiques, l'équivalent d'un moteur d'autocomplétion très avancé. Je savais faire ces choses ; je ne voulais tout simplement pas perdre de temps. Et puis, j'ai commencé à franchir un palier supplémentaire : demander à l'IA de créer un plugin WordPress complet, puis un outil de traçage GPS. Les résultats étaient là. Pas parfaits — il m'arrivait encore de mettre les mains dans le code pour déboguer — mais les fondations étaient posées.
C'est là que m'est venu un désir de radicalité : et si on oubliait complètement l'IDE ? Et si le code devenait juste un substrat invisible derrière la création ?
Le terminal, interface ultime (et ses limites)
Sur Linux, l'interface la plus minimaliste qui soit, c'est le terminal. J'ai donc commencé à explorer les outils en ligne de commande conçus pour le Vibe Coding. J'ai testé Gemini CLI (Google), Claude Code CLI — la référence chez de nombreux développeurs professionnels (docs.anthropic.com) — mais aussi Cursor CLI, Codex CLI (OpenAI), GitHub Copilot CLI, sans oublier des solutions moins connues comme Kimi Code, Qwen Code, MiniMax CLI ou Mistral Code.
C'est en plongeant dans cet écosystème que j'ai découvert le concept d'agents de code : des systèmes capables de planifier, construire et réviser du code de façon autonome. J'ai exploré les architectures multi-agents, les subagents, les systèmes de contexte et de plugins. J'ai appris à connecter de nouveaux services via les MCP (Model Context Protocol) — un standard proposé par Anthropic pour relier les LLM à des outils externes comme des bases de données, des API ou des systèmes de fichiers. En pratique, je pouvais désormais créer des agents qui se chargent de planifier, de construire et de relire le code, sans que j'aie besoin d'y toucher.
Fascinant. Et chronophage. Plus je testais, plus j'imaginais des automatisations nouvelles, et moins j'avancais sur mes projets réels.
OpenCode : l'équilibre trouvé
Je voulais un outil agnostique aux LLM — c'est-à-dire compatible avec n'importe quel modèle — et entièrement libre. J'ai donc testé OpenCode et Goose (by Block, l'entreprise derrière Square). J'ai finalement choisi de me concentrer sur OpenCode, séduit par son écosystème dynamique et sa capacité à évoluer rapidement.
La version CLI d'OpenCode est pratique et puissante, mais elle reste l'apanage des initiés : raccourcis à mémoriser, menus cachés, courbe d'apprentissage. Puis est apparue une version desktop : même puissance, mais dans une interface graphique sobre, sous forme de simple chat. On tape ce qu'on veut faire, l'IA s'en charge. C'est l'outil que j'utilise encore aujourd'hui.
La nouvelle vague des interfaces agentiques
Alors que je me croyais arrivé à destination, deux nouveaux acteurs ont bousculé le paysage. OpenClaw a fait son apparition — et dans la foulée, Anthropic a lancé Claude Cowork : une interface encore plus dépouillée pour exécuter des agents directement sur son poste, capable de prendre le contrôle des interfaces graphiques de l'ordinateur. Une sorte d'assistant qui "voit" votre écran et agit à votre place. En réponse, OpenCode a lancé OpenWork. Personnellement, j'ai préféré rester sur OpenCode pour mes sessions de Vibe Coding — par habitude, par confiance dans l'outil, et parce qu'on ne change pas une équipe qui gagne.
2. Quel modèle LLM choisir pour coder ?
Pendant ces quelques mois, j'ai testé de nombreux modèles de langage. Pour éviter de multiplier les abonnements, j'ai utilisé OpenRouter (openrouter.ai) : une plateforme qui agrège des dizaines de modèles accessibles via une seule clé API. Un seul accès, un seul paiement, des centaines de modèles disponibles. Je les ai testés un par un, sur plusieurs mois, en conditions réelles.
Claude Sonnet : le meilleur de mes tests
Je ne vais pas faire l'originalité pour l'originalité : Claude Sonnet (Anthropic) est, dans mes tests, le modèle le plus efficace pour le Vibe Coding. À chaque demande, je n'ai quasiment jamais eu besoin de rentrer dans le code. Deux ou trois échanges pour affiner mes spécifications, et le résultat correspondait à ce que j'attendais. J'ai également testé Claude Opus (le modèle premium d'Anthropic, plus puissant mais plus coûteux), sans constater d'avantage décisif pour mes usages.
Les belles surprises : les modèles moins connus
En dehors de ce numéro un, j'ai eu de très bonnes surprises avec des modèles moins médiatisés : MiniMax, Kimi (Moonshot AI) et GLM (Zhipu AI). Mes tests portaient à 80 % sur du PHP et du JavaScript, avec quelques exercices en C et en Lua. Ces modèles m'ont généré du code fonctionnel dans 95 à 98 % des cas après quelques échanges d'affinage. Quelques bugs ont nécessité de chercher d'autres approches, mais rien d'insurmontable.
J'ai également eu une belle surprise avec kat-coder-pro, accessible gratuitement au moment de mes tests, qui a produit des résultats remarquables.
Les déceptions
Les grands noms ne m'ont pas toujours convaincu. GPT (OpenAI), Grok (xAI) et surtout DeepSeek ont généré plus de problèmes que prévu. Avec ces modèles, j'ai régulièrement dû me plonger dans le code pour comprendre ce qui n'allait pas. DeepSeek a même bouclé indéfiniment sur un problème en C, incapable de trouver une solution — ce qui, pour un modèle souvent présenté comme révolutionnaire, m'a laissé perplexe.
Il faut préciser que tous ces modèles évoluent constamment : mes résultats de fin 2025 ne reflètent pas forcément les performances actuelles. Mais, étrangement, je continue d'utiliser les mêmes modèles sélectionnés, sans éprouver le besoin de revenir tester ceux qui m'avaient déçus.
3. Le local : reprendre le contrôle de ses données
Si vous avez suivi jusqu'ici, vous devinez déjà ma réponse sur l'interface locale : OpenCode, avec une personnalisation poussée via des Skills.
Les Skills dans OpenCode sont des fichiers de configuration qui permettent de définir des conventions de code : syntaxe JavaScript spécifique à un projet, règles de nommage, langue des commentaires (anglais ou français), bonnes pratiques d'architecture... Pour gagner du temps, je recommande d'explorer le site skillsmp.com/fr, qui recense des Skills prêts à l'emploi créés par la communauté.
Jan.ai : le ChatGPT local
Pour faire tourner un LLM en local, j'ai opté pour Jan.ai (jan.ai). Cet outil permet de disposer d'un équivalent de ChatGPT entièrement sur sa propre machine — aucune donnée n'est envoyée sur un serveur externe. Il supporte les modèles compatibles Llama (le format open source popularisé par Meta), les connexions à des fournisseurs distants via des serveurs MCP pour étendre ses capacités (recherche dans ses fichiers locaux, connexion à des API...). Surtout, Jan.ai peut exposer un serveur local compatible avec l'API OpenAI, ce qui le rend utilisable directement depuis OpenCode.
Quels modèles locaux pour coder ?
En local, j'alterne entre plusieurs modèles selon les besoins : LFM (Liquid Foundation Models), Ministral (Mistral AI), Qwen (Alibaba Cloud) et Gemma (Google DeepMind). Ces modèles fonctionnent sans connexion internet, sur ma propre machine, et m'ont permis — entre autres — de développer des scripts Python pour générer automatiquement des présentations avec la bibliothèque python-pptx, un langage que je maîtrise très peu.
Pour explorer les modèles compatibles Ollama et trouver celui qui correspond à votre usage, je vous recommande le site ollama.com. En filtrant sur la catégorie "Tools", vous identifiez rapidement les modèles capables d'utiliser des outils externes — un critère important pour le Vibe Coding. Vous pourrez y trouver également des modèles comme GPTOSS, moins connus mais souvent étonnants.
L'avenir des petits LLMs
Je suis convaincu que les modèles locaux et spécialisés vont connaître un développement important dans les prochaines années. L'ère du "tout dans un énorme modèle généraliste" touchera peut-être à sa fin, au profit de petits LLMs très efficaces sur des domaines précis. Ce mouvement est déjà en marche : dans le domaine de la cartographie par exemple — une autre de mes passions — j'utilise ces petits modèles pour faciliter l'interprétation de données LiDAR, de photogrammétrie ou de GPS. Pour ceux qui souhaitent en apprendre davantage sur les données ouvertes cartographiques en France, l'IGN propose un portail remarquable : ign.fr.
4. Ce que j'ai vraiment appris
Les LLMs évoluent si vite qu'au moment où je finalise cet article, de nouvelles versions sont déjà sorties. Des outils comme Hermes font leur apparition et promettent à chacun son assistant personnel. Est-ce que j'ai perdu mon temps ?
Non. Absolument pas. Et voilà pourquoi.
Au-delà des outils testés, ces mois d'expérimentation m'ont appris quelque chose de bien plus précieux : la méthode. Le Vibe Coding n'est pas juste "parler à une IA et voir ce qui sort". Si on le pratique sérieusement, c'est une discipline qui demande une vraie rigueur amont.
Ma méthode de travail actuelle
Voici comment je procède désormais, et je pense que cette approche peut être utile à beaucoup :
Étape 1 — Zéro code d'emblée. Je commence par expliquer au LLM tous les user stories attendus, idéalement classés par ordre de priorité. Pour les flux complexes, j'utilise Mermaid (mermaid.js.org) pour schématiser les interactions sous forme de diagrammes — un langage que les LLM comprennent très bien.
Étape 2 — Génération des spécifications. Je demande au modèle de produire un document de spécifications complet à partir des user stories, ainsi que les cahiers de tests associés. Je lui demande explicitement de me poser des questions s'il a des zones d'ombre.
Étape 3 — Revue croisée. Je soumets ces spécifications à un second LLM — pas le même que celui qui les a rédigées — pour identifier d'éventuels angles morts. Cette double lecture m'a évité plusieurs erreurs de conception.
Étape 4 — Découpage par priorité. Le modèle découpe ensuite les spécifications en features indépendantes, classées par ordre de priorité. Chaque feature est isolée et documentée.
Étape 5 — Le code, enfin. Je lance le codage feature par feature, en m'appuyant sur des Skills qui définissent les bonnes pratiques (front, back, design, API, SEO...). Pour chaque feature codée, je demande au modèle de vérifier que les tests du cahier de tests passent bien.
Étape 6 — Compilation et correction automatique. Si le code doit être compilé (comme en C), je demande au modèle de le faire et de corriger lui-même les erreurs éventuelles.
Étape 7 — Journal des erreurs. Toutes les erreurs rencontrées et corrigées sont enregistrées dans un fichier dédié. C'est une mine d'or pour comprendre les limites du modèle ou les ambiguïtés de mes spécifications.
Étape 8 — Multi-agents et code review. J'organise le travail via des subagents pour maintenir des contextes limités et efficaces. Et en fin de parcours, un agent est chargé de la revue de code.
Le point aveugle : la sécurité
Il y a un sujet que beaucoup de Vibe Coders ignorent — et c'est dangereux : la sécurité. Chaque semaine, on lit des articles sur des applications générées par IA déployées en production et piratées en quelques heures. Les uploads de fichiers non sécurisés, les injections de code, les surfaces d'attaque laissées béantes... Ce sont des problèmes réels, et l'IA ne les résout pas spontanément. C'est le chantier sur lequel je travaille actuellement : intégrer systématiquement une phase d'audit de sécurité dans ma méthode de Vibe Coding.
En guise de conclusion : vers l'IA domestique
Le paysage évolue si vite que les acteurs majeurs d'aujourd'hui ne seront pas forcément ceux de demain. En quelques mois, j'ai vu mon entourage passer de ChatGPT à Gemini, ou adopter des solutions plus intégrées comme Claude Cowork. Personne ne sait vraiment où tout cela mène.
Mais j'ai une conviction : l'agent IA va se démocratiser de manière radicale. Je vois venir une sorte de box domestique — locale, connectée, personnelle — qui nous aidera au quotidien : créer, apprendre, rechercher, organiser. Un objet qui serait au cœur du foyer comme la télévision l'était dans les années 80. Apple prépare peut-être déjà un Siri "agentique" capable de tenir ce rôle. Amazon et Google n'en sont pas loin non plus avec leurs assistants connectés.
Le Vibe Coding, finalement, n'est qu'une manifestation parmi d'autres d'un mouvement bien plus large : celui de l'IA qui se fond dans notre quotidien jusqu'à disparaître en tant qu'outil visible, pour ne laisser que la création, la pensée, l'intention.
Et ça, franchement, ça mérite bien quelques mois de bidouillage.
📌 N'hésitez pas à commenter cet article en donnant vos REX sur le Vibe Coding.
MAJ 01/06/2026 : Je viens de tester Qwopus3.6-27B-V2-MTP-GGUF, c'est une petite révolution pour coder en local.