Vous vous trouvez probablement dans l'une de ces deux situations. Soit vous avez hérité d'une application Cordova qui reste cruciale pour l'entreprise, soit vous maintenez une application hybride stable pendant que l'équipe migre progressivement vers de nouveaux outils. Puis, une demande produit arrive : scanner des étiquettes d'inventaire, des tickets, des colis ou des étiquettes de rayon avec la caméra du téléphone.
C'est là que scanner de code-barres Cordova devient intéressant. Une démo de base est facile à réaliser. L'intégration en production ne l'est pas. Les points complexes sont le choix d'un plugin adapté à vos formats de codes-barres, la configuration propre des permissions natives et la gestion des particularités de plateforme qui n'apparaissent que sur les appareils réels. Si votre application touche aussi aux opérations de terrain ou aux flux d'inventaire, la fonction de scan est généralement liée à des enjeux opérationnels plus larges comme la gestion de composants IT critiques, où l'application mobile devient une partie intégrante d'un workflow d'actifs et de services plus vaste.
Cordova reste une stack bien réelle dans la maintenance d'entreprise. Dès le milieu des années 2010, le scan de codes-barres sous Cordova dépassait déjà le stade de l'exemple gadget pour devenir des apps hybrides d'entreprise conçues pour Android et connectées à des services backend, incluant un flux documenté utilisant cordova create, cordova platform add android, and a generated barcodeScanner-debug.apk dans un exemple concret de build d'application issu de le tutoriel de scan Cordova de SitePoint. Si votre équipe réfléchit également à des choix d'architecture à long terme, cette comparaison entre applications natives et applications web aide à comprendre pourquoi les apps hybrides figurent encore dans les pipelines de livraison mobile sérieux.
Table of Contents
- Pourquoi ajouter un scanner de codes-barres à votre app Cordova
- Choisir votre plugin de scan de codes-barres Cordova
- Installation et configuration des plateformes
- Implémenter le scanner dans votre application Code
- Tests et résolution des erreurs courantes
- Conseils de performance et migration vers Capacitor
Pourquoi ajouter un scanner de codes-barres à votre app Cordova
Un scanner change les capacités d'une app Cordova sur le terrain. Au lieu de demander aux utilisateurs de saisir des numéros de série, des ID de commande ou des codes produits, vous utilisez la caméra comme périphérique de saisie. Cela réduit la friction et, surtout, limite les erreurs de saisie des utilisateurs.
En pratique, le scan de codes-barres s'impose là où les apps mobiles rencontrent les opérations réelles. Réception en entrepôt, recherche en magasin, validation de pièces en service terrain, enregistrement de visiteurs ou suivi d'actifs internes : tous en bénéficient. Un scanner modifie aussi les attentes des utilisateurs. Une fois la caméra disponible, ils ne tolèrent plus la saisie manuelle de code, sauf en cas de repli explicite.
Cordova reste pertinent en mode maintenance
Beaucoup d'équipes parlent de Cordova comme s'il avait disparu. Ce n'est pas le cas. Il a évolué vers des portefeuilles d'entreprise axés sur la maintenance, où remplacer une app fonctionnelle est plus complexe que de l'étendre. Si l'app gère déjà l'authentification, la synchro, les formulaires et le stockage hors ligne, ajouter un scanner est souvent moins risqué que de reconstruire tout le produit.
Règle pratique : Ne considérez pas une demande de scan comme un déclencheur de réécriture, sauf si le reste de l'app pose déjà des problèmes opérationnels à votre équipe.
Cordova a également trouvé sa place car les plugins exposaient les capacités natives de l'appareil d'une manière que le code web pouvait utiliser. C'est pourquoi le scan de codes-barres est devenu si courant dans les apps mobiles hybrides. Cela correspondait exactement au modèle conçu pour Cordova : placer une capacité native derrière un API JavaScript et laisser le flux de l'app rester principalement basé sur le web.
La valeur réside dans le workflow, pas dans la démo
Un bouton de scan qui renvoie du texte est la partie facile. Le vrai travail réside dans tout ce qui l'entoure :
- Choisir les symbologies supportées : Votre app peut n'avoir besoin que du QR code, ou aussi de codes spécifiques au retail et à la logistique.
- Gérer les permissions proprement : If camera access fails once, users often assume the feature is broken.
- Concevoir l'action post-scan : La recherche, la validation, la navigation et la gestion des doublons comptent plus que l'interface de la caméra.
- Planifier la modernisation : Si votre équipe migre vers Capacitor, vous avez besoin d'une approche qui ne limite pas la fonctionnalité aux seules hypothèses de Cordova.
Ce dernier point est crucial. Les équipes réussissent souvent l'intégration initiale avec Cordova, puis rencontrent des problèmes lors de la migration car le modèle de rendu natif change sous le plugin. Le scanner fonctionne toujours. C'est juste que l'aperçu ne s'affiche pas là où vous l'attendez.
Choisir votre plugin de scan de codes-barres Cordova
Avant d'écrire le code de votre application, déterminez votre priorité. Certaines équipes ont besoin d'une large compatibilité des codes-barres. D'autres nécessitent seulement une superposition de caméra pour des flux QR. Choisir le mauvais plugin dès le départ entraîne du travail supplémentaire, surtout si le produit demande un format de code-barres supplémentaire après le lancement.
Le plugin que la plupart des développeurs reconnaîtront est cordova-plugin-barcodescanner. Son package npm documente un scan(success, fail) API et la prise en charge des symbologies courantes, notamment QR_CODE, DATA_MATRIX, UPC_A, EAN_13, CODE_128, PDF_417 et AZTEC, ce qui lui permet de s'adapter aux scénarios de vente au détail et de logistique, plutôt qu'aux seuls cas d'usage basés sur le QR, comme le montre la documentation du package du plugin sur npm.
Pour les équipes qui évaluent leur stratégie de plugins de manière plus large, cet aperçu de ce qu'il faut savoir sur les plugins Capacitor est utile car il souligne les différences entre les anciennes hypothèses de plugins de style Cordova et les nouveaux modèles de pont natif.
Ce qui compte avant toute installation
Ne vous fiez pas uniquement à la popularité. Partez de votre besoin de scan.
Si l'app doit lire plusieurs familles de codes-barres dans divers contextes opérationnels, une prise en charge étendue des symbologies compte plus qu'un API minimal. Si l'app ne nécessite que le check-in par QR code, vous pouvez vous contenter d'un outil plus limité s'il offre une expérience caméra plus simple. Ce que les développeurs juniors oublient souvent, c'est que le scan consiste moins à savoir « est-ce que ça scanne » qu'à savoir « est-ce que ça scanne exactement les étiquettes utilisées sur le terrain sans bricolages pénibles ».
Voici une checklist pour bien choisir :
- Couverture des codes-barres : Confirmez les formats exacts utilisés en production.
- Attentes par plateforme : Vérifiez ce que l'équipe supporte réellement aujourd'hui, pas ce que le plugin supportait par le passé.
- Modèl’UI : Certains plugins ouvrent un flux de scan natif. D'autres reposent sur une approche d'aperçu intégré.
- Tolérance à la migration : Demandez-vous si ce plugin deviendra pénible si l'app migre vers Capacitor plus tard.
Un plugin qui fonctionne en démo mais qui casse la mise en page, le cycle de vie ou la migration de votre app est généralement le mauvais plugin.
Tableau comparatif des plugins
| Fonctionnalité | phonegap-plugin-barcodescanner | cordova-plugin-qrscanner |
|---|---|---|
| Usage principal | Scan large de multiples formats de codes-barres | Flux de scan axés sur le QR code |
| Style API | Pattern de callback classique des projets Cordova hérités | Souvent choisi pour des cas d'usage avec aperçu caméra en direct |
| Portée des formats de codes-barres | Plus adapté si le produit nécessite plus que du QR | Plus adapté si le QR est la seule exigence stricte |
| Risque de migration | Peut fonctionner, mais d'anciennes hypothèses peuvent surgir lors des migrations de bridge modernes | Les approches basées sur l'aperçu peuvent révéler des problèmes de rendu plus rapidement |
| Meilleure option | Retail, logistics, asset, and mixed barcode workflows | Flux de check-in, URL, authentification et QR uniquement |
Ce tableau reflète l'adéquation pratique, pas un score. Si vous avez besoin de symbologies retail et logistique, la catégorie de plugin plus large est généralement le choix le plus sûr. Si vous ne scannez que du QR et souhaitez une expérience de preview plus contrôlée, une approche orientée QR peut être plus légère.
L'erreur que je vois le plus souvent est de choisir un outil axé sur le QR parce que la première release n'a besoin que de QR, pour ensuite devoir l'adapter au UPC ou au Code 128 plus tard. S'il y a la moindre chance que vos utilisateurs scannent des étiquettes d'imprimantes, d'étagères, de bacs ou de documents d'expédition, choisissez dès maintenant en fonction de ce futur.
Installation et configuration de la plateforme
L'intégration casse généralement avant le premier scan, pas après. La plupart des échecs proviennent d'un décalage de configuration entre les attentes JavaScript et la configuration de la plateforme native. Traitez cette partie comme une checklist, pas comme une installation rapide.
Un flux d'implémentation solide commence par l'ajout du plugin ou de SDK, la création du contexte de capture, la restriction des symbologies aux codes utilisés en production, la configuration de l'UI, et seulement ensuite, l'enregistrement d'un écouteur de scan. Cette séquence est préconisée dans le guide Cordova de Scandit pour SparkScan, et elle correspond à la manière dont les intégrations de scanners professionnelles restent maintenables dans les apps hybrides, comme décrit dans le guide développeur de Scandit pour le scan de codes-barres avec Cordova. Si votre app est encore fortement hybride au niveau de l'architecture, ce guide sur le développement d'apps hybrides Cordova est un excellent compagnon.
Commencez par le flux d'intégration
Une fonctionnalité de scan est plus efficace si vous définissez ces points au préalable :
- Quels types de codes-barres l'app doit accepter.
- Si le scan est une action plein écran ou fait partie d'un workflow intégré.
- Ce que l'app doit faire après une lecture réussie.
- Quelle solution de repli est prévue si la caméra est indisponible.
Cela permet de lier l'installation du plugin à un véritable workflow plutôt qu'à une simple capacité de l'appareil.
Étapes d'installation Cordova
Pour une configuration Cordova classique utilisant le plugin de scanner de code-barres courant, le point de départ est la commande d'installation standard documentée par le package :
cordova plugin add cordova-plugin-barcodescannerUne séquence de configuration de projet typique ressemble à ceci :
cordova create barcodeScannerApp
cd barcodeScannerApp
cordova platform add android
cordova platform add ios
cordova plugin add cordova-plugin-barcodescanner
cordova build android
cordova build iosCette séquence est simple, mais ne vous arrêtez pas là. Lancez un build immédiatement après l'installation du plugin pour détecter les problèmes de dépendances natives avant de lier l'interface code. Si le build échoue, résolvez cela en priorité.
Config native qui casse généralement en premier
Sur iOS, l'accès à la caméra doit être déclaré correctement dans les paramètres du projet natif. Si la description d'utilisation de la permission est manquante ou vague, le scanner ne fonctionnera pas correctement pour les utilisateurs. Ajoutez une description claire de la confidentialité de la caméra dans Info.plist qui explique pourquoi l'application a besoin de la caméra.
Sur Android, examinez les entrées du manifeste et les permissions liées aux plugins après l'installation. Le plugin peut ajouter ce dont il a besoin, mais les anciens projets contiennent souvent des changements de config accumulés, des paramètres Gradle personnalisés ou des chevauchements de plugins qui causent des avertissements au build ou des erreurs au runtime. Ne supposez pas que le manifeste est propre simplement parce que le plugin s'est installé avec succès.
Utilisez cette checklist rapide :
- Vérifiez les versions des plateformes : Les anciens projets Cordova conservent souvent des packages de plateforme obsolètes.
- Examinez les prompts de permission : The wording and timing matter to user trust.
- Testez sur un appareil réel rapidement : Les émulateurs ne vous en diront pas assez sur le comportement de la caméra.
- Limitez le scope du scanner : Activez uniquement les types code acceptés par votre workflow.
Si votre scanner n'a besoin que d'un ou deux formats, configurez-les en priorité. Un scan large semble flexible, mais cela ralentit souvent le debugging car chaque étiquette illisible devient ambiguë.
Pour les développeurs juniors, la leçon clé est celle-ci : l'installation n'est pas qu'une commande terminal. C'est un alignement du projet natif. Si Android et iOS ne sont pas configurés intentionnellement, la couche JavaScript ne vous sauvera pas.
Implémenter le scanner dans votre application Code
Une fois le plugin installé et l'app compilée, gardez une première implémentation simple. Placez l'action de scan derrière un bouton, loguez le résultat complet et prouvez que le flux de callback fonctionne avant de concevoir une interface soignée.
Le pattern classique des scanners Cordova utilise la méthode scan(success, fail) du plugin. Ce style de callback est ancien, mais il est fiable dans les bases de code legacy et facile à encapsuler plus tard si votre app utilise des promises ou des abstractions TypeScript. Si vous voulez mieux comprendre comment le code web appelle le code natif dans ces projets, cette explication comment Capacitor fait le pont entre le web et le code natif vous aidera, même si vous développez encore sous Cordova aujourd'hui.
Exemple en JavaScript pur
Voici une implémentation minimale pour une ancienne application Cordova :
<button id="scan-button">Scan barcode</button>
<div id="scan-result"></div>document.addEventListener('deviceready', function () {
var button = document.getElementById('scan-button');
var resultEl = document.getElementById('scan-result');
button.addEventListener('click', function () {
cordova.plugins.barcodeScanner.scan(
function (result) {
if (result.cancelled) {
resultEl.textContent = 'Scan cancelled';
return;
}
resultEl.textContent =
'Text: ' + result.text +
' | Format: ' + result.format;
},
function (error) {
resultEl.textContent = 'Scan failed: ' + error;
}
);
});
});Cela permet de faire trois choses utiles. Cela attend deviceready, lie le scan à une action utilisateur intentionnelle et gère explicitement les cas de succès et d'échec. Ne négligez pas le cas d'annulation. Les utilisateurs quittent les flux caméra tout le temps.
Exemple TypeScript
Si votre projet utilise TypeScript, définissez vous-même la forme du résultat pour que le reste de l'app puisse l'utiliser proprement :
interface BarcodeScanResult {
text: string;
format: string;
cancelled: boolean;
}
function scanBarcode(): void {
cordova.plugins.barcodeScanner.scan(
(result: BarcodeScanResult) => {
if (result.cancelled) {
renderStatus('Scan cancelled');
return;
}
handleScannedCode(result);
},
(error: unknown) => {
renderStatus(`Scan failed: ${String(error)}`);
}
);
}
function handleScannedCode(result: BarcodeScanResult): void {
renderStatus(`Scanned ${result.format}: ${result.text}`);
if (!result.text) {
renderStatus('Empty scan result');
return;
}
lookupItemByCode(result.text);
}
function renderStatus(message: string): void {
const el = document.getElementById('scan-result');
if (el) el.textContent = message;
}
function lookupItemByCode(code: string): void {
console.log('Lookup code:', code);
}Cette version sépare le scan de la logique métier. C'est important car le plugin de scan ne doit que capturer l'entrée. La validation, la recherche et la navigation doivent être gérées ailleurs.
Que faire du résultat du scan
Un bon flux post-scan correspond généralement à l'un de ceux-ci :
- Flux de recherche : Utilisez le texte scanné pour récupérer un produit, une commande ou un enregistrement d'actif.
- Flux de validation : Comparez la valeur scannée avec un code attendu déjà présent à l'écran.
- Flux de navigation : Dirigez l'utilisateur vers une tâche liée à l'élément scanné.
- Flux de capture : Save the value locally for later sync.
Ne laissez pas le callback du scanner devenir un dépotoir pour les appels API, les mises à jour du DOM, l'analytics et la navigation. Transmettez la valeur rapidement.
De plus, loguez le résultat brut lors des premiers tests. Même si votre UI de production n'a besoin que de text, le résultat retourné format retournée est utile pour déboguer les labels incorrects. Si l'opération indique « le scanner ne peut pas lire ce code », le formatage des données vous dira souvent si le problème vient du type de code-barres et non de sa qualité.
Tests et dépannage des erreurs courantes
La plupart des problèmes de scanner de code-barres avec Cordova ne proviennent pas du scan API lui-même. Ils proviennent de la limite entre l'UI web, les vues natives et les permissions de l'appareil. C'est là que des démos propres se transforment en rapports de bugs confus.
Le problème le plus difficile à diagnostiquer est le bug de rendu Android qui apparaît lors des migrations Capacitor ou des configurations mixtes Cordova-Capacitor. Un développeur dans Capacitor issue #1213 l'a décrit simplement : « J'ai essayé ce plugin sur mon application capacitor, mais il semble que le scanner soit derrière l'application », et la correction nécessite de rendre l'arrière-plan de la webview native transparent en plus d'appliquer des changements de transparence au DOM, ce que les tutoriels Cordova standards ne couvrent généralement pas, comme documenté dans la discussion sur le problème de rendu Android Capacitor. Si vous déboguez une migration hybride, voici ce guide pour le débogage des applications Capacitor vaut la peine de rester ouvert.
Le bug de l'aperçu Android derrière l'application
Symptôme
Vous lancez le scanner. Les permissions semblent correctes. Aucun crash évident ne survient. Mais l'aperçu de la caméra apparaît invisible, bloqué ou « derrière » l'interface de l'app.
Cause
La vue native du scanner et la webview sont superposées différemment de ce que le plugin Cordova original attendait. Sur Android, dans des configurations de type Capacitor, le fond de la webview peut rester opaque, ce qui fait que l'aperçu natif existe mais reste caché dessous.
Solution
Appliquez une configuration de vue transparente des deux côtés :
- Côté natif : Réglez le fond de la webview sur transparent.
- Côté web : Supprimez les fonds opaques des éléments conteneurs situés au-dessus de l'aperçu du scanner.
- Côté mise en page : Vérifiez les wrappers plein écran, les shells de modales et les conteneurs de pages du framework pour les couleurs d'arrière-plan par défaut.
- Côté tests : Validez sur un appareil Android physique, car le comportement de la mise en page peut être trompeur dans les shells de développement.
C'est ce bug qui fait croire aux développeurs que le plugin est cassé, alors qu'il s'agit d'un problème de composition de vue.
Échecs de permission et faux négatifs
Les permissions échouent de manières qui ressemblent à des bugs du scanner.
Si l'utilisateur refuse l'accès à la caméra, votre callback peut renvoyer une erreur générique, ou le scanner peut ne pas s'afficher comme prévu. Gérez le refus de permission comme un flux normal de l'UI. Expliquez à l'utilisateur ce qui s'est passé et comment réessayer après avoir activé l'accès. Sur iOS particulièrement, un texte de permission peu clair crée de la méfiance avant même que l'utilisateur ne voie le scanner.
Quelques habitudes aident :
- Déclenchez le scan via une action utilisateur claire : Les prompts de permission paraissent moins suspects.
- Affichez une alternative de saisie : La saisie manuelle permet de maintenir le workflow.
- Chemins de test (refus puis nouvel essai) : Many teams only test the happy path once.
Problèmes de build et de test sur appareil
Certaines erreurs n'apparaissent que sur certains environnements.
| Problème | Cause probable | Solution pratique |
|---|---|---|
| Le scanner s'ouvre mais aucun résultat utile n'est retourné | Format de code-barres non supporté ou inattendu | Tester avec des étiquettes connues correspondant à votre cas d'usage |
| Le build échoue après l'installation du plugin | Dérive de plateforme ou de dépendance dans un projet ancien | Réconciliez les packages de plateforme avant de modifier le code de l'app |
| Fonctionne dans un shell d'app mais pas dans un autre | Interférences de couches de vue ou de CSS | Réduisez l'écran à un layout minimal et réajoutez les styles progressivement |
| Le comportement de l'émulateur est trompeur | La simulation de la caméra ne reflète pas la réalité de l'appareil | Testez tôt sur du matériel Android et iPhone physique |
Réduisez la page à un bouton et un élément de résultat lors du debug. Si le scanner fonctionne ainsi, votre problème vient généralement du layout ou du code de l'app, pas du plugin.
Conseils de performance et migration vers Capacitor
Un scanner de code-barres peut décoder correctement mais échouer concrètement pour l'utilisateur. Le problème se manifeste souvent par de la latence, des clignotements, des bugs de l'aperçu caméra, ou un écran Android qui se comporte différemment selon les appareils d'un même pool de tests.
Dans les anciennes apps Cordova, le décodeur n'est souvent pas le point faible. La webview, la superposition des vues et le code qui réagit aux résultats de scan causent généralement plus de problèmes que la reconnaissance du code-barres elle-même.
Commencez par limiter le champ d'action de l'écran de scan. Si l'écran est destiné à scanner des étiquettes d'inventaire, laissez-le se concentrer sur les étiquettes d'inventaire. Les filtres superflus, les panneaux animés et les mises à jour d'état trop larges augmentent la charge de rendu, là où le rendu de la webview Android est déjà fragile.
A few changes tend to pay off fast:
- Limitez les formats de codes-barres acceptés si votre plugin le permet. Cela réduit les lectures erronées et facilite la gestion de la couverture de tests.
- Gardez la logique post-scan concise. Analysez, validez et mettez à jour la plus petite partie possible de l'interface.
- Bloquez les lectures en double temporairement. Certains appareils renverront le même résultat plusieurs fois avant que l'utilisateur ne déplace la caméra.
- Prévoyez une saisie manuelle dans le flux. Les étiquettes endommagées, le mauvais éclairage et les emballages réfléchissants surviennent toujours en conditions réelles.
- Surveillez de près le coût de repaint sur Android. Les overlays lourds, les transitions CSS et les composants superposés peuvent déstabiliser l'aperçu de la caméra dans une webview Cordova.
Un parcours de migration pratique vers Capacitor
La migration de Cordova vers Capacitor la plus propre est progressive, pas héroïque. Les équipes s'exposent à des problèmes lorsqu'elles changent le conteneur de l'app, le plugin du scanner, le flux de permissions et les overlays d'interface en une seule fois, sans pouvoir identifier quelle modification a causé la rupture.
Utilisez plutôt cet ordre :
-
Auditez les plugins actuels
Listez chaque plugin Cordova et marquez-le comme actif, remplaçable ou risqué s'il dépend de comportements de plateformes plus anciens. -
Migrez d'abord le shell de l'app
Exécutez l'application web existante dans Capacitor avant de remplacer le scanner code. Cela permet de séparer les problèmes de conteneur des problèmes de plugin. -
Gardez les plugins Cordova pour une courte transition si besoin
Une compatibilité temporaire est souvent plus sûre que de réécrire simultanément le scanner, l'accès aux fichiers et la gestion des permissions. -
Remplacez tôt les composants fragiles du scanner
Les anciens plugins qui reposent sur des overlays personnalisés, des comportements Android non documentés ou une gestion obsolète de la caméra devraient passer en priorité.
Le bug de l'aperçu de la caméra sur Android mérite une attention particulière car il fait perdre énormément de temps au débogage. J'ai vu des écrans de scan échouer parce que l'aperçu natif se trouve derrière la webview, est rogné sur les bords, ou affiche un écran noir sur certains appareils Android. À ce stade, le plugin de barcode est souvent le premier accusé, même si le problème de fond est la composition de la vue.
Considérez cela comme une investigation de rendu, et pas seulement une investigation de scanner. Supprimez les overlays décoratifs. Réduisez la page à l'aperçu, un déclencheur et un champ de résultat. Si l'aperçu devient stable après cela, le problème vient généralement de votre structure d'écran ou de votre CSS, pas du décodage.
C'est aussi ici qu'une migration vers Capacitor commence à se justifier. Capacitor ne supprime pas tous les bugs de caméra, mais il offre généralement une séparation plus nette entre la gestion de la vue native et l'UI web code. Pour le scan de codes-barres, @capgo/camera-preview affiche un flux caméra en direct sous forme d'overlay natif avec des contrôles personnalisables, ce qui vous permet de décoder des frames en JavaScript sans que l'aperçu ne se retrouve derrière la webview. Pour le scan en entreprise sur les appareils Zebra, @capgo/capacitor-zebra-datawedge gère les profils DataWedge et les déclencheurs de scan. Pour les workflows de tags NFC, @capgo/capacitor-nfc gère la découverte, la lecture et l'écriture de tags natifs sur iOS et Android.
Les projets Cordova ont tendance à casser à cause de l'obsolescence des plugins, de la dérive des plateformes et d'hypothèses cachées dans les anciennes intégrations. Les projets Capacitor exposent des problèmes différents, principalement liés à la gestion du cycle de vie et à la superposition native, mais ces échecs sont plus faciles à tracer car la partie native est plus explicite.
Si votre scanner Cordova actuel ne fonctionne qu'après une accumulation de correctifs spécifiques à chaque appareil, arrêtez d'ajouter des patchs. Stabilisez l'écran de scan, confirmez si le bug de prévisualisation Android est réellement un problème de superposition de la webview, puis migrez par étapes contrôlées. Cette approche est plus lente pendant une semaine, mais plus rapide pour le reste du projet.
