Lancer une application mobile : visibilité, publicité et sécurité, le guide complet

Une application qui fonctionne, c’est la moitié d’un lancement. L’autre moitié décide si quelqu’un la trouve, l’installe et lui confie ses données : comptes développeur et déclarations de confidentialité, fiche rédigée pour la recherche dans les stores, site web, éventuellement publicité, et contrôles de sécurité qui empêchent les données d’un utilisateur d’atterrir chez un autre.

Ce guide explique comment lancer une application mobile en quatre étapes, dans l’ordre où je les aborderais. Il s’adresse aux petites équipes, que le code vienne d’un développeur, d’une agence ou d’un outil d’IA, et chaque section renvoie à l’article détaillé de l’étape.

Je développe des applications de bout en bout pour des clients, et des logiciels pour mon propre usage : je sais ce que c’est d’avoir besoin d’un outil et de le construire. Présenter une application à des inconnus est un autre métier, et c’est ce métier que couvre ce guide. Les prix et les règles cités ici sont ceux du 19 octobre 2026.

Lancer une application mobile : les quatre étapes en bref

L’ordre compte plus que n’importe quelle astuce. Une publicité qui envoie vers une fiche faible gaspille le budget, une fuite de données découverte après le lancement coûte bien plus cher qu’une fuite repérée avant, et la règle de test de Google peut retarder de plusieurs semaines une sortie Android si vous la découvrez trop tard.

Avant le lancement : comptes développeur et tests

Apple : l’Apple Developer Program

Pour publier sur l’App Store, il faut adhérer à l’Apple Developer Program. Apple l’affiche à 99 dollars US par année d’adhésion et indique le montant en euros pendant l’inscription ; vérifiez-le sur la page d’inscription d’Apple (en anglais) avant de budgéter (octobre 2026).

Vous pouvez vous inscrire comme particulier ou comme organisation. Une organisation doit être une entité juridique avec un numéro D-U-N-S, une adresse email professionnelle sur son propre nom de domaine et un site web public et fonctionnel sur ce domaine. Apple refuse les pages de réseaux sociaux, les sites presque vides et les pages d’attente des bureaux d’enregistrement : si votre application n’a pas encore de site, créez-le maintenant, il vous servira pour les stores comme pour Google.

Google Play : la Play Console

Google Play facture des frais d’inscription uniques de 25 dollars US (une vingtaine d’euros), payés par carte (aide de la Play Console, octobre 2026). L’inscription peut prendre jusqu’à 48 heures, et Google peut demander une pièce d’identité au nom légal du titulaire du compte.

L’étape qui surprend : un compte personnel créé après le 13 novembre 2023, donc tout nouveau compte, doit mener un test fermé avec au moins 12 testeurs inscrits pendant 14 jours d’affilée avant de pouvoir demander l’accès à la production (règle de Google pour les nouveaux comptes personnels). Réunissez vos testeurs (clients, salariés, proches équipés d’Android) avant d’en avoir besoin, et prévoyez au moins trois semaines entre le début du test et votre sortie Android.

iPhone ou Android d’abord ?

Si vous ne pouvez pas sortir les deux versions en même temps, commencez là où sont vos clients. En France, d’après les estimations de trafic web de Statcounter pour août 2026, environ un tiers du trafic mobile vient d’iPhone et deux tiers d’Android ; au Royaume-Uni, l’iPhone pèse environ la moitié. Vos propres chiffres, ceux de votre site ou de votre fichier clients, valent mieux que n’importe quelle moyenne nationale.

Créée avec l’IA, par une agence, ou pour votre seule équipe

La façon dont l’application a été construite change les risques, pas les étapes du lancement. Si vous la construisez vous-même, mon article sur ce qui est réaliste quand on crée une application avec l’IA trace la limite : les générateurs d’applications par IA conviennent à un petit outil pour vous ou votre équipe, et un développeur devient nécessaire dès que l’application stocke des données de clients, leur ouvre des comptes ou encaisse des paiements. L’IA a beaucoup raccourci mes propres délais de livraison ; elle n’a pas raccourci cette liste.

Si l’application ne sert qu’à votre équipe, comme le CRM interne que j’ai développé pour un client débordé de prospects, la moitié marketing de ce guide ne vous concerne pas : personne n’a besoin de la trouver dans un store ni de cliquer sur une annonce. La moitié confidentialité et sécurité, elle, s’applique toujours.

Confidentialité : ce que demandent les stores, ce qu’exige la loi

Deux chantiers se confondent souvent. Les stores veulent une description des données que collecte votre application ; la loi, dans l’UE comme au Royaume-Uni, exige le consentement de vos utilisateurs avant certaines de ces collectes.

