Le commerce unifié (unified commerce) signifie que chaque canal de vente lit et écrit les mêmes données commerciales : une fiche produit, un chiffre de stock par site, un historique de commandes, un profil client et un seul jeu de prix et de promotions. Le webshop, la caisse du magasin, l'offre sur la marketplace et l'écran du service client sont des vues sur ces données, pas des copies séparées maintenues à jour par des tâches de synchronisation et des tableurs.
L'omnicanal décrit ce que vit l'acheteur : acheter en ligne et retirer en magasin, retourner n'importe où, le même prix sur tous les écrans. Le commerce unifié décrit le back-end qui permet de tenir ces promesses sous la charge. Tu peux faire tourner une expérience omnicanale sur des systèmes faiblement connectés pendant un temps ; le commerce unifié, c'est le moment où ces systèmes cessent de se contredire. Si tu veux d'abord les bases de la stratégie de canaux, commence par notre article précédent sur omnicanal vs multicanal.
Une définition concrète du commerce unifié, donnée par donnée
La plupart des définitions restent abstraites (« une seule plateforme », « une vue unique »). Il est plus utile de nommer les données qui doivent être partagées, car c'est ce que tu peux tester. Une entreprise pratique le commerce unifié quand chacune de ces cinq données a un seul propriétaire et que chaque canal utilise cette version :
- Fiche produit : identifiants (SKU, GTIN, ID de variante), titres, descriptions, attributs, images et catégorie, gérés une fois et publiés sur chaque canal.
- Données de stock : stock par site (entrepôt, magasin, dropshipping fournisseur), avec réservations, pour qu'un article vendu en magasin ne soit pas aussi vendu en ligne.
- Données de commande : toutes les commandes de tous les canaux au même endroit, avec leur statut, leur lieu de préparation et leur historique de retours.
- Données client : un profil par personne, couvrant comptes en ligne, fidélité, tickets de caisse en magasin et contacts avec le service client.
- Données de prix et de promotions : prix catalogue, prix par canal et promotions actives, avec des règles qui précisent où chacun s'applique.
Les paiements sont souvent ajoutés comme sixième donnée : paiements en ligne et en magasin traités par le même prestataire, pour qu'un remboursement puisse revenir sur la carte d'origine quel que soit le lieu du retour. Le point commun : aucun canal ne possède sa propre copie privée de ces données.
Commerce unifié vs omnicanal : expérience contre architecture
Les deux termes décrivent des couches différentes, c'est pourquoi les éditeurs les emploient indifféremment et pourquoi cela embrouille les acheteurs.
Omnicanal vs commerce unifié
| Ce que c'est | Une promesse faite au client | Une propriété des systèmes |
|---|---|---|
| Où le juger | En front-end : puis-je commencer sur mon téléphone et finir en magasin ? | En back-end : la caisse du magasin voit-elle la même commande, le même stock et le même profil client que le webshop, au moment où elle en a besoin ? |
| Circulation des données | Souvent des systèmes séparés, reliés par des intégrations qui copient les données de l'un à l'autre | Moins de copies, donc moins de choses à garder synchronisées |
| Mode de défaillance | Des écarts, par exemple un article épuisé en ligne mais affiché comme disponible au retrait | Des pannes plus rares mais plus graves, car une interruption touche tous les canaux |
En clair, toute entreprise en commerce unifié peut offrir des parcours omnicanaux, mais toute entreprise omnicanale n'est pas unifiée. La plupart des distributeurs de taille moyenne se situent entre les deux : les données produit et les commandes en ligne sont partagées, le stock en magasin et les profils clients ne le sont pas.
Pourquoi Forrester juge le terme flou
Les analystes ne s'accordent pas sur l'étiquette. Dans un article d'octobre 2024 intitulé « Unified Commerce Is Not A Thing », les analystes de Forrester Emily Pfeiffer et Lauren Cevallos estiment que des éditeurs de nombreuses catégories utilisent le terme pour des choses différentes : regrouper des fonctions dans une plateforme, intégrer plusieurs plateformes ou simplement lister les fonctionnalités de leur propre produit. Une définition courante chez les éditeurs, notent-elles, n'est au fond qu'une reformulation de l'omnicanal.
Gartner, de son côté, a publié en juin 2024 une « quick answer », « What Is Unified Retail Commerce, and Why Does It Matter? », qui cite trois piliers : unifié, guidé par l'expérience et composable. La leçon pratique des deux : quand un éditeur parle de « commerce unifié », demande-lui laquelle des cinq données il unifie vraiment, et lesquelles il compte te laisser connecter toi-même.
Caisse, gestion des commandes, paiements : les briques que la plupart des suites regroupent
Une plateforme de commerce unifié est un logiciel qui gère nativement plusieurs des cinq données et sert plus d'un canal à partir d'elles. Les briques habituelles :
- Boutique en ligne et checkout pour le web et l'app.
- Point de vente (POS) pour les magasins, fonctionnant sur les mêmes données produit, stock et client que le webshop.
- Gestion des commandes qui oriente les commandes vers un entrepôt ou un magasin et gère les retours de n'importe quel canal. Voir gestion des commandes pour les composants.
- Gestion des stocks avec stock par site et visibilité du stock en temps réel pour chaque canal.
- Données clients et fidélité dans un seul profil.
- Paiements en ligne et en magasin.
- Données produit, que la plupart des plateformes ne conservent que sous la forme dont leur propre boutique a besoin. Les marketplaces, les feeds et les catalogues de gros demandent généralement plus de champs que cela.
Peu d'entreprises obtiennent les sept auprès d'un seul éditeur. C'est moins un échec qu'un choix de conception, que la section suivante aborde.
Deux voies : une suite unique ou une stack connectée avec des données partagées
Il existe deux façons d'arriver à des données partagées. Aucune n'est automatiquement meilleure ; la bonne dépend du nombre de canaux et de systèmes que tu fais déjà tourner.
Voie 1 : une suite de commerce unique
Webshop, caisse, commandes, stock et clients tournent sur la plateforme d'un seul éditeur avec une seule base de données. Il n'y a pas de couche de synchronisation entre eux, ce qui supprime toute une catégorie d'erreurs. Le prix à payer, c'est la dépendance : tu acceptes le modèle de données de la suite, son matériel de caisse et son rythme d'évolution.
- Convient quand : tu vends surtout via ton propre webshop et tes propres magasins, avec une poignée de sites.
- Points de vigilance : les marketplaces et canaux B2B que la suite ne sert pas nativement, et des données produit trop maigres pour ces canaux.
Voie 2 : une stack connectée avec un propriétaire par donnée
Chaque donnée a un système de référence : un ERP pour le stock et la finance, un système de gestion des commandes pour les commandes, un PIM pour les données produit, un CDP ou un CRM pour les clients. Tout le reste lit auprès de ces propriétaires via des API et des flux d'événements. C'est l'approche headless et composable appliquée au back-office.
- Convient quand : tu vends via de nombreux canaux (marketplaces, portails de gros, plusieurs pays) ou que tu as déjà un ERP que tu ne remplaceras pas.
- Points de vigilance : les intégrations qui copient les données selon un calendrier plutôt qu'à chaque changement. Une synchronisation de stock nocturne n'est pas unifiée, quoi qu'en dise le schéma d'architecture.
Voie 2 : un propriétaire par donnée
Les vendeurs B2B finissent souvent sur la voie 2, car leurs acheteurs utilisent énormément de points de contact : le B2B Pulse de McKinsey a montré que les acheteurs B2B utilisent en moyenne dix canaux (McKinsey, 2024).
L'identité produit : la clé de jointure dont dépend tout système unifié
Les discussions sur le commerce unifié se concentrent sur le stock et les clients, car c'est là que les acheteurs remarquent les défaillances. Elles mentionnent rarement que chacune de ces données se rattache à un identifiant produit. Si la caisse du magasin connaît une veste sous le code-barres 8712345678906, le webshop sous la variante 4471 et le compte marketplace sous la référence vendeur RJ-NAVY-M, rien ne peut être unifié tant que ces trois-là ne sont pas reliés à un seul produit.
Google rend cette dépendance explicite. Pour les annonces d'inventaire en magasin et les fiches locales gratuites, la spécification des données d'inventaire en magasin exige un code magasin qui correspond à ta fiche d'établissement, une valeur de disponibilité par magasin, et les mêmes valeurs d'ID produit dans tes données produit et dans tes données d'inventaire local. Si les ID diffèrent, Google ne peut pas rattacher le stock du magasin au produit.
La fiche produit doit aussi être assez complète pour le canal le plus exigeant, pas seulement pour le webshop. Une caisse de magasin a besoin d'un code-barres et d'un prix. Une marketplace a besoin d'attributs, d'une catégorie et d'un GTIN. Une fiche Google a besoin d'une image, d'une disponibilité et d'une description. Garder une seule fiche par produit qui répond à toutes ces exigences, c'est l'idée derrière une source unique de vérité.
Une veste de pluie retournée en magasin, suivie à travers cinq données
Une cliente commande une veste de pluie bleu marine, taille M, sur le webshop et la retourne dans un magasin physique huit jours plus tard. Voici ce que chaque donnée doit faire pour que ce retour se passe bien :
- Produit : le magasin scanne le code-barres de l'étiquette. La caisse doit le rattacher au même produit et à la même variante que la ligne de la commande en ligne. Sans identifiant partagé, le retour est traité comme un article inconnu.
- Commande : la caisse retrouve la commande en ligne d'origine grâce à l'e-mail de la cliente ou au numéro de commande et vérifie le délai de retour.
- Paiement : le remboursement est versé sur le moyen de paiement d'origine, ce qui ne fonctionne que si le magasin peut accéder à la transaction en ligne.
- Stock : la veste est ajoutée au stock du magasin, et la disponibilité en ligne pour ce magasin se met à jour, pour que le prochain acheteur puisse la réserver en retrait.
- Client : le retour apparaît sur le profil client, pour que le service client et la prochaine campagne e-mail en tiennent compte.
Dans une entreprise multicanale, l'étape 1 ou l'étape 2 échoue et le magasin renvoie la cliente chez elle. Dans une entreprise omnicanale sur des systèmes séparés, les cinq étapes fonctionnent, mais une personne ou une tâche de synchronisation les réconcilie après coup. Dans une entreprise unifiée, elles se font en une seule transaction.
Dix questions à poser à un éditeur de commerce unifié
Utilise-les lors d'une démo ou d'un appel d'offres. Chacune porte sur une donnée plutôt que sur une fonctionnalité, ce qui permet de repérer facilement les réponses vagues.
Dix questions pour un éditeur de commerce unifié
Démarrer par le client, syncs nocturnes et trois autres pièges
- Commencer par le profil client. Une vue client unique est l'objectif le plus visible, mais elle dépend de commandes propres, qui dépendent elles-mêmes d'identifiants produit propres. Les équipes qui commencent par le haut finissent par rattacher des clients à des commandes de produits qu'elles ne savent pas identifier.
- Qualifier d'unifiées des synchronisations planifiées. Passer d'un export nocturne à un export horaire laisse encore une heure pendant laquelle le magasin et le webshop se contredisent.
- Considérer les données produit comme migrées, pas maintenues. Le catalogue produit est copié une fois dans la nouvelle plateforme, puis de nouveau modifié à trois endroits en quelques mois.
- Ignorer les marketplaces et le B2B. Une suite qui unifie le webshop et les magasins mais pas bol, Amazon ou le portail de gros laisse les plus gros canaux en dehors du modèle.
- Acheter l'étiquette. Comme le souligne Forrester, le terme recouvre des produits très différents. Une plateforme qui n'unifie que le front-end ne règle ni le stock ni les retours.
L'ordre qui fonctionne en général : d'abord des identifiants produit partagés et une fiche produit complète, puis le stock par site, puis les commandes et les retours, puis les profils clients. Un catalogue multicanal bâti sur une seule fiche produit est la fondation dont les autres couches ont besoin.
Synchroniser le contenu produit vers les boutiques et Merchant Center depuis une seule fiche
WISEPIM n'est ni une caisse, ni un système de gestion des commandes, ni une suite de commerce. Il couvre la fiche produit dans les deux voies : il importe ton catalogue, complète et corrige descriptions, attributs, traductions et catégories avec l'AI, vérifie la complétude par canal avec Quality Guard et envoie la même fiche vers tes boutiques et Google Merchant Center via ses connexions. Avec l'auto-sync activable, un produit enregistré est envoyé vers les boutiques connectées comme Shopify, WooCommerce et Magento 2 environ 30 secondes plus tard : les canaux cessent ainsi de diverger sur le contenu et les identifiants pendant que tu travailles sur le stock, les commandes et les clients.
