Rork fonctionne. L’IA génère du code React Native ou Swift natif à partir de prompts texte, et des apps arrivent effectivement sur l’App Store. Le problème, c’est que la quasi-totalité des avis disponibles datent de mi-2025, comparent encore Rork à Bubble (qui ne fait même pas du mobile natif), et ignorent des évolutions majeures comme Rork Max, le Toolkit IA intégré ou le backend Hono en beta. Résultat : des reviews qui décrivent un outil qui n’existe plus tout à fait sous cette forme. Cet article corrige le tir. Pas pour vendre Rork, mais pour poser les vrais arbitrages. Parce que selon ton profil, ton budget réel et ta capacité à gérer un déploiement App Store, Rork sera soit un accélérateur redoutable, soit une perte de crédits et de temps.

Rork en 30 secondes, et pourquoi la plupart des avis passent à côté

Les reviews anglophones décrivent toutes le même Rork : un chat où tu décris ton app, l’IA génère du React Native, tu scannes un QR code. Ce résumé est correct mais incomplet, et cette incomplétude fausse la plupart des verdicts publiés.

Ce que Rork fait réellement (et ce qu’il ne fait pas, malgré le marketing)

Rork génère des applications mobiles natives à partir de prompts en langage naturel. Le mot clé est natif : le code produit est du React Native compilé via Expo, pas un site web emballé dans une coquille mobile. Les apps tournent sur iOS et Android avec des composants d’interface réels du système. Tu peux tester en temps réel sur ton téléphone via l’app Expo Go en scannant un QR code depuis l’éditeur.

Ce que Rork ne fait pas : te publier une app en un clic. Le marketing laisse croire que le process est entièrement automatisé, de l’idée au store. La réalité, c’est que Rork gère la génération du code et le build. La publication exige un Apple Developer Account (99$/an), la configuration des certificats, la soumission manuelle et le passage en review chez Apple ou Google. Un non-technique peut y arriver, mais il va transpirer.

Autre point que personne ne mentionne : Rork n’a pas d’éditeur visuel. Tu ne déplaces pas des composants à la souris. Tout passe par le prompt. Si l’IA interprète mal ton instruction, ta seule option est de reformuler. Pas de drag-and-drop de secours. C’est un choix de design assumé qui rend l’outil rapide pour les profils qui pensent en mots, et frustrant pour ceux qui pensent en pixels.

Rork Pro vs Rork Max : le choix que personne n’explique

Aucune review anglophone ne mentionne Rork Max. C’est pourtant la différence la plus structurante de la plateforme.

Rork Pro utilise React Native et Expo. Il produit des apps cross-platform iOS et Android depuis un seul codebase. Le test se fait via Expo Go sur téléphone. C’est le mode par défaut, celui que toutes les reviews décrivent.

Rork Max génère du code Swift natif, exclusivement pour iOS. Il nécessite un Mac sous macOS 26, l’app Rork Companion installée, et un iPhone branché en USB avec le mode développeur activé. En échange de ces contraintes, tu accèdes à tout ce que React Native ne peut pas toucher : widgets home screen et lock screen, Live Activities, Dynamic Island, body tracking avancé pour les apps fitness, réalité augmentée, Apple Watch avec suivi cardiaque, CarPlay, Siri, audio basse latence, et caméra LiDAR.

L’arbitrage est simple. Si ton app est un dashboard, un outil de contenu, un tracker ou une marketplace, Rork Pro suffit et couvre les deux plateformes. Si ton app repose sur des fonctionnalités profondément liées au hardware Apple (fitness avec capteurs, AR, widgets système), Rork Max est le seul choix. Le fait que cette distinction soit absente de tous les avis existants montre à quel point ils se copient les uns les autres sans consulter la documentation officielle.

Le vrai coût d’une app publiée avec Rork (pas juste l’abonnement)

Tous les avis affichent le même tableau de pricing Rork. Aucun ne calcule le coût total réel d’une app qui arrive sur l’App Store avec un système de paiement fonctionnel.

Pricing Rork : crédits, plans et ce que les tableaux comparatifs ne montrent pas

Rork fonctionne sur un système de crédits. Chaque interaction avec l’IA consomme un crédit. Les crédits se réinitialisent le 1er du mois sans report.

