La liste de contrôle avant de publier votre app

Une faute de frappe sur le bouton « Payer ». Une politique de confidentialité qui mène à une page introuvable. Un plantage au premier lancement sur le téléphone le moins cher de votre public. Aucun de ces défauts n’est difficile à corriger ; tous sont faciles à oublier la veille d’une publication.

Les pilotes de ligne déroulent une liste de contrôle avant chaque décollage, quelle que soit leur expérience. Ce n’est pas qu’ils ignorent la procédure : sous la pression, la mémoire flanche. Une mise en ligne, c’est pareil.

Voici notre liste, regroupée en huit familles et commentée point par point. À la fin de cet article, vous aurez une liste à copier dans votre outil, à adapter à votre app et à passer avant chaque publication, sur Android, sur iPhone ou sur le web.

Comment utiliser cette liste de contrôle

Une liste de contrôle ne remplace pas le test : elle vérifie que rien d’important n’a été oublié. Passez-la sur la version candidate, celle que vous allez réellement envoyer au store, et pas sur une version de développement.

Trois règles rendent la liste efficace :

• Quelqu’un d’autre que le développeur la passe. On ne voit pas ses propres oublis.
• Chaque ligne reçoit une réponse : fait, défaut signalé (avec un ticket), ou sans objet pour cette app.
• Notez le contexte : date, numéro de build, appareils et versions du système utilisés.

Fonctionnel, appareils et réseau : l’app fait-elle ce qu’elle promet ?

Commencez par l’essentiel : les parcours principaux marchent-ils, partout où vos utilisateurs se trouvent ? Un premier passage rapide, le smoke test, élimine les défauts grossiers avant le reste (voir notre article smoke test, régression et recette).

• L’installation neuve fonctionne : désinstallez, réinstallez, ouvrez. C’est le premier contact de chaque nouvel utilisateur.
• La mise à jour depuis la version précédente garde les données : compte connecté, panier, préférences. C’est le cas de tous vos utilisateurs actuels.
• Chaque parcours principal va au bout : inscription, action principale (commande, transfert, réservation), consultation de l’historique.
• Les bugs corrigés depuis la dernière version ne sont pas revenus : c’est le test de régression.
• Le téléphone le plus modeste de votre cible : peu de mémoire, petit écran, ancienne version d’Android. Voir le test de compatibilité.
• Portrait, paysage et texte agrandi : aucun bouton coupé ou caché.
• Réseau lent, coupé puis rétabli : un message clair, pas d’écran blanc, pas de double envoi. Notre guide pour tester sur un réseau lent détaille la méthode.
• Interruptions : appel entrant, passage en arrière-plan, batterie faible, puis retour dans l’app.

Si vous n’avez pas ces téléphones sous la main, confiez cette partie à de vrais testeurs : c’est le métier de GeekTest, qui vous permet de commander des testeurs sur leurs propres appareils Android, iPhone, iPad ou ordinateur.

Inscription, connexion et paiement : les parcours qui rapportent

Un défaut ici coûte directement des utilisateurs ou de l’argent. Testez avec des comptes de test dédiés, et avec les moyens de paiement de votre public.

• Inscription par e-mail et par téléphone : formats de numéro locaux acceptés, indicatif pays correct.
• Code reçu par SMS : il arrive, il expire, et l’on peut en redemander un sans bloquer le compte.
• Mot de passe oublié : le lien ou le code fonctionne, et l’ancien mot de passe ne marche plus.
• Session expirée et déconnexion : retour propre à l’écran de connexion, sans perte de données saisies.
• Suppression du compte depuis l’app : Apple et Google l’exigent si l’on peut créer un compte dans l’app ; Google demande aussi un lien web pour en faire la demande.
• Paiement réussi, refusé et annulé : chaque cas affiche un message juste et laisse la commande dans le bon état.
• Double appui et coupure réseau pendant le paiement : jamais de double débit. En Mobile Money, testez aussi une confirmation qui arrive en retard.
• Reçu et historique : le montant, la devise (FCFA, euro…) et la date sont exacts.

Textes, langues et accessibilité

Les textes sont la partie la plus visible de l’app, et la plus souvent relue en dernier. L’accessibilité, elle, est souvent oubliée ; notre article sur le test d’accessibilité vous donne les seuils et la méthode.

• Aucun texte provisoire : pas de « Lorem ipsum », de « TODO » ni de bouton « Test ». Apple demande de retirer tout contenu provisoire avant l’envoi.
• Orthographe relue sur tous les écrans, messages d’erreur compris.
• Chaque langue est complète : aucun mot resté en anglais dans la version française, aucun texte coupé quand la traduction est plus longue.
• Formats locaux : dates, heures, séparateurs de milliers, devises.
• Messages d’erreur humains : ils disent ce qui s’est passé et quoi faire, sans code technique seul.
• Lecteur d’écran (TalkBack sur Android, VoiceOver sur iPhone) : chaque bouton annonce sa fonction.
• Contraste et taille du texte : lisible en plein soleil, et toujours utilisable avec le texte agrandi.
• Zones tactiles assez grandes et information jamais transmise par la couleur seule.

Sécurité et vie privée

Les deux stores vous demandent de déclarer ce que l’app fait des données. Un écart entre vos déclarations et le comportement réel de l’app peut vous valoir un refus, voire des sanctions. Pour les vérifications de sécurité à la portée d’un testeur, lisez notre guide dédié.

