Applications web monopages, avantages et inconvénients

Ces applications reposent essentiellement sur JavaScript qui a la possibilité d’afficher l’interface utilisateur, d’exécuter la logique applicative et de communiquer avec un serveur Web. Leur popularité récente est conjointe à celle des frameworks Javascript (AngularJS, Ember.js, Meteor.js, React, Vue.js, etc.) qui permettent de les concevoir avec une plus grande facilité que s’il fallait tout coder de A à Z. D’autres outils peuvent aussi être employés, comme Google Web Toolkit qui permet de développer l’application en Java, le compilateur croisé GWT traduisant le code en JavaScript.

Les requêtes des AWM vers le serveur sont soit des données structurées (XML/JSON) ou des portions de code HTML à injecter dans le DOM. Le serveur est déchargé de la tâche de bâtir des vues, tout est réalisé par le client.

Si le développement d’une AWM peut parfois paraître à certains la solution simple et rapide, faire une bonne application web monopage, qui soit pleinement satisfaisante pour l’utilisateur, s’avère souvent complexe et nécessite d’éviter certains écueils. En voici les principaux :

Navigation web ruinée

C’est le problème le plus fréquent, rencontré avec trop d’AWM conçues peu soigneusement. L’utilisateur a l’impression de changer de page, mais l’URL demeure fixe et l’historique du navigateur est ruiné. S’il utilise la fonction “page précédente” du navigateur, soit il ne se passe rien, soit il se retrouve à son grand étonnement sur un site précédemment consulté. Dans ce dernier cas, si cette manœuvre entraîne la perte de données déjà saisies, ou du point de parcours où il se trouvait, l’utilisateur pestera certainement et à raison après les concepteurs quand il reviendra sur l’application. Ce problème d’utilisabilité n’est pourtant pas une fatalité, car il existe plusieurs techniques fiables pour créer un pseudo-historique qui soit fonctionnel dans les navigateurs. Mais cela demande bien sûr des efforts. Et il ne faut pas oublier de gérer l’événement beforeunload en cas d’entrée de données par l’utilisateur afin de l’avertir du risque de données perdues.

SEO problématique

L’optimisation pour les moteurs de recherche est en partie le corollaire de la question précédente, les AWM ne fonctionnent pas comme un site traditionnel. Si rien n’a été spécifiquement prévu pour eux, les robots d’indexation des moteurs de recherche perdront invariablement leur latin face à une AWM. Les robots ne sont pas conçus pour exécuter du JavaScript et de tenter de comprendre ce qui se passe. Si le référencement est un enjeu capital, il est sans doute préférable de ne pas avoir recours à une AWM, ou seulement partiellement. Une solution est d’avoir, juste pour les robots, des pages HTML qui font miroir des pseudo-pages de l’application, mais ce n’est pas très élégant et cela occasionne parfois des problèmes de maintenance.

Accessibilité compromise

Force est de constater que la quasi-totalité des applications monopages que l’on croise sont médiocrement accessibles ou pas du tout accessibles. C’est dommage, mais il faut bien se rendre à l’évidence : concevoir une AWM en respectant tous les canons de l’accessibilité est tout un défi. Cela dit, il faut bien comprendre que bien des efforts portés sur l’accessibilité, même minimaux — du code HTML sémantique valide bien construit et un historique de navigation par exemple — ont des bénéfices sur le SEO.

Statistiques ardues

La plupart des outils de statistiques, comme Google Analytics, reposent sur le mécanisme du chargement d’une page complète. Ils ne peuvent pas enregistrer l’affichage d’une pseudo-page générée par une AWM. L’application refond en effet son affichage en réponse à des actions sans demander au serveur d’aller chercher un nouveau HTML. Vous ignorez donc ce que vos utilisateurs font, l’exécution étant confinée dans leur navigateur, à moins de développer vous-même des fonctions permettant de le traquer au sein de votre application, c’est à dire de faire en sorte que le serveur soit informé et enregistre l’état de l’application à des points clés. Les classiques outils de monitorage de la performance ne fonctionneront pas non plus.

Temps de chargement

La nécessité de charger des gros volumes de code JavaScript et une bonne dose de déclarations CSS au préalable, avant que l’utilisateur puisse interagir avec l’application, a forcément des impacts. Que l’utilisateur puisse penser que le serveur est simplement en panne et qu’il passe à autre chose n’étant pas le moindre (les développeurs ont généralement d’excellentes connexions à Internet, ce qui n’est pas toujours le cas pour les utilisateurs). Un travail d’optimisation du code à charger doit être fait si l’application est trop longue à charger ; différentes stratégies peuvent être mises en œuvre. Il faut aussi se poser des questions telles que “Est-ce que j’ai besoin d’inclure un framework CSS aussi lourd ? Ne pourrais-je pas en utiliser un plus léger, voire me passer de framework ?”. Etc. Dans un même registre, à l’intérieur de l’app, il peut être important de prévoir si nécessaire une indication visuelle de chargement entre les pseudo-pages pour que l’utilisateur soit incité à patienter et éviter qu’il appuie sur “Actualiser/Recharger”.

Pour conclure

Le choix de l’application web monopage relève parfois de la fausse bonne idée. Si vous avez toutefois de bonnes raisons de faire un tel choix, obtenir un résultat de qualité demandera nécessairement du temps, des compétences, de bonnes pratiques et des moyens. Si vous développez une AWM, privilégiez des frameworks vraiment conçus pour cet usage, comme Ember.js par exemple, qui facilitent le développement en offrant des moyens de contourner certains des écueils décrits ci-dessus.

S’il s’agit de concevoir juste un site web, l’idée de l’encapsuler dans une AWM n’est pas toujours très judicieuse (SEO, accessibilité, navigation, statistiques, etc.). Cette tactique n’est pas sans faire penser aux sites réalisés en Flash il y a une vingtaine d’années (avec des problèmes similaires comme le temps de chargement, le référencement, l’ergonomie, etc.). À voir certains exemples “créatifs”, on se rend compte que des designers ont réussi à recréer tous les problèmes du site Flash avec des technologies modernes — “Oui, mais c’est joli, ça bouge, c’est interactif, c’est une expérience riche.”

Les meilleurs cas d’utilisation d'une SPA sont ceux où l’application, tout en étant physiquement sur le web, n’a pas de nécessité intrinsèque à “faire partie du web”. Elles sont aussi une bonne solution si vous avez besoin d’un fonctionnement hors-ligne, ce qu’un site web ne peut offrir. Elles peuvent servir à créer des interfaces plus modernes et fonctionnelles pour un système hérité, ou des tableaux de contrôle pour des appareils. Un de leurs atouts est d’être multiplateforme par défaut (Windows, Linux, OSX, Android, iOS…).

Les AWM sont aussi bien adaptées aux applications complexes qui traitent beaucoup de données en interaction avec l’utilisateur. Pensez au client web de Gmail par exemple.

Retenons que les applications web monopages ne sont pas la solution à tout, mais sont un bon choix dans certains cas de figure. Comme pour toute technologie, elles ont des avantages, des inconvénients et des défis à relever qui leur sont propres.