Le plan gratuit donne 35 crédits par mois avec un plafond de 5 par jour. Le plan Junior coûte 25$/mois pour 100 crédits. Le Middle monte à 50$/mois pour 250 crédits. Le Senior à 100$/mois pour 500. Les plans Scale vont de 200$/mois (1 000 crédits) jusqu’à 1 800$/mois (10 000 crédits).

Ce que les tableaux comparatifs ne disent jamais : le coût effectif par crédit est constant à 0,20$ sur la majorité des plans. Il n’y a pas de dégressivité significative avant le Scale 5K. Autrement dit, acheter le plan Middle plutôt que deux fois le Junior ne te fait économiser strictement rien par crédit. La seule raison de monter en plan, c’est d’éviter la frustration de tomber à sec en milieu de mois.

L’autre angle mort : la qualité de ton premier prompt détermine directement combien de crédits tu vas brûler. Un prompt vague génère un résultat médiocre qui nécessite 5 à 10 itérations de correction. Un prompt structuré (expérience cible, mood, contraintes, flow principal) peut produire un résultat exploitable en 2 à 3 échanges. La doc officielle de Rork insiste lourdement sur ce point, mais aucune review externe ne le quantifie.

Les coûts cachés : Apple Developer Account, RevenueCat, Supabase, domaine support, screenshots

Le plan Rork n’est que la première ligne de dépense. Voici ce que tu vas payer en plus si tu veux réellement publier une app monétisée.

Apple Developer Account : 99$/an, obligatoire pour publier sur l’App Store. Pas de contournement possible. Google Play Developer : 25$ en frais uniques. Supabase : gratuit sur le tier free pour le prototypage, mais le plan Pro à 25$/mois devient nécessaire dès que tu as des utilisateurs réels avec authentification. RevenueCat : gratuit jusqu’à 2 500$ de MRR, puis 1% du revenu au-delà. Domaine + hébergement pour la page de support et les politiques légales (Privacy Policy, CGU, EULA) : comptez 10 à 20$/an minimum via un hébergeur basique ou Google Sites (gratuit). Screenshots App Store : à produire toi-même ou via un outil comme Previewed.app (freemium).

Budget réaliste pour aller de l’idée à une app publiée et monétisée : entre 50$ et 200$/mois tout compris les premiers mois, selon le plan Rork choisi. C’est 100 à 500 fois moins cher qu’un développement traditionnel, mais c’est loin du « gratuit » que certains articles laissent entendre.

Combien de crédits pour un MVP réaliste : simulation sur 3 types d’apps

Les reviews disent « un MVP en 10 crédits » ou « 35 crédits suffisent ». Ces chiffres correspondent à une app d’une seule page sans authentification ni logique métier.

App simple (tracker d’habitudes, 5 écrans, stockage local) : entre 15 et 30 crédits si le prompt initial est bien structuré. Le plan gratuit peut suffire pour un prototype, mais pas pour itérer sérieusement.

App intermédiaire (app de contenu avec auth Supabase, 10 écrans, paywall RevenueCat) : entre 60 et 120 crédits. Le plan Junior à 100 crédits sera juste. Le Middle à 250 offre une marge confortable pour itérer.

App complexe (app sociale avec backend, IA intégrée via le Toolkit, 15+ écrans) : entre 150 et 300 crédits. Le plan Senior est le minimum réaliste.

Ces estimations supposent un utilisateur qui sait prompter. Si tu découvres l’outil en même temps que tu construis, multiplie par 1,5 à 2.

Ce que Rork a changé depuis les reviews de 2025 (et ce qui n’a pas bougé)

La majorité des avis en circulation décrivent un Rork figé à mi-2025. La plateforme a ajouté des briques significatives depuis, mais certains problèmes fondamentaux persistent.

Le Rork Toolkit : Claude Sonnet, GPT-5, DALL-E et Whisper intégrés sans config

C’est probablement l’ajout le plus sous-estimé. Le Rork Toolkit donne accès à une pile IA complète directement dans tes apps, sans backend à configurer et sans clé API à gérer.

Le chat et les workflows agents utilisent Claude Sonnet 4.5 (Anthropic). La génération de texte passe par GPT-5 (OpenAI). L’extraction de données structurées utilise GPT-4.1. La génération d’images repose sur DALL-E (GPT-Image-1.5). L’édition d’images utilise Gemini 2.5 Flash Image (Google). La transcription vocale passe par Whisper-1 (OpenAI).

