Liens profonds dans une application : retrouver le bon écran après connexion

Le bon rendez-vous, mais pas forcément le bon compte

Une personne reçoit un rappel pour un atelier réservé à son nom. Elle touche le lien sur son téléphone. L'application s'ouvre, mais un autre compte est encore connecté. Faut-il afficher le rendez-vous, demander de changer de compte ou revenir à l'accueil ?

La réponse paraît évidente quand on pose la question ainsi. Pourtant, un cahier des charges limité à « ajouter des liens profonds » ne la donne pas. Le lien désigne une destination ; il ne décide pas à lui seul qui peut la consulter.

Ce guide part d'un service de réservation fictif pour expliquer les choix à faire avant le développement. L'objectif est simple : permettre à la personne de poursuivre ce qu'elle venait faire, sans contourner la sécurité et sans lui demander de tout rechercher. Ce n'est ni une étude de cas Appfyl ni une promesse de résultat chiffré.

Commencer par distinguer information publique et accès personnel

La fiche publique d'un atelier peut présenter un lieu, une date et une description. La réservation personnelle contient autre chose : identité, statut, documents éventuels, options choisies. Ces deux destinations ne doivent pas recevoir les mêmes règles d'accès, même si elles concernent le même événement.

Pour chaque famille de liens, précisez ce qui peut apparaître avant connexion et ce qui nécessite une vérification. Vous éviterez ainsi deux excès : imposer un compte pour lire une description publique, ou exposer un dossier privé à quiconque possède l'adresse.

Une invitation transférable mérite une décision explicite. Peut-on la transmettre à quelqu'un d'autre ? Est-elle réservée au destinataire ? Expire-t-elle après utilisation ? Le nom du mécanisme technique ne répond à aucune de ces questions. Elles appartiennent au fonctionnement du service.

Évitez d'inscrire dans l'URL un nom, une adresse électronique ou le détail confidentiel du rendez-vous. Le lien peut être copié, transféré ou enregistré par des intermédiaires. Une référence technique validée côté serveur est généralement plus appropriée qu'une adresse qui raconte toute la réservation.

Ce que les liens Apple et Android prennent en charge

Les Universal Links d'Apple et les App Links d'Android permettent d'associer des adresses web à une application. La documentation Apple présente cette relation, tandis que le guide Android explique comment vérifier l'association du domaine.

Cette association aide à transmettre le lien à l'application. Elle ne remplace ni la recherche du contenu ni le contrôle des droits. Votre équipe doit donc traiter séparément la réception du lien, la reconnaissance du rendez-vous et l'autorisation de le consulter.

Pour des invitations largement partagées, une adresse HTTPS sur un domaine que vous contrôlez offre aussi la possibilité d'un vrai parcours web. Une adresse spéciale du type exampleapp://booking/123 n'offre pas, à elle seule, une page exploitable quand l'application n'est pas installée.

Il ne faut pas davantage confondre lien profond et reprise après installation. Le premier peut fonctionner pour une application déjà présente. Le second doit retrouver le contexte après le téléchargement depuis une boutique d'applications et la première ouverture. Prévoyez explicitement ce parcours dans le projet.

Ne pas abandonner la destination pendant la connexion

Lorsqu'une session a expiré, la demande de connexion est normale. Ce qui l'est moins, c'est de renvoyer ensuite la personne vers l'accueil sans explication. L'application devrait conserver la destination demandée, puis vérifier à nouveau l'accès avant de l'afficher.

Cette conservation doit être encadrée. On n'enregistre pas une URL arbitraire pour l'ouvrir sans contrôle plus tard. L'application doit reconnaître les destinations autorisées, vérifier les paramètres et refuser ce qui ne correspond pas à ses règles. Le serveur reste responsable de l'accès aux données privées.

Reprenons le téléphone connecté au mauvais compte. Une bonne réponse indique que ce compte ne permet pas de consulter la réservation, sans dévoiler son contenu. Elle propose un changement de compte et garde la référence nécessaire pour reprendre ensuite. Un message générique « erreur » ne donne aucune chance de résoudre le problème.

Le même soin s'applique à l'inscription. Une succession d'écrans de bienvenue ne doit pas effacer l'invitation initiale. Intégrez ce cas dans le parcours des nouveaux utilisateurs et testez-le jusqu'au bout, y compris si l'application est fermée entre deux étapes.

La connexion ou l'installation peut interrompre le parcours. Il faut prévoir comment retrouver la même destination, plutôt que remplacer celle-ci par l'accueil.

Préparer un parcours pour les personnes sans application

Avant de choisir un prestataire, demandez quelle part du parcours exige réellement l'application. Si la personne peut lire les informations de l'atelier sur le web, montrez-les. Une page qui ne dit que « téléchargez notre application » laisse planer un doute : suis-je encore au bon endroit ?

Si l'installation est nécessaire, décrivez ce qui doit se passer à la première ouverture. La reprise de la destination initiale, appelée deferred deep linking, nécessite une transmission ou une récupération de contexte. L'article pratique d'Airbridge explique ce principe du point de vue d'un fournisseur.

