La dernière étape d’un projet d’application, la publication sur l’App Store et sur Google Play, réserve souvent des surprises : comptes à ouvrir à l’avance, déclarations de confidentialité détaillées, phases de test imposées, refus lors de l’examen. Chez Web Solutis, nous avons conçu et publié l’application Plouf Check sur iOS et Android, avec une app Apple Watch, des widgets et une intégration à Siri. Voici ce que nous retenons de ce parcours.
Étape 1 : ouvrir les comptes développeur
Apple Developer Program
Pour publier sur l’App Store, il faut adhérer à l’Apple Developer Program, facturé 99 USD par an (ou l’équivalent en monnaie locale). Sans renouvellement, vos applications ne sont plus disponibles au téléchargement. Pour une entreprise, le compte organisation est préférable au compte individuel : l’application est publiée au nom de la société et plusieurs collaborateurs peuvent y accéder avec des rôles distincts. Il nécessite un numéro D-U-N-S, identifiant d’entreprise gratuit dont l’obtention peut prendre un peu de temps si votre société n’en dispose pas encore.
Google Play Console
Côté Android, l’inscription à la Play Console implique des frais uniques de 25 USD, ainsi qu’une vérification d’identité. Point essentiel : pour les nouveaux comptes développeur personnels, Google impose un test fermé avec au moins 12 testeurs pendant au moins 14 jours avant de pouvoir demander l’accès à la production. Découverte trop tard, cette contrainte peut décaler un lancement de plusieurs semaines.
Astuce : ouvrez les comptes au nom de votre entreprise, et non à celui de votre prestataire, puis invitez ce dernier avec les droits nécessaires. Vous restez ainsi propriétaire de vos applications, de leurs avis et de leurs statistiques, quelle que soit la suite de la collaboration.
Étape 2 : préparer la fiche de l’application
La fiche, votre vitrine sur les stores, se prépare pour chaque langue proposée.
Textes et mots-clés (ASO)
L’ASO (App Store Optimization) est l’équivalent du référencement naturel pour les stores. Les deux plateformes n’exploitent pas les champs de la même manière :
| Élément | App Store | Google Play |
|---|---|---|
| Nom | 30 caractères maximum | 30 caractères maximum |
| Accroche | Sous-titre de 30 caractères | Description courte de 80 caractères |
| Mots-clés | Champ dédié de 100 caractères, invisible pour l’utilisateur | Pas de champ dédié : les termes sont lus dans le titre et les descriptions |
| Description | Jusqu’à 4 000 caractères, sans rôle direct dans la recherche | Jusqu’à 4 000 caractères, prise en compte pour la recherche |
Choisissez les termes que vos utilisateurs emploient réellement plutôt que votre jargon interne, et évitez les noms de marques concurrentes, susceptibles de motiver un refus. Ces limites peuvent évoluer : vérifiez-les dans les consoles.
Captures d’écran et visuels
Les captures d’écran pèsent souvent davantage que la description dans la décision de téléchargement. Montrez les écrans clés avec une courte légende. Elles doivent refléter fidèlement l’application : des visuels trompeurs sont un motif de refus. Apple et Google publient les formats attendus selon les tailles d’écran ; si votre application fonctionne sur iPad, sur Apple Watch ou sur tablette Android, prévoyez des captures spécifiques. Pour Plouf Check, l’app Apple Watch a ainsi demandé ses propres visuels.
Étape 3 : les déclarations de confidentialité
C’est l’étape la plus sous-estimée. Les deux stores exigent une description précise des données collectées par l’application, y compris par les bibliothèques tierces qu’elle intègre : mesure d’audience, publicité, rapports de plantage, authentification.
- App Store : les étiquettes de confidentialité, renseignées dans App Store Connect, indiquent les types de données collectées, leur finalité, leur éventuel rattachement à l’identité de l’utilisateur et leur usage à des fins de suivi. Apple attend aussi des manifestes de confidentialité dans l’application et dans certains SDK tiers.
- Google Play : la section « Sécurité des données » décrit les données collectées et partagées, leur finalité, leur chiffrement en transit et la possibilité d’en demander la suppression.
- Politique de confidentialité : une URL publique vers une politique de confidentialité est obligatoire sur les deux plateformes. Elle doit rester accessible et cohérente avec vos déclarations comme avec le comportement réel de l’application.
Une incohérence peut entraîner un refus, voire un retrait ultérieur : inventoriez chaque SDK avec vos développeurs avant de remplir les formulaires.
La suppression de compte
Si votre application permet de créer un compte, elle doit aussi permettre de le supprimer depuis l’application. Google Play demande en outre un lien web permettant de demander la suppression du compte et des données associées. Une simple désactivation ne suffit généralement pas. Cette fonctionnalité, qui touche aussi le back-office, doit donc figurer dès le cahier des charges.
Étape 4 : tester avant de soumettre
TestFlight côté Apple
TestFlight distribue des versions de test à deux catégories de personnes : les testeurs internes, membres de votre équipe App Store Connect, qui reçoivent les versions sans examen préalable, et les testeurs externes, invités par courriel ou par lien public, pour lesquels la première version passe un examen bêta par Apple. Chaque version de test reste disponible 90 jours.
Les pistes de test de Google Play
La Play Console propose des tests internes, à diffusion très rapide, des tests fermés sur liste d’adresses et des tests ouverts. Pour un nouveau compte personnel, c’est le test fermé qui permet de satisfaire l’exigence des 12 testeurs pendant 14 jours. Recrutez des testeurs réellement actifs : Google vous interroge sur le déroulement du test au moment de demander l’accès à la production.
Testez sur de vrais appareils, avec des versions de système variées et en conditions dégradées : réseau lent, mode avion, permissions refusées.
Les exigences des stores sont des spécifications à part entière : une publication réussie se prépare dès le début du projet, pas la veille du lancement.
Étape 5 : l’examen et les motifs de refus fréquents
Chaque version soumise sur l’App Store est examinée par les équipes d’Apple. L’examen est généralement rapide, mais sa durée reste variable et aucun délai n’est garanti : prévoyez une marge avant toute date de lancement annoncée. Google Play examine également les applications, et une première publication peut demander plus de temps qu’une simple mise à jour.
Les motifs de refus les plus fréquents sont bien identifiés :
- plantages et bugs constatés par l’examinateur, ou fonctionnalités inaccessibles ;
- absence de compte de démonstration lorsque l’application exige une connexion : fournissez des identifiants de test valides et des instructions claires dans les notes destinées à l’examen ;
- contenu provisoire : textes de remplissage, liens cassés, écrans « bientôt disponible » ;
- fonctionnalités trop limitées, par exemple une application qui se contente d’afficher un site web ;
- paiements : les contenus numériques vendus dans l’application doivent en principe passer par l’achat intégré, avec des exceptions qui varient selon les pays et les règles en vigueur ;
- confidentialité : déclarations incomplètes, politique absente, permissions demandées sans explication claire ;
- métadonnées trompeuses : captures ou descriptions qui ne correspondent pas à l’application.
Un refus n’est pas une impasse : le message cite la règle concernée, et vous pouvez répondre, corriger ou faire appel depuis la console. Une correction ciblée suffit souvent.
Étape 6 : maîtriser la mise en ligne
Une fois l’application validée, vous pouvez la publier immédiatement, à une date choisie ou manuellement. Les deux plateformes proposent aussi un déploiement progressif des mises à jour, par étapes sur l’App Store et par pourcentage d’utilisateurs sur Google Play. Surveillez alors de près les rapports de plantage et les avis.
Après la publication : mises à jour et maintenance
Publier une application, c’est s’engager dans la durée. Plusieurs échéances reviennent chaque année :
- Nouvelles versions d’iOS et d’Android : chaque version majeure peut modifier le comportement de votre application, ses permissions ou son interface.
- Niveau d’API cible sur Google Play : Google exige chaque année que les nouvelles applications et les mises à jour ciblent un niveau d’API Android récent. À défaut, vous ne pourrez plus publier de mises à jour, et l’application peut cesser d’être proposée aux nouveaux utilisateurs des versions récentes d’Android.
- Outils Apple : Apple impose régulièrement une version minimale de Xcode et du SDK pour soumettre de nouvelles versions.
- Bibliothèques tierces et déclarations : les SDK évoluent, et toute nouvelle collecte de données impose de mettre à jour les fiches de confidentialité.
- Comptes et contrats : renouvellement de l’adhésion Apple, acceptation des nouveaux accords dans les consoles.
Prévoyez donc un budget de maintenance dès le départ. Le choix entre développement natif ou multiplateforme influe d’ailleurs directement sur l’effort nécessaire pour suivre ces évolutions. Sur Plouf Check, chaque nouvelle version d’iOS et de watchOS est l’occasion de revérifier l’app Apple Watch, les widgets et les raccourcis Siri, qui dépendent étroitement des évolutions du système.
Check-list avant soumission
- Comptes développeur ouverts au nom de l’entreprise, accès partagés avec le prestataire.
- Test fermé d’au moins 14 jours avec au moins 12 testeurs planifié, pour un nouveau compte personnel Google Play.
- Politique de confidentialité en ligne, étiquettes de confidentialité et section « Sécurité des données » cohérentes.
- Suppression de compte disponible dans l’application si la création de compte existe.
- Compte de démonstration et notes pour l’examinateur.
- Captures, textes et mots-clés prêts pour chaque langue, tests réalisés sur appareils réels.
- Marge de calendrier prévue avant tout lancement annoncé.
En résumé
Publier une application suppose d’ouvrir des comptes développeur (99 USD par an chez Apple, 25 USD une seule fois chez Google), de soigner la fiche, de déclarer précisément les données collectées et de tester avant l’examen. Les pièges les plus coûteux sont prévisibles : test fermé obligatoire pour les nouveaux comptes personnels Google Play, suppression de compte, cohérence des déclarations de confidentialité. Ensuite, l’application doit suivre chaque année l’évolution des systèmes et des règles des stores.
Web Solutis conçoit, publie et maintient des applications iOS et Android pour les entreprises et les collectivités. Découvrez notre offre de développement d’applications ou contactez-nous pour préparer votre projet.