• Les étiquettes de confidentialité d’Apple : depuis le 8 décembre 2020, toute nouvelle application et toute mise à jour exigent des réponses sur la confidentialité dans App Store Connect, affichées sur votre fiche. Elles couvrent les SDK que vous ajoutez autant que votre propre code.
• La section Sécurité des données de Google Play : obligatoire depuis le 20 juillet 2022 pour toutes les applications, même celles qui ne collectent rien, à remplir dans la Play Console sous Contenu de l’application.
• La suppression du compte : si l’on peut créer un compte dans votre application, Apple exige depuis le 30 juin 2022 qu’on puisse lancer sa suppression depuis l’application, et Google Play demande une option dans l’application plus un lien web.
• Le suivi sur iOS : depuis iOS 14.5 (26 avril 2021), avec App Tracking Transparency, vous devez afficher la fenêtre d’Apple et obtenir l’accord de l’utilisateur avant de le suivre dans les applications et sites d’autres entreprises ou de lire l’identifiant publicitaire.

Mon tutoriel sur le consentement RGPD, les étiquettes Apple et la section Sécurité des données détaille les deux formulaires et le consentement qu’exigent vos SDK.

En France, les SDK de mesure d’audience et de publicité qui lisent ou écrivent des données sur le téléphone exigent en général un consentement préalable. Comme pour un site, la CNIL n’en dispense qu’une mesure d’audience très encadrée : des statistiques anonymes pour votre seul usage, sans recoupement ni transmission à des tiers. Ses recommandations sur les applications mobiles (septembre 2024) précisent aussi qu’une autorisation du système d’exploitation ne doit pas être confondue avec le consentement au sens du RGPD. Le Royaume-Uni a assoupli la règle depuis le 5 février 2026 pour la mesure d’audience purement statistique, pas pour la publicité. Pour tout le reste, voyez mon guide du RGPD pour les petites équipes, en Europe et hors d’Europe.

Ce guide présente les règles et les recommandations officielles ; ce n’est pas un conseil juridique. Si votre application traite des données de santé, des données financières ou des données d’enfants, faire relire votre dispositif par un avocat ou un DPO avant le lancement est une dépense utile.

Sécurité : les contrôles à faire avant de publier

L’examen des stores porte sur l’application que vous soumettez, pas sur le serveur qui est derrière : une application peut être acceptée et livrer quand même les données d’un utilisateur à un autre. Quatre articles couvrent ce travail, dans cet ordre :

1. La checklist de sécurité avant lancement traduit l’OWASP MASVS, le standard de référence de la sécurité des applications mobiles, en contrôles faisables avant la sortie : aucune clé secrète dans l’application, des droits vérifiés par le serveur à chaque requête, des jetons gardés dans le trousseau d’iOS ou l’Android Keystore, un trafic chiffré, des SDK audités et un moyen public de signaler une faille.
2. Les clés API dans une application mobile explique pourquoi n’importe qui peut extraire une clé de votre application, et où placer les clés secrètes de services comme OpenAI, Claude ou Stripe : sur un serveur, derrière une petite fonction qui vérifie d’abord l’utilisateur.
3. Votre application créée avec l’IA laisse-t-elle fuiter des données ? concerne les applications que l’outil d’IA a reliées directement à Supabase ou Firebase. Là, la sécurité RLS ou les règles de sécurité de Firebase sont le seul verrou sur vos données, et le tutoriel montre comment les tester comme le ferait un inconnu.
4. Le Cyber Resilience Act et votre app couvre le règlement qui s’ajoute désormais à tout cela.

Le Cyber Resilience Act (règlement (UE) 2024/2847, texte intégral sur EUR-Lex) fait de la sécurité une obligation légale autant que pratique. Au 19 octobre 2026, ses obligations de signalement s’appliquent depuis le 11 septembre 2026 : si une faille de votre application est activement exploitée, ou si un incident grave la touche, vous envoyez une alerte précoce sous 24 heures via la plateforme unique de signalement de l’ENISA (article 14). La plupart des autres exigences, dont les mises à jour de sécurité pendant la période d’assistance et le marquage CE, s’appliquent à partir du 11 décembre 2027 aux nouvelles applications, et aux applications déjà sur le marché qui subissent ensuite une modification substantielle (article 69). Les microentreprises et les petites entreprises ne peuvent pas être sanctionnées pour une alerte précoce manquée (article 64, paragraphe 10), mais la notification sous 72 heures et le rapport final restent dus.

Pour le reste de votre activité (gestionnaire de mots de passe et double authentification, sauvegardes, vérification avant de payer un nouveau RIB, plan pour la première heure d’un incident), voyez mon guide de la cybersécurité pour les petites équipes.

Être visible : l’ASO dans l’App Store et Google Play

