Application TWA refusée sur Google Play? Passez à WebView

Ce refus est l’un des plus frustrants pour un développeur indépendant. Vos testeurs étaient réellement actifs. Vous aviez vos 12 participants. Les 14 jours se sont écoulés. Pourtant, Google vous a répondu "your testers were not engaged enough." Si vous avez construit votre application comme une Trusted Web Activity (TWA) ou un wrapper PWA, vous n’imaginez pas ce schéma: parmi les 7 400+ applications que nous avons accompagnées, ces versions rencontrent ce refus bien plus souvent que les applications natives classiques ou WebView. Ce guide explique pourquoi, montre la différence d’architecture déterminante et détaille le passage à WebView sans perdre les jours de test déjà accumulés.

Pourquoi les applications TWA sont-elles refusées au test fermé?

Une Trusted Web Activity affiche votre site au moyen de la surface Custom Tabs de Chrome au lieu de dessiner les écrans dans votre propre application. C’est un moyen rapide de transformer un site ou une PWA en application installable et, pour de nombreuses applications déjà en production, cette architecture fonctionne bien. Le problème apparaît surtout lorsqu’un compte de développeur personnel doit remplir l’exigence obligatoire de 14 jours de test fermé avant d’obtenir un accès en production.

D’après notre expérience auprès de plus de 7 400 applications, les versions TWA et les wrappers PWA reçoivent le refus "testers were not engaged" bien plus souvent que les applications natives classiques, même lorsque les testeurs sont réellement actifs chaque jour. Ce schéma est assez constant pour que nous recommandions désormais d’abandonner la TWA lorsqu’une application doit encore effectuer le test fermé de 14 jours.

Ce qu’est réellement une TWA et comment elle est construite

Avant de corriger le refus, il faut comprendre exactement ce que vous avez publié. Une Trusted Web Activity est une application Android qui correspond essentiellement à votre site web exécuté en plein écran dans un véritable moteur de navigateur, sans barre d’adresse ni interface indiquant à l’utilisateur qu’il consulte une page web. Elle ressemble à une application native, mais repose en réalité sur votre site en ligne.

Les TWA sont généralement générées avec le CLI Bubblewrap de Google ou avec PWABuilder, tous deux fondés sur la bibliothèque androidbrowserhelper de Google. Vous indiquez une URL à l’outil, il produit un projet Android, puis vous le signez et importez l’AAB dans Google Play.

Pourquoi les développeurs choisissent une TWA

Le compromis qui provoque le refus

Ce qui rend la TWA peu coûteuse la fragilise aussi pendant le test fermé:

• Elle a besoin d’Internet. C’est une fenêtre sur votre site. Une connexion faible produit donc une expérience médiocre, sauf si votre PWA gère correctement le mode hors connexion.
• Elle risque un refus sur le Play Store. Le règlement sur les fonctionnalités minimales et le contenu répétitif vise les applications qui ne sont qu’un site dans un wrapper. Une TWA sans véritable capacité native peut être refusée ou supprimée, surtout lors d’une première soumission. Ajoutez des fonctions natives comme les notifications push, un mode hors connexion, l’appareil photo ou des cibles de partage pour rester du bon côté de cette limite.
• Elle peut affaiblir les signaux d’engagement. C’est la raison pour laquelle des comptes de développeur personnels soumis au test fermé de 14 jours continuent de recevoir le message "testers not engaged".

L’idée reçue: une TWA n’est PAS un WebView

C’est le point que la plupart des articles expliquent mal. La précision est importante, car elle change la façon de corriger le problème. Une TWA n’utilise pas le composant WebView d’Android.

Comme une TWA utilise le moteur de Custom Tabs, elle bénéficie du même moteur de rendu, du même moteur JavaScript et du même bac à sable de sécurité que Chrome, ainsi que des cookies et du stockage partagés avec Chrome. Un utilisateur déjà connecté sur le web reste donc connecté. Vous profitez aussi des mises à jour automatiques du navigateur et d’une prise en charge complète de la plateforme web. Ces atouts sont puissants pour une application déjà publiée, mais ils signifient également que vos écrans s’exécutent hors processus, dans Chrome, et non dans votre propre application. C’est l’origine probable de l’affaiblissement des signaux d’engagement et du faible nombre d’utilisateurs actifs.