Concrètement, tu peux construire une app qui analyse des photos, génère du contenu, transcrit de la voix et dialogue avec l’utilisateur via un chatbot, le tout en promptant Rork sans toucher une ligne de code ni créer un compte chez OpenAI. C’est un avantage compétitif massif que strictement aucune review existante ne mentionne, alors qu’il change fondamentalement le type d’apps réalisables avec la plateforme.

Le backend Hono + tRPC en beta : ce que ça débloque concrètement

Les reviews de 2025 reprochaient unanimement à Rork de ne pas gérer le backend. Ce n’est plus tout à fait vrai. Rork propose désormais une infrastructure serveur en beta, construite sur Hono (framework serveur) et tRPC (couche API typée).

Ce backend permet de créer des endpoints custom, d’exécuter de la logique côté serveur, de stocker des données de manière persistante et de protéger des routes avec de l’authentification. En pratique, ça débloque les apps sociales (interactions entre utilisateurs), le temps réel et tout ce qui nécessite une source de données centralisée.

La nuance importante : ce backend est en beta. Il fonctionne, mais des frictions existent et le support est limité sur cette fonctionnalité. Pour les apps mono-utilisateur avec stockage local ou les apps qui utilisent uniquement le Toolkit IA, il n’est pas nécessaire. Supabase reste une alternative plus mature pour l’authentification et la base de données, avec une intégration native documentée (tu colles tes clés Supabase et tu prompts « Connect Supabase »).

Le sync GitHub bidirectionnel : quand Rork devient un point de départ, pas une impasse

La critique récurrente des reviews anglaises est le vendor lock-in. L’argument ne tient plus. Rork propose un sync GitHub bidirectionnel : ton code est poussé vers un repo GitHub que tu possèdes, et tu peux éditer ce code localement dans Cursor, VS Code ou Xcode, puis repousser les modifications vers Rork.

L’implication est stratégique. Rork n’est plus obligatoirement l’outil final. Tu peux l’utiliser pour générer 80% de l’app en quelques heures, exporter le code, puis confier les 20% restants (personnalisations fines, features edge-case) à un développeur freelance qui travaille sur le repo GitHub. Le code généré est du React Native standard, lisible et maintenable.

Cette fonctionnalité est réservée aux plans payants. Tous les utilisateurs payants possèdent l’intégralité du code généré.

Les bugs et le support : état réel début 2026

Les bugs existent toujours. Les previews qui ne chargent pas, les crashes intermittents et les incohérences de génération sur des projets complexes sont documentés par les utilisateurs. La plateforme a gagné en stabilité par rapport à 2025, mais elle reste sensiblement moins fiable que des outils matures comme FlutterFlow.

Le support reste le point noir le plus cité. Le support email existe, le chat est disponible à partir du plan Middle, mais les temps de réponse sont inconstants. Plusieurs utilisateurs Reddit rapportent des tickets restés sans réponse pendant des jours. La communauté Discord compense partiellement ce manque, avec des utilisateurs expérimentés qui partagent des solutions.

Si tu bases un projet critique sur Rork, intègre ce risque dans ton planning. Prévois des marges de temps pour les bugs et ne compte pas sur une résolution rapide par le support.

Rork vs la vraie concurrence en 2026 (pas Bubble ni Appy Pie)

Comparer Rork à Bubble en 2026, c’est comparer un tournevis à une perceuse parce que les deux sont des outils. Bubble construit des apps web. Rork construit des apps mobiles natives. Ils ne sont pas concurrents. Voici les vrais arbitrages.

Bloom, Dreamflow, Emergent : les 3 alternatives que personne ne compare

Bloom est un builder mobile IA soutenu par Y Combinator, avec une approche plus ludique que Rork. Son avantage principal : un tier gratuit de 700 crédits mensuels, soit 20 fois plus que Rork. Un MVP basique consomme environ 10 crédits sur Bloom, ce qui permet de tester sans payer. L’interface est plus légère, les résultats légèrement moins aboutis sur des projets complexes.

