Discussion :

[Michael Guilloux]

Progressive Web Apps : une nouvelle approche de Google pour créer des applications web
avec une expérience d’applications natives

À quoi pourraient ressembler les applications web de demain ? Si vous vous êtes déjà posé cette question, une réponse possible pourrait se trouver dans un nouveau concept sur lequel la firme de Mountain View travaille depuis un certain temps. Avec un trafic web mobile en pleine croissance, les applications web ciblent de plus en plus les dispositifs mobiles. Mais dans ce domaine, il y a un débat qui est né et qui demeure toujours : que choisir entre une application web et une application native ?

Si le web offre de nombreux avantages, il a certainement beaucoup à envier aux applications natives en ce qui concerne l’expérience utilisateur et bien d’autres fonctionnalités. Commençons par présenter la différence entre une application web mobile et une application native. Une application native est développée spécifiquement pour une plateforme (Android, iOS, etc.), avec un langage spécifique, est installable et est distribuée à partir d’un magasin d’applications. À l’opposé, une application web (Web app) est une application mobile développée avec les technologies du web (HTML, CSS, JS) et qui peut être exécutée sur tous les systèmes mobiles via un simple navigateur.

Ces deux concepts présentent à la fois des avantages et des inconvénients, c’est ce qui justifie leur coexistence. Une application native a de nombreux avantages. Accessible hors connexion, elle offre également une meilleure expérience utilisateur (plus rapide et fluide, mode plein écran, accès aux fonctionnalités du téléphone, notifications Push, etc.). Elle est également mieux référencée à cause des téléchargements sur les plateformes d’applications. Toutefois, le coût de développement est important si le développeur doit encore concevoir une version pour chaque plateforme cible. L’utilisateur doit en plus gérer les mises à jour manuellement à chaque nouvelle version.

Par contre, une Web app a un coût de développement plus faible avec un seul code pour les différentes plateformes et est compatible avec tous les navigateurs. Les mises à jour sont en plus gérées de manière transparente. Le hic, c’est qu’elle n’est pas accessible hors connexion (sauf avec mise cache) et ne peut accéder aux fonctionnalités du téléphone.

Pour essayer de concilier les deux modèles, les applications hybrides sont nées en combinant quelques éléments des applications web et des applications natives, mais Google veut quelque chose de beaucoup plus évolué. Le concept de Mountain View baptisé « Progressive Web Apps » a été présenté lors du récent Chrome Dev Summit 2015. Selon la société, les progressive web apps (PWA) « combinent le meilleur du web et le meilleur des applications ». Elles utilisent les fonctionnalités modernes du web pour offrir une expérience utilisateur de type application.

Les PWA exploitent plusieurs technologies clés et reposent essentiellement sur une combinaison de l’architecture « application shell » et des service workers. Un service worker est un script qui est exécuté dans le navigateur et qui permet de supporter des expériences hors ligne. Les service workers apportent également des gains de performance grâce à une mise en cache hors ligne intelligente et le chargement instantané pour des visites répétées sur votre site ou application web. Ils incluent d’autres fonctionnalités comme les notifications Push avec la capacité d’intercepter et de traiter les requêtes de réseau.

En ce qui concerne l’architecture application shell, il s’agit d’une architecture d’application web moderne qui tire parti d’un service worker pour mettre en cache la « coque » de votre application hors ligne et remplir son contenu en utilisant JS, quand la coque est chargée (comme illustrée dans l’image suivante). La coque (shell en anglais) d’une application fait allusion au code HTML, CSS et JavaScript minimal qui alimente l’interface utilisateur.

Entre autres caractéristiques des progressive web apps, on peut noter qu’elles sont :

• progressives : elles sont construites avec l'amélioration progressive comme un principe de base et fonctionnent pour chaque utilisateur, quel que soit le choix du navigateur ;
• responsives : s’adaptent à tout facteur de forme à savoir bureau, mobile, tablette, etc. ;
• indépendantes de la connectivité : capables de fonctionner hors ligne ou sur les réseaux de faible qualité grâce aux service workers ;
• toujours à jour grâce aux service workers ;
• sûres : servies via HTTPS pour prévenir l’espionnage et assurer que le contenu n’a pas été altéré ;
• elles offrent une expérience avec des interactions de style application et de la navigation ;
• elles peuvent être partagées facilement via une URL ;
• elles disposent d’une icône qui peut être affichée sur l’écran d’accueil.