L’ASO, c’est le référencement des applications dans l’App Store et Google Play : choisir les mots que chaque store compare aux recherches, puis rendre la fiche assez convaincante pour qu’on installe. Les deux stores ne lisent pas les mêmes champs, c’est pourquoi un même texte collé dans les deux fonctionne rarement.

Commencez par mon guide ASO pour débutants, qui explique comment chaque store classe les applications et ce que vous maîtrisez. La recherche de mots-clés ASO montre ensuite comment trouver les mots vraiment tapés dans les stores, des expressions de vos utilisateurs aux suggestions des stores, aux fiches concurrentes et à l’indice de popularité d’Apple Ads, et pourquoi une nouvelle application doit viser des expressions précises avant les termes larges. Le tutoriel sur la fiche App Store et Google Play transforme ces mots en nom, sous-titre, champ de mots-clés et description qui respectent la limite de chaque champ.

Écrivez la première ligne de la description comme une phrase simple qui dit ce que fait l’application et pour qui, et faites en sorte que vos premières captures montrent exactement cela. Une fois le trafic régulier, les deux stores permettent de tester des variantes : l’optimisation de la page produit d’Apple oppose jusqu’à trois variantes à votre page d’origine, et les tests de fiche de Google Play en font autant.

Le site de votre application : la moitié que Google voit

Les stores classent votre fiche ; Google classe votre site. Ils répondent à des recherches différentes, donc votre site a besoin de ses propres mots-clés : ceux qu’on tape dans Google avant de connaître votre application.

Le SEO du site de votre application couvre la landing page (le problème résolu, de vraies captures, les badges officiels des stores, une FAQ), les pages de confidentialité et d’assistance vers lesquelles pointent vos fiches, et les liens entre le site et l’application. Les liens universels d’iOS et les Android App Links ouvrent vos adresses web dans l’application quand elle est installée, et la Smart App Banner d’Apple invite les visiteurs sur iPhone à l’installer sans masquer la page. Si d’anciens liens reposaient sur Firebase Dynamic Links, remplacez-les : Google a fermé le service le 25 août 2025.

Un petit site suffit pour commencer : une landing page, une page de confidentialité et une page d’assistance. Apple en exige d’ailleurs un des organisations qui s’inscrivent : il passe donc en tête de liste. Les sites web représentent une grande part de mon travail, et un site simple peut être en ligne bien avant l’application.

Publicité : Apple Ads, campagnes Google ou Meta

Les installations payées ne rapportent que si la page où elles arrivent convertit. Avant de dépenser, vérifiez que votre fiche transforme les visiteurs en installations, que vous avez quelques avis authentiques et que les installations sont mesurées. Choisissez ensuite une plateforme :

• Apple Ads (Apple Search Ads jusqu’en avril 2025) affiche votre application en tête des résultats de recherche de l’App Store, mais aussi dans l’onglet Aujourd’hui, l’onglet Recherche et sur les fiches d’autres applications. Le tutoriel Apple Ads monte une première campagne pas à pas : mots-clés exacts pour votre marque et votre catégorie, budget quotidien, enchère maximale par tap et campagne de découverte qui repère de nouvelles recherches.
• Les campagnes pour applications de Google Ads transforment vos textes, images et vidéos en annonces sur la recherche Google, YouTube, Discover, le Réseau Display et, pour Android, Google Play, le tout depuis une seule campagne. Le fonctionnement et le budget de ces campagnes détaille la règle qui surprend : Google conseille un budget quotidien d’au moins 50 fois votre coût par installation cible, donc pour 1 € visé, 50 € par jour, soit environ 1 520 € par mois.
• Meta (Facebook et Instagram) touche des gens qui ne cherchent pas encore, ce qui convient à une application qui s’explique en une courte vidéo.

Pour trancher, lisez où investir les 1 000 premiers euros de votre app. Son conseil : une plateforme, pas trois. Apple Ads si l’on cherche dans l’App Store ce que fait votre application et qu’une bonne part de votre public a un iPhone, Google s’il est surtout sur Android, Meta si l’application se vend à l’écran.

Mon avis sur ces plateformes vient de la publicité en général, pas des campagnes d’installation d’applications. Google Ads n’est pas si compliqué, mais il récompense le travail fait en amont pour savoir ce que les gens recherchent ; mon guide Google Ads pour débuter détaille ces recherches. Les publicités Facebook et Instagram fonctionnent pour la notoriété comme pour la conversion, mais une partie du budget part en tests A/B avant de savoir ce qui marche, et sauter ces tests fait partie des erreurs contre lesquelles je mets en garde les fondateurs.

