Votre app a-t-elle besoin d'un site web ?

Les développeurs posent cette question en attendant un oui ou un non, et obtiennent des réponses contradictoires parce que ceux qui répondent traitent des questions différentes. Les voici, toutes les quatre, séparément.

1. Un store exige-t-il un site vitrine ?

Non. Il n’existe aucun champ de console intitulé « site web » sans lequel une soumission échoue.

La fiche Google Play a un champ website dans Store settings → Store listing contact details (Paramètres du store → Coordonnées de la fiche), à côté d’une adresse e-mail et d’un numéro de téléphone. L’e-mail est obligatoire pour publier ; le site web ne l’est pas. App Store Connect a une Marketing URL, explicitement facultative.

Donc si la question est « dois-je construire une page d’accueil avec des captures d’écran et un bouton de téléchargement » — non.

2. Quelque chose exige-t-il une URL ?

Oui, plusieurs choses, et c’est là que se trouve la vraie réponse :

Exigence	Faut-il une URL ?
Politique de confidentialité	Oui. La politique User Data de Play : “All apps must post a privacy policy link in the designated field within Play Console, and a privacy policy link or text within the app itself.” (Traduction : toutes les apps doivent publier un lien vers la politique de confidentialité dans le champ prévu de la Play Console, ainsi qu’un lien ou le texte de la politique dans l’app elle-même.) Apple : un champ Privacy Policy obligatoire
Suppression de compte	Oui, si votre app a des comptes. Une URL web publique, déclarée dans la Play Console sous App content → Data deletion
Support	Oui, chez Apple. Le champ Support URL est obligatoire
app-ads.txt	Oui, si vous affichez des publicités. Les régies le récupèrent à la racine du site du développeur indiqué dans votre fiche

Quatre exigences, quatre URL, et aucune n’est satisfaite par une page vitrine. Ce qu’il vous faut, ce sont des pages, pas un site web au sens où on l’entend quand on pose la question.

3. Alors pourquoi le champ « site du développeur » compte-t-il malgré tout ?

À cause de app-ads.txt. Ce fichier n’est trouvé ni par votre app, ni par votre nom de package, ni par votre compte publicitaire — il est trouvé grâce à l’URL du site web affichée sur votre fiche du store. Le robot lit ce nom d’hôte et récupère /app-ads.txt à sa racine.

Laissez le champ vide et le robot n’a nulle part où commencer, ce qui est la raison la plus fréquente pour laquelle un fichier apparaît comme « not found ». Si vous monétisez avec de la publicité, le champ site web cesse d’être facultatif en pratique.

C’est aussi le seul champ qui relie discrètement les autres : les développeurs qui y indiquent un hôte servant leurs pages de conformité se retrouvent avec les cinq URL sur un seul nom d’hôte, soit une seule chose à maintenir en ligne au lieu de quatre.

4. Et une page d’accueil pour l’app ?

Utile, peu glamour, et pas pour la raison qu’on imagine. Une page simple qui dit ce qu’est l’app, qui la fait et comment joindre ses auteurs remplit trois rôles :

• elle donne au champ site web de la fiche une vraie destination ;
• elle donne à un examinateur qui ouvre vos URL une image cohérente au lieu de cinq pages juridiques orphelines ;
• elle donne au robot app-ads.txt un nom d’hôte que vous contrôlez.

Elle n’a besoin ni de captures d’écran, ni d’image d’en-tête, ni de bouton de téléchargement. Une page de texte suffit.

Ce dont vous pouvez vous passer

• Un domaine, si vous n’en voulez pas déjà un. Voir l’hébergement sans domaine.
• Un site vitrine, sauf si vous faites du marketing.
• Un blog, un kit presse, une liste de diffusion. Rien de tout cela ne relève de la conformité.
• Un serveur, pour tout sauf la suppression de compte — qui a besoin de quelque chose capable de recevoir une demande, pas seulement de servir des fichiers.

Dans quel ordre procéder

1. Choisissez le nom d’hôte unique qui servira l’ensemble.
2. Publiez-y la politique de confidentialité, les conditions, la page de support et la page de suppression de compte.
3. Placez une page d’accueil simple à sa racine.
4. Indiquez ce nom d’hôte comme site web dans votre fiche du store.
5. Ajoutez app-ads.txt à la racine, si vous affichez des publicités.

Remplissez ensuite les champs de la console — pas avant, sinon vous ferez pointer un champ vers une page qui n’existe pas encore.

Ce que fait AppFoyer ici

C’est exactement la forme du produit : votre app obtient son propre sous-domaine avec une page d’accueil, une politique de confidentialité, des conditions, une page de support et une page de suppression de compte, plus app-ads.txt à la racine — sans domaine, sans serveur, sans backend à vous. Vous indiquez ce sous-domaine comme site du développeur dans votre fiche, et chacune des quatre exigences ci-dessus trouve sa réponse sur le même nom d’hôte.

La page de suppression de compte est celle qui fait plus que servir un fichier : elle reçoit la demande, l’enregistre et vous prévient. Une app est gratuite, et rien de ce qu’exige un store n’est payant.

Les sources qui font foi

• Politique User Data — Aide Google Play. La citation ci-dessus provient de cette page.
• Exigences relatives à la politique de confidentialité — Aide Google Play, pour l’emplacement du champ
• Comprendre les exigences de Google Play en matière de suppression de compte — Aide Google Play
• Required, localizable, and editable properties — Apple, le tableau qui marque la Support URL comme obligatoire et la Marketing URL comme non obligatoire
• Configurer app-ads.txt — Aide AdMob