jeudi 3 novembre 2016

L'archivage sur le navigateur web : une technologie sous-estimée

Dans mon billet précédent je vous présentais funKTest, un applicatif web qui génère des codes de test Protractor, mais je ne vous ai pas parlé d'une de ses caractéristiques techniques, qui n'a rien à voir avec les tests : il ne possède pas de back-end, pas de côté serveur, pas de cloud. Les données produites par l'utilisateur restent sur sa machine, et plus précisément dans l'espace de stockage de son navigateur internet, et là uniquement. Une telle architecture mérite le détour d'une analyse, car elle pourrait bien répondre aux besoin des utilisateurs de rester propriétaires de leurs données.

Imaginez que toutes les données qui vous concernent sur Facebook soient stockées sur votre machine personnelle. Facebook ne ferait que se synchroniser sur les données que vous autoriseriez, stockées sur votre disque dur. A tout instant vous pourriez modifier vos données, ou les supprimer. Un rêve ? Techniquement non, alors on n'y échappera pas. Je vous propose donc ici de nous intéresser à ce genre d'architecture novatrice.

Le modèle SAAS

En matière d'applicatifs web la mode est au système SAAS (Service As A Software). Son fonctionnement simple est schématisé sur la figure 1.

Figure 1 : l'architecture SAAS typique

Dans un premier temps l'utilisateur télécharge un applicatif web, c'est à dire un mélange de HTML, de CSS et de Javascript, bref une page HTML. Il dispose alors d'un logiciel lui permettant d'accomplir des actions métier. Ce faisant il produit des données, qui sont stockées sur le serveur après avoir transité par le réseau.

Ce type d'architecture possède de nombreux avantages dont :

  • une gestion centralisée des données, permettant une vision unique et instantanée,
  • un développement unique, donc une mise à jour automatique des utilisateurs, sans problème de versioning
  • un accès simple, standardisé et rapide à l'applicatif, car tous les utilisateurs possèdent un navigateur internet

Mais elle présente aussi quelques inconvénients dont :

  • les données doivent être sécurisées, pendant leur passage par le réseau, mais aussi sur le serveur,
  • le serveur doit être une grosse machine s'il doit gérer de nombreux utilisateurs,
  • des bases de données complexes et à accès rapide doivent être utilisées sur le serveur,
  • ET SURTOUT : les utilisateurs n'aiment pas du tout laisser leurs données stratégiques sur un cloud

Ainsi du côté de l'offreur de service, le système SAAS est presque idéal, mais du point de vue utilisateur, il est risqué, et non confidentiel. C'est le défaut congénital de cette solution, qui empêche nombre d'utilisateurs de se lancer plus avant dans les clouds. En général ils acceptent de se faire tordre le bras si le service est utile, mais de toute façon ils ne laisseront que des données qu'ils estiment sans conséquence.

Pour convaincre l'utilisateur d'adopter un applicatif web, il faudrait lui garantir que ses données ne transiteront ni sur le réseau, ni sur aucun serveur, mais qu'elles resteront en local, sur la machine qui les a produites. Ce serait l'idéal de l'utilisateur … et c'est techniquement possible. Je vous propose d'expliquer ici comment faire.

Chaque navigateur web possède un espace de stockage

On sait qu'il existe des espaces de stockage sur un navigateur internet. Vous avez remarqué en effet que les cookies, les mots de passe et autres favoris sont sauvegardés, même si vous redémarrez votre machine. Ce qu'on sait moins c'est qu'il y a en plus deux espaces de stockages qui sont utilisables par les scripts Javascripts de toute page HTML. Il s'agit du « LocalStorage » et de la base de donnée NoSql « indexedDB ». Si le premier type de stockage ne dépasse pas 5Mo, le second est limité à a taille de votre disque dur.

Grâce à indexedDB il est possible de concevoir une application qui sauvegardera toutes les données utilisateur sur le navigateur qui les a produites, comme présenté sur la figure 2. C'est d'ailleurs l'architecture de funKTest.