Sur iOS, la mesure est la partie difficile. Depuis App Tracking Transparency, les personnes qui refusent la fenêtre ne peuvent plus être suivies d’une application à l’autre : les plateformes s’appuient alors sur les outils d’attribution d’Apple qui protègent la vie privée (SKAdNetwork et AdAttributionKit) et sur la modélisation. Attendez-vous à des chiffres agrégés et différés plutôt qu’au détail de chaque installation, jugez une campagne sur son coût par installation après deux semaines plutôt qu’après deux jours, et vérifiez que votre SDK de mesure reçoit le choix de consentement de chaque utilisateur (le mode Consentement de Google pour les applications le fait pour Firebase).

Après le lancement : avis, mises à jour et chiffres utiles

Notes et avis

Apple indique que les notes et les avis peuvent influencer le classement de votre application dans la recherche de l’App Store, et ils s’affichent en haut de votre fiche pour chaque visiteur. Obtenir plus d’avis 5 étoiles sans enfreindre les règles des stores explique comment les demander : uniquement par les invites officielles (celle d’Apple, que le système affiche au maximum trois fois par an à chaque personne, et l’API In-App Review de Google Play), juste après un moment de réussite, jamais contre une récompense et jamais seulement aux personnes satisfaites. Les faux avis enfreignent les règles des stores et le Code de la consommation (article L121-4).

Répondez aux avis et corrigez ce qu’ils signalent. Google Play pondère sa note publique en faveur des notes récentes : une mise à jour qui règle une plainte fréquente se voit dans votre note.

Mises à jour et stabilité

Les plantages coûtent deux fois : dans les avis, et sur Google Play en visibilité. Google indique que les principales statistiques Android Vitals d’une application influencent sa visibilité, et qu’au-delà de ses seuils de mauvais comportement (un taux de plantage perçu par les utilisateurs de 1,09 % au total, ou de 0,47 % pour les blocages « L’application ne répond pas ») Google Play peut réduire sa visibilité et afficher un avertissement sur la fiche. Consultez Android Vitals dans la Play Console et vos rapports de plantage chaque semaine pendant le premier mois.

Prévoyez les mises à jour dans le lancement, pas après coup : pour une application publiée ou modifiée de façon substantielle à partir du 11 décembre 2027, le Cyber Resilience Act imposera des mises à jour de sécurité pendant toute sa période d’assistance, en général cinq ans au moins.

Les chiffres utiles

Les téléchargements seuls disent peu de chose. Quatre chiffres montrent où se situe le problème :

1. Impressions et vues de la fiche : les stores montrent-ils votre application ? Des chiffres faibles désignent les mots-clés.
2. Taux de conversion : App Store Connect divise les téléchargements par les impressions uniques, et la Play Console met en regard visiteurs de la fiche et installations. Un taux faible désigne la fiche : captures, première ligne, notes.
3. Installations par source : recherche, navigation dans le store, autres applications, sites web, publicité. App Store Connect indique combien de personnes viennent de la recherche, pas ce qu’elles ont tapé ; la Play Console peut afficher les termes de recherche qui ont mené à votre fiche.
4. Rétention : la part des nouveaux utilisateurs qui ouvrent encore l’application un jour, une semaine et un mois après l’installation. La publicité ne corrige pas une rétention faible ; les changements dans l’application, si.

Votre checklist de lancement, et quand déléguer

1. Comptes développeur ouverts ; pour un nouveau compte Google Play personnel, 12 testeurs prêts pour un test fermé de 14 jours.
2. Un site en ligne avec une landing page, une page de confidentialité et une page d’assistance.
3. Étiquettes Apple et section Sécurité des données remplies pour l’application et ses SDK ; consentement recueilli avant le lancement des SDK de mesure et de publicité ; suppression du compte possible dans l’application.
4. Checklist de sécurité faite : aucune clé secrète dans l’application, règles de la base de données testées, moyen public de signaler une faille.
5. Fiche rédigée à partir de la recherche de mots-clés, avec des captures qui montrent la fonction principale.
6. Demande d’avis placée après un moment de réussite.
7. Installations mesurées, puis une seule plateforme publicitaire avec un seul budget.
8. Une personne désignée et une procédure pour signaler sous 24 heures une faille activement exploitée.

Vous n’avez besoin de personne pour la fiche, la recherche de mots-clés ou les réponses aux avis : c’est de l’écriture, et personne ne connaît vos utilisateurs mieux que vous. Faites appel à un développeur pour les parties où une erreur fait fuiter des données : le serveur, les règles de la base, les clés et la connexion. Payez un test de sécurité indépendant dès que l’application traite des données de santé, financières ou d’enfants.

Quand je développe une application pour un client, je la construis de bout en bout, avec 30 % ou 50 % à la commande et le solde à la livraison. Quel que soit votre prestataire, demandez avant de signer qui s’occupera des comptes des stores, des déclarations de confidentialité et des mises à jour de sécurité après le lancement : ces tâches font partie du lancement d’une application mobile, ce ne sont pas des options.