Tutoriel pour présenter un panorama sur la fragmentation du développement Web en 2016

Sami Jaber

Jamais le monde du développement Web n'aura connu telle révolution. En l'espace de 10 ans, le marché, les technologies, les acteurs ont dû se réinventer pour embrasser une fragmentation qui touche aujourd'hui toutes les couches logicielles d'une application. De la partie cliente à la partie serveur en passant par l'outillage, réaliser le développement d'un projet Web aujourd'hui est un vrai casse-tête pour celui qui recherche pérennité, maintenabilité et simplicité. Cet article, s'il est loin d'être exhaustif, fait un état du marché actuel et du métier de développeur Web. Il précise les technologies en jeu en insistant parfois sur leurs avantages et faiblesses, mais dénonce aussi cette surenchère au framework soi-disant le plus innovant, qui conduit finalement à faire la même chose, mais différemment. Développeur Web en 2016, un difficile métier.

Pour réagir à ce tutoriel, un espace de dialogue vous est proposé sur le forum : Commentez

- Titre : Tutoriel pour présenter un panorama sur la fragmentation du développement Web en 2016

- Auteur : Sami Jaber

- Parution : 18 juillet 2016

- Licence : Copyright ® 2016 Sami Jaber. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. L'historique

- II. Les technologies de présentation (front-end)

- II-A. Le véritable casse-tête du langage

- II-B. AngularJS 1 & 2

- II-C. ReactJS

- II-D. NodeJS

- II-E. Standard W3C : Les Web Components

- II-F. GWT (Gwit Web Toolkit)

- III. Les technologies Serveur (Spring, JEE et Microsoft)

- IV. Les outils

- IV-A. L'environnement de développement

- IV-B. Génération de code (Java JHipster)

- IV-C. L'intégration continue et le déploiement (Docker, Jenkins…)

- IV-D. Maven & Gradle

- V. La sécurité

- VI. La mobilité

- VII. Les kits d'ergonomie (Material Design, Bootstrap, Apple iOS, Microsoft UWP)

- VIII. Les microservices

- IX. Conclusion

- X. Remerciements

I - L'historique

En quelques années, nous sommes passés d'architectures finalement assez dichotomiques à une ribambelle d'étoiles et de planètes formant aujourd'hui la sphère du Web. À l'image de la figure suivante, le monde technologique dans l'entreprise était partagé dans les années 2000 entre d'un côté les applications Java (JEE ou Spring) et de l'autre les applications .NET et de manière plus « alternative » les technologies dites libres qu'on qualifiera de LAMP (Linux, Apache, MySQL, PHP).

En l'espace de 10 ans, cette dichotomie a littéralement explosé. On pourrait dater le moment précis à partir duquel les choses ont changé. L'annonce par Apple de l'arrêt du support de Flash dans les iPhones a été un signe fort vers le tout HTML 5. Cet article de Steve Jobs daté d'avril 2010 est une ode à HTML 5 et encourage le marché à trouver un consensus autour de ce balbutiant standard : http://www.apple.com/hotnews/thoughts-on-flash/.

