Les deep links sur iOS et Android : le guide pratique

Un deep link est une URL qui ouvre un écran précis à l’intérieur d’une application installée plutôt qu’une page web. C’est toute l’idée, et elle a été implémentée de trois façons différentes en quinze ans, chacune avec ses propres modes de défaillance. Si les équipes marketing continuent d’ouvrir des tickets à ce sujet, c’est que les trois coexistent toujours, et qu’une même URL peut se comporter différemment selon qu’elle a été touchée dans une messagerie, un navigateur, un client de courrier électronique ou une webview intégrée à une application sociale.

Ce guide explique honnêtement les mécanismes, y compris ce qu’ils ne savent pas faire. Si vous ne retenez qu’une chose, que ce soit celle-ci : router un clic vers le bon écran d’application est une infrastructure résolue, tandis que router un utilisateur vers le bon écran après qu’il a installé l’application ne l’est pas, en tout cas pas depuis la seule plateforme de liens.

Les trois générations de liens applicatifs

Les schémas d’URL personnalisés

Le mécanisme d’origine. Une application enregistre un schéma comme myapp, et une URL du type myapp://product/42 lui confie la requête. Les schémas sont triviaux à implémenter et restent utiles comme format de routage interne, mais ils portent deux problèmes structurels.

Il n’y a pas de vérification de propriété : n’importe quelle application peut enregistrer n’importe quel schéma, et quand deux applications revendiquent le même, la résolution est indéfinie sur iOS et donne une boîte de dialogue de choix sur Android. Et il n’y a pas de repli : sur un appareil où l’application n’est pas installée, une URL de schéma produit une page d’erreur ou rien du tout, si bien que chaque lien de schéma a besoin d’une enveloppe qui détecte l’échec et envoie l’utilisateur quelque part d’utile. Cette enveloppe est précisément la pièce fragile qui a cédé quand les navigateurs ont durci leur traitement des minuteurs de navigation.

Les Universal Links sur iOS

Le remplacement proposé par Apple utilise des URL HTTPS ordinaires. Votre application déclare un entitlement de domaine associé de la forme applinks:yourbrand.com, et le domaine publie un fichier JSON à l’adresse /.well-known/apple-app-site-association décrivant les chemins qui appartiennent à l’application.

{
  "applinks": {
    "details": [
      {
        "appIDs": ["ABCDE12345.com.yourbrand.app"],
        "components": [{ "/": "/p/*", "comment": "Product pages" }]
      }
    ]
  }
}

Le fichier doit être servi en HTTPS sans aucune redirection, en JSON, à ce chemin exact. iOS le récupère autour de l’installation et des mises à jour, largement à travers le CDN d’Apple, ce qui signifie que les modifications ne prennent pas effet instantanément. L’avantage, c’est que la même URL fonctionne partout : si l’application est installée et que le chemin correspond, elle s’ouvre ; sinon, Safari charge la page web. Il n’y a pas d’état d’erreur.

Les App Links sur Android

L’équivalent d’Android utilise un fichier Digital Asset Links à l’adresse /.well-known/assetlinks.json, qui nomme le package de l’application et l’empreinte SHA-256 du certificat de signature.

[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.yourbrand.app",
      "sha256_cert_fingerprints": ["A1:B2:C3:D4:E5:F6:..."]
    }
  }
]

Côté application, on déclare un intent filter pour le domaine avec la vérification automatique activée. Quand la vérification réussit, le lien ouvre l’application sans boîte de dialogue de choix. Quand elle échoue, le lien ouvre le navigateur, et la cause la plus fréquente de loin est une empreinte qui ne correspond pas : les équipes publient l’empreinte de leur clé de release locale alors que Play App Signing resigne l’application avec une autre. L’empreinte qui doit figurer dans le fichier est celle que le store affiche pour l’artefact distribué.

Comment un lien court choisit sa destination

Un lien court est un point de décision plutôt qu’un pointeur figé, et c’est ce qui le rend utile pour les campagnes applicatives : un même code imprimé peut servir différemment les utilisateurs d’iPhone, ceux d’Android et les visiteurs sur ordinateur, et la décision peut changer après l’impression du code.

Le moteur de redirection voit l’agent utilisateur de la requête, les client hints qu’elle transporte et les signaux dérivés du réseau comme le pays. Un lien configuré pour du trafic applicatif porte généralement trois destinations : une URL iOS, une URL Android et une URL web utilisée pour tout le reste. Par-dessus, les règles de ciblage peuvent router selon le pays, l’appareil, le système d’exploitation ou la langue, si bien qu’une campagne peut envoyer le trafic Android canadien vers une destination et tous les autres vers une autre, sans créer de liens séparés.

