Pourquoi un lien profond ouvre parfois une application et parfois le navigateur

Un lien profond reçu dans un message ouvre directement une application. Le suivant, pourtant construit avec le même domaine, reste dans le navigateur. Un troisième affiche une fenêtre demandant quelle application utiliser.

Ce comportement paraît aléatoire. Il ne l’est pas tout à fait. Lorsqu’une personne touche un lien comme Inscription à BizBet, le téléphone examine le domaine, les applications installées et les associations déjà vérifiées. Le résultat dépend aussi du navigateur ou de la messagerie depuis laquelle le lien a été ouvert.

Derrière un simple toucher se cache donc une petite négociation.

Un lien profond vise un endroit précis

Une adresse web classique peut envoyer le visiteur vers une page d’accueil. Un lien profond, ou deep link, vise une section particulière : un article, une fiche, un formulaire ou un événement en cours.

L’objectif est d’éviter plusieurs étapes. La personne ne devrait pas avoir à ouvrir l’application, chercher le bon menu puis retrouver le contenu qu’elle avait devant elle quelques secondes plus tôt.

Trois cas sont possibles :

Le troisième cas explique une bonne partie des résultats jugés incohérents.

Android vérifie le propriétaire du domaine

Sur Android, les App Links utilisent des adresses HTTPS ordinaires. Pour qu’une application puisse les ouvrir automatiquement, le site et l’application doivent prouver qu’ils appartiennent au même éditeur.

Le site publie un fichier assetlinks.json dans le dossier /.well-known/. Ce fichier contient notamment l’identité du paquet Android et l’empreinte du certificat utilisé pour signer l’application. Android compare ces informations à celles de l’application installée.

Une seule différence peut casser la vérification :

Élément vérifié	Erreur fréquente	Résultat possible
Nom de domaine	Variante avec ou sans www	Ouverture dans le navigateur
Certificat	Empreinte d’une version de test	Association refusée
Fichier JSON	Syntaxe incorrecte	Vérification impossible
Chemin du lien	Règle trop restrictive	Mauvais écran ou page web
Redirection	Passage vers un autre domaine	Contrôle interrompu

Le lien reste parfaitement valide comme adresse web. C’est son ouverture automatique dans l’application qui ne fonctionne plus.

Depuis Android 15, les Dynamic App Links permettent de modifier certaines règles côté serveur sans publier immédiatement une nouvelle version de l’application. La configuration déclarée dans l’application fixe toutefois les limites générales : les règles distantes ne peuvent pas élargir ce que le manifeste n’a jamais prévu.

iOS utilise une association comparable

Apple appelle ce mécanisme les Universal Links. Le site héberge un fichier d’association et l’application déclare les domaines qu’elle accepte.

Si la correspondance est valide et que l’application est installée, iOS peut transmettre l’adresse à celle-ci. Sans application, Safari ouvre la page web. Le même lien HTTPS reste donc utilisable dans les deux situations.

Les anciens schémas personnalisés, du type monapp://, fonctionnent autrement. Ils peuvent lancer une application, mais n’offrent pas le même lien web de secours. Ils posent également davantage de questions autour de l’application autorisée à revendiquer le schéma.

Les liens universels reposent sur le domaine. Ce détail rend l’association plus difficile à détourner.

Le navigateur intégré change parfois le trajet

Beaucoup de liens ne sont pas ouverts depuis Safari ou Chrome. Ils viennent d’une messagerie, d’un réseau social, d’un lecteur de courrier ou d’une autre application possédant son propre navigateur intégré.

Ce navigateur peut conserver la navigation à l’intérieur de sa fenêtre. Il peut aussi demander une confirmation avant de passer vers une application externe. Certains suppriment des paramètres de l’adresse ou les transmettent différemment.

Le développeur doit donc tester davantage qu’un copier-coller dans la barre d’adresse :

Un essai réussi dans un seul navigateur ne prouve pas que le parcours fonctionne ailleurs.

Le choix précédent de l’utilisateur compte

Le système peut mémoriser une décision. Une personne a peut-être demandé que ce domaine reste dans le navigateur. Sur Android, elle peut retirer l’autorisation d’ouverture automatique dans les réglages de l’application. Sur iOS, certaines interactions précédentes influencent également le passage entre le site et l’application.

Cela explique pourquoi deux téléphones identiques ne réagissent pas toujours de la même manière.

Réinstaller l’application peut relancer certaines vérifications, mais ce n’est pas une solution de diagnostic suffisante. Il vaut mieux contrôler l’état de l’association, les domaines autorisés et la version réellement installée.

La destination doit exister dans l’application

Ouvrir l’application ne suffit pas. Encore faut-il afficher le bon écran.

Le code reçoit l’adresse complète, examine son chemin et ses paramètres, puis choisit une destination interne. Une route inconnue devrait conduire vers une page utile, pas vers un écran vide.

Le test d’une adresse telle que https://africa-bizbet.com/fr/live doit ainsi vérifier deux choses distinctes : quelle application reçoit le lien et quelle section elle présente ensuite.

Cette seconde étape demande quelques précautions. Apple recommande de valider les paramètres reçus et d’empêcher qu’un lien déclenche directement une opération sensible. Une URL peut ouvrir un écran ; elle ne devrait pas supprimer une donnée ou confirmer une action irréversible sans contrôle supplémentaire.

Une méthode courte pour trouver la panne

Quand un lien reste dans le navigateur, modifier plusieurs fichiers à la fois complique le diagnostic.

Mieux vaut suivre l’ordre du trajet :

1. vérifier l’adresse HTTPS et ses redirections
2. ouvrir le fichier d’association depuis le téléphone
3. comparer le domaine déclaré dans l’application
4. contrôler le certificat ou l’identifiant utilisé en production
5. tester avec l’application installée, puis absente
6. répéter l’essai depuis plusieurs applications sources
7. observer enfin la route interne reçue

La panne se trouve souvent dans un caractère.