Où héberger une politique de confidentialité quand on n'a pas de domaine

Vous n’avez pas besoin d’un domaine pour publier une politique de confidentialité : il vous faut une URL publique qui se charge sans connexion et qui se chargera encore dans deux ans. Les deux stores vérifient le lien, et la documentation App Privacy d’Apple liste « the URL to your publicly accessible privacy policy » (l’URL de votre politique de confidentialité accessible publiquement) comme champ obligatoire. La seule question est de savoir où la mettre.

Voici six endroits que les développeurs utilisent réellement, avec ce que chacun coûte vraiment. Aucun n’est mauvais pour tout le monde ; ils échouent à des endroits différents.

1. Un hébergeur statique sur un sous-domaine qu’il vous fournit

GitHub Pages, Cloudflare Pages, Netlify, Vercel. Gratuit, rapide, et l’URL reste stable tant que le compte existe.

Où ça casse : la page de suppression de compte. Un hébergement statique sert des fichiers ; il ne peut pas recevoir une demande. Si votre app a des comptes, Google Play exige une route web où un utilisateur peut demander la suppression — vous finissez donc par afficher une adresse email sur une page statique, à la merci des scrapers, ou par greffer un service de formulaires tiers qui voit désormais les adresses email de vos utilisateurs. Ça casse aussi si vous renommez un jour le dépôt ou le projet, car l’URL change et la fiche du store, elle, ne change pas.

2. Un lien vers un document — Google Docs, Notion, un PDF

La solution la plus rapide du monde, et celle dont les reviewers se méfient le plus.

Où ça casse : les paramètres de partage. Un document « tous les utilisateurs disposant du lien » aujourd’hui devient « personnes de votre organisation » après un changement de politique de l’espace de travail, et personne ne vous prévient. Les pages Notion sont dépubliées. Sur certains appareils, un PDF est un téléchargement, pas une page. Au-delà de la mécanique, cela fait improvisé, ce qui est exactement l’impression que vous ne voulez pas associer à une soumission déjà examinée pour autre chose.

3. Firebase Hosting

Une offre gratuite, un vrai domaine qui vous est attribué, text/plain servi correctement — et explicitement cité par AdMob comme un emplacement acceptable pour app-ads.txt, ce qui est pratique si vous affichez aussi des publicités.

Où ça casse : comme tout hébergeur statique pour la suppression de compte, et en plus vous devez maintenir une étape de déploiement pour cinq pages de texte. Viable si Firebase fait déjà partie de votre stack, une charge en plus sinon.

4. Une page sur un site que vous ne contrôlez pas

Un profil sur un réseau social, une page sur le site d’un éditeur, le blog d’un ami.

Où ça casse : partout, tôt ou tard. Vous ne pouvez pas corriger un lien cassé sur le site de quelqu’un d’autre au moment où une review est bloquée à cause de lui, et compter sur un reviewer qui accepterait un profil de réseau social comme politique de confidentialité n’est pas un plan.

5. Acheter un domaine et l’héberger vous-même

Environ 12 $ par an plus un après-midi. La bonne réponse si vous comptiez de toute façon avoir un site vitrine.

Où ça casse : les renouvellements et le problème de réception. Un domaine expiré fait tomber au même instant l’URL de confidentialité, l’URL de support et l’URL de suppression d’une fiche en ligne sur le store, et vous l’apprenez par le store. Si vous choisissez cette voie, mettez le renouvellement sur une carte qui n’expire pas et programmez un rappel un mois avant.

6. Une page de conformité hébergée

Un service qui vous fournit les cinq pages sur une URL qui lui appartient.

Où ça casse : ce qui se passe quand vous arrêtez de payer. C’est la question à poser avant de coller l’URL où que ce soit, et il est légitime de nous la poser aussi — voir plus bas.

L’exigence qui en élimine la moitié

Si votre app a des comptes, vous ne publiez pas une page, vous publiez un ensemble : la politique de confidentialité, et une route web où un utilisateur peut demander la suppression de son compte. Google Play demande à la fois un parcours dans l’app et un lien web public. Une page qui ne fait qu’afficher du texte ne peut pas répondre au second, c’est pourquoi les options 1 à 3 se transforment discrètement en « plus un service de formulaires » dès que vous y arrivez.

Tranchez la question une fois, pour les cinq URL, plutôt que de régler la politique de confidentialité ce soir et de redécouvrir le problème au prochain rejet.

Quel que soit votre choix, vérifiez-le comme le fera un reviewer

Déconnecté, dans une fenêtre de navigation privée, sur des données mobiles plutôt que sur votre propre réseau :

curl -i https://your-url.example/privacy

200 OK et un contenu lisible. Les problèmes courants sont un 404, une redirection vers une page de connexion, ou une page qui ne fonctionne sur votre ordinateur que parce que vous êtes connecté au service qui l’héberge.

Ce que fait AppFoyer

Les cinq pages sont mises en ligne sur le propre sous-domaine de votre app, sans domaine ni serveur à vous, et la page de suppression de compte peut réellement recevoir une demande — elle l’enregistre et vous notifie. La notification par email est incluse dans toutes les offres, y compris la gratuite ; Telegram et Slack sont dans les offres payantes. C’est vous qui effectuez la suppression dans vos propres systèmes ; nous n’y avons aucun accès et ne prétendons jamais le contraire.

La question légitime, avec sa réponse : si vous arrêtez de payer, la page de suppression de compte reste en ligne, indéfiniment. Vos utilisateurs ne nous ont pas choisis 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. Une app est gratuite, sans carte bancaire.

Les sources de référence

• Privacy policy requirements — Aide Google Play
• App privacy details on the App Store — Apple
• Provide information about data deletion — Aide Google Play