WebView dans les applications : qu'est-ce que c'est et quand il est judicieux de l'utiliser

De nombreuses personnes ont utilisé une application qui, sans le savoir, était en réalité un site Web exécuté dans un shell. L'écran prend un peu plus de temps à charger, le défilement est légèrement différent et lorsque vous appuyez sur quelque chose, cet indicateur de chargement apparaît et ressemble à un navigateur. C'est WebView au travail, et il est présent dans plus d'applications que vous ne le pensez.

WebView est l’un des concepts les plus utiles et, en même temps, les plus mal compris du développement mobile. Bien utilisé, il permet d’économiser du temps et de l’argent et résout de vrais problèmes. Mal utilisé, il délivre une expérience tiède qui aliène l’utilisateur et ternit la perception du produit.

Ce texte est une introduction. Si vous êtes fondateur, chef de produit ou venez tout juste d'entrer dans le monde mobile et que vous avez entendu parler de WebView sans vraiment comprendre de quoi il s'agit, voici un aperçu : qu'est-ce que c'est, comment il fonctionne et, surtout, quand il est judicieux de l'utiliser.

Qu'est-ce qu'une WebView, en pratique

Une WebView est essentiellement un navigateur sans barre d'adresse, intégré dans une application. Il permet à l'application d'afficher du contenu Web, des pages HTML, des applications Web entières, comme s'il s'agissait d'écrans natifs.

Du point de vue de l'utilisateur, il n'y a souvent aucune différence visible : il ouvre l'application, navigue, l'utilise. En dessous, cependant, cet écran n’a pas été construit avec les composants natifs du système d’exploitation. Il s'agit d'une page Web rendue dans un conteneur.

Android et iOS proposent officiellement ce composant. En d’autres termes, WebView n’est pas un hack, c’est un outil légitime et largement pris en charge par les plateformes elles-mêmes. La question n’a jamais été « est-ce autorisé ? », mais plutôt « est-ce le bon choix dans ce cas ? ».

Pourquoi cette approche existe

La raison d'être de WebView est simple : la réutilisation. Si votre entreprise dispose déjà d’un site web ou d’une application web fonctionnel, l’afficher au sein d’une application évite de tout reconstruire à partir de zéro pour chaque plateforme.

Construire une application véritablement native signifie, en pratique, maintenir des bases de code distinctes pour Android et iOS, chacune avec son propre langage, ses propres équipes et ses propres cycles. C'est cher et prend du temps. WebView propose un raccourci : écrire l'interface une seule fois, dans les technologies web, et l'afficher n'importe où.

Ce raccourci a une réelle valeur, en particulier pour ceux qui ont besoin de mettre en place quelque chose rapidement, de valider une idée ou de maintenir un contenu qui change fréquemment. Mais, comme tout raccourci, il a un prix, et comprendre ce prix est ce qui différencie une bonne décision d’une décision naïve.

La thèse : WebView n'est ni bon ni mauvais, c'est un compromis

La question que j’entends souvent est « WebView est-il bon ou mauvais ? ». La question est fausse. WebView est un échange, et ce qui compte c'est de savoir ce que vous échangez.

Vous gagnez en vitesse de développement, en code partagé entre les plateformes et en facilité de mise à jour. Vous perdez, à des degrés divers, des performances, de la fluidité et un accès complet aux ressources de l'appareil. Dans certains produits, cet échange est excellent. Dans d’autres, c’est désastreux.

Ceux qui considèrent WebView comme une solution universelle, « faisons tout dans WebView pour économiser de l'argent », ont tendance à le regretter lorsque le produit se développe et que l'expérience tiède commence à coûter cher aux utilisateurs. Et quiconque le rejette par principe, "WebView est pour les amateurs", gaspille un outil qui résoudrait le problème avec élégance. La maturité technique, c'est savoir à quelle place appartient chaque approche.

Quand WebView a du sens

Il existe des scénarios dans lesquels WebView est le choix intelligent, et non une solution provisoire.