Deux détails d’implémentation méritent d’être connus, parce qu’ils expliquent l’essentiel des comportements déroutants.

Le premier, ce sont les robots sociaux. Quand un robot comme celui de Facebook ou de Telegram demande un lien pour construire une carte d’aperçu, un moteur de redirection correct répond avec les métadonnées d’aperçu plutôt que de compter la requête comme un clic et plutôt que de la router comme s’il s’agissait d’un téléphone. Si vos compteurs de clics bondissent à l’instant où un lien est publié, avant que quiconque l’ait touché, c’est que le moteur ne le fait pas.

Le second, c’est la frontière de l’association, et c’est le point technique le plus important de cet article. Les Universal Links sont évalués par rapport au domaine de l’URL que l’utilisateur a réellement touchée. Si quelqu’un touche go.yourbrand.com/p/42 et que ce domaine répond par une redirection vers yourbrand.com/p/42, iOS ne considère pas la cible de la redirection comme un lien associé, et l’application ne s’ouvre donc pas. Pour qu’un lien court ouvre l’application nativement, le fichier d’association doit être servi sur le domaine court lui-même. Là où ce n’est pas possible, le repli pratique est un passage de relais vers un schéma personnalisé ou directement vers le store, ce que font en réalité la plupart des fonctions de deep link des raccourcisseurs. Demandez à chaque fournisseur lequel des deux il implémente, car le discours commercial est identique dans les deux cas.

La chaîne de repli

Un lien applicatif qui fonctionne est en réalité un petit arbre de décision, et chaque branche appelle une réponse délibérée.

| Situation | Ce qui doit se produire | Erreur fréquente | | --- | --- | --- | | Application installée, chemin reconnu | L’application s’ouvre sur l’écran visé | Une chaîne de redirections casse l’association | | Application installée, chemin non reconnu | La page web se charge, l’application est suggérée | Une boîte de dialogue de choix à chaque appui | | Application absente, mobile | La page du store pour la bonne plateforme | Lien de store figé sur une seule plateforme | | Ordinateur | L’équivalent web complet de l’écran | Atterrissage sur une page d’accueil générique | | Robot social | Métadonnées d’aperçu, aucun clic compté | La récupération d’aperçu gonfle les statistiques |

Pointez la branche store vers la fiche correspondant à la plateforme plutôt que vers un lien unique, et gardez la branche web réellement équivalente à l’écran de l’application. Une large part du trafic des campagnes applicatives finit sur la branche web, quelle que soit la qualité du reste de la configuration, et la traiter comme une impasse gâche l’essentiel du budget.

La frontière de l’installation, sans fard

C’est ici que le discours des fournisseurs et la réalité divergent. Supposons qu’un nouvel utilisateur touche un lien vers un produit précis, n’ait pas l’application, atterrisse dans le store, installe et ouvre. L’application affiche alors son écran d’accueil par défaut, parce que rien n’a transporté l’identifiant du produit à travers l’installation. Faire fonctionner cela s’appelle le deep linking différé, et ce n’est pas quelque chose qu’une plateforme de liens peut faire seule.

Cela exige un SDK à l’intérieur de l’application qui, au premier lancement, demande à un serveur ce que l’utilisateur avait touché avant d’installer. Le serveur doit rapprocher les deux événements, et les signaux disponibles pour ce rapprochement se sont fortement réduits. La prise d’empreinte d’appareil n’est pas fiable et se trouve de plus en plus restreinte par les règles des plateformes. Les identifiants publicitaires exigent un consentement que la plupart des utilisateurs refusent. Les cadres d’attribution d’Apple rapportent aux annonceurs une attribution au niveau de l’installation, sans transmettre de chemin à votre application. La technique du presse-papiers qui transportait autrefois un jeton déclenche désormais une notification de collage visible.

Ce qui reste fonctionne, mais c’est un autre produit, avec un autre coût d’intégration : le SDK d’un partenaire de mesure mobile, une initialisation dans l’application et une fenêtre de rapprochement probabiliste plutôt qu’exacte. LinkProfit route les clics par appareil et passe le relais au store, et ne prétend pas assurer le routage après installation, parce que le faire correctement suppose d’embarquer du code dans votre application. Si le routage différé est une exigence ferme, prévoyez ce SDK à côté de votre plateforme de liens plutôt qu’à sa place.

Webviews et autres pièges concrets

Les navigateurs intégrés aux applications

La plupart des liens touchés à l’intérieur des applications sociales s’ouvrent dans une webview intégrée plutôt que dans le navigateur du système, et les webviews traitent l’association applicative de façon inégale : certaines ignorent les Universal Links, d’autres bloquent les schémas personnalisés, et le comportement diffère d’une version d’application à l’autre. C’est la raison la plus fréquente pour laquelle un lien parfaitement fonctionnel en test ouvre le site web en production, puisque les tests se font en général en touchant un lien dans une messagerie, qui se comporte correctement.

