WebView au quotidien : ce qui change dans le fonctionnement et la maintenance de l'application

La décision d'utiliser WebView est généralement prise au début du projet, lors d'une réunion où sont discutés le délai et le budget. Ce que presque personne ne discute lors de cette réunion, c'est ce qui va suivre : comment cette application se comportera au cours de la deuxième année, qui la maintiendra, comment elle se met à jour, ce qui se casse lorsque le système d'exploitation change.

C'est là que la théorie rencontre la réalité. Une application WebView qui semblait représenter une économie importante au lancement pourrait devenir un casse-tête opérationnel, ou continuer à être le meilleur choix, selon la manière dont l'équipe gère les opérations quotidiennes.

Ce texte s'adresse à ceux qui disposent déjà ou vont disposer d'une application basée sur WebView en cours d'exécution. Ce n'est pas une question de concept, mais de fonctionnement. De quels changements dans la routine de ceux qui entretiennent, soutiennent et font évoluer un produit comme celui-ci. Car c’est dans la vie de tous les jours, et non sur la diapositive de décision, que le choix se prouve.

L'avantage opérationnel que tout le monde cite

Commençons par le bon côté, qui est réel. Le plus gros avantage pratique de WebView apparaît justement dans le fonctionnement : la possibilité de mettre à jour le contenu et les corrections sans passer par le store.

Dans une application purement native, toute modification, même la correction d'un texte erroné, nécessite de générer une nouvelle version, de la soumettre au magasin pour examen, d'attendre l'approbation et d'espérer que les utilisateurs la mettent à jour. Ce cycle prend des jours et n’atteint jamais tout le monde immédiatement ; Il y aura toujours ceux qui s’en tiendront à une ancienne version.

Dans WebView, l'écran est une page Web. Vous le corrigez sur le serveur et la correction atteint tous les utilisateurs la prochaine fois qu'ils ouvriront cet écran. Pour les équipes qui ont besoin de réagir rapidement, de corriger une erreur, d’ajuster une campagne, de changer une règle métier, c’est de l’or opérationnel. C'est la différence entre éteindre un incendie en quelques heures ou en une semaine.

La thèse : WebView échange le coût de lancement contre le coût d'exploitation

Ma position, après avoir vu plusieurs produits mûrir, est que WebView n'élimine pas les coûts, mais les déplace au fil du temps. Vous payez moins pour le lancement et, en retour, vous accordez une attention continue au fonctionnement.

Ce n'est pas un défaut. C'est la nature du choix. Le problème est que l'équipe traite WebView comme "nous l'avons fait et c'est tout", comme s'il s'agissait d'une application native que vous publiez et oubliez. Ce n'est pas. Une application WebView dépend d'une infrastructure Web vivante, de serveurs, de pages, de performances et de sécurité, qui nécessitent des soins permanents.

Ceux qui comprennent cela planifient l’opération dès le début. Ceux qui ne comprennent pas découvrent, au pire moment, que l’application qui était « bon marché » avait en réalité un coût récurrent que personne n’avait budgétisé.

Quels changements dans la routine de maintenance

Vous commencez à entretenir deux mondes

