Ce que la syndication des données produit doit fournir par canal
Les canaux ne sont pas en désaccord sur le produit lui-même. Ils divergent sur la manière de le décrire, et ces désaccords sont banals, précis, et constituent le cœur du travail.
- Structure des champs : un canal exige une description unique, un autre des listes à puces, un troisième des variantes courtes et longues avec des limites de caractères distinctes
- Taxonomie des catégories : chaque place de marché gère sa propre arborescence, et le même produit se retrouve dans un nœud différent sur chacune d'elles
- Attributs obligatoires : une place de marché peut rejeter une fiche sans un champ de certification spécifique qu'aucun autre canal ne demande
- Spécifications des médias : dimensions des images, arrière-plans, et nombre d'angles autorisés ou requis
- Unités et formats : dimensions en centimètres ou en pouces, poids en kilogrammes ou en livres, dates dans l'ordre attendu par la destination
Rien de tout cela n'est difficile isolément. Cela devient coûteux car l'opération se répète pour chaque canal, c'est pourquoi les intégrations PIM ne s'arrêtent que rarement au système de gestion des informations produit lui-même. Toute modification du produit source implique de revoir chaque destination où il est diffusé.
Pourquoi un seul produit finit-il par avoir six versions ?
Le premier canal récupère les données produit directement à la source. Le second en utilise une copie, généralement parce que la rapidité de lancement a primé sur la centralisation des données. À partir de là, il existe deux sources de vérité sans aucune règle pour déterminer laquelle fait autorité.
Les corrections sont ensuite effectuées là où l'erreur a été constatée. Un agent du support corrige une dimension erronée sur la boutique en ligne suite à une plainte client. Personne ne corrige cette erreur sur la marketplace, car personne ne s'en est encore plaint. Six mois plus tard, les deux enregistrements divergent et il est impossible de savoir lequel est le bon.
L'enrichissement rend cette fragmentation permanente. Le marketing rédige de meilleurs contenus pour le canal à fort volume, car c'est là que le retour sur investissement est le plus élevé. La meilleure version du contenu produit se retrouve isolée, tandis que les autres canaux conservent la version originale, rendant le catalogue non seulement incohérent, mais aussi inégal en termes de qualité.
Le coût de maintenance d'un catalogue par canal
La maintenance d'un catalogue par canal est rarement budgétisée, car elle est répartie entre plusieurs collaborateurs qui y consacrent chacun un temps jugé négligeable.
- Retards de lancement : une nouvelle gamme arrive à temps sur la boutique principale, mais avec plusieurs semaines de retard sur les autres canaux, car chaque mise à jour est manuelle
- Fiches produits rejetées ou supprimées : une marketplace refuse des produits auxquels il manque un attribut obligatoire, et personne ne s'en aperçoit avant que les ventes de ces articles ne s'arrêtent
- Retours causés par les données : une dimension erronée ou une spécification obsolète entraîne un retour que le produit lui-même ne méritait pas
- Canaux inexploités : une marketplace pourtant rentable est écartée car personne ne peut assumer la charge de maintenance d'un catalogue supplémentaire
Ce dernier point est le plus coûteux, car il n'apparaît jamais comme une dépense directe. Il se dissimule derrière une stratégie de canaux qui semble être un choix délibéré. La même logique comptable s'applique à l'intégration marketplace, où le développement est chiffré, mais pas la maintenance.
Trois approches sont courantes pour gérer la distribution, et chacune atteint ses limites. Un PIM conserve efficacement l'enregistrement de référence et l'exporte vers un ensemble fixe de destinations, ce qui nécessite un développement spécifique pour tout canal inhabituel. Les outils de gestion de flux gèrent correctement les marketplaces et les comparateurs, mais ne se connectent généralement pas à l'ERP pour les stocks et les prix. La gestion manuelle de chaque canal est ce que font réellement la plupart des entreprises, et c'est la raison pour laquelle le nombre de canaux ne progresse plus.
Comment une plateforme d'intégration gère-t-elle la syndication des données produit ?
Une plateforme d'intégration en tant que service (iPaaS) repose sur un principe simple : la fiche produit est stockée une seule fois et remodelée à la sortie. Le PIM ou l'ERP demeure la source de référence, et chaque canal reçoit la version dont il a besoin sans qu'il soit nécessaire de maintenir un catalogue spécifique pour chacun d'eux.
Le remodelage est l'étape cruciale, et il va bien au-delà du simple reformatage. La taxonomie d'une marketplace doit être mappée nœud par nœud et ses attributs obligatoires vérifiés avant tout envoi. Effectuer ce travail pour chaque destination et détecter un rejet avant même que le canal ne le fasse est une tâche qu'une exportation planifiée ne peut accomplir.
Alumio est une plateforme d'intégration de ce type, conçue pour remodeler une fiche par destination plutôt que d'en stocker plusieurs. La plateforme d'intégration Alumio y parvient de quatre manières.
- Une fiche, de multiples formats : un transformateur de données au sein d'Alumio convertit le produit de référence selon la structure, la taxonomie et les unités de chaque canal, afin que les formats des canaux n'imposent jamais la manière dont le catalogue est stocké
- Des mises à jour déclenchées par le changement : un flux de données piloté par les événements envoie une spécification corrigée à chaque canal proposant ce produit, sans attendre que quelqu'un se souvienne des canaux concernés
- Des rejets détectés en amont : des règles de validation vérifient les attributs requis par chaque canal avant l'envoi d'une fiche, permettant ainsi de détecter un champ de certification manquant à la frontière plutôt que de constater une baisse des ventes
- Traçabilité par canal : des journaux détaillés enregistrent quelle version d'un produit a été envoyée, où et quand, ce qui permet d'expliquer toute divergence dans une fiche produit
La configuration gère les règles de mappage et de taxonomie, et l'iPaaS Alumio propose un transformateur de code pour les cas où l'écriture de code est plus efficace que la configuration. Dès le troisième ou quatrième canal, la majeure partie du mappage est déjà en place, une affirmation qui mérite d'être testée.
Syndication des données produit pour 25 000 produits et deux modèles de vente
Les grossistes sont confrontés au problème de la syndication plus tôt que la plupart des détaillants, car ils gèrent un plus grand nombre de produits et les vendent via davantage de canaux simultanément.
AGU est un grossiste et détaillant néerlandais d'articles de cyclisme basé à Alkmaar, comptant plus de 160 employés et plus de 25 000 produits, opérant à la fois en B2B et en B2C. Son écosystème utilise Centric comme ERP, Akeneo comme PIM et Adobe Commerce comme boutique en ligne.
AGU a connecté Centric à Akeneo pour les produits, catégories, attributs et modèles de produits, et Centric à Adobe Commerce pour les stocks, les prix et les données de commande, via l'iPaaS Alumio. Ce qui compte pour la syndication, c'est le traitement subi par les données en cours de route. Les entités ont été normalisées lors de leur transfert, spécifiquement pour permettre l'ajout ultérieur de nouveaux canaux sans avoir à refaire le travail de mappage. Le catalogue n'a jamais eu besoin d'être restructuré pour s'adapter à une destination particulière.
Ce que la syndication des données produit apporte à un détaillant
La syndication des données produit est généralement justifiée par l'efficacité, mais l'efficacité ne représente que la partie émergée de l'iceberg. Le véritable avantage réside dans les nouveaux canaux qui deviennent exploitables.
Ces trois rôles perçoivent les choses différemment. Le responsable e-commerce gère la boutique en ligne et subit les retards lorsqu'une gamme arrive tardivement ailleurs. Le responsable du contenu produit maintient la base de données et doit s'adapter à chaque nouveau format. Le responsable de marketplace ou de canal est celui qui finit par ne plus proposer de nouveaux canaux, car chacun d'eux représente une charge de maintenance plutôt qu'une simple mise en correspondance.
Lorsqu'ajouter une marketplace ne coûte qu'une simple mise en correspondance, la décision devient commerciale plutôt qu'opérationnelle. Une plateforme d'intégration rend cette mise en correspondance suffisamment abordable pour que cela soit possible. La stratégie de canal est alors dictée par l'emplacement des clients plutôt que par les capacités d'absorption du catalogue.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
