Votre app est terminée, testée, votre communication est calée sur un lancement lundi prochain… et Apple rejette votre soumission le vendredi soir pour un motif que vous ne comprenez même pas. J'ai vu ce scénario ruiner des lancements — non pas parce que l'app était mauvaise, mais parce que personne n'avait anticipé le processus de publication. Publier sur l'App Store n'est pas un détail administratif de fin de projet : c'est une étape à part entière, avec ses règles, ses délais et ses pièges.
Après plus de treize ans de projets dont une bonne part d'applications mobiles, voici tout ce que j'aurais aimé qu'on m'explique avant ma première soumission — mis à jour pour la réalité de 2026.
Les chiffres à retenir : comptez 99 $ par an pour le compte développeur Apple (gratuit sous conditions pour certaines structures publiques ou à but non lucratif), 24 à 72 h de délai de review dans la grande majorité des cas, et prévoyez 2 à 3 semaines de marge entre la fin du développement et votre date de lancement public pour absorber un ou deux rejets sans stress.
Étape 1 : le compte développeur (à ouvrir dès le début du projet)
L'erreur classique : créer le compte Apple Developer la semaine de la sortie. La vérification d'identité peut prendre de quelques jours à plusieurs semaines, surtout pour une entreprise : Apple exige un numéro D-U-N-S (un identifiant international d'entreprise, gratuit mais parfois long à obtenir ou à corriger si vos informations légales sont mal synchronisées). Deux points de vigilance que je répète à tous mes clients :
- Le compte doit appartenir au client, pas au prestataire. Votre app, votre compte, votre fiche store. Un développeur qui publie votre app sur son propre compte vous rend captif — et Apple interdit d'ailleurs de publier au nom d'un tiers depuis un compte individuel.
- Individuel ou organisation ? Le compte « individuel » affiche votre nom personnel sur le store ; le compte « organisation » affiche votre raison sociale et permet de gérer une équipe. Pour une entreprise, c'est organisation, sans hésiter.
Étape 2 : TestFlight, votre répétition générale
TestFlight est l'outil d'Apple pour distribuer des versions bêta avant la publication. Concrètement : vous envoyez votre app à jusqu'à 100 testeurs internes (disponible en quelques minutes) puis jusqu'à 10 000 testeurs externes, qui l'installent comme une vraie app. Les builds externes passent une mini-review, plus rapide et plus clémente que la review finale — c'est donc aussi un excellent signal d'alerte précoce sur les points qui fâchent.
Mon rituel : au moins deux semaines de TestFlight avec de vrais utilisateurs avant toute soumission publique. Vous y détecterez les crashs sur des appareils que vous n'avez pas, les problèmes de connexion réseau réelle et les incompréhensions d'interface — pendant qu'ils sont encore invisibles du grand public. Pour l'outillage de suivi des crashs, je détaille ma stack dans déboguer une app mobile en production.
Étape 3 : la fiche store, à préparer en parallèle du développement
La fiche App Store demande plus de travail qu'on ne l'imagine : nom (30 caractères), sous-titre (30 caractères), description, mots-clés, captures d'écran aux bons formats (au minimum pour les grandes tailles d'iPhone, plus iPad si votre app le supporte), politique de confidentialité obligatoire hébergée sur une URL publique, et le questionnaire de « nutrition des données » qui déclare tout ce que l'app collecte. Chaque élément est vérifié pendant la review : une capture d'écran qui montre une fonctionnalité absente de l'app est un motif de rejet.
Ne bâclez pas les mots-clés et les visuels : c'est votre référencement dans le store qui se joue là. J'y ai consacré un guide complet : l'ASO, le SEO des app stores.
Les motifs de rejet qui reviennent tout le temps
Apple publie ses App Review Guidelines, et la grande majorité des rejets se concentre sur une poignée de règles. Les connaître avant de développer évite des semaines de retard :
| Guideline | Ce qu'elle sanctionne | Comment l'éviter |
|---|---|---|
| 2.1 — Complétude | App qui crashe, bugs, contenus placeholder, serveur de démo éteint | Tester le parcours complet, fournir un compte de démo fonctionnel |
| 4.3 — Spam / répétition | App trop similaire à d'autres, template générique, « site web encapsulé » | Apporter une vraie valeur native : notifications, offline, capteurs |
| 3.1 — Paiements | Vendre du contenu numérique sans passer par le paiement Apple | Choisir le bon circuit de paiement selon ce que vous vendez (voir plus bas) |
| 5.1 — Vie privée | Permissions non justifiées, collecte non déclarée, absence de politique | Ne demander que le nécessaire, expliquer chaque permission |
| 4.0 — Design | Interface cassée, navigation incompréhensible, non-adaptation aux écrans | Respecter les conventions iOS, tester sur plusieurs tailles |
Le cas particulier des paiements (guideline 3.1)
C'est le sujet le plus mouvant. La règle de base : les biens et services numériques consommés dans l'app (abonnement à du contenu, fonctionnalités premium) passent par le système de paiement d'Apple, avec une commission de 15 à 30 % selon votre chiffre d'affaires et votre situation. Les biens et services physiques ou consommés hors de l'app (livraison de repas, réservation, e-commerce) utilisent votre propre paiement, sans commission. Depuis les évolutions réglementaires récentes — notamment le DMA en Europe — des ouvertures existent (liens vers des paiements externes, boutiques alternatives dans l'UE), mais les conditions changent régulièrement : à la date où j'écris, je recommande de valider votre montage de paiement avant de développer, pas après un rejet.
Le piège 4.3 pour les apps « vitrines »
Si votre app se contente d'afficher votre site web dans une coquille, Apple la refusera. C'est une vraie question de conception en amont : avez-vous besoin d'une app native, ou une PWA suffit-elle ? J'ai posé les critères de décision dans PWA vs application native. Si vous publiez, assumez du natif : notifications push pertinentes, mode hors ligne, intégration aux fonctions du téléphone.
Les délais réels, de la soumission à la mise en ligne
- Première review : 24 à 72 h dans la plupart des cas. Prévoyez jusqu'à une semaine en période chargée (fin d'année, avant les grandes conférences Apple).
- En cas de rejet : vous corrigez, vous resoumettez, et vous repartez pour un cycle. Deux rejets successifs, c'est facilement 10 jours de perdus — d'où la marge de 2 à 3 semaines que je préconise.
- Publication différée : bonne pratique : choisissez la « publication manuelle » plutôt qu'automatique. L'app approuvée attend votre feu vert, et vous déclenchez la mise en ligne le jour J, à l'heure de votre choix.
- Mises à jour suivantes : même processus de review à chaque version. Intégrez-le dans votre rythme de livraison — un correctif urgent peut demander une « expedited review », accordée avec parcimonie.
Ces délais s'ajoutent au calendrier de développement lui-même, que j'ai détaillé dans combien de temps pour développer une app mobile. Beaucoup de plannings de lancement oublient purement et simplement cette dernière ligne droite.
Ma checklist avant de cliquer sur « Soumettre »
- Compte de démonstration fourni aux reviewers : identifiants valides, données réalistes, toutes les fonctionnalités accessibles. Le motif de rejet le plus bête et le plus fréquent.
- Notes de review remplies : expliquez ce que fait l'app, à qui elle s'adresse, et tout ce qui pourrait intriguer un reviewer (matériel requis, compte professionnel, zone géographique).
- Backend de production allumé et stable pendant toute la période de review — un serveur de staging qui redémarre pendant le test, et c'est le rejet 2.1.
- Permissions justifiées : chaque demande (caméra, localisation, contacts) a un texte d'explication clair, en français et en anglais.
- Politique de confidentialité en ligne, cohérente avec le questionnaire de collecte de données et avec le RGPD.
- Suppression de compte disponible dans l'app si vous proposez une création de compte — c'est obligatoire.
- Achats intégrés testés en sandbox, y compris la restauration des achats, exigée par Apple.
- Fiche store relue : captures à jour, aucune mention d'autres plateformes, aucun prix affiché qui contredit les achats intégrés.
Après la mise en ligne : les premières 72 heures
La publication n'est pas la fin du processus. Les trois premiers jours, surveillez de près le taux de crash (votre outil de monitoring doit être branché avant la sortie), les premiers avis — répondez-y systématiquement, ça pèse sur la note et sur le classement — et la conversion de la fiche store (visites vers installations). Préparez aussi une version corrective : quoi que vous fassiez, les vrais utilisateurs trouveront en trois jours des bugs que trois semaines de tests n'avaient pas révélés. Avoir le correctif prêt à soumettre dès la fin de la première semaine fait partie du plan de lancement, pas de l'improvisation. Et si vous comptez sur les notifications push pour faire revenir vos utilisateurs, définissez la stratégie avant le lancement — j'explique comment dans ma stratégie de notifications push.
Et si vous êtes quand même rejeté ?
Pas de panique : la majorité des apps rejetées finissent publiées. Lisez le motif précis dans App Store Connect, répondez dans le fil de discussion si le rejet vous semble reposer sur un malentendu (c'est fréquent, et les reviewers reviennent sur leur décision quand on leur explique calmement), corrigez si le motif est fondé, et resoumettez. En cas de désaccord persistant, une procédure d'appel existe. Ce qu'il ne faut jamais faire : resoumettre à l'identique en espérant tomber sur un reviewer plus conciliant, ou contourner la règle en la masquant — les sanctions vont jusqu'à la suppression du compte.
Mon principe sur tous mes projets mobiles : la review d'Apple se prépare au moment du cahier des charges, pas la veille de la soumission. Chaque règle découverte en fin de projet coûte dix fois plus cher qu'une règle anticipée.
Publions votre app dans les règles
De la conception à la mise en ligne sur les stores, j'accompagne les entreprises sur tout le cycle — y compris cette dernière ligne droite où tant de projets trébuchent. Si vous préparez un lancement d'app, réservez un appel découverte : on sécurisera ensemble votre calendrier de publication.
À lire ensuite : ASO : être trouvé sur les stores et Combien de temps pour développer une app mobile ?