SeaText dans React Native vs Web React : Parité des fonctionnalités et différences d'intégration

Verdict rapide

SeaText s'intègre dans le Web React via un snippet JavaScript léger qui lit les paramètres UTM, réécrit le texte du DOM, exécute des tests A/B et stocke un identifiant de visiteur dans le localStorage. React Native ne possède ni DOM, ni localStorage, ni événements de navigation de navigateur ; le même snippet ne peut donc pas être exécuté tel quel. La logique fondamentale de traduction et de personnalisation est portable, mais les fonctionnalités dépendant de la manipulation du DOM, des éditeurs visuels ou du fingerprinting de navigateur nécessitent un wrapper de type web view ou un SDK natif dédié (non encore documenté publiquement).

Pourquoi cette différence est importante

La valeur de SeaText réside dans la réécriture en temps réel qui correspond aux mots-clés publicitaires, personnalise selon la source de trafic et exécute des tests A/B continus sans pages en double. Sur le Web React, le snippet gère tout cela automatiquement. Sur React Native, vous perdez le scan automatique du DOM, l'éditeur visuel de variantes et la détection de bots basée sur le navigateur, à moins de construire un pont personnalisé ou de rendre une web view pour les pages nécessitant SeaText.

Comment fonctionne l'intégration Web React aujourd'hui

La documentation montre une balise de script asynchrone unique placée dans index.html ou le fichier de montage du framework. Au chargement, il :

• Lit les paramètres UTM et les jetons Google Ads ValueTrack depuis l'URL
• Scanne le DOM pour construire une carte des éléments traduisibles et testables
• Stocke un ID visiteur dans localStorage pour la continuité entre les sessions
• Réécrit les nœuds texte de manière synchrone avant le premier rendu (CLS = 0)
• Expose un éditeur de variantes qui met en évidence les régions modifiables dans le navigateur
• Exécute des scripts de fingerprinting de bots et met en file d'attente des rapports pour remboursement

Toutes ces étapes supposent l'existence de window, document, localStorage et d'événements de navigation standard.

Ce qui ne fonctionne pas dans React Native

• Pas de DOM : document.querySelectorAll et le remplacement de nœuds texte n'existent pas.
• Pas de localStorage : React Native fournit AsyncStorage avec une API asynchrone différente.
• Pas de navigation de navigateur : Les changements de route SPA (React Router) déclenchent un re-scan SeaText ; la navigation RN (React Navigation) émet des événements différents.
• Pas d'éditeur visuel : Le surligneur de variantes dans le navigateur ne peut pas s'attacher aux vues natives.
• Les signaux de bots diffèrent : Pas de mouvements de souris, précision des minuteurs différente, pas de surface de fingerprinting navigator.

Solutions de contournement utilisées par les équipes aujourd'hui

1. Web view pour les tunnels clés : Rendre les écrans de paiement, de landing page et d'articles dans une WebView qui charge la build Web React normale avec le snippet SeaText. Maintient une parité de fonctionnalités à 100 % pour ces écrans.
2. API de traduction headless : Envoyer les chaînes de texte au backend de SeaText (si exposé) et rendre les traductions renvoyées dans des composants natifs. On perd les tests A/B en temps réel et l'éditeur visuel.
3. Pont personnalisé : Réimplémenter la logique principale du snippet en TypeScript, se connecter aux événements de React Navigation, utiliser AsyncStorage et parcourir l'arbre des éléments React au lieu du DOM. Charge de maintenance élevée.

Choisissez Web React si…

• Vous avez besoin de l'éditeur visuel de variantes pour les marketeurs.
• La détection de bots et les rapports de remboursement de clics publicitaires sont une priorité.
• Vous voulez une intégration sans ingénierie (coller le snippet, c'est fini).
• Votre trafic est principalement web ou vous pouvez servir des web views pour les pages de destination payantes.

Choisissez React Native (avec web view) si…

• La présence sur l'App Store et les performances natives sont requises.
• Vous pouvez confiner les flux dépendants de SeaText (pages de destination payantes, paiement, centre d'aide) dans une web view.
• Vous acceptez que l'éditeur visuel et l'agent bot ne fonctionnent qu'à l'intérieur de cette web view.

Recommandation conditionnelle

Si plus de 80 % de votre trafic payant arrive sur des URL web, conservez l'intégration Web React et utilisez des liens profonds depuis les publicités vers ces URL. Si vous devez convertir le trafic payant à l'intérieur d'une application native, enveloppez les flux de destination et de paiement dans une web view avec le snippet standard. N'investissez pas dans un pont natif personnalisé tant que SeaText n'aura pas publié un SDK React Native officiel avec des API documentées pour la gestion des variantes, la traduction et la détection de bots.

Faits clés

Limites de cette comparaison

• Aucune documentation de SDK React Native public n'existe dans le pack source ; l'analyse suppose que le snippet web actuel est la seule intégration supportée.
• SeaText pourrait proposer des modules natifs en bêta privée non reflétés dans les documents publics.
• La performance d'un wrapper web view dépend de la version spécifique de React Native et du pont (JSI vs legacy).
• La tarification pour l'utilisation native vs web n'est pas divulguée dans le pack source.

Terminologie

• SPA : Single Page Application — Applications React, Vue, Angular qui réécrivent le DOM sans rechargement complet de page.
• ValueTrack : Système de paramètres Google Ads (ex: {keyword}) transmis dans l'URL de clic.
• CLS : Cumulative Layout Shift — Un Core Web Vital mesurant la stabilité visuelle.
• AsyncStorage : Magasin clé-valeur persistant de React Native, API asynchrone, non partagé avec le localStorage web.
• Web view : Un composant natif qui affiche une page web à l'intérieur de l'application (react-native-webview).

FAQ

Puis-je utiliser le même projet SeaText pour le web et React Native ?

Oui, si l'application React Native charge les mêmes pages dans une web view. L'ID visiteur reste dans le localStorage de la web view, donc la continuité entre les sessions ne fonctionne qu'à l'intérieur de la web view.

SeaText prévoit-il un SDK React Native officiel ?

La documentation publique et les articles de blog (S1, S4, S7) n'en mentionnent pas. Consultez la roadmap de SeaText ou contactez le service commercial pour un accès en bêta privée.

La traduction fonctionnera-t-elle si j'envoie des chaînes à une API au lieu d'utiliser le snippet ?

Le pack source décrit une réécriture du DOM côté client, pas une API de traduction autonome. Si une API existe, elle n'est pas documentée dans les sources fournies.

Comment transmettre les paramètres UTM d'un lien profond vers la web view ?

Analysez le lien profond dans le code natif, ajoutez les paramètres à l'URL de la web view, et le snippet les lira au chargement exactement comme sur le web.

Puis-je exécuter des tests A/B sur des composants natifs sans web view ?

Pas avec le snippet actuel. L'éditeur de variantes et le calcul automatique du gagnant nécessitent l'éditeur visuel basé sur le DOM et le moteur de test côté client.

Qu'en est-il de la détection de bots à l'intérieur d'une web view ?

La web view exécute un véritable moteur de navigateur, donc l'agent de protection contre les bots fonctionne normalement pour le trafic à l'intérieur de cette vue. Les écrans natifs en dehors de la web view ne sont pas protégés.

Y a-t-il une pénalité de performance pour l'approche web view ?

Le react-native-webview moderne avec pont JSI ajoute environ 20-50 ms au démarrage et partage le même moteur JS que la page web. Pour les flux de destination et de paiement, la pénalité est généralement acceptable.