Alors qu'on s'acheminait vers plus de clients lourds (à l'époque les fameux « Smart Client ») à base de Flash, Flex (chez Adobe), Swing (chez Oracle), WinForms & WPF (chez Microsoft), le marché, pris un peu de court, a dû se réinventer pour construire les briques permettant de coder en HTML 5 une application d'entreprise.

Il faut avouer que les débuts ont été assez difficiles avec de nombreux essais mêlant pêle-mêle des frameworks JavaScript (JQuery entre autres) connectés à des services exposés plus ou moins en REST. Non seulement l'outillage ne permettait pas d'être productif mais le cycle de test et debug s'apparentait plus à du bricolage en additionnant des couches logicielles qu'à une réelle industrialisation.

Aujourd'hui, les choses ont changé, les frameworks techniques règnent en maître. Les langages se sont multipliés, les outils ont dû s'adapter pour être « multicompétences ». Voyons quels sont les choix qui s'offrent à celui souhaitant créer une application Web en 2016.

II - Les technologies de présentation (front-end)

La partie cliente relève de tout ce qui touche à la couche de présentation, c'est-à-dire les composants graphiques, le fenêtrage, le placement (« layout » en anglais), les styles, etc.

II-A - Le véritable casse-tête du langage

En 2005, un développeur sortant de l'école et ayant des notions dans un langage (objet ou non) pouvait se spécialiser facilement dans un des langages prédominants du moment (Java, C#, PHP, C/C++) pour bâtir une application Web, notamment lorsque les architectures en vigueur ciblaient le MultiPage. La logique d'affichage et de rendu était gérée non pas par le navigateur mais par le serveur. Aujourd'hui, les choses sont totalement différentes. Le Single Page Application (SPA) a pris le dessus. En pratique, cela signifie que les frontières entre client et serveur sont de plus en plus floues. Un traitement métier consistant à valider un formulaire est écrit en JavaScript en mode SPA. La navigation et la gestion du placement sont également implémentées côté client. Une part importante du métier autrefois délégué au serveur se voit migrer sur le poste client.

Or, en 2010, le seul langage capable de s'exécuter correctement dans un navigateur est JavaScript. À cette époque, il fallait être téméraire pour convertir des pans entiers de code serveur existant en JavaScript. Il n'aura pas fallu longtemps à certains férus pour s'apercevoir qu'un framework client était nécessaire, ne serait-ce que pour optimiser les opérations de navigation, de binding et de séparation entre traitement et présentation. Là où le bât blesse, c'est que JavaScript est loin d'être le langage rêvé du développeur Web souhaitant réaliser des applications complexes d'entreprise : pas nativement objet, non modulaire, difficile à déboguer de par sa nature dynamique, peu ou pas d'adhérence possible avec les outils (notamment les métadonnées nécessaires au langage) pour construire des générateurs de code.

En bref, le marché s'est aperçu qu'il fallait réformer JavaScript. Ce qui fut fait avec le consortium ECMA chargé de définir certains standards du Web. Il existe aujourd'hui 3 versions majeures de JavaScript : ES5 (créé en 2009 et largement supporté), ES6 (publié en juin 2015 en cours de généralisation) et ES7 plus ambitieux (en cours de développement).

En parallèle de ces travaux, certains acteurs comme Microsoft ou Google se sont empressés de créer leur propre langage plus typé (principal défaut de JavaScript). Nous avons ainsi vu arriver TypeScript créé par Microsoft et Dart de Google.

Pour simplifier les choses, il existe aujourd'hui des transpileurs tels que Babel permettant de convertir certains langages dans d'autres. GWT est également à ajouter dans cet écosystème de langages, car il permet de coder en Java pour ensuite générer du JavaScript.

En résumé, nous avons donc JavaScript (en trois versions) : Java, TypeScript et Dart. Voyons maintenant la liste des principaux frameworks permettant de mettre en œuvre une application SPA avec ces différents langages.

II-B - AngularJS 1 & 2

Angular est probablement le framework qui a le plus œuvré à démocratiser JavaScript. Créé par Google et présenté comme un « Super Héroïque Framework », il propose de multiples fonctionnalités :

- modèle data binding évolué : il suffit d'associer un formulaire aux propriétés d'un objet pour bénéficier à moindre coût d'une mise à jour uni ou bidirectionnelle ;

- basé sur des contrôleurs et le design pattern MVW (Model View Whatever) : on fournit un contrôleur de page puis un mécanisme de mise à jour basé sur des callback permet de séparer la partie présentation (le Document Object Model) et les traitements métier ;

- routage, validation, communication avec le serveur : l'API, très riche, propose de nombreuses fonctionnalités de routage (gestion de l'historique en mode SPA), mais également la validation de champs ou la communication asynchrone en AJAX avec le serveur ;

- directives, templates, internationalisation : le concept de directives a aussi contribué à faire connaître Angular ; ce sont l'équivalent de balises personnalisées interprétées par un moteur de rendu propriétaire (intégré dans Angular). Ce moteur fait d'ailleurs l'objet de nombreux débats liés à ses performances dans le cas de pages riches et complexes. L'internationalisation et l'utilisation de modèles de pages apportent là encore une richesse en matière de séparation traitement-présentation ;

- testabilité, injectable : la testabilité et l'injection réalisent le découplage des composants applicatifs ou techniques.