Dreamflow combine un chat IA avec un éditeur visuel drag-and-drop. C’est l’hybride que Rork n’est pas. Un build basique consomme environ 2,5 crédits. L’outil convient aux profils qui veulent pouvoir intervenir visuellement après la génération IA, ce qui est impossible sur Rork.

Emergent prend un chemin inverse : il construit d’abord une app web, puis la convertit en app mobile via Capacitor. L’approche dual-platform est intéressante si tu veux aussi une version web, mais les performances natives sont inférieures à du React Native pur.

Rork garde l’avantage sur la qualité du code React Native généré, l’intégration Expo mature et le Toolkit IA intégré. Mais il n’est plus seul sur le créneau du mobile IA, et son absence de tier gratuit généreux le pénalise face à Bloom pour les utilisateurs en phase d’exploration.

FlutterFlow vs Rork : visuel vs conversationnel, le vrai arbitrage

FlutterFlow est le concurrent le plus sérieux de Rork pour le mobile natif. Il génère du Flutter (framework Google) et propose un éditeur visuel complet avec drag-and-drop.

L’arbitrage est clair. Si tu penses en mots et que tu veux aller vite, Rork est plus rapide. Tu décris, l’IA génère, tu itères par le chat. Si tu penses en visuels et que tu veux un contrôle précis sur chaque composant, FlutterFlow te donne ce contrôle. FlutterFlow a une courbe d’apprentissage plus élevée mais offre une personnalisation que Rork ne peut pas égaler sans exporter le code.

FlutterFlow est aussi plus mature et plus stable. Les bugs y sont moins fréquents, le support est plus réactif, et l’écosystème de templates et plugins est plus riche. En contrepartie, il coûte 50 à 200$/mois et la vitesse de prototypage est inférieure à celle de Rork.

Pour un MVP rapide destiné à valider une idée, Rork gagne. Pour une app destinée à rester en production avec des itérations régulières, FlutterFlow est plus fiable sur la durée.

La question que tout le monde évite : faut-il un dev à un moment ou pas ?

La réponse honnête est oui, dans la majorité des cas, si tu vises une app publiée et monétisée sur le long terme.

Rork couvre la génération du MVP, le prototypage rapide et même la première version publiable. Mais dès que tu atteins des besoins spécifiques (logique métier complexe, intégrations inhabituelles, optimisation de performance, fix de bugs que l’IA ne comprend pas), tu frappes un mur.

Le sync GitHub bidirectionnel existe précisément pour ça. Le scénario réaliste : tu utilises Rork pour construire 80% de l’app, tu exportes le code, et tu paies un dev React Native freelance entre 500 et 2 000€ pour les finitions. Le coût total reste 10 à 50 fois inférieur à un développement from scratch.

L’erreur fréquente est de croire qu’un outil no-code élimine le besoin de compétence technique. Ce qu’il élimine, c’est le besoin de compétence technique pour démarrer. Le besoin resurgit au moment du déploiement, de la monétisation et de la maintenance.

Le mur du déploiement : là où « no-code » devient un mensonge

Construire l’app, c’est 40% du travail. La publier sur les stores sans se faire rejeter, c’est les 60% restants. Et c’est là que la promesse no-code de Rork montre ses limites.

Publier sur l’App Store : ce qui est automatisé et ce qui ne l’est pas

Rork a simplifié le process de publication iOS. Depuis l’éditeur, tu cliques « Publish », tu entres tes identifiants Apple Developer, tu valides le code de vérification, et Rork gère le build et l’upload vers App Store Connect.

Ce qui n’est pas automatisé : la création de l’Apple Developer Account (99$/an, avec parfois un délai de validation de 24 à 48h). La rédaction de la description App Store. La création des screenshots (3 à 10 captures obligatoires, pas de screenshots iPhone étirés pour iPad sous peine de rejet). La mise en place des politiques légales (Privacy Policy, Terms & Conditions, EULA). La configuration des permissions dans le fichier app.json avec des descriptions justifiant chaque accès demandé. Et la gestion de la review Apple elle-même, qui peut prendre de 24h à plusieurs jours.

C’est faisable sans être développeur, mais ça demande de la rigueur et quelques heures de travail non trivial.

Les rejets Apple les plus fréquents avec Rork (et comment les anticiper)