Le lancement, étape par étape

La relation de confiance: Digital Asset Links

Chrome ne retire la barre d’adresse que si l’application peut prouver son association avec le site au moyen de Digital Asset Links. L’application déclare le site qu’elle représente, et ce site doit fournir un fichier /.well-known/assetlinks.json indiquant le package de l’application et l’empreinte SHA-256 du certificat de signature.

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.yourapp.name",
    "sha256_cert_fingerprints": [
      "AB:CD:EF:...:99"  // your signing cert SHA-256
    ]
  }
}]

Le parcours des signaux d’engagement: TWA ou WebView

Le moyen le plus simple de comprendre le refus consiste à suivre l’activité réelle d’un testeur. Dans une TWA, vos écrans se trouvent une couche plus loin de l’application, dans la surface Custom Tabs de Chrome. Dans une application WebView, les mêmes écrans s’exécutent dans le processus de votre propre application et sont directement attribués à votre package. Cette différence détermine la netteté avec laquelle l’activité est enregistrée.

Comment reconnaître une TWA de l’extérieur et de l’intérieur

Vous ne savez pas si l’application que vous avez publiée, ou fait réaliser par un prestataire, est réellement une TWA? Voici comment le confirmer, d’abord visuellement, puis avec certitude à partir de l’APK ou d’un appareil connecté.

Indices visuels rapides pour l’utilisateur

• Elle se comporte exactement comme le site web, puisqu’elle affiche ce site.
• Si elle est mal configurée, une barre d’adresse apparaît en haut. C’est un indice décisif lié au problème assetlinks décrit plus haut.
• Le contenu change sans mise à jour de l’application dans le Play Store.

Indices techniques décisifs dans l’APK ou sur l’appareil

Confirmez avec adb

Sur un appareil connecté ou un émulateur, deux commandes suffisent:

# Is it a TWA? Look for the delegation service:
adb shell dumpsys package <package.name> | grep -i DelegationService

# Which site does it wrap, and is the trust check passing?
adb shell pm get-app-links <package.name>
#   -> "verified"  = Digital Asset Links pass (fullscreen)
#   -> "1024"      = verification failed (address bar shows)

TWA ou WebView pour le test fermé: comparaison directe

Les deux architectures enveloppent du contenu web. Pour réussir le test fermé de 14 jours, la différence essentielle tient à l’endroit où ce contenu s’exécute et à la façon dont son activité est attribuée. Voici leur comparaison sur les critères qui déterminent si vous atteignez la production en un seul cycle.

La solution: construisez une application WebView standard

Au lieu de réparer une TWA par petites touches ou de tenter d’en renforcer les signaux, la méthode la plus propre consiste à reconstruire l’application autour d’un composant WebView, puis à publier cette version. Trois solutions courantes permettent toutes de charger votre site dans votre propre application:

La configuration WebView minimale à copier

Le cœur est compact: un WebView charge votre URL avec JavaScript et le stockage activés, conserve la navigation dans l’application au lieu de l’envoyer vers Chrome et gère le bouton Retour comme l’attend l’examen de Google. Choisissez votre langage dans les onglets, puis copiez la base:

val webView = findViewById<WebView>(R.id.webview)
webView.settings.apply {
    javaScriptEnabled = true          // most sites need this
    domStorageEnabled = true          // localStorage / sessionStorage
    cacheMode = WebSettings.LOAD_DEFAULT
}

// Keep links INSIDE the app (this is the key difference vs a TWA)
webView.webViewClient = WebViewClient()
webView.loadUrl("https://yourwebsite.com")

// The exact back-button handler Google looks for
onBackPressedDispatcher.addCallback(this, object : OnBackPressedCallback(true) {
    override fun handleOnBackPressed() {
        if (webView.canGoBack()) {
            webView.goBack()
        } else {
            finish()
        }
    }
})

WebView webView = findViewById(R.id.webview);
WebSettings settings = webView.getSettings();
settings.setJavaScriptEnabled(true);      // most sites need this
settings.setDomStorageEnabled(true);      // localStorage / sessionStorage
settings.setCacheMode(WebSettings.LOAD_DEFAULT);

