Alternative à Firebase Dynamic Links : comment les remplacer après l'arrêt

Si vous cherchez en 2026 une alternative à Firebase Dynamic Links, commencez par distinguer ce dont vous avez réellement besoin de ce que l’ancien produit regroupait autrefois. La plupart des équipes ont surtout besoin de trois choses : une URL HTTPS de marque, un routage fiable selon l’appareil et un comportement de fallback propre pour le web desktop et mobile. Beaucoup moins d’équipes ont besoin d’un deferred deep linking complet ou d’une logique d’attribution mobile avancée. Cette différence est importante, car elle change à la fois le coût de migration et la bonne architecture de remplacement.

D’après la FAQ officielle de Firebase Dynamic Links, Firebase Dynamic Links a été déprécié puis devait être arrêté le 25 août 2025. Si vos campagnes, vos flux de téléchargement d’app, vos QR codes ou vos liens d’onboarding dépendaient encore de ces URLs, la voie la plus sûre consiste désormais à reconstruire votre couche de liens sur des briques stables : domaines personnalisés, redirections HTTP, fichiers d’association d’app natifs et destinations de secours explicitement définies.

Si ce remplacement s’inscrit dans une refonte plus large ou un changement de domaine, gardez aussi sous la main notre checklist de redirections pour une migration de site. La plupart des migrations Firebase Dynamic Links échouent pour les mêmes raisons qu’une migration de site : inventaire incomplet et règles de fallback trop vagues.

À quoi servaient réellement Firebase Dynamic Links

Quand une équipe dit qu’elle a besoin d’un remplaçant à Firebase Dynamic Links, elle parle généralement de l’un de ces cas :

Envoyer les utilisateurs iPhone vers l’App Store et les utilisateurs Android vers Google Play.
Envoyer les visiteurs desktop vers une landing page ou une page avec QR code.
Conserver une URL de marque propre plutôt que partager un long lien d’App Store.
Préserver les paramètres de campagne pour la mesure.
Ouvrir l’application installée via la gestion native des liens.

Ce ne sont pas exactement les mêmes problèmes.

Par exemple :

Le fallback vers les stores et le routage par appareil relèvent surtout d’un problème de redirection HTTP.
L’ouverture d’une app déjà installée dépend le plus souvent des Android App Links et des Apple Universal Links.
Le deferred deep linking après installation demande souvent une logique supplémentaire côté app ou une pile d’attribution dédiée.
La conservation des paramètres de campagne est un problème de qualité de redirection. Si c’est un point clé pour vous, définissez la gestion des chemins et des query strings explicitement dès la phase de spécification.

[!TIP] La migration la plus rapide n’est généralement pas « remplacer Firebase fonctionnalité par fonctionnalité », mais « remplacer uniquement les comportements dont les équipes produit et marketing ont réellement besoin ».

La décision la plus simple pour migrer

Utilisez cette règle pratique :

Vous avez seulement besoin de smart routing

Si votre objectif est :

iOS -> App Store
Android -> Google Play
desktop -> site web ou page QR

alors une couche de redirection intelligente suffit souvent. C’est le cas d’usage le plus naturel pour un service comme UrlEdge Device Targeting.

Vous devez ouvrir directement l’app installée

Si vous voulez :

ouvrir directement l’app iOS installée
ouvrir directement l’app Android installée
renvoyer les utilisateurs non équipés vers le store ou le web

alors il vous faut les deux :

une couche de routage de liens
une configuration d’app links natifs côté app et côté domaine

Concrètement, cela signifie publier les bons fichiers AASA et assetlinks.json, puis vérifier que votre app sait bien gérer le chemin ciblé.

Vous avez besoin de deferred deep linking ou d’attribution

Si votre équipe growth dépend de :

l’attribution d’installation
l’envoi vers des écrans précis après installation
la correspondance de campagne pendant le parcours d’installation

alors ne partez pas du principe qu’un service de redirection générique suffira seul. Dans ce cas, utilisez une couche de redirection pour le contrôle des liens de marque, puis combinez-la avec la stack mobile qui gère déjà l’attribution et l’état applicatif dans votre organisation.

Une architecture pratique pour remplacer Firebase Dynamic Links

Pour beaucoup d’équipes, la migration ressemble à ceci :

Ordinateur portable et smartphone utilisés ensemble pour représenter des smart links de marque, le device targeting et les fallbacks vers les stores

smart.votremarque.com/promo
  -> détection de l’appareil à l’edge
  -> iOS : destination App Store ou Universal Link
  -> Android : destination Google Play ou App Link
  -> Desktop : landing page, documentation ou page de relais avec QR code

Cette architecture présente plusieurs avantages :

votre domaine reste sous votre contrôle
le comportement de fallback est explicite et testable
vos liens marketing ne sont pas verrouillés à un seul fournisseur mobile
vous pouvez ajouter plus tard analytics, règles géographiques ou overrides temporaires

Pour les équipes qui ont surtout besoin de routage et de fallback, cette approche est souvent plus maintenable que de reconstruire une plateforme de deep linking monolithique.

Plan de migration étape par étape

Étape 1 : inventorier tous les Dynamic Links actifs

Ne migrez pas à l’aveugle. Exportez toutes les URLs actives depuis :

les campagnes payantes
les emails lifecycle
les bios sociales
les QR codes
la documentation partenaire
les parcours d’onboarding mobile
les referrals in-app

Créez un tableau avec au minimum ces colonnes :

old_dynamic_link,owner,use_case,ios_destination,android_destination,desktop_destination,notes
https://xyz.page.link/sale,growth,app download,https://apps.apple.com/app/...,https://play.google.com/store/apps/...,https://yourbrand.com/sale,seasonal campaign

