QR code vers une application : deep link ou Universal Link ?

Un code sur un abribus, un scan, et trois issues possibles : l'application s'ouvre exactement sur le bon écran, le navigateur affiche la bonne page, ou un message indique que l'adresse n'est pas valide, et l'affiche vient de gâcher sa seule chance avec vous.

Laquelle des trois vous obtenez n'a presque rien à voir avec le QR code et presque tout à voir avec l'URL imprimée à l'intérieur.

Le code ne transporte qu'une URL

Commençons par le point qui règle la moitié des malentendus : un QR code encode du texte, rien d'autre. Quand ce texte commence par un schéma reconnu, l'application de scan le considère comme un lien et le transmet au système. Il n'existe aucun champ « ouvre mon application », aucun indicateur « préfère le natif », aucune place pour une solution de repli. Tout le reste se joue sur le choix de la destination, décidé avant de créer le code, et modifiable ensuite seulement si ce code pointe vers une redirection que vous contrôlez.

Ce dernier point est l'argument pratique pour mettre un code dynamique sur tout ce qui est imprimé. Les détails d'association d'application changent. Les domaines déménagent. Un code statique fige l'URL dans l'encre, et si la passation vers l'application était mal configurée, le seul remède est la réimpression.

Les schémas personnalisés échouent discrètement

La plus ancienne façon d'atteindre une application est un schéma privé : une adresse commençant par quelque chose comme monappli, suivie des deux-points et des barres obliques habituels. L'application déclare le schéma, le système route les URL correspondantes vers elle, et l'application analyse le reste.

Cela fonctionne quand l'application est installée. Quand elle ne l'est pas, l'échec est mauvais d'une manière particulière. Il n'y a aucun site web à cette adresse, parce que ce n'est pas du tout une adresse web. Selon le navigateur et la version du système, vous obtenez une page d'erreur, rien du tout, ou une boîte de dialogue proposant de lancer une recherche à la place. Le comportement varie entre plateformes et même entre versions d'une même plateforme, ce qui devrait tenir les schémas personnalisés éloignés des supports imprimés.

Deux faiblesses de plus. Les noms de schéma ne sont enregistrés nulle part et ne sont pas vérifiés, donc n'importe quelle application peut revendiquer n'importe quel schéma, et ce qui se passe quand deux applications revendiquent le même n'est défini par aucune des deux plateformes. Et comme un schéma ne porte pas de domaine, aucune plateforme ne peut le rattacher à un site dont vous avez prouvé le contrôle.

Les schémas personnalisés gardent une place légitime : navigation interne, passation entre deux applications qui vous appartiennent, cible de redirection atteinte depuis votre propre page après avoir confirmé la présence de l'application. Pas la porte d'entrée.

Universal Links et App Links sont des URL https ordinaires

Les deux plateformes ont résolu le même problème de la même façon. Plutôt que d'inventer un nouvel espace d'adressage, elles laissent une application revendiquer un ensemble d'URL https ordinaires appartenant à un domaine dont le développeur peut prouver le contrôle.

Apple appelle sa version Universal Links. Google appelle la sienne Android App Links. Dans les deux cas, l'adresse dans votre QR code est une adresse web normale, du genre que vous pourriez taper dans n'importe quel navigateur. Quand l'application est installée et la revendication vérifiée, le système ouvre l'application au lieu du navigateur. Quand l'application manque, rien de spécial ne se produit et la page se charge comme une page web. Cette dégradation en douceur est toute la raison pour laquelle cette forme est la bonne derrière un code imprimé.

Les fichiers d'association

La vérification passe par un fichier sur votre serveur web.

• iOS cherche un fichier JSON nommé apple-app-site-association, servi en https depuis le répertoire well-known à la racine de votre domaine, listant les identifiants d'application et les chemins d'URL que chacun revendique. Côté application, il faut la capacité de domaines associés nommant le même domaine. Apple récupère le fichier via sa propre infrastructure, les changements ne prennent donc pas toujours effet immédiatement.
• Android cherche assetlinks.json dans le même répertoire well-known. Il liste le nom de paquet de l'application et l'empreinte SHA-256 du certificat avec lequel l'application a été signée, ce qui rattache la revendication à une compilation précise plutôt qu'à n'importe quoi qui prétend simplement être ce paquet. Le manifeste de l'application déclare un filtre d'intention pour le domaine avec la vérification automatique activée.

