lundi 14 novembre 2016

Le data Model : pierre angulaire du développement applicatif

Le modèle MVC, pour « Model, View, Controller », fait un tabac dans les architectures applicatives web. La vue en est l'aspect le plus connu : c'est ce qui est affiché à l'utilisateur. Le contrôleur quant à lui est bien sûr chargé de contrôler le comportement de la vue, il gère ce qui doit être fait sur un clic, un enter, etc. Reste le M pour modèle qui est beaucoup moins bien compris. On considère trop souvent que ce sont simplement les données. Grave erreur, qui se paiera cher en temps, en quiproquos et en complexité de développement.

Lorsque j'interviens dans une entreprise pour développer du front-end, ma première question est systématique : « quel est votre data model applicatif ? ». La réponse du chef de projet est presque toujours la même : « notre quoi ? ». Au bout d'un temps d'explication j'ai le droit à un « ah oui, je vois ce que tu veux dire, heu, non, on n'en a pas ». Puis je regarde l'applicatif et son code, et là je comprends ce que coûte cette absence. Il m'importe donc dans ce billet de souligner l'intérêt du data model, non seulement pour le développement, mais bien plus encore pour la relation entre l'utilisateur métier et l'informaticien, un aspect des choses qui coûte en général très cher à un projet, voire le plus cher. Le data model doit être la pierre angulaire de tout développement, son fil rouge, et le trait d'union entre le métier et l'informatique.

Le data model en pratique

Comme d'habitude je parlerai ici du développement web et de ses standards, mais cela est applicable à tout développement objet moderne.

Le « M» de MVC est en réalité le « data Model », c'est à dire la façon d'organiser les données. Ce ne sont pas les données en elles même (sinon on aurait dit DVC), mais le réceptacle qui permettra de les structurer. Ainsi un modèle de données peut, et doit pouvoir, exister vide de données.

Au XXème siècle, on utilisait un « modèle de base de données » (sous entendu SQL), qui remplissait finalement la même fonction conceptuelle, mais de façon très laborieuse et indirecte.

En pratique le data model, à létat pur, n'est qu'un fichier Json, c'est tout (standard qui actuellement écrase XML par exemple). Ce fichier décrit comment vos données sont structurées pour faire fonctionner votre applicatif, TOUT votre applicatif. En prenant l'exemple classique d'une bibliothèque municipale, le data model pourrait ressembler à cela :

Figure 1 : un exemple de data model objet Json, dans le cas d'une bibliothèque municipale

Ce data model décrit la position et les dépendances de tous les objets et variables qui seront nécessaire à développer TOUTE l'application. Vous remarquez aussi que ce data model est vide de données, et pourtant il donne une image très claire de l'organisation de celles-ci, telle que le bibliothécaire la conçoit. Cela est structurellement fondamental pour le développement de votre applicatif.

Mais ne vous y trompez pas, seul un utilisateur métier sera capable de décrire cette architecture … métier. Aucun informaticien ne sait en quoi consiste le métier de l'utilisateur, car il est informaticien, pas commerçant, ni avionneur, ni distributeur, ni banquier, ni bibliothécaire, …

Evidemment, à l'inverse, l'utilisateur n'est pas un informaticien, et il y a donc peu de chance qu'il sache ce qu'est un objet json. C'est donc à l'informaticien, comme préalable à tout choix technologique, et donc à tout développement, d'interviewer l'utilisateur pour lui faire décrire son data model métier. Le résultat de cette interview sera retranscrite en objet Json tel que celui de la figure 1. l'informaticien est là l'interprète de l'utilisateur auprès de la machine, sans lui aucun de ces deux là ne pourraient se rencontrer.

Avant tout, LE lien entre l'utilisateur et l'informaticien

Cette pratique du data model possède de nombreux avantages, notamment lors de sa modification.

Si un mois après le début des travaux, l'utilisateur annonce qu'il a oublié un aspect des choses, et qu'il s'est trompé sur un autre (non, non, ça n'arrive jamais =;o), il suffit de modifier l'objet json, en accord avec lui. Etre agile, quoi, mais réellement, et même si on ne fait pas de DSM (Daily Standup Meeting). L'objet Json est idéal pour ça.

Parfois on se rend compte à cette occasion que l'utilisateur veut une chose et son contraire, ou qu'il a une vision incomplète, voire incohérente, de ce qu'il souhaite (le propre de l'homme). Le data model est alors d'une extrême utilité pour lui mettre en lumière les défauts, et parvenir à une adaptation d'un commun accord. Cette adaptation est toujours possible dans le data model, mais il se peut que cela perturbe les méthodes qui ont été développées avant la modification, et dans ce cas, l'utilisateur voit plus directement les conséquences de ses modifications (il acceptera donc mieux une surfacturation, ou le dépassement de délais, dont il est responsable).