Apple rejette les apps pour des raisons précises et documentées. Avec Rork, les motifs récurrents sont identifiables.

Le premier : les descriptions de permissions génériques dans le fichier app.json. Si ton app demande l’accès à la caméra et que la description dit simplement « Camera access needed », Apple rejette. Chaque permission doit expliquer pourquoi ton app spécifiquement a besoin de cet accès (« We use your camera to scan meal photos for calorie estimation »).

Le deuxième : l’absence de politiques légales visibles. Privacy Policy, CGU et EULA doivent être accessibles dans l’app ET dans la fiche App Store. La doc Rork recommande d’utiliser le EULA standard Apple pour simplifier.

Le troisième : le manque de transparence sur les prix. Si ton app a un paywall, la description App Store doit mentionner explicitement que des fonctionnalités nécessitent un abonnement payant. Oublier cette mention provoque un rejet systématique.

Le quatrième : les screenshots iPhone utilisées pour iPad. Apple exige des screenshots aux dimensions correctes pour chaque type d’appareil. Pas de redimensionnement approximatif.

Anticiper ces quatre points avant la soumission élimine la grande majorité des rejets.

Google Play Store : le process différent que les reviews ignorent

Quasiment aucune review ne parle du déploiement Android. Le process diffère sur plusieurs points.

Google exige un fichier AAB (Android App Bundle) pour la distribution, pas un APK. L’APK sert au développement et aux tests sur appareil, le AAB est le format de production. Rork génère les deux, mais la confusion entre les deux formats est fréquente chez les débutants.

Le Google Play Developer Account coûte 25$ en paiement unique (pas d’abonnement annuel comme Apple). La review Google est généralement plus rapide qu’Apple mais peut être imprévisible sur les premières soumissions. Les exigences en matière de politiques de confidentialité sont similaires.

Un point spécifique à Android : la Data Safety Section dans Google Play Console requiert de déclarer précisément quelles données ton app collecte, partage et stocke. C’est un formulaire détaillé que tu remplis manuellement et qui doit correspondre exactement au comportement réel de l’app.

Peut-on réellement gagner de l’argent avec une app Rork ?

La question que tout le monde pose et à laquelle personne ne répond avec des chiffres. Publier une app ne suffit pas. La monétiser exige un système de paiement, un onboarding qui convertit et des métriques suivies dès le premier jour.

Le modèle subscription via RevenueCat : setup réel et friction réelle

RevenueCat est le standard pour gérer les abonnements in-app. Rork l’intègre nativement via le panneau Integrations. Tu connectes ton compte RevenueCat, tu prompts « Set up RevenueCat », et l’IA configure les offerings, products et entitlements.

La friction commence après. Tu dois créer les abonnements manuellement dans App Store Connect (subscription groups, product IDs, prix, localisations). Puis connecter App Store Connect à RevenueCat en configurant : le Bundle ID, l’In-App Purchase Key, l’App Store Connect API Key, le Vendor Number, et l’App-Specific Shared Secret. Chaque étape a sa propre interface, ses propres formats, et ses propres pièges.

Le test passe d’abord par le sandbox RevenueCat (achats simulés), puis par TestFlight (achats sandbox Apple). Ce n’est qu’après validation sur TestFlight que les achats réels fonctionnent en production.

C’est faisable en suivant la documentation Rork pas à pas, mais comptez une demi-journée à une journée complète pour un premier setup, en incluant les erreurs et les allers-retours entre les interfaces.

Les métriques à suivre dès le jour 1 : MRR, churn, trial-to-paid

Le MRR (Monthly Recurring Revenue) est ton chiffre d’affaires mensuel récurrent. C’est le seul indicateur de santé de ton app à abonnement. 100 utilisateurs à 9,99$/mois = 999$ de MRR brut, moins 30% de commission Apple = environ 700$ net.

Le Net New MRR décompose la trajectoire : nouveaux abonnés + upgrades moins les désabonnements. Si ce chiffre est négatif, ton app meurt à petit feu même si le MRR total semble stable.

Le churn mensuel (taux de désabonnement) est le tueur silencieux. Un churn de 10%/mois signifie que tu perds la moitié de tes abonnés en 7 mois. Les benchmarks acceptables varient par catégorie, mais sous les 6 à 8% mensuels tu es dans une zone saine pour une app consumer.