• Tout passe en HTTPS, y compris les images et les appels à l’API.
• Aucun secret dans l’app : clés d’API privées, mots de passe de serveur. Le code d’une app installée peut être décortiqué.
• Journaux propres : aucun mot de passe, code reçu par SMS ou numéro de carte dans les logs.
• Autorisations minimales : l’app ne demande que ce qu’elle utilise, au moment où elle en a besoin, avec une explication.
• Politique de confidentialité en ligne : son adresse figure dans la console du store et dans l’app ; Google et Apple l’exigent tous les deux.
• Déclarations à jour : la section Sécurité des données (Data safety) dans la Play Console, et la section App Privacy dans App Store Connect, affichée sous le nom « Confidentialité de l’app » sur l’App Store en français.

La fiche du store : captures, textes et déclarations

La fiche est votre vitrine, et le premier endroit où l’examinateur cherche des incohérences. Le tableau suivant rassemble les points de contrôle principaux pour chaque store.

Côté Android, vérifiez aussi le niveau d’API cible : depuis le 31 août 2026, les nouvelles apps et les mises à jour doivent viser Android 16 (API 36) au minimum, avec quelques exceptions (Wear OS, Android TV…) décrites dans l’aide Google Play sur le niveau d’API cible (nouvel onglet). Une prolongation jusqu’au 1er novembre 2026 peut être demandée.

• Les captures montrent la version actuelle, pas une maquette ni une ancienne interface.
• Le nom, l’icône et les captures sont cohérents entre le store et l’app.
• La description promet ce que l’app fait, rien de plus.
• Chaque langue de la fiche est relue, captures comprises si elles contiennent du texte.
• Les liens de la fiche fonctionnent : site, assistance, politique de confidentialité.
• Les comptes de test fournis aux examinateurs marchent, et ne demandent pas de code envoyé sur votre téléphone.

Analytique, suivi des plantages et plan de retour arrière

Le jour de la publication, vous devez voir ce qui se passe et pouvoir réagir vite. Sur aucun des deux stores on ne « réinstalle » simplement l’ancienne version chez tout le monde : il faut donc préparer la marche arrière avant d’en avoir besoin.

• Le suivi des plantages est actif dans la version candidate : provoquez un plantage volontaire sur un build de test et vérifiez qu’il remonte.
• Les fichiers de symboles sont envoyés (fichier de correspondance R8 ou ProGuard sur Android, symboles de débogage sur iOS) pour que les rapports soient lisibles.
• Les événements clés remontent : inscription, paiement, erreur de paiement, dans le respect du consentement de l’utilisateur.
• Le tableau de bord du premier jour est prêt : plantages, connexions, paiements réussis.
• Le déploiement est progressif : Google Play permet d’interrompre un déploiement par étapes ; l’App Store propose une publication progressive sur sept jours (nouvel onglet), que l’on peut mettre en pause.
• Un interrupteur à distance existe pour couper une fonction risquée sans nouvelle version.
• Le serveur accepte encore l’ancienne version de l’app, car tout le monde ne met pas à jour le même jour.
• Les rôles sont clairs : qui décide d’arrêter le déploiement, qui corrige, qui prévient les utilisateurs.

Pour un site ou une app web : référencement et performance

Un site n’a pas de store, mais il a Google Search et des visiteurs pressés. Ajoutez ces points à la liste si vous publiez un site ou une application web.

• Chaque page a un titre et une description uniques, qui disent ce que l’on y trouve.
• HTTPS partout, et les anciennes adresses redirigent vers les nouvelles.
• Le plan du site (sitemap.xml) existe et le fichier robots.txt ne bloque pas les pages à référencer.
• L’aperçu de partage est soigné : titre, description et image quand on colle le lien dans WhatsApp ou sur un réseau social.
• Une page 404 utile ramène le visiteur vers l’accueil ou la recherche.
• Bonnes performances sur téléphone : les Core Web Vitals, les trois indicateurs de Google pour l’expérience d’une page, sont au vert : le plus grand élément s’affiche en 2,5 secondes au plus (LCP), la page réagit aux interactions en 200 millisecondes au plus (INP) et la mise en page bouge peu (CLS de 0,1 au plus), pour au moins 75 % des visites.
• Les images sont compressées et chargées seulement quand elles deviennent visibles.
• Les formulaires marchent sur téléphone : bon clavier pour l’e-mail et le téléphone, messages d’erreur à côté du champ.
• Les navigateurs de vos visiteurs sont testés : Chrome sur Android, Safari sur iPhone, au moins un navigateur d’ordinateur.

Pas le temps de tout passer avant l’envoi ? Commencez au moins par ces points, dès aujourd’hui.

Pour aller plus loin

• Aide Play Console : règlement « Données utilisateur » (nouvel onglet) — politique de confidentialité dans la console et dans l’app, suppression de compte, section Sécurité des données (consultée le 20 octobre 2026).
• Aide Play Console : ajouter des assets de prévisualisation pour présenter votre application (nouvel onglet) — captures d’écran, icône, image de présentation, description courte et mots interdits.
• Aide Play Console : déployer les mises à jour d’applications par étapes (nouvel onglet) — interrompre et reprendre un déploiement.
• App Review Guidelines (nouvel onglet) — les directives d’Apple : app complète et sans texte provisoire (2.1), politique de confidentialité et suppression de compte (5.1.1), en anglais.
• App Store Connect Help : Manage app privacy (nouvel onglet) — les questions App Privacy, les partenaires tiers et l’adresse de la politique de confidentialité.
• web.dev : Web Vitals (nouvel onglet) — la définition des Core Web Vitals et leurs seuils, par l’équipe Chrome de Google.