Configurer Universal Links et App Links après Firebase

Si vous avez encore d’anciens liens d’app dans des QR codes, des emails, des campagnes paid social ou des parcours d’onboarding, votre vrai sujet n’est plus "trouver un remplaçant à Firebase". Votre sujet est de garder des liens publics fiables sans casser l’ouverture d’app, le fallback ni la mesure.

C’est pour cela qu’il faut séparer les briques que Firebase Dynamic Links mélangeait :

1. le lien public de marque
2. l’ouverture native de l’app
3. le fallback vers l’App Store, Google Play ou le web
4. la conservation des paramètres de campagne

La FAQ officielle de Firebase Dynamic Links indique que le service a été arrêté le 25 août 2025. Si vos anciens liens vivent encore dans des campagnes, des QR, des pages de téléchargement ou des parcours referral, il vaut mieux reconstruire une couche de liens plus lisible que chercher un clone.

Universal Links et App Links ne suffisent pas à eux seuls

Les deux sont indispensables, mais ils ne font pas tout.

Universal Links

Apple Universal Links permettent d’ouvrir une app iOS installée depuis un lien HTTPS classique si :

• le domaine est bien associé à l’app
• la capability est correctement déclarée
• le domaine sert un apple-app-site-association valide
• le chemin reçu correspond à ce que l’app sait traiter

Android App Links

Android App Links couvrent le même besoin côté Android. Il faut pour cela :

• un domaine vérifié
• une configuration correcte dans le manifest
• un assetlinks.json valide
• un handling propre des routes dans l’app

Ce qu’il manque encore

Même avec Universal Links et App Links, il reste à gérer :

• le fallback desktop
• la page ou le store pour les utilisateurs sans app
• l’URL de marque partagée par marketing
• la préservation des UTM
• les overrides temporaires de campagne

Autrement dit : il faut aussi une couche de routage.

L’architecture la plus saine après Firebase

Pour beaucoup d’équipes, la pile la plus simple ressemble à ceci :

go.votremarque.com/promo
  -> détection de l’appareil à l’edge
  -> iPhone avec app : Universal Link
  -> iPhone sans app : App Store
  -> Android avec app : App Link
  -> Android sans app : Google Play
  -> Desktop : landing page, page d’aide ou page avec QR

Cette approche a plusieurs avantages :

• le domaine reste sous votre contrôle
• le fallback est explicite
• marketing partage une URL propre
• mobile et growth testent le même flux réel

Le vrai point de friction : les fichiers d’association

Beaucoup d’équipes savent qu’il faut publier :

• apple-app-site-association
• assetlinks.json

mais se bloquent quand le site principal tourne sur Shopify, Webflow, Wix ou un CMS peu flexible côté racine.

C’est justement un cas d’usage où UrlEdge est utile. Avec custom response, vous pouvez servir ces fichiers depuis l’edge sans transformer cette étape en chantier séparé.

Plan de mise en place

1. Inventoriez tous les liens publics

Ne migrez pas "de mémoire". Récupérez les liens depuis :

• campagnes paid
• QR codes
• boutons de téléchargement
• emails lifecycle
• pages support
• liens social bio
• parcours referral

2. Séparez ouverture d’app et fallback

Pour chaque lien important, posez ces questions :

1. si l’app est installée, faut-il l’ouvrir ?
2. sinon, faut-il envoyer vers le store ou vers le web ?
3. que voit l’utilisateur desktop ?
4. faut-il conserver des UTM ?

3. Choisissez votre domaine public canonique

En général :

• go.votremarque.com
• app.votremarque.com
• links.votremarque.com

Cela réduit la dépendance à un hostname tiers et simplifie les futures migrations.

4. Validez les fichiers d’association

Appuyez-vous sur la documentation officielle :

• Apple Universal Links
• Android App Links

Si cette couche est incorrecte, l’ouverture native restera instable même si le redirect général paraît fonctionner.

5. Définissez des règles de fallback explicites

Par exemple :

• iOS avec app -> app
• iOS sans app -> App Store
• Android avec app -> app
• Android sans app -> Google Play
• desktop -> landing page ou QR handoff

Ne laissez pas ce comportement à l’implicite.

6. Testez dans les vrais contextes

Testez au minimum :

• iPhone Safari
• Android Chrome
• navigateurs in-app des réseaux ou apps de messagerie
• desktop
• QR scanné depuis mobile
• liens avec paramètres de campagne

C’est là que vous verrez la différence entre "le lien répond" et "le parcours complet fonctionne".

Les erreurs les plus fréquentes

Croire que le device routing remplace Universal Links et App Links

Non. Le routing choisit une destination. Universal Links et App Links donnent la confiance native au niveau OS.

Oublier le desktop

Un desktop fallback mal défini casse vite les pages d’aide, les docs, les parcours sales et les usages QR vus depuis un ordinateur.

Perdre les UTM

Si vos liens vivent dans l’email, WhatsApp, QR ou paid social, les paramètres doivent survivre au redirect. Sinon le trafic arrive, mais l’analyse devient floue.

Empiler trop de couches

Plus vous ajoutez de shorteners, de redirects intermédiaires et de pages tampons, plus le débogage devient pénible.

Où UrlEdge apporte de la valeur

UrlEdge est pertinent si vous avez besoin de réunir :

• une URL publique de marque
• un routage par appareil
• un fallback store ou web
• la conservation des paramètres de campagne
• l’analytics du clic
• la publication des fichiers de vérification à l’edge

Cela ne remplace pas toute la partie attribution mobile avancée, mais cela redonne le contrôle sur le lien public et sur le fallback, qui sont souvent les points les plus visibles pour l’utilisateur.

En résumé

Après Firebase Dynamic Links, la meilleure réponse n’est généralement pas "un autre outil magique". C’est une architecture plus propre :

• domaine de marque
• routage par appareil
• Universal Links et App Links bien vérifiés
• fallback explicite
• paramètres de campagne préservés

Moins de magie. Plus de contrôle.