Huit étapes entre ton prompt et une app qui marche.
VULK n'est pas un seul appel LLM. C'est un pipeline déterministe qui classifie, planifie, route, génère, valide, répare, prévisualise et déploie — avec le bon modèle choisi pour chaque étape et une boucle d'autofixer quand une étape échoue.
- 01
Classificateur rapide
Classifier le prompt
Quelle surface l'utilisateur veut-il ? Web app, mobile (Flutter), thème Shopify, site marketing, outil interne ? Un classificateur petit et rapide choisit le bon pipeline avant que la génération commence — la mauvaise surface est le mode d'échec le plus cher.
- 02
Planner lourd (Claude Opus / Gemini Pro)
Planifier l'architecture
Un planner étend le prompt en liste de features, esquisse de schéma, plan des routes, décisions de modèle et critères d'acceptation. Le plan est ce que l'utilisateur voit d'abord en scrollant ; rien n'est généré avant que le plan soit verrouillé.
- 03
Router (déterministe)
Router les modèles par phase
Chaque étape suivante reçoit le modèle qui rend le mieux pour elle selon nos benchmarks internes : un modèle rapide écrit le scaffolding, un modèle lourd écrit la logique métier, un modèle spécialisé écrit la 3D / Flutter / Liquid. Nous changeons le routing quand un meilleur modèle apparaît.
- 04
Générateur (modèle par phase)
Générer le code
Chaque fichier est émis sous forme d'action XML structurée — VULK ne stream jamais juste du code libre. Le XML nous permet de tracer quels fichiers existent, valider avant écriture et éditer chirurgicalement plus tard sans régénérer tout le projet.
- 05
Validateur (règles + petit modèle)
Valider contre le build
Type-check, résolution des dépendances, build vite, sanity du schéma. L'analyse statique tourne de façon synchrone — nous ne te montrons pas un preview qui ne compile pas. Les échecs partent vers l'autofixer ; les succès vont droit en preview.
- 06
Réparateur (modèle lourd)
Autofix des échecs
Quand le validateur trouve une erreur, l'autofixer lit la sortie réelle de l'erreur et édite chirurgicalement les fichiers en échec. Il boucle jusqu'au vert ou jusqu'à un plafond strict — et rapporte honnêtement quand il ne peut pas corriger plutôt que de prétendre l'avoir fait.
- 07
Démarrer la preview en microVM
Une microVM Firecracker s'approvisionne en quelques secondes : kernel, rootfs, dépendances, le projet. La preview en direct est réelle, pas une iframe sandboxée — ton app générée tourne de la même façon qu'elle tournera en production.
- 08
Déployer là où elle vit
Un click envoie sur Cloudflare Pages, Vercel ou ta propre infra. Les builds mobiles (Flutter) sont remis à EAS / aux pipelines natifs avec la bonne metadata pour la soumission à l'App Store + Play.
Quel modèle tourne à quelle étape.
Le routing est déterministe et change quand les benchmarks changent. Les identifiants spécifiques de modèles changent chaque semaine — la politique ci-dessous est stable.
| Étape | Classe de modèle | Pourquoi |
|---|---|---|
| Classification | Petit / rapide | Pas cher, sous la seconde |
| Planification | Raisonnement lourd | One-shot, contexte le plus long |
| Génération (web) | Lourd, optimisé code | Règles de sortie les plus strictes |
| Génération (mobile) | Spécialisé Flutter | Justesse du widget-tree > brièveté |
| Génération (3D) | Spécialisé Three.js | Exige une géométrie / shaders corrects |
| Édition (chirurgicale) | Lourd, optimisé code | Fenêtre de diff plus petite, le fichier doit rester vivant |
| Réparation | Raisonnement lourd | Lit les erreurs de compilation en entrée |
| Résumé | Petit / rapide | Récap du plan, notes finales |
Ce qui se passe quand la génération échoue.
La plupart des app builders IA streament le code, le rendent et croisent les doigts. VULK suppose que la première génération échouera au moins une fois et traite la récupération comme une étape de premier ordre.
- Vérifications statiques d'abord. TypeScript, règles eslint bloquantes, résolution des dépendances. Moins cher que de lancer le build.
- Build du projet. Vite pour le web, Flutter analyzer pour le mobile, theme-check pour Liquid. Le vrai build, pas une simulation.
- Capture de l'erreur littérale. Le fixer lit la sortie réelle du compilateur, pas un résumé paraphrasé.
- Edit chirurgical. Le modèle de réparation émet une action vulkEdit ciblant uniquement les fichiers en échec — la régénération complète est l'exception, pas la règle.
- Boucle jusqu'au vert ou au cap. Maximum trois passes de réparation. Après ça nous surfacons l'échec honnêtement avec l'erreur et un bouton « regénérer depuis zéro ».
Tu veux le sentir ?
Le moyen le plus rapide de comprendre le pipeline est de le voir tourner. Démarre un essai payant de 7 jours — crédits complets du plan, annule quand tu veux.
Dernière révision : 30 avril 2026