Comment résoudre les alertes d'adresse invalide sous Safari lors des replis par schéma d'URL

Pourquoi Safari indique-t-il que l'adresse est invalide pour un schéma d'URL ? Safari peut afficher une erreur d'adresse invalide ou de page inaccessible lorsqu'une page web tente de naviguer vers un schéma d'URL personnalisé que le système ne parvient pas à associer à un gestionnaire disponible. La résolution de ce problème nécessite une migration vers les Universal Links vérifiés ou la mise en œuvre de replis déclenchés par l'utilisateur, redirigeant les utilisateurs n'ayant pas l'application vers les boutiques d'applications.

L'alerte « Safari ne peut pas ouvrir la page car l'adresse est invalide » survient lorsque Safari mobile tente d'accéder à un schéma d'URL personnalisé sur un appareil dépourvu de l'application native cible ou d'un gestionnaire éligible. Pour remédier à cela, il est nécessaire de passer des anciens schémas URI aux Universal Links vérifiés ou de déployer des architectures de repli conformes aux gestes de l'utilisateur, permettant de rediriger les visiteurs vers les App Stores sans provoquer d'erreurs de protocole.

Pourquoi Safari affiche l'erreur d'adresse invalide sur les schémas personnalisés

La cause racine : Comment WebKit répond aux protocoles URI non enregistrés

Lorsqu'un utilisateur interagit avec un lien sur une page web mobile, le moteur de rendu du navigateur évalue le schéma URI pour déterminer le protocole de transport ou le gestionnaire d'application approprié. Dans Apple Safari, propulsé par le moteur WebKit, les protocoles web standard tels que http:// et https:// sont gérés en interne par le chargeur de ressources réseau.

Lorsqu'une page web demande à Safari de naviguer vers un schéma URI personnalisé (tel que myapp://product/detail/1024), le système d'exploitation tente de localiser une application installée ayant enregistré ce schéma spécifique dans sa configuration de bundle CFBundleURLTypes. Si l'application cible est présente, iOS peut lancer l'application native. Cependant, si l'application n'est pas installée sur l'appareil, le schéma ne peut être résolu via les couches DNS ou de transport web standard. Comme Safari ne possède pas de gestionnaire web interne pour les schémas personnalisés, tenter de naviguer vers un protocole personnalisé non géré peut faire apparaître une boîte de dialogue indiquant que Safari ne peut pas ouvrir la page car l'adresse est invalide.

La barrière du bac à sable (Sandbox) : Pourquoi le JavaScript ne peut pas interroger l'état d'installation d'une application native

Les développeurs front-end tentent fréquemment de contourner cette alerte en écrivant du JavaScript côté client qui vérifie si une application est installée avant de déclencher le schéma. Selon l'architecture de sécurité et de confidentialité d'Apple, cette vérification est structurellement inaccessible au contenu web.

Safari mobile impose une isolation stricte entre le contenu web et le système d'exploitation hôte. Le JavaScript des pages web n'est pas autorisé à interroger les registres du système de fichiers local, à inspecter les packages d'applications installées ou à vérifier si un schéma URI externe possède un gestionnaire actif. Comme le navigateur ne peut pas sonder l'état d'installation à l'avance, l'exécution d'un schéma personnalisé non géré sur un appareil dépourvu de l'application correspondante risque de déclencher l'alerte d'échec de WebKit.

Impact sur l'expérience utilisateur : Comment les alertes système natives augmentent les taux de rebond

Rencontrer une alerte système indiquant que « l'adresse est invalide » nuit à la confiance des utilisateurs et perturbe les tunnels de conversion :

• Anxiété liée à la sécurité : Les utilisateurs peuvent interpréter les alertes d'adresse invalide comme des signes de site web cassé, de logiciel non fiable ou d'avertissements de sécurité.
• Interruption du tunnel : L'alerte oblige l'utilisateur à accuser réception et à fermer une boîte de dialogue bloquante avant de pouvoir interagir à nouveau avec la page, ce qui augmente le taux de départ immédiat.
• Transition fragmentée vers la boutique : Si une alerte non gérée apparaît simultanément avec des scripts de redirection vers la boutique, la transition vers l'App Store semble incohérente.

Pourquoi les solutions de contournement historiques échouent dans les versions modernes de WebKit

