Applications mobiles et deep links

Un lien court qui mène à une application mobile a trois publics à la fois : les gens qui ont déjà l’application, ceux qui ne l’ont pas, et ceux dont le navigateur vit à l’intérieur d’une autre application. Cette page couvre les trois, plus les deux éléments de configuration qui font la différence : les fichiers d’association sur votre domaine, et le contexte de clic différé que votre application peut lire au premier lancement.

Ce que fait la section mobile

Ouvrez un lien, allez dans l’onglet Mobile et activez les destinations mobiles. Pour chaque plateforme, vous pouvez définir trois adresses :

• Lien de l’application — l’adresse à l’intérieur de votre application : votre propre schéma avec un chemin (myapp://product/42), un intent Android, ou un lien universel https.
• Adresse de la boutique — la page App Store ou Google Play, utilisée quand l’application ne s’ouvre pas.
• Repli web — une page pour les visiteurs que vous préférez ne pas envoyer en boutique.

Tout est facultatif. Un lien qui n’a qu’une adresse de boutique est une simple redirection vers la boutique. Un lien avec un lien d’application et une adresse de boutique obtient le comportement complet : la page essaie d’abord l’application et passe à la boutique quand rien ne se produit.

Deux réglages de plus décident de ce qui se passe hors d’un navigateur mobile ordinaire :

• Tablettes — les traiter comme des téléphones (le choix par défaut) ou comme des ordinateurs.
• Navigateurs intégrés aux applications — que faire quand le lien s’ouvre dans Instagram, TikTok, Facebook ou une application similaire.

Les visiteurs sur ordinateur suivent la Destination ordinateur si vous en définissez une, et sinon la destination principale du lien. Rien dans la section mobile ne change ce que voient les visiteurs sur ordinateur, sauf si vous le demandez.

Pourquoi les navigateurs intégrés méritent leur propre règle

La plupart des clics sur les liens d’un fil social n’atteignent jamais Safari ni Chrome. Ils s’ouvrent dans une vue web à l’intérieur de l’application elle-même, et plusieurs de ces vues web gardent toute navigation pour elles : un lien universel reste dans la vue web, et un schéma personnalisé ne fait tout simplement rien. Ce n’est pas un défaut que vous puissiez corriger depuis le lien — c’est une décision de l’application à qui appartient la vue web.

Le réglage vous offre donc trois options honnêtes :

| Choix | Ce que reçoit le visiteur | | --- | --- | | Essayer d’ouvrir l’application | La page intermédiaire tente le lien de l’application ; quand la vue web est connue pour le bloquer, la page saute l’attente et montre comment rouvrir le lien dans le navigateur du téléphone. | | Aller directement à la boutique | Aucune tentative d’ouverture de l’application — utile pour les campagnes d’installation où la page de la boutique est l’objectif. | | Aller au repli web | Le visiteur reste sur le web, ce qui est souvent la meilleure réponse pour les liens de contenu. |

Fichiers d’association : la configuration qui fait ouvrir l’application en silence

Pour qu’un lien ouvre votre application sans arrêt dans le navigateur, le système d’exploitation doit savoir que votre domaine et votre application vont ensemble. Les deux plateformes le vérifient avec un fichier servi depuis le domaine lui-même :

https://go.brand.com/.well-known/apple-app-site-association
https://go.brand.com/.well-known/assetlinks.json

Ces fichiers, vous ne les écrivez pas. Dans Domaines, ouvrez le domaine et ajoutez vos applications sous Applications mobiles :

• pour iOS : l’App ID sous la forme TEAMID.com.company.app, et les chemins que l’application doit traiter (* couvre tous les liens courts) ;
• pour Android : le nom du package et les empreintes de signature SHA-256 issues de la Play Console.

La plateforme construit et sert les deux fichiers depuis votre domaine avec exactement la réponse que les deux plateformes exigent : statut 200, aucune redirection, application/json, aucune compression de transport. Ce dernier point compte plus qu’il n’y paraît : un proxy qui compresse le fichier en route est l’une des causes les plus fréquentes d’arrêt silencieux des liens applicatifs.

Vérifier la configuration

Le bouton Vérifier les fichiers récupère les deux fichiers depuis votre domaine en production et rapporte ce qu’une plateforme verrait. Les constats renvoient à des correctifs précis :

| Constat | Que faire | | --- | --- | | Le domaine n’a pas répondu | Le domaine ne sert pas encore de trafic, ou le DNS se propage encore. | | Le fichier est absent | Aucune application n’est configurée pour ce domaine, ou la requête n’atteint jamais la plateforme. | | Le domaine redirige cette adresse | Quelque chose devant le domaine réécrit /.well-known/. Les plateformes ne suivent pas les redirections ici. | | Servi avec le mauvais type | La réponse est du HTML, en général une page 404 d’un autre service. | | La réponse arrive compressée | Un proxy compresse le fichier. Les vérifications des deux plateformes peuvent échouer là-dessus. | | Aucune application déclarée | Le fichier est valide mais vide pour cette plateforme — ajoutez l’application dans le tableau de bord. |

Une fois les fichiers en place, les deux plateformes les mettent en cache sur leur propre CDN : une installation neuve de l’application peut donc mettre du temps à prendre en compte un changement. Réinstaller l’application est le moyen fiable de forcer une relecture pendant les tests.

Contexte du clic différé après l’installation

Un visiteur sans votre application clique sur un lien, atterrit dans la boutique, installe l’application et l’ouvre. À cet instant, l’application ne sait rien d’où venait la personne : la session du navigateur et l’application sont deux mondes sans lien.

Activez Transmettre le contexte du clic après l’installation et la plateforme conserve pendant deux heures environ une brève empreinte de l’appareil : plateforme, version majeure du système, langue, pays, taille d’écran, fuseau horaire et opérateur réseau. On n’y trouve aucune adresse IP, aucun identifiant publicitaire, et rien qui puisse remonter à une personne.

Au premier lancement, votre application demande à la plateforme si un clic a eu lieu :

curl -X POST https://go.brand.com/__dl/claim \
  -H 'content-type: application/json' \
  -d '{
    "platform": "ios",
    "os_version": "17.4",
    "language": "de",
    "timezone_offset": 120,
    "screen_width": 1170,
    "screen_height": 2532,
    "pixel_ratio": 3
  }'