Cette explication ne signifie pas que tous les services ont besoin du même outil. Une application destinée à des membres déjà équipés peut commencer avec des liens vérifiés et une page web claire. Un service dont les invitations recrutent constamment de nouveaux utilisateurs aura d'autres exigences.

Demandez une démonstration sur les appareils et les boutiques d'applications que vous comptez prendre en charge, avec les choix de consentement prévus. Ne vous contentez pas d'un parcours préparé sur un seul téléphone. Les mécanismes disponibles et leurs limites doivent être compris avant de promettre une continuité automatique.

Prévoyez aussi une récupération simple : revenir au message après installation, ou saisir un code si le produit le permet. C'est un détour, certes, mais un détour explicite vaut mieux qu'une destination perdue. N'utilisez pas la collecte discrète de données comme réponse par défaut aux limites de reconnaissance.

Les fonctions proposées pour certaines campagnes sur l'App Store constituent une autre partie du parcours. Notre guide sur les pages produit personnalisées explique leurs possibilités. Une fonction propre à une boutique ou à une version du système n'est pas une garantie pour toutes les invitations ordinaires.

Un rendez-vous change ; le lien doit rester compréhensible

L'atelier peut être complet, annulé ou déplacé. La personne peut aussi avoir annulé sa réservation. Il faut donc définir la réponse à partir de l'état actuel du service, et non conserver éternellement la promesse faite lors de l'envoi.

Cela ne justifie pas une redirection silencieuse vers une autre séance. Expliquez la situation et proposez une action adaptée : voir les nouvelles dates, retrouver ses réservations ou contacter l'organisateur lorsque c'est pertinent. Ne présentez pas une alternative comme si elle était la destination d'origine.

Utilisez une référence stable pour identifier le rendez-vous. Son titre peut changer sans rendre tous les messages invalides. Précisez également si le lien désigne un événement ponctuel ou une série ; cette distinction évite des inscriptions au mauvais créneau.

Pensez au retour arrière. Après avoir ouvert directement une réservation, la personne doit pouvoir rejoindre une liste ou un espace cohérent. Le contenu correct dans un écran sans issue reste une mauvaise expérience.

Enfin, une absence de réseau n'est pas une interdiction d'accès. Affichez le bon motif et permettez, lorsque c'est possible, de réessayer la demande initiale. Les messages d'erreur participent autant à la fiabilité du parcours que la configuration des liens.

Vérifier les messages qui partiront vraiment

Un lien collé dans un outil de test n'est pas toujours celui que la personne touchera. La mesure des clics dans une campagne peut ajouter une redirection. Les navigateurs intégrés aux messageries et les préférences du téléphone peuvent aussi modifier l'ouverture.

Le contexte du navigateur compte : Apple documente notamment des cas où une navigation Safari sur le même domaine reste sur le web. Il faut donc une destination web convenable, et non l'idée que tout passage par le navigateur constitue forcément un défaut.

Voici une grille de recette proposée pour le service de réservation. Elle complète le plan de tests avant publication, sans prétendre couvrir tous les appareils possibles.

Le guide de test d'Adjust distingue les parcours d'utilisateurs existants et les nouvelles installations. Cette séparation aide à localiser une panne. Si l'application installée ne reconnaît déjà pas la destination, commencez par ce problème avant d'examiner la transmission après installation.

Notez pour chaque essai la version de l'application, l'appareil, le message utilisé et le résultat. Incluez un démarrage à froid et une application déjà ouverte ailleurs. Ce relevé transforme une impression vague en problème que l'équipe peut reproduire.

Garder la maîtrise après le lancement

Un domaine imprimé sur une invitation ou un billet peut survivre au prestataire qui l'a créé. Attribuez la responsabilité des adresses et des redirections, puis vérifiez les supports encore utilisés lors d'un changement de fournisseur.

Firebase Dynamic Links a cessé de fonctionner le 25 août 2025. Les anciennes campagnes méritent donc un contrôle réel, notamment celles utilisant des adresses page.link. Il ne s'agit pas de la fermeture de tous les produits Firebase. Et modifier votre propre domaine ne remet pas en service une adresse appartenant à un tiers.

La mesure doit suivre le résultat pour la personne. Distinguez la réception du lien, la résolution de la destination, son affichage et l'action finale. Ce sont des étapes possibles pour votre plan de mesure de l'application, pas des noms d'événements imposés par une plateforme.

N'enregistrez pas les détails privés de la réservation dans les paramètres d'analyse. Et si le lien participe à un programme de parrainage, gardez les règles de récompense séparées. Ouvrir un écran ne prouve pas que les conditions du programme sont remplies.

Pour préparer cette fonctionnalité avec Appfyl, apportez les messages et destinations prévus. Quelques parcours bien définis suffisent pour démarrer. Le résultat recherché n'a rien de spectaculaire : une personne suit une invitation, comprend où elle arrive et peut continuer.

Questions fréquentes