jeudi 13 avril 2017

Back-end, front-end, deux mondes à séparer

Ce matin un chef de projet, travaillant sur un applicatif web bancaire, me téléphone pour discuter d'une éventuelle mission dans son entreprise. Une grande entreprise donc. Il cherchait un vrai pro du front-end (HTML/CSS/Javascript), mais qui devrait aussi programmer du back-end (java). Il n'a pas su m'expliquer très exactement les tenants et les aboutissants de cette répartition, ni en quoi elle consisterait en pratique.

Si une intervention full-stack est bien sûr normale pour les petites structures, il est étrange de la rencontrer encore dans les grandes, et d'autant plus que les projets sont d'envergure. En matière d'internet le back-end est devenu un véritable métier à part entière, avec ses spécificités, ses langages, ses architectures. Il en va de même pour le front-end qui est aujourd'hui un véritable travail de spécialiste. Le développement javascript est totalement asynchrone, à l'inverse des langages de back-end (sauf node.js), et l'architecture, les méthodes, les technologies n'ont rien à voir. Il est indispensable d'avoir une tournure d'esprit spéciale, asynchrone, pour s'y engager, et cela ne convient pas à la culture de développement back-end.

Aujourd'hui si vous êtes un spécialiste du back, vous ne pouvez plus être spécialiste du front, et vice versa. Tout projet ambitieux réclame donc de constituer des équipes back et front totalement séparées, et d'instaurer entre elle un canal de communication structuré et documenté : les API REST.

Le back pour pérenniser

Le back-end va stocker et sécuriser les informations liées à l'applicatif. Il fera aussi tourner les algorithmes spécifiques métiers qu'on ne souhaite pas dévoiler au grand jour. Je rappelle en effet que le javascript est toujours lisible, et qu'on ne peut donc pas déléguer au front-end un algorithme dont on veut garder le secret, c'est le back qui doit s'en charger. Enfin, le back doit être serveur de données pour le front, grâce à une couche d'API REST. Le back est donc le fournisseur d'eau de gaz et d'électricité, c'est à dire l'infrastructure de base.

On peut modifier les technologies et les architectures du back, tant que les API REST servent toujours les informations nécessaires au front. Ainsi on voit que le back doit se structurer de façon indépendante du front, il n'est donc pas obligé d'être réécrit à chaque nouvelle application, ni que chaque application ait son back dédié. On voit dès lors que le back doit jouer le rôle de socle du système d'information, garantissant la pérennité des données, de leur traitement et de leur service.

Le front, la partie sans cesse évolutive

A l'inverse du back le front-end doit s'adapter sans cesse aux besoins utilisateurs : nouvelles fonctionnalités, nouveau look, nouvelles technologies plus ergonomiques, moins gourmandes en ressources, … Et dans ces domaines chaque jour apporte ses innovations, voire ses révolutions (ajax, websockets, two-way data binding, applis mobiles, …). Il est inimaginable de programmer un front-end aujourd'hui avec les technologies d'il y a 5 ans (HTML5, CSS3 ou Angular n'existaient pas), et encore moins 10 ans. Le front doit donc être conçu dans cette perspective.

Quoi que vous fassiez votre front-end ne durera pas 3 ans car les utilisateurs, et vous, aurez besoin de nouvelles fonctionnalités, d'une autre charte graphique, de nouvelles pages, ... De nouveaux besoins apparaîtrons, qui vous forceront à évoluer si vous ne voulez pas perdre vos internautes. Ainsi le front-end doit être pensé en perpétuelle évolution, outre les montés de niveau majeures. Le temps sera votre ennemi, et vous devrez impérativement développer des technologies et méthodes de « rapid development », pour ne pas perdre vos clients, et vous y parviendrez en étant plus rapide que vos concurrents. J'irai même jusqu'à dire que ce doit être du jetable, ou au moins pensé comme tel au maximum.

Des gains drastiques

En reprenant le problème de ce chef de projet qui me téléphonait, la fabrication d'un front-end de compte bancaire, connaissant les interfaces que me proposent mes banques (LCL et Caisse d'Epargne), un tel front-end ne doit pas prendre beaucoup plus que 3 semaines à programmer, pour un homme seul. Si le back-end est bien conçu, et que la définition des fonctionnalités de l'interface sont clairement décrites, des technologies comme Angular, et surtout Damo, associées à un datamodel cohérent, permettent de réduire drastiquement le temps de développement. Et à vrai dire le poste le plus coûteux n'est alors plus le développement, mais l'aspect graphique de l'interface, toujours très chronophage, notamment pour faire responsive. On peut donc ajouter une semaine à mon chiffrage pour cet aspect des choses.

Avec de tels délais il est effectivement possible de penser les interfaces comme jetables. Imaginez également les gains en terme de coûts ...

Une impression

J'ai souvent l'impression que les projets web ne sont pas suffisamment structurés en fonction des technologies et de l'architecture du réseau. Ils sont plutôt pensés a priori, comme au XXème siècle. Pourtant l'internet met à notre disposition des outils de tous types qui, s'ils sont correctement employés, bouleversent totalement la donne logicielle.

Si les anglo-saxons semblent avoir compris cela (je l'ai vécu), et se ruent sur cette opportunité, je constate que les grandes entreprises françaises n'ont pas encore pris la mesure de la révolution technologique qu'apporte le réseau et ses outils (je l'ai aussi vécu). Trop souvent les sphères fonctionnelles métiers se mêlent aux sphères techniques, dans un enchevêtrement où on ne sait plus qui fait quoi. Les rôles du back et du front se chevauchent, sans séparation claire et standardisée. Il est alors impossible d'embarquer au plus vite les nouvelles technologies qui apparaissent, pour bénéficier de leurs avantages compétitifs, et c'est pourtant presque tous les jours pour le front-end. Au total on aboutit trop souvent à des usines à gaz, chères à maintenir et faire évoluer, en retard d'une ou deux technologies, et ne satisfaisant que partiellement les internautes.

