Vérifications automatiques de conformité App Store et Google Play sur chaque pull request avec Claude Code
Une fois votre app en ligne, chaque merge est une release, car les apps WebViewGold chargent votre URL de production. Un workflow GitHub Actions avec Claude Code peut passer en revue chaque pull request à la recherche des changements qui font refuser les apps basées sur le web, et vous le signaler avant le merge. Voici deux configurations complémentaires : un reviewer qui commente via l'action officielle, et un véritable garde-fou bâti sur le mode headless.
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
9:41
Votre app
Votre appDésormais dans votre poche
App Store · Google Play Approuvée
Pourquoi une app publiée a besoin d'une vérification des stores sur chaque PR
Avec une app WebViewGold, le binaire du store est une coque et votre web app est le produit. Une pull request qui ajoute un bouton Stripe sur l'écran des tarifs, supprime l'action Supprimer le compte ou livre un onglet « bientôt disponible » change ce que voient vos utilisateurs iOS et Android dès qu'elle est déployée. Elle change aussi ce que verra le reviewer lors de votre prochaine mise à jour native, car l'App Review teste l'app entière telle qu'elle est ce jour-là, pas votre diff.
La code review habituelle ne repère pas ce genre de chose, parce que le code est correct ; le problème, c'est une règle des stores. La vérification ci-dessous est donc volontairement étroite : elle ignore le style et l'architecture et ne cherche que les risques liés à l'App Store et à Google Play. Elle existe en deux variantes :
Commentaire : anthropics/claude-code-action@v1 passe le diff en revue et publie un seul commentaire sur la pull request. Consultatif, lisible et peu coûteux pour commencer.
Garde-fou : Claude Code en mode headless (claude -p) renvoie du JSON structuré, et le job échoue quand il trouve un blocker. Faites-en un status check obligatoire une fois que vous lui faites confiance.
Mise en place
Il vous faut un accès administrateur au dépôt et soit une clé d'API Claude, soit un jeton d'abonnement Claude.
Installez la Claude GitHub App et ajoutez un secret
Le plus rapide est /install-github-app dans Claude Code ; il faut pour cela la GitHub CLI, connectée avec gh auth login. À la main : installez la Claude GitHub App sur le dépôt et ajoutez ANTHROPIC_API_KEY (une clé d'API de la Claude Console) ou CLAUDE_CODE_OAUTH_TOKEN (créé avec claude setup-token) comme secret du dépôt.
Commitez les règles dont le reviewer a besoin
Claude Code lit CLAUDE.md à chaque exécution : le contexte natif et les règles des stores du modèle CLAUDE.md s'appliquent donc aussi en CI. Gardez le fichier court ; il est lu, et payé, à chaque exécution.
Ajoutez le workflow
Enregistrez le YAML ci-dessous sous .github/workflows/store-readiness.yml et adaptez la liste paths à vos dossiers.
Ouvrez une pull request de test
Ajoutez un lien « Acheter des crédits » codé en dur sur une page que voient les utilisateurs natifs. Le commentaire doit le signaler au titre d'Apple 3.1.1 et de la facturation Google Play. Fermez ensuite la pull request.
Ajoutez le garde-fou quand vous lui faites confiance
Ajoutez le job de garde-fou et son schéma JSON, laissez-le tourner à côté du commentaire pendant quelques semaines, puis marquez-le comme status check obligatoire dans vos règles de protection de branche.
Gardez des coûts prévisibles
Le workflow ignore les brouillons, ne tourne que pour les chemins pertinents, annule les exécutions dépassées et plafonne les tours et les minutes. Chaque exécution consomme des minutes GitHub Actions, plus des tokens d'API ou de l'usage d'abonnement.
Workflow 1 : un commentaire de conformité aux stores sur chaque pull request
Basé sur l'action officielle en mode automatisation : comme un prompt est défini, elle s'exécute sur chaque pull request correspondante sans que personne ait à taper @claude. Les outils autorisés sont en lecture seule, plus les commandes gh nécessaires pour lire le diff et publier un commentaire.
yaml
# .github/workflows/store-readiness.yml
name: Store readiness
on:
pull_request:
types: [opened, synchronize, ready_for_review, reopened]
paths:
- "src/**"
- "app/**"
- "public/**"
- "native/**"
- "CLAUDE.md"
concurrency:
group: store-readiness-${{ github.event.pull_request.number }}
cancel-in-progress: true
jobs:
review:
if: github.event.pull_request.draft == false
runs-on: ubuntu-latest
timeout-minutes: 20
permissions:
contents: read
pull-requests: write
issues: read
id-token: write
steps:
- uses: actions/checkout@v6
with:
fetch-depth: 1
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
prompt: |
REPO: ${{ github.repository }}
PR NUMBER: ${{ github.event.pull_request.number }}
This web app is also published as iOS and Android apps built with
WebViewGold. The apps load our production URL in a native WebView, so
every merged change is live in the store apps after the next deploy.
CLAUDE.md describes the native context and the store rules we follow.
Review only the changes in this pull request (gh pr diff) for App Store
and Google Play risks:
- digital goods, subscriptions, prices or external payment links that
are visible when isNativeApp() is true (Apple 3.1.1, Google Play billing)
- removed or broken /privacy, /terms, /delete-account or the in-app
Delete account action (Apple 5.1.1, Google Play account deletion)
- a new third-party login without Sign in with Apple (Apple 4.8)
- placeholder content, "coming soon", dead links, beta labels (Apple 2.1, 2.3)
- new data collection, SDKs or tracking the privacy policy does not
cover (Apple 5.1.1 and 5.1.2, Google Play Data safety)
- fixed bars without safe-area padding, tap targets under 44 px (Apple 4.0)
- user-generated content without report and block (Apple 1.2)
- under native/: URLs other than the production domain in Config.swift
or Config.java, new permissions, version and build numbers
Post exactly one comment with gh pr comment: a verdict line, then a table
with severity (blocker, risk, polish), rule, file:line and fix. If nothing
in the diff is store-relevant, post one line saying so. Skip general code
review feedback; another check handles that.
claude_args: |
--max-turns 25
--allowedTools "Read,Grep,Glob,Bash(gh pr diff *),Bash(gh pr view *),Bash(gh pr comment *)"
WebViewGold nous a permis d'avoir le temps de mise sur le marché le plus court et le plus efficace jamais possible parmi toutes les autres plates-formes d'application que nous avons essayées au cours des 5 dernières années. Je ne sais pas pourquoi je ne vous ai pas découvert plus tôt, mais je suis vraiment, vraiment content de l'avoir fait. Nous approchons actuellement les 6000 téléchargements d'application sur l'App Store iOS et Google Play Store sans aucun problème!
Workflow 2 : un garde-fou qui échoue sur les blockers
Ajoutez ce job sous jobs: dans le même fichier. Il installe Claude Code, envoie le diff de la pull request en mode headless et demande un JSON conforme à un schéma. --permission-mode dontAsk refuse tout ce qui nécessiterait une approbation : l'exécution peut lire des fichiers, mais pas les modifier. Le label store-review-ok permet à une personne de passer outre une fausse alerte : ajoutez le label, puis relancez le job.
yaml
# Second job in the same workflow file
gate:
if: github.event.pull_request.draft == false
runs-on: ubuntu-latest
timeout-minutes: 15
permissions:
contents: read
pull-requests: read
steps:
- uses: actions/checkout@v6
with:
fetch-depth: 0
- name: Install Claude Code
run: |
curl -fsSL https://claude.ai/install.sh | bash
echo "$HOME/.local/bin" >> "$GITHUB_PATH"
- name: Store-readiness gate
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
GH_TOKEN: ${{ github.token }}
PR: ${{ github.event.pull_request.number }}
BASE_REF: ${{ github.base_ref }}
run: |
# Human override: add the label, then re-run this job
if gh pr view "$PR" --json labels --jq '.labels[].name' | grep -qx 'store-review-ok'; then
echo "Label store-review-ok is set, skipping the gate."
exit 0
fi
git diff "origin/$BASE_REF...HEAD" | claude -p \
"The input is the diff of a pull request. This web app is also published as iOS and Android apps with WebViewGold, which load the production URL. Using the store rules in CLAUDE.md, report every change in this diff that would likely get the iOS or Android app rejected or removed. Only report findings you can tie to a file and line of the diff. Use severity blocker only for a likely rejection." \
--permission-mode dontAsk \
--allowedTools "Read,Grep,Glob" \
--max-turns 15 \
--output-format json \
--json-schema "$(cat .github/store-gate-schema.json)" > result.json
if ! jq -e '.structured_output' result.json > /dev/null; then
echo "::warning::The store gate returned no structured result; see the log."
exit 0
fi
jq '.structured_output' result.json
blockers=$(jq '[.structured_output.findings[] | select(.severity == "blocker")] | length' result.json)
if [ "$blockers" -gt 0 ]; then
echo "::error::$blockers store-review blocker(s). Fix them or add the store-review-ok label."
exit 1
fi
Le schéma JSON du garde-fou
Enregistrez-le sous .github/store-gate-schema.json. Le mode headless place le résultat conforme au schéma dans le champ structured_output de sa sortie JSON, que le workflow lit avec jq.
Un commentaire lisible avec un verdict et un tableau
Statut réussi ou échoué, JSON dans le log du job
Bloque le merge
Non
Oui, une fois défini comme status check obligatoire
Authentification
Claude GitHub App plus une clé d'API ou un jeton d'abonnement
Clé d'API en variable d'environnement
Idéal pour
Expliquer les risques à la personne qui a écrit la pull request
S'assurer que personne ne merge un blocker connu un jour de rush
Fausses alertes
Ignorez le commentaire
Corrigez le code, ou ajoutez le label store-review-ok et relancez
Laissez Claude Code écrire les workflows pour votre dépôt
Claude adapte le filtre paths à l'arborescence de vos dossiers et vous laisse vous occuper des secrets.
À coller dans Claude Code, à la racine de votre dépôt
Créez des workflows GitHub Actions pour une vérification de conformité aux stores sur les pull requests. Contexte : cette web app est aussi publiée sous forme d'apps iOS et Android avec WebViewGold, qui chargent notre URL de production ; chaque modification mergée est donc en ligne dans les apps des stores après le déploiement suivant. CLAUDE.md contient notre contexte natif et nos règles des stores.
1. .github/workflows/store-readiness.yml, déclenché sur pull_request (opened, synchronize, ready_for_review, reopened), qui ignore les brouillons, avec un groupe de concurrence par pull request et un filtre paths qui correspond à nos vrais dossiers de web app et de projets natifs (regardez d'abord l'arborescence du dépôt).
2. Job review : anthropics/claude-code-action@v1 avec un prompt qui ne passe en revue que les risques liés aux stores dans le diff (Apple 1.2, 2.1, 2.3, 3.1.1, 4.0, 4.2, 4.8, 5.1.1, 5.1.2 ; facturation Google Play, Data safety, suppression de compte, autorisations ; URL de production dans Config.swift et Config.java) et publie un seul commentaire avec gh pr comment. Outils autorisés : Read, Grep, Glob et les commandes gh pr diff, view et comment. 25 tours au maximum.
3. Job gate : installez Claude Code, envoyez le diff de la pull request dans claude -p avec --permission-mode dontAsk, --allowedTools "Read,Grep,Glob", --output-format json et --json-schema depuis .github/store-gate-schema.json. Le job échoue quand un constat a la gravité blocker ; il est ignoré quand la pull request porte le label store-review-ok.
4. Le fichier de schéma avec verdict et findings (severity, rule, file, line, fix).
Ne mettez aucun secret dans un fichier. Dites-moi quel secret de dépôt créer et comment faire du job gate un status check obligatoire.
Pièges
Tout lancer sur tout. Sans le filtre paths, l'exclusion des brouillons et le groupe de concurrence, un dépôt actif paie pour des reviews que personne ne lit.
Un prompt qui dérive vers la code review. Une vérification des stores qui commente aussi le nommage et les tests finit ignorée. Limitez-la aux règles des stores et laissez le reste à une review séparée.
Attendre qu'elle voie l'écran. Elle lit du code et des diffs. Les problèmes de mise en page sur un vrai téléphone, les premiers chargements lents et les parcours cassés exigent toujours un test sur appareil et la vérification de conformité sur votre URL de preview ou de production.
Rendre le garde-fou obligatoire dès le premier jour. La sortie du modèle varie d'une exécution à l'autre. Faites d'abord tourner le garde-fou en parallèle du commentaire, ajustez le prompt, puis rendez-le obligatoire.
Oublier ce que --bare laisse de côté.--bare rend les exécutions en CI reproductibles, mais ignore CLAUDE.md, les hooks et les skills. Si vous l'utilisez, passez vos règles avec --append-system-prompt-file.
Des règles périmées. La vérification n'est à jour que si CLAUDE.md l'est. Mettez-le à jour quand Apple ou Google changent une règle qui vous concerne ; le fichier du sous-agent de review demande le même soin.
Questions fréquentes
Dois-je utiliser une clé d'API ou mon abonnement Claude ?
Les deux fonctionnent avec l'action. ANTHROPIC_API_KEY facture l'usage de l'API sur votre compte Claude Console ; CLAUDE_CODE_OAUTH_TOKEN, créé avec claude setup-token, utilise un forfait Claude payant. Pour un dépôt partagé par plusieurs personnes, une clé d'API est le choix le plus propre, car le jeton est lié à une seule personne.
L'action lit-elle CLAUDE.md et le reste de .claude/ ?
Elle exécute Claude Code dans le dépôt récupéré : CLAUDE.md s'applique donc à chaque exécution, et un skill de projet peut être lancé en passant /nom-du-skill comme prompt. Les mêmes règles servent à vos sessions locales et à la CI.
Existe-t-il une option sans écrire de YAML ?
Anthropic propose aussi Code Review, qui passe en revue les pull requests automatiquement, sans fichier de workflow. C'est un reviewer généraliste : les règles propres aux stores doivent donc toujours vivre dans CLAUDE.md pour qu'il les applique.
Combien coûte une exécution ?
Cela dépend de la taille du diff et du nombre de fichiers que le reviewer ouvre. La limite de tours, le filtre paths et le timeout plafonnent le pire cas, et la sortie JSON du mode headless inclut un coût estimé par exécution que vous pouvez journaliser.
Cela peut-il tourner sur GitLab ?
Claude Code dispose aussi d'une intégration GitLab CI/CD, et le garde-fou headless fonctionne dans tout système de CI capable de lancer une commande shell avec la clé d'API définie. L'action elle-même est réservée à GitHub.
Repérera-t-il toutes les raisons de refus ?
Non. Il repère ce qui est visible dans un diff. Les notes pour la validation, les captures d'écran, les questionnaires de confidentialité et le comportement sur appareil ont toujours besoin de vous, et le sous-agent de review est le meilleur outil pour un audit complet avant soumission.
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.
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.
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.
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.