AppFoyer : les pages de conformité que réclament les stores

Développer l'application, c'était la partie que vous vouliez faire. Puis le store réclame une URL de politique de confidentialité, une URL d'assistance, une URL de suppression de compte et — si vous affichez de la publicité — un fichier app-ads.txt sur un domaine que vous contrôlez. Rien de tout cela n'était votre motivation de départ, et rien ne peut être sauté.

AppFoyer existe exactement pour ce vide. Il donne à une application mobile un site hébergé et conforme aux exigences des stores — accueil, politique de confidentialité, conditions d'utilisation, assistance, suppression de compte et app-ads.txt — sans posséder de domaine, sans serveur, sans backend.

Nous l'avons d'abord construit pour nos propres dictionnaires : environ 110 versions Android et une application iOS, chacune ayant besoin des mêmes quelques pages, et à nouveau chaque fois qu'un store change d'avis.

Où un site est réellement obligatoire

Il est facile de supposer qu'une petite application n'a pas besoin de site. La file de validation n'est pas d'accord, et de façon très précise :

• Google Play exige une URL de politique de confidentialité pour chaque application, et une URL de suppression de compte accessible pour toute application avec des comptes — la page doit être trouvable depuis l'extérieur, pas seulement depuis un écran de réglages enfoui.
• l'App Store d'Apple exige une URL de politique de confidentialité sur chaque fiche et une URL d'assistance qui mène à une vraie page. Une page vide ou un lien mort, c'est un refus.
• Les régies publicitaires — AdMob, AppLovin, Unity et les autres — lisent app-ads.txt depuis le site développeur indiqué sur votre fiche. Une erreur ici fait perdre discrètement à votre inventaire son statut de vendeur autorisé, ce qui se voit comme une perte de revenus, pas comme un message d'erreur.

Chacun de ces points est une URL. Pas une page d'accroche, pas une marque, pas un site vitrine — une adresse qui renvoie une vraie page quand un validateur ou un robot la demande.

Ce que vous obtenez

Cinq pages et un fichier publicitaire, chacun écrit pour ce que les stores vérifient réellement :

• Politique de confidentialité — générée à partir de la vraie liste de SDK de votre application. L'éditeur demande quels SDK d'analyse, de publicité et de rapport de plantage vous utilisez, et la liste de contrôle intégrée continue de signaler la page tant que chaque espace réservé n'est pas remplacé par quelque chose de vrai.
• Conditions d'utilisation — un modèle simple couvrant l'usage de l'application, les achats et la responsabilité. Si votre application vend quelque chose, le CLUF standard d'Apple est ajouté en lien.
• Page d'assistance — l'URL d'assistance que les deux stores réclament : votre adresse de contact et les éléments que cherchent les validateurs.
• Suppression de compte — la page exigée par Google Play. Un utilisateur envoie une demande, AppFoyer l'enregistre et vous prévient. C'est vous qui effectuez la suppression dans vos propres systèmes ; AppFoyer ne touche jamais aux données de vos utilisateurs et ne prétend jamais avoir supprimé quoi que ce soit à votre place.
• app-ads.txt — des préréglages pour AdMob, AppLovin, Unity et d'autres, avec validation ligne par ligne. Servi en texte brut sans redirection, ce qui est exactement ce qu'exigent les robots.

À côté, une liste de contrôle de conformité qui indique ce qui manque encore et pourquoi tel store le demande. La question « est-ce que j'ai fini ? » a ainsi une réponse autre que resoumettre en croisant les doigts.

Deux façons d'y arriver

Si vous utilisez Claude Code, installez l'extension AppFoyer et dites : « rends cette application prête pour les stores ». L'agent lit votre vrai code — votre manifeste, vos dépendances, vos SDK — et rédige chaque page à partir de ce qu'il trouve. Vous relisez, corrigez et publiez.

Sinon, le formulaire web demande six champs et vous rend une URL en ligne. Mêmes pages, même liste de contrôle.

Dans les deux cas, les pages sont ensuite les vôtres et restent modifiables. Rien n'est enfermé derrière l'agent.

Ce que cela coûte

Il existe un plan gratuit, et l'essentiel est ce qui n'en est pas absent : rien de ce qu'un store exige n'est derrière un paywall. Toutes les pages ci-dessus, la liste de contrôle et app-ads.txt sont dans le plan gratuit. Il couvre une application publiée et les notifications par e-mail — soit la totalité du travail pour un développeur avec une application sur le store. L'inscription demande une adresse e-mail, sans carte bancaire.

Au-dessus, Pro et Advanced. Ils vendent de l'échelle, pas de la conformité : davantage d'applications publiées, un sous-domaine de votre choix au lieu d'un sous-domaine généré, et Telegram et Slack en plus de l'e-mail pour les notifications de suppression. Si vous publiez une seule application, le plan gratuit n'est pas un essai — c'est le produit. Les formules actuelles sont sur appfoyer.com/pricing.

Une réserve honnête

AppFoyer génère des documents à partir de modèles et de ce que vous lui dites de votre application. Ce n'est pas un conseil juridique, et l'outil ne prétend pas l'être. Si votre application traite des données de santé, des données d'enfants, des paiements ou autre chose ayant ses propres règles, faites relire ce que vous publiez par un avocat. L'outil supprime la page blanche, l'hébergement et la question de savoir quelle URL va dans quel champ du store — pas votre responsabilité sur le contenu.

Essayer

Si une application attend chez vous une URL de politique de confidentialité, c'est quelques minutes de travail : appfoyer.com. Il existe aussi une visite guidée du produit si vous voulez voir le tableau de bord avant de vous inscrire.