Migrer depuis Firebase Dynamic Links vers Elido

Firebase Dynamic Links a été arrêté le 25 août 2025. Chaque lien FDL renvoie désormais une erreur 404. Si votre application l'utilisait pour l'attribution d'installation, le deep linking différé ou le routage post-installation vers un écran spécifique, ces flux sont cassés en production en ce moment. Branch.io commence à 199 $/mois pour le niveau qui remplace ce que FDL faisait gratuitement. Le routage de deep links d'Elido couvre les mêmes schémas pour une fraction du coût, avec la résidence des données en UE intégrée.

Voici le chemin le plus court des liens FDL cassés vers des Universal Links fonctionnels et des Android App Links.

En résumé

• Firebase Dynamic Links a été arrêté le 25 août 2025 ; toutes les URLs *.page.link renvoient HTTP 404 depuis cette date, conformément à la FAQ de dépréciation de Firebase Dynamic Links
• L'attribution d'installation, le routage post-installation et les deep links différés de votre application sont cassés si vous n'avez pas encore migré
• La migration consiste en un changement DNS, deux fichiers JSON (un Apple, un Google), et une réécriture de liens - pas une réécriture de code
• Le niveau d'entrée de Branch.io pour ce cas d'usage est à 199 $/mois ; Elido Pro couvre le même routage à un coût sensiblement inférieur sans facturation par lien
• Vous n'avez pas besoin de modifier votre code de gestion des deep links existant en Swift ou Kotlin - le handoff Universal Link / App Link au niveau du système d'exploitation fonctionne de la même manière quel que soit le service qui héberge le routage

Ce que Firebase Dynamic Links faisait réellement

FDL était la réponse de Google à trois problèmes que les liens HTTPS simples ne peuvent pas résoudre seuls.

Deep linking différé. Un utilisateur sur un appareil sans votre application clique sur un lien. Le système d'exploitation ouvre l'App Store ou le Play Store. L'utilisateur installe l'application. L'application s'ouvre sur un écran d'accueil générique et ne sait pas que l'utilisateur essayait d'accéder à un contenu spécifique. FDL stockait la destination prévue et la transmettait après la fenêtre d'installation - l'application pouvait interroger le SDK de FDL au premier lancement et rediriger l'utilisateur vers le bon écran.

Attribution d'installation. Les liens FDL portaient des paramètres de campagne (utm_source, utm_medium, paramètres personnalisés via ?st= et ?si=) qui survivaient à l'installation. C'est le mécanisme qui permettait d'attribuer une installation à une campagne e-mail spécifique, une créative sociale payante ou un lien d'influenceur sans MMP tiers.

Routage adapté à la plateforme. Un lien, trois destinations : les utilisateurs iOS allaient vers l'App Store (ou directement dans l'application si installée), les utilisateurs Android vers le Play Store (ou l'application), et les navigateurs de bureau recevaient une URL de repli configurable. Le routage se faisait côté serveur en périphérie chez Google, pas dans le code de votre application.

Quand FDL s'est arrêté, ces trois capacités ont toutes retourné une erreur 404 simultanément. Si vous utilisiez le SDK FDL dans votre application, il appelle un point de terminaison qui n'existe plus.

L'équivalent Elido

Elido reproduit les trois mêmes comportements via la détection de plateforme en périphérie de redirection et les mécanismes de deep link natifs du système d'exploitation.

Détection de plateforme en périphérie. Un lien court Elido inspecte l'en-tête User-Agent au moment de la redirection et route vers différentes destinations selon la plateforme : iOS vers l'URL de l'App Store (ou le lien universel de l'application), Android vers l'URL du Play Store (ou l'intent de lien d'application), bureau vers votre repli web. Cela se produit en moins de 5 ms en périphérie de redirection. Pas d'appel SDK, pas d'aller-retour vers un service d'attribution séparé.

Universal Links iOS. Quand votre application est installée sur l'appareil, iOS intercepte le lien HTTPS avant que le navigateur ne s'ouvre. Cela nécessite de servir un fichier Apple App Site Association (apple-app-site-association) depuis le chemin well-known de votre domaine personnalisé. Elido héberge ce fichier en votre nom lorsque vous configurez un domaine personnalisé avec le routage de deep links activé. Le résultat est identique à ce que FDL offrait : l'application s'ouvre directement sur l'écran lié.

