Redirection vers l'App Store : un seul lien pour les utilisateurs iPhone et Android

Les personnes qui cherchent « redirection vers un store d'applications » ou « redirection mobile » veulent généralement une des deux choses suivantes. La plupart veulent un lien unique qu'elles peuvent placer dans une publicité, un e-mail, une bio sur les réseaux sociaux ou sur un code QR imprimé, qui ouvre le bon store sur n'importe quel téléphone qui le touche. D'autres veulent que les visiteurs sur téléphone arrivent sur une version mobile d'un site web. Ce guide couvre d'abord le cas du store d'applications, avec du code à copier-coller, puis le cas du site mobile et ce que Google en dit.

Étape 1 : Obtenir les deux URL des stores#

Chaque option ci-dessous nécessite l'URL publique de chaque store. Les deux suivent un modèle fixe :

• Apple App Store : https://apps.apple.com/app/id<your app ID>. L'ID de l'application est le numéro qu'Apple affiche comme « Apple ID » sous Informations sur l'app dans App Store Connect, ou le numéro entre « id » et « ? » dans le lien provenant des outils marketing de l'App Store d'Apple.
• Google Play : https://play.google.com/store/apps/details?id=<package name>. Le nom du package est l'ID de l'application dans le manifeste de votre application ; il est également affiché dans la Play Console.

Ouvrez les deux URL sur un téléphone et sur un ordinateur avant de les utiliser. Une fiche qui n'est pas disponible dans un pays affiche une erreur au lieu de l'application, alors testez depuis les marchés sur lesquels vous faites la promotion.

Étape 2 : Choisir comment l'appareil est détecté#

Il existe quatre façons courantes de créer la redirection. Elles diffèrent par l'endroit où la décision est prise et par l'effort de maintenance qu'elles demandent.

Option A : une page « Obtenir l’application » avec les deux badges#

La redirection la plus robuste vers une boutique d’apps n’en est pas vraiment une : une seule page avec un badge de l’App Store, un badge Google Play, une courte description et un code QR pour les visiteurs sur ordinateur. Personne n’est jamais envoyé vers la mauvaise boutique, cela fonctionne dans tous les navigateurs intégrés aux applications, et cela vous donne un espace pour expliquer ce que fait l’application.

Sur iPhone et iPad, vous pouvez ajouter le Smart App Banner^[1] d’Apple à la même page. Il affiche une bannière en haut de la page qui ouvre votre fiche App Store, ou ouvre l’app si elle est déjà installée, et il n’apparaît pas sur les appareils que votre app ne prend pas en charge. Vous l’ajoutez avec une seule balise meta dans le head de la page :

html<meta name="apple-itunes-app" content="app-id=000000000, app-argument=https://mybrand.com/get-the-app">

Option B : redirection avec quelques lignes de JavaScript#

Placez ce script sur la page « Obtenir l’application » de l’option A. Les téléphones sont redirigés immédiatement vers leur boutique ; les visiteurs sur ordinateur et tout ce que le script ne reconnaît pas restent sur la page et voient les deux badges. Remplacez les deux URL par les vôtres.

html<script>
  var IOS_URL = 'https://apps.apple.com/app/id000000000';
  var ANDROID_URL = 'https://play.google.com/store/apps/details?id=com.mybrand.app';

  var ua = navigator.userAgent || '';
  // Les iPad qui demandent la version desktop du site déclarent un User-Agent Mac, donc vérifiez aussi le tactile
  var isIPadDesktopMode = /Macintosh/.test(ua) && navigator.maxTouchPoints > 1;

  if (/iPhone|iPad|iPod/.test(ua) || isIPadDesktopMode) {
    window.location.replace(IOS_URL);
  } else if (/Android/.test(ua)) {
    window.location.replace(ANDROID_URL);
  }
  // Tous les autres restent ici et voient les deux badges de boutique.
</script>

location.replace() est utilisé à la place d’un simple changement de lien afin que la page de la boutique remplace la page de redirection dans l’historique ; lorsque les visiteurs appuient sur Retour, ils ne rebondissent pas immédiatement vers la boutique.

Option C : redirection côté serveur#

Une règle côté serveur répond avant que le moindre HTML ne soit envoyé, il n’y a donc aucun flash de la page. Cet exemple Nginx envoie /app vers la bonne boutique et tout le reste vers la page des badges. Utilisez un 302 plutôt qu’un 301 : la réponse dépend de l’appareil, et une redirection permanente peut être mise en cache par un navigateur ou un proxy puis rejouée pour le mauvais appareil. L’en-tête Vary indique aux caches que la réponse change selon le User-Agent.

