Pourquoi développer un site internet en mode découplé ?

C’est bien connu, le monde du web n’attend pas la nouvelle année pour évoluer. D’où la nécessité pour les acteurs du milieu de savoir constamment se réinventer, évoluer, pour ne pas tomber dans la désuétude. Ce n’est pas pour rien si les termes "réactivité, agilité, scalability" font désormais partie de notre quotidien.

A l'occasion d'une future refonte ou lors de l’élaboration de votre cahier des charges, vous viendrez forcément à vous poser les questions suivantes : Quelle(s) technologie(s) utiliser ? Pour quel(s) résultat(s) ? Les réponses vont dépendre de différents critères, s’agit-il d’une création ou d’une refonte (donc de l’existant), délais de mise en place… Pour discuter régulièrement avec des e-commerçants, les choix se résument souvent à : Magento, Prestashop ou Shopify. Ce sont les 3 solutions les plus utilisées en France, et se passer d’un CMS est souvent impensable et cela semble tellement compliqué et coûteux (et les agences pour la plus grande majorité utilisent des CMS).

Dans notre cas, l’objectif était d’intégrer un nouveau site e-commerce à notre suite applicative existante (basée sur le framework php Laravel). Nous avions donc déjà toutes les briques du site e-commerce, de la même façon que sur un CMS grand public comme Prestashop ou Magento. Si nous avons utilisé Laravel en backend et Angular Universal en frontend, nous aurions tout aussi bien pu partir sur le CMS Magento et React en frontend par exemple. Le principal inconvénient d’avoir une application dite “monolithique” comme la nôtre est le manque d’agilité que cela engendre. En effet, les mises à jour sont lourdes et entraînent un coût de maintenance élevé puisqu’elles nécessitent une mise à jour complète de l’application (même si les modifications ne touchent qu’une petite partie de l’application). De plus, si l’on veut garder des performances correctes, on se retrouve forcément limité dans l’utilisation des technologies pour le front-office. 

Comment fonctionne une architecture découplée ?

Le principe de l’architecture découplée ne vous est certainement pas inconnu, que vous soyez développeur ou que vous travaillez dans le web, vous avez forcément entendu parler des systèmes d’API dit “RESTFull”. Que vous travaillez avec une agence pour maintenir votre site web ou que vous le fassiez en interne, vous avez certainement remarqué qu’une fois le backoffice de votre application fonctionnel, la majorité des mises à jours concerne le front-office. En effet, on constate une durée de vie du simple au double entre le front et le back office :

-5 à 10 ans pour le back
-2 à 3 ans pour le front-on voit qu’ici encore, le principe du SoC (Séparation of Concerns) prendrait tout son sens.

La principale différence de notre architecture découplée est le format de fichier que le serveur rend. Forcément, un fichier JSON sera plus léger et rapide à interpréter qu’un fichier PHP. De plus, cela permet d’éviter tout rechargement de page puisque le contenu est directement mis à jour dans l’application exécutée coté client. C’est donc ce que nous avons mis en place sur le site de Polytrans.

Si vous avez bien suivi jusqu’ici ou si vous avez déjà mis en route une application Javascript, vous vous rendez certainement compte qu’un problème va se poser et pas des moindres dans le cas d’un site e-commerce : le référencement ! Le SEO devient plus rapide, plus agile et plus facile à mettre à jour.

Des mises à jour en un clin d’oeil

En effet, si le code est mis à jour côté client, et que le serveur renvoie du JSON, comment va-t-on nourrir les robots des différents moteurs de recherche ?

C’est là qu’entre en scène le SSR (Server Side Rendering), qui comme son nom l’indique est une technologie permettant de générer les pages HTML requises pour le référencement du site web côté serveur (avec node.JS). On peut donc finalement tirer avantage de ce qui était initialement une problématique. On obtient donc une application, mais ce n’est pas tout. En plus de grandement améliorer l’expérience utilisateur, on va également pouvoir lui proposer une toute nouvelle expérience : la PWA (Progressive Web App).

Les PWAs sont des applications hybrides ultra-légères qui reprennent les fonctionnalités de votre site web en y ajoutant la brique applicative (possibilité d’envoyer des notifications PUSH, icône sur l’écran d'accueil, gestion du offline...). Il s’agit en gros de la version enrichie d’un site responsive, qui remplacera dans la majeure partie des cas une application native.

En tant que lead-développeur, je vois un autre avantage à ce type d’architecture : l’attrait que cela peut engendrer dans les équipes. En effet, les technologies front end ont le vent en poupe depuis quelques années, en choisissant une technologie de pointe comme celle-ci, vous vous assurez d’attirer facilement de nouvelles ressources humaines.

Grâce au principe de workspace sur Angular, nous allons facilement pouvoir partager ces évolutions techniques avec notre autre site e-commerce : La ferme des animaux. En effet, la majorité des composants de notre application seront utilisés de la même manière sur les différents points de vente. Les principales différences sont dans le style et la structure du contenu de la page. Pour illustrer le gain de temps de travailler en mode découplé, imaginez que vous êtes sur un CMS multiboutique, vous développez ou faites développer une évolution (ajout d’un module de devis par exemple). Une fois l’intégration faite sur un des thèmes de votre CMS, vous devez réitérer l’opération sur le thème utilisé par l’autre site. Vous augmentez donc le temps d’intégration et de mise à jour de l’application par le nombre de site hébergé. Avec le système découplé, une fois le composant crée pour l’un des sites, il est directement disponible pour les différents sites, il ne reste qu'à ajuster le style et la structure du contenu. Des contraintes, forcément…

"Chaque difficulté rencontrée doit être l’occasion d’un nouveau progrès" - Pierre de Coubertin

Il est évident que mettre en place ce genre d’application est plus contraignant et représente plus de travail initialement qu’un simple CMS. Il sera plus coûteux aussi bien en temps de développement qu’en coût d'hébergement qu’un site monolithique. En effet, quelle que soit l’architecture de votre SI (Système d’information), il faudra l’adapter pour faire fonctionner votre site découplé. Il faudra également dupliquer votre méthode de déploiement, notamment sur vous utilisez l’intégration continue. Pour les ressources humaines également, même si ces technologies ont le vent en poupe, vous aurez plus de mal à trouver des ressources expertes sur le sujet, et ce qui est rare est cher, forcément... 

Cette technologie peut s’appliquer à n’importe quel projet Web, en la couplant sur un hébergement basé sur les micro-services, comme AWS ou Google Cloud, vous obtiendrez une application réactive, facile à mettre à jour, scalable, et très performante. Plus que jamais, dans le cas d’architecture découplée, la mise en place d’une stratégie de CD (Continuous Deploiement) est très importante. En effet, si une typo s’était glissée dans votre déploiement, empêchant ainsi l'exécution de l‘application, il vous faudra recompiler entièrement l’application, ce qui peut prendre un peu de temps. (Le temps paraît encore plus long quand votre site est down !). Si dans certains cas, le choix de l’architecture découplé est une nécessité (si vous souhaitez avoir une expérience utilisateur très poussée par exemple), dans la majorité des cas, cela reste un plus, mais un plus qui peut faire la différence.