Android App Links. Même mécanisme sur Android, format de fichier différent. Le fichier assetlinks.json de Google réside à /.well-known/assetlinks.json sur votre domaine. Elido génère et sert ce fichier lorsque vous fournissez le nom de paquet de votre application et l'empreinte du certificat SHA-256. Android App Links ouvre votre application directement sans interstitiel de navigateur.

Transmission de deep link différé. Pour le cas de fenêtre d'installation (l'utilisateur n'a pas encore l'application), Elido stocke la destination de deep link prévue pour l'URL courte et l'expose via un point de terminaison de requête léger. Votre application appelle ce point de terminaison au premier lancement avec l'URL courte depuis laquelle elle a été installée - récupérable depuis le référent d'installation sur Android (INSTALL_REFERRER) et l'API d'attribution de l'App Store sur iOS - et obtient en retour le chemin de deep link d'origine. Pas de SDK FDL, pas de handshake propriétaire. Le guide des deep links couvre le contrat du point de terminaison de requête.

La page de fonctionnalité complète est à /features/deep-links.

Migration étape par étape

Cela suppose que vous avez un compte Elido sur Pro ou supérieur et un domaine personnalisé que vous contrôlez. Prévoyez 30 minutes pour une migration simple ; ajoutez une marge si votre volume de liens FDL est assez grand pour nécessiter un script de réécriture en masse.

Étape 1 : Ajouter votre domaine personnalisé à Elido

Dans le tableau de bord Elido, allez dans Espace de travail → Domaines personnalisés → Ajouter un domaine. Entrez votre domaine de marque prévu (ex. links.yourapp.com). Elido vous montrera un enregistrement CNAME à créer.

Chez votre registraire DNS, ajoutez le CNAME :

links.yourapp.com.  CNAME  cname.elido.me.

Recommandation TTL : réduisez-le à 300 secondes quelques heures avant si le TTL actuel est à 3600 ou plus. Le provisionnement TLS est automatique via le TLS à la demande et se termine en quelques minutes après la propagation DNS.

Étape 2 : Configurer iOS Universal Links (fichier AASA)

Dans les paramètres du domaine, activez le Routage de deep links et fournissez :

• L'identifiant de bundle iOS de votre application (ex. com.yourcompany.yourapp)
• Les schémas de chemin URL qui doivent ouvrir l'application (ex. /l/* pour tous les liens courts, ou des chemins spécifiques)

Elido génère et sert le fichier AASA à https://links.yourapp.com/.well-known/apple-app-site-association. Vérifiez qu'il se résout correctement avant de continuer :

curl -s https://links.yourapp.com/.well-known/apple-app-site-association | python3 -m json.tool

La réponse doit inclure votre identifiant de bundle dans le tableau applinks.details. Le CDN iOS met en cache le fichier AASA et l'actualise selon un calendrier ; forcez une actualisation lors des tests en réinitialisant le cache AASA de l'appareil via Développeur → Réinitialiser dans les Réglages iOS, ou en installant l'application fraîche.

Le fichier Info.plist de votre application doit déclarer le domaine associé. S'il le fait déjà pour votre domaine FDL, ajoutez le nouveau domaine à côté pendant la période de chevauchement :

<key>com.apple.developer.associated-domains</key>
<array>
  <string>applinks:links.yourapp.com</string>
  <!-- garder le domaine FDL pendant le chevauchement si nécessaire -->
</array>

Étape 3 : Configurer Android App Links (assetlinks.json)

Dans le même panneau de paramètres de deep links, fournissez :

• Le nom de paquet de votre application (ex. com.yourcompany.yourapp)
• L'empreinte SHA-256 de votre certificat de signature de publication

Récupérez l'empreinte si vous ne l'avez pas en cache :

keytool -list -v -keystore release.keystore -alias your-alias | grep SHA256

Elido génère et sert le fichier à https://links.yourapp.com/.well-known/assetlinks.json. Vérifiez :

curl -s https://links.yourapp.com/.well-known/assetlinks.json | python3 -m json.tool

