Note: This is part 1 in our series of posts about how Syndigo’s futuristic approach to its architecture benefits our customers.
Primitive digital commerce systems were designed for primitive commerce
Historiquement, les systèmes de commerce numérique existaient en tant que monolithes isolés dans le paysage des systèmes d’entreprises vendant des produits ou des services. Non seulement toutes les données nécessaires existaient dans ces systèmes, mais ils fournissaient également toutes les fonctionnalités essentielles : calcul des prix, remises, fonctions permettant d’enrichir les données relatives aux produits, fonctionnalités mineures de système de gestion de contenu (SGC), etc. Le front-end (l’interface avec le client) et le back-end (le serveur, la base de données et la logique commerciale) du système étaient étroitement intégrés.
L’intégration entre l’e-commerce et d’autres systèmes était elle aussi primitive. Il n’y avait aucun moyen de vérifier la précision des stocks et la cohérence des prix sur les différents canaux par exemple, car tous les canaux fonctionnaient indépendamment les uns des autres. Il s’agissait d’un véritable paysage composé de plusieurs systèmes monolithiques différents plus ou moins désynchronisés.
L’évolution a été dictée par les préférences des clients
Cependant, lorsque les consommateurs ont commencé à exiger de meilleures expériences, les fournisseurs ont dû s’adapter. Les consommateurs réclamaient un meilleur contenu et de meilleures informations sur les produits, mais plus simplement, de meilleures incitations à leur fidélité à l’entreprise. Il fallait donc améliorer la communication entre les systèmes (et les canaux). Par exemple, il est devenu nécessaire de disposer d’un système unique pour calculer le prix pour un client donné et ce, pour tous les canaux ! Il est devenu nécessaire de connaître le nombre exact d’articles en stock avant de passer la commande. Il est devenu nécessaire de traiter immédiatement la commande dans le système de gestion des commandes (OMS) sous-jacent, qu’il s’agisse d’un grand ERP monolithique ou d’un système OMS distinct.
Au fur et à mesure que les technologies web progressaient, les API (interfaces de programmation d’applications) se sont généralisées. Elles ont permis d’améliorer l’échange de données et l’intégration entre différents systèmes. Les plateformes d’e-commerce ont commencé à proposer des API pour permettre aux développeurs tiers de créer des front-end personnalisés ou de s’intégrer à d’autres systèmes.
Ce fut un véritable pas en avant et un véritable moteur pour le prochain changement au sein de l’e-commerce : le passage du multicanal à l’omnicanal. Ce fut une étape importante vers la création d’une expérience client plus cohérente sur tous les canaux. Mais l’autre moteur de l’évolution, plus important encore, fut la quantité, la taille et la vitesse des données. Les systèmes existants n’ont tout simplement pas été conçus pour gérer des demandes de l’ampleur de celles que nous connaissons aujourd’hui. Il y avait une demande croissante pour des expériences d’e-commerce plus flexibles et personnalisables.
Le commerce headless fut l’étape suivante dans l’évolution du commerce numérique.
Une brève analogie pour décrire l’architecture headless
Une façon simple de penser au sans tête est de penser à un scénario dans lequel vous avez besoin de faire livrer vos courses. Vous disposez probablement d'une application dans laquelle vous sélectionnez quelques éléments et quelques minutes plus tard, ils apparaissent à votre porte. Mais que se passe-t-il lorsque vous cliquez sur ce bouton ? Vous avez besoin de deux choses: quelqu'un pour parcourir le magasin et faire vos courses et quelqu'un pour conduire du magasin à votre domicile et les livrer.
Il existe une version de ce processus dans laquelle celui qui achète et celui qui livre sont une seule et même personne.
Mais imaginez que ce ne soit pas le cas. Vous seriez en mesure d’obtenir la meilleure personne non seulement pour faire vos courses mais aussi pour vous les livrer. Si celle qui livre devait déménager ou démissionner, vous pourriez la remplacer et demander à la personne qui fait les courses de les remettre au nouveau livreur en toute transparence.
C’est ce que l’on appelle l’architecture headless. Il s’agit d’une approche moderne de l’architecture e-commerce dans laquelle le front-end (l’interface orientée vers le client) et le back-end (la base de données, la logique commerciale et la logistique) d’une boutique en ligne sont couplés de manière souple ou séparés. Ce découplage permet davantage de flexibilité, d’évolutivité et de personnalisation dans la fourniture d’expériences d’achat numérique.
Cette séparation a été rendue possible grâce aux API, qui ont permis de développer des front-ends personnalisés à l’aide de diverses technologies comme les cadres JavaScript (par exemple, React, Vue.js) ou les applications mobiles, et de faciliter la communication et l’échange de données entre les composants front-end et back-end.
Comment Syndigo PIM opère l’architecture headless
Dans tout système PIM, quelques fonctions clés sont indispensables.
- Le système doit être en mesure de définir la nature des données (le schéma).
- Il doit être capable d’embarquer les données et de les stocker.
- L’utilisateur doit pouvoir effectuer une recherche sur les données.
- Le système doit être en mesure de valider les données, c’est-à-dire de vérifier qu’elles sont complètes et exactes.
- Enrichissement du contenu, si possible par l’automatisation
- Syndication?
Traditionnellement, ces fonctions sont intégrées dans une application unique qui répond de bout en bout aux besoins de l’utilisateur. À première vue, cette méthode semble suffisante. Mais avec le développement de nouvelles technologies et de nouveaux processus, toute mise à jour de l’application nécessiterait une refonte massive et coûteuse. Il faudrait réécrire l’ensemble de l’application pour améliorer la capacité de recherche. Et encore plus tard, quand il existera une meilleure façon d’enrichir le contenu. Et encore une fois lorsque la fonction de recherche sera perfectionnée.
Au lieu de cela, l'approche de Syndigo en matière de PIM propose ces services sous forme de modules reliés par des API. Ainsi, lorsqu’il est nécessaire ou souhaitable d’améliorer l’exécution de la fonction de recherche, seul ce module doit être mis à jour. Le reste de l’application reste inchangé. De cette manière, l’utilisateur se voit toujours proposer la meilleure configuration possible de cette application.
Même en dehors de la solution PIM elle-même, le client bénéficie de la souplesse nécessaire pour configurer son paysage e-commerce dans son ensemble grâce au couplage lâche avec la PIM. Les mises à jour des modèles de données dans la PIM peuvent circuler en amont ou en aval par l’intermédiaire d’interfaces de modification de modèle. Il est possible de modifier le moteur de tarification ou l’interface web du système d’e-commerce sans avoir à s’inquiéter des modifications à apporter à l’ensemble de la pile technologique, comme c’est le cas avec un fournisseur monolithique. Avec l’approche de Syndigo, nos clients disposent d’une solution PIM de pointe pour leurs besoins commerciaux et sont en mesure d’adapter et d’améliorer leur technologie selon leurs besoins, avec un minimum d’interruptions. Contactez-nous pour en savoir plus sur la façon dont l’approche headless de Syndigo peut vous aider non seulement à rationaliser les fonctionnalités de votre PIM, mais aussi à vous donner les moyens de vous adapter et de prospérer dans un marché numérique en constante évolution