Le data model est donc, avant toute chose, LE point commun unissant l'utilisateur métier et l'informaticien, autour d'un applicatif. Au moindre problème l'informaticien peut décrire à l'utilisateur, très précisément, sur quelle partie du data model il bute. Et surtout vice versa, ce qui n'est pas le moindre des avantages. Cela fait gagner un temps fou, en évitant nombre de quiproquos et d'incompréhensions.

Et si vous y réfléchissez bien, combien de temps ont perdu vos projets sur de telles incompréhensions mutuelles ?

Le data model pour l'informaticien

Vu du côté programmatique, le data model est un objet contenant des propriétés, en revanche il ne possède aucune méthode associée. C'est normal car le data model est indépendant du langage objet que vous utiliserez pour votre développement. Gros avantage. Selon le langage, vous pourrez transformer votre objet « data model » en un objet « active data model ». A tout niveau de l'objet Json vous pourrez prototyper les méthodes les plus adaptées à votre besoin applicatif, dans le langage que vous aurez choisi. Sur le front comme sur le back, qui évidemment partageront le même data model.

On voit qu'ici aussi l'utilisateur devra définir ses besoins. Une fois la structure de ses données définies, que veut-il qu'on en fasse ? C'est de sa réponse que découleront les méthodes nécessaires à rendre le data model actif. Une seconde interview sera donc nécessaire, et distincte. Le data model est en quelque sorte l'état initial, mais si l'application est en mouvement, il faut en définir ses lois mécaniques : quelle est la conséquence de la modification de telle donnée ? Ce travail nécessaire est grandement facilité par l'existence du data model, car tout événement mécanique présuppose son existence et peut donc se référer à lui. Je ne vais pourtant pas entrer ici plus en détail de cet aspect mécanique des choses, car cela nous éloigne de notre propos, bien qu'il s'agisse d'un autre facteur important du succès d'une application.

Bien sûr, l'aspect monolithique du data model Json que j'ai décrit jusqu'ici est trop rudimentaire. Par exemple on peut avoir besoin de décrire un objet « book », et de permettre au data model d'en intégrer un nombre indéfini au préalable. L'objet « book » doit alors posséder son propre data model, mais toujours de façon cohérente et en accord avec le data model applicatif père, qui ne doit jamais être perdu de vue, car il est le liant de tout l'applicatif.

Pour ce qui est du développement d'interfaces web, il est en général pratique d'ajouter à « l'active data model » des propriétés relatives à l'état de l'interface. Par exemple un livre de la bibliothèque n'est plus disponible, il ne faut donc pas l'afficher dans le stock. On rajoute donc au « book » la propriété « book.visible : false », qui pourra être interprétée rapidement par la bibliothèque qui gère le DOM. Et en réalité tout dépend de votre technologie, cet ajout étant optionnel, mais toujours possible. On voit par là que le data model n'est pas un carcan, mais une base de départ qui peut s'adapter à toutes les situations. Attention cependant à ne pas rendre « l'active data model » finalement illisible, pensez toujours à structurer proprement vos propriétés et méthodes.

On voit aussi que l'organisation d'un développement requérant plusieurs développeurs sera avantagé par le partage d'un même data model, qui n'est rien d'autre qu'un référentiel commun. Il est en effet possible de distribuer les charges de développements en modules indépendants, chacun traitant d'une partie du data model actif, et pour autant chaque programmeur saura très exactement où il intervient au sein du projet global.

Notez enfin une chose importante, le data model que je décris est immédiatement intégrable à une base de donnée « no SQL », sans filtre aucun. Il est de même nature qu'elles et s'y intègre naturellement, nativement, puisqu'il est un objet.

Message aux Chefs de Projets

Si vous respectez ces conseils, et que vous utilisez une bibliothèque comme Angular, React, Damo, etc., vous parviendrez à développer de façon très rapide. Ces bibliothèques front-end modernes sont fondamentalement structurées sur une arborescence objet, leur adhésion à votre objet data model est dès lors native, immédiate. Dans le cas d'Angular par exemple, une fois le data model mis à disposition du scope (par un service par exemple), tout le travail se fera sur la programmation des tags HTML, et très peu en programmation javascript, sauf application complexe bien sûr. Les bugs sont rares, les développements sont factorisés, il n'y a pas d'incompréhension des intervenants, le dialogue avec l'utilisateur est facilité, tout va plus vite et plus simplement.