Le filtre d'intent de votre AndroidManifest.xml devrait déjà être configuré pour App Links si vous utilisiez FDL avec la fonctionnalité de vérification automatique du SDK Android. Sinon, ajoutez l'attribut android:autoVerify="true" à votre filtre d'intent de deep link et pointez-le vers le nouveau domaine.

Étape 4 : Réécrire vos liens FDL existants

Les liens FDL ont la forme https://yourapp.page.link/SLUG ou https://yourapp.page.link/?link=https%3A%2F%2F...&.... Aucun de ces schémas ne continuera à fonctionner - le domaine page.link est mort.

Si vous avez créé un petit nombre de liens FDL (moins de quelques centaines), réécrivez-les manuellement dans le tableau de bord Elido. Si vous en avez créé des milliers - courant pour les campagnes e-mail ou les impressions de QR codes - utilisez l'API d'importation en masse d'Elido :

curl -X POST https://api.elido.app/v1/links/bulk \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "links": [
      {
        "slug": "welcome",
        "destination": "https://yourapp.com/welcome",
        "routing": {
          "ios": "https://apps.apple.com/app/id12345678",
          "android": "https://play.google.com/store/apps/details?id=com.yourcompany.yourapp",
          "fallback": "https://yourapp.com/welcome"
        }
      }
    ]
  }'

Pour les liens déjà imprimés sur des supports physiques (emballages, affiches, cartes de visite), vous ne pouvez pas mettre à jour l'URL elle-même - mais si l'URL imprimée était un lien FDL sur domaine personnalisé pointant vers un domaine que vous contrôlez, vous pouvez rediriger le CNAME de ce domaine vers Elido et le lien imprimé recommencera à fonctionner avec votre nouvelle configuration de routage.

Étape 5 : Mettre à jour la requête de deep link différé au premier lancement de l'application

Les applications FDL appellent FirebaseDynamicLinks.dynamicLinks().handleUniversalLink(url) ou la méthode SDK équivalente au premier lancement. Supprimez cela. Remplacez-le par un appel au point de terminaison de deep link différé d'Elido :

// iOS - au premier lancement après installation
let installURL = "https://links.yourapp.com/welcome" // récupéré depuis l'attribution StoreKit
let endpoint = URL(string: "https://api.elido.app/v1/deferred?url=\(installURL.addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed)!)")!
URLSession.shared.dataTask(with: endpoint) { data, _, _ in
    guard let data, let result = try? JSONDecoder().decode(DeferredLink.self, from: data) else { return }
    DispatchQueue.main.async { self.navigate(to: result.deepLink) }
}.resume()

L'équivalent Android utilise l'API Play Install Referrer pour récupérer l'URL courte, puis appelle le même point de terminaison. Le guide des deep links contient des exemples de code complets pour les deux plateformes.

Étape 6 : Tester de bout en bout

Avant de basculer, testez les trois cas :

1. Application installée, lien cliqué sur l'appareil - touchez le lien court dans Safari/Chrome, confirmez que l'application s'ouvre directement sur le bon écran sans interstitiel de navigateur.
2. Application non installée, lien cliqué - touchez le lien, confirmez qu'il redirige vers la bonne page App Store / Play Store.
3. Application installée depuis le store après avoir cliqué sur un lien - installez l'application fraîche, confirmez qu'elle s'ouvre sur l'écran prévu au premier lancement (chemin de deep link différé).

Testez sur un appareil physique pour Universal Links. Les simulateurs iOS n'exécutent pas le handoff AASA de manière fiable.

Cas particuliers

Paramètres FDL que vous lisiez dans l'application. Si votre application appelait DynamicLink.dynamicLink().url pour lire les paramètres d'un lien FDL après ouverture, ces paramètres ont disparu. Vous devez encoder les mêmes informations dans l'URL de destination de votre lien court Elido en tant que paramètres de requête et les lire depuis l'URL de deep link que iOS ou Android envoie à votre application. L'encodage des paramètres est le même - ?screen=onboarding&ref=email_april - simplement déplacé du wrapper propriétaire link= de FDL dans l'URL de destination elle-même.