Les limites du sondage par iframe cachée dans le Safari moderne

Dans les versions antérieures d'iOS, les développeurs déployaient souvent un sondage par iframe cachée. Un script injectait un élément <iframe> invisible dans le DOM et définissait sa source sur le schéma personnalisé (myapp://), tout en exécutant un minuteur JavaScript simultané. L'intention était que l'application installée se lance sans naviguer dans la fenêtre principale, tandis qu'une application non installée échouerait silencieusement dans le cadre.

Dans les navigateurs mobiles contemporains, cette approche n'est pas fiable :

• Le WebKit moderne applique des restrictions de navigation et de bac à sable qui peuvent limiter les transitions de protocole externe depuis des iframes, surtout celles qui sont restreintes.
• Tenter de charger des schémas non enregistrés dans des iframes peut toujours déclencher des boîtes de dialogue d'erreur au niveau du navigateur ou échouer silencieusement sans fournir de repli propre.
• Parce que le sondage par iframe est incohérent à travers les versions d'iOS et les contextes de sécurité, il ne doit pas être considéré comme un mécanisme fiable pour évaluer la présence d'une application.

Cascades window.location basées sur des minuteurs : Pourquoi les navigateurs modernes restreignent les redirections automatisées

Une autre technique héritée consistait à exécuter une cascade basée sur un minuteur utilisant window.location.href :

// Anti-modèle hérité : fragile et restreint dans les navigateurs modernes
window.location.href = "myapp://product/detail";
setTimeout(function() {
    window.location.href = "https://apps.apple.com/app/id123456789";
}, 2000);

Cette approche crée de multiples problèmes d'expérience utilisateur et des modes d'échec techniques :

1. Alertes simultanées : Si l'application n'est pas installée, Safari peut afficher l'alerte « adresse invalide » lors de l'évaluation du schéma personnalisé, forçant l'utilisateur à rejeter l'alerte pendant que le minuteur en arrière-plan initie une redirection secondaire.
2. Redirection non désirée : Si l'application est installée et s'ouvre avec succès, le navigateur peut toujours exécuter le minuteur en attente lors de la reprise, redirigeant inutilement l'utilisateur vers l'App Store lorsqu'il revient dans Safari.

Activation de l'utilisateur et politiques de navigation des navigateurs

Les navigateurs mobiles modernes appliquent des politiques d'activation par l'utilisateur qui restreignent les navigations non sollicitées. WebKit limite les redirections de fenêtres automatisées et les transitions de protocoles provenant de minuteurs en arrière-plan, de rappels asynchrones ou de scripts chargés sans interaction récente de l'utilisateur.

Les transitions programmatiques s'exécutant sans interaction directe sont moins prévisibles et peuvent être supprimées selon le contexte du navigateur. Pour un routage fiable, les transitions vers une application native doivent provenir directement d'un geste explicite de l'utilisateur, tel qu'un appui physique sur un élément interactif.

Pourquoi les Universal Links ont été conçus par Apple comme la solution privilégiée