Le trial-to-paid mesure combien d’utilisateurs en essai gratuit convertissent en abonnés payants. Entre 40 et 60%, c’est bon. Sous 30%, ton onboarding a un problème. Au-dessus de 60%, ton pricing est probablement trop bas.

RevenueCat fournit toutes ces métriques dans son dashboard. Les configurer ne prend que quelques clics une fois le setup initial terminé.

Le cas Wrestle AI : 1M de vues, 17 000$ : ce que ça révèle sur le product-market fit

Ce cas est documenté dans le Rork Playbook (section marketing de la documentation officielle). Wrestle AI est une app de coaching lutte qui analyse des vidéos de matchs via l’IA pour identifier forces, faiblesses et axes d’amélioration.

L’app a généré 17 000$ avec 1 million de vues sur du contenu influenceur. Le fondateur était lui-même lutteur, comprenait intimement le problème, et l’app résolvait un besoin spécifique que les utilisateurs ne pouvaient satisfaire autrement. Le « gotcha moment » (la feature qui arrête le scroll) était l’analyse IA d’un match, visuellement impressionnante et impossible à reproduire sans télécharger l’app.

Le product-market fit explique tout. L’audience cible (lutteurs sérieux) est nichée mais passionnée, le problème est ressenti fréquemment (chaque entraînement), et la solution est unique. Ces trois conditions réunies transforment du trafic en revenus.

L’erreur des apps « vibe codées » : 1,5M de vues pour 15$ quand l’idée est mauvaise

Le même fondateur a lancé simultanément un clone de RizzGPT. L’app a généré 1,5 million de vues via le même type de marketing influenceur. Résultat : 15$ de revenus.

L’explication est brutale. L’app n’était pas originale (clones de RizzGPT partout), le fondateur n’était pas passionné par le produit, et l’utilisateur n’avait aucune raison de payer pour une app interchangeable avec dix autres gratuites. Le trafic était là, la conversion non.

Cette comparaison détruit un mythe central du vibe coding : l’idée que la vitesse de création suffit à générer des revenus. Rork peut te construire une app en 20 minutes. Si l’app ne résout pas un problème réel pour une audience identifiable, ces 20 minutes ne valent rien. La plateforme est un accélérateur de construction, pas un accélérateur de product-market fit.

Verdict opérationnel : pour qui Rork vaut le coup (et pour qui c’est une perte de temps)

Les reviews existantes concluent toutes par « c’est bien pour le prototypage, pas pour la production ». Ce verdict binaire est paresseux. La réalité est plus granulaire.

Les 3 profils pour qui Rork est rentable

Le solopreneur avec une idée d’app consumer nichée qui veut valider un concept avant d’investir. Rork lui permet de passer de l’idée à un prototype testable sur téléphone en quelques heures, pour moins de 50$. Si l’idée ne tient pas, la perte est minimale. Si elle tient, il a une base de code exportable pour continuer.

Le créateur de contenu qui veut monétiser via une app plutôt que via des produits d’information classiques. L’app à abonnement avec paywall RevenueCat est un modèle de revenus récurrents que Rork rend accessible sans équipe technique. Le Toolkit IA intégré permet d’ajouter de l’intelligence (chatbot, analyse, génération) comme avantage compétitif.

Le freelance ou la petite agence qui vend des MVPs à des clients. Rork permet de produire un prototype fonctionnel en quelques jours au lieu de plusieurs semaines, avec un coût de revient suffisamment bas pour dégager des marges significatives sur des prestations de 2 000 à 5 000€.

Les 3 profils qui vont perdre leur temps et leurs crédits

Celui qui cherche un outil magique sans aucune compétence technique. Rork supprime le besoin de coder, pas le besoin de comprendre comment fonctionne un écosystème d’app (stores, permissions, paiements, review). Sans cette compréhension minimale, chaque étape post-build devient un mur.

Celui qui veut une app enterprise complexe avec un backend lourd (gestion d’équipe, workflows complexes, intégrations multiples, conformité réglementaire). Rork n’est pas conçu pour ça. Le backend en beta et les limites de personnalisation rendent ce type de projet frustrant et sous-optimal.

