Builders d'Apps IA

Ce que contient ce pack

Ces sept couvrent tout le spectre de "tape une phrase, obtiens une SaaS" à "donne aux designers un contrôle visuel sur ma vraie codebase React". Ils ne sont pas interchangeables — chacun parie sur quelque chose de différent : qui fait le travail et quoi est généré.

Pourquoi c'est important

La catégorie "IA construit votre app" est passée du gimmick au workflow réel en 2025. Trois raisons :

1. WebContainers : le runtime Node en navigateur de StackBlitz fait qu'un npm install complet + dev server démarre en 5 secondes dans un onglet. Plus d'"attendez qu'on provisionne un sandbox".
2. Capacité de code des modèles frontier : Claude Sonnet 3.7 et GPT-5 écrivent enfin du React qui compile et fonctionne au premier essai, pas "presque marche après 3 corrections".
3. Édition en direct sur codebases réelles : Onlook est la percée — les designers glissent des éléments dans le navigateur et émettent des diffs propres contre votre repo existant. Plus de "redesigner dans Figma → ingénieur réimplémente".

Résultat : construire une app CRUD depuis un prompt prend maintenant 15 minutes y compris auth, déploiement et une vraie base. Le goulot s'est déplacé du code vers la réflexion produit.

Installer en une commande

# Installe tout le pack
tokrepo install pack/ai-app-builders

# Ou choisissez celui qui correspond à votre situation
tokrepo install bolt-diy
tokrepo install webstudio
tokrepo install onlook

La page TokRepo de chaque ressource liste les options hosted vs self-host, le coût typique en tokens par génération, et les cibles de déploiement supportées (Netlify, Vercel, Cloudflare Pages, Docker).

Pièges courants

• WebContainer != Node : bolt.diy et Bolt.new font tourner les apps dans WebContainer, un runtime WASM compatible Node. Certains paquets npm avec bindings natifs ne marchent pas. Vérifiez votre stack avant d'engager un projet.
• Drift de code généré : le React généré par IA utilise souvent des patterns légèrement hors-spec (hooks mal memoizés, bugs accidentels client/serveur). Traitez la génération comme un point de départ, pas un produit fini.
• Outils internes vs apps : Budibase et ToolJet sont des builders d'outils internes — ils supposent un utilisateur employé authentifié. Ne les lancez pas comme SaaS client sans repenser auth, branding et cas limites.
• Onlook a besoin d'un vrai repo : il édite votre React, pas un sandbox. Le brancher exige de lancer un process agent local. Traitez-le comme un outil designer-installe-une-fois, pas un spin-up par tâche.
• Dépense en tokens sur Bolt.new : les générations d'app complète peuvent brûler 100k+ tokens par tour. Le tier hosted plafonne l'usage ; self-hoster bolt.diy avec votre propre clé Anthropic évite le plafond mais vous facture direct.

Quand ce pack seul ne suffit pas

Ce pack génère le frontend. Pour faire tourner un vrai produit il faut aussi :

• Un backend ou CMS : voir CMS Headless pour IA — Strapi, Directus, Hasura — la couche données structurées vers laquelle pointer votre app générée.
• Une base de données : les démos WebContainer de bolt.diy utilisent SQLite ou en mémoire ; la prod a besoin de Postgres / Supabase / Neon.
• Auth : Bolt.new branche Auth0 ou Supabase Auth ; si self-host, planifiez-le explicitement.
• Pipeline de déploiement : choisissez Netlify ou Cloudflare Pages et tenez-vous-y.

Pour sites docs, pages marketing ou blogs produit, vous n'avez pas besoin de ce pack — voir Générateurs Sites Statiques & Docs. Les app builders résolvent une forme différente de problème.

Idées reçues courantes

"Je génère une SaaS ce week-end". Peut-être — mais le code généré c'est ~70% du travail. Flux d'auth, intégration paiement, multi-tenancy, états d'erreur, cas limites mobile responsive, consent RGPD, accessibilité et observabilité sont des choses que les builders sautent ou font mal. Ces 30% restants sont là où les produits vivent ou meurent.