Aperçu en temps réel : comment VULK rend votre 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 votre 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 votre 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 votre 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 votre application réelle tournant sur une vraie infrastructure serveur, streamée vers votre é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, vous devez 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 votre 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 votre 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. Vous obtenez 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 — vous voyez vos 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 honnête par plateforme :

Ces deux dernières lignes comptent. React Native bundlé par Metro ne peut pas tourner honnêtement dans un aperçu web, et le code Shopify a besoin du runtime admin et storefront de Shopify. Plutôt que de simuler ces rendus, l'éditeur vous dit exactement comment les exécuter là où ils tournent vraiment. Un aperçu auquel on ne peut pas se fier est pire que pas d'aperçu.

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, vous testez 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 vous voyez dans l'aperçu correspond à ce que les utilisateurs voient en production.

Que voyez-vous pendant la génération ?

VULK ne vous 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. Vous voyez 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, vous le voyez en quelques secondes et arrêtez 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 vos yeux, il fait partie de la vérification.

Quelles sont les limites de l'aperçu ?

Démarrages à froid. Les dépendances non cachées peuvent prendre 10–30 secondes d'installation à la première génération. Les exécutions suivantes dans le même projet réutilisent les caches et sont bien plus rapides.

Flutter a une latence de build. ~20–60 secondes par build (un vrai flutter build web), et pas de hot-reload entre les builds — un rendu fidèle au prix de la vitesse d'itération.

Pas de rendu mobile natif. Flutter s'aperçoit en Flutter Web — fonctionnellement fidèle, visuellement proche, mais le test final d'appareil appartient à un appareil. React Native n'a pas encore d'aperçu dans l'éditeur.

Limites de ressources. Chaque microVM a des plafonds CPU et mémoire pour un partage équitable ; les charges extrêmement lourdes (gros datasets, simulations complexes) peuvent les atteindre.

Isolation réseau. Les environnements d'aperçu ne peuvent pas appeler des services externes arbitraires, pour des raisons de sécurité. Les appels d'API tierces échouent dans l'aperçu et fonctionnent après le déploiement.

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

L'aperçu n'est pas un build séparé de votre app — c'est le même code tournant dans un environnement de développement. Quand vous cliquez sur Deploy, VULK prend ce même code, exécute un build de production (vite build) et livre la sortie sur Cloudflare Pages en 10–30 secondes. Ce que vous avez testé est ce que vos utilisateurs reçoivent, plus la minification, le tree shaking et l'optimisation des assets.