Comment VULK gère 8 plateformes depuis une conversation

Mis à jour le 18 juillet 2026 — statuts d'aperçu corrigés vers la réalité multi-runtime actuelle (microVMs PHP + Python live depuis juillet 2026) et données de la plateforme rafraîchies.

Comment VULK génère-t-il pour 8 plateformes depuis une conversation ?

La réponse complète : avant que votre prompt n'atteigne un modèle IA, le système de détection de VULK le scanne à la recherche de signaux spécifiques à chaque plateforme — en pondérant le contexte, les termes co-occurrents et les patterns d'intention, pas seulement des mots-clés — et le route vers l'un des huit pipelines de génération dédiés : React + Vite, Flutter, React Native + Expo, thèmes Liquid Shopify, apps Shopify (Remix + App Bridge), Shopify Hydrogen, PHP/Laravel et jeux Three.js. Chaque pipeline a son propre system prompt, sa logique de structure de fichiers, sa stratégie d'aperçu et sa voie de déploiement. Vous ne choisissez jamais dans un menu déroulant ; vous décrivez ce que vous voulez et le bon mode s'active.

La demande est mesurablement multi-plateforme : sur 11 355 projets générés, la demande cumulée de prompts inclut 381 requêtes pour Flutter, 310 pour les backends Node, 246 pour Python, 213 pour React Native/Expo et 174 pour PHP — à côté de la majorité React (données de la plateforme VULK, juillet 2026). Le monde du développement est bien plus vaste que React, et VULK a été construit pour tout ce monde.

Pourquoi personne d'autre n'a voulu résoudre cela ?

Quand j'ai commencé à construire VULK, chaque builder de code IA du marché générait la même chose : une app React avec Tailwind CSS. Bolt, v0, Lovable, Replit — tous. Si vous vouliez une app mobile, un thème Shopify, un backend Laravel ou un jeu navigateur, pas de chance. Toute la catégorie avait décidé que « l'IA construit des apps » signifiait « l'IA construit des apps React ».

Cela n'a jamais eu de sens pour moi. Il y a 1,7 million de marchands Shopify qui ont besoin de thèmes personnalisés. Flutter compte plus d'un million de développeurs actifs construisant des apps mobiles natives. PHP propulse toujours l'essentiel du côté serveur du web. Three.js est le standard de la 3D en navigateur. Ce sont des communautés massives, et elles étaient complètement ignorées.

Alors j'ai construit VULK pour les gérer toutes. Une conversation, 8 plateformes :

1. React + Vite — Web apps avec Tailwind CSS
2. Flutter — Apps mobiles natives avec Clean Architecture
3. React Native + Expo — Mobile cross-platform avec NativeWind
4. Thèmes Liquid Shopify — Online Store 2.0
5. Apps Shopify — Remix + App Bridge + Polaris
6. Shopify Hydrogen — Storefronts de commerce headless
7. PHP / Laravel — Applications côté serveur
8. Three.js — Jeux navigateur avec moteurs physiques

Comment la détection fonctionne-t-elle réellement sous le capot ?

Voici la partie qui intrigue le plus. Vous ne choisissez pas une plateforme dans un menu. Vous décrivez simplement ce que vous voulez, et VULK détermine quel mode de génération activer.

Avant que votre prompt n'atteigne le modèle IA, notre système de détection le scanne pour des signaux spécifiques aux plateformes. Ce ne sont pas de naïves correspondances de mots-clés — le système pondère le contexte, les termes co-occurrents et les patterns d'intention. Par exemple, « construis une app avec des écrans et une barre de navigation en bas » signale du mobile, pas du web. « Construis une boutique avec des variantes de produits et des collections » signale Shopify, pas de l'e-commerce générique.

La détection suit un ordre de priorité strict, et il y a une raison : Shopify App > Shopify Hydrogen > Shopify Liquid > Flutter > React Native > Three.js > PHP/Laravel > React (défaut).

Pourquoi cet ordre ? Parce que la spécificité doit gagner. Si quelqu'un mentionne « app Shopify », c'est une intention très précise — il veut une app marchande basée sur Remix avec App Bridge et Polaris, pas une web app générique qui s'intègre à Shopify. Plus la plateforme est spécialisée, plus sa priorité est haute. React est en bas parce que c'est le fourre-tout. Si rien d'autre ne correspond, vous voulez probablement une web app, et React + Vite est le meilleur défaut pour cela.

Voici ce qui déclenche chaque mode :

• Flutter — « app mobile », « Flutter », « iOS et Android », « app native », « APK », « écrans » (pas « pages »)
• React Native — « React Native », « Expo », « mobile cross-platform »
• Shopify Liquid — « thème Shopify », « boutique en ligne », « boutique Shopify »
• Apps Shopify — « app Shopify », « app pour marchands », « plugin Shopify »
• Shopify Hydrogen — « Hydrogen », « Shopify headless », « Storefront API »
• PHP/Laravel — « PHP », « Laravel », « WordPress », « côté serveur »
• Three.js — « jeu », « 3D », « Three.js », « jeu navigateur »
• React — Tout le reste

