Toujours dans la ligne droite des évolutions majeures de ces 30 dernières années, les applications sont passées de ce que l’on a coutume d’appeler un « client lourd », une application Windows accédant directement aux données, à son pendant au sein d’un navigateur appelé « client léger », puis « client riche » au cours de son évolution.
Ce passage est désormais acté pour la grande majorité des utilisateurs, et les derniers convaincus en date sont ceux qui ont tenté d’utiliser un client lourd sur une connexion VPN résidentielle durant ces dernières semaines de télétravail contraint.
Quelles ont été les étapes de cette évolution, tant en termes d’architecture que d’expérience utilisateur au sens large ?
L’évolution de l’architecture
J’ai déjà eu l’occasion de parler des bases de données et de leur évolution ; mais ici la différence est plus radicale.
Une application Windows accède directement au serveur de base de données dans l’immense majorité des cas. Dans une première approche c’est effectivement plus efficient : le flux de données est réduit au minimum, et un serveur applicatif intermédiaire n’est pas nécessaire.
Mais en fait quand on y réfléchit, les problèmes sont ailleurs.
En effet il faut tout d’abord considérer l’aspect administration : installation de l’application ,maintenance de ses versions, pilotes de base de données, qui ont à terme un impact lourd sur le coût de l’application, multiplié par le nombre de clients.
D’un point de vue technique, la connectivité entre les différents postes et la base de données n’est pas forcement idéale et dans des conditions de latence réseau dégradées, les performances peuvent devenir apocalyptiques.
À l’opposé, dans le cas d’une application Web, le serveur applicatif est non seulement la seule machine à maintenir, mais, positionné intelligemment au regard du serveur de base de données, il bénéficiera d’échanges rapides quelle que soit la latence du poste client.
Revenons-en aux flux réseaux, là où historiquement le Web péchait. C’est l’occasion de parler de :
Client léger ou client riche ?
Lorsque les applications Web sont apparues, la partie client se contentait des bases du langage HTML. Cela impliquait des saisies simples, des allers-retours serveur pour toutes les validations et un travail intensif du serveur de mise en forme du flux.
C’était à la fois frustrant pour l’utilisateur et lourd pour la charge du serveur, qui je le rappelle , supporte les demandes de TOUS les clients.
On a donc cherché rapidement à enrichir les possibilités du client : sont apparues les technologies Java Runtime Engine, Adobe Flash ou Microsoft Silverlight, plugins des navigateurs destinés à améliorer l’expérience utilisateur et soulager le serveur de certaines tâches.
Le défaut de cette génération de client riche, outre le fait de devoir développer spécifiquement pour chacun d’entre eux, était de devoir installer ou maintenir l’extension sur les navigateurs clients, sans compter les nombreux trous de sécurité que ces technologies créaient et qui ont fini par provoquer leur rejet par les navigateurs.
Cette méthode a désormais disparu, rejointe par les évolutions tant d’HTML que par l’existence de la technologie performante et généralisée qu’est JavaScript, soutenue par des bibliothèques comme jQuery ou Bootstrap ou encore React.
Cet ensemble amène non seulement les interfaces Web au même niveau technique que les interfaces Windows, mais il leur concède aussi la même réactivité.
Dernier point : au travers des bibliothèques Javascript, le flux peut se réduire de façon importante en demandant au serveur des flux Json plutôt que HTML
Il reste le point principal, qui a longtemps été un frein, à savoir l’ergonomie de saisie et de navigation, mais c’est un sujet qui mérite à lui seul un billet.
Olivier Piochaud, PDG d’Apsynet