Aucune configuration ne corrige cela globalement. Ce qui marche, c’est de soigner la destination web, d’y ajouter une commande d’ouverture dans l’application bien visible, et de tester chaque canal de publication individuellement plutôt que de supposer qu’ils se comportent tous pareil.

Les erreurs sur le fichier d’association

Quatre reviennent sans cesse. Servir le fichier d’association à travers une redirection, y compris la redirection automatique de l’apex vers www, ce qui l’invalide. Le servir avec un mauvais type de contenu ou depuis un chemin qu’un framework réécrit. Publier la mauvaise empreinte de signature Android, comme décrit plus haut. Et oublier qu’iOS met le fichier en cache, si bien qu’une correction peut mettre un jour ou plus à atteindre les appareils où l’application est déjà installée.

Les statistiques sur la branche applicative

Dès qu’un clic entre dans une application, votre analytique web cesse de le voir, et c’est là que le reporting se délite en silence. Gardez les paramètres de campagne sur le lien pour que le moteur de redirection les enregistre, et transmettez un identifiant jusqu’à la destination applicative pour que la session dans l’application puisse être rattachée au clic. Notre guide sur le suivi des clics sur les liens détaille ce qu’un événement de clic peut et ne peut pas vous dire, et les mêmes réserves sur les robots et les visiteurs uniques s’appliquent ici.

Tester avant de publier

curl -sSI https://yourbrand.com/.well-known/apple-app-site-association
curl -sS https://yourbrand.com/.well-known/assetlinks.json

# Android: open a URL as if it were tapped, then inspect verification state
adb shell am start -a android.intent.action.VIEW -d "https://yourbrand.com/p/42"
adb shell pm get-app-links com.yourbrand.app

# iOS simulator
xcrun simctl openurl booted "https://yourbrand.com/p/42"

Les deux premières commandes doivent répondre 200 sans redirection. Notez que taper un Universal Link dans la barre d’adresse de Safari n’ouvre délibérément pas l’application : testez donc depuis une note, un message ou la commande du simulateur, sinon vous courrez après un bug qui n’existe pas.

Ce que les plateformes de liens incluent réellement

La prise en charge des deep links est empaquetée de façons très différentes d’un fournisseur à l’autre, et les différences portent sur le forfait qu’il faut acheter plutôt que sur la capacité elle-même.

| Fournisseur | Disponibilité des deep links, en août 2026 | | --- | --- | | BL.INK | Tous les forfaits, palier d’entrée à 48 USD par mois pour un utilisateur et un domaine | | Short.io | À partir du forfait Team, à 48 USD par mois | | Rebrandly | À partir du forfait Growth, de 99 à 119 USD par mois | | Switchy | Prise en charge annoncée de plus de 130 applications | | LinkProfit | Destinations par appareil sur tous les forfaits |

BL.INK est ici la référence honnête : inclure les deep links à tous les paliers est inhabituel, même si le prix d’entrée est élevé pour un seul domaine. Le placement de Rebrandly sur Growth est le schéma qu’il faut surveiller en général, puisque le palier dont vous avez besoin pour une seule fonction finit par déterminer toute la facture.

Une séquence de déploiement qui fonctionne

1. Décidez de l’URL web canonique de chaque écran d’application que vous voulez cibler ; la page web est le repli et la source de vérité.
2. Publiez les deux fichiers d’association sur le domaine qui apparaîtra dans les liens, et vérifiez-les en HTTPS, sans redirection.
3. Ajoutez l’entitlement de domaine associé sur iOS et l’intent filter vérifié sur Android, avec l’empreinte de la build distribuée.
4. Confirmez sur quel domaine vos liens courts seront touchés, et si l’association y réside ou si la plateforme passe le relais à un schéma ou au store.
5. Configurez des destinations par appareil plus un repli web sur chaque lien, avec la bonne fiche de store par plateforme.
6. Testez sur les deux plateformes depuis une messagerie, depuis le navigateur du système et depuis chaque application sociale où vous publiez.
7. Vérifiez que les paramètres de campagne survivent à la redirection et sont enregistrés dans les statistiques.
8. Automatisez la création via l’API si les liens sont générés par campagne, par destinataire ou par produit.

Rien de tout cela n’est difficile isolément. La difficulté, c’est que les pièces vivent à trois endroits — le projet applicatif, la zone DNS et la plateforme de liens — habituellement détenus par trois personnes différentes. Écrire noir sur blanc qui détient le fichier d’association vaut plus que n’importe quel conseil de configuration particulier de cet article.