Changer une URL déjà présente dans une fiche en ligne

Tôt ou tard, vous déménagez : un hébergeur gratuit ferme, un domaine a expiré, une société a changé de nom, ou vous avez enfin construit le vrai site que vous aviez toujours prévu. Les champs sont modifiables, donc le changement en lui-même est trivial. Ce qui piège, c’est tout le reste qui pointe discrètement vers l’ancienne adresse.

L’ordre qui ne casse rien

1. Publiez la nouvelle URL et vérifiez-la déconnecté. Elle doit être en ligne avant que quoi que ce soit pointe vers elle.
2. Faites rediriger l’ancienne adresse vers la nouvelle. Pas supprimer — rediriger. C’est l’étape que l’on saute, et c’est celle qui vous sauve.
3. Mettez à jour les champs des consoles. Play Console → App content pour les URL de politique de confidentialité et de suppression des données ; App Store Connect pour la politique de confidentialité et la Support URL. Google Play demande que la politique « is available on an active URL » (soit disponible à une URL active) — le champ ne doit donc jamais pointer vers quelque chose de mort, même brièvement.
4. Mettez à jour les liens dans votre app. La politique User Data de Play exige le lien vers la politique de confidentialité dans Play Console et dans l’app elle-même, et celui de l’app est généralement codé en dur dans un build livré il y a des mois. Les utilisateurs de l’ancienne version continuent d’atteindre l’ancienne URL jusqu’à leur mise à jour, et certains ne mettront jamais à jour.
5. Laissez la redirection en place. Pas une semaine — indéfiniment, si possible.

Procéder dans l’autre ordre — changer d’abord le champ, ou supprimer d’abord l’ancien hébergement — c’est ainsi qu’on se retrouve avec une fiche en ligne pointant vers une 404 pendant un examen.

Pourquoi l’ancienne adresse doit continuer à répondre

Le champ de la console est l’adresse que vous contrôlez. Ce n’est pas le seul endroit où l’ancienne URL existe :

• Les binaires de l’app déjà livrés. Chaque copie installée de chaque version précédente renvoie vers l’ancienne URL. Vous ne pouvez pas les mettre à jour ; les utilisateurs le font, un jour, et certains jamais.
• Le cache de la fiche et les sites agrégateurs qui ont récupéré votre fiche.
• Les e-mails et reçus que vous avez déjà envoyés.
• Les enregistrements des réseaux publicitaires, si l’ancien hôte était votre site web du développeur déclaré.

« L’ancienne URL est morte mais le champ est à jour » n’est donc vrai que de votre côté.

L’exception : app-ads.txt ne doit pas être redirigé

Un cas particulier, et c’est celui qui coûte de l’argent sans bruit. Les réseaux publicitaires récupèrent /app-ads.txt à la racine du site web indiqué dans votre fiche, et la spécification attend qu’il soit servi directement. Une redirection devant lui est une cause fréquente de résultat « introuvable », même quand le fichier est parfaitement correct.

Donc, si l’ancien hôte était votre site web du développeur déclaré et que vous le gardez comme redirection, /app-ads.txt sur cet hôte doit être servi avec un 200 plutôt que redirigé tant que l’ancienne adresse risque encore d’être explorée. Tout le reste peut répondre en 301 ; ce chemin-là, non.

Ce qu’il faut vérifier après le déménagement

Lancez ces commandes déconnecté, dans une fenêtre privée :

curl -i https://old-host.example/privacy        # expect 301 to the new URL
curl -i https://new-host.example/privacy        # expect 200
curl -i https://old-host.example/app-ads.txt    # expect 200 text/plain, NOT a redirect

Puis dans les consoles : chaque champ d’URL ouvre la bonne page, et les réponses Data safety / App Privacy correspondent toujours à ce que disent les nouvelles pages. Déplacer une page est un bon moment pour remarquer que la politique est devenue obsolète il y a deux SDK.

Le changement difficile à annuler

Une URL est une identité, pas un réglage. Une fois qu’elle a figuré dans une fiche, elle existe à des endroits que vous ne contrôlez pas ; c’est pourquoi le déménagement vaut la peine d’être fait une seule fois, délibérément, vers une adresse que vous comptez garder. La question à se poser sur un hébergeur avant de coller son URL dans un champ de console n’est pas « est-ce gratuit », mais « cette adresse exacte répondra-t-elle encore dans deux ans, et pourrai-je la rediriger sinon ».

Ce que fait AppFoyer

Deux choses sont conçues précisément autour de ce problème.

L’adresse aléatoire de votre app est permanente. Chaque app reçoit app-xxxxxx.appfoyer.page à sa création et cette adresse ne change jamais — même si vous revendiquez plus tard un sous-domaine personnalisé sur un forfait payant, l’adresse d’origine continue de répondre avec le même site, sans redirection et sans expiration. L’adresse que vous avez collée dans un champ de console il y a un an ne cesse pas de fonctionner parce que vous avez renommé quelque chose.

Un sous-domaine personnalisé que vous remplacez est libéré immédiatement. Remplacez-en un et l’ancienne adresse cesse aussitôt de répondre — sans redirection — et n’importe qui peut la revendiquer, y compris un autre compte. Ne mettez donc jamais un sous-domaine personnalisé dans une fiche que vous pourriez changer plus tard : c’est l’adresse permanente ci-dessus qui est garantie de continuer à fonctionner.

Et comme l’adresse permanente sert le site lui-même au lieu de rediriger, /app-ads.txt répond avec un 200 sur cette adresse comme sur l’adresse actuelle : la règle ci-dessus est respectée sans rien configurer.

Les sources qui font foi

• Privacy policy requirements — Aide Google Play, pour la formulation « available on an active URL ».
• User Data policy — Aide Google Play, pour la règle console plus app.
• Set up app-ads.txt — Aide AdMob, pour la façon dont le fichier est localisé.
• App Store Connect — app information — Apple, pour l’emplacement des champs.