Une correspondance répond avec le lien d’origine et ses balises de campagne :

{
  "matched": true,
  "confidence": "high",
  "score": 100,
  "matched_on": ["screen", "timezone_offset", "language", "os_version"],
  "url": "myapp://product/42",
  "domain": "go.brand.com",
  "slug": "promo",
  "link_id": "lnk_...",
  "utm": { "utm_source": "newsletter" },
  "click_id": "...",
  "clicked_at": "2026-08-14T10:00:00.000Z"
}

L’absence de correspondance répond {"matched": false} — de même qu’une seconde requête pour le même clic, car l’enregistrement n’est remis qu’une seule fois.

Les limites, dites clairement

• La correspondance est probabiliste. Deux appareils du même modèle, sur le même réseau, dans le même fuseau horaire et la même langue sont identiques pour cette méthode. C’est pourquoi chaque réponse porte un confidence et la liste des attributs sur lesquels elle a été décidée : high signifie que la taille d’écran et le fuseau horaire correspondaient sur un clic récent, low signifie qu’il faut le traiter comme un indice et non comme un fait.
• La fenêtre se compte en heures, pas en jours. L’empreinte expire deux heures après le clic, et la confiance baisse dès les quinze premières minutes.
• Envoyez la requête une seule fois, au premier lancement. L’enregistrement est consommé par la première correspondance réussie ; un second appel ne renvoie rien.
• Une redirection directe vers la boutique, sans page intermédiaire, collecte moins. La taille d’écran et le fuseau horaire ne sont connus que de la page qui s’exécute dans le navigateur : un lien qui va droit à la boutique ne correspond que par la langue et la version du système — et il le dit, avec une confiance moindre.

Liste de contrôle des tests

1. Ouvrez le lien sur un téléphone avec l’application installée : il devrait aboutir dans l’application.
2. Ouvrez-le sans l’application : la page apparaît brièvement et la boutique s’ouvre.
3. Ouvrez-le depuis un fil social : vérifiez que votre choix pour les navigateurs intégrés correspond à ce que vous attendez.
4. Ouvrez-le dans un navigateur d’ordinateur : la destination ordinateur ou la destination principale.
5. Lancez Vérifier les fichiers sur le domaine et confirmez que les deux fichiers reviennent propres.