En revanche cela vous contraindra à réfléchir avant d'agir, à ne pas vous lancer tête baissée dans le développement, mais d'avoir au préalable une vision globale de toutes vos contraintes. Il faut prendre le temps, avec l'utilisateur, de bien définir votre data model commun, et ce n'est pas toujours simple, comme je le disais plus haut. Mais rassurez vous, ce que vous perdrez ici, vous le gagnerez au centuple au cours du développement. On ne peut automatiser que ce qui est structuré, et donc plus vous structurerez en amont, et plus vous automatiserez, et donc gagnerez en tout. C'est cela dont il est question dans la constitution d'un data model.

Quelques user stories

Chez un constructeur automobile français, j'ai réécrit en 15 jours (WE compris) le travail de trois développeurs pendant un an, non pas que je sois un génie (même si je le regrette =;o), mais simplement parce que j'ai conçu un vrai data model applicatif, et que c'est l'idéal pour Angular. Le côté front-end rapatriait des données du serveur, puis l'application n'avait qu'à afficher (à part un ou deux clics et enter par ci, par là qui écrivaient sur le serveur en ajax). Au total, à part l'installation du framework Angular, toujours aussi lourd et rébarbatif, il n'y avait plus rien à faire, sauf bien sûr une mise en ordre des variables appelées dans les templates HTML angularisées. Les scopes d'Angular étaient vides, il suffisait de passer le data model en service, et il était directement utilisable pour la programmation du DOM, dans tous les scopes, en two-way data binding.

Ma dernière création, funKTest (voir mon billet précédent), à base d'Angular, c'est une semaine de travail grâce au data model (ok, le look est affreux, je ne suis pas graphiste =;o). Mais c'est avant tout le fruit d'une réflexion sur les besoins des entreprises qui souhaitent se lancer dans les tests fonctionnels, et dans lesquelles j'ai pu intervenir. Oui, cela aussi, je veux dire « le métier de testeur fonctionnel », peut-être structuré dans un data model, et aboutir à un logiciel : funKTest. J'ai bâti, à force d'interviews de ces entreprises sur leurs besoins métiers, le data model correspondant. Ce dernier s'est avéré tellement élémentaire que j'en ai créé un générateur de codes de test (Protractor) universel, utilisable pour tous les sites http(s). Cela fait partie des avantages non prévus de la structuration en data model, grâce à cet exercice, vous n'êtes pas à l'abri de réaliser parfois, contre toute attente, une économie drastique.

La version 9 d'OceanVirtuel, un mois de développement seulement, quant il m'en fallait 4 sans data model bien conçu. C'est un applicatif extrêmement complexe. Cartographie à multiples couches actives, moteur météo sur toute la planète, à 1/2 degré de maille géographique et 6 altitudes, massive computing data, noSQL database, responsive for all terminals, intégrations de nombreuses bibliothèques tierces, ... Tout cela s'éclaircit, se structure et se simplifie avec le fil rouge d'un data model digne de ce nom. Cela me permet d'affirmer que le data model est une solution idéale à l'intégration de bibliothèques tierces. Dans ce cas une simple fonction de filtrage, entre leur data model et le votre, est nécessaire pour les intégrer.