Celui qui itère sans stratégie en envoyant des prompts vagues et en corrigeant au fil de l’eau. Le modèle par crédits punit ce comportement. 100 crédits brûlés en corrections auraient pu construire 3 MVPs avec des prompts bien structurés.

Le scénario optimal : Rork comme accélérateur, pas comme solution complète

Rork est le plus rentable quand il est utilisé comme un outil de phase 1, pas comme la solution de bout en bout.

Le workflow optimal : tu définis ton idée, tu structures un prompt détaillé (expérience cible, mood, flow principal, contraintes), tu génères le MVP en 30 à 60 crédits, tu testes sur téléphone, tu itères 2 à 3 fois, puis tu exportes le code via GitHub. Si l’app doit aller en production, tu confies les finitions (personnalisation UI, edge cases, optimisation performance) à un dev React Native freelance qui travaille sur le repo exporté.

Le coût total de ce scénario : 50 à 100$ de crédits Rork + 99$ d’Apple Developer Account + 500 à 2 000€ de dev freelance pour les finitions. Total : entre 600€ et 2 200€ pour une app publiée sur l’App Store. Un développement traditionnel équivalent coûte entre 10 000€ et 50 000€.

C’est dans ce ratio que Rork trouve sa vraie proposition de valeur. Pas dans la promesse du zéro effort, mais dans la compression radicale du temps et du coût entre l’idée et le premier produit testable.

Questions fréquentes

Rork fonctionne-t-il en français ou uniquement en anglais ?

L’interface de Rork et l’IA comprennent les prompts en anglais. Tu peux tenter de prompter en français, mais les résultats seront moins précis et moins fiables qu’en anglais. Le contenu généré dans l’app (textes d’interface, labels, placeholders) peut être en français si tu le spécifies dans ton prompt. La documentation officielle est exclusivement en anglais. Pour obtenir les meilleurs résultats, rédige tes prompts en anglais, même si ton app cible un public francophone.

Les apps Rork passent-elles la review Apple du premier coup ?

Rarement sans préparation. Les rejets ne viennent généralement pas du code généré par Rork (qui est du React Native standard via Expo), mais des éléments périphériques : descriptions de permissions trop vagues dans app.json, absence de Privacy Policy ou CGU dans l’app et sur la fiche store, screenshots mal dimensionnées, ou omission de la mention d’abonnement payant dans la description. En suivant la checklist de la documentation Rork avant soumission, le taux de passage en première tentative augmente significativement, mais un ou deux allers-retours avec Apple restent fréquents.

Peut-on utiliser Rork pour créer une app Android uniquement ?

Oui, en mode Rork Pro (React Native/Expo). Le code généré est cross-platform par défaut. Tu peux choisir de ne déployer que sur Google Play Store en générant un fichier AAB sans jamais toucher à l’App Store. C’est d’ailleurs une stratégie pertinente pour les créateurs qui veulent éviter les 99$/an de l’Apple Developer Account et se concentrer sur le marché Android avec les 25$ uniques de Google Play. Rork Max en revanche est exclusivement iOS (Swift natif) et ne produit aucun build Android.

Que se passe-t-il si on dépasse ses crédits mensuels en plein projet ?

Tu es bloqué jusqu’au 1er du mois suivant ou jusqu’à ce que tu upgrades ton plan. Il n’y a pas d’option d’achat de crédits supplémentaires à l’unité. Les crédits non utilisés ne sont pas reportés. C’est une contrainte réelle qui oblige à planifier : estimer le nombre d’itérations nécessaires avant de commencer un projet, regrouper les modifications dans des prompts détaillés plutôt que d’envoyer des micro-corrections, et garder une réserve de crédits pour les ajustements post-test sur téléphone.

Rork convient-il pour créer des jeux mobiles ?

Rork Pro (React Native) peut générer des jeux simples de type quiz, jeux de cartes ou puzzles basiques. Pour tout ce qui implique du rendu graphique temps réel, de la physique ou des animations complexes, React Native n’est pas le bon framework. Rork Max (Swift) ouvre davantage de possibilités grâce à l’accès natif aux frameworks Apple (SpriteKit, SceneKit, ARKit), mais la génération IA de logique de jeu complexe reste limitée. Si ton projet principal est un jeu mobile, des outils spécialisés comme Unity ou Godot seront plus adaptés, même s’ils exigent des compétences techniques.