Directives de révision 2026 : checklist de première soumission Apple et Google Play

Réponse rapide : Guide de révision d'app sont les règles imposées par Apple et Google avant la publication de votre application. Celles d'Apple Directives d'examen de l'App Store sont organisées en Sécurité, Performance, Business, Design et Juridique. Google Play examine votre release par rapport aux politiques du Developer Program plus les exigences de la Play Console, comme la classification du contenu et la sécurité des données. Délais d'examen : Apple précise que l'App Review fonctionne 24h/24 et traite généralement au moins 50 % des soumissions sous 24 heures et 90 % sous 48 heures (Examen de l'app). Google indique que certains comptes peuvent attendre jusqu'à sept jours ou plus dans des cas exceptionnels (Publiez votre app). Les nouveaux comptes personnels Play Console peuvent aussi nécessiter au moins 12 testeurs qui restent inscrits en continu pendant 14 jours consécutifs en test fermé, avec au moins 12 ont encore accepté lors de votre demande de production. Premiers refus de l'app proviennent souvent de 2.1 Exhaustivité de l'app (crashs, liens morts, comptes de démo invalides), 2.3 Métadonnées précises, et 5.1 Confidentialité sur iOS, ou des politiques Play incomplètes ou des étapes de test sur Android. Pour les directives 4.2 et 4.3 stratégie, lisez comment réussir la review de l'App Store en 2026. Pour les notes et le contrôle parental, consultez le guide des classifications d'âge de l'app store. Pour les frais d'inscription, consultez coût pour publier une app sur l'App Store.

Soumettre votre première app sur l'App Store ou le Play Store peut sembler intimidant. Entre des directives en constante évolution et un contrôle plus strict en 2026, faire approuver votre app demande une attention particulière aux détails. Cette checklist vous explique ce que les reviewers vérifient lors d'une première soumission, sur iOS comme sur Android, avec des playbooks détaillés sur les rejets Apple dans notre comment réussir la review de l'App Store en 2026 guide lorsque vous avez besoin de détails plus approfondis que ce simple aperçu.

Comprendre le processus de revue en 2026

Apple et Google ont considérablement renforcé leurs processus de review ces dernières années, en mettant l'accent sur la confidentialité, la sécurité et l'expérience utilisateur. Comprendre ces changements est crucial pour les développeurs qui débutent.

Délais de revue de l'App Store iOS

Apple publie les délais sur sa App Review page :

• Délais typiques : au moins 50 % des soumissions sont examinées en moins de 24 heures, et 90 % en moins de 48 heures
• Soumissions incomplètes: La revue peut être retardée ou échouer si les métadonnées, l'accès à la démo ou les réponses de conformité sont manquants
• Applications complexes: Apple notes that apps needing greater scrutiny can take longer (Après la soumission)
• Revue accélérée: Disponible pour les correctifs de bugs critiques ou les événements limités dans le temps après soumission via App Store Connect et envoi de la requête via le formulaire de demande de revue accélérée d'Apple

Prévoyez les moyennes de publication, et non les pics de file d'attente anecdotiques, et considérez chaque note de revue manquante comme un risque de retard.

Les statuts App Store Connect que vous verrez

• Préparer la soumission: Votre build ou vos métadonnées sont encore en cours de préparation
• En attente de revue: Apple a placé votre soumission en file d'attente
• En cours de revue: L'équipe de revue examine activement l'app
• Release développeur en attente: Approuvée, mais en attente de votre choix de publication manuelle
• Refusée / Problèmes non résolus: Apple demande des modifications avant approbation

Délais de revue du Google Play Store (mise à jour 2026)

Google indique les délais de revue Publier votre app:

• Publication standard: Les mises à jour sont traitées et publiées dès que possible après examen
• Examen prolongé: Pour certains comptes développeurs, Google peut prendre jusqu'à sept jours, voire plus dans certains cas exceptionnels
• Phase de test fermé: Les comptes personnels créés après le 13 novembre 2023 nécessitent au moins 12 testeurs qui doivent rester inscrits en continu pendant au moins 14 jours consécutifs de test fermé, et au moins 12 testeurs doivent toujours être inscrits au moment de votre demande d'accès à la production
• Après les tests: L'examen de production vérifie toujours la conformité aux règles du Play Store avant la mise en ligne

Mise à jour importante: Google exige désormais des tests bien plus rigoureux pour certains nouveaux comptes Play Console, ce que nous détaillons ci-dessous.

Configuration du compte Apple Developer

Avant votre première release iOS, vérifiez que tout est correctement configuré côté Apple :

• Inscrivez-vous à l' Apple Developer Program
• Activez l'authentification à deux facteurs pour le compte Apple utilisé lors de l'inscription
• Choisissez le bon type d'adhésion :
  • Individuel / Entrepreneur individuel: votre nom légal devient le nom du vendeur sur l'App Store
  • Organisation: nécessite une entité juridique, un numéro D-U-N-S, un site web public et une personne habilitée à engager l'entreprise dans les accords Apple
• Utilisez des noms légaux lors de l'inscription. Les pseudonymes ou noms de société dans les champs nom/prénom peuvent retarder l'approbation
• Une fois l'inscription approuvée, connectez-vous à App Store Connect et créez la fiche de l'app avec le bundle ID final, le nom de l'app, le SKU et la langue principale

Important: Apple modifie les exigences minimales de SDK au fil du temps. À partir de 28 avril 2026, les apps envoyées sur App Store Connect doivent utiliser iOS & iPadOS 26 SDK ou ultérieur.

L'exigence critique des tests Android

C'est le changement qui surprend la plupart des éditeurs Android débutants :

Les 12 testeurs requis pour les nouveaux comptes Android personnels

Si votre compte développeur Google Play est un compte personnel créé après le 13 novembre 2023, vous devez passer par une période de test fermé avant que l'application puisse passer en production :

Prérequis:

• 12 testeurs minimum: Vous devez avoir au moins 12 testeurs qui restent inscrits en continu
• Période de test de 14 jours: Ces testeurs doivent rester inscrits pendant que l'app est en test fermé pendant au moins 14 jours consécutifs
• Demande d'accès à la production: Lors de votre demande, au moins 12 testeurs doivent toujours être inscrits après la période de test fermé
• Collecte de retours: You should document the issues found, fixes made, and how testers used the app

Comment configurer votre canal de test

Pourquoi Google a instauré cette règle

Google a instauré cette exigence pour :

• Réduire le spam d'applications de faible qualité
• Assurez-vous que vos apps sont bien testées avant d'atteindre les utilisateurs
• Identifiez les apps malveillantes via les modèles d'utilisation réels
• Améliorez la qualité globale du Play Store

Le retour à la réalité: Cela ajoute au moins 2 à 3 semaines à votre calendrier de lancement. Prévoyez en conséquence et commencez à recruter des testeurs tôt.

Exigences d'authentification et de connexion

L'une des raisons de rejet les plus fréquentes est l'implémentation incorrecte des systèmes d'authentification, surtout le social login.

L'exigence Apple Sign-In (critique pour iOS)

La règle d'Apple: Si votre app propose une option de social login tierce (Google, Facebook, Twitter, etc.), vous devez proposez également Sign in with Apple comme option.

Ceci s'applique à:

• Google Sign-In
• Connexion Facebook
• Connexion avec Twitter/X
• Connexion avec LinkedIn
• Tout autre service d'authentification tiers

Ceci ne s'applique PAS à:

• Authentification par e-mail/mot de passe uniquement
• Les systèmes d'identité gouvernementaux
• Les systèmes SSO d'entreprise (quand l'app est dédiée à cette entreprise)
• Les systèmes d'authentification des organismes d'éducation