Si vous voulez outrepasser la détection, soyez explicite. « Construis ça en Flutter » ou « Utilise React pour ça » gagne toujours.

Qu'est-ce qui rend chaque mode réellement différent ?

Ce n'est pas juste échanger un template contre un autre. Chaque plateforme a son propre pipeline de génération avec quatre couches distinctes, et réussir chacune a demandé des mois d'ingénierie.

Ingénierie de prompts — Chaque plateforme a son propre system prompt qui enseigne au modèle IA les conventions, patterns et bonnes pratiques de ce stack. Le prompt Shopify seul dépasse 2 100 lignes. Il couvre la syntaxe Liquid, les schémas de sections, la compatibilité Dawn, les patterns de metafields et les dizaines de subtilités qui séparent un thème fonctionnel d'un thème qui casse dans l'éditeur de thèmes Shopify. Le prompt Flutter impose la Clean Architecture. Le prompt Three.js gère les boucles de jeu, la détection de collisions et l'intégration physique. On ne peut pas juste dire à un modèle « écris du code Shopify » et espérer un bon résultat. Il faut une ingénierie de prompts profonde et propre à chaque plateforme.

Structure de fichiers — React génère src/components/ et src/pages/. Flutter génère lib/models/, lib/screens/ et lib/services/. Shopify génère sections/, templates/ et assets/. Laravel génère app/Http/Controllers/, resources/views/ et database/migrations/. Chaque framework a des attentes sur où vit le code, et les violer rend le résultat inutilisable pour des développeurs expérimentés.

Stratégie d'aperçu — C'est là que l'ingénierie devient réellement dure, et là où j'insiste sur l'honnêteté quant à ce qui tourne en live et ce qui ne tourne pas. React + Vite (et Three.js) tournent dans des microVMs Firecracker — des machines virtuelles isolées avec hot-reload, lancées depuis un pool chaud. Flutter utilise un pipeline build-then-serve : le projet est compilé avec flutter build web sur un service de build dédié et servi en ~20–60 secondes par build. Depuis juillet 2026, PHP et Python tournent aussi comme runtimes microVM live — php-fpm 8.3 + nginx pour les apps type Laravel/WordPress, et serveurs uvicorn/Flask/Django/Streamlit auto-détectés pour Python. React Native et les trois modes Shopify n'ont pas d'aperçu live — RN est bundlé par Metro (un aperçu dans l'éditeur est en développement), et le code Shopify exige le runtime propre de Shopify : l'éditeur affiche des instructions de configuration honnêtes plutôt qu'un rendu factice.

Déploiement — React se déploie sur Cloudflare Pages en un clic. Flutter exporte de vrais fichiers APK/AAB avec échafaudage de soumission aux stores. Les thèmes Shopify se poussent via la Shopify CLI. Les projets Laravel et Python s'exportent comme des répertoires complets prêts pour n'importe quel hébergeur.

Où en est chaque plateforme aujourd'hui ?

Ce tableau est la version honnête de « 8 plateformes ». La génération est universelle ; l'aperçu live couvre les stacks exécutables sur le web ; les voies de déploiement correspondent à ce que chaque écosystème exige réellement.

Comment VULK se compare-t-il aux autres builders IA ?

Je vais être direct sur le paysage concurrentiel, parce que je crois que les développeurs méritent la transparence :

Ce n'est pas incrémental. C'est catégorique. L'écart existe parce que la génération multi-plateforme est réellement difficile à construire. Chaque nouvelle plateforme multiplie le travail d'ingénierie : nouvelle ingénierie de prompts, nouvelle logique de structure de fichiers, nouvelle infrastructure d'aperçu, nouveau pipeline de déploiement, nouvelle surface de test. Et chaque plateforme doit produire un résultat qu'un développeur expérimenté de cet écosystème jugerait acceptable. Un développeur Flutter repère immédiatement un projet Dart mal structuré. Un développeur Shopify saura si les templates Liquid ne suivent pas les patterns Online Store 2.0.

Pourquoi personne d'autre ne fait cela ?

J'y ai beaucoup réfléchi, et je crois que la réponse est simple : l'économie ne semble pas attrayante à première vue.

Si vous construisez un builder de code IA et que 80 % de vos utilisateurs veulent des apps React, la décision business évidente est de rendre la génération React excellente et d'ignorer le reste. Ajouter Flutter, ce sont des mois d'ingénierie pour une minorité de votre base d'utilisateurs. Le ROI par plateforme décroît.

Mais cette analyse rate l'essentiel : ces communautés plus petites n'ont presque aucune alternative. Un développeur React peut choisir entre cinq ou six builders IA. Un développeur Shopify qui veut générer un thème personnalisé avec l'IA a une option. Un développeur Flutter qui veut aller du prompt à l'APK a une option. Le fossé concurrentiel dans ces catégories est énorme précisément parce que personne d'autre ne veut investir pour le construire. Et le tableau de demande ci-dessus — 381 prompts Flutter, 246 Python, 213 RN, 174 PHP et ça monte — montre que ces « niches » s'additionnent en une part substantielle de ce que les builders demandent réellement.