Plus de détails techniques sont disponibles sur la page de Google dédiée aux PWA.

Sources : Page Progressive Web Apps, Instant Loading Web Apps with An Application Shell Architecture

Et vous ?

Sur quel type d'applications mobiles votre choix se porte-t-il : web app, natif ou hybride ? Et pourquoi ?
Que pensez-vous des PWA ? Pourraient-elles concilier les deux mondes d'applications web et native ?
Quels sont les avantages et limites que vous trouvez à ce nouveau concept ?


Voir aussi

Forum Mobiles
Forum général Conception Web

[scandinave]

Bonjour,
Je ne voit pas bien où est la nouveauté. Le hors ligne, ça fait un baille que ça existe maintenant pour les applis HTML. Certes il faut se donner un peu de mal mais ça fonctionnement plutôt bien. L'approche de Google tel que décrit là n'a rien de révolutionnaire. Au mieux google cherche à standardisé en lui donnant un nom, un ensemble de techniques et procédures qui existent déjà.

• progressives : elles sont construites avec l'amélioration progressive comme un principe de base et fonctionnent pour chaque utilisateur, quel que soit le choix du navigateur ; // Ça s'appelle du mobile first
• responsives : s’adaptent à tout facteur de forme à savoir bureau, mobile, tablette, etc. ; // Existe déjà aussi => media query - cf bootstrap par exemple.
• indépendantes de la connectivité : capables de fonctionner hors ligne ou sur les réseaux de faible qualité grâce aux service workers ; // Ça, c'est nouveau mais pas encore implémenté par les navigateur
• toujours à jour grâce aux service workers ;
• sûres : servies via HTTPS pour prévenir l’espionnage et assurer que le contenu n’a pas été altéré ; // Existe aussi
• elles offrent une expérience avec des interactions de style application et de la navigation ; // MetroUI CSS ou MaterializeCSS par exemple
• elles peuvent être partagées facilement via une URL ; // Principe d'un site web
• elles disposent d’une icône qui peut être affichée sur l’écran d’accueil. // On peut déjà le faire, j'ai ai une pour développez sur mon Android phone

Après je ne doute pas des intentions de Google deproposer un pattern de conception simple pour tout les développeurs souhaitant ne réaliser qu'une seule application web pour toutes les plateformes

[Neckara]

Bonjour,

indépendantes de la connectivité : capables de fonctionner hors ligne ou sur les réseaux de faible qualité grâce aux service workers ; // Ça, c'est nouveau mais pas encore implémenté par les navigateur

J'ai peut-être mal compris, mais n'est-ce pas une fonctionnalité de l'HTML5 ?

[scandinave]

Pour le Hors ligne oui, je parle des services worker qui contrairement au Shared Worker ne sont pas encore un standard.

[hotcryx]

Concernant "l'application cache" j'avais lu quelque-part (pas sur W3School) que cette fonctionnalité pouvait stopper à tout moment par l'installation d'une nouvelle du browser et que par conséquent il ne fallait plus l'employer. Vrai ou faux finalement???

[DMike92]

Un nouveau moyen de développer des virus ?

[randriano]

La question "en quoi c'est nouveau" se pose bien

On a toujours entendu "web app" mais "progressive" qu'est-ce que cela voudrait dire? C'est peut-être ça qui rend cela une nouveauté!?

[CM-63]

Bonjour,

Moi je me tate, je fais du progressive ou pas? Mon projet : une appli Mobile avec back-office web. L'utilisateur de l'appli aura un compte sur le back-office, et il faut que l'appli puisse travailler en local, et qu'elle puisse de temps en temps se connecter sur le compte du back-office, afin de synchroniser : actualiser sur le back-office ce que la personne aura fait en local sur son appli. Si l'appli fait du stockage en local, je ne veux pas qu'elle réplique toute la BDD du back-office, je veux qu'elle ne stocke que les données relatives à l'utilisateur local.
Je fais du progressive ou pas? J'ai un peu lu la doc, et je vois mal comment un service worker standard pourrait stocker en local juste ce qu'il faut pour assurer ce fonctionnement. J'ai l'impression que ça ne fait que de la bufferisation d'IHM mais pas vraiment de stockage d'infos complexes à synchroniser plus tard sur le back-office.
Vous connaissez des docs sérieuses sur le sujet?

