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 ton 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. Tu ne choisis jamais dans un menu déroulant ; tu décris ce que tu veux 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 tu voulais 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. Tu ne choisis pas une plateforme dans un menu. Tu décris simplement ce que tu veux, et VULK détermine quel mode de génération activer.

Avant que ton 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, tu veux 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 tu veux outrepasser la détection, sois 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.

React + Vite et Three.js utilisent des aperçus web en direct. Flutter utilise un aperçu web compilé. PHP et Python tournent dans leurs environnements dédiés. 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.

Déploiement — React se publie sur ton-projet.vulk.space 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 montre ce que « 8 plateformes » veut dire en pratique : la génération est universelle, et les voies d'aperçu et de déploiement correspondent à ce que chaque écosystème attend.

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 tu construis un builder de code IA et que 80 % de tes 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 ta 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.