Lorsque le contenu change fréquemment, les conditions d'utilisation, les politiques, les pages d'aide, le centre d'actualités, cela n'a pas de sens de l'intégrer dans l'application et de devoir lancer une nouvelle version à chaque ajustement de texte. Dans WebView, vous modifiez la page et la modification apparaît immédiatement à tout le monde.

Lorsque vous disposez déjà d’une application Web mature et que vous souhaitez être présent rapidement en magasin, WebView vous permet d’atteindre le marché avec beaucoup moins d’investissement. Valider si une application en vaut la peine avant d’investir massivement, c’est une stratégie raisonnable.

Lorsque le budget et l’équipe sont limités et que l’alternative serait de ne pas avoir d’application du tout, un produit WebView bien conçu vaut mieux que rien. L’optimum est l’ennemi du possible dans de nombreux contextes réels.

Quand WebView gêne

D’un autre côté, il existe des situations où insister sur WebView est une erreur.

Les applications dont la proposition de valeur est l'expérience, la fluidité, les animations, la réponse instantanée au toucher, le sentiment de qualité, souffrent dans WebView. L'utilisateur n'est peut-être pas en mesure d'expliquer pourquoi, mais il trouve que « c'est bizarre ». Sur des marchés concurrentiels, cette différence subtile définit qui reste et qui part.

Les fonctionnalités fortement dépendantes du matériel, la caméra avec traitement en temps réel, les capteurs, l'utilisation intensive hors ligne, les intégrations spécifiques au système, rencontrent des frictions dans WebView. Il est possible de contourner une partie de ce problème, mais les efforts déployés pour le contourner annulent parfois les économies qui ont motivé le choix.

Et se pose la question des performances sur des appareils plus modestes. Au Brésil, où une grande partie de la base utilise des appareils intermédiaires, une interface web lourde peut rester bloquée là où coulerait une interface native. Choisir WebView sans penser au véritable appareil de votre utilisateur, c'est décider dans le noir.

Limites et pièges

Le piège le plus courant consiste à traiter la décision comme purement technique alors qu’il s’agit d’une décision de produit. La bonne question n’est pas « quelle technologie préférons-nous ? », mais « de quelle expérience notre utilisateur a-t-il besoin et combien sommes-nous prêts à payer pour cela ? ».

Un autre piège est le mensonge du « tout ou rien ». De nombreux produits bien conçus sont hybrides : des écrans natifs critiques, où l'expérience compte, et des écrans WebView secondaires, où la réutilisation est payante. Vous n’êtes pas obligé de choisir un camp pour la vie. Une bonne architecture se mélange en fonction de la valeur de chaque écran.

Il reste quand même un point de sécurité qui mérite attention dès le début : une WebView transporte du contenu web, et le contenu web porte en lui les préoccupations du web. Charger des pages à partir de sources non fiables ou exposer des fonctionnalités sensibles au contenu chargé ouvre des portes qu'une application purement native n'aurait pas. Ce n'est pas une raison pour éviter WebView, c'est une raison pour l'utiliser avec prudence.

Le bon choix est celui qui sert l'utilisateur

En fin de compte, WebView est un outil, et les outils n'ont pas de morale, ils ont une application. La question ne devrait jamais être de savoir si WebView est bon, mais s'il répond à ce que votre produit doit fournir, à votre budget et à votre utilisateur réel.

Ceux qui comprennent cela arrêtent de discuter de technologie sur la base d’une idéologie et commencent à décider en fonction du contexte. Parfois la réponse est native, parfois c'est WebView, souvent c'est un savant mélange des deux. La maturité, c'est choisir clairement, savoir exactement ce que vous gagnez et ce à quoi vous abandonnez.

Si vous décidez de l'architecture d'une application et que vous hésitez entre natif, hybride et WebView, cela vaut la peine d'en discuter avant de faire un choix qui vous pèsera pendant des années. J'ai d'autres textes sur le blog sur le développement mobile et les produits numériques, et j'aime aider ceux qui en sont à ce stade de la décision.