Le glossaire des liens d’app et du deep linking

Les Android App Links sont des liens https vérifiés qu’Android, depuis la version 6.0 et sur les appareils dotés des services Google, ouvre directement dans votre app, sans demander à l’utilisateur quelle application choisir. La vérification repose sur deux éléments : un intent filter marqué android:autoVerify="true" dans l’app et un fichier assetlinks.json publié sur le domaine.

Le fichier apple-app-site-association, ou AASA, est un fichier JSON publié sur votre domaine, à l’adresse /.well-known/apple-app-site-association. Il indique à iOS quelles apps ont le droit d’ouvrir les liens de ce domaine, chacune identifiée par son Team ID et son bundle ID, et pour quels chemins. Sans lui, pas d’Universal Links.

assetlinks.json est le fichier Digital Asset Links qu’Android consulte pour vérifier vos App Links. Publié à l’adresse /.well-known/assetlinks.json de votre domaine, il déclare qu’une app, désignée par son nom de package et par l’empreinte SHA-256 de son certificat de signature, a le droit d’ouvrir les liens de ce domaine.

Un deep link, ou lien profond, est un lien qui ouvre un écran précis d’une application mobile (une fiche produit, un panier, un article) au lieu d’une page web ou de l’écran d’accueil de l’app. Il existe sous plusieurs formes : le scheme d’URL, les Universal Links sur iOS, les App Links sur Android et le deep link différé.

Un deep link différé (deferred deep link en anglais) garde sa destination le temps de l’installation. La personne touche le lien, n’a pas l’app, passe par le store et l’installe. À la première ouverture, l’app affiche directement l’écran promis : le produit, l’invitation ou le code promo, et non l’écran d’accueil.

Les Universal Links (liens universels) sont des liens https classiques qu’iOS ouvre directement dans votre app quand elle est installée, et sur votre site web sinon. Apple les a introduits avec iOS 9. Ils reposent sur une association vérifiée entre l’app et le domaine : l’entitlement Associated Domains d’un côté, le fichier apple-app-site-association de l’autre.

Un URI scheme, ou scheme d’URL personnalisé, est un préfixe propre à une app, comme myapp://, qu’elle déclare auprès du système. Un lien qui commence par ce préfixe ouvre l’app et lui transmet le reste de l’adresse : myapp://product/42 peut ainsi afficher directement le produit 42.

Une URL intent est un format de lien propre à Chrome sur Android, qui commence par intent://. Elle indique le scheme à utiliser, le nom de package de l’app et, en option, une page web à ouvrir si l’app manque. Si l’app est installée, Chrome l’ouvre ; sinon il charge cette page web, ou la fiche de l’app sur Google Play.

Un Dynamic Link désigne le plus souvent un lien Firebase Dynamic Links, le service de deep linking de Google. Déclaré obsolète en 2023, le service a fermé le 25 août 2025 et les anciens liens ne fonctionnent plus. Au sens large, un lien dynamique est un lien dont la destination se décide au moment du clic.

Un navigateur in-app est le navigateur intégré à une app comme Instagram, TikTok, Facebook ou LinkedIn. Quand on touche un lien dans ces apps, la page s’ouvre à l’intérieur, sans passer par Safari ou Chrome. L’app hôte garde ainsi l’utilisateur chez elle, et vos Universal Links ou App Links peuvent ne pas ouvrir votre app.

Un QR code dynamique contient un lien court qui redirige vers la vraie destination. Vous pouvez donc changer cette destination après l’impression et compter les scans. Un QR code statique contient directement l’adresse finale : impossible à modifier, mais il ne dépend d’aucun service et n’expire jamais.

La Smart App Banner est le bandeau d’Apple qui propose votre app en haut d’une page web. Elle s’active avec une seule balise meta, apple-itunes-app, placée dans la page. Mais elle ne s’affiche que dans Safari sur iOS : ni dans Chrome sur iPhone, ni dans les navigateurs in-app, ni sur Android.