Figure 2 : l'architecture SAAS à sauvegarde locale, utilisée par funKTest. Le « Local Storage » peut être le « localStorage » du navigateur, ou son indexedDB.

Actuellement on utilise en général l'indexedDB pour garantir un fonctionnement en mode déconnecté. C'est bien pratique, mais c'est le réduire à peu de chose. Je vous propose plutôt de le considérer comme une utilité fondamentale et structurelle de l'applicatif, garantissant la propriété des données.

Aucun autre navigateur sur la même machine, et a fortiori sur une autre, n'aura accès à ces données. Il n'y a donc pas de problème de sécurité, si tant est que l'utilisateur soit bien sécurisé par un login, celui de son Windows, de son Mac ou de son Ubuntu. Aucune donnée ne transitant sur le réseau, aucun besoin de cryptage, de cookie d'authentification, de serveur pour gérer les données. On peut craindre cependant que les données, étant bloquées sur un navigateur, ne puissent être partagées. Mais ce n'est pas le cas si on s'y prend bien.

La première façon de faire communiquer un applicatif à local storage est de le faire disposer de facilités d'import/export qui permettront d'échanger tout ou partie des données par l'intermédiaire de fichiers Json. Je rappelle ici que le format Json est aujourd'hui le standard d'échange de données dans le monde du front-end web, bien plus par exemple que XML.

Les fichiers peuvent alors être cryptés et transiter sur le réseau pour nourrir un autre navigateur internet. Ce n'est pas très pratique, mais ça marche bien. Dans un tel schéma, le fournisseur de service est réduit à portion congrue : il ne fait que mettre un logiciel à disposition. Mais bien sûr, sans côté serveur, aucun moyen de faire communiquer automatiquement les utilisateurs entre eux, ce qui est une extrême limitation, rarement tenable.

Il faut donc imaginer une solution moins austère, et plus ouverte, tout en garantissant à l'utilisateur qu'il gardera la main sur ses données.

Une architecture qui garantit la propriété des données

Si on veut aisément partager les données stockées localement avec un serveur, il vaut mieux doter l'applicatif web d'une fonction Ajax qui lira et écrira tout ou partie des données sur ce serveur. Une telle fonctionnalité sera indispensable notamment si l'applicatif doit synchroniser plusieurs utilisateurs, ou en général se synchroniser sur un flux de données temps réel. Une modélisation d'une telle architecture est représentée sur la figure 3.

Figure 3 : Local Storage et partage de données

La sauvegarde des données en local permet à l'utilisateur de choisir les données qu'il veut partager. La base des données principale de l'application n'est donc plus sur le serveur, mais reste chez les utilisateurs, sous forme d'une base de donnée distribuée. Le serveur quant à lui ne sert qu'à synchroniser ces données avec un flux temps réel. Il rend compte, en temps réel, des données que les utilisateurs l'autorisent à publier ou partager.

Imaginez par exemple que toutes les données qui vous concernent sur Facebook soient stockées en priorité sur votre machine personnelle, et que sur un clic vous autorisiez/interdisiez la publication ou la mise à jour de telle ou telle information. Cette architecture applicative apporte bien plus qu'un simple droit à l'oubli, elle respecte la propriété des données de l'utilisateur, qui en reste maître.

Et si vous aviez le choix entre le Facebook actuel et le Facebook que je vous décris, lequel choisiriez-vous ?

A n'en pas douter, les préoccupations sur la vie privée et la propriété des données deviendront un facteur essentiel dans l'acceptation des utilisateurs à se servir d'une application. Il est donc temps de s'intéresser à des architectures qui répondent à ces préoccupations, car on ne pourra plus tordre le bras des utilisateurs pendant très longtemps.

Restant à votre disposition si vous souhaitez en savoir plus,
Cordialement
Hervé

Aucun commentaire:

Enregistrer un commentaire