Perte d'attribution. L'attribution de FDL était autonome : Google stockait les paramètres de campagne et les retournait au SDK. Elido stocke les données d'événement de clic (horodatage, plateforme, pays, référent) dans notre entrepôt d'analytique et les expose via l'API d'analyse, mais ce n'est pas un MMP (partenaire de mesure mobile). Si vous avez besoin d'une attribution d'installation probabiliste ou déterministe à grande échelle - analyse de cohorte, LTV par source d'acquisition, assemblage SKAdNetwork - vous avez besoin soit d'un MMP (Adjust, AppsFlyer), soit d'instrumenter le webhook de clics Elido dans votre propre pipeline d'analyse. Pour la plupart des applications indépendantes et des équipes en phase précoce qui utilisaient FDL purement pour "rediriger l'utilisateur vers le bon écran", les analyses d'Elido sont suffisantes. Pour les équipes d'acquisition payante qui gèrent une attribution multi-canal, voir la section suivante.

URLs courtes FDL existantes intégrées dans le binaire de votre application. Si vous avez codé en dur des URLs courtes FDL dans le code de votre application (charges utiles de notifications push générées côté client, liens de parrainage créés depuis l'application), ces chaînes référencent un domaine mort. Vous avez besoin d'une mise à jour forcée de l'application ou d'un point de terminaison côté serveur qui génère la nouvelle URL courte à la demande. Il n'y a aucun moyen de rediriger page.link - Google a complètement arrêté le domaine.

URLs FDL longues avec paramètres encodés. FDL supportait des URLs longues comme https://yourapp.page.link/?link=https%3A%2F%2F...&ibi=com.yourapp&ifl=...&afl=.... Ces paramètres (ibi, ifl, afl, isi) sont spécifiques à FDL. Faites correspondre aux champs de routage Elido : ifl (repli iOS) vers routing.ios, afl (repli Android) vers routing.android, ibi (identifiant de bundle iOS) est déjà configuré au niveau du domaine dans Elido. Le paramètre link devient votre URL de destination.

Résidence des données en UE. Si votre application opère dans l'UE et que vous traitez des données d'utilisateurs européens, les événements de redirection - y compris les adresses IP et les chaînes User-Agent - sont des données personnelles au sens du RGPD. FDL était hébergé sur l'infrastructure mondiale de Google avec un traitement aux États-Unis. Elido est hébergé dans la région UE par défaut ; les événements de clics en UE restent dans l'UE. La page de confiance et la vue d'ensemble de la conformité couvrent les spécificités contractuelles.

Quand vous avez réellement besoin de Branch.io à la place

Elido est le bon choix pour la plupart des applications qui utilisaient FDL pour le routage d'écran et l'attribution d'installation de base. Ce n'est pas le bon choix si vous dépendez de :

Attribution probabiliste pour l'acquisition payante. Branch s'intègre avec les réseaux publicitaires (Meta, Google, TikTok, Snap) via des postbacks et peut attribuer des installations de manière probabiliste lorsque l'empreinte déterministe n'est pas disponible - par exemple, sur iOS 14.5+ avec ATT non consenti. Elido ne fait pas d'attribution probabiliste. Si votre équipe de croissance gère de l'acquisition payante et a besoin de réconcilier les installations avec les dépenses publicitaires au niveau de la cohorte, Branch ou un MMP (Adjust, AppsFlyer) est le bon outil pour ce problème spécifique.

Empreinte digitale et correspondance d'appareils au niveau SDK. Le SDK de Branch collecte des signaux d'appareils (résolution d'écran, IP, langue, fuseau horaire) pour identifier un appareil après la fenêtre d'installation sans dépendre d'un référent d'installation. La correspondance uniquement par référent se dégrade dans les environnements où le référent est supprimé - si le taux de succès de votre deep link différé doit dépasser environ 80 %, l'approche au niveau SDK fonctionne mieux.

Intégration approfondie avec des réseaux publicitaires spécifiques. Branch dispose d'intégrations dédiées avec le CAPI de Meta, le suivi des conversions de Google et l'API d'événements de TikTok qui vont au-delà de ce que couvre le transfert de conversions côté serveur d'Elido. Si votre stack d'attribution est étroitement couplé à l'un de ces réseaux, évaluez la documentation d'intégration spécifique de Branch avant de changer.

Le test pratique : si vous utilisiez FDL principalement pour rediriger les utilisateurs vers le bon écran après l'installation, et que vos besoins en attribution sont couverts par les paramètres UTM dans votre outil d'analyse, Elido remplace FDL à moindre coût. Si vous gérez des campagnes de performance marketing à grande échelle et que la précision de l'attribution oriente les décisions budgétaires, c'est la vraie proposition de valeur de Branch et 199 $/mois achète une vraie infrastructure pour cela.

FAQ

Mon application contient des liens courts FDL dans les charges utiles de notifications push - que se passe-t-il quand les utilisateurs cliquent dessus ?

Les liens pointent vers page.link, qui renvoie une erreur 404. La gestion des liens par le système d'exploitation renvoie le 404 au navigateur ou au gestionnaire de liens universels de votre application, ce qui échouera. Vous devez mettre à jour votre service de notifications push pour générer des liens courts Elido à la place. Si vous générez des charges utiles push côté serveur (l'approche correcte), c'est un changement d'une ligne pour appeler l'API Elido au lieu de l'API FDL. Si les charges utiles sont générées côté client depuis des modèles codés en dur, une mise à jour de l'application est nécessaire.

Dois-je publier une mise à jour de l'application pour terminer la migration ?

Pour la requête de deep link différé (routage après la fenêtre d'installation), oui - vous devez remplacer l'appel SDK FDL par l'appel au point de terminaison Elido, ce qui nécessite une mise à jour de l'application. Pour Universal Links et Android App Links vers l'application déjà installée, aucune mise à jour n'est nécessaire une fois que le DNS et les fichiers AASA/assetlinks.json sont en place - le système d'exploitation interroge ces fichiers depuis le serveur, pas depuis le binaire de l'application. L'exception : si votre Info.plist / AndroidManifest.xml ne déclare pas encore votre nouveau domaine comme domaine associé, cela nécessite une mise à jour de l'application.

Que se passe-t-il avec les clics sur les anciens liens FDL après avoir terminé la migration ?

Si l'ancien lien était sur un domaine page.link : rien - ce domaine est mort et ces liens sont irrécupérables. Si vous utilisiez un domaine personnalisé pour FDL (moins courant mais supporté), redirigez le CNAME du domaine vers Elido et configurez des règles de routage équivalentes ; les anciennes URLs recommenceront à fonctionner.

Elido dispose-t-il d'un SDK ?

Elido ne nécessite pas de SDK pour Universal Links ou App Links - ce sont des mécanismes natifs du système d'exploitation. Pour le point de terminaison de requête de deep link différé, vous effectuez un appel HTTPS standard ; aucune dépendance SDK n'est nécessaire. Si vous voulez un client typé, le SDK Go Elido, le SDK TypeScript et le SDK Python encapsulent tous l'API de deep link, mais il n'y a pas de SDK iOS/Android et vous n'en avez pas besoin. C'est voulu - moins il y a de SDK tiers dans une application en production, mieux c'est.

Combien de temps prend la propagation de l'AASA / assetlinks.json ?

Une fois votre DNS propagé (quelques minutes à une heure selon le TTL), les fichiers AASA et assetlinks.json sont immédiatement disponibles depuis la périphérie d'Elido. iOS actualise sa copie mise en cache du fichier AASA lors de l'installation de l'application et périodiquement par la suite ; le délai que vous remarquerez lors des tests est la latence du cache iOS, pas la latence de service d'Elido. Pour un test propre, installez l'application fraîche après la propagation du changement DNS.

---

Si vous examinez l'ensemble des fonctionnalités de deep linking, la page /features/deep-links couvre la matrice de support de plateforme et la profondeur des règles de routage. Pour les spécificités de résidence des données en UE pertinentes aux applications mobiles qui collectent des données d'utilisateurs européens, la vue d'ensemble de la conformité contient le DPA et la liste des sous-traitants que votre équipe de protection des données vous demandera.

À lire aussi sur le blog

• Deep links sans SDK : comment Universal Links et App Links fonctionnent réellement
• Résidence des données en UE pour les outils marketing : ce que votre DPO demande réellement
• Smart links expliqués : routage par appareil, géo, heure du jour et référent
• Migrer depuis Bitly sans casser les liens : un guide des modes d'échec