Je vous signale enfin ma bibliothèque, Damo.js, qui s'appelle ainsi car « Da(ta)mo(del) ». C'est un Angular, développé en Jquery (pour ôter tout le côté abstrait, inutile, et absconse d'Angular), qui se fonde sur une structuration des données comme celle que je viens de vous décrire. Je vous laisse en lire la documentation pour en savoir plus. C'est avec Damo que fonctionne OceanVirtuel V9, application complexe s'il en est. J'applique donc mes solutions à ma pratique, et je crois que les skippers des « Vents du Globes » en sont très satisfaits (à l'heure où j'écris ces lignes =;o).

Je ne saurais trop vous prévenir que ce qui va arriver demain matin en matière d'applicatif web sera vif, cinglant, rapide, incontrôlable et sans pitié. Et le lendemain sera pire. Votre capacité à vous adapter, vous interconnecter, vous intégrer, sera cruciale. Sans maîtrise de vos data model, vous n'aurez tout simplement pas le temps de vous adapter. Et la nature est ferme sur ce principe : pas adapté = éliminé.

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

mercredi 9 novembre 2016

Migration vers le web : Attention, Javascript !

Les temps sont à la migration des logiciels maison vers leur version web. La volonté de plus en plus de managements d'entreprises est d'offrir leurs services sur cette plate-forme universelle et mobile. Un rapide coup d'oeil au marché leur apprend que certaines bibliothèques tiennent le haut du pavé en matière de développement front-end web (Jquery, React, Angular, Cordova, Node, …). Ils donnent donc mission au développeur de reproduire le logiciel maison, sous forme d'applicatif web, pensant qu'il s'agira simplement de traduire un langage dans un autre. C'est oublier les spécificités des développements javascript/HTML/CSS, et particulièrement sa pauvreté à tous points de vue.

Une anecdote : pendant une mission dans une grande entreprise, l'équipe dans laquelle j'intervenais, est allé se former au javascript et à Angular, car ils n'avaient jamais abordé ce monde, s'étant consacré à du développement .Net. A leur retour ils avaient des yeux grands comme des soucoupes et m'ont immédiatement interpellé en chœur : « Javascript, mais c'est quoi ce truc ? C'est n'importe quoi !». Et ils n'avaient pas tort : tout développeur de langage structuré voit javascript comme un vaste foutware, permissif, déstructuré, ce qu'il est effectivement.

Javascript : « C'est n'importe quoi ce truc ! »

Sans s'en rendre compte, les managers qui demandent de « webiser » les logiciels classiques existants, présupposent que la programmation javascript est une programmation comme les autres, mais ce n'est pas le cas. Passons donc en revue certaines des ses spécificités qui étonnent lorsqu'on ne connaît pas le développement des applicatifs web :

  • Il est lent : javascript ne tourne pas directement sur la CPU de la machine, mais sur la machine virtuelle du navigateur internet, lui-même tournant sur la CPU de la machine. Cette surcouche se traduit par une perte de performances drastiques par rapport à une application native sur l'OS. A titre d'illustration je vous propose ce simulateur de transferts spatiaux : Transfer Simulator. Vous constaterez que cet applicatif a tout d'une application native (graphisme temps réel, paramétrisation complexe, …), bref une vraie belle appli scientifique. Le problème est que si la précision de 3600s vous paraît trop faible, et que vous souhaitez une précision de 1s pour avoir des trajectoires plus précises, et bien vous pouvez attendre le résultat plus d'une heure, alors que ce serait quasi instantané sur un applicatif natif. Ce qu'il faut retenir de cela est que vous pouvez oublier javascript si vos besoin en CPU sont trop importants.
  • Il est asynchrone : javascript se comporte comme un langage séquentiel … tant que vous n'utilisez pas les événements (clics, enter, scroll, …) ni les transferts Ajax. Donc en pratique, puisque javascript est destiné à gérer des interfaces en mode SAAS (software as a service), vous travaillerez quasiment toujours en asynchrone. Quant à migrer une application séquentielle en javascript, on comprends bien qu'il ne sera plus seulement question de réécriture dans un autre langage, mais de concevoir une toute nouvelle architecture logicielle asynchrone.
  • Il possède une queue séquentielle d'événements très dure à maîtriser, rendant problématique une gestion trop riche des événements (clics, scroll, drag, animations, ...)
  • Javascript ne peut pas écrire sur le disque dur client (sauf localStorage et indexedDB, voir mon billet précédent), ni le lire, rendant impossible toute liaison directe avec une autre application de l'utilisateur.
  • Vos codes seront lisibles en clair par tous les utilisateurs qui afficheront vos pages. Il n'y a pas de possibilité de les cacher par une compilation.
  • Même si la situation s'améliore, tous les navigateurs n'implémentent pas javascript de la même façon, vous forçant à coder spécifiquement pour l'un et l'autre.
  • Javascript manipule des objets HTML, mais ces objets sont rudimentaires. Impossible par exemple d'insérer des images dans un tag <option>, ou de styler un <input type="file" />. Il faut recréer des objets plus complexes qui cacheront cette misère.
  • Les différentes bibliothèques disponibles sont le plus souvent incompatibles les unes avec les autres, mais il y en a foison, et chaque jour de nouvelles. Comment choisir la bonne ?
  • La gestion du cache des navigateurs est une épine dans le pied,
  • etc.

En fait une grande partie de la programmation javascript consiste à cacher la pauvreté du monde HTML, et à « faire croire » à l'utilisateur qu'il est devant une application « normale ». Cette illusion est possible tant que l'application n'est pas trop complexe et ne gère pas trop d'événements, mais elle possède des limites vite atteintes.

Pourtant il ne faut pas conclure que le javascript doit être délaissé, ce serait faire une autre erreur. De toute façon, vous n'avez pas le choix. Si votre objectif est d'être présent dans le monde des applicatifs web, Javascript est un passage obligé, car c'est le langage natif des navigateurs. Tant pis s'il a des défauts, il faut faire avec, car il n'y a pas autre chose. Cependant, au bout du tunnel il y a l'accès à la sphère internet, ce qui vaut bien de se coltiner javascript.

Les avantages des applicatifs web sont drastiques

Programmer javascript c'est proposer un applicatif que tous les navigateurs du monde pourront faire tourner, sur un clic, sans installation. C'est un atout crucial aujourd'hui. En outre cela vous impose de séparer clairement votre back-end et votre front-end, rendant par la même plus facile toute évolution future de l'interface (et dieu sait si les utilisateurs se lassent vite). Faisant ainsi vous structurerez vos méthodes avec les standards les plus fiables (HTML5, CSS3, Json, …), garantissant l'interopérabilité et la pérennité de vos applicatifs. Ces derniers tourneront peu ou prou en mode SAAS, vous garantissant ainsi un serveur, temps réel qui plus est, peu chargé, car tout l'effort CPU et mémoire sera assuré par l'utilisateur. Grâce à SAAS, fini le versioning, une correction sur le code et la modification est immédiatement disponible pour tous les utilisateurs.

J'arrête ici la liste des avantages, mais on pourrait la prolonger à loisir.

Réfléchir avant d'agir

J'encourage donc les managements d'entreprises à s'orienter en effet vers des applicatifs web, mais je les mets en garde sur les contraintes techniques de ce monde particulier des technologies web. Il est recommandé de ne pas les ignorer, sous peine de fiasco.

J'entends beaucoup parler d'équipes qu'on a lancé sur un développement Angular d'un logiciel maison, mais qui ne s'en sortent pas. Elles ont beau changer de Tech Lead, rien à faire, ça ne fonctionne toujours pas. C'est le symptôme typique d'une application qui est trop complexe et trop riche pour passer en Angular. Il est alors temps de se poser les bonnes questions : peut-être pourrait-elle passer en ExtJS, une des meilleures bibliothèques javascript, ou bien il pourrait suffire de repenser l'ergonomie de l'application, exploser une page complexe en 3 pages simples, angularisables. Ceci n'est qu'un exemple.

On voit par là que le développement javascript est une affaire complexe dans laquelle la technologie de développement doit être déterminée par les besoins applicatifs, eux-même jaugés par un ergonome et un graphiste. Les performances javascript étant médiocres, il est indispensable de ne développer que le nécessaire, et d'oublier les fonctionnalités superflues ou peu utilisées. Il faut donc opérer un lourd travail de factorisation des fonctionnalités, ainsi définir de façon optimale l'ergonomie fonctionnelle métier est crucial, avant de choisir les rechnologies, et de se lancer dans le développement. Ces contraintes n'existent pas pour un logiciel compilé classique, auquel on peut ajouter des fonctionnalités presque à volonté.

Quoi qu'il en soit, la technologie Javascript est techniquement à la traîne, comparée aux technologies de développement à compilation (.Net, C++, Java, …), puissantes et bien rôdées, ses fonctionnalités sont pauvres, ses performances sont médiocres. Réaliser ce que veut l'utilisateur en matière d'interface est donc souvent un challenge technique qui ne doit pas être mésestimé. C'est de plus une tâche qui désoriente totalement le développeur « classique » qui ne trouve plus ses repères habituels.

En conclusion, mon conseil avant de s'engager dans le développement d'un applicatif web, est de commencer par faire consulter le projet par un expert technique du front-end. Seul un tel expert saura indiquer les bonnes architectures, technologies et méthodes à utiliser, ce qui fera gagner beaucoup de temps et d'argent. N'oubliez pas que le monde du web et du javascript sont en perpétuel renouveau, et seul un spécialiste a les capacités de suivre ces évolutions rapides. A titre d'exemple Goole Trends vous montrera l'évolution relative de l'intérêt porté à Angular et à React, et vous verrez que ce qui était vrai il y a un an, ne l'est plus aujourd'hui. Même si un expert ne fait que valider vos vues, il sera la garantie de ne pas diriger votre projets dans une impasse technologique, car les embûches sont nombreuses.

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

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é