Les techniques avancées de Valérian
Session live où Valérian Lebert, développeur freelance spécialisé en digitalisation et géomatique, partage son parcours d'outils de vibe coding puis tente de construire from scratch une application Tauri (Voice-to-Text) avec Vue.js et Rust, en utilisant successivement l'agent Zed avec Grok, puis Claude Code avec Haiku 4.5, pour aboutir à un prototype fonctionnel d'enregistrement audio et transcription via l'API Mistral Voxstral.
Stack technique
Outils utilisés
Résumé de la session
La session commence par une présentation approfondie du parcours de Valérian. Il se décrit comme ingénieur télécom devenu freelance en digitalisation, avec une double activité : du no-code (Airtable, N8N) pour la digitalisation de processus, et du développement Python/SQL plus poussé dans le domaine de la géomatique et de la fibre optique. Il utilise l'IA à deux niveaux distincts : comme assistant pour un dev expérimenté qui sait où il va, et comme outil permettant de faire des choses qui auraient été inaccessibles il y a deux ans, comme des interfaces web en Vue.js sur des backends N8N/Airtable.
Valérian retrace ensuite son parcours d'outils de vibe coding. Il a commencé par Continue.dev sur VS Code, une extension qui permettait d'utiliser les modèles de son choix en API, y compris des modèles locaux légers pour le code completion. Il explique que le code completion lui paraît désormais désuet face à la puissance du vibe coding actuel. Il mentionne ensuite AIDER en ligne de commande, dont il apprécie les principes sains de gestion du contexte.
Valérian détaille ensuite son utilisation de Cline, qu'il considère comme le premier outil à avoir eu une approche « bourrin mais efficace » avec un prompt système de 15 000 tokens qui guide l'IA étape par étape. Il a fait du reverse engineering sur ces prompts pour comprendre leur fonctionnement et les reproduire ailleurs. Le mode plan/act de Cline reste selon lui une référence, même si l'outil est volontairement simple (« la vieille voiture qui tourne tout le temps »). Il mentionne les forks RooCode et KiloCode, ce dernier étant jugé parfois over-engineered, notamment avec son navigateur headless qui prend des screenshots et consomme beaucoup de tokens.
Alexis et Valérian échangent ensuite sur Mistral. Valérian clarifie la distinction entre CodeStral (modèle léger avec capacité Fill-in-the-Middle pour le code completion), DevStral (entraîné pour l'agentique) et Mistral Medium (le meilleur modèle actuel selon lui, toutes tâches confondues). Il explique que la rapidité de Mistral en chat vient de l'utilisation de puces Cerebras pour l'inférence, mais pas pour l'API. Il mentionne aussi l'investissement d'ASML dans Mistral et spécule sur un possible développement hardware.
Valérian présente ensuite Zed en détail. L'éditeur, développé en Rust par les anciens d'Atom, offre des standards plus modernes que VS Code, notamment pour le développement Python. Il décrit l'évolution de Zed : d'abord un panneau de chat simple (le « text trade ») où l'utilisateur maîtrisait totalement le contexte et pouvait éditer la conversation, puis l'ajout d'un agent avec des outils (lecture de fichiers, diagnostics). Valérian a reconstruit dans Zed un prompt système de 1300 tokens reproduisant le mode plan/act de Cline, ce qui lui permet d'avoir deux modes de fonctionnement même si l'outil n'est pas conçu pour ça. Il apprécie aussi la possibilité récente d'utiliser Claude Code, Gemini CLI et Codex directement depuis Zed.
Le projet pratique démarre. Valérian veut construire une application Tauri, un framework qui utilise le WebView natif de l'OS (au lieu d'embarquer Chrome comme Electron) avec un backend Rust. L'objectif est de reproduire partiellement son outil Python SuperVoxTral de voice-to-text. Il initialise un projet Tauri avec un frontend Vue.js via la commande CLI standard.
Premier essai avec Claude Code dans Zed : Valérian lance directement en « mode YOLO » sans phase de planification. Claude Code se bat avec la compilation, exécute des commandes sleep étranges, mais finit par produire une fenêtre Tauri avec un bouton. Le bouton ne ferme cependant pas la fenêtre. Après correction (ajout de permissions Tauri), le Hello World fonctionne.
Valérian bascule ensuite sur l'agent natif de Zed avec Grok (via OpenRouter) pour ajouter l'enregistrement audio. Le plan est produit, l'implémentation se fait, mais l'interface n'a pas de boutons visibles au premier run. Après un cycle plan/act supplémentaire, l'enregistrement fonctionne et produit un fichier WAV dans les documents. Le coût total avec Grok : 4 centimes.
Pour comparer, Alexis propose de refaire la même chose avec Claude Code. Valérian crée une branche, repart du projet vierge et utilise cette fois Claude Haiku 4.5 (sorti la veille). Le plan est plus lisible, la checklist mieux présentée. Au premier run, les boutons sont présents (contrairement à Grok), mais le fichier audio ne s'enregistre pas. Après un cycle de debug en mode plan, Claude identifie des problèmes de format et d'import, corrige, et l'enregistrement fonctionne en .webm.
Valérian ajoute ensuite la transcription via l'API Mistral Voxstral. Il fournit un extrait de documentation à Claude. L'intégration passe par plusieurs erreurs : d'abord l'application se ferme au lieu d'afficher les erreurs, puis une erreur 400 liée à un mauvais nom de modèle dans l'appel API, puis un problème de format du corps de requête. Après trois tentatives et corrections manuelles du nom de modèle, la transcription fonctionne. À 11h02, le prototype est opérationnel : enregistrement audio + transcription via Voxstral dans une application Tauri.
Ce qu'on a appris
- Le code completion (complétion de ligne) est devenu quasi obsolète face à la puissance du vibe coding conversationnel. La qualité des sorties actuelles fait que même pour corriger deux lignes, on passe par le chat plutôt que de réfléchir soi-même, ce qui pose des questions de dépendance et de consommation de tokens.
- Le prompt engineering interne des outils est un différenciateur majeur, souvent invisible. Le prompt système de 15 000 tokens de Cline, qui force le modèle à planifier avant d'agir et à ne faire qu'un seul appel outil à la fois, permet d'obtenir des résultats qualitatifs même avec des modèles moins performants. Ce n'est pas que le modèle, c'est le combo outil + modèle qui fait la performance.
- La gestion des diffs (modifications partielles de fichiers) reste un problème technique central dans tous ces outils. Les stratégies varient (interprétation de commentaires "Previous code", réécriture complète par un modèle léger en fallback) et aucune n'est parfaitement fiable, surtout avec Haiku qui a montré plusieurs erreurs d'édition durant la session.
- La maîtrise du contexte est une compétence clé du vibe coder. Valérian préfère les outils où il voit exactement ce qui est dans le contexte, pouvoir éditer la conversation, supprimer des morceaux qui polluent, plutôt que des boîtes noires où on ne sait pas si un fichier modifié entre-temps a été relu. Cette discipline mentale de « gestion du contexte » est ce qui sépare un usage efficace d'un usage qui dérive.
- Le mode plan avant action reste une pratique essentielle, même quand les modèles savent raisonner par étapes. Valérian l'a intégré dans un prompt système de 1300 tokens pour Zed, et les moments où il est parti en « mode YOLO » sans planification ont systématiquement produit plus de problèmes (commandes sleep aberrantes, boutons manquants).
- Quand on travaille sur des technologies qu'on ne maîtrise pas (ici Rust + Tauri), la confiance aveugle dans l'agent devient risquée. Sans comprendre ce que fait le code, on ne peut pas diagnostiquer les erreurs, et on entre dans des boucles de debug où l'agent tourne en rond. C'est la limite fondamentale du vibe coding pur : il faut au minimum pouvoir lire et évaluer ce qui est produit.
- Les modèles économiques (Grok à 4 centimes pour toute la session, Haiku 4.5 censé être au niveau Sonnet 4) changent l'équation du vibe coding. On peut itérer beaucoup plus librement avec des modèles peu chers, réserver les modèles premium pour les phases critiques, et utiliser des modèles légers pour les tâches simples (Mistral Medium pour les commandes terminal).
- La comparaison Grok vs Haiku 4.5 montre des profils différents : Grok a produit un résultat fonctionnel mais sans boutons d'interface (oubli), avec moins de logging et de debug. Haiku a produit une interface correcte du premier coup avec les boutons, un meilleur plan visible, mais plus d'erreurs d'édition de fichiers et une moindre fiabilité sur le respect des consignes (mode plan pas toujours respecté).
- L'intégration de Claude Code dans Zed crée un workflow hybride intéressant : utiliser l'interface graphique de Zed pour le confort, basculer en terminal pour plus de contrôle, et retrouver l'historique des conversations entre les deux modes. Mais cette intégration est encore instable (régressions sur les slash commands, affichage incohérent du modèle utilisé).
- Les appels API externes (ici Mistral Voxstral) restent un point de friction récurrent. Le modèle a mis un mauvais nom de modèle, un mauvais format de corps de requête, et n'a pas anticipé la compatibilité de format audio (WebM vs WAV). Fournir un extrait de documentation aide, mais ne suffit pas toujours.
- L'approche multi-outils avec OpenRouter comme couche d'abstraction a des limites concrètes : variabilité de qualité entre providers pour un même modèle, gestion du caching inégale, suspicions de modèles de qualité moindre chez certains fournisseurs. Valérian recommande de forcer le provider original (Z&A pour GLM par exemple).
- Le commit régulier est indispensable dans un workflow de vibe coding. Le moment où Valérian n'a pas fait de commit avant de lancer l'intégration de la transcription est exactement celui où Haiku a « pourri le code » avec des erreurs d'échappement de caractères, sans point de retour propre.
- Les outils simples et peu opinionés (Cline, l'agent Zed) permettent paradoxalement plus de contrôle que les outils sophistiqués (KiloCode avec son navigateur headless, ses diagrammes Mermaid automatiques) qui consomment des tokens sur des fonctionnalités non demandées. La tendance à l'over-engineering des outils de vibe coding est un vrai problème d'expérience utilisateur.
- Le déploiement et le packaging restent le parent pauvre du vibe coding. Tout le monde se concentre sur la génération de code, mais les problèmes de Docker, de Cloudron, de compilation Rust, d'installation de dépendances système sont des murs que les agents ne franchissent pas facilement, et c'est souvent là que les projets bloquent en production.
- La vitesse perçue du modèle influence directement le confort d'utilisation. Valérian mentionne que Mistral Medium en chat est agréable grâce aux puces Cerebras, que Haiku 4.5 donne une sensation de rapidité par rapport à Sonnet, et que GPT-5/Codex paraît plus lent parce qu'il cache le thinking. Ce n'est pas qu'une question de performance brute, c'est aussi une question d'expérience développeur.