nginxlocation = /app {
    add_header Vary User-Agent always;
    if ($http_user_agent ~* "iphone|ipad|ipod") {
        return 302 https://apps.apple.com/app/id000000000;
    }
    if ($http_user_agent ~* "android") {
        return 302 https://play.google.com/store/apps/details?id=com.mybrand.app;
    }
    return 302 https://mybrand.com/get-the-app;
}

Le serveur ne voit que l’en-tête User-Agent, donc un iPad en mode bureau est traité comme un Mac et arrive sur la page des badges. C’est un repli sûr, c’est pourquoi la dernière ligne ne devrait jamais pointer vers l’une des boutiques.

Option D : Utiliser un service de deep linking ou de smart linking#

Si vous avez besoin de plus qu’une redirection vers une boutique, par exemple ouvrir un écran spécifique dans l’application installée, transmettre ce contexte lors d’une nouvelle installation, ou attribuer les installations à des campagnes, une plateforme mobile de deep linking ou d’attribution est le bon outil. Ces services vous demandent généralement d’ajouter leur SDK à l’application.

Si vos liens utilisent encore Firebase Dynamic Links (URL page.link), remplacez-les maintenant. Google a arrêté le service le 25 août 2025, et les liens cliqués renvoient une erreur HTTP 404^[2].

Étape 3 : Le configurer et le tester#

Quelle que soit l’option que vous choisissez, le déploiement est le même :

1. Copiez l’URL de votre App Store et l’URL de votre Google Play (étape 1).
2. Publiez une page « Obtenir l’application » avec les badges des deux boutiques, un code QR et un lien vers votre site web.
3. Ajoutez la redirection : le script de l’option B, la règle côté serveur de l’option C, ou le lien de votre service.
4. Testez le lien sur un iPhone, un iPad, un téléphone Android et dans un navigateur de bureau, puis une fois de plus dans l’application Instagram ou Facebook, où les liens s’ouvrent dans un navigateur intégré à l’application.
5. Vérifiez ce que renvoie le lien avec notre test de vitesse de redirection : le code de statut, la destination et la rapidité de réponse.
6. Utilisez ce même lien partout : publicités, e-mails, bios sur les réseaux sociaux, emballages et QR codes imprimés.

Ouverture de l’application lorsqu’elle est déjà installée#

Une redirection vers une boutique ouvre toujours la fiche de l’application, même pour les personnes qui ont déjà votre application. Pour ouvrir l’application elle-même, configurez les Universal Links sur iOS et les App Links sur Android : vous publiez un petit fichier de vérification sur votre domaine, et les liens vers ce domaine s’ouvrent dans l’application lorsqu’elle est installée et dans le navigateur lorsqu’elle ne l’est pas. L’argument d’application du Smart App Banner fait la même chose pour les visiteurs Safari sur votre site web.

• Visiteurs sur ordinateur : affichez la page des badges avec un code QR qu’ils peuvent scanner avec leur téléphone, au lieu de les envoyer vers une boutique depuis laquelle ils ne peuvent pas installer.
• Offrez une issue : un lien « Continuer vers le site web » sur la page des badges, afin que personne qui voulait simplement votre site ne reste bloqué.
• Boutiques des fabricants : si vous publiez aussi sur des boutiques comme Samsung Galaxy Store ou Huawei AppGallery, ajoutez une règle pour ces marques avant la règle Android générale ; tous les autres appareils Android vont vers Google Play.

Les redirections mobiles renvoient vers un site mobile#

L’autre sens de « redirection mobile » consiste à envoyer les visiteurs sur téléphone depuis www.example.com vers un site mobile distinct, par exemple m.example.com. Le conseil de Google est d’éviter cette configuration si vous le pouvez :

• Privilégiez le design responsive. Google recommande le design web adaptatif parce que c’est le modèle le plus simple à mettre en œuvre et à maintenir^[3] : une seule URL et une seule page HTML pour chaque appareil, donc rien à rediriger.
• Si vous conservez un site mobile distinct, redirigez chaque URL desktop vers son URL mobile équivalente, jamais chaque page vers la page d’accueil mobile. Les pages qui redirigent vers une page sans rapport peuvent disparaître de l’index.
• Liez les deux versions. L’URL desktop est la canonique et l’URL mobile est son alternative, marquée avec rel="canonical" sur la page mobile et rel="alternate" sur la page desktop.
• Diffuser un HTML différent sur la même URL (service dynamique) nécessite un en-tête de réponse Vary: User-Agent, afin que les caches et les robots sachent que la page change selon l’appareil.

