Dans tout projet e-commerce, la question légitime et sensible de la refonte d’une boutique en ligne peut se poser tôt ou tard. Pour quelles raisons ? Une plate-forme de vente en ligne bâtie sur une solution vieillissante, qui n’est plus à jour sur les standards du web d’aujourd’hui, ou encore des besoins exprimés par les consommateurs qui nécessitent de basculer son e-shop sur une solution plus flexible. Avec l’émergence de nouvelles solutions en mode SaaS comme Shopify ou encore BigCommerce, de solutions CMS de vente en ligne comme Woocommerce de WordPress, ou encore les solutions e-commerce françaises comme Prestashop ou encore Wizishop, les possibilités sont nombreuses. On accueille aujourd’hui le retour d’expérience d’une migration e-commerce réalisée par l’entreprise Polytrans.fr, qui revient sur toutes les étapes clés depuis la prise de décision de refondre leur site existant jusqu’aux choix techniques décidés par l’équipe e-commerce.
Sur internet, tout va très vite, il est donc important de progresser et de proposer de nouvelles fonctionnalités sur son site internet. Cela passe par de nouveaux produits, de nouveaux services, mais aussi pour un visuel plus agréable et mieux pensé, et arrive tôt ou tard la question de la refonte de site web. Vous devez forcément déjà avoir entendu parler des termes suivants : agilité, scalability, réactivité…
En ce début d’année, comme de nombreux e-commerçants, vous pensez que c’est le moment idéal pour refaire votre site. Vous êtes donc en train de réaliser un cahier des charges complet, que ce soit pour une agence, un freelance ou pour vos développeurs en interne. Oui mais une refonte doit avoir un but :
– Dans quel(s) but(s)
– Quelle techno utiliser
– Sous combien de temps
Bien entendu, il faut prendre encore plus le temps de la réflexion dans le cadre de la création d’un site internet. Car dans le cadre d’une refonte, il n’est pas toujours simple de changer de technologies, mais pas impossible ! Lorsque l’on discute avec des e-commerçants, on se rend compte que la très grande majorité utilisent les CMS suivants : Magento, Prestashop ou Shopify (qui commence à percer). Et la plupart du temps, les agences ne cherchent pas à proposer autre chose, peu proposent une solution maison ou qui pourrait sortir des sentiers battus.
La refonte du site Polytrans.fr avait différents buts :
Basée sur le framework php Laravel, cette suite avait déjà toutes les briques nécessaires au bon fonctionnement d’un site ecommerce :
Il était possible de partir sur une solution alternative, comme par exemple se baser sur le CMS Magento et React pour la partie Front. Néanmoins, une application ‘monolithique’ a différents inconvénients comme le manque d’agilité :
De nombreux e-commerçants seront confrontés à ce genre de problématique. La solution utilisée dans le cas de Polytrans est la suivante : l’architecture découplée.
Si vous êtes un développeur confirmé (ou même en devenir), vous connaissez certainement les systèmes d’API dit “RESTFul”. Ce type de solution peut donc être envisagée aussi bien en agence que chez le client.
Vous le savez, dans la très grande majorité des cas, vous allez commencer par développer votre site ecommerce par le Back Office. Cela est normal, par contre, une fois qu’il fonctionne, vous n’allez pas le toucher pendant longtemps (depuis quand n’avez-vous rien ajouté sur votre Prestashop en Back ?). La plupart des mises à jour se feront au niveau de la partie visible du site web. Il n’est pas rare de rester sur la même version d’un CMS mais de changer plusieurs fois de design (car cela a un rôle direct sur le taux de conversion et donc sur votre chiffre d’affaire).
Vous ne serez donc pas étonné de voir qu’un Back Office durera deux fois plus longtemps que le front :
Le SoC (Separation of Concerns) prend donc tout son intérêt lorsque l’on a affaire à ce genre de problématique. Comme un schéma est toujours mieux qu’un long discours, voici les différences entre les deux structures :
Le gros avantage d’un fichier JSON par rapport à un fichier php, c’est sa légèreté ainsi que sa rapidité à être interprété. Ains, vous allez éviter le rechargement des pages afin de gagner en temps de chargement (car tout le contenu de la page est mis à jour via l’appli qui est exécutée au niveau du client).
Si vous avez déjà mis en place une application Javascript, vous avez déjà été confronté au problème suivant : le référencement naturel !
Vous l’aurez compris, les clients vont apprécier le fait de consulter un site internet qui se charge rapidement. Mais c’est aussi le cas des moteurs de recherche qui prennent à juste titre ce critère comme étant important pour le classement des sites internet.
Par contre, il faut prendre en compte le fait que le code est mis à jour depuis le navigateur du client. Le serveur lui va renvoyer le JSON, mais quid des moteurs de recherche ?
Heureusement, il existe une solution : le Server Side Rendering (plus connu sous le nom de SSR). Cette techno permettra donc de générer des pages au format Html pour le référencement du site web du côté serveur (via nodeJS).
Mais ce n’est pas tout, car vous allez également pouvoir mettre en place la PWA (Progressive Web App) qui à termes pourrait remplacer les applications.
Ces applications ont pour particularité d’être vraiment légères et également d’être plus simple niveau maintenabilité et mise à jour.
Vous pourrez ainsi retrouver toutes les fonctionnalités de votre site internet tout en ajoutant des briques vraiment pertinentes :
Mais ce n’est pas tout, car le fait d’avoir plusieurs sites internet permet également de rentabiliser le temps passer. Prochainement, ce sera le cas de lafermedesanimaux.com qui sera retravaillé sur la même structure.
Quel que soit le point de vente, les composants créés pour notre application pourront ainsi être utilisés. Les changements se situeront au niveau du Front afin de permettre aux internautes de faire la différence entre les deux sites internet.
Cela revient sur le principe d’un CMS qui utilise le multi-boutique, vous allez demander à votre agence de développer une fonctionnalité (par exemple la gestion de devis), une fois intégré sur un de vos sites, vous pourrez réitérer sur un autre.
Le gain de temps (et donc d’argent est énorme) puisque vous allez réduire considérablement le temps d’intégration (ainsi qu’au niveau des mises à jour).
Donc une fois que vous aurez développé un composant, il sera de suite disponible pour tous vos autres sites.
« La difficulté attire l’homme de caractère, car c’est en l’étreignant qu’il se réalise lui-même. » Charles de Gaulle
Ce type de solution a de nombreux avantages, néanmoins, il faut avoir en tête les contraintes. En effet, mettre en place ce genre d’application demande bien plus de travail que d’utiliser un simple CMS déjà tout prêt. Niveau développement, cela demandera donc un budget plus important, et l’hébergement d’un site coutera également plus cher.
Si vous utilisez l’intégration continue, vous devez également dupliquer votre méthode de déploiement. Egalement, même si au niveau du recrutement, vous aurez plus de facilité à attirer des profils, il existe un côté négatif. Vous aurez plus de difficultés pour trouver des profils ayant ces compétences (niveau expert), et ce qui est rare est cher…
Comme évoqué plus haut, il existe des différences entre ce qui sera interprété du côté du serveur et ce qui sera ensuite exécuté côté client (via le navigateur).
Louis Rocher a donc développé une Directive (classe sous Angular) qui permet d’ajouter du Lazy Load côté Front (donc qui agit au niveau des images).
Une fonctionnalité connue de tous qui permet de charger les images au fur et à mesure de la navigation de l’internaute (ce qui permet encore de réduire le temps de chargement de la page).
Comme vous pouvez le remarquer dans le code source, cette méthode implique l’utilisation de l’objet ‘window’. Et comme vous le savez certainement, il est utilisable du côté partie client, mais pas de côté serveur (il ne sera donc pas interprété).
Angular dispose heureusement des méthodes isPlatformBrowser et isPlatformServer. Ce qui donnera donc :
Ainsi, le code sera exécuté par le navigateur du client et non par le SSR.
Vous le savez, chez E-Works, nous vous proposons des formations webmarketing, car nous sommes convaincus qu’il est important de se former afin de progresser. En choisissant des technologies d’avenir, vous allez notamment pouvoir vous démarquer que ce soit sur votre CV mais aussi lors des entretiens d’embauche. Les recruteurs aiment les profils qui vont au bout des choses et qui ne cessent de se tenir informé, l’architecture découplée est un très bel exemple.
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 faudrait 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 !
Merci à Louis Rocher, développeur web Fullstack depuis 2014 pour la rédaction de cet article. Après avoir travaillé pendant 3 ans dans une agence web basée à Saint-Etienne, il a rejoint l’agence Livepoint en 2017 comme lead-développeur, et s’est occupé de la refonte e-commerce du site Polytrans.