Pourquoi Vaisonet s’appuie sur les webservices natifs pour E-connecteur

Régulièrement, mes clients me demandent pourquoi nous avons fait le choix technologique de gérer les échanges de flux de données via des web services et non via un module qui viendrait compléter le CMS. Cela m’a donné envie d’écrire un article à ce sujet pour expliquer comment cela fonctionne et quels bénéfices en découlent pour les e-commerçants qui utilisent notre E-connecteur.

Disposer d’une architecture robuste basée sur des services indépendants

Les plus technophiles auront déjà entendu parler de Docker, un système de conteneur permettant de gérer des micro services informatiques. C’est une tendance forte en informatique qui consiste à cloisonner une application métier en plusieurs petits services autonomes. L’ensemble de ces services constitue l’application métier en elle-même.

C’est ce principe que nous utilisons pour notre E-connecteur quand nous travaillons avec les web services. L’objectif de travailler par petit service indépendant autonome est d’améliorer la robustesse globale, la résilience et l’évolutivité de l’application.

Quand il y a besoin de réaliser une évolution sur une partie de l’activité, il suffit de travailler sur le micro-service concerné (en l’occurrence les web services). Les autres services ne sont pas impactés et les risques d’impacts et d’effets de bord sont donc minimisés.

Si un service rencontre une anomalie, ce qui peut toujours arriver, son identification est plus rapide et plus simple. Pas besoin de rechercher « qui fait quoi » ni comment cela interagit, contrairement à ce qui se passerait dans le cadre d’une application qui aurait une imbrication forte avec plusieurs systèmes.

A l’image de la conteneurisation de Docker, le premier avantage à utiliser un web service plutôt qu’un module réside dans le fait que les fonctionnalités n’étant pas réparties entre l’applictaion et le module, les applicatifs sont cloisonnés et en cas d’anomalie, la panne est localisée et résolue plus rapidement.

Cela n’empêche pas d’avoir des échanges techniques, mais la responsabilité des actions à mener est connue car elle suit le découpage des services.

Obtenir une intégration parfaite avec le CMS utilisé

Tous les CMS ont des mécanismes de gestion d’événements, généralement appelés « hooks » qui permettent au CMS ou à des modules additionnels de réagir à un événement. Par exemple, si vous venez de vendre sur la boutique le dernier produit, il faut informer la marketplace Amazon de ce statut pour ne pas avoir à payer de pénalités. Autre cas courant, lors de la création d’un compte client, il faut lancer un processus d’on-boarding. Nativement, ces hooks sont très nombreux et ils sont désormais dynamiques, puisque qu’il est possible d’en créer pour répondre à des besoins particuliers.

Quand on utilise un web service natif, tous les hooks sont nativement lancés sans risque d’en oublier, ce qui n’es pas le cas lorsque l’on utilise un module.

Faciliter la maintenance de l’ensemble et renforcer la sécurité du site

Utiliser le web service du CMS, c’est aussi avoir 0 ligne de code à ajouter, à auditer, à vérifier, à mettre à jour dans le CMS et/ou dans l’ERP. ce qi se révèle bien plus pratique, sûr et fiable. Les web services fonctionnant comme une boite noire, indépendante des applicatifs avec lesquels ils interagissent, la maintenance est réduite. Le site e-commerce est également plus sécurisé et plus stable car il n’est pas impacté par les évolutions.

Des limites techniques très faibles

Certains détracteurs des web services mettent souvent en avant limites techniques. Ne nous voilons pas la face, tout système a ses limites. Mais celles qui sont évoqués ci-après ne restreignent pas forcément les possibilités du E-connecteur.

La première limite généralement évoquée est la capacité technique du web service. Dire que certaines fonctions d’un web service donné ne sont pas disponibles, dans tous CMS (Prestashop, WooCommerce ou même Shopify), est généralement faux. Techniquement, les web services sont issus des mêmes classes qui gèrent les fonctionnalités dans un back office (ou le front office) et les méthodes sont donc rigoureusement les mêmes. Le tout est de le savoir et d’être formé sur ces outils. C’est le cas de notre équipe qui a développé une expertise dans ce domaine.

La deuxième limite évoquée est celle du volume de données. Prenons un exemple concret. Imaginons un site e-commerce avec 5000 clients et 5000 produits et des remises dégressives selon 5 paliers de quantité. Il existe sur le site, en théorie, 5000x5000x5 = 125 millions de possibilités tarifaires. Cela peut paraître énorme. Sauf que, dans ce cas, le vrai problème n’est pas de gérer un flux de 125 millions de lignes via un web service mais bien se demander si ces 125 millions de possibilités tarifaires sont vraiment utiles et si elles seront réellement exploitées sur le site !

Aucun CMS e-commerce n’est capable de gérer nativement une telle volumétrie en conservant des performances front et back acceptables. Aussi, il devient nécessaire, dans ce cas, de revoir la stratégie « technique » de gestion des tarifs au sein du CMS pour qu’il en supporte la volumétrie. Si vous revoyez ces éléments et répercutez cette stratégie sur le web service, celui-ci supportera sans problème et sans latence un tel volume.

Pour conclure, nous sommes convaincus, en tant d’experts de la gestion des flux de données, qu’il y a bien plus d’avantages à utiliser les web services natifs de votre CMS e-commerce préféré que d’inconvénients. A condition toujours d’être bien accompagné pour la création de votre site !

Que vous soyez revendeur informatique ou agence web, n’hésitez pas à nous contacter si vous souhaitez ne savoir plus sur toutes les possibilités offertes par notre technologie de gestion des flux et notre E-connecteur.