Un smart link est un lien unique, souvent accompagné de son QR code, qui reconnaît l’appareil au moment du clic. Un iPhone part vers l’App Store, un Android vers Google Play ou un autre store, un ordinateur vers votre site web. Si l’app est déjà installée, le lien l’ouvre directement.

La transmission de paramètres consiste à faire suivre les paramètres d’un smart link (tags UTM, code promo, identifiant de parrainage) jusqu’à chaque destination : le store, le site web et le deep link. Un seul lien sert ainsi toutes les variantes d’une campagne, sans en créer un par canal ou par partenaire.

Le web-to-app regroupe tout ce qui fait passer une personne de votre site mobile, de vos e-mails ou de vos pages pour ordinateur vers votre app : bannières, smart links, QR codes affichés sur desktop et deep links qui conservent la page consultée. Le but : que personne ne reparte de zéro une fois dans l’app.

Un lien App Store suit le format https://apps.apple.com/<pays>/app/<nom>/id<numéro>, un lien Google Play le format https://play.google.com/store/apps/details?id=<package>. Les variantes itms-apps:// et market:// ouvrent directement l’app App Store ou Play Store du téléphone, sans passer par le navigateur. L’app y est désignée par son numéro chez Apple et par son nom de package chez Google.

Un lien de campagne App Store est un lien vers votre page App Store auquel on ajoute trois paramètres : pt (provider token), ct (campaign token) et mt=8. App Store Connect regroupe ensuite par campagne les impressions, les vues de la page produit, les téléchargements et les ventes. Les données sont agrégées, jamais par utilisateur.

Une page de produit personnalisée est une version supplémentaire de votre page App Store, avec d’autres captures d’écran, un autre texte promotionnel ou d’autres aperçus vidéo. Apple en autorise jusqu’à 70 par app. Chacune a sa propre URL, qui ajoute à l’adresse habituelle un paramètre d’identifiant de page produit.

Les stores Android alternatifs sont les boutiques d’applications autres que Google Play : Huawei AppGallery, indispensable sur les téléphones Huawei sans services Google, Samsung Galaxy Store, Xiaomi GetApps ou encore RuStore en Russie. Un même lien peut envoyer chaque téléphone vers le store dont il dispose réellement.

L’attribution mobile consiste à déterminer quelle publicité, quelle campagne ou quel lien a amené une installation ou une action dans l’app. Elle répond à une question simple, « d’où vient cet utilisateur ? », et c’est de cette réponse que dépend la répartition du budget marketing. Sur iOS, ATT et SKAdNetwork en ont profondément changé les règles.

Les clics de bots sont des ouvertures de lien faites par des programmes, pas par des personnes : les robots qui génèrent les aperçus dans WhatsApp, iMessage, Slack ou Facebook, les robots des moteurs de recherche et les scanners de sécurité des messageries. Ils passent souvent avant les humains et gonflent le nombre de clics.

Le fingerprinting, ou prise d’empreinte, consiste à relier une installation à un clic en combinant des signaux techniques comme l’adresse IP, le modèle de l’appareil et la version du système. Ensemble, ces signaux forment une empreinte qui fait office d’identifiant. Apple l’interdit à des fins de suivi, même quand l’utilisateur a donné son accord via ATT.

L’install referrer est l’information que Google Play transmet à une app après son installation : la valeur du paramètre referrer contenue dans le lien Play Store qui a mené au téléchargement. L’app la récupère avec l’API Play Install Referrer. C’est la méthode déterministe pour attribuer une installation sur Android.

Les paramètres UTM sont cinq balises ajoutées à un lien (utm_source, utm_medium, utm_campaign, utm_term et utm_content) que les outils d’analyse lisent pour savoir d’où vient une visite. Sur le web, ils fonctionnent très bien. Vers les stores, c’est une autre histoire : l’App Store les ignore, et Google Play ne les garde que dans le paramètre referrer.

Un postback est un message envoyé de serveur à serveur pour signaler une installation ou un événement dans l’app, soit à une régie publicitaire, soit à votre propre serveur ; on parle alors plutôt de webhook. Il est souvent signé, pour que le destinataire puisse vérifier qu’il vient bien de l’expéditeur annoncé.