Aller au contenu
WebViewGold Du vibe coding à l'App Store
Français
Obtenir WebViewGold

Cursor

Les background agents de Cursor pour une passe de conformité : des tâches en parallèle, relues comme des pull requests

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.

  • Garantie d'approbation – ou remboursement sous 14 jours
  • Aucun codage requis
  • Paiement unique, mises à jour gratuites
  • Support humain 24/7
  • Conçu en Allemagne depuis 2014 · ISO 27001

Pourquoi la préparation aux stores convient aux agents en parallèle

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.

Les Cloud Agents en six points

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.

Plusieurs façons d'en lancer un

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.

D'abord le contrôle de version

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.

Les secrets dans le tableau de bord

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.

Ils lisent AGENTS.md

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.

Un coût à l'usage

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.

Donnez à chaque agent un environnement de travail

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.

json
{
  "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 :-)

Julian Koch · Co-fondateur de DuelDonkey · CodeCanyon

Ajoutez une section pour les agents cloud dans AGENTS.md

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.

markdown
## 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.

Découpez la passe en tâches parallèles

AgentTâcheFichiers typiquesTerminé quand
1. Pages légalesDe vraies pages /privacy et /terms basées sur ce que le code collecte, liées depuis le pied de page et les réglagesRoutes, pied de page, écran des réglagesLes deux URL se chargent directement et nomment chaque SDK qui collecte des données
2. Suppression de compteSupprimer le compte dans les réglages, plus une page publique /delete-account ; le serveur supprime les données, les fichiers et l'utilisateur d'authentificationRéglages, route API, helpers d'authentificationUn 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, routeurLes clics hors ligne affichent un état d'erreur, jamais un écran blanc
4. Mode appHelper isNativeApp() ; masquer dans l'app les badges des stores, les invitations à installer et les badges de builderHelper de plateforme, bandeauxEn simulant le user agent, chaque élément réservé au web disparaît
5. Brouillons pour les storesdocs/store/ : notes pour la validation, description, mots-clés, inventaire des données pour App Privacy et Data safetyDocumentation uniquementChaque 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 survolCSS, composants de mise en pageAucun défilement horizontal à 320 px sur les routes principales

Un seul modèle de prompt pour les six agents

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.

À coller dans chaque Cloud Agent, en changeant le bloc TÂCHE
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.

Lancez la passe

Environ une heure de mise en place, puis surtout du temps de relecture.

  1. Connectez le contrôle de version et préparez l'environnement

    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.

  2. Committez AGENTS.md et .cursor/BUGBOT.md

    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.

  3. Ajoutez les secrets et un compte de test

    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 ».

  4. Lancez les agents 1 à 5 ensemble

    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.

  5. Relisez chaque pull request

    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.

  6. Fusionnez, déployez, testez dans la vraie app

    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.

.cursor/BUGBOT.md : une checklist de validation pour chaque pull request

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.

markdown
# 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.

Ce qu'il faut vérifier dans chaque pull request

  • Le diff ne touche que des fichiers liés à la tâche ; des modifications sans rapport justifient de la renvoyer.
  • Le lint, les tests et le build ont tourné, et la description le dit.
  • Les écrans réservés aux utilisateurs connectés ont vraiment été vérifiés : la description nomme le compte de test, pas « devrait fonctionner ».
  • Aucun nouveau SDK ou traceur ne s'est glissé, que vous devriez déclarer dans App Privacy et Data safety.
  • Les textes sont réels : pas de Lorem ipsum, pas de « Your Company Inc. » dans la politique de confidentialité.
  • Tout ce qui est natif (push, partage, biométrie) se trouve derrière isNativeApp(), avec une solution de repli web.

Pièges

  • Plusieurs agents sur les mêmes fichiers : les conflits de fusion mangent le temps gagné. Découpez par zone de fichiers, pas par idée.
  • Des agents qui annoncent « testé sur iOS ». Ils tournent dans des VM cloud sans votre app native ; les tests sur de vrais appareils restent votre affaire.
  • Une URL de déploiement de preview copiée dans la configuration WebViewGold. Seul le domaine de production va dans Config.swift et Config.java.
  • Des secrets committés parce qu'un agent en « avait besoin ». Utilisez les secrets du tableau de bord et renouvelez tout ce qui a atterri dans le dépôt.
  • Six agents sur un gros modèle, la facture grimpe vite. Commencez par deux ou trois, vérifiez la qualité des pull requests, puis passez à l'échelle.
  • AGENTS.md et .cursor/rules qui se contredisent. Les agents suivent celui qu'ils lisent ; gardez des invariants identiques (comment garder une seule source).

Questions fréquentes

Background agents et Cloud Agents, est-ce la même chose ?

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.

Les Cloud Agents suivent-ils mes .cursor/rules ?

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.

Un Cloud Agent peut-il compiler l'app iOS ?

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.

Puis-je lancer un agent depuis une issue GitHub ?

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.

Un agent va-t-il fusionner dans main de lui-même ?

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.

Combien d'agents lancer à la fois ?

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.

Trois façons de mettre votre app dans les stores

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.

Faites-le vous-même

$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

Full Service

$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é par WeSetupYourWebViewApp

Prix Soldes d'hiver valables jusqu'au 31 décembre 2026.

Prêt à publier votre app ?

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.