Deep Link : ce que c'est, types de liens et principe de fonctionnement

Qu'est-ce qu'un Deep Link

Un Deep Link (lien profond) est un URI qui, lorsqu'on clique dessus, n'ouvre pas une page web mais un écran spécifique au sein d'une application mobile. La technologie résout un problème fondamental des plateformes mobiles : le navigateur ne peut pas ouvrir directement un écran d'application, et un deep link crée un pont entre le web et le code natif. Sans deep link, l'utilisateur atterrit toujours sur l'écran d'accueil et doit naviguer manuellement vers le contenu souhaité.

L'architecture d'un deep link se compose de deux parties : le schéma (scheme) détermine quelle application doit traiter le lien, et le chemin (path) pointe vers une ressource spécifique au sein de l'application — un produit, un article, un profil utilisateur ou une section de paramètres. Les paramètres de requête (?source=push&campaign=summer) transmettent un contexte supplémentaire pour l'analyse, la personnalisation et l'attribution de campagnes.

Il est important de distinguer un deep link d'un lien classique. Un lien classique (https://example.com/product/42) s'ouvre dans le navigateur et mène à la version web d'une page. Un deep link (myapp://product/42), si l'application est installée, ouvre l'écran natif avec le même contenu, mais si l'application n'est pas installée, il affiche une erreur. Universal Link (iOS) et App Link (Android) ont été créés précisément pour résoudre le problème du fallback transparent.

Types de liens profonds

Différentes tâches nécessitent différents types de deep links. Certains liens fonctionnent uniquement avec l'application installée, d'autres peuvent attendre l'installation, et d'autres encore transmettent un contexte analytique. Le choix du type dépend du cas d'utilisation : campagne publicitaire, notification push, partage de contenu ou newsletter par e-mail.

Deep Link standard (Standard Deep Link)

Un Standard Deep Link est le type de base qui se déclenche uniquement si l'application est déjà installée sur l'appareil. L'utilisateur clique sur un lien myapp://product/42, le système détecte le schéma enregistré et ouvre l'application sur l'écran souhaité. Si l'application n'est pas installée, le navigateur affiche une erreur « Page non trouvée » ou ne fait rien. Ce type convient à la navigation interne au sein d'une application déjà installée.

Configurer un deep link standard est simple : il suffit d'enregistrer le schéma URI dans le manifeste (Android) ou Info.plist (iOS). Aucune validation de serveur ni certificat SSL n'est requis. Cependant, précisément en raison de l'absence de fallback, ce type est considéré comme obsolète pour les campagnes marketing — la perte de trafic des utilisateurs sans l'application peut atteindre 60 %.

Deferred Deep Link (lien profond différé)

Un Deferred Deep Link résout le problème principal des deep links classiques : il fonctionne même si l'application n'est pas installée. L'utilisateur clique sur un lien → voit une page (landing page ou App Store/Google Play) → installe l'application → au premier lancement, l'application reçoit le contexte du lien d'origine et ouvre l'écran souhaité. La technologie nécessite un SDK intermédiaire (AppsFlyer, Branch, Adjust) qui stocke le contexte sur le serveur jusqu'au premier lancement.

Branch est l'une des plateformes les plus populaires pour les deferred deep links. Elle fournit un lien unique qui fonctionne sur toutes les plateformes : détecte le système d'exploitation de l'utilisateur, redirige vers la boutique d'applications et, après l'installation, transmet le contexte (code promo, ID produit, source de campagne). Selon Branch (2024), les deferred deep links augmentent la conversion des campagnes publicitaires de 40 à 70 %.

Contextual Deep Link (lien profond contextuel)

Un Contextual Deep Link est un deep link classique ou différé complété par des paramètres de contexte : source de trafic, campagne, code promo, référent, ID partenaire. Les paramètres sont transmis dans l'URL et traités par l'application pour la personnalisation : afficher un bonus de bienvenue, ouvrir un produit avec remise, enregistrer les analyses d'installation.

Les balises UTM (utm_source, utm_medium, utm_campaign) sont un moyen standard de transmettre le contexte. Dans le mobile, les deep links contextuels sont essentiels pour l'attribution : sans eux, le propriétaire de l'application ne sait pas quel canal a amené l'utilisateur — trafic organique, publicités Facebook, newsletter par e-mail ou code QR. Une attribution de qualité nécessite une intégration avec un MMP (Mobile Measurement Partner).

Deep Link sur iOS

