DevOps
Comment j'ai vibe codé un linter Mistral : De l'idée au produit
✍️Enzo
📅13/12/2025
⏱️12 min
👁️...
#OpenStack#VSCode Extension#Linter#Claude#AI
Chargement du contenu de l'article...
Sources et références
Sources consultées le 15/01/2026
Tu connais cette sensation quand tu as une idée de side project, tu te dis "ça devrait être simple", et 3 semaines plus tard tu te retrouves avec une extension VSCode complète, un CLI, des tests, une CI/CD, et tu te demandes comment t'en es arrivé là ? 😅
Bienvenue dans l'univers du vibe coding : cette approche où tu codes par itérations successives, en suivant ton flow créatif, sans tout planifier à l'avance. Aujourd'hui, je vais te raconter comment j'ai transformé une frustration quotidienne avec les workflows Mistral en une extension VSCode de 2000+ lignes de TypeScript.
Spoiler : Claude Code a été mon copilote, et les bons prompts ont fait toute la différence ! 🚀
Dans ma boîte, on utilise OpenStack Mistral pour orchestrer nos workflows d'automatisation. Si tu ne connais pas Mistral, c'est un moteur de workflow qui utilise YAQL (un langage de query) et Jinja2 pour définir des tâches, des transitions, des boucles...
Un workflow Mistral typique :
version: '2.0'
my_workflow:
input:
- servers
- action
tasks:
validate_input:
action: std.noop
publish:
validated: <% $.servers.len() > 0 %>
on-success:
- deploy_servers: <% $.validated %>
- fail_workflow: <% not $.validated %>
Lorsque je travaillais avec OpenStack Mistral, j'ai constaté que les erreurs dans les expressions YAQL (Yet Another Query Language) étaient difficiles à détecter avant l'exécution. Les développeurs perdaient du temps à déboguer des erreurs de syntaxe qui auraient pu être détectées plus tôt.
# Scénario classique à 10h du matin
1. Tu écris un workflow de 200 lignes
2. Tu le déploies sur Mistral
3. Erreur : "Task 'deploy_servers' not found"
→ Typo dans le nom de la tâche 😤
4. Tu corriges, re-déploies
5. Erreur : "Unknown variable: deployed_id"
→ Manque un 's' à deployed_ids 😡
6. Tu corriges encore, re-déploies
7. Erreur : "Orphaned task: cleanup_on_error"
→ Task définie mais jamais appelée 🤬
8. 45 minutes perdues pourLes stats qui font mal :
❌ Éditeurs de texte classiques :
- Pas de validation YAQL
- Pas d'auto-complétion des task names
- Pas de détection d'erreurs sémantiques
❌ yamllint :
- Valide uniquement la syntaxe YAML
- Ignore complètement YAQL et la logique Mistral
❌ Extensions VSCode existantes :
- Aucune n'existe pour Mistral v2 + YAQL
- Les extensions YAML génériques sont trop basiquesC'était clair : il fallait créer notre propre outil ! 🛠️
Le vibe coding est une approche où vous décomposez un problème complexe en petites tâches réalisables, en utilisant un assistant IA pour accélérer le développement. La clé est de ne pas tout faire d'un seul coup, mais de progresser itérativement.
Problème initial : Les erreurs YAQL dans les workflows Mistral ne sont détectées qu'à l'exécution.
Objectif : Créer un linter VSCode qui valide les expressions YAQL en temps réel.
# Exemple de workflow Mistral avec YAQL
version: '2.0'
workflow_example:
tasks:
task1:
action: std.echo
input:
output: <% $.data.value %> # Expression YAQL à validerAvant de coder quoi que ce soit, j'ai exploré les différentes approches :
Option A : CLI standalone
Avantages :
✓ Simple à implémenter
✓ Intégrable en CI/CD
✓ Portable
Inconvénients :
✗ Pas de feedback temps réel
✗ Workflow interrompu (éditer → sauver → linter → corriger)
✗ Pas d'auto-complétionOption B : Extension VSCode
Avantages :
✓ Feedback temps réel
✓ Auto-complétion native
✓ Intégration IDE parfaite
✓ UX optimale
Inconvénients :
✗ Plus complexe à développer
✗ Nécessite de comprendre l'API VSCode
✗ Limité à VSCode (mais bon, qui utilise autre chose ? 😏)Option C : Language Server Protocol (LSP)
Avantages :
✓ Compatible tous éditeurs (VSCode, Vim, Emacs...)
✓ Architecture propre et réutilisable
✓ Scalable
Inconvénients :
✗ TRÈS complexe à implémenter
✗ Overkill pour un début
✗ Temps de dev multiplié par 3J'ai opté pour une stratégie progressive :
Phase 1 : Extension VSCode de base
→ + diagnostics temps réel
→ Auto-complétion basique
→ Temps de dev : ~1 semaine
Phase 2 : CLI extractable
→ Réutiliser le core de validation
→ Intégration CI/CD
→ Temps de dev : +2 jours
Phase 3 : Features avancées
→ Snippets intelligents
→ Signature help pour YAQL
→ Diagrammes de workflow
→ Temps de dev : itératif selon besoins💡 Pro tip : En vibe coding, tu ne planifies pas tout. Tu commences par le MVP et tu itères selon le flow créatif !
Au lieu de demander "Crée-moi un linter complet", j'ai décomposé le projet en étapes :
<% et %>)Voici le prompt initial que j'ai utilisé avec Claude Code :
Je veux créer une extension VSCode pour linter des workflows Mistral v2 (OpenStack).
Contexte :
- Workflows en YAML avec expressions YAQL (<% ... %>)
- Besoin de valider :
1. Syntaxe YAML
2. Sémantique Mistral (tasks, transitions, variables)
3. Expressions YAQL (variables, fonctions)
Objectifs :
- Diagnostics temps réel (erreurs soulignées)
- Auto-complétion des task names
- Structure TypeScript propre et extensible
Questions :
1. Quelle architecture TypeScript recommandes-tu ?
2. Comment parser le YAML et extraire les expressions YAQL ?
3. Comment intégrer avec l'API VSCode Diagnostic ?Réponse de Claude Code :
// Architecture proposée
src/
├── bin/
│ ├── cli.ts // Interface en ligne de commande pour utilisation CI/CD
├── core/
│ ├── completionsData.ts // Données d'auto-complétion (fonctions YAQL, actions std.*)
│ ├── diagramGenerator.ts // Génère des diagrammes DOT/Graphviz des workflows
│ ├── helpers.ts // Fonctions utilitaires partagées (parsing, validation)
│ ├── types.ts // Définitions TypeScript des structures Mistral
│ ├── validator.ts // Moteur de validation principal (syntaxe + sémantique)
│ └── yaqlParser.ts // Parser des expressions YAQL (<% ... %>)
└── extension/
│ ├── adapter.ts // Adaptateur entre core et API VSCode
│ ├──
Ce que j'ai appris : Claude Code excellait pour structurer l'architecture, mais il fallait découper en prompts spécifiques pour chaque composant.
Au lieu de demander tout d'un coup, j'ai procédé par petites itérations :
Prompt 1 : Parser YAML
Écris un parser YAML qui :
1. Charge un fichier workflow Mistral
2. Extrait les métadonnées (version, name, description)
3. Parse les tasks et leurs propriétés
4. Gère les erreurs de parsing proprement
Utilise js-yaml et retourne un objet typé TypeScript.Prompt 2 : Extraire YAQL
À partir du YAML parsé, je dois extraire toutes les expressions YAQL.
Format YAQL : <% expression %>
Contextes à détecter :
- Dans publish: <% $.variable %>
- Dans on-success/on-error: <% $.condition %>
- Dans action inputs: <% task().result %>
- Dans with-items: <% $.list.select($.item) %>
Retourne une liste de {expression, location, context}.Prompt 3 : Validation sémantique
Implémente les règles de validation Mistral suivantes :
1. Noms de tasks valides : [a-z0-9_]+ uniquement
2. Pas de tasks dupliquées
3. Les références dans requires/on-success/on-error existent
4. Les variables YAQL sont définies :
- inputs du workflow
- publish des tasks précédentes
- task() pour résultats
5. Détecte les tasks orphelines (jamais appelées)
Retourne une liste de diagnostics avec severity (error/warning).Une fois le core fonctionnel, j'ai ajouté features par features :
Prompt pour auto-complétion :
Je veux ajouter de l'auto-complétion contextuelle :
Contextes :
1. Après "requires:" → suggère les task names disponibles
2. Après "<% $." → suggère les variables disponibles
3. Dans "action:" → suggère les actions std.* et custom
Utilise l'API VSCode CompletionItemProvider.
Fournis des exemples avec CompletionItemKind appropriés.Prompt pour snippets :
Crée des snippets VSCode pour accélérer l'écriture :
1. mistral-workflow : squelette workflow complet
2. mistral-task : template task avec toutes les clés
3. with-items : loop avec YAQL
4. retry : politique de retry
5. join : stratégie de join (all/any)
Format VSCode snippet JSON avec placeholders ${1:name}.Prompt pour diagrammes :
Je veux générer un diagramme DOT (Graphviz) du workflow.
Éléments à représenter :
- Nodes : tasks (rectangles)
- Edges : transitions (on-success vert, on-error rouge)
- Clusters : groupes logiques si tags présents
- Entry point : task sans requires
Génère le code DOT et utilise l'API VSCode pour afficher.Pour que Claude Code soit encore plus efficace sur ce projet, j'ai créé un fichier de règles spécifiques :
.claude/rules.md - Règles du projet
# Mistral YAQL Linter - Règles de développement
## Architecture
- Séparer parsing, validation, et diagnostic
- Chaque validateur est indépendant et testable
- Utiliser des types TypeScript stricts partout
## Conventions de code
- Noms de fichiers : camelCase.ts
- Classes : PascalCase
- Fonctions/variables : camelCase
- Constantes : SCREAMING_SNAKE_CASE
## Patterns à suivre
1. **Validators** : retournent `Diagnostic[]`
2. **Parsers** : retournent des objets typés ou `null` en cas d'erreur
3. **Providers** : implémentent les interfaces VSCode
## Règles métier Mistral
- Task names : ^[a-z0-9_]+$
- YAQL expressions : entre <% et %>
- Variables disponibles : $.inputs, $.publish, task().result
- Fonctions YAQL : len, map, filter, select, where, etc.
## Tests
Voici un template de prompt que j'utilise systématiquement :
## Contexte
Je travaille sur le linter Mistral YAQL (TypeScript + VSCode).
## Problème actuel
[Description du problème ou feature manquante]
## Objectif
[Ce que je veux accomplir]
## Contraintes
- Doit s'intégrer dans l'architecture existante (src/validators/)
- Doit retourner des Diagnostic[] compatibles VSCode
- Doit être testable unitairement
## Exemple de cas d'usage
[Exemple YAML qui devrait trigger la règle]Voici les templates de prompts que j'utilise quotidiennement. Copy-paste friendly et prêts à adapter à ton contexte ! 📋
Feature : [NOM DE LA FEATURE]
Contexte :
- Projet : Mistral YAQL Linter (TypeScript VSCode extension)
- Architecture actuelle : [BRIEF DESCRIPTION]
Objectif :
[Description en 2-3 phrases de ce que tu veux accomplir]
Contraintes techniques :
- Doit utiliser [TECHNOLOGIE/PATTERN]
- Doit s'intégrer avec [COMPOSANT EXISTANT]
- Performance : [EXIGENCE SI PERTINENT]
Exemple d'usage :
[Exemple concret]
Livrables attendus :
1. Code TypeScript fonctionnel
2. Tests unitaires
3. Documentation inline
Question principale :
[Ta question spécifique]Bug Report
Symptôme :
[Ce qui ne fonctionne pas]
Comportement attendu :
[Ce qui devrait se passer]
Comportement actuel :
[Ce qui se passe réellement]
Code concerné :
[Extrait de code pertinent]
Contexte d'exécution :
- Fichier : [CHEMIN]
- Fonction : [NOM]
- Input : [DONNÉES]
Question :
Identifie la cause root et propose une fix.Refactoring Request
Code actuel :
[Ton code qui sent mauvais]
Problèmes identifiés :
1. [Code smell #1]
2. [Code smell #2]
Objectif du refactoring :
- Améliorer [ASPECT]
- Simplifier [PARTIE]
- Rendre testable [COMPOSANT]
Contraintes :
- Ne pas casser les tests existants
- Garder la même API publique
- [Autre contrainte]
Question :
Propose une version refactorisée avec explications."Crée-moi une extension VSCode complète pour valider YAQL
avec tous les features possibles"Problème : Trop vague, trop complexe, résultat incertain.
1. "Aide-moi à parser un fichier YAML avec js-yaml"
2. "Comment extraire les expressions entre <% et %> ?"
3. "Quelle regex pour valider les variables YAQL ?"
4. "Comment créer un diagnostic VSCode ?"Avantage : Progression claire, résultats testables, compréhension profonde.
Au final, vibe coder ce linter Mistral, c'est un peu comme faire du jazz : tu as une mélodie de base (le concept), puis tu improvises et tu affines au fur et à mesure. Claude Code, c'est ton saxophoniste qui te suit et enrichit ta composition.
Les principes clés du vibe coding :
Le projet aujourd'hui :
Alors, prêt à vibe coder ton prochain side project ? Lance-toi, commence petit, et laisse le flow créatif te guider ! 🎨
🔥 Challenge bonus : Prends un problème qui te frustre au quotidien. Passe 2h à vibe coder un MVP avec Claude Code. Partage ton résultat, je parie que tu seras surpris de ce que tu peux accomplir !
Merci de me suivre dans cette aventure ! 🚀
Cet article a été écrit avec ❤️ pour la communauté DevOps.
PS : Le repo est dispo sur GitHub. Si tu bosses avec Mistral, teste l'extension et n'hésite pas à contribuer. Et si tu vibe codes un truc cool, ping-moi, j'adore voir ce que les autres créent en mode flow ! 🚀