Validateur de deep links : schemes, App Links et Universal Links au format

Un deep link mal formé, c’est une campagne qui paie des clics pour ouvrir la mauvaise page, ou pire, une erreur. Ce validateur contrôle le format de vos URL schemes personnalisés, Universal Links iOS et App Links Android : chaque règle est vérifiée une par une et expliquée, sans aucun appel réseau. Vous repartez avec un lien propre et la checklist exacte des fichiers d’association à contrôler sur votre serveur.

Mode d’emploi : un diagnostic de format en trois gestes

L’outil ne demande qu’une seule information, le reste est déduit :

1. Collez votre lien dans le champ « Lien à valider ». L’outil détecte seul de quoi il s’agit : une adresse en monapp:// est traitée comme un URL scheme personnalisé, une adresse en https comme un lien destiné aux Universal Links iOS et aux App Links Android. Vous n’avez rien à choisir, et le même champ accepte les deux familles.
2. Cliquez sur « Valider le lien ». L’analyse est immédiate. Le « Type détecté » s’affiche en tête de résultat : c’est la première chose à vérifier, car un lien https collé alors que vous pensiez tester un scheme (ou l’inverse) est déjà un signal d’erreur dans votre documentation interne.
3. Lisez les contrôles ligne par ligne. Chaque règle de format donne son verdict : réussi, attention ou échec, toujours accompagné de l’explication du contrôle. Vous ne recevez pas une note globale opaque, mais la liste de ce qui a été vérifié et la raison exacte de chaque alerte, dans l’ordre où un développeur corrigerait.
4. Terminez par la « Checklist des fichiers d’association ». Pour un lien https, l’outil affiche l’emplacement exact attendu des deux fichiers : apple-app-site-association côté iOS, assetlinks.json côté Android. C’est la partie que l’outil ne peut pas vérifier à votre place, puisqu’il ne fait aucun appel réseau : la checklist vous dit précisément quoi ouvrir et quoi constater.

Le bon réflexe : validez le lien ici avant de l’envoyer en campagne, puis parcourez la checklist sur votre serveur au moindre doute. La quasi-totalité des deep links qui échouent en production tombent sur l’un des deux tableaux : un format bancal, ou un fichier d’association mal servi.

À quoi sert un deep link, et pourquoi il casse si souvent

Un deep link est une adresse qui ouvre votre application directement sur le bon écran : une fiche produit, un panier abandonné, une conversation, un parcours de parrainage. Sans lui, chaque sollicitation externe (e-mail, notification, publicité, QR code sur un packaging) ramène l’utilisateur à l’écran d’accueil, à charge pour lui de retrouver sa route. Les usages concrets ne manquent pas :

• Les campagnes d’acquisition : le clic sur l’annonce ouvre l’écran promis, pas la page d’accueil. Associez-y des paramètres de suivi construits avec le générateur d’UTM pour campagnes d’application pour mesurer ce que chaque canal rapporte.
• Les e-mails et SMS transactionnels : « votre commande est expédiée » doit ouvrir le suivi de la commande, en une seconde, sans authentification superflue.
• Les QR codes imprimés : l’affiche ou le packaging mène à l’écran visé. Le générateur de QR code de téléchargement couvre le cas voisin où la cible est la fiche du store.
• La reprise de parcours : un panier, un dossier entamé ou une invitation reprennent exactement où l’utilisateur s’était arrêté.

Si ces liens cassent si souvent, c’est qu’ils dépendent de trois systèmes à la fois : le format du lien lui-même, la configuration de l’application (entitlements iOS, filtres d’intention Android) et un fichier publié sur votre site web. Une seule pièce défaillante, et le lien ouvre le navigateur au lieu de l’application, sans message d’erreur pour vous prévenir. D’où l’intérêt de verrouiller au moins la première pièce, le format, avant toute diffusion.

Les trois familles de liens profonds

Sous le terme générique de deep link cohabitent trois mécanismes distincts, aux garanties très différentes :

Le scheme personnalisé est l’ancêtre : monapp:// ouvre l’application si elle est installée, et ne fait rien de prévisible sinon. Il reste utile pour des usages internes (liens entre vos propres apps, retours de paiement, outils de développement), mais il souffre de deux faiblesses structurelles : aucun repli web possible, et aucune réservation du nom. Si deux applications déclarent le même scheme, le système ne garantit pas laquelle s’ouvre.

Les Universal Links et App Links corrigent ces deux défauts avec la même idée : le lien profond est une adresse https ordinaire de votre site. Application installée, elle s’ouvre au bon écran ; application absente, la page web se charge et le parcours continue. La contrepartie est une preuve de propriété : un fichier publié sur votre domaine doit déclarer l’application autorisée à intercepter ces adresses. C’est ce couple lien plus fichier que l’outil vous aide à préparer.