Une application native a un cycle de maintenance. Une application dans WebView en a deux : le conteneur natif (le shell qui va au magasin) et le contenu Web (les pages qu'il affiche). Ils évoluent à des rythmes différents et se cassent pour différentes raisons.

Cela signifie que votre équipe a besoin de compétences sur les deux fronts, ou d'une division claire entre qui s'occupe de quoi. Lorsque les connaissances sont concentrées entre les mains d'une seule personne qui comprend « la magie de la façon dont l'application communique avec le Web », vous êtes confronté à un point d'échec unique qui attend de se produire.

Le navigateur intégré vieillit également

Un détail qui surprend de nombreuses équipes : le composant WebView fait partie du système d’exploitation et évolue avec lui. Une mise à jour Android ou iOS peut modifier subtilement le rendu de vos pages. Quelque chose qui fonctionnait parfaitement commence à se comporter différemment sans que personne ne touche au code.

Par conséquent, la maintenance d’une application dans WebView nécessite des tests réguliers sur les versions actuelles des systèmes, et non une seule fois au lancement. Un fonctionnement sain implique de surveiller ce que les plateformes annoncent et de valider avant que le changement n'atteigne l'utilisateur.

La performance est une question de maintenance, pas de configuration

La fluidité d'une application WebView dépend directement du poids des pages qu'elle charge. Au fil du temps, il est naturel que les pages accumulent du code, des bibliothèques et des fonctionnalités, et deviennent plus lentes. Ce qui était acceptable au lancement peut se dégrader de mois en mois sans que personne ne s'en aperçoive, jusqu'à ce que l'utilisateur s'en plaigne.

Maintenir les performances devient alors une routine : surveiller les temps de chargement, surveiller la croissance des pages, optimiser régulièrement. Au Brésil, où de nombreuses personnes utilisent des appareils intermédiaires et des réseaux instables, ce soin est ce qui différencie une application utilisable d'une application qui plante là où cela compte le plus.

Le support utilisateur est différent

Lorsque quelque chose ne va pas dans une application native, le problème vient généralement de la version installée. Dans WebView, le problème peut provenir du shell, de la page, du serveur, de la connexion de l'utilisateur ou de la version du système de l'utilisateur. Le diagnostic comporte plusieurs niveaux.

Cela change le travail de ceux qui apportent leur soutien. Avoir un bon enregistrement des erreurs qui distingue l'endroit où la panne s'est produite est ce qui rend le diagnostic viable, car « l'application ne se charge pas » peut signifier des choses très différentes. Sans cette visibilité, l’équipe doit deviner et l’utilisateur doit attendre.

D'un autre côté, il y a un soulagement opérationnel : lorsque le problème concerne le contenu Web, vous le corrigez une fois et le résolvez pour tout le monde, sans dépendre de la mise à jour de l'utilisateur. La possibilité d’effectuer des corrections de manière centralisée, sur le serveur, est l’un des plus grands avantages du modèle en matière d’assistance quotidienne.

La sécurité au quotidien, pas seulement dans le projet

Étant donné que WebView charge du contenu Web, il hérite des problèmes de sécurité du Web, et ces problèmes sont permanents et non ponctuels. Bibliothèques qui vieillissent et acquièrent des failles connues, des certificats qui expirent, des configurations qui doivent suivre les meilleures pratiques : tout cela est une maintenance récurrente.

Pour les applications qui gèrent les données des utilisateurs ou des citoyens, cela est directement lié à LGPD et à la continuité du service. Une page compromise ou une dépendance obsolète n'est pas un problème de « site », c'est un problème d'application, avec les mêmes conséquences juridiques et de confiance. Traiter la sécurité de la couche Web comme une routine opérationnelle fait partie du prix à payer pour maintenir une WebView.

Les pièges de l'opération

Le piège le plus courant est celui de l’abandon de l’application à l’intérieur. De l'extérieur, il est toujours dans le magasin, il semble vivant. À l’intérieur, les pages qu’il charge n’ont pas retenu l’attention depuis des mois, les performances se sont dégradées, les dépendances ont vieilli. L'application "existe", mais le fonctionnement s'est arrêté, et cela devient un risque silencieux.

Un autre piège est de ne pas budgétiser l'opération. Le projet avait de l'argent pour construire, mais personne ne le réservait à l'entretien. Étant donné que WebView déplace les coûts vers l'exploitation, un produit sans budget de maintenance est voué à pourrir plus rapidement qu'une application native équivalente.

Le troisième est le manque de propriétaire. Lorsqu’il n’y a pas de clarté quant à savoir qui est responsable de la couche Web de l’application, chaque partie suppose que l’autre s’en charge. Le shell est « l'équipe mobile », la page est « l'équipe web », et la frontière entre les deux est orpheline, exactement là où apparaissent le plus de problèmes.

WebView est un engagement à long terme, pas un raccourci

La phrase à retenir : WebView n’est pas une décision que vous prenez une seule fois. C'est un engagement opérationnel que vous renouvelez chaque mois. Les économies de lancement ne sont réalisées que si l'opération est prise au sérieux par la suite.

Bien exploitée, une application WebView offre une agilité qu'une application purement native ne possède pas, des corrections immédiates, un contenu toujours à jour, un cycle d'évolution rapide. Mal exploité, il devient un produit tiède et fragile qui coûte en réputation ce qu'il a économisé en développement. La technologie est la même ; Ce qui change, c'est la discipline de ceux qui la maintiennent.

Si vous exploitez une application dans WebView et estimez que la maintenance est devenue réactive, ne changeant que lorsqu'elle tombe en panne, cela vaut la peine de structurer cette routine avant que le coût n'apparaisse d'un seul coup. J'ai d'autres textes sur le blog sur la maintenance logicielle, le mobile et le fonctionnement des produits, et je suis disponible pour échanger avec ceux qui maintiennent des produits comme celui-ci au quotidien.