[CM-63]

La question "en quoi c'est nouveau" se pose bien

On a toujours entendu "web app" mais "progressive" qu'est-ce que cela voudrait dire? C'est peut-être ça qui rend cela une nouveauté!?

Si j'ai bien compis, ça veut dire que l'appli peut travailler en local si le web n'est pas disponible et se synchroniser avec le serveur lorsque le web devient disponible. Grâce au service worker. Mais sion, les autres critères de la liste, effectivement, c'est déjà dans "web app", comme la portabilité, le fait qu'on n'installe pas (ou rapidement), qu'on ne passe pas par des stores, etc.

En fait , l'"installation" se résume à mettre un lien (lanceur) sur le bureau de ton Mobile, qui va lancer le navigateur avec comme argument l'url de cette appli web, qui est en fait un site. Mais ça, effectivement, c'est déjà comme ça pour les applis web normales, si en plus elle est progressive, il faudra que le navigateur utilisé ait la fonctionnalité de service worker. Ce qui n'est toujours pas le cas du navigateur par défaut sous Android. Donc déjà, tu es obligé d'expliquer aux gens qu'il faut qu'ils passent par un navigateur qui le fait, comme Firefox (mais je viens d'essayer et ça marche pas, à moins que j'ai loupé quelque chose).

[Almopine]

Bonjour,

Moi je me tate, je fais du progressive ou pas? Mon projet : une appli Mobile avec back-office web. L'utilisateur de l'appli aura un compte sur le back-office, et il faut que l'appli puisse travailler en local, et qu'elle puisse de temps en temps se connecter sur le compte du back-office, afin de synchroniser : actualiser sur le back-office ce que la personne aura fait en local sur son appli. Si l'appli fait du stockage en local, je ne veux pas qu'elle réplique toute la BDD du back-office, je veux qu'elle ne stocke que les données relatives à l'utilisateur local.
Je fais du progressive ou pas? J'ai un peu lu la doc, et je vois mal comment un service worker standard pourrait stocker en local juste ce qu'il faut pour assurer ce fonctionnement. J'ai l'impression que ça ne fait que de la bufferisation d'IHM mais pas vraiment de stockage d'infos complexes à synchroniser plus tard sur le back-office.
Vous connaissez des docs sérieuses sur le sujet?

Non c'est une technologie sans intérêt, pour faire des sites web "ressemblant" à des applications mobiles.

Pour ce que tu veux passes par Cordova & Ionic qui permet de faire une application mobile en langage web. Tu peux aussi utiliser Azur pour ne pas t'embêter avec la synchronisation des données et le back-end ou firebase. ça reste très abordable en prix voir gratuit pour firebase.

Si tu es sur une application métier en entreprise, tu peux te renseigner sur Xamarin.

[CM-63]

Bonjour,

Merci pour les tuyaux. Ionic + Cordova, oui je suis en plein dedans, ça a l'air bien, mais le temps que je maîtrise. En fait je souhaiterais que l'appli mobile fasse des requêtes au back-office, mais en termes applicatifs, genre je veux savoir combien l'utilisateur a de documents crées, et je ne veux pas que l'appli attaque directement la base de données du back-office . Il faut que je vois comment faire pour créer une API dans le back-office, et alors je pourrais l'interroger (comme on interroge un compte Facebook grâce à l'API Facebook). Ça je ne maîtrise pas.

Mais sinon, oui, je vais faire les deux en appli web html5 : le back-office et l'appli web. Et je n'utilise pas le progressive, je fais deux applis distinctes.

Azur? Tu veux dire Windows Azur? Moi tout ce qui est M$ ou W$ j'évite. Firebase, je ne connais pas, on peut faire des back-office? Je vais me renseigner.

Merci de ton aide.