Pour éliminer les modes d'échec des schémas d'URL propriétaires, Apple a introduit les Universal Links dans iOS 9. Les Universal Links remplacent les schémas personnalisés (myapp://) par des URL web HTTPS standard et vérifiées (https://app.example.com/product/1024).

En ancrant le deep linking dans une infrastructure HTTPS standard, Apple a supprimé le mode d'échec lié aux protocoles non enregistrés. Si l'application est installée, associée et éligible dans le contexte de navigation actuel, iOS achemine le lien directement vers les gestionnaires natifs ; si l'application n'est pas installée, Safari continue la navigation vers l'URL HTTPS comme une ressource web normale, chargeant une page web ou un repli vers la boutique sans alerte de protocole.

Comment les Universal Links éliminent l'alerte d'adresse invalide

La fondation HTTPS : Suppression du mode d'échec lié au protocole non enregistré

La différence principale entre un schéma d'URL personnalisé et un Universal Link réside dans la manière dont la pile réseau du navigateur évalue l'URL demandée :

• Schéma personnalisé (myapp://) : Un protocole non standard. WebKit ne peut pas le résoudre via DNS ou transport web standard. Si aucune application enregistrée ne gère le schéma, la requête peut faire apparaître une erreur d'adresse invalide.
• Universal Link (https://app.example.com) : Une URL HTTPS standard et pleinement qualifiée. WebKit résout et charge les adresses HTTPS nativement.

Parce qu'un Universal Link est fondamentalement une URL web valide, Safari ne rencontre jamais de protocole non enregistré. Si la transition vers l'application native ne se produit pas, Safari charge simplement le contenu web hébergé à cette adresse.

L'association bidirectionnelle : Coordination des droits natifs avec le fichier AASA hébergé

Les Universal Links établissent un routage vérifié grâce à une association entre le binaire de l'application mobile et le domaine du site web :

1. Autorisation de l'application : L'application iOS déclare une autorisation Associated Domains contenant la chaîne du domaine cible : applinks:app.example.com.
2. Déclaration du serveur : Le domaine du site web héberge un fichier JSON à l'adresse https://app.example.com/.well-known/apple-app-site-association (AASA). Ce fichier spécifie les identifiants d'application autorisés et les composants de correspondance de chemin.
3. Résolution au niveau de l'OS : Lorsque l'utilisateur installe l'application, iOS valide l'association de domaine. Lorsqu'un lien associé est touché, le système d'exploitation évalue si une application éligible peut gérer la destination.

Dégradation web fluide : Ce qui se passe lorsqu'une application n'est pas installée

Lorsqu'un utilisateur n'ayant pas l'application touche un Universal Link :

1. Le système d'exploitation iOS évalue l'URL par rapport à son registre d'associations vérifiées.
2. Ne trouvant aucune application installée correspondant au domaine, iOS délègue le lien à Safari comme une navigation web standard.
3. Safari charge la page web hébergée à cette URL sans afficher d'alertes d'erreur système.
4. La page web hébergée peut afficher le contenu pertinent, présenter un CTA vers l'App Store ou coordonner la récupération de paramètres différés.

Gérer la mise en garde de navigation sur le même domaine dans Safari avec des sous-domaines dédiés

Lors du déploiement d'Universal Links sur des pages web, les équipes doivent prendre en compte le comportement de navigation sur le même domaine de Safari, tel que documenté dans la documentation pour les développeurs Apple sur l'autorisation des applications et sites web à créer des liens vers votre contenu.

Si un utilisateur navigue sur une page web hébergée sur https://example.com/promo et touche un Universal Link pointant vers le même domaine (https://example.com/product/1024), Safari suppose que l'utilisateur souhaite continuer à naviguer sur le site web et charge la page web plutôt que d'ouvrir l'application native.

L'utilisation d'un hôte de routage associé séparément évite ce cas de continuation sur le même domaine et permet à l'Universal Link d'être évalué pour le routage natif lorsque son association de domaine est valide :

• Hébergez le site web principal sur votre domaine racine ou un sous-domaine web : https://www.example.com.
• Configurez le routage des Universal Links via un sous-domaine dédié et associé séparément : https://app.example.com.

Le passage par des limites de sous-domaines distinctes satisfait les heuristiques de navigation de Safari, favorisant l'exécution directe de l'application native.

Mise en œuvre de transitions web-vers-app résilientes avec des SDK JavaScript

Architecturer des replis multi-niveaux : Universal Links d'abord, repli explicite ensuite

Les architectures web-vers-app en production déploient une cascade de redirection multi-niveaux :

• Niveau 1 (Universal Links) : Le bouton d'appel à l'action principal invoque un Universal Link vérifié pointant vers un sous-domaine associé. Sur les appareils où l'application est installée, cela permet un routage natif sans l'alerte de schéma personnalisé non enregistré.
• Niveau 2 (Repli web contextuel) : Si l'application n'est pas installée, l'Universal Link navigue de manière fluide vers la page d'accueil web, présentant un bouton de téléchargement App Store.
• Niveau 3 (Repli par schéma personnalisé) : Là où les anciens schémas personnalisés (myapp://) sont maintenus pour des versions antérieures du système d'exploitation ou des conteneurs spécifiques, invoquez-les comme un repli qui doit généralement provenir d'une interaction utilisateur explicite plutôt que de scripts automatisés.

Utilisation de l'API Page Visibility comme signal de suppression heuristique

Lors de la mise en œuvre de minuteurs de repli avec des schémas personnalisés, les scripts clients évaluent si le document a perdu la visibilité au premier plan afin d'annuler les redirections vers la boutique. Comme le JavaScript ne peut pas inspecter directement l'exécution du processus natif, les architectures front-end utilisent la norme HTML WHATWG sur la visibilité de la page.

Lorsqu'un onglet de navigateur passe à l'arrière-plan à la suite d'une transition externe, le script détecte le changement de visibilité :

// Délai de repli illustratif ; à calibrer selon les exigences UX de l'application
var fallbackTimer = setTimeout(function() {
    if (!document.hidden) {
        // Le document est resté visible au premier plan ; procéder avec le CTA de repli
        window.location.href = "https://apps.apple.com/app/id123456789";
    }
}, 2000);

document.addEventListener("visibilitychange", function() {
    if (document.hidden) {
        // Le document est devenu caché ; supprimer le minuteur de repli en attente
        clearTimeout(fallbackTimer);
    }
});

Un changement de visibilité indique que le document est devenu caché, ce qui sert de signal de suppression utile pour éviter les redirections erronées vers la boutique. Cependant, les changements de visibilité ne prouvent pas qu'une application cible spécifique s'est ouverte avec succès, car des actions utilisateur telles que changer d'onglet, réduire le navigateur ou verrouiller l'appareil déclenchent également des transitions d'état en arrière-plan. Le délai de 2000 ms est une heuristique illustrative et ne doit pas être considéré comme un seuil de protocole standardisé.

Lier les gestes de l'utilisateur aux ancres Universal Link progressives

Pour un routage de lien direct, les développeurs front-end lient des éléments d'ancrage progressifs directement aux points de terminaison des Universal Links vérifiés. Lorsque des clics se produisent, le navigateur navigue vers le lien HTTPS, permettant à iOS d'intercepter la route.

Dans les tunnels d'acquisition avancés, des plateformes comme OpoInstall prennent en charge la restauration des paramètres différés comme un canal d'ingestion auxiliaire distinct. En enregistrant le contexte web au moment du clic et en le corrélant avec les signaux de lancement post-installation via des hooks SDK natifs, l'application native peut récupérer des paramètres de campagne personnalisés lors du lancement initial sans modifier la validation standard des URL Universal Link. Consultez la documentation d'intégration du SDK pour plus de détails sur l'intégration des auditeurs d'attribution différée aux côtés des gestionnaires Universal Link natifs.

[L'utilisateur touche le bouton CTA web]
             │
             ▼
[Évaluer la primitive de routage]
   ┌─────────┴─────────┐
   ▼                   ▼
[Schéma personnalisé : myapp://] [Universal Link : https://]
   │                           │
   ▼                           ▼
[Safari tente la résolution]   [L'OS évalue l'association]
├─ App résout -> App s'ouvre  ├─ App installée + éligible -> App native
└─ Pas de gestionnaire / bloqué -> └─ Pas installée ->
   Peut afficher l'alerte        Charge la page d'accueil web
   système "Adresse invalide"      │
                                  ▼
                                  [Présente l'App Store ou le repli web]

Mise en œuvre côté client : Routage Universal Link et gestion des replis

Configuration des scripts de redirection Universal Link modernes en HTML/JavaScript front-end

L'implémentation front-end structure un élément d'ancrage interactif qui se lie directement à une URL Universal Link vérifiée sur un sous-domaine associé, offrant un repli d'amélioration progressive si l'exécution du script est bloquée.

Réception native iOS dans les architectures de cycle de vie basées sur les scènes

Pour les applications iOS basées sur des scènes, les Universal Links fournis par Safari sont traités via le cycle de vie UIWindowSceneDelegate : scene(_:willConnectTo:options:) lors d'un lancement à froid et scene(_:continue:) lorsque l'application est en cours d'exécution ou suspendue en mémoire. L'implémentation native valide que l'NSUserActivity entrante a un type d'activité NSUserActivityTypeBrowsingWeb, extrait la webpageURL et valide la route.

L'implémentation technique ci-dessous démontre comment configurer l'ancrage progressif front-end et gérer les URL Universal Link entrantes de manière sécurisée en Swift natif.

// Web : Transition Universal Link front-end avec repli d'ancrage progressif
// Configure une destination Universal Link HTTPS propre avec assainissement des requêtes côté client.
(function() {
    var ctaButton = document.getElementById("openAppBtn");
    if (!ctaButton) return;

    // 1. État initial : Universal Link vérifié sur sous-domaine dédié pour éviter la continuation Safari sur le même domaine
    var targetBaseUrl = "https://app.example.com/detail/1024";

    // 2. Extraire et assainir les paramètres de requête dynamiques de l'URL de la page actuelle
    var urlParams = new URLSearchParams(window.location.search);
    var rawId = urlParams.get("id") || "";
    var rawPromo = urlParams.get("promo_code") || "";
    var rawSource = urlParams.get("utm_source") || "web_landing";

    var idRegex = /^[A-Za-z0-9_-]{1,64}$/;
    var targetId = idRegex.test(rawId) ? rawId : "";
    var promoCode = idRegex.test(rawPromo) ? rawPromo : "";
    var utmSource = idRegex.test(rawSource) ? rawSource : "web_landing";

    var finalUrl = targetBaseUrl + "?utm_source=" + encodeURIComponent(utmSource);
    if (targetId.length > 0) {
        finalUrl += "&id=" + encodeURIComponent(targetId);
    }
    if (promoCode.length > 0) {
        finalUrl += "&promo_code=" + encodeURIComponent(promoCode);
    }

    // Amélioration progressive : l'attribut href de l'ancre fournit une navigation Universal Link directe et sans alerte
    if (ctaButton.tagName.toLowerCase() === "a") {
        ctaButton.setAttribute("href", finalUrl);
    } else {
        ctaButton.addEventListener("click", function(e) {
            e.preventDefault();
            window.location.assign(finalUrl);
        });
    }
})();

// iOS : SceneDelegate.swift - Traitement des Universal Link & Assainissement des routes
// Exemple d'intégration de référence. Vérifiez les signatures de méthodes et le routage par rapport à votre architecture déployée.
import UIKit

struct ValidatedAppRoute {
    let path: String
    let queryParams: [String: String]
}

class AppRouteValidator {
    private static let allowedHosts = Set(["app.example.com"])
    private static let allowedPathPrefixes = ["/detail/", "/promo/"]
    private static let allowedKeys = Set(["id", "promo_code", "utm_source"])

    static func validate(url: URL) -> ValidatedAppRoute? {
        guard let scheme = url.scheme?.lowercased(), scheme == "https" else {
            return nil
        }
        guard let host = url.host?.lowercased(), allowedHosts.contains(host) else {
            return nil
        }

        let path = url.path
        guard allowedPathPrefixes.contains(where: { path.hasPrefix($0) }) else {
            return nil
        }

        var sanitizedParams: [String: String] = [:]
        var seenKeys = Set<String>()

        if let components = URLComponents(url: url, resolvingAgainstBaseURL: false),
           let queryItems = components.queryItems {
            let validChars = CharacterSet(charactersIn: "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_-")
            for item in queryItems {
                // Validation à fermeture par défaut : rejeter l'URL si des clés de requête inconnues existent
                guard allowedKeys.contains(item.name), !seenKeys.contains(item.name) else {
                    return nil
                }
                seenKeys.insert(item.name)

                let value = item.value ?? ""
                if value.count <= 64 && value.rangeOfCharacter(from: validChars.inverted) == nil {
                    sanitizedParams[item.name] = value
                } else {
                    return nil
                }
            }
        }

        return ValidatedAppRoute(path: path, queryParams: sanitizedParams)
    }
}

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var window: UIWindow?

    func scene(
        _ scene: UIScene,
        willConnectTo session: UISceneSession,
        options connectionOptions: UIScene.ConnectionOptions
    ) {
        guard let _ = (scene as? UIWindowScene) else { return }

        // Gérer le lancement à froid via Universal Link
        if let userActivity = connectionOptions.userActivities.first(where: { $0.activityType == NSUserActivityTypeBrowsingWeb }),
           let webpageURL = userActivity.webpageURL {
            processIncomingUniversalLink(url: webpageURL)
        }
    }

    func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
        // Gérer la reprise à chaud via Universal Link
        if userActivity.activityType == NSUserActivityTypeBrowsingWeb,
           let webpageURL = userActivity.webpageURL {
            processIncomingUniversalLink(url: webpageURL)
        }
    }

    private func processIncomingUniversalLink(url: URL) {
        // Appliquer une liste d'autorisation stricte et un assainissement sur l'Universal Link entrant
        if let route = AppRouteValidator.validate(url: url) {
            DispatchQueue.main.async {
                AppNavigator.shared.navigateTo(path: route.path, params: route.queryParams)
            }
        } else {
            DispatchQueue.main.async {
                AppNavigator.shared.navigateToDefaultHome()
            }
        }
    }
}

// Coordinateur de navigation spécifique à l'application (pas une API SDK)
class AppNavigator {
    static let shared = AppNavigator()

    func navigateTo(path: String, params: [String: String]) {
        // Exécuter la transition du contrôleur de vue interne basée sur le chemin et les paramètres de requête
    }

    func navigateToDefaultHome() {
        // Repli sécurisé vers l'écran d'accueil sur les deep links malformés ou non reconnus
    }
}

Assainissement des paramètres entrants : Application d'un filtrage strict sur les routes natives

Conformément au guide OWASP sur les tests de sécurité des applications mobiles et les deep links non sécurisés, tous les paramètres transmis via des Universal Links doivent être traités comme des entrées non fiables :

• Validation du chemin : Vérifiez que le chemin de l'URL correspond à une liste autorisée de contrôleurs de vue (/detail/, /promo/).
• Filtrage des requêtes : Appliquez des clés de requête autorisées (id, promo_code, utm_source) et rejetez les clés inattendues.
• Limites de longueur et de caractères : Restreignez les valeurs des paramètres aux ensembles de caractères alphanumériques ($\le 64$ caractères).

Matrice de protocole Safari Deep Linking et d'atténuation des erreurs

Comparaison complète des protocoles et liste de contrôle pour la prévention des erreurs

La sélection du protocole de deep linking approprié est essentielle pour prévenir les erreurs de navigation WebKit. La matrice ci-dessous compare les principaux mécanismes de deep linking selon les comportements d'erreur et les exigences de la plateforme :

Comparaison des schémas d'URL, Universal Links et Smart App Banners selon les comportements d'erreur

Résumé et cadre de décision

L'alerte « Safari ne peut pas ouvrir la page car l'adresse est invalide » est une conséquence opérationnelle de l'utilisation de schémas URI personnalisés sur des appareils où aucun gestionnaire d'application correspondant n'existe. Se reposer sur d'anciens sondages par iframe cachée ou des cascades automatisées de minuteurs introduit une fragilité de navigation et nuit aux tunnels de conversion web-vers-app.

La migration vers des Universal Links vérifiés supprime le mode d'échec lié aux protocoles personnalisés non enregistrés et fournit une voie de repli HTTPS fiable. En combinant des associations HTTPS vérifiées avec des modèles d'intégration web conformes aux gestes de l'utilisateur, les équipes d'ingénierie réduisent les alertes gênantes du navigateur, préservent les paramètres marketing lors des téléchargements en boutique et soutiennent des expériences d'intégration fiables à travers les tunnels web mobiles.

Pour apprendre à mettre en œuvre les Universal Links et le passage de paramètres automatisé, consultez la documentation d'intégration du SDK.

Documents associés

• Concepts : Schéma d'URL personnalisé, Universal Links, Redirection Web vers App, Atténuation des erreurs WebKit, Restauration de scène
• Technologies : Apple WebKit, iOS UIKit, Apple App Site Association (AASA), SDK Web JS OpoInstall
• Normes : IETF RFC 3986 Uniform Resource Identifier, Spécification des domaines associés Apple, Guide OWASP de test de sécurité des applications mobiles (MASTG)
• API : UIApplication.shared.open, UIWindowSceneDelegate.scene(_:continue:), WHATWG HTML Page Visibility
• Documentation officielle et références :
  • Documentation pour les développeurs Apple sur la définition d'un schéma d'URL personnalisé pour votre application
  • Documentation pour les développeurs Apple sur l'autorisation des applications et sites web à créer des liens vers votre contenu
  • Note technique Apple TN3155 sur le débogage des Universal Links
  • Norme HTML WHATWG sur la visibilité de la page
  • Guide OWASP de test de sécurité des applications mobiles sur les deep links non sécurisés