L'élément le plus notable à retenir d'Angular est la différence entre la version 1 et la version 2 (non encore finalisée au moment de la rédaction de cet article). Là où la version 1 privilégiait clairement JavaScript comme langage, la version 2 est une refonte complète avec une rupture de compatibilité. Cette rupture concerne les API, mais aussi le langage. La décision d'adopter TypeScript (créée par Microsoft) dans Angular 2 a été perçue de manière très mitigée par certains aficionados JavaScript. Plus que le langage, les nombreuses entreprises qui ont investi dans cette technologie se trouvent aujourd'hui dans une situation délicate. La migration risque d'être douloureuse et de nombreux développeurs vont probablement se désintéresser de la version 1 pour se tourner vers la version 2 plus typée.

II-C - ReactJS

ReactJS, développé par Facebook s'inscrit comme un concurrent d'Angular tout en proposant un modèle de développement très structurant avec une approche « orientée composant ». L'idée sous-jacente consiste à fournir un framework qui simplifie l'état applicatif d'une interface utilisateur. Son architecture totalement découplée part du principe qu'un composant graphique ne doit pas avoir de lien fort avec un autre composant graphique. De cette manière, l'interface peut évoluer facilement sans avoir à remettre en cause la conception existante. Via un mécanisme de propriétés, chaque composant va propager à ses enfants toute modification de l'état conversationnel d'une application. Une sorte de data binding optimisé, car nécessitant moins de traitement (cet article donne plus de détails) en utilisant le concept de DOM virtuel. Si techniquement ReactJS possède une vraie singularité, se pose la question de son écosystème. Les composants ReactJS ne sont pas la panacée et le modèle à base de templates HTML traditionnels est loin de s'accommoder du format propriétaire JSX de React.

Côté langages, ReactJS adopte JavaScript par le biais d'ES6 (un support d'ES7 est prévu). Un pont Dart est disponible et rien n'empêche d'utiliser TypeScript via son transpiler JavaScript (http://blog.wolksoftware.com/working-with-react-and-typescript).

II-D - NodeJS

NodeJS se différencie clairement d'Angular et ReactJS par le fait qu'il couvre toute l'infrastructure applicative, de la couche de présentation à la couche serveur. Très sommairement, l'idée à la base de NodeJS est d'unifier le langage (en l'occurrence JavaScript) pour le généraliser sur le client et le serveur. Pour ce faire, il s'appuie sur le moteur JavaScript V8 de Chrome pour en faire une machine virtuelle applicative (client et serveur). Les API NodeJS, côté client et serveur sont très riches. Il est évidemment possible d'utiliser ReactJS et AngularJS sur une infrastructure Node. En pratique, n'importe quel framework UI JavaScript est par nature compatible NodeJS. Il faut donc voir NodeJS comme l'intégration d'un framework JavaScript dans une infrastructure homogène dédiée à JavaScript.

II-E - Standard W3C : Les Web Components