iOS prend en charge les deep links via deux mécanismes : l'ancien Custom URL Scheme et le moderne Universal Link (iOS 9+). Custom URL Scheme fonctionne en enregistrant un schéma personnalisé dans Info.plist. L'application enregistre myapp://, et iOS ouvre l'application lorsqu'on clique sur ce type de lien. Le problème : si le schéma n'est enregistré par aucune application, le navigateur affiche une erreur.

Le traitement des deep links sur iOS s'effectue via la méthode AppDelegate application(_:open:options:) ou SceneDelegate scene(_:openURLContexts:). Le développeur extrait l'URL, analyse le chemin et les paramètres, puis navigue vers l'écran approprié. Si SwiftUI est utilisé, le traitement s'effectue via OpenURLAction ou onChange(of: openURL). Il est important de traiter correctement l'état de l'application : l'application peut être non lancée, en arrière-plan ou active.

La sécurité sur iOS est stricte : toute application peut intercepter un Custom URL Scheme en enregistrant le même schéma. Il s'agit d'une vulnérabilité potentielle (détournement de schéma URL). C'est pourquoi Apple recommande Universal Link comme alternative plus sécurisée : seul le propriétaire vérifié du domaine peut associer des liens à l'application. En savoir plus sur Universal Link dans l'article Universal Link.

Deep Link sur Android

Android implémente les deep links via des Intent Filters dans AndroidManifest.xml. L'application définit une Activity qui traite un schéma spécifique (myapp://) ou des hôtes et chemins spécifiques. Lorsque l'utilisateur clique sur un deep link, Android recherche une Activity avec un Intent Filter correspondant et l'ouvre. S'il y a plusieurs Activities correspondantes, le système affiche une boîte de dialogue de sélection d'application.

// AndroidManifest.xml - Intent Filter pour Deep Link
<activity
    android:name=".ui.ProductActivity"
    android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data
            android:scheme="myapp"
            android:host="product"
            android:pathPrefix="/" />
    </intent-filter>
</activity>

Le traitement des deep links sur Android s'effectue dans la méthode Activity.onCreate() ou onNewIntent(). Le développeur reçoit l'Intent, extrait l'URI et exécute la navigation. Pour Jetpack Navigation, le composant Navigation Deep Link permet de décrire déclarativement les deep links dans le graphe de navigation. Android App Link (Android 6.0+) est une évolution des deep links avec vérification via Digital Asset Links, éliminant la boîte de dialogue de sélection d'application.

Il est important de prendre en compte les changements d'Android 12+ : à partir de l'API 31, le système exige la déclaration explicite de exported=true pour les Activities traitant les deep links et vérifie la conformité de l'Intent Filter. Google Play Store vérifie la validation d'App Link lors de la publication. Sans validation, Google peut rejeter la mise à jour si les deep links mènent à des pages inexistantes du site web.

Configuration du Deep Link

La configuration des deep links comprend plusieurs étapes communes aux deux plateformes. La première étape consiste à définir le schéma et la structure de l'URL. Il est recommandé d'utiliser le schéma https (plutôt qu'un schéma personnalisé) pour la compatibilité avec Universal Link et App Link. La structure de l'URL doit refléter la structure du site web : /product/42, /profile/john, /settings/notifications. Cela simplifie la maintenance et l'indexation du contenu par les moteurs de recherche.

La deuxième étape est le traitement des deep links dans le code de l'application. Pour Android, Jetpack Navigation avec des deep links déclaratifs dans nav_graph est recommandé. Pour iOS — SwiftUI NavigationStack avec traitement OpenURLAction. Il est important de traiter trois états de l'application : démarrage à froid (application non lancée), démarrage à chaud (en arrière-plan) et actif (à l'écran). Chaque état nécessite une logique de navigation différente.

• Définir le schéma et la structure de l'URL (myapp:// ou https://your.domain/)
• Enregistrer le schéma dans le manifeste (Android) ou Info.plist (iOS)
• Implémenter le traitement dans Activity ou AppDelegate/SwiftUI
• Configurer le fallback pour le cas où l'application n'est pas installée
• Tester les trois états : démarrage à froid, démarrage à chaud, actif

Le test des deep links est une tâche distincte. Android Studio fournit l'outil App Links Assistant pour vérifier les Intent Filters. Sur iOS, le test s'effectue via Xcode en passant une URL par des arguments de schéma de lancement. Il est recommandé de configurer une vérification CI : navigation automatique par deep link et vérification que l'écran attendu s'est ouvert. Pour les deferred deep links, le test inclut le cycle complet « installation → premier lancement → contexte ». Sans tests, les deep links se cassent souvent lors de la mise à jour de la navigation dans l'application.