Pourquoi faire simple, rapide et peux coûteux, quand on peut faire compliqué, lent et cher, me direz-vous. Je vous répondrai : pour prendre toute votre place dans le XXIème siècle.

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

mardi 3 janvier 2017

Responsive si possible

Si votre applicatif n'utilise pas les périphériques des terminaux mobiles, alors vous n'avez aucun intérêt à produire des binaires téléchargeables, il faut plutôt penser web responsive.

L'autre jour j'ai été contacté par un entrepreneur qui avait perdu son développeur, pour je ne sais quelle raison, et qui cherchait un remplaçant en urgence. Le logiciel devait être livré une semaine plus tard. Il s'agissait d'une application javascript Angular encapsulée avec Cordova afin d'obtenir des applications binaires mobiles Androïd et IOs téléchargeables depuis les Play Store et autre Apple Store. Je connais Angular et Cordova, pour les avoir largement programmés, et je lui ai dit que je reprenais le projet au vol. Enfin un peu de challenge !

Malheureusement je ne possède aucun Mac, et si je peux compiler pour Android sur mon Linux, je suis incapable de compiler pour IOs, système fermé pour utilisateurs captifs s'il en est. Patatras ! L'affaire n'a pu se faire … et cet entrepreneur est reparti à la recherche de quelqu'un qui possède les compétences, et qui pouvait en plus compiler IOs, le tout avec l'épée de Damoclès des délais au dessus de sa tête.

Avez-vous besoin des périphériques du mobile ?

Dans cette affaire, cet entrepreneur m'a confié son code, que j'ai donc scruté avec intérêt. Un code très bien écrit, très bien structuré. Tout juste aurais-je une remarque à faire sur l'utilisation du LocalStorage plutôt que d'une IndexedDB, ce qui limite la quantité de sauvegarde utilisateur à 5Mo au lieu d'un espace illimité.

Mais ce qui m'a frappé tout de suite c'est que l'application n'utilisait aucun des éléments spécifiques à un terminal mobile : géolocalisation, accéléromètre, carnet d'adresse, agenda, boussole, ... Cordova ne faisait appel qu'au clavier. Par conséquent distribuer cet applicatif sous forme de binaire téléchargeable n'a aucun intérêt, pire, c'est une perte de temps et d'argent, avec une probabilité élevée de se trouver bloqué à un moment donné … par exemple si votre programmeur vous lâche.

Cet applicatif étant développé en Javascript, il tourne nativement sur n'importe quel navigateur internet. Ainsi il suffit de diriger l'utilisateur vers une page web, plutôt que de lui demander de télécharger un binaire, puis de l'installer. Il aura exactement le même service, exactement le même, mais l'éditeur de ce service, lui, fera des économies drastiques de tout. C'est l'enjeu des systèmes SAAS, Software As A Service, qu'il faut savoir utiliser pour leurs avantages.

Software As A Service même si le binaire est plus hipe

Si on conçoit un service comme une page Web, il n'y a plus de versioning à gérer. En effet, une correction sur le serveur est immédiatement disponible pour tous les utilisateurs, quels que soient leurs OS. Il n'y a plus pour eux à télécharger la dernière version et remplacer l'ancienne. Il n'y a plus de compilations pour toutes les versions d'Android, IOs, Windows Phone, Blackberry, ..

Bien sûr, si vous avez besoin de la géolocalisation, ou d'accéder au répertoire de l'utilisateur, etc., vous ne pourrez échapper à Cordova et des compilations binaires. Mais si vous n'utilisez rien de cela il n'y a strictement aucun intérêt à vous construire une usine à bug et une gestion titanesque des versions, avec les coûts et délais que cela entraînera immanquablement. Et accessoirement, si votre programmeur vous lâche, il est plus facile de lui trouver un remplaçant =;o)

Etre hipe et moderne ce n'est pas fournir des applis téléchargeables dans les play stores, c'est fournir un service en ligne hipe et moderne. Ici encore il faut avant tout concevoir les choses au grand bénéfice de l'utilisateur. S'il n'y a pas besoin de le contraindre à installer ou upgrader, alors il ne faut pas le faire. L'utilisateur veut de l'efficace et du pas cher, alors il faut faire au plus efficace et au moins cher.

Tant que votre application n'a pas besoin des périphériques du mobile, je vous conseille de penser responsive : un seul code s'adaptant à tous types de terminaux. Un bon exemple de site responsive est Wikipedia, et un autre parmi mille, OceanVirtuel. Une correction ou une évolution de votre applicatif est alors immédiatement disponible pour tous les terminaux, sans besoin de compilation, sans téléchargement, sans imposer quoi que ce soit à l'utilisateur. Et bien évidemment cela coûte infiniment moins cher que de gérer des binaires, et c'est infiniment plus rapide, plus efficace.

Vous ne serez pas choisi par les utilisateurs parce que vous avez un binaire téléchargeable sur l'Apple Store. Vous serez choisi parce que votre service lui est utile, simple d'utilisation, novateur, efficace et pas cher. Ce qui est important c'est ce qu'il y a dans la boîte, ce n'est pas l'emballage, et encore moins s'il vous coûte trop cher en tout.

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