Les redirections vers les boutiques d’applications n’ont pas ce problème SEO tant que le lien est une URL de campagne dédiée (comme /app ou go.mybrand.com/app) plutôt qu’une page de contenu que vous souhaitez positionner. Ne redirigez pas votre page d’accueil ou vos articles de blog vers une boutique sur mobile : vous masqueriez ce contenu aux visiteurs sur téléphone et au robot d’exploration mobile de Google.

Où s’inscrit RedirHub#

RedirHub ne choisit pas lui-même une boutique selon l’appareil ; cette décision doit être prise sur votre page « Obtenir l’application » ou dans votre règle serveur. Ce qu’ajoute RedirHub, c’est le lien qui le précède : une adresse courte et fiable sur votre propre domaine, que vous pouvez imprimer, partager et modifier plus tard.

• Un seul lien sur votre domaine. go.mybrand.com/app est un lien court de marque qui apparaît comme le vôtre dans les publicités, les bios et les e-mails, et vous pouvez le faire pointer vers une nouvelle page plus tard sans changer le lien.
• Un code QR qui n’a jamais besoin d’être réimprimé. Cochez « Créer aussi un code QR » et le même lien devient un code QR que vous pouvez mettre à jour après l’impression, afin que les emballages et les affiches continuent de fonctionner lorsque la page change d’emplacement.
• Voyez qui l’utilise. Les clics et les visiteurs uniques, les bots étant filtrés, par pays, appareil et système d’exploitation, afin de voir combien de clics proviennent d’iPhone par rapport aux téléphones Android.
• Rapide et sécurisé partout. Servi depuis 130 points de présence (PoP) en périphérie à travers le monde, au plus près de chaque visiteur, avec HTTPS automatique émis et renouvelé pour le domaine de votre lien. Seul l’enregistrement DNS de ce sous-domaine change ; votre site web et vos e-mails restent là où ils sont.
• Aucun hébergement de page n’est nécessaire sur Pro. Le type de redirection HTML personnalisé (forfait Pro) diffuse votre propre HTML à l’adresse du lien, ce qui suffit pour une simple page de badges.

Pour créer le lien dans le tableau de bord RedirHub :

1. Connectez le domaine de votre lien, par exemple go.mybrand.com, dans Hostnames et suivez Connect DNS.
2. Créez un nouveau lien de marque.
3. Dans Destination URL, saisissez votre page « Obtenir l’application », par exemple https://mybrand.com/get-the-app.
4. Dans Short link, choisissez go.mybrand.com et saisissez app.
5. Cochez Créer aussi un code QR si le lien doit être imprimé.
6. Cliquez sur Créer un lien, puis partagez go.mybrand.com/app partout.

Si vous avez besoin de liens profonds différés ou d’une attribution d’installation, une plateforme de deep linking est le meilleur choix. Si vous avez besoin d’un seul lien fiable et d’un code QR qui redirigent les gens vers votre application, une page de badges avec le script ci-dessus derrière un lien RedirHub suffit, et une page de badges gratuite sur votre propre site suffit à elle seule si vous n’avez pas besoin de suivre ou de modifier le lien.

Erreurs courantes de redirection vers les boutiques d’applications#

• Utiliser une 301. La bonne destination dépend de l’appareil, alors utilisez une 302 (voir 301 vs 302 redirects).
• Pas de solution de repli pour ordinateur. Envoyer les visiteurs sur ordinateur vers Google Play ou l’App Store gaspille le clic ; affichez la page de badges et un code QR.
• Oublier les iPad. Safari sur iPad demande généralement le site de bureau, donc une simple vérification "iPhone|iPad" le manque. Ajoutez la vérification tactile de l’option B, ou laissez la page de badges le détecter.
• Boucles de redirection dans l’historique du navigateur. Utilisez location.replace() pour que le bouton Retour ne renvoie pas les gens vers la boutique.
• Fiches de boutique inactives. Si une application est supprimée ou n’est pas disponible dans un pays, la boutique affiche une erreur. Revérifiez les deux URL chaque fois que vous modifiez les fiches, les régions ou les noms de package.