PWA ou apps en natif, vrai débat ou faux problème pour la médiation numérique ?

S’intéresser à la technologie lorsque l’on fait de la médiation est toujours intéressant dès lors que l’expérience des visiteurs est potentiellement impactée. Et c’est le cas ici, au delà des termes techniques abscons et du jargon de développeur, qu’il faut prendre le temps de comprendre un peu.

Il y a aujourd’hui deux voies principales pour développer une application mobile : soit on décide de coder en langage dit « natif » , et d’adopter Swift pour iOS et Java pour Android, soit on part sur des technologies web (html, CSS, Javascript) selon une approche dite de « Progressive Web App » ou PWA, auquel cas on recourt à des frameworks comme React ou Angular, par exemple. Si les termes vous effraient, concentrez-vous sur leurs implications : développer en « natif » se traduit par une livraison au commanditaire d’une application, qui nécessitera donc une publication sur un store (App-store pour iOS, Google Play store pour Android) et que l’utilisateur final téléchargera sur son smartphone ou sa tablette. Développer en PWA en revanche, puisque il s’agit de technologies web, conduit à livrer un site web prenant la forme d’une application. L’utilisateur final, dans ce cas, ne passe par un store et ne télécharge rien : il ouvre son navigateur et consulte le service en ligne.

Première question à se poser : une application PWA a-t-elle les mêmes fonctionnalités et les mêmes performances qu’une application native (sous-entendu : développer en natif devrait être forcément mieux puisqu’on utilise le langage propre à l’OS de la machine qu’on utilise) ?

Réponse : oui et non. Globalement oui : tant que les fonctionnalités que vous attendez ne sont pas trop sophistiquées (on va y revenir), une application en PWA se traduira, pour un visiteur lambda, par une solution visuellement et pratiquement indifférenciable d’une application téléchargeable. Spécifiquement non : dès lors que les fonctionnalités attendues sortent du champ classique et nécessitent d’aller activer des possibilités un peu plus « hardwares » (liées au fonctionnement matériel intrinsèque du terminal), le natif sera plus pertinent. Par exemple : exploiter 100% des possibilités proposées par l’ArKit d’Apple ou l’ArCore de Google n’est à l’heure actuelle pas envisageable en PWA (sauf preuve du contraire : développeurs créatifs manifestez-vous auprès de moi !). Pour être encore plus précis dans mes exemples, aller chercher à exploiter le LIDAR de l’iPad Pro en PWA me semble relever de la gageure improbable, à date du présent article…

Deuxième question qui vous vient à l’esprit j’en suis sûr : vu que PWA contient le mot « web », cela signifie-t-il que la solution sera utilisable uniquement en mode connecté ?

Réponse : non. Le PWA offre la possibilité d’embarquer des contenus au démarrage de l’application, donc à l’ouverture du navigateur. On se retrouve donc dans un cas d’usage presque identique à celui d’une app native : après un premier téléchargement de contenus, le client final n’a plus besoin de connexion.

Voici un exemple en vidéo, il s’agit de la solution Geed déployée par la société Livdeo pour le Musée des Beaux-arts et d’Archéologie de Besançon : http://tiny.cc/yc5rsz.

Troisième question : dans ce cas, et si on reste sur des fonctionnalités multimédias classiques, pourquoi choisir une solution plutôt qu’une autre ? Est-ce que le PWA est moins cher ?

Réponse : le PWA doit être moins cher. En effet, le développement qu’il implique est unique. Dans le cas du natif, en revanche, chaque OS nécessite sa variante. Ce handicap est limité par le fait qu’il est possible de recourir à des plateformes de génération d’applications natives, comme Xamarin, ou plus habituellement Unity ou Unreal. Cela étant dit, produire en natif conduit inévitablement à devoir gérer une maintenance double dont le coût devra bien être répercuté au client et compris par lui. Mais cet argument du coût ne suffit pas complètement à trancher entre les deux approches…

C’est pourquoi je propose un autre angle, reposant sur un constat basique : le PWA est plus simple à gérer à long terme et plus ouvert.

Plus simple à gérer à long terme parce que si vous êtes le commanditaire nous n’avez pas à vous préoccuper de gérer des comptes développeurs chez Apple et Google. Vous n’avez pas non plus à faire souffrir un développeur en maintenance continuelle en raison des milliers de terminaux et des multiples versions d’Android auxquelles le code n’est évidemment pas toujours parfaitement adapté, et aussi en raison des mises à jour impératives d’Apple qui arrivent sans crier gare et qui nécessitent des adaptations en urgence sous peine d’éviction du store. Certes, il y aura quand même de la maintenance corrective et adaptative car certains traîneront des versions anciennes de navigateurs ou utiliseront des solutions exotiques pour aller sur le web, mais globalement, ça sera plus facile.

Plus ouvert : encore une fois c’est du web. Donc vous êtes chez vous. C’est votre url, votre serveur. Vous faites ce que vous voulez. Par exemple, vous réservez l’usage de l’application PWA au fait d’être présent sur votre site sans que vos visiteurs puisse télécharger quoi que ce soit avant. Ou vous prévoyez des hybridations vers vos autres sites web, votre CRM, vos comptes sociaux… Ou encore, vous construisez un modèle économique Bien entendu, il ne s’agit pas d’en profiter pour faire n’importe quoi (le monde fermé des applications natives a quand même pour avantage d’avoir uniformisé les pratiques et d’être sous contrôle qualité constant d’Apple et Google), mais vous obtenez de la souplesse, pour ne pas dire de la liberté.

Deux bémols cependant pour ne pas conclure hâtivement et pour ne surtout pas donner l’impression que j’enterre un peu vite le natif vs le PWA :

• La liberté offerte par le PWA ne s’use que si l’on ne s’en sert pas, ou mal : si votre stratégie digitale n’est pas claire (objectifs de publics et de médiation pas assez travaillés, discordance des moyens et des buts, mauvaise prise en compte des attentes et des comportements des publics…) et si votre culture interne de la médiation numérique est faible, vous ne verrez pas d’avantage à adopter les technos web.
• Si votre site ou votre musée est sous doté en infrastructure de connexion (wifi faible, disponible uniquement à l’accueil par exemple, ou couverture 4G limitée voire inexistante), vous n’irez pas bien loin en PWA et autant viser l’embarquement d’un maximum de contenus pour proposer  une expérience correcte. Dans ce cas, mieux vaut sans doute rester sur du natif. Avec un message au passage : occupez-vous vite de votre infrastructure…

En conclusion, le choix entre PWA ou solution native a de vraies implications à long terme et mérite une grande attention, surtout lorsqu’on réfléchit à une stratégie digitale globale portant autant sur l’expérience de médiation délivrée aux visiteurs, qu’à leur engagement numérique et au développement de l’attractivité de sa structure.

Et si vous n’êtes pas sûrs de vous, faites-vous accompagner 😉