Ce que l’outil contrôle sur un URL scheme personnalisé

Pour une adresse détectée comme scheme personnalisé, chaque règle vérifiée correspond à un incident classique de production :

• La syntaxe scheme:// : le séparateur doit être complet. Un monapp:/ecran à un seul trait oblique passe inaperçu à l’œil et échoue à l’exécution.
• Les caractères du scheme : une lettre d’abord, puis uniquement des lettres, des chiffres, le plus, le tiret et le point. Ni accent, ni espace, ni tiret bas : mon_app:// est invalide, mon-app:// est correct.
• Les schemes réservés : http, https, mailto, tel et file appartiennent au système. Les détourner pour votre application ne fonctionne pas et crée des comportements imprévisibles ; l’outil les signale en échec franc.
• Un contenu après le séparateur : un scheme nu du type monapp:// ouvre l’application sans lui dire où aller. L’outil recommande un hôte ou un chemin (monapp://profil/42) pour que le lien mérite son nom de lien profond.
• La spécificité du nom : un scheme trop générique (app://, mobile://, test://) a toutes les chances d’entrer en collision avec une autre application. L’alerte vous invite à préfixer avec votre marque, la convention la plus sûre restant le nom inversé de domaine (fr.votremarque.app://).

Un scheme qui passe ces contrôles est correct au format. Il reste soumis aux limites de sa famille : pensez au repli, la section suivante et l’outil de lien intelligent de téléchargement couvrent précisément ce besoin.

Ce que l’outil contrôle sur un lien https

Pour une adresse https destinée aux Universal Links et App Links, les contrôles suivent les exigences publiées par Apple et Google :

• Le protocole https, sans exception : un lien en http est refusé. Les deux systèmes d’association n’acceptent que https, côté lien comme côté fichier.
• Un domaine nommé, pas une adresse IP : l’association repose sur un nom de domaine capable de servir un certificat valide. Une IP ou un hôte local ne peut pas porter d’Universal Link.
• Un port implicite : le mécanisme d’association fonctionne sur le port standard (443). Un port explicite non standard dans le lien déclenche une alerte, car la vérification du domaine ne suivra pas.
• Pas de fragment : tout ce qui suit un dièse (#section) est ignoré par les App Links et ne participe pas à la correspondance des chemins. Si votre écran cible dépend du fragment, il ne sera jamais transmis de façon fiable : déplacez l’information dans le chemin ou la query string, qui sont eux transmis à l’application.
• Un chemin significatif : le chemin du lien devra correspondre aux chemins déclarés (paths et components côté Apple, filtres d’intention côté Android). Un lien réduit à la racine du domaine est signalé en attention : il intercepterait tout votre site, ce qui est rarement voulu.

Un lien https validé ici est prêt côté format. Restent les deux fichiers d’association, que l’outil ne peut pas aller lire à votre place : c’est l’objet de la checklist et de la section suivante.

Les fichiers d’association, côté Apple et côté Google

La preuve de propriété du domaine tient en deux fichiers JSON, à des emplacements imposés au caractère près :

• Côté iOS : https://votre-domaine.fr/.well-known/apple-app-site-association. Le nom s’écrit sans extension, et le serveur doit le livrer en application/json, directement, sans aucune redirection. Le fichier déclare votre appID (l’identifiant d’équipe suivi du bundle identifier, par exemple ABCDE12345.fr.votremarque.app) et la liste des chemins interceptés. L’application, elle, doit porter l’entitlement Associated Domains avec l’entrée applinks:votre-domaine.fr. Le système récupère ce fichier à l’installation et lors des mises à jour : une correction n’est donc pas prise en compte à la seconde.
• Côté Android : https://votre-domaine.fr/.well-known/assetlinks.json. Le fichier relie le domaine à votre application par son package_name et l’empreinte SHA-256 du certificat de signature (celle de la signature Play si vous l’avez déléguée à la console). Dans le manifeste, le filtre d’intention du lien doit porter android:autoVerify= »true » : c’est lui qui déclenche la vérification à l’installation et permet l’ouverture directe, sans boîte de dialogue de choix.

Deux pièges de publication reviennent sans cesse. D’abord la redirection : beaucoup de serveurs renvoient l’apex vers www ou l’inverse, et le fichier d’association suit la redirection ; Apple exige une livraison directe, prévoyez donc le fichier sur chaque hôte réellement visé par vos liens, sous-domaines compris. Ensuite le Content-Type : un serveur qui sert le fichier sans extension en text/html le rend invisible pour les systèmes de vérification. La checklist de l’outil reprend ces points un par un, il ne vous reste qu’à ouvrir les deux adresses et constater.

Les erreurs qui font échouer un deep link en production

Au-delà du format, voici les causes d’échec que l’on retrouve le plus souvent en audit, toutes évitables :

1. Le fichier d’association servi derrière une redirection. Le lien est bon, l’application est bonne, mais le fichier répond en 301 : la vérification échoue en silence et tous les liens ouvrent le navigateur.
2. Le mauvais Content-Type. apple-app-site-association sans extension est souvent servi en texte brut ou en HTML par défaut : configurez explicitement application/json sur ce chemin.
3. Un chemin absent des déclarations. Le marketing crée une nouvelle page de campagne, personne ne met à jour les chemins déclarés : le lien de la campagne n’est pas intercepté. Traitez la liste des chemins comme un livrable du projet, au même titre que le cahier des charges de l’application.
4. Des tests trompeurs. Un Universal Link saisi à la main dans la barre d’adresse de Safari n’ouvre pas l’application : le mécanisme se déclenche depuis un toucher dans une autre app (Mail, Messages, Notes). Testez sur appareil réel, depuis un vrai contexte d’envoi, jamais uniquement sur simulateur.
5. Un scheme personnalisé en campagne publicitaire. La plupart des régies exigent une URL de clic en https et refusent monapp:// : le scheme reste un outil interne, la campagne passe par un lien https ou une page de redirection.
6. L’oubli du repli. Tout lien diffusé publiquement sera un jour ouvert sans l’application installée : décidez à l’avance de la page web qui prend le relais, et vérifiez qu’elle mène au téléchargement.

Questions fréquentes

L’outil vérifie-t-il que mes fichiers d’association sont en ligne ?

Non, et c’est volontaire : l’outil ne fait aucun appel réseau, votre lien n’est envoyé nulle part et rien n’est téléchargé. Il vérifie le format du lien puis vous remet la checklist des fichiers d’association avec leurs emplacements exacts : ouvrir les deux adresses dans votre navigateur et contrôler le Content-Type prend moins de deux minutes.

Quelle est la différence entre un deep link et un lien intelligent de téléchargement ?

Le deep link ouvre un écran précis de l’application déjà installée ; le lien intelligent route un visiteur vers le bon store pour installer l’application. Les deux se complètent : la campagne diffuse un lien intelligent, et une fois l’application installée, les communications suivantes utilisent des deep links pour ouvrir directement les bons écrans.

Pourquoi mon lien https ouvre-t-il le navigateur au lieu de l’application ?

Les causes les plus fréquentes, dans l’ordre : le fichier d’association absent, servi derrière une redirection ou avec un mauvais Content-Type ; le chemin du lien absent des chemins déclarés ; l’entitlement Associated Domains ou l’attribut android:autoVerify manquant ; enfin un test mené depuis la barre d’adresse, qui ne déclenche pas les Universal Links. Reprenez la checklist point par point avant d’incriminer le code.

Puis-je utiliser la même adresse pour iOS et Android ?

Oui, et c’est même la pratique recommandée : une seule adresse https de votre domaine, déclarée des deux côtés, dans apple-app-site-association pour iOS et assetlinks.json pour Android. Un seul lien à diffuser, un repli web commun, et deux fichiers à maintenir en parallèle.

Que se passe-t-il si l’application n’est pas installée ?

Avec un Universal Link ou un App Link, la page web correspondante s’ouvre : soignez-la pour qu’elle propose le téléchargement et, idéalement, reprenne le contenu visé. Avec un scheme personnalisé, rien d’utilisable ne se produit : c’est la raison principale de ne jamais diffuser un scheme seul auprès du grand public.

Un scheme personnalisé suffit-il pour mes campagnes ?

Non. Les régies publicitaires attendent une URL de destination en https, et un scheme n’offre aucun repli pour les visiteurs sans l’application. Réservez le scheme aux échanges internes entre applications et aux liens techniques ; pour la diffusion, utilisez une adresse https associée ou une page de redirection dédiée.

Où placer exactement les fichiers d’association ?

Dans le répertoire /.well-known/ à la racine de chaque domaine ou sous-domaine visé par vos liens : apple-app-site-association (sans extension, servi en application/json, sans redirection) et assetlinks.json. Un lien vers app.votre-domaine.fr exige les fichiers sur app.votre-domaine.fr : ceux du domaine principal ne couvrent pas les sous-domaines.

Comment tester un Universal Link de façon fiable ?

Sur un appareil réel, application installée depuis une build récente, en touchant le lien depuis une autre application : collez-le dans Notes ou envoyez-le vous par message, puis touchez-le. Testez aussi le parcours inverse, application désinstallée, pour valider le repli web. Le simulateur et la saisie directe dans Safari produisent des faux négatifs.