// Keep links INSIDE the app (this is the key difference vs a TWA)
webView.setWebViewClient(new WebViewClient());
webView.loadUrl("https://yourwebsite.com");

// The exact back-button handler Google looks for
getOnBackPressedDispatcher().addCallback(this, new OnBackPressedCallback(true) {
    @Override
    public void handleOnBackPressed() {
        if (webView.canGoBack()) {
            webView.goBack();
        } else {
            finish();
        }
    }
});

# Wrap an existing web/PWA project in a native WebView shell
npm install @capacitor/core @capacitor/cli
npx cap init "YourApp" "com.yourapp.name"

# Point Capacitor at your live site (capacitor.config.ts)
#   server: { url: "https://yourwebsite.com", cleartext: false }

npm install @capacitor/android
npx cap add android
npx cap sync

# Capacitor handles back-button + DOM storage natively.
# Open in Android Studio to build a signed AAB:
npx cap open android

Les trois ajouts nécessaires pour franchir l’examen

Un WebView rudimentaire qui appelle uniquement loadUrl() reste un thin wrapper. Les trois ajouts suivants le transforment en véritable application et empêchent les testeurs de rencontrer des écrans vides:

Comment changer sans remettre à zéro le délai de 14 jours

Si votre test est déjà en cours, vous n’avez pas à repartir de zéro. Le compteur de 14 jours survit à une mise à jour tant que vous conservez le même canal de test et le même package name. Voici la migration sûre:

Une application WebView reste-t-elle un "thin wrapper"?

C’est le piège des développeurs qui voient WebView comme une solution magique. Passer de TWA à WebView corrige le problème des signaux d’engagement, mais ne vous dispense pas du règlement de Google relatif au spam et aux fonctionnalités minimales. Un WebView qui se limite à encadrer votre page d’accueil peut encore être refusé comme thin wrapper, c’est-à-dire comme simple enveloppe d’un site sans véritable valeur native, tout comme une TWA rudimentaire.

Considérez ces contrôles comme deux portes distinctes. Un service de test ou une reconstruction avec WebView peut vous aider à franchir la première, mais pas la seconde.

L’objectif n’est donc pas simplement de choisir WebView plutôt que TWA. Il faut une application WebView suffisamment utile et dotée d’un vrai comportement natif. En pratique:

Vous souhaitez une liste complète des motifs de refus liés à la qualité? Notre guide explique pourquoi un test fermé est refusé et détaille les problèmes de conformité et d’examen qui dépassent l’engagement.

Vous ignorez si votre application est une TWA? Nous la contrôlons dès la commande

Vous n’avez pas à exécuter de commandes adb ni à fouiller dans votre APK. PrimeTestLab peut confirmer pour vous si votre application est une TWA. Dès que vous commandez notre service de test, notre équipe inspecte votre version, détermine s’il s’agit d’une TWA ou d’un wrapper PWA et, le cas échéant, vous indique précisément ce qu’il faut corriger avant de perdre 14 jours sur une architecture susceptible d’être signalée pour son engagement.

Ce qui se passe dès votre commande

Comment PrimeTestLab vous aide à résoudre l’autre moitié du problème

L’architecture ne représente qu’une moitié du problème. L’autre, qui bloque la plupart des développeurs indépendants, consiste à obtenir 12 testeurs qui s’inscrivent réellement au test et restent actifs pendant 14 jours sans interruption. C’est ce que prend en charge PrimeTestLab.

Nous fournissons des testeurs inscrits et vérifiés sur de véritables appareils Android. Ils maintiennent votre test fermé actif pendant toute la durée requise, afin qu’un seul abandon ne rompe pas la série de 14 jours. Vous partagez le lien partageable; nous gérons les invitations, la confirmation des inscriptions, le suivi quotidien de l’engagement et la présence pendant 14 jours. Plus de 7 400 applications accompagnées, avec un taux de réussite au premier essai de 99.9%.

Prix indiqués plus 5% de frais de service

Plans actuels

+5% de frais de service · Nouveau test gratuit ou remboursement intégral

Questions fréquentes

Conclusion