Façons courantes dont cela casse : le fichier servi via une redirection, une règle de CDN qui change son type de contenu, une empreinte de certificat périmée après un passage à la signature d'application gérée par la plateforme, ou un motif de chemin qui ne couvre pas l'URL vers laquelle votre code pointe réellement. Toutes échouent de la même façon vue de l'extérieur, le lien s'ouvrant dans un navigateur sans qu'aucune erreur ne soit visible.

L'écart d'empreinte mérite une attention particulière parce qu'il est silencieux et propre à la compilation. L'empreinte doit correspondre au certificat de la compilation que l'utilisateur a installée, pas à celle sur votre portable.

Le scanner au milieu

Il y a une étape entre l'appareil photo et le système d'exploitation, et elle n'est pas homogène.

Une application appareil photo de la plateforme qui remet l'URL au système donne au mécanisme d'association sa meilleure chance de se déclencher. Un scanner intégré à une application sociale ou de messagerie ouvre souvent le lien dans son propre navigateur embarqué, et les navigateurs embarqués ne passent pas la main de façon fiable à une application native. Que votre Universal Link ouvre l'application dépend donc en partie du scanner que la personne a utilisé. Certaines plateformes retiennent aussi le choix antérieur de rester dans le navigateur pour un domaine donné et le respectent lors des visites suivantes.

Concevez comme si la passation pouvait ne pas se déclencher, car parfois elle ne se déclenchera pas. Si la page web à cette URL affiche le même contenu que l'écran de l'application aurait montré, une passation manquée est une déception légère plutôt qu'une impasse.

Et en France ?

Pour un usage ponctuel, comme consulter une carte, payer un stationnement ou suivre un colis, beaucoup de visiteurs préfèrent ne pas installer d'application. Un QR code qui mène directement vers une boutique d'applications perd donc une partie de son public avant même le premier écran.

La solution robuste reste la même : un lien universel qui ouvre l'application si elle est installée, et sinon une page web en français qui rend le même service. Si vous proposez l'application sur cette page, utilisez les badges officiels en français, « Télécharger dans l'App Store » et « Disponible sur Google Play », que les deux plateformes fournissent pour cet usage.

La chaîne de repli qui vaut la peine d'être construite

Voici les trois destinations possibles, dans l'ordre à privilégier :

1. L'application, sur le bon écran. Gérée par le système via l'URL https, sans aucun JavaScript.
2. La page web, avec le même contenu. La même URL, rendue pour un navigateur. C'est la couche qui rattrape toute personne sans l'application et tout scanner qui a avalé la passation.
3. Le magasin d'applications, proposé et non imposé. Mettez un lien d'installation clair sur la page. Rediriger droit vers une fiche de magasin est l'erreur, car cela abandonne tous ceux qui voulaient le contenu et pas un téléchargement.

Laissez tomber la vieille astuce du minuteur qui déclenche un schéma personnalisé en JavaScript et redirige vers un magasin si rien ne se passe en une seconde ou deux. Elle se bat contre les règles de fenêtres surgissantes, rate son coup sur les appareils lents, et se comporte différemment selon les versions du système. Chrome sur Android prend bien en charge une forme d'URL d'intention avec repli navigateur déclaré, ce qui est réellement utile, mais c'est propre à ce navigateur et non quelque chose sur quoi compter partout.

Testez le bon à tirer imprimé sur un appareil sans l'application, puis sur le même appareil avec l'application installée, puis via au moins un scanner tiers. Si le premier test atterrit sur une page fonctionnelle plutôt que sur une erreur, l'essentiel de la valeur est déjà acquis. Quand un code aboutit franchement au mauvais endroit, déroulez la liste de vérification des échecs de scan avant d'accuser le fichier d'association, et gardez en tête que le symbole lui-même ne fait rien de plus que remettre une chaîne de caractères.