Toutes les URL que demande votre fiche du store. C'est fait.

Non. Chaque app a son propre sous-domaine, et c'est cette URL que vous collez dans la console du store. Si vous possédez déjà un domaine, vous pouvez toujours l'utiliser pour le site marketing de votre app — ces pages-ci sont celles de la conformité.

Pas aujourd'hui. Avec l'offre Pro, vous pouvez remplacer le sous-domaine aléatoire par un nom de votre choix — dans le respect de règles de nommage qui refusent les mots réservés, les noms de marques et les mots évoquant une connexion comme « login ». Les domaines personnalisés ne font pas encore partie du produit.

Non, et il ne le peut pas. La page de suppression de compte recueille la demande, l'enregistre et vous prévient. Supprimer le compte dans votre propre backend reste à votre charge — c'est précisément ce que Google Play exige de vous. Toute formulation laissant entendre le contraire serait fausse.

Ce sont des modèles que vous complétez, pas un conseil juridique. Elles couvrent ce que demandent les stores et chaque page indique clairement que le développeur est responsable de son exactitude. Si votre app est exploitée dans un pays aux exigences particulières, faites-les relire par un avocat.

Oui. En octobre 2026, AdMob a indiqué « app-ads.txt file found and verified » pour des apps dont le site web du développeur est un sous-domaine AppFoyer, sur l'App Store comme sur Google Play. Le fichier est servi comme l'exige la spécification — texte brut, HTTP 200, sans redirection. Indiquez votre URL AppFoyer comme site web dans votre fiche du store et laissez à AdMob jusqu'à 24 heures pour l'explorer. Nous n'avons encore aucun résultat d'exploration de notre côté pour les autres réseaux publicitaires.

Chaque site répond aussi sur un second domaine : la même adresse avec .app au lieu de .page. Mêmes pages, même slug, même app-ads.txt — un site, deux adresses. Certains pays et réseaux bloquent des domaines de premier niveau entiers ; si .page est inaccessible pour vous ou vos utilisateurs, utilisez l'adresse .app dans votre fiche du store et dans votre app. Vous choisissez l'adresse qu'affiche le tableau de bord en un clic.

Rien du tout tant que le paiement est encore retenté — cela dure deux à quatre semaines et aucun compte à rebours de notre part ne démarre pendant ce temps. Une fois l'abonnement réellement annulé, vous repassez à l'offre gratuite : vous choisissez l'app qui reste publiée, les autres restent en ligne mais en lecture seule pendant une semaine, puis sont mises hors ligne au bout de trois semaines. Vous recevez un e-mail au jour 0, au jour 7 et au jour 18. Rien n'est supprimé à aucun moment, et votre sous-domaine personnalisé vous est réservé et n'est jamais attribué à quelqu'un d'autre — vous réabonner rétablit tout en une publication.

Ils le peuvent toujours. La page de suppression de compte est la seule page que nous continuons à servir après la dépublication d'une app — en lecture seule, masquée des moteurs de recherche, sans limite de durée. Les demandes vous parviennent toujours par e-mail. Vos utilisateurs n'ont jamais choisi AppFoyer et ne savent rien de votre facturation ; leur faire perdre le moyen de vous joindre à cause d'une facture impayée serait notre erreur, pas la vôtre. Le fichier qui s'arrête immédiatement, c'est app-ads.txt, parce que ce sont les réseaux publicitaires qui l'exigent, pas un store d'applications.

C'est la question légitime à poser à un service d'hébergement, c'est pourquoi la réponse figure dans nos Conditions et pas seulement dans un article de blog. Si nous arrêtons un jour le service, vous êtes prévenu au moins douze mois à l'avance : vos pages restent en ligne pendant toute cette période, et les nouvelles inscriptions s'arrêtent immédiatement pour que personne ne commence une soumission avec une URL appelée à disparaître. Vous pouvez modifier et republier pendant les trois premiers mois ; ensuite les pages continuent d'être servies mais ne changent plus, rien n'est facturé pendant les neuf mois restants, et une période payée d'avance est remboursée au prorata. Exportez tout — le Markdown de chaque page, votre app-ads.txt, vos réglages et votre journal des demandes de suppression — dès le jour de l'annonce.

Demandez-le dans les 14 jours suivant n'importe quel prélèvement — le premier ou un renouvellement — et vous êtes remboursé intégralement, sans avoir à vous justifier. L'annulation se fait en un clic dans le portail client, et vous gardez l'offre jusqu'à la fin de la période payée.

Oui. Les éditeurs de la politique de confidentialité et des conditions ont chacun un prompt prêt à l'emploi, déjà rempli avec le nom de votre app, le développeur, l'e-mail de support, les liens vers les stores et les données que vous avez déclarées. Lancez-le dans n'importe quel assistant — idéalement un agent de code ouvert dans le dépôt de votre app, pour qu'il nomme les SDK que votre build embarque réellement au lieu de deviner —, répondez à ses questions et collez la réponse. Elle arrive dans l'éditeur, pas sur votre site : vous la lisez et la publiez vous-même. Les deux prompts sont reproduits dans nos guides, et si vous utilisez Claude Code, le plugin AppFoyer fait ce travail pour chaque page sans copier-coller.

Il prépare les réponses ; c'est vous qui les saisissez. Cochez les SDK inclus dans votre build, ou laissez le plugin Claude Code les trouver, et l'onglet Store forms liste chaque type de données sur lequel chaque store pose des questions. Il indique s'il est collecté ou partagé, associé à l'utilisateur ou utilisé pour le suivi, et les finalités. Chaque réponse cite sa source : la déclaration de l'éditeur du SDK, son privacy manifest, ou notre lecture de la liste de données de l'éditeur. Les questions auxquelles vous seul pouvez répondre, comme le chiffrement en transit, sont signalées pour que vous les vérifiiez. Rien n'est soumis à un store, et les réponses ne sont pas un conseil juridique.

Vos pages décrivent l'ancien build jusqu'à ce que vous les mettiez à jour, et les deux stores attendent que vous le fassiez. Une vérification gratuite le détecte sur la pull request : le plugin Claude Code enregistre dans appfoyer.json ce à partir de quoi les pages ont été rédigées, et une GitHub Action compare avec lui les fichiers de build de chaque pull request. Un nouveau SDK ou une nouvelle permission apparaît dans le résumé du job avec son fichier et sa ligne, et relancer le plugin met à jour les brouillons et l'enregistrement. Elle ne lit que les fichiers de build et ne modifie jamais une page.

Une fois connecté, ouvrez Support dans le tableau de bord et écrivez-nous — sur toutes les offres, y compris Free. C'est de la messagerie, pas un chat en direct : nous répondons quand nous voyons votre message, et la réponse s'affiche sur le même écran. Avant de vous inscrire, ou si vous préférez, écrivez à support@appfoyer.com.

Oui. Chaque page est en Markdown avec un aperçu en direct, que le premier brouillon vienne d'un modèle ou de votre agent. Rien n'est publié tant que vous ne le publiez pas.