Aperçu en temps réel : comment VULK rend ton app en direct

Mis à jour le 18 juillet 2026 — réécrit autour de l'architecture actuelle : microVMs Firecracker, le service de build Flutter et les runtimes PHP + Python passés en live en juillet 2026.

Comment VULK rend-il ton app en direct ?

La réponse complète : pendant que l'IA streame les fichiers générés, VULK les pousse vers un service d'aperçu dédié qui exécute ton app dans une microVM Firecracker — une vraie machine virtuelle isolée avec son propre kernel, système de fichiers et réseau, tirée d'un pool chaud pour s'attacher en quelques secondes. Dans la microVM, un vrai serveur de dev Vite exécute ton app React avec hot module replacement ; l'app en marche est proxiée vers un iframe dans l'éditeur. Les apps Flutter passent par un pipeline build-then-serve séparé (flutter build web, ~20–60 secondes par build), et depuis juillet 2026 les apps PHP et Python tournent aussi en live dans leurs propres runtimes microVM.

Ce n'est ni une simulation ni une sandbox navigateur : c'est ton application réelle tournant sur une vraie infrastructure serveur, streamée vers ton écran. Cette vitesse rend possible le chiffre qui définit la plateforme — le builder médian passe de l'inscription à une app générée en marche en 47 secondes (données de la plateforme VULK, juillet 2026, N = 11 355 projets).

Pourquoi l'aperçu est-il le problème dur de la génération d'apps par IA ?

Quand un générateur IA produit du code, tu dois voir le résultat immédiatement. La plupart des plateformes prennent l'un de deux chemins : une capture statique, ou compiler le code dans le navigateur avec des outils comme WebContainers ou Sandpack. Les deux ont des limites significatives.

Les captures statiques sont évidemment insuffisantes — impossible d'interagir, de scroller, de cliquer des boutons ou de tester la fonctionnalité. La compilation en navigateur est meilleure mais apporte ses propres problèmes : gros téléchargements de la toolchain, support limité des APIs Node.js, pas d'exécution backend, compilations à froid lentes, forte consommation mémoire et restrictions de sandbox qui cassent de nombreux paquets npm.

VULK prend la troisième voie : l'aperçu côté serveur sur des microVMs isolées. Cela coûte plus cher à opérer — de la vraie infrastructure au lieu du navigateur de l'utilisateur — mais c'est la seule approche où « l'aperçu fonctionne » signifie de manière fiable « l'app fonctionne ».

Que se passe-t-il entre la génération et une app visible ?

Étape 1 : Génération du code. Le modèle IA streame sa réponse, produisant des fichiers enveloppés dans des balises XML vulkAction. Dès qu'un fichier est complet, VULK en extrait le chemin et le contenu.

Étape 2 : Attribution de microVM. Les fichiers partent vers le service d'aperçu (webapp.vulk.dev), qui attache ton projet à une microVM Firecracker issue d'un pool pré-démarré. Chaque microVM est une machine virtuelle authentique — isolation au niveau matériel, pas un conteneur partagé — avec une image rootfs adaptée aux besoins de ton projet (image web basique, image compatible 3D, ou image complète avec dépendances lourdes préinstallées).

Étape 3 : Dépendances et démarrage du serveur. Dans la VM, les dépendances s'installent contre des couches de node_modules pré-cachées — l'étape la plus lente d'un aperçu froid, réduite à quelques secondes pour les stacks courants. Pour les projets React + Vite, le serveur Vite démarre ; pour les autres stacks, le runtime approprié.

Étape 4 : Rendu en iframe. L'application en marche est proxiée via une URL unique et affichée dans un iframe dans l'éditeur VULK. Tu obtiens l'application complète et fonctionnelle — pas un rendu partiel.

Étape 5 : Hot reload sur les modifications. Quand un prompt de suivi modifie des fichiers, seuls les fichiers changés sont poussés dans la VM. Le hot module replacement de Vite met à jour l'iframe sans rechargement complet — tu vois tes changements en moins d'une seconde, généralement sans perdre l'état des composants.

Étape 6 : Suspension et reprise. Les aperçus inactifs sont suspendus pour libérer des ressources et repris à la demande — revenir à un projet ne signifie pas le reconstruire de zéro.

Comment chaque plateforme s'aperçoit-elle réellement ?

Les différents stacks passent par des pipelines réellement distincts — voici la carte par plateforme :

React Native + Expo utilise Expo Go pour les aperçus et les tests sur iOS et Android. Les thèmes et apps Shopify tournent dans l’environnement Shopify avec ses outils habituels.

Pourquoi le côté serveur bat-il la compilation navigateur ?

Le code backend tourne vraiment. Les apps full-stack générées par VULK incluent de vraies APIs et un accès base de données — et 62 % de toutes les apps générées incluent un schéma SQL (données de la plateforme VULK, juillet 2026). Les sandboxes navigateur ne peuvent pas exécuter ce backend ; elles le simulent ou le sautent. Dans l'aperçu VULK, tu testes le flux entier : inscription, connexion, création de données, appels API.

Aucune limite de sandbox. Les outils basés navigateur émulent Node.js dans un Service Worker ; certains paquets npm échouent en silence, les modules natifs ne fonctionnent pas, l'accès au système de fichiers est restreint. Une microVM est un vrai environnement Linux — aucune de ces limites n'existe.

Cohérent sur tous les appareils. Le build tourne sur le serveur — un Chromebook d'entrée de gamme et un MacBook Pro obtiennent la même performance d'aperçu, et les navigateurs mobiles, où la compilation en navigateur est pénible voire impossible, fonctionnent parfaitement.

Isolation au niveau matériel. Les microVMs Firecracker isolent à la couche de virtualisation — la même technologie qu'AWS Lambda. La boucle infinie d'un utilisateur ne peut pas toucher l'aperçu d'un autre, et une VM plantée est recyclée automatiquement.

Rendu fidèle. L'iframe charge depuis une vraie URL servie par un vrai serveur — ce que tu vois dans l'aperçu correspond à ce que les utilisateurs voient en production.

Que vois-tu pendant la génération ?

VULK ne te fait pas attendre la fin de toute la génération. L'aperçu se met à jour progressivement : dès que les fichiers de base (index.html, main.tsx, package.json) existent, le serveur démarre ; à mesure que les fichiers de composants arrivent, le file watcher déclenche des hot updates. Tu vois l'app se construire en temps réel — le layout d'abord, puis les composants, puis les styles.

Ce rendu progressif donne un retour précoce. Si l'IA part dans la mauvaise direction, tu le vois en quelques secondes et arrêtes la génération au lieu d'attendre. Et après la génération, le render gate de VULK charge ce même aperçu en marche dans une vraie instance Chromium et rejette les générations qui rendent une page blanche ou une error boundary — l'aperçu n'est pas que pour tes yeux, il fait partie de la vérification.

Que se passe-t-il entre l'aperçu et la production ?

L'aperçu n'est pas un build séparé de ton app — c'est le même code tournant dans un environnement de développement. Quand tu cliques sur Deploy, VULK prend ce même code, exécute un build de production (vite build) et publie la sortie sur ton-projet.vulk.space en 10–30 secondes. Ce que tu as testé est ce que tes utilisateurs reçoivent, plus la minification, le tree shaking et l'optimisation des assets.