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é