ChatGPT & Codex
La plupart des problèmes d'une app web lors de sa première soumission (safe areas, pages légales, suppression de compte, états d'erreur, restes du site web) sont indépendants les uns des autres. Ils se prêtent donc bien à Codex dans le cloud : une tâche par correction, toutes exécutées en même temps dans leur propre espace de travail, chacune aboutissant à un diff que vous relisez et à une pull request que vous mergez. Tout l'art consiste à découper le travail pour que les pull requests n'entrent pas en conflit.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
Une tâche cloud Codex s'exécute dans le cloud plutôt que sur votre ordinateur portable. Vous publiez une fois pour toutes un environnement (le dépôt GitHub, un script d'installation des dépendances, des règles réseau et, si besoin, des secrets), et chaque tâche que vous lancez reçoit son propre espace de travail isolé, préparé à partir de cet environnement. Codex modifie le code, exécute vos commandes de lint et de test, puis vous rend un diff accompagné de la sortie des tests. Vous pouvez demander des modifications complémentaires dans la même tâche, puis commiter ou ouvrir une pull request. Les tâches continuent de tourner pendant que votre ordinateur est en veille, et vous pouvez les lancer depuis l'app ou l'interface web de Codex, depuis l'extension IDE ou depuis le terminal avec codex cloud.
La préparation pour les stores s'y prête bien. Les corrections que demandent les examinateurs sont pour la plupart indépendantes (les safe areas ne se soucient pas de votre page de confidentialité, la suppression de compte ne se soucie pas des indicateurs de chargement), chacune a une définition de « terminé » vérifiable, et aucune n'a besoin de l'app native : l'app WebViewGold charge simplement ce que vous déployez sur votre URL de production. Au lieu d'une longue session qui touche à tout, vous lancez quatre ou cinq tâches ciblées, relisez de petites pull requests et les mergez une par une.
Ce que les tâches cloud ne font pas : compiler ou signer les apps iOS et Android, ouvrir le résultat sur un téléphone ou remplir App Store Connect. Cela reste entre vos mains, celles de votre projet WebViewGold et des deux consoles.
Environ trente minutes ; chaque tâche ultérieure en profite.
Les tâches cloud travaillent sur une copie du dépôt : le fichier accompagne donc chaque tâche. Il doit contenir vos commandes d'installation, de lint, de vérification des types et de test (Codex les exécute avant de terminer) ainsi que les règles des stores rédigées sous forme d'invariants. Partez du modèle AGENTS.md pour les apps WebViewGold et ajoutez la section sur le travail en parallèle ci-dessous.
Plusieurs corrections ont besoin de savoir si la page s'exécute dans l'app native. Créez isNativeApp() (une vérification du user agent à la recherche du marqueur que vous définissez dans WebViewGold via useragent_iphone et useragent_ipad dans Config.swift et USER_AGENT dans Config.java) dans une tâche ou en local, et mergez-le avant de répartir le travail. Sinon, cinq tâches écrivent cinq helpers.
Connectez GitHub, sélectionnez le dépôt et laissez Codex détecter le runtime. Vérifiez que le script d'installation effectue une installation propre de vos dépendances (par exemple npm ci). Pour l'accès réseau, n'autorisez que les domaines du gestionnaire de paquets : ces tâches n'ont pas besoin de l'Internet ouvert, et un accès limité empêche une tâche de récupérer et de suivre des contenus que vous n'avez jamais relus.
La mise en page, les pages légales et les états d'erreur ne demandent aucun secret. Si vos tests ont besoin d'une base de données, faites-les pointer vers un projet de test séparé. Ne mettez jamais une clé service role de production ni un secret de paiement dans un environnement qui exécute des tâches sans surveillance.
Publiez l'environnement, puis lancez une tâche jetable : « Exécutez les commandes d'installation, de lint, de vérification des types et de test d'AGENTS.md, ne modifiez rien, rapportez les résultats. » Si elle échoue, corrigez l'environnement avant de commencer le vrai travail ; chaque tâche parallèle échouerait de la même manière.
Ajoutez ceci à l'AGENTS.md que vous avez déjà. C'est la règle de périmètre qui permet de merger les pull requests parallèles ; le format des pull requests permet de relire chacune en quelques minutes.
## Commands (run all of them before you finish a task)
- Install: npm ci
- Lint: npm run lint
- Types: npm run typecheck
- Tests: npm test
## Store-readiness work
This web app is also published as native iOS and Android apps with WebViewGold.
The native apps load https://app.example.com in a WebView. Detect the app only
with isNativeApp() from src/lib/platform.ts.
Rules for every task:
- Stay inside the files and folders named in the task prompt. Several tasks run
in parallel; changes outside your scope cause merge conflicts. If a fix needs
a change elsewhere, describe it in the summary instead of making it.
- No new dependencies and no version upgrades unless the prompt asks for them.
- Native features are called only through the WebViewGold URL schemes listed in
the bridge section of this file. Never invent a native API.
- Digital goods inside the native app go through in-app purchase. Never add a
Stripe checkout or an external payment link for them behind isNativeApp().
- Users can sign up, so account deletion must keep working.
- Every screen works at 320px width, pads fixed bars with safe-area insets,
has tap targets of 44px or more and inputs with a font-size of 16px or more.
## Pull requests
Title: [store-readiness] <task name>
Body: what changed, which App Store or Google Play rule it serves, files
touched, how to test it on a phone, and what is left for a human.
Mon WebView iOS est enfin approuvé. Merci !!
| Tâche | Touche à | Quand | Terminé quand |
|---|---|---|---|
| 0. Helper de plateforme | src/lib/platform.ts et les vérifications de user agent existantes | Seule, en premier | isNativeApp() existe, les vérifications en ligne sont remplacées, les tests passent |
| 1. Safe areas, zones tactiles, taille des champs | CSS global, composants de mise en page et de boutons | Vague 1 | Les barres fixes utilisent env(safe-area-inset-*), zones tactiles de 44 px ou plus, champs de 16 px ou plus, aucun débordement à 320 px |
| 2. Pages de confidentialité et de conditions | Nouvelles routes plus un lien dans le pied de page et un lien dans les réglages | Vague 1 | /privacy et /terms s'affichent comme de vraies pages et nomment les services que le code utilise réellement |
| 3. Suppression de compte | Écran des réglages, une nouvelle fonction serveur, /delete-account | Vague 1 | La suppression s'exécute côté serveur, déconnecte l'utilisateur et confirme ; la page publique explique les étapes |
| 4. Audit pour les stores (rapport uniquement) | Un seul nouveau fichier, STORE-AUDIT.md | Vague 1 | Chaque paiement, autorisation, fournisseur de connexion et lien externe est listé avec des références de fichiers |
| 5. États de chargement, vides et d'erreur | Hooks de données et composants de page | Vague 2 (partage des composants avec la tâche 1) | Aucun écran vide, un bouton pour réessayer sur chaque requête échouée, une error boundary globale |
| 6. Interface propre à l'app | Bannières, avis sur les cookies, en-tête desktop | Vague 2 (nécessite la tâche 0, chevauche la tâche 1) | Bannières de téléchargement et restes du site web masqués quand isNativeApp() est true |
| 7. Sign in with Apple, achats intégrés | Code d'authentification et de paiement | Plus tard, une à la fois | Planifiées à partir de l'audit ; nécessitent une configuration des consoles de votre part (prompts 6 et 7 ici) |
Copiez-le une fois par tâche et remplissez les crochets. La ligne de périmètre et la consigne « décrire au lieu de modifier » évitent les conflits ; la définition de « terminé » rend la pull request rapide à relire.
Tâche : [NOM DE LA TÂCHE DU TABLEAU, p. ex. « Safe areas, zones tactiles, taille des champs »] Contexte : lisez d'abord AGENTS.md. Cette app web s'exécute dans des apps natives iOS et Android créées avec WebViewGold, qui chargent notre URL de production dans une WebView. D'autres tâches Codex modifient en même temps d'autres parties de ce code. Périmètre : ne modifiez que [FICHIERS OU DOSSIERS]. Si la correction nécessite une modification hors de ce périmètre, ne la faites pas ; décrivez-la dans votre résumé. À ne pas faire : ajouter ou mettre à jour des dépendances, modifier les scripts de package.json, toucher au code d'authentification ou de paiement, éditer des fichiers générés, ou appeler des fonctionnalités natives autres que les schémas d'URL WebViewGold listés dans AGENTS.md. Définition de « terminé » : 1. [VÉRIFICATIONS CONCRÈTES, p. ex. chaque en-tête fixe, pied de page et feuille du bas a un padding avec env(safe-area-inset-top) / env(safe-area-inset-bottom) ; tous les boutons et liens font au moins 44x44 px ; tous les champs utilisent une font-size de 16 px ou plus ; aucun défilement horizontal à 320 px de largeur] 2. Les commandes de lint, de vérification des types et de test d'AGENTS.md passent dans cet environnement. 3. Rien ne change pour les utilisateurs d'un navigateur de bureau, à part la correction elle-même. Terminez par un résumé de pull request au format défini dans AGENTS.md, en indiquant comment tester la modification sur un téléphone et ce que vous n'avez pas pu faire.
Les paiements, les autorisations et les fournisseurs de connexion déterminent vos tâches suivantes, et les modifier à l'aveugle est risqué. Laissez une tâche les cartographier sans toucher au code ; elle peut tourner en parallèle sans risque, car elle ne fait qu'ajouter un fichier.
Ne modifiez aucun code dans cette tâche. Créez STORE-AUDIT.md à la racine du dépôt avec les sections suivantes, en citant les chemins de fichiers et les numéros de ligne pour chaque élément : 1. Paiements : chaque endroit où un utilisateur peut payer quelque chose. Pour chacun : route ou composant, ce qui est vendu, numérique ou physique, prestataire de paiement actuel, et s'il doit passer par l'achat intégré dans les apps natives iOS et Android (biens numériques, abonnements, crédits) ou peut rester sur Stripe (biens physiques, services dans le monde réel). 2. Autorisations : chaque autorisation du navigateur que demande l'app web (géolocalisation, caméra, microphone, notifications, presse-papiers), avec l'action de l'utilisateur qui la déclenche. 3. Connexion : chaque méthode de connexion et chaque fournisseur tiers, et si Sign in with Apple est proposé. 4. Liens externes : chaque lien qui quitte notre domaine depuis l'app. 5. Données de compte : où sont stockées les données des utilisateurs et s'il existe un parcours complet de suppression côté serveur. 6. Questions ouvertes auxquelles vous n'avez pas pu répondre à partir du code. La seule modification dans la pull request est le nouveau fichier STORE-AUDIT.md.
window.webkit.messageHandlers ou un objet window.WebViewGold imaginaire. Les fonctionnalités WebViewGold sont des schémas d'URL comme registerpush:// ou shareapp:// ; tout le reste ne fait rien dans l'app.OpenAI ne publie pas de chiffre fixe unique ; les limites d'utilisation dépendent de votre offre ChatGPT. En pratique, la limite, c'est votre capacité de relecture : trois à cinq petites tâches par vague, c'est ce qu'une personne peut relire correctement en un après-midi.
Oui. Chaque tâche travaille sur une copie de votre dépôt : l'AGENTS.md commité (et ceux imbriqués dans les sous-dossiers) s'applique exactement comme dans la CLI ou l'extension IDE. Les modifications locales non commitées ne sont pas visibles pour les tâches cloud.
Non. Elle exécute vos commandes de test dans son environnement, ainsi que les tests dans un navigateur si votre dépôt en contient et que le script d'installation les met en place. La vraie vérification, c'est le déploiement de prévisualisation sur votre téléphone et, avant la soumission, un build TestFlight ou de test interne.
Mergez la plus importante, puis demandez à Codex, dans l'autre tâche, de faire un rebase sur la branche main actuelle et de résoudre les conflits. Pour les petits diffs, il est souvent plus rapide de relancer cette tâche depuis une branche main à jour.
Pour ces tâches, c'est inutile. Les domaines du gestionnaire de paquets suffisent pour les installations ; un accès ouvert permet à une tâche de lire des pages non fiables et d'envoyer des données là où vous ne l'aviez pas prévu. N'ajoutez des domaines précis que lorsqu'un test en a vraiment besoin.
Elle peut modifier Config.swift et Config.java si le projet natif se trouve dans un dépôt, par exemple pour définir l'URL ou le marqueur du user agent. Elle ne peut ni compiler, ni signer, ni téléverser ; cela relève de Xcode, d'Android Studio ou du Cloud Builder.
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é par
Prix 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.