Les Web Components sont une initiative de Google et Mozilla. Le standard repris par le W3C (https://www.w3.org/standards/techs/components#w3c_all) puis accepté en 2015 par Microsoft vise à proposer un modèle de composants HTML/JavaScript réutilisables. En utilisant les capacités natives des navigateurs récents, un développeur crée une balise personnalisée dont le comportement est défini en JavaScript, la structure en HTML et l'apparence en CSS. La particularité des Web Components est de standardiser la manière de créer ces composants. Pour ceux qui connaissent un peu Flex, ASP.NET ou JSF, il suffit d'imaginer l'équivalent de ces balises interprétées dans le navigateur côté client. Comme pour AngularJS, la question du langage à utiliser se pose. Dans Polymer, le framework de Google, il y a peu d'ambiguïté, la préférence va clairement à JavaScript.

Il faut noter que les concepts existants dans AngularJS et Polymer sont très proches (navigation, services, routage, gestion du placement…). La notion de directive (balise personnalisée) se rapproche des Custom Elements de Polymer (https://customelements.io/) et pour couronner le tout, les deux projets ont la même origine : Google. Autant dire que les Web Components contribuent à cette fragmentation du marché. Et la nature « standard » des Web Components ne leur confère aucune légitimité par rapport à leurs concurrents. Ce qui n'était pas le cas à une époque pas très lointaine où le terme « standard W3C » avait un sens réel.

II-F - GWT (Gwit Web Toolkit)

GWT est le plus ancien des frameworks présentés ici. Créé en 2005 par Google (eh oui, encore lui) dans le but d'optimiser les applications AJAX en fournissant un compilateur Java vers JavaScript, GWT a vu l'avènement de l'ère JavaScript sans forcément y prendre part. Plus qu'un compilateur, GWT est un framework fournissant une multitude de services (essentiellement côté client). Tout comme NodeJS cherche à unifier l'utilisation du langage JavaScript, GWT unifie l'utilisation du langage Java sur le client et le serveur. Là où la situation est, il faut dire, assez ubuesque, c'est qu'à l'époque où JavaScript s'est démocratisé, Java et JavaScript avaient structurellement de vraies différences (gestion de l'orienté objet, métadonnées, modularité…). Aujourd'hui, Java 8 propose les « lambdas expressions » rendant Java de plus en plus dynamique et JavaScript (notamment ES6) propose désormais le typage fort, l'héritage, le polymorphisme et nombre de fonctionnalités héritées des langages-objets. Java et JavaScript n'ont jamais été structurellement aussi proches et en même temps aussi loin dans leurs écosystèmes respectifs.

III - Les technologies Serveur (Spring, JEE et Microsoft)

En dix ans, si la couche de présentation a subi de profondes modifications, on ne peut pas en dire autant de la couche serveur. Excepté la partie « données » qui a vu la popularisation des bases NoSQL et du BigData, la couche de services a finalement confirmé certaines technologies dévoilées dans les années 2000. Que ce soit le mapping objet/relationnel, l'injection de dépendances, le modèle REST et la notion de composant de services, les éditeurs partagent une vision commune.

Voyons dans le détail les deux visions d'architecture logicielle dans le monde Java.

Comme le montre la figure précédente, deux écoles se dessinent. Le monde « standard » et le monde « Spring ». Le monde Spring tend à fournir un framework intégré et cohérent. Spring Boot (http://projects.spring.io/spring-boot/) fournit tous les services permettant d'être rapidement opérationnel sur les différentes couches : les composants transactionnels, distribués et sécurisés via Spring REST et Spring Security.

La partie « Données » est prise en charge par Spring Data, une surcouche proposant une abstraction à de multiples sources de données (JPA, NoSQL, JDBC…).

Dans le monde Microsoft, les choses sont relativement plus simples, l'éditeur fournit au travers de .NET un tout cohérent et intégré allant de l'outillage (Visual Studio .NET) aux frameworks. La figure suivante décrit les mêmes couches avec les API associées.

À noter que l'éditeur est actuellement dans une phase consistant à restructurer entièrement .NET pour en faire une plate-forme portable ET Open Source (c'est déjà le cas avec .NET). Avec le récent rachat de Xamarin, Microsoft vient clairement empiéter sur les plates-bandes de Java. Dans un premier temps comme fournisseur d'infrastructure Cloud Linux (avec Azure) et maintenant comme fournisseur de solutions multiplate-formes pour les développeurs, qui l'eut cru ? Il faut dire que le départ de Steve Ballmer et son remplacement par Satya Nadella ont sûrement accéléré le déploiement de cette nouvelle offre dénommée .NET Core. Celle-ci remplacera probablement à terme le framework actuel et va considérablement bouleverser la donne, notamment si Microsoft réussit à percer sur le mobile, point fort de Xamarin.

Côté communauté NodeJS, cette architecture possède un équivalent, mais il est difficile de la qualifier d'architecture « type ». Le choix est tellement vaste qu'il n'existe pas de « standard » NodeJS. La couche de services peut tirer parti d'un framework tel que ExpressJS. Le mapping objet relationnel peut être pris en charge par Sequelize, CaminteJS ou directement en utilisant les packages (NPM) disponibles pour les différents éditeurs. Les développeurs utilisent indifféremment IntelliJ, Visual Studio ou Eclipse.

IV - Les outils

IV-A - L'environnement de développement

Les trois grands ateliers de développement actuellement sont Eclipse, IntelliJ et Visual Studio. Dans ce domaine où la dichotomie était clairement visible et affichée, les frontières sont de plus en plus floues. Ces outils ont dû se réinventer pour supporter cette fragmentation. Eclipse n'est plus uniquement dédié à Java et propose des plugins pour NodeJS, TypeScript ou ES6. IntelliJ, largement plébiscité par les connaisseurs, offre aussi un atelier JavaScript très riche. Visual Studio, enfin, s'est depuis ouvert à Angular/React et JavaScript et cible des technologies de plus en plus hétérogènes. Il est révolu le temps où les développeurs Java pointaient du doigt le côté fermé de Visual Studio. L'outil le plus apte à supporter les dernières nouveautés du framework le plus à la mode s'octroie les faveurs des développeurs.

IV-B - Génération de code (Java JHipster)

Nous l'avons vu avec la multiplication des architectures, coder une application Web aujourd'hui consiste à choisir les bons éléments. La fragmentation est telle que cet assemblage devient très coûteux s'il est réalisé manuellement. C'est là où des outils comme JHipster prennent tout leur sens. La vocation première de JHipster est de générer des applications Java/JavaScript (en se basant sur le moteur Yeoman). L'outil pose des questions à l'utilisateur dont les réponses (le prérequis étant d'accepter par défaut une configuration avec Angular et SpringBoot) sont utilisées pour générer un squelette de projet contenant certains services de base (gestion utilisateur, statistiques, logs…). Il est également possible de créer son modèle du domaine en passant par des outils type UML ou un DSL maison (le langage JDL http://jhipster.github.io/jdl/) ou de générer des DTO (objets de transfert).

JHipster est typiquement le fruit d'une situation assez rocambolesque dans laquelle le monde du développement est plongé. Les frameworks sont aujourd'hui tellement nombreux qu'il est nécessaire de recourir à un outil pour les choisir et les intégrer. Dans son approche très « génération de code », les plus anciens auront probablement reconnu des concepts empruntés à MDA (Model Driven Architecture), à ceci près que JHipster ne fournit pas (encore) de modèles de projets. Mais il serait tout à fait imaginable de créer un modèle spécifique applicatif dans lequel l'utilisateur configurerait ses services et son modèle du domaine. Puis en fonction de plugins (qui correspondrait aux frameworks retenus), génèrerait une bonne partie du code. Encore un concept d'antan qui revient au goût du jour, mais… différemment et plus « geek ».

À noter que ce type d'outil n'existe pas dans le monde .NET, car le choix des API est dicté par les classes du framework .NET.

IV-C - L'intégration continue et le déploiement (Docker, Jenkins…)

Voilà un autre domaine qui a bien évolué ces dernières années, celui des outils d'intégration continue. Que ce soit des outils tels que Bamboo, Jenkins ou même TFS (Team Foundation Server) chez Microsoft, tous ont pris le pli des outils de gestion de dépendances (Maven, Gradle…) associés aux outils de gestion de configuration (Git, SVN…).

Mais là encore, force est de constater que la fragmentation du marché JavaScript a frappé. En effet, on n'intègre plus un simple binaire contenant le code client et le code serveur dans une seule et même architecture (ou un même langage). L'amoncellement de frameworks, notamment côté JavaScript, nécessite également une gestion de dépendances côté client. C'est là où interviennent des outils tels que Gulp ou Grunt. Ces outils proposent des plugins permettant de compiler, transpiler, minifier, compresser du code JavaScript ou des fichiers de style CSS (notamment le style dynamique créé avec SASS ou Less). À la différence de Java (avec les JAR) et de .NET (avec les Assemblies), le monde JavaScript ne possède aucun « standard » binaire pour la gestion de modules, c'est du partage de code source. L'outil et le format de packaging le plus utilisé à ce jour est celui de NodeJS avec NPM. N'oublions pas qu'il existe des applications NodeJS entièrement conçues en JavaScript (client et serveur), ces applications-là n'ont nul besoin d'outils Java, NPM assure la gestion des modules côté client et serveur.

Autre outil à connaître dans le monde JavaScript : Bower. Bower est à JavaScript ce que l'outil « apt-get » est à Ubuntu, un gestionnaire de paquets. Il s'assure qu'on dispose de la dernière version des librairies JavaScript en maintenant un fichier local de métadonnées (bower.json).

Enfin, difficile de finir ce paragraphe sans aborder l'outil ultime permettant de simplifier le déploiement d'applications : Docker. Pour schématiser, Docker permet de virtualiser un environnement en réduisant l'étanchéité entre la machine hôte et l'environnement hébergé. En s'appuyant physiquement sur les ressources de la machine hôte il est possible de lancer en quelques secondes un environnement virtualisé. Packager des applications consiste à créer une image contenant l'application métier à déployer, mais aussi les dépendances techniques associées (Apache, logs, serveur d'application, bases de données…). Des places de marché (ou Hub dans le jargon Docker) fournissent toutes sortes d'images « prêtes à l'emploi » dans lesquelles il suffit d'insérer son binaire à déployer (WAR ou JAR). Dans un contexte de microservices (abordé plus loin) et de forte montée en charge nécessitant des déploiements dynamiques et instantanés sans arrêt de service, Docker est un vrai plus.

IV-D - Maven & Gradle

Dans le monde Java, le marché des outils de gestion de dépendances, jusque-là très stable, commence à se fragmenter aussi. Il est passé le temps où Maven jouissait d'une renommée qui le rendait incontestable et incontesté pour les projets Java. Nombreux sont ceux aujourd'hui à pointer sa complexité, ses performances et son approche monolithique plutôt qu'orientée « DSL » comme peut l'être Gradle. Au moment de démarrer un nouveau projet, il vous faudra là encore trancher. JHipster permet de choisir l'un ou l'autre. À titre d'exemple, des éditeurs fournissant des SDK tels que le portail Liferay introduisent désormais Gradle dans leur portefeuille. Eclipse et IntelliJ sont depuis longtemps bilingues. Et comme personne n'ose réellement trancher, la coutume consiste à proposer les deux types de fichiers de configuration : une aberration.

V - La sécurité

La sécurité également a énormément évolué ces dernières années avec l'apparition de nouveaux standards et des modèles sociaux (OAuth notamment https://fr.wikipedia.org/wiki/OAuth). Il existe de multiples mécanismes d'authentification proposant parfois des protections CSRF (https://fr.wikipedia.org/wiki/Cross-Site_Request_Forgery) ou XSS, que ce soit en utilisant un annuaire LDAP, une gestion par session HTTP avec des jetons (JWT…), ou SAML.

À titre d'exemple, dans le monde Java, JHipster demande à l'utilisateur la méthode d'authentification par défaut lors de la génération du projet. Les méthodes basées sur le stockage d'un jeton en session HTTP sont qualifiées de « stateful », les autres (OAuth, JWT…) sont « stateless ». Ce paramètre est important à prendre en compte, notamment lorsqu'il sera nécessaire plus tard de mettre en place la stratégie de répartition de charge. Une application sans état est beaucoup plus simple à multiplier du fait que l'état n'est pas stocké sur un nœud en particulier. Une application stateful nécessite des mécanismes de synchronisation complexes.

VI - La mobilité

La mobilité est le domaine qui a vu le plus grand nombre d'évolutions et d'amélioration. Alors que le marché était largement dominé par les deux mastodontes que sont Google (Android) et Apple (iPhone iOS), la demande commence à converger vers une plus grande unification des technologies. Lorsqu'on ajoute à la fragmentation Web classique des développements spécifiques natifs pour Android et iOS, les coûts explosent du fait de la combinatoire. C'est pourquoi de nombreuses sociétés se tournent aujourd'hui vers le développement hybride consistant à implémenter une application Web traditionnelle packagée comme une application native et conçue pour être « Responsive Design ». En 2016, le Gartner prédit 50% d'applications hybrides avec une tendance s'accentuant dans les années à venir vers plus d'hybride (http://www.gartner.com/newsroom/id/2324917). Côté technologies, l'avantage de l'hybride est de tirer parti des technologies HTML 5 classiques en utilisant des « connecteurs » natifs spécifiques aux mobiles. Parmi ces outils, on trouve PhoneGap/Cordova ou les composants de visualisation HTML (WebView) présents nativement dans la plupart des périphériques.

VII - Les kits d'ergonomie (Material Design, Bootstrap, Apple iOS, Microsoft UWP)

L'autre dimension de cette fragmentation est la partie ergonomique, trop souvent oubliée mais essentielle. Que ce soit Google, Microsoft ou Apple, la plupart des éditeurs cherchent à rendre cohérent le « Look and Feel » de leur application. Comment faire en sorte d'unifier l'expérience utilisateur si les technologies et les frameworks de composants sont fragmentés ? C'est là qu'interviennent les « kits ergonomiques ». Dans la pratique, un kit ergonomique est une spécification de règles ergonomiques. De cette manière, l'utilisateur naviguant dans son Gmail ou Outlook mobile dispose des mêmes boutons et menus navigationnels que lorsqu'il est dans son application métier.

Google avec Android propose le « Material Design » et Apple son ergonomie légendaire iOS. Quant à Microsoft, il fournit UWP pour Universal Windows Platform. Concrètement, un kit ergonomique définit les règles de conception graphique (navigation, placement des contrôles, signification des couleurs, métaphores), mais aussi l'interaction entre le périphérique et l'utilisateur (toucher, transitions, animations…).

Dans ce domaine-là, il faut avouer que les choses se compliquent aussi sérieusement. En effet, le kit visuel ayant eu le plus d'attrait ces dernières années est Bootstrap (http://getbootstrap.com/) produit par Twitter. On ne compte plus le nombre de thèmes, modèles, kits visuels basés aujourd'hui sur Bootstrap. Bootstrap est par défaut « responsive » et a comblé un manque criant ces dernières années dans ce domaine. Mais comment imaginer garder une cohérence sur mobile lorsque d'un côté Google propose Material et de l'autre Twitter propose Bootstrap ? Sans compter les déclinaisons technologiques liées à ces différents kits, chaque framework JavaScript devant supporter a minima ces différentes ergonomies.

Vous l'aurez compris, dans cette fragmentation, la dimension ergonomique ajoute une complexité supplémentaire.

VIII - Les microservices

Avec la généralisation des architectures citées précédemment, le déploiement du cloud à large échelle et la possibilité de bénéficier d'environnements fortement extensibles, une architecture occupe de plus en plus le devant de la scène : l'architecture à base de microservices.

Plébiscitée par la société NetFlix (https://www.netflix.com/fr) qui en est un des précurseurs (en tout cas dans ses concepts les plus communément admis) les microservices consistent à scinder une application monolithique en plusieurs services aux périmètres fonctionnels plus restreints. Objectifs : faciliter la mixité des choix technologiques (on retient la technologie la plus adaptée au service en question), faciliter le déploiement des services unitairement moins complexes, faciliter l'organisation des équipes par bloc fonctionnel.

Les plus anciens reconnaîtront probablement certains concepts inhérents à l'architecture SOA (Service Oriented Architecture). D'autres, encore plus anciens, auront capté des similitudes avec les modèles d'architectures distribuées basées sur Corba ou RMI. Quoi qu'il en soit, les microservices reprennent des idées du passé en y apportant quelques spécificités :

- la communication entre les services est assurée par un mécanisme de messagerie synchrone HTTP, WebSocket…) ou asynchrone (broker de messages, JMS…) ;

- chaque service est isolé, mais aussi interopérable, il possède sa propre base de données ;

- l'annuaire des services n'est pas imposé, de nombreux outils existent sur le marché (Netflix Eureka, Zookeeper, Consul,Etcd…) ;

- la tolérance et la gestion des pannes deviennent une fonctionnalité et non un cas exceptionnel.

En ce qui concerne les outils, plusieurs éditeurs fournissent des solutions « prêtes à l'emploi » permettant de générer des squelettes de projets type « microservices » dans lesquels il ne reste plus qu'à implémenter la logique métier et la base de données, le tout déployé à partir d'un seul binaire (simple JAR dans le monde Java).

Ainsi, SpringBoot offre un environnement intégré comprenant toute la pile Spring, JHipster permet lui de générer des projets types. Dans le monde JEE, des outils tels que KumuluzEE ou Wildfly Swarm proposent le même type de support. Enfin, chez Microsoft, Azure Service Fabric est la pile proposée.

IX - Conclusion

Le but de ce panorama était non seulement de présenter les différentes technologies et architectures dominant le marché aujourd'hui, mais aussi de pointer du doigt la complexité inhérente à la fragmentation. Le règne anarchique des frameworks ne doit pas faire oublier que même si les entreprises ont besoin d'innover, elles ont aussi besoin d'un minimum de pérennité et de stabilité, ne serait-ce que pour des raisons évidentes de coûts. Les fameux schémas directeurs ou paliers technologiques d'antan ne sont plus viables dans le monde d'aujourd'hui. L'obsolescence programmée touche aussi de plein fouet le logiciel qui devient une denrée… jetable. Et que dire de tous ces frameworks JavaScript qui vont se « coboliser » dans quelques années ? Comment former les nouveaux développeurs Web quand les fondations logicielles du moment sont aussi vacillantes et changeantes ? Ce qui est certain, c'est que le métier de développeur n'aura jamais été aussi important.

X - Remerciements

Cet article a été publié avec l'aimable autorisation de Sami Jaber. L'article original (Panorama et fragmentation du développement Web en 2016) a été rédigé par Sami Jaber.

Nous tenons à remercier genthial pour sa relecture orthographique et Malick SECK pour la mise au gabarit.