Vous éviterez ainsi le scénario classique où l’équipe engineering migre les liens les plus évidents et où le marketing découvre deux semaines plus tard qu’il manque des destinations QR ou email.

Ce tableau ressemble beaucoup à celui que nous recommandons dans notre checklist de redirections pour une migration de site, car dans les deux cas tout repose sur une redirect map fiable avant le lancement.

Étape 2 : classer les liens par comportement, pas par canal

Rangez chaque lien dans l’une de ces catégories :

Fallback vers les stores uniquement
Fallback vers le web uniquement
App link natif avec fallback
Logique spéciale de campagne, de géolocalisation ou d’appareil

Cette classification vous dira si une plateforme de redirection suffit à elle seule ou si vous avez aussi besoin d’un vrai travail côté app.

Étape 3 : déplacer les liens de marque sur un domaine que vous contrôlez

Une migration est le bon moment pour cesser de dépendre, lorsque c’est possible, de domaines courts contrôlés par un produit tiers. Utiliser votre propre domaine vous apporte :

le contrôle du SSL et du DNS
la propriété durable des liens
une meilleure cohérence de marque et de SEO
moins de dépendance à une plateforme

Un host comme go.votremarque.com ou links.votremarque.com est généralement plus simple à gouverner que de mélanger vos app links à votre domaine marketing principal.

Étape 4 : définir explicitement les destinations selon la plateforme

Ne laissez pas le mot « fallback » dans le flou. Écrivez ce qui doit se passer.

Exemple :

iPhone -> App Store
Téléphone Android -> Google Play
Desktop -> landing page produit avec QR code
Tablette -> soit le web desktop, soit le store, selon votre produit

Si vous savez déjà que votre comportement doit varier selon l’appareil, utilisez le routage par appareil au lieu de faire passer toute la logique par une redirection générique.

Étape 5 : mettre en place les app links natifs là où c’est vraiment nécessaire

Si l’app installée doit s’ouvrir directement, terminez correctement le travail natif :

configurez les Android App Links
configurez les Apple Universal Links
testez le matching de chemins dans l’app
confirmez que l’app gère bien les nouvelles installations comme les utilisateurs récurrents

C’est l’étape que beaucoup d’équipes sous-estiment. Une couche de redirection peut envoyer le trafic au bon endroit, mais elle ne peut pas inventer la gestion applicative des liens pour vous.

Étape 6 : tester sur de vrais appareils et de vrais navigateurs

Au minimum, testez :

iPhone Safari
navigateurs intégrés sur iPhone
Android Chrome
navigateurs intégrés sur Android
desktop Chrome
desktop Safari

Testez aussi ces variantes :

app installée
app non installée
paramètres de campagne présents
scan de QR code depuis une page générée sur desktop

Pour le débogage, un outil comme Redirect Checker vous aide à inspecter le comportement réel des redirections au lieu de vous fier uniquement aux dashboards de campagne.

Erreurs de migration les plus fréquentes

Traiter tous les liens comme un seul besoin

Fallback store, ouverture de l’app installée et deferred deep linking sont des besoins différents. Si vous les mélangez, vous risquez soit de trop acheter, soit de sous-construire la solution.

Oublier le comportement desktop

Beaucoup de projets de liens mobiles se cassent sur desktop parce que les équipes n’optimisent que pour iOS et Android. Votre fallback desktop fait partie de l’expérience produit, ce n’est pas un détail secondaire.

Ignorer le tracking de campagne

Si vos anciens liens transportaient des paramètres utm_ ou des identifiants de campagne, conservez-les intentionnellement. Ne supposez pas que chaque chemin de remplacement transmettra automatiquement les query strings.

Attendre après le lancement pour mettre en place le monitoring

Une migration sans observabilité n’est qu’une suite de suppositions. Assurez-vous de pouvoir inspecter les clics et les destinations défaillantes dès le départ avec analytics.

Quand UrlEdge est particulièrement pertinent

UrlEdge est le plus fort lorsque votre besoin de remplacement concerne surtout le contrôle du routage :

domaines personnalisés de marque
fallback vers l’App Store et Google Play
fallback vers le web desktop
règles selon l’appareil
règles géographiques
validation des redirections
analytics à l’edge

C’est particulièrement utile lorsque vous voulez que la couche de routage reste indépendante du cycle de release de votre app.

Si votre équipe a aussi besoin d’une attribution post-installation poussée ou de deferred deep linking, gardez un cadre honnête : utilisez UrlEdge pour la couche de routage et combinez-le avec la stack mobile qui gère l’attribution et l’état applicatif chez vous.

FAQ

Puis-je conserver un seul lien pour tous les appareils ?

Oui. C’est l’un des schémas de migration les plus courants. Une seule URL de marque peut envoyer iOS vers l’App Store, Android vers Google Play et desktop vers un site web ou une page de relais avec QR code.

Ai-je encore besoin d’Universal Links ou d’App Links ?

Oui, si vous voulez ouvrir directement l’application installée. Les redirections HTTP et les associations natives d’app résolvent des couches différentes du problème.

Et si j’utilisais Firebase Dynamic Links seulement pour les pages de téléchargement d’app ?

Dans ce cas, votre migration est souvent beaucoup plus simple que prévu. Dans bien des cas, des smart links basés sur l’appareil, des fallbacks explicites vers les stores et une bonne gestion des paramètres de campagne suffisent.

Dois-je migrer les anciens liens un par un ?

Pas manuellement si vous pouvez l’éviter. Commencez par un inventaire, classez le comportement des liens, puis définissez les destinations de façon systématique. C’est bien plus sûr qu’un remplacement improvisé lien par lien.

Routage de base

Règles intelligentes

Sécurité et surveillance

Utilitaires et vérificateurs

Commencez à créer gratuitement

Entreprise et communauté

Juridique et conformité

Documentation