Implémenter Sign in with Apple

Si vous utilisez le social login, voici ce que vous devez implémenter :

import { SignInWithApple } from '@capacitor-community/apple-sign-in';

async function signInWithApple() {
  try {
    const result = await SignInWithApple.authorize({
      clientId: 'com.yourapp.service',
      redirectURI: 'https://yourapp.com/auth/callback',
      scopes: 'email name',
      state: '12345',
      nonce: 'nonce',
    });

    // result contains:
    // - identityToken
    // - authorizationCode
    // - email (may be null if user previously authorized)
    // - givenName
    // - familyName

    // Send to your backend for verification
    await verifyAppleToken(result.identityToken);

  } catch (error) {
    console.error('Apple Sign In failed:', error);
  }
}

Considérations importantes:

1. Confidentialité de l'e-mail: Les utilisateurs peuvent choisir de masquer leur e-mail. Apple fournit un e-mail de relais privé (ex : abc123@privaterelay.appleid.com). Votre application doit savoir gérer cela.

2. Nouveaux utilisateurs vs utilisateurs récurrents: Apple ne fournit les détails de l'utilisateur (nom, e-mail) que lors de la première autorisation. Stockez ces informations car les connexions suivantes ne les incluront pas.

3. Design du bouton: Apple impose des directives de design strictes pour le bouton Sign in with Apple. Utilisez leurs assets officiels.

4. Vérification backend: Vérifiez toujours l'identity token sur votre serveur backend, ne faites jamais confiance aux tokens côté client seuls.

Exigences de Social Login sur Android

Bien qu'Android n'exige pas de fournisseur spécifique comme iOS, Google a des directives :

Prérequis pour Google Sign-In:

• Doit utiliser l'SDK officiel de Google Sign-In
• Doit respecter les directives de branding de Google
• Devrait être l'option principale si vous la proposez

Bonne pratique pour le multiplateforme: Proposez les mêmes options de connexion sur les deux plateformes pour rester cohérent :

• E-mail/mot de passe
• Se connecter avec Apple (iOS uniquement, ou sur Android si vous supportez la connexion Apple via le web)
• Se connecter avec Google
• Autres options de connexion sociale (Facebook, Twitter, etc.)

Exigences pour les comptes de démo

Crucial pour la review: Si votre app nécessite un login, vous devez fournir des identifiants de démo fonctionnels dans les notes de l'App Review.

Demo Account Information:

Username: reviewer@demo.com
Password: ReviewTest123!

OR

Test Phone: +1 555-0123
Test OTP: 123456 (static for review)

Notes:
- This account has full premium features enabled
- All payment flows work in sandbox mode
- Account will reset daily

Erreurs courantes:

• Fournir des identifiants expirés
• Le compte de démo n'a pas accès à toutes les fonctionnalités
• Oublier de préciser comment contourner la vérification par téléphone
• Oublier de mentionner les détails des paiements sandbox

Politique de confidentialité et exigences légales

Les deux stores exigent désormais des politiques de confidentialité et des conditions d'utilisation accessibles avant votre première soumission est approuvée.

Exigences pour la politique de confidentialité

Votre politique de confidentialité doit :

1. Être accessible publiquement

   • Être hébergée sur une URL publique (sans authentification)
   • Être consultable via un navigateur web standard
   • Être disponible dans les mêmes langues que votre app

2. Couvrir ces sujets obligatoires:

   • Quelles données vous collectez (soyez précis)
   • Comment vous utilisez les données collectées
   • Si les données sont partagées avec des tiers
   • Durée de conservation des données
   • Droits des utilisateurs (accès, suppression, portabilité)
   • Contact pour les questions de confidentialité
   • Confidentialité des enfants (si l'app cible les < 13/16 ans)

3. Lien direct dans l'application

   • Accessible via les réglages ou le compte
   • Doit être accessible en un clic (pas caché dans les menus)
   • Doit s'ouvrir dans le navigateur par défaut ou l'in-app browser

Où héberger votre politique de confidentialité

Option 1 : Votre site web (Recommandé)

https://yourapp.com/privacy-policy
https://yourapp.com/terms-of-service

Option 2 : Pages GitHub (Gratuit)

https://yourusername.github.io/app-privacy-policy

Option 3: Privacy Policy Generators (Démarrage rapide)

• Termly
• PrivacyPolicies.com
• FreePrivacyPolicy.com

Important: Les générateurs sont un bon point de départ, mais assurez-vous que la politique reflète fidèlement vos pratiques réelles en matière de données. Les modèles génériques qui ne correspondent pas à votre application seront signalés.

Exigences pour les conditions générales

Bien que ce ne soit pas toujours obligatoire, avoir des conditions générales est fortement recommandé et requis si :

• Vous proposez des achats in-app ou des abonnements
• Vous avez du contenu généré par les utilisateurs
• Vous fournissez un service au-delà des fonctionnalités de base de l'app
• Vous souhaitez une protection juridique

Doit inclure:

• Politique d'utilisation acceptable
• Conditions de résiliation du compte
• Limitation de responsabilité
• Droits de propriété intellectuelle
• Processus de résolution des litiges
• Politique de remboursement (notamment pour les IAP)

Implémentation dans l'application

// Settings or Account Screen
function LegalLinks() {
  return (
    <div className="legal-section">
      <h3>Legal</h3>
      <a
        href="https://yourapp.com/privacy-policy"
        target="_blank"
        rel="noopener noreferrer"
      >
        Privacy Policy
      </a>
      <a
        href="https://yourapp.com/terms-of-service"
        target="_blank"
        rel="noopener noreferrer"
      >
        Terms of Service
      </a>
      <a
        href="https://yourapp.com/contact"
        target="_blank"
        rel="noopener noreferrer"
      >
        Contact Us
      </a>
    </div>
  );
}

Exigences relatives aux métadonnées de l'App Store

Les deux stores exigent que vous fournissiez l'URL de la politique de confidentialité lors de la publication de l'app :

iOS - App Store Connect:

• Informations sur l'app > Informations générales > URL de la politique de confidentialité
• Doit être en HTTPS (le HTTP sera rejeté)
• Sera affiché sur votre page App Store
• Ajoutez une URL de support avec de vraies coordonnées pour les utilisateurs
• Complétez le questionnaire de classification d'âge avant la soumission

Android - Google Play Console:

• Présence sur les stores > Paramètres du store > Politique de confidentialité
• Requis pour toutes les apps ciblant les enfants
• Fortement recommandé pour toutes les apps

Étiquettes de confidentialité (iOS)

iOS exige des informations détaillées sur la confidentialité au format « étiquette nutritionnelle » :

Catégories à déclarer:

• Infos de contact: e-mail, nom, numéro de téléphone
• Informations financières: infos de paiement, carte bancaire, compte bancaire
• Localisation: localisation précise ou approximative
• Contenu utilisateur: photos, vidéos, audio, messages
• Identifiants: ID utilisateur, ID appareil, ID publicitaire
• Usage Data: interaction produit, données publicitaires, logs de crash
• Diagnostics: Données de crash, données de performance

Pour chaque type de données, précisez:

• Si elle est collectée
• Si elle est liée à l'identité de l'utilisateur
• Si elle est utilisée pour le tracking
• La finalité de la collecte

Erreur courante: Dire que vous ne collectez pas de données alors que votre SDK le fait. Auditez tous les SDK tiers pour vérifier ce qu'ils collectent.

Section sécurité des données de Google Play

Comme sur iOS, Android exige une déclaration de sécurité des données :

Étapes:

1. Allez dans Play Console > Contenu de l'application > Sécurité des données
2. Répondez aux questions sur la collecte de données
3. Précisez les types de données collectées
4. Expliquez vos pratiques de sécurité (chiffrement, etc.)
5. Fournir le lien vers la politique de confidentialité

Critique: Ces informations sont juridiquement contraignantes. Toute fausse déclaration peut entraîner le retrait de l'application et la suspension du compte.

Motifs courants de rejet initial

Comprendre pourquoi les apps sont rejetées vous aide à éviter ces pièges :

1. L'application plante ou ne se lance pas

Pourquoi cela arrive:

• Tests uniquement sur émulateur, pas sur appareil réel
• Absence de gestion d'erreurs pour les échecs réseau
• Endpoints API codés en dur et inaccessibles
• Hypothèse de capacités spécifiques (caméra, GPS)

Comment l'éviter:

// Always implement proper error handling
async function loadData() {
  try {
    const response = await fetch('https://api.yourapp.com/data');

    if (!response.ok) {
      throw new Error(`HTTP ${response.status}`);
    }

    const data = await response.json();
    return data;

  } catch (error) {
    // Show user-friendly error
    showError('Unable to load data. Please check your connection.');

    // Log for debugging
    console.error('Data load failed:', error);

    // Graceful degradation
    return getCachedData();
  }
}

Checklist de test:

• Tester sur des appareils réels (min. 2-3 modèles différents)
• Tester avec un réseau instable (via Network Link Conditioner)
• Tester en mode avion
• Tester avec les permissions refusées
• Tester avec une installation fraîche (sans données en cache)

2. Fonctionnalités clés manquantes ou défectueuses

Pourquoi cela arrive:

• Features shown in screenshots don’t exist yet
• Le compte de démo n'a pas accès aux fonctionnalités annoncées
• Les fonctionnalités premium sont affichées mais non implémentées
• Placeholders « Coming Soon » dans l'app

Comment l'éviter:

• Ne soumettez l'app que lorsque toutes les fonctionnalités annoncées sont prêtes
• Make sure demo account has full access
• Supprimez ou désactivez les fonctionnalités incomplètes avant la soumission
• Update screenshots to match current build exactly

3. Contenu inapproprié pour la classification d'âge

Pourquoi cela arrive:

• Classification d'âge fixée à 4+ alors que l'app contient des fonctions sociales
• La classification d'âge ne correspond pas au contenu réel
• Contenu généré par les utilisateurs sans modération
• Liens vers du contenu externe non modéré

Comment définir la bonne classification d'âge:

Classifications d'âge iOS:

• 4+ (aucun contenu inapproprié)
• 9+ (contenu léger occasionnel)
• 12+ (contenu modéré)
• 17+ (contenu intense ou fréquent)

Classifications de contenu Android:

• Tout public
• Tout public 10+
• Adolescents
• Mature 17+
• Adultes uniquement 18+

Important: Si les utilisateurs peuvent partager du contenu entre eux, vous devez avoir :

• Un système de modération de contenu
• Une fonctionnalité de signalement/blocage
• Des règles de communauté claires
• Un contrôle de l'âge si nécessaire

4. Métadonnées trompeuses ou mensongères

Pourquoi cela arrive:

• Le nom de l'app promet des fonctionnalités inexistantes
• Captures d'écran de concurrents ou maquettes
• Faux avis ou manipulation des notes
• Description contenant des superlatifs sans preuve

Exemples de métadonnées problématiques:

❌ MAUVAIS:

• Nom de l’app : « Best Fitness Tracker - #1 App »
• Description : « L’app la plus incroyable et révolutionnaire jamais créée ! »
• Captures d’écran : photos de stock génériques

✅ BON:

• Nom de l’app : « FitTrack - Workout Logger »
• Description : « Suivez vos entraînements avec des routines personnalisables et des graphiques de progression. »
• Captures d’écran : écrans réels de l’app issus du build actuel

5. Tests insuffisants (surtout les tests fermés sur Android)

Pourquoi cela arrive:

• Sauter la période de test obligatoire de 14 jours
• Ne pas recruter assez de testeurs
• Les testeurs n'utilisent pas vraiment l'app
• Aucun monitoring des crashs pendant les tests

Comment l'éviter:

• Commencez à recruter des testeurs 3 à 4 semaines avant le lancement prévu
• Utilisez Firebase Crashlytics ou un outil similaire pendant les tests
• Engagez-vous activement auprès des testeurs (sondages, formulaires de feedback)
• Corrigez les problèmes critiques avant le passage en production

6. Permissions sans justification

Pourquoi cela arrive:

• Demander la localisation sans l'utiliser
• Permission caméra sans explication
• Accès aux contacts sans but précis
• Localisation en arrière-plan pour les apps hors navigation

Comment corriger:

iOS - Info.plist:

<key>NSCameraUsageDescription</key>
<string>Camera access is required to scan QR codes for quick login.</string>

<key>NSLocationWhenInUseUsageDescription</key>
<string>Location helps us show nearby fitness centers and outdoor running routes.</string>

<key>NSPhotoLibraryUsageDescription</key>
<string>Photo library access lets you upload a profile picture and share workout photos.</string>

Android - Stratégie de permissions:

<!-- Only request what you actually need -->
<uses-permission android:name="android.permission.CAMERA" />

<!-- Use when-in-use rather than always for location -->
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

<!-- Avoid if possible -->
<!-- <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" /> -->

Demande de permission au runtime:

import { Camera } from '@capacitor/camera';

async function takePicture() {
  // Request with context
  const permissionStatus = await Camera.requestPermissions();

  if (permissionStatus.camera === 'granted') {
    const photo = await Camera.getPhoto({
      quality: 90,
      allowEditing: true,
      resultType: 'uri'
    });

    return photo;
  } else {
    // Explain why permission is needed
    showDialog(
      'Camera access required',
      'To upload a profile picture, please enable camera access in Settings.'
    );
  }
}

Exigences spécifiques à iOS

Captures d'écran et aperçus App Store

Tailles requises:

• iPhone 6,7” : 1290 x 2796
• iPad 13” : 2064 x 2752
• iPad 12,9” : 2048 x 2732

Important: Si votre app est compatible iPad, vous devez envoyer des captures d'écran iPad. Ne pas étirer les captures iPhone pour les adapter aux formats iPad.

Bonnes pratiques pour les captures d'écran:

• Doivent montrer le contenu réel de l'app (pas de mockups)
• Supprimez la barre d'état ou affichez un contenu réaliste
• Localisez pour toutes les langues supportées
• Évitez les superpositions de texte excessives
• Montrez les fonctionnalités clés dès les 2-3 premières captures

Configuration des métadonnées App Store Connect

Avant la soumission, complétez ces champs App Store Connect :

• URL de politique de confidentialité: requis pour les apps iOS
• URL de support: requis, et doit mener à des coordonnées réelles
• Age Rating: complétez le questionnaire pour pouvoir publier l'app
• Informations pour l'examen de l'app: ajoutez un contact pour la review, des identifiants de démo fonctionnels si un login est requis, et des notes claires pour l'équipe de review
• Conformité à l'exportation: répondez aux questions sur le chiffrement, ou configurez ITSAppUsesNonExemptEncryption dans Info.plist le cas échéant pour ne pas répéter les mêmes réponses à chaque upload

TestFlight avant la revue de l'app

Effectuez un véritable passage sur TestFlight avant la revue de production :

• Installez le build exact depuis TestFlight
• Connectez-vous avec le même compte de revue que celui que vous prévoyez de fournir
• Testez les parcours d'achat, de restauration et d'annulation
• Confirmez que le relecteur accède aux fonctionnalités clés sans configuration cachée
• Testez sur iPhone et iPad si les deux sont supportés

Vidéos d'aperçu de l'app (optionnel mais recommandé)

Prérequis:

• Durée de 15 à 30 secondes
• Doit montrer l'application en action
• Peut inclure de courts textes en superposition
• Pas de musique avec des problèmes de droits d'auteur
• Même résolution que les captures d'écran

Implémentation de Sign in with Apple

Déjà mentionné plus haut, mais crucial pour la revue iOS si vous utilisez le social login.

Exigences pour les achats in-app

Si vous proposez des biens ou services numériques :

Déclarations obligatoires:

• Prix clair avant l'achat
• Conditions d'abonnement clairement indiquées
• Instructions d'annulation visibles
• Bouton restaurer les achats

Exemple d'écran d'abonnement conforme:

function SubscriptionOffer() {
  return (
    <div className="subscription-screen">
      <h2>Choose Your Plan</h2>

      <PlanCard>
        <h3>Monthly</h3>
        <p className="price">$9.99/month</p>
        <ul>
          <li>Unlimited workouts</li>
          <li>Personalized plans</li>
          <li>Progress tracking</li>
        </ul>
        <button>Subscribe</button>
      </PlanCard>

      <PlanCard>
        <h3>Annual</h3>
        <p className="price">$79.99/year</p>
        <p className="savings">Save 33%</p>
        <ul>
          <li>Everything in Monthly</li>
          <li>Priority support</li>
        </ul>
        <button>Subscribe</button>
      </PlanCard>

      <div className="subscription-terms">
        <p>
          Subscription automatically renews unless cancelled at least
          24 hours before the end of the current period. Manage your
          subscription in Settings.
        </p>
        <button onClick={restorePurchases}>Restore Purchases</button>
      </div>

      <div className="legal-links">
        <a href="/privacy/">Privacy Policy</a> |
        <a href="/terms">Terms of Service</a>
      </div>
    </div>
  );
}

Exigences spécifiques à Android

Configuration du compte Google Play Console

Avant votre première release Android, assurez-vous que le compte Play Console et l'app shell existent :

• Créez votre compte développeur sur Inscription Play Console
• Dans la Play Console, allez sur Accueil &gt; Créer une application
• Choisissez la langue par défaut, le type d'app/jeu et l'e-mail de support
• Acceptez la politique Play requise, exportez et remplissez les déclarations de Play App Signing
• Déterminez si l'application est gratuit ou payant

Important: Google vous permet de passer une application payante en gratuite plus tard, mais une fois qu'une application a été proposée gratuitement, elle ne peut plus redevenir payante.

Exigence de l'App Bundle

Important: Google Play exige le format Android App Bundle (.aab), pas l'APK :

# Sync the native Android project first
bunx cap sync android

# Then build the release app bundle
cd android
./gradlew bundleRelease

Niveau API cible requis

Exigence actuelle: Les nouvelles apps et les mises à jour doivent cibler Android 15 (API niveau 35) ou supérieur.

Modification dans android/app/build.gradle:

android {
    compileSdkVersion 35

    defaultConfig {
        targetSdkVersion 35
        minSdkVersion 23  // Minimum supported version
    }
}

Sécurité des données Google Play

Déjà mentionné plus haut, mais absolument crucial pour l'approbation Android.

Canal de test fermé (exigence actuelle)

C'est le point majeur pour les nouveaux comptes développeurs personnels : l'exigence des 12 testeurs en opt-in continu pendant 14 jours, détaillée plus haut dans ce guide.

Calendrier:

1. Semaine 1 : recruter les testeurs, configurer le test fermé
2. Semaines 2-3 : période de test active (14 jours minimum)
3. Semaine 4 : corriger les bugs, préparer la release de production
4. Semaine 5 : soumettre à l'examen de production

Audience cible et classification du contenu

Questionnaire de classification du contenu:

• Requis pour toutes les apps
• Prend 10 à 15 minutes à remplir
• Détermine la classification d'âge (Tout public, Adolescent, Adulte, etc.)
• Mettez-l’à jour dès que votre contenu change d'une manière qui affecte les réponses

Sujets abordés:

• Violence
• Contenu sexuel
• Grossièretés
• Substances contrôlées
• Jeux d'argent
• Fonctionnalités d'interaction utilisateur

Important: Si vous proposez du contenu généré par les utilisateurs ou des fonctions sociales, vous devez le signaler et mettre en place une modération.

Exigences de la fiche store

Assets requis:

• Icône de l'app (512 x 512 PNG)
• Image de présentation (1024 x 500 JPG ou PNG)
• Captures d'écran téléphone (2 minimum, 8 maximum)
• Captures d'écran tablette 7” (optionnelles mais recommandées)
• Captures d'écran tablette 10” (optionnelles mais recommandées)

Exigences de la description:

• Description courte (80 caractères max)
• Description complète (4000 caractères max)
• Doit décrire précisément les fonctionnalités de l'app
• Ne doit pas inclure de coordonnées ni de tarifs

Checklist pré-soumission

Avant de soumettre votre application, passez en revue cette checklist complète :

Exigences techniques

• L'application se lance correctement sur des appareils réels
• All features shown in screenshots work
• No placeholder or “Coming Soon” content
• Toutes les clés API tierces sont des clés de production
• La gestion des erreurs réseau est implémentée
• Les demandes de permissions incluent des explications claires
• L'application ne crash pas en cas de mauvaise connexion
• Testée avec les permissions refusées
• Testée sur la version minimale de l'OS supportée
• Fuites de mémoire vérifiées et corrigées

Authentification et connexion

• Si vous utilisez le social login, Sign in with Apple est inclus (iOS)
• Identifiants de compte démo fournis dans les notes de review
• Le compte démo a accès à toutes les fonctionnalités
• Le flux de réinitialisation de mot de passe fonctionne
• Logout functionality works correctly
• Option de suppression de compte disponible (requis par le RGPD/CCPA)

Mentions légales et confidentialité

• Politique de confidentialité accessible au public
• URL de la politique de confidentialité ajoutée à la fiche du store
• Conditions d'utilisation accessibles publiquement (si applicable)
• Politique de confidentialité liée dans l'app (écran Paramètres)
• Étiquettes de confidentialité exactes (iOS)
• Section sécurité des données complétée (Android)
• Toutes les finalités de collecte de données expliquées
• Collecte de données SDK par des tiers divulguée

Contenu et métadonnées

• Nom de l'app conforme aux règles (pas de bourrage de mots-clés)
• Description fidèl’aux fonctionnalités
• Captures d'écran montrant l'app actuelle
• Captures d'écran localisées pour toutes les langues supportées
• Aucune mention de concurrent dans la description
• Aucun superlatif sans preuve
• La classification d'âge correspond au contenu
• L'e-mail de contact est surveillé

Spécifique à iOS

• Sign in with Apple implémenté (si vous utilisez le social login)
• Toutes les tailles de captures d'écran requises fournies
• Captures d'écran iPad réelles envoyées si le support iPad est activé
• Les descriptions des permissions dans Info.plist sont claires
• URL de support ajoutée avec de vraies coordonnées
• Privacy Policy URL added in App Store Connect
• Questionnaire de classification d'âge complété
• Conformité à l'exportation correctement renseignée
• Contact pour l'App Review et compte démo permanent fournis
• Cible iOS 15.0 ou supérieur
• Si IAP : tarifs clairs, bouton de restauration des achats présent
• Aucune référence à Android ni à d'autres plateformes

Spécifique à Android

• Format App Bundle (.aab) utilisé
• Cible API 35 ou supérieur
• Questionnaire de classification du contenu rempli
• Graphique de présentation envoyé
• Tests fermés terminés si votre compte Play Console l'exige (12 testeurs inscrits en continu pendant 14 jours consécutifs, avec au moins 12 toujours inscrits au moment de la demande)
• Rapports de crash des tests examinés et corrigés
• Aucune référence à iOS ni à d'autres plateformes

Tests (exigence actuelle d'Android)

• 12 testeurs ou plus recrutés si votre compte Play exige des tests fermés
• Canal de tests fermés créé
• Plus de 12 testeurs sont restés inscrits pendant 14 jours consécutifs et au moins 12 l'étaient encore lors de votre demande
• Les testeurs ont réellement utilisé l'app (pas seulement installé)
• Surveillance des crashs activée pendant les tests
• Bugs critiques identifiés lors des tests corrigés
• Retours des testeurs documentés

Notes de révision : quoi inclure

De bonnes notes de révision peuvent faire la différence entre une approbation immédiate et un rejet. Voici ce qu'il faut inclure :

Modèle pour les notes de révision

APP REVIEW INFORMATION

=== Test Account ===
Email: reviewer@testapp.com
Password: TestReview123!
(This account has all premium features enabled)
(This account stays active during review)

=== Review Contact ===
Name: Jane Developer
Email: review@yourapp.com
Phone: +1 555-0100

=== Testing Instructions ===
1. Launch app and tap "Sign In"
2. Enter test credentials above
3. Navigate to "Dashboard" to see main features
4. Tap "Upgrade" to test subscription flow (sandbox mode)
5. Go to Settings > Account to see privacy policy and terms

=== Key Features to Test ===
- Workout tracking (tap "New Workout" on Dashboard)
- Progress charts (Analytics tab)
- Social sharing (Share button on workout details)
- Camera upload for profile picture (Settings > Profile)

=== Third-Party Services ===
- Firebase Authentication (for login)
- Stripe (for payments - sandbox mode)
- AWS S3 (for image uploads)
- Google Maps SDK (for location features)

=== Notes ===
- Location permission is optional, app works without it
- Camera permission only requested when uploading profile picture
- All subscription flows use Apple/Google sandbox environments
- Background location is not used
- Support URL and privacy policy are available from Settings > Account

=== Contact ===
For questions: developer@yourapp.com
Response time: Within 24 hours

Notes de révision spécifiques à iOS

Pour iOS, incluez également :

=== Device Coverage ===
Tested on: iPhone 15 Pro Max, iPad Pro 13-inch

=== App Store Connect Metadata ===
Support URL: https://yourapp.com/support
Privacy Policy: https://yourapp.com/privacy-policy

=== Submission Notes ===
- iPad screenshots match the current iPad UI
- Export compliance answered for this build
- Sign in with Apple is available on the login screen

Notes de revue spécifiques à Android

Pour Android, incluez également :

=== Testing Track Information ===
Closed testing period: [Start Date] to [End Date]
Number of active testers: 23
Critical issues found during testing: 2 (both fixed)
Test distribution method: Email invite list

=== Crash Data ===
Testing period crashes: 3 total
Crash rate: 0.8%
All crashes fixed in this build

=== API Levels ===
Target SDK: 35 (Android 15)
Min SDK: 23 (Android 6.0)
Tested on: Android 11, 12, 13, 14, 15

Que faire en cas de refus

Pas de panique : le rejet est courant, surtout lors d'une première soumission. Voici comment le gérer :

Étapes après un rejet

Motifs de rejet courants

Rejet : « Votre application plante au lancement »

Réponse :

I sincerely apologize for the crash. I have identified and fixed
the issue:

Root cause: The app attempted to fetch data before network
initialization completed, causing a null reference exception.

Fix: Implemented proper async initialization with error handling
and offline mode. The app now gracefully handles network issues.

Testing: Verified on iPhone 12 (iOS 17), iPhone 14 Pro (iOS 17.1),
tested with WiFi, cellular, and airplane mode.

Build version: 1.0.2 (build 3)

Rejet : « Politique de confidentialité manquante »

Réponse :

Thank you for the feedback. I have added the privacy policy:

URL: https://myapp.com/privacy-policy
Location in app: Settings > Privacy Policy (tappable link)
Also added to: App Store Connect > App Information > Privacy Policy URL

The privacy policy covers all data collection as disclosed in the
Privacy Nutrition Labels.

Rejet : « Non conforme à la règle 4.2 - Fonctionnalité minimale »

This is trickier. It means your app doesn’t do enough to warrant being an app. Read comment réussir la review de l'App Store en 2026 notre guide complet pour répondre aux règles 4.2 et 4.3. Exemple de texte pour un appel :

Réponse :

Thank you for the feedback. I'd like to clarify the app's
functionality:

Core Features:
1. [Feature 1 with specific details]
2. [Feature 2 with specific details]
3. [Feature 3 with specific details]

The app provides significant utility beyond a simple website by:
- Offline functionality for [specific feature]
- Native camera integration for [specific feature]
- Push notifications for [specific feature]
- Device hardware access for [specific feature]

Test account credentials have been provided to demonstrate all
features. Please let me know if you need additional clarification.

Bonnes pratiques après l'approbation

Félicitations ! Votre application est approuvée. Voici comment maintenir ce statut :

Monitoring après le lancement

Métriques critiques à surveiller:

• Taux de crash (à maintenir sous 1 %)
• Taux d'ANR (Android : à maintenir sous 0,5 %)
• Notes App Store/Play Store
• Contenu des avis (répondez à tous les avis)
• Bugs signalés par les utilisateurs

Outils à utiliser:

• Firebase Crashlytics
• App Store Connect Analytics
• Google Play Console Vitals
• Sentry ou un outil de suivi d'erreurs similaire

Directives de mise à jour

Lors de l'envoi de mises à jour :

• Testez aussi rigoureusement que la soumission initiale
• Mettez à jour les captures d'écran si l'UI change radicalement
• Update privacy labels if data collection changed
• Fournissez des descriptions « Nouveautés » claires
• Consider staged rollouts for major changes

Rester conforme

Exigences annuelles:

• Renouveler la classification du contenu Android (requis chaque année)
• Update privacy policy if practices change
• Révisez et mettez à jour la classification d'âge si le contenu change
• Auditer la conformité des SDK tiers

Surveillance continue:

• Rester informé des changements de guidelines
• S'abonner aux newsletters développeurs d'Apple et Google
• Participer aux communautés de développeurs
• Follow App Store/Play Store policy blogs

Ressources et lectures complémentaires

Documentation officielle

Apple:

• Directives d'examen de l'App Store
• Se connecter avec Apple
• Aide App Store Connect
• Confidentialité et utilisation des données

Google:

• Centre des politiques pour les développeurs
• Checklist de lancement
• Section Sécurité des données
• Directives de test

Ressources communautaires

• r/androiddev - Communauté des développeurs Android
• r/iOSProgramming - Communauté des développeurs iOS
• Stack Overflow - Questions techniques
• Indie Hackers - Communauté de développeurs indépendants

Outils pour politique de confidentialité

• Générateur de politique de confidentialité Termly
• PrivacyPolicies.com
• Politique de confidentialité gratuite

Foire aux questions

Que sont les directives de révision d'app ?
Ce sont celles d'Apple Directives d'examen de l'App Store et de Google Règles du programme développeur. Reviewers check your binary, metadata, privacy disclosures, and account setup before release.

Combien de temps prend la révision d'une app en 2026 ?
Apple vise 50 % des soumissions sous 24 heures et 90 % sous 48 heures. Google peut mettre jusqu'à sept jours, voire plus, pour certains comptes. Les nouveaux comptes personnels Play Console doivent aussi avoir au moins 12 testeurs inscrits en continu pendant au moins 14 jours consécutifs de test fermé, dont au moins 12 encore inscrits au moment de la demande, lorsque cette règle s'applique.

Quelles sont les cinq sections des directives d'Apple ?
Sécurité, Performance, Business, Design et Juridique. La section Performance couvre l'exhaustivité et les métadonnées (dont la 2.3). La section Juridique couvre la confidentialité (dont la 5.1).

Que dois-je corriger avant ma première soumission ?
Identifiants de démo fonctionnels, HTTPS et liens de support, labels de confidentialité honnêtes, tests sur appareils réels et assets de store conformes au build. Complétez le questionnaire de classification d'âge sur les deux stores lorsque cela s'applique à votre app.

Où se situent les directives 4.2 et 4.3 ?
Ce sont des rejets d'Apple Design pour les applications trop légères ou dupliquées. Utilisez comment réussir la review de l'App Store en 2026 pour ce périmètre, pas pour cette checklist.

Quel est le coût de la publication sur Apple ?
Consultez coût pour publier une app sur l'App Store pour les frais d'inscription et de liste actuels.

Besoin d'aide pour la validation de votre app ?

Si vous vous sentez submergé ou si vous voulez les conseils d'experts pour que votre app passe la revue du premier coup, nous sommes là pour vous aider !

Réserver un appel de consultation avec notre équipe pour une assistance personnalisée sur :

• Préparation de la revue App Store et Play Store
• la revue de la politique de confidentialité et des documents légaux
• l'implémentation de Sign in with Apple
• Stratégie de test et recrutement de testeurs
• la préparation des notes de revue
• la réponse aux rejets et aux recours
• Processus complet de soumission d'app

Notre équipe a aidé des centaines de développeurs à réussir l'examen de leur app et peut vous faire gagner des semaines d'essais et d'erreurs.

Conclusion

Soumettre votre première app peut être intimidant, mais avec une bonne préparation, vous pouvez réussir l'examen dès le premier essai. Gardez ces points clés en tête :

1. Anticipez: Surtout pour Android — recrutez vos 12 testeurs au moins 3 semaines avant votre lancement prévu
2. La vie privée d'abord: Have your privacy policy ready and accurately reflect your data practices
3. Connexion avec Apple: Si vous utilisez un social login, vous devez inclure Sign in with Apple sur iOS
4. Testez minutieusement: Testez sur des appareils réels, avec un réseau instable et en refusant les permissions
5. Soyez honnête: Des métadonnées précises et des déclarations de confidentialité évitent les rejets et les problèmes juridiques
6. Notes de révision détaillées: Aidez les réviseurs à comprendre votre app rapidement

Les exigences actuelles de test Android rallongent le processus, mais elles permettent d'obtenir de meilleures apps et moins de problèmes après le lancement. Prévoyez 3 à 4 semaines supplémentaires pour les soumissions Android, et vous serez bien positionné pour réussir.

Bonne chance pour le lancement de votre app ! N'oubliez pas que même en cas de rejet, c'est une opportunité d'apprentissage. La plupart des apps à succès passent par plusieurs cycles de révision avant d'être approuvées.

Vous ne voulez pas vous lancer seul ? Planifier une consultation et laissez nos experts vous guider tout au long du processus.

Besoin d'aide pour implémenter les live updates après l'approbation de votre app ? Découvrez la solution live update de Capgo pour des mises à jour d'app fluides sans passer par la revue des stores.

Continuer avec les règles de l'App Review 2026

Si vous utilisez cette checklist des règles de l'App Review pour planifier la sécurité et la conformité, connectez-l’à Chiffrement pour les détails d'implémentation du chiffrement, Conformité pour les détails d'implémentation de la conformité, Scanner de sécurité Capgo pour le workflow produit dans Capgo Security Scanner, Capgo et la sécurité pour le workflow produit dans Capgo Security, et Capgo Centre de confiance pour le workflow produit dans Capgo Trust Center.