Checklist application mobile pour startups : 34 points du MVP à l'approbation de l'App Store (2026)

Checklist application mobile pour startups : 34 points du MVP à l'approbation de l'App Store (2026)

La directive 5.1.1(v) de l'App Store Review d'Apple a tué plus de dates de lancement de startups que n'importe quel bug que nous ayons jamais livré. Un bouton de suppression de compte manquant, soumis la veille d'un demo day, et tout le planning glisse d'une semaine. Cette checklist application mobile pour startups existe parce que cette erreur est parfaitement évitable, et presque personne ne note le numéro de directive qui la provoque.

Points clés :

• Apple rejette des apps pour absence de parcours de suppression de compte et de lien vers la politique de confidentialité : les directives 5.1.1 et 1.5 le disent explicitement.
• Google Play exige à la fois un parcours de suppression de compte dans l'app et sur le web public, avec des mesures d'application depuis l'échéance de prolongation du 31 mai 2024.
• Les checklists de soumission iOS et Android diffèrent ; les traiter comme une seule liste combinée est la première cause de retards de lancement de dernière minute.

Avant d'écrire la moindre ligne de code

Avant même de concevoir le premier écran, trois points doivent être verrouillés : ce qu'est réellement votre MVP, si vous avez besoin d'une politique de confidentialité (oui), et si le RGPD ou le KVKK turc s'applique à vos utilisateurs. Sauter cette étape, c'est la raison pour laquelle des fondateurs finissent par rédiger leurs pages légales en urgence la semaine même où ils voulaient soumettre.

Un MVP, en une phrase, c'est la plus petite version de votre produit qui teste votre hypothèse centrale auprès de vrais utilisateurs. Ce n'est pas une version allégée de votre vision complète. Si le périmètre reste flou, bien cadrer votre projet avant d'écrire la moindre ligne de code vous évite de couper des fonctionnalités en plein développement plutôt qu'avant.

Les directives d'Apple sont sans ambiguïté sur l'exigence de politique de confidentialité : la directive 5.1.1(i) stipule que les apps « doivent inclure un lien vers leur politique de confidentialité » dans les métadonnées App Store Connect et, dans de nombreux cas, dans l'app elle-même. Ce n'est pas une suggestion. C'est un motif de blocage de la soumission si le lien manque.

• Définissez le périmètre de votre MVP en une phrase
• Confirmez que vous avez besoin d'une politique de confidentialité (c'est presque toujours le cas)
• Rédigez une URL de support (la directive 1.5 d'Apple l'exige)
• Vérifiez l'applicabilité du RGPD/KVKK si vous avez des utilisateurs européens ou turcs
• Décidez de la stack native ou cross-platform

La semaine de développement du MVP

La semaine de développement du MVP, c'est le moment où vous décidez ce qui sort vraiment et ce qui passe à la trappe, et la réponse honnête est : plus de choses que les fondateurs ne l'imaginent. Les analytics et le crash reporting s'intègrent pendant le développement, pas après. Les ajouter après le lancement, c'est perdre précisément les données dont vous aviez besoin pour valider votre première hypothèse.

Ce que nous coupons réellement d'un périmètre v1, la plupart du temps, c'est tout ce qui n'est pas la chose unique testée. Notifications push, connexion sociale, écran de réglages avec six interrupteurs : tout cela peut attendre. Les fondateurs résistent, on les comprend ; on a l'impression de livrer quelque chose d'inachevé. C'est inachevé. C'est le but.

Comme l'écrit un fondateur qui a sorti plusieurs apps dans un billet de checklist sur dev.to, faire l'impasse sur un mécanisme de feedback au début est une erreur qu'il a « regrettée à chaque fois ». Intégrez-le maintenant, pas après l'arrivée de votre premier avis. Si vous voulez accélérer la conversation de cadrage elle-même, utiliser l'IA pour cadrer plus vite mérite un coup d'œil avant le début du développement.

• Instrumentez les analytics avant votre premier build TestFlight/interne
• Branchez le crash reporting (Sentry ou Firebase Crashlytics)
• Intégrez un mécanisme de feedback dans l'app
• Coupez toute fonctionnalité qui n'est pas au cœur de la chose testée
• Écrivez votre première chaîne de version (voir le versionnage ci-dessous)

La semaine précédant la soumission

C'est l'étape que toutes les checklists concurrentes passent entièrement sous silence, et c'est là que se produisent les retards les plus évitables. Le versionnage sémantique des apps suit le schéma MAJOR.MINOR.BUILD (1.0.0, puis 1.0.1 pour un correctif, 1.1.0 pour une nouvelle fonctionnalité). Choisissez un schéma maintenant, car des numéros de version incohérents embrouillent les app stores comme votre propre équipe.

Un déploiement progressif diffuse votre mise à jour à un petit pourcentage d'utilisateurs d'abord (souvent 1 %, puis 10 %, puis 50 %) avant une diffusion générale. Une seule des trois checklists concurrentes que nous avons examinées le mentionne, et encore, en passant. Si un crash passe au travers, un déploiement progressif limite le rayon d'impact au lieu de toucher 100 % des utilisateurs d'un coup.

Les questions que nous posons avant de donner le feu vert à une soumission client sont simples : le parcours critique fonctionne-t-il de bout en bout, maintenant, sur un vrai appareil ? Pas le simulateur. Le taux de sessions sans crash est-il acceptable ? Les assets de la fiche store sont-ils vraiment définitifs, pas des placeholders ?

• Confirmez que votre numéro de version suit un schéma cohérent
• Testez votre parcours critique de bout en bout une dernière fois
• Préparez votre pourcentage de déploiement progressif si le store le propose
• Confirmez que le taux de sessions sans crash est acceptable avant de soumettre
• Capturez et préparez tous les assets de la fiche store

Jour de soumission : iOS vs. Android

Les soumissions iOS et Android échouent pour des raisons différentes, et les traiter comme une seule checklist combinée est de loin la première cause de retards de lancement de dernière minute que nous observons. Les App Store Review Guidelines d'Apple et les règles développeurs de Google Play énoncent chacune des exigences précises et vérifiables, et la plupart des fondateurs les découvrent seulement après un e-mail de rejet.

Dans nos propres soumissions d'apps, les deux points qui font trébucher le plus souvent les fondateurs débutants sont l'exigence de suppression de compte et une URL de support injoignable. Les deux se corrigent en une ligne si vous les repérez avant de soumettre. Les deux provoquent un rejet automatique sinon.

Les App Store Review Guidelines d'Apple sont précises : la directive 5.1.1(v) impose aux apps qui permettent la création de compte de proposer aussi la suppression de compte dans l'app, la directive 1.6 couvre les déclarations de sécurité des données (Data Security), et la directive 1.5 exige une URL de support fonctionnelle. Côté Android, les règles développeurs de Google Play exigent à la fois un parcours de suppression dans l'app ET une URL web publique pour les demandes de suppression de compte. Google a annoncé l'exigence en avril 2023, fixé une échéance au 7 décembre 2023 pour les questions de suppression de données du formulaire de sécurité des données, puis accordé des prolongations jusqu'au 31 mai 2024, date après laquelle les apps non conformes s'exposent à des mesures d'application. Ce n'est pas une vieille règle abandonnée pour les petites apps ; elle s'applique toujours.

Les deux flux de soumission divergent aussi mécaniquement, pas seulement sur le papier. Sur iOS, vous uploadez un build via Xcode ou Transporter, App Store Connect le traite (cela prend de quelques minutes à plus d'une heure), et de là vous l'envoyez vers TestFlight pour des testeurs internes et externes, ou vous le soumettez directement à l'App Review. TestFlight n'est pas une formalité optionnelle : c'est la façon dont Apple s'attend à ce que vous attrapiez les bugs pour lesquels un réviseur vous rejetterait sinon. Sur Android, Google Play Console fonctionne par rails plutôt que par soumission unique : tests internes, puis tests fermés ou ouverts, puis production, chacun avec son audience et son étape de promotion. Le déploiement progressif n'apparaît qu'au moment où vous mettez à jour une version de production existante. Comme l'indique la propre documentation de publication de Google, « si vous déployez votre première version, vous ne verrez pas l'option permettant de sélectionner un pourcentage de déploiement » ; ne planifiez donc pas votre tout premier lancement autour d'une montée en pourcentage, cela vient plus tard.

Ce sont les formalités, pas le code, qui bloquent réellement la plupart des premières soumissions. Apple exige un manifeste de confidentialité (privacy manifest) pour une liste définie de SDK tiers couramment utilisés (régies publicitaires, analytics, outils de crash reporting), et sa propre documentation est directe quant au responsable : « lorsque vous utilisez un SDK tiers avec votre app, vous êtes responsable de tout le code que le SDK inclut dans votre app, et vous devez connaître ses pratiques de collecte et d'utilisation des données », selon la page des exigences SDK tiers d'Apple. Oubliez le manifeste pour un SDK listé et votre build ne passera pas App Store Connect. L'équivalent côté Google Play est le formulaire de sécurité des données (Data safety form), obligatoire pour toute app sur tous les rails, sauf les builds cantonnés aux tests internes : « tous les développeurs ayant une app publiée sur Google Play doivent remplir le formulaire de sécurité des données, y compris les apps sur les rails de tests fermés, ouverts ou de production », selon la documentation Sécurité des données de Google Play. En cas d'erreur, Google dit clairement qu'il « peut prendre les mesures appropriées, y compris des mesures d'application » dès qu'un écart entre votre comportement déclaré et réel apparaît.

Il existe un troisième mode d'échec qui n'a rien à voir avec le texte des règles : le réviseur ne peut littéralement pas tester votre app. La directive 2.1 d'Apple le formule directement : « incluez les informations d'un compte de démonstration (et activez votre service back-end !) si votre app inclut une connexion ». Pas d'identifiants de démo fonctionnels, pas de backend en ligne pendant la fenêtre de revue, pas d'URL de support joignable, et vous serez recalé quelle que soit la conformité de votre parcours de suppression de compte. Si une partie de votre app se trouve derrière un paywall ou une connexion, rédigez des notes à l'intention du réviseur expliquant exactement comment y accéder. C'est une étape de deux minutes que les fondateurs débutants sautent en permanence.

Une dernière barrière, propre à Android, mérite d'être mentionnée : le niveau d'API cible. La documentation développeurs d'Android indique que « les nouvelles apps et les mises à jour d'apps doivent cibler » le niveau d'API Android actuellement requis « pour être soumises à Google Play », et que « les apps obsolètes ne sont pas disponibles pour les nouveaux utilisateurs d'appareils exécutant des versions plus récentes d'Android ». Cela n'a rien à voir avec la suppression de compte ni la sécurité des données, mais cela bloque une soumission tout aussi net, et c'est le genre d'exigence qui change chaque année ; vérifiez donc le numéro en vigueur avant de compiler votre version.

Aucune des checklists les mieux classées sur cette recherche exacte ne cite le moindre numéro de directive de l'App Store. Nous, si, parce que deviner la conformité est la meilleure façon de voir son lancement retardé d'une semaine à la fois. Si vous construisez votre posture plus large de gestion des données, notre checklist de sécurité avant lancement couvre le volet sécurité que nous ne dupliquons pas ici.

Checklist de soumission iOS :

• URL de politique de confidentialité en ligne et accessible
• Parcours de suppression de compte dans l'app livré (directive 5.1.1(v))
• URL de support en ligne (directive 1.5)
• Déclarations Data Security remplies (directive 1.6)
• Build TestFlight approuvé avant la soumission publique

Checklist de soumission Android :

• Formulaire de sécurité des données rempli dans Play Console
• Parcours de suppression de compte dans l'app livré
• URL web publique pour les demandes de suppression de compte en ligne (exigence Google Play)
• Pourcentage de déploiement progressif défini
• Niveau d'API cible conforme à l'exigence Play en vigueur

Jour de lancement

Le jour de lancement est le jour où votre app devient réellement accessible aux vrais utilisateurs, à distinguer de la soumission, qui peut avoir lieu des jours ou des semaines plus tôt, et de la première semaine, qui est l'après. Le suivi du déploiement progressif le premier jour vous dit s'il faut continuer à étendre ou mettre en pause.

Surveillez votre tableau de bord App Store Connect ou Play Console toutes les heures, pas une fois par jour, pendant les premières 24 heures. Si votre taux de sessions sans crash chute, vous voulez le savoir dans l'heure, pas le lendemain matin quand cent utilisateurs de plus ont rencontré le même bug. Gardez un build de rollback prêt. La même discipline durcir-stabiliser-déployer que nous appliquons aux fonctionnalités IA s'applique tout aussi directement ici.

• Surveillez le taux de sessions sans crash toutes les heures pendant les premières 24 heures
• Prévoyez un canal de support opérationnel et prêt
• Confirmez que votre déploiement progressif s'étend comme prévu
• Gardez un build de rollback prêt en cas de bug critique

Votre première semaine en ligne

La première semaine en ligne est le moment où l'essentiel du travail réel se produit, même si presque personne ne le planifie. La relecture quotidienne des rapports de crash et les réponses à vos premiers avis sur le store comptent plus que tout ce que vous avez fait le jour du lancement.

« Le lancement lui-même compte moins qu'on ne le croit. Ce qui compte, c'est ce que vous faites dans les semaines qui suivent », écrivait un fondateur dans sa propre checklist post-lancement. Voilà la version honnête de la première semaine : patchez vite, répondez personnellement, et vérifiez réellement que votre parcours de suppression de données fonctionne avant qu'un vrai utilisateur ne le teste à votre place. Si vous vous demandez maintenant combien tout cela coûte à construire et à maintenir, notre article sur le budget de maintenance et de mises à jour post-lancement est le complément idéal. Cet article couvre la préparation ; celui-là couvre la facture.

• Passez en revue les rapports de crash quotidiennement la première semaine
• Répondez personnellement à vos 10 premiers avis sur le store
• Qualifiez et patchez tout bug critique sous 48 heures
• Confirmez que votre processus de demande de suppression de données fonctionne vraiment de bout en bout
• Fixez un rythme pour confronter vos analytics à votre hypothèse MVP initiale

L'approche de Techsy

Nous traitons la revue de pré-soumission de la même façon pour chaque build client : avant de donner le feu vert, nous vérifions si le parcours critique fonctionne sur un vrai appareil, si le taux de sessions sans crash tient, et si chaque parcours imposé par les directives (suppression de compte, politique de confidentialité, URL de support) fonctionne réellement, pas seulement dans une maquette. C'est une liste courte, mais c'est celle qui détermine si une app passe la revue du premier coup.

Si vous préférez confier votre soumission à quelqu'un qui connaît déjà ces directives, notre processus de développement d'applications mobiles est construit précisément autour de cette étape de revue de pré-soumission. Ce n'est pas un substitut à vos propres devoirs, c'est ce que nous faisons une fois que vous les avez faits.

Questions fréquemment posées

Qu'est-ce qu'un MVP et pourquoi est-ce important pour une checklist de lancement ?

Un MVP est la plus petite version de votre produit qui teste une hypothèse centrale auprès de vrais utilisateurs. C'est important ici parce que chaque point de cette checklist grandit avec le périmètre : un MVP plus resserré signifie moins de choses qui peuvent mal tourner à la soumission, et moins de fonctionnalités à instrumenter, surveiller et patcher la première semaine.

Pourquoi les apps sont-elles rejetées de l'App Store ?

Les raisons évitables les plus fréquentes sont l'absence de lien vers la politique de confidentialité (directive 5.1.1(i)), l'absence de suppression de compte dans l'app (directive 5.1.1(v)) et une URL de support injoignable (directive 1.5). Aucune ne demande d'effort d'ingénierie à corriger : ce sont des points de checklist, pas des bugs.

Que se passe-t-il si je n'ajoute pas d'option de suppression de compte à mon app ?

Sur iOS, la directive 5.1.1(v) en fait un motif de rejet automatique si votre app permet la création de compte. Sur Android, Google Play exige à la fois un parcours de suppression dans l'app et sur le web public, les apps non conformes s'exposant à des mesures d'application après l'échéance de prolongation du 31 mai 2024 ; l'omettre bloque la soumission sur les deux plateformes.

Les startups ont-elles besoin d'une politique de confidentialité pour une app mobile ?

Oui, presque toujours. Apple exige une politique de confidentialité liée au titre de la directive 5.1.1(i), et Google Play en exige une dans le formulaire de sécurité des données. Si vous collectez la moindre donnée utilisateur, ne serait-ce qu'un e-mail d'inscription, il vous en faut une avant de soumettre.

Quelle différence entre soumettre sur l'App Store et sur Google Play ?

La revue d'Apple est pilotée par des directives aux clauses numérotées (5.1.1, 1.5, 1.6) et un réviseur humain ; Google Play s'appuie sur le formulaire de sécurité des données et des contrôles automatisés. L'exigence de suppression de compte est similaire dans l'esprit mais diffère dans la mécanique ; voir le tableau comparatif ci-dessus.

Combien de temps prend vraiment la revue d'un app store ?

Aucun des deux stores ne publie de délai garanti ; traitez donc tout chiffre que vous lisez comme une estimation approximative plutôt que comme une promesse. Dans nos propres soumissions clients, les approbations d'Apple arrivent généralement en un à deux jours, tout ce qui touche à la suppression de compte ou à la déclaration des données prenant plus longtemps. Google Play est généralement plus rapide. Dans tous les cas, prévoyez votre date de lancement avec de la marge.

Qu'est-ce qu'un déploiement progressif et faut-il en utiliser un ?

Un déploiement progressif diffuse une mise à jour à un petit pourcentage d'utilisateurs d'abord, puis s'étend graduellement, au lieu de toucher 100 % d'un coup. Utilisez-le chaque fois que le store le propose ; il limite le nombre d'utilisateurs touchés par un bug avant que vous puissiez mettre en pause et corriger.

Ai-je besoin d'une URL de support pour soumettre mon app ?

Oui. La directive 1.5 d'Apple exige une URL de support fonctionnelle dans la soumission, et Google Play attend également un contact de support. Un lien mort ou une boîte mail non surveillée est ici un motif de rejet facile à éviter.

Que surveiller pendant la première semaine de mon app en ligne ?

Les rapports de crash quotidiennement, vos dix premiers avis sur le store, et le fonctionnement réel de votre processus de demande de suppression de données de bout en bout. C'est aussi le moment où vous commencez à confronter les données d'usage réelles à l'hypothèse que votre MVP devait tester.

Le RGPD ou le KVKK concernent-ils l'app d'une petite startup ?

Si vous avez des utilisateurs dans l'UE, le RGPD s'applique quelle que soit la taille de votre entreprise. Si vous avez des utilisateurs en Turquie, le KVKK s'applique de la même façon. Aucune des deux lois ne prévoit d'exemption pour les petites startups ; vérifiez donc l'applicabilité pendant le cadrage, pas après avoir de vraies données utilisateurs à protéger.

Conclusion

Une checklist application mobile pour startups ne mérite sa place que si elle est assez précise pour agir dès aujourd'hui : définissez votre MVP en une phrase, instrumentez les analytics avant de développer, révisez votre schéma de version la semaine précédant la soumission, et séparez vos checklists iOS et Android au lieu de les traiter comme une seule liste. Les points de suppression de compte et de politique de confidentialité représentent à eux seuls la majorité des rejets évitables que nous observons.

Imprimez la checklist, parcourez-la étape par étape, et ne sautez pas la première semaine en ligne : c'est la partie que toutes les checklists concurrentes oublient, et c'est celle qui détermine réellement si votre lancement tient. Si vous préférez un second regard sur votre soumission avant de l'envoyer, obtenez une consultation gratuite →.