Des machines isolées
Chaque agent tourne dans sa propre VM cloud avec un environnement de développement complet. Il clone votre dépôt, travaille sur une branche séparée et pousse le résultat pour que vous le relisiez.
Cursor
Les background agents de Cursor, désormais appelés Cloud Agents, tournent sur des machines cloud isolées, travaillent sur leur propre branche et rendent une pull request. Cela convient très bien à la préparation pour l'App Store : découpez le travail de conformité en tâches indépendantes, lancez-les côte à côte et relisez chaque résultat comme la PR d'un collègue avant que quoi que ce soit n'atteigne le build natif.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
Une passe de conformité aux stores est une checklist de corrections en grande partie indépendantes : pages légales, suppression de compte, mise en page mobile, états d'erreur, masquage des éléments réservés au web, notes pour la validation. Dans une longue session locale, ces modifications s'empilent en un seul diff difficile à relire. Réparties entre plusieurs agents cloud, chaque tâche touche ses propres fichiers, arrive dans sa propre pull request et peut être acceptée, renvoyée ou relancée isolément.
L'objectif est le même que dans le workflow Cursor de bout en bout : une web app qui se comporte comme une app quand WebViewGold la charge dans une WebView native. Cette page ne couvre que la partie en parallèle, et ce qu'il vous reste à faire vous-même. Tout le reste sur la publication de projets Cursor est rassemblé sur la page dédiée à Cursor.
Chaque agent tourne dans sa propre VM cloud avec un environnement de développement complet. Il clone votre dépôt, travaille sur une branche séparée et pousse le résultat pour que vous le relisiez.
Choisissez Cloud sous le champ de saisie de l'agent dans Cursor, utilisez cursor.com/agents depuis n'importe quel appareil, mentionnez @cursor dans Slack ou Linear, ou commentez @cursor sur une issue ou une pull request GitHub.
Un administrateur du compte Cursor connecte le contrôle de version (GitHub, GitLab, Bitbucket Cloud ou Azure DevOps), et l'agent a besoin d'un accès en lecture et en écriture au dépôt.
Ajoutez les clés API et les identifiants de test comme secrets dans le tableau de bord Cursor au lieu de committer un fichier .env. Ils sont injectés au démarrage d'un agent : les agents déjà en cours ne voient donc pas les nouveaux.
La documentation des agents cloud de Cursor le dit clairement : placez donc le contexte de l'app native et les invariants des stores dans AGENTS.md, pas seulement dans .cursor/rules.
Les exécutions sont facturées au tarif du modèle choisi, et tous les forfaits ne les incluent pas. Vous fixez une limite de dépenses à la première utilisation ; gardez-la raisonnable avant d'en lancer six à la fois.
Les agents peuvent configurer l'environnement eux-mêmes (et l'enregistrer sous forme de snapshot), ou vous committez .cursor/environment.json. Pour une web app Node typique, cela suffit : installer les dépendances, lancer le serveur de développement dans un terminal que l'agent peut voir, exposer le port. Les noms de champs viennent du schéma publié par Cursor ; la description du terminal est affichée à l'agent.
{
"install": "npm ci",
"terminals": [
{
"name": "web",
"command": "npm run dev -- --port 3000",
"description": "Dev server. Check changed routes here at 390 px and 320 px width."
}
],
"ports": [
{ "name": "web app", "port": 3000 }
]
}
Avec une bonne version optimisée de votre application Web, vous pouvez avoir une superbe application mobile en quelques minutes. De plus, le service client est très agréable et très utile! Je ne peux que recommander WebViewGold :-)
Committez ceci sur la branche par défaut avant de lancer quoi que ce soit. Le premier bloc est le contexte partagé de l'app native ; le second indique à chaque agent comment se comporter en tant que travailleur parmi d'autres.
## Native app (WebViewGold)
This web app also ships as iOS and Android apps. WebViewGold loads
https://app.example.com in a native WebView; every deploy is live in both apps.
- Detect the app only with isNativeApp() (user agent contains "MyAppNative").
- Native features are URL schemes from https://www.webviewgold.com/llms-full.txt.
Never invent one; always keep a web fallback.
- Store invariants: real /privacy and /terms; in-app account deletion (server-side);
Sign in with Apple next to any social login; no external checkout for digital
goods in the iOS app; loading, empty and error states; layout works at 320 px.
## Cloud agents
- One task per agent. Touch only the files the task needs. If you must edit a
shared layout file, say so at the top of the PR description.
- Run npm run lint, npm test and npm run build before you push.
- Check every route you changed in the browser at 390 px and 320 px and describe
what you saw in the PR.
- PR description: what changed, how you verified it, open questions, and what
needs a test on a real iPhone and Android phone.
- You cannot run the native app. Never claim you tested on iOS or Android.| Agent | Tâche | Fichiers typiques | Terminé quand |
|---|---|---|---|
| 1. Pages légales | De vraies pages /privacy et /terms basées sur ce que le code collecte, liées depuis le pied de page et les réglages | Routes, pied de page, écran des réglages | Les deux URL se chargent directement et nomment chaque SDK qui collecte des données |
| 2. Suppression de compte | Supprimer le compte dans les réglages, plus une page publique /delete-account ; le serveur supprime les données, les fichiers et l'utilisateur d'authentification | Réglages, route API, helpers d'authentification | Un utilisateur de test a disparu de la base de données et du fournisseur d'authentification (exigences de suppression) |
| 3. États et impasses | États de chargement, vides et d'erreur avec Réessayer ; une page 404 ; suppression des boutons « bientôt disponible » | Composants de données, routeur | Les clics hors ligne affichent un état d'erreur, jamais un écran blanc |
| 4. Mode app | Helper isNativeApp() ; masquer dans l'app les badges des stores, les invitations à installer et les badges de builder | Helper de plateforme, bandeaux | En simulant le user agent, chaque élément réservé au web disparaît |
| 5. Brouillons pour les stores | docs/store/ : notes pour la validation, description, mots-clés, inventaire des données pour App Privacy et Data safety | Documentation uniquement | Chaque type de données de l'inventaire renvoie à du code du dépôt |
| 6. Mise en page mobile (en dernier) | Débordements, zones tactiles, padding safe-area, champs de 16 px, aucune commande uniquement au survol | CSS, composants de mise en page | Aucun défilement horizontal à 320 px sur les routes principales |
Gardez la partie commune identique pour que chaque pull request ait la même forme ; seul le bloc de tâche change. L'exemple montre l'agent 2.
Contexte : cette web app est aussi publiée sous forme d'apps natives iOS et Android via WebViewGold, qui charge notre URL de production dans une WKWebView et une Android WebView. Lisez d'abord AGENTS.md et suivez ses sections « Native app » et « Cloud agents ». Règles pour cette exécution : - Travaillez uniquement sur la tâche ci-dessous. Ne refactorisez pas de code sans rapport et n'ajoutez pas de dépendances, sauf si la tâche l'exige. - Lancez le lint, les tests et le build de production avant de pousser. - Ouvrez une pull request intitulée « store-readiness: <nom de la tâche> ». Dans la description, indiquez ce qui a changé, comment vous l'avez vérifié (routes et largeurs), les questions ouvertes et ce que je dois tester sur un vrai iPhone et un vrai téléphone Android. - Si quelque chose est ambigu, par exemple quelles tables contiennent des données utilisateur, arrêtez-vous et posez la question dans la pull request au lieu de deviner. TÂCHE : Suppression de compte - Ajoutez dans les réglages une action « Supprimer le compte » avec une étape de confirmation. - À la confirmation, appelez un endpoint côté serveur qui supprime les lignes de l'utilisateur dans chaque table qui le référence, supprime ses fichiers stockés et supprime l'utilisateur d'authentification. Déconnectez-le ensuite et affichez un écran de confirmation. - Ajoutez une page publique /delete-account qui explique les étapes dans l'app et propose un moyen de demander la suppression sans l'app (formulaire ou adresse e-mail). - Ajoutez un test qui crée un utilisateur, le supprime et vérifie qu'il ne reste ni lignes ni fichiers.
Environ une heure de mise en place, puis surtout du temps de relecture.
Un administrateur connecte le fournisseur du dépôt dans Cursor. Committez environment.json, ou laissez le premier agent configurer l'environnement et l'enregistrer sous forme de snapshot, pour que les agents suivants démarrent plus vite.
Les agents lisent AGENTS.md ; Bugbot lit .cursor/BUGBOT.md (exemple ci-dessous). Les deux doivent se trouver sur la branche par défaut avant le premier lancement.
Stockez l'URL de la base de données de staging, les identifiants de test et les clés API comme secrets du tableau de bord. Sans login de test, les agents ne peuvent pas vérifier les écrans réservés aux utilisateurs connectés et vous diront qu'ils « devraient fonctionner ».
Démarrez-les depuis le champ de saisie de l'agent (Cloud), depuis cursor.com/agents, ou créez une issue GitHub par tâche et commentez @cursor avec le prompt. Lancez l'agent 6 une fois les autres fusionnés, car le travail de mise en page touche les mêmes composants.
Lisez le diff et la description, laissez Bugbot commenter et ouvrez le déploiement de preview dans le navigateur de votre téléphone. Pour demander des modifications, commentez @cursor sur la pull request en précisant quoi corriger.
Fusionnez dans un ordre logique, déployez en production, puis testez le build WebViewGold sur de vrais appareils. Les agents cloud ne peuvent pas exécuter l'app native : cette étape reste la vôtre.
Bugbot n'utilise pas vos fichiers .cursor/rules ; il lit .cursor/BUGBOT.md (toujours le fichier racine, ainsi que les fichiers imbriqués proches des fichiers modifiés). Il s'exécute à chaque mise à jour d'une pull request, et un commentaire cursor review ou bugbot run le déclenche à la main.
# Store review rules
This app ships as iOS and Android apps via WebViewGold (native WebView around our URL).
Flag as a bug:
- New fixed or sticky UI without env(safe-area-inset-*) padding.
- Tap targets smaller than 44 x 44 px, or hover-only interactions.
- OAuth opened via window.open, target="_blank" or a popup.
- A native URL scheme (registerpush://, shareapp://, bioauth:// ...) called without
an isNativeApp() check or without a web fallback.
- Purchase or upgrade buttons for digital goods that link to an external checkout
inside the native app.
- Removing or breaking /privacy, /terms, /delete-account or the Delete account action.
- Data fetching without loading, empty and error states.
- Secrets or service-role keys in client-side code.
Ignore: styling preferences, naming, and refactors that do not change behavior.Oui. Cursor a renommé les Background Agents en Cloud Agents. Les anciens tutoriels utilisent encore l'ancien nom ; l'idée reste la même : un agent dans une VM cloud isolée, qui travaille sur sa propre branche et rend le résultat.
La documentation des agents cloud de Cursor indique explicitement qu'ils lisent AGENTS.md : c'est donc l'endroit sûr pour tout ce que chaque agent doit respecter. Gardez vos règles de projet pour le travail local, avec les mêmes invariants.
Non. Compiler et signer une app iOS nécessite Xcode sous macOS, et les agents travaillent dans des environnements de développement cloud. Compilez avec Xcode sur un Mac ou avec le Cloud Builder de WebViewGold, qui compile et envoie les deux apps depuis le navigateur.
Oui. Une fois le contrôle de version connecté, commentez @cursor sur une issue ou une pull request avec vos instructions. Une issue par tâche de conformité vous donne en plus un historique propre de ce qui a été fait.
Les agents cloud travaillent sur une branche séparée et la poussent pour que vous la relisiez. Protégez quand même votre branche par défaut, pour que rien n'arrive en production sans relecture humaine.
Autant que vous avez de tâches indépendantes. Six conviennent à cette passe, mais commencez par deux ou trois jusqu'à ce que vous fassiez confiance au résultat, et lancez le travail de mise en page en dernier.
Même résultat, charge de travail différente de votre côté. Les trois formules incluent la garantie d'approbation et le support humain 24/7.
$109 par plateforme, paiement unique
La licence WebViewGold : un projet Xcode ou Android Studio prêt à l'emploi. Collez votre URL, définissez le nom et l'icône, activez les fonctionnalités, compilez et soumettez. Mises à jour gratuites à vie.
Voir les offres sur la page principale$349 par licence, extension en paiement unique
Ni Mac, ni Xcode, ni Android Studio : configurez dans le navigateur, nous compilons les deux apps dans le cloud et les transmettons à App Store Connect et à la Play Console.
Comment fonctionne le Cloud Builder Essayer la démo gratuite$698 par plateforme $798
Envoyez-nous votre URL et votre icône. Notre équipe configure, compile et livre votre app sous 72 heures, en marque blanche, projets sources inclus. Les deux plateformes pour $1,158.
Détails du Full Service Propulsé parPrix Soldes d'hiver valables jusqu'au 31 décembre 2026.
Garantie d'approbation App Store & Google Play – ou remboursement sous 14 jours
Vous préférez déléguer ? Full Service : nous configurons, compilons et livrons sous 72 heures, dès $698 par plateforme. Des questions ? Chattez avec nous 24/7.
Les remboursements sont accordés aux conditions indiquées dans notre FAQ : un refus non lié au contenu par Apple et/ou Google, demandé dans les 14 jours suivant l'achat.