Pourquoi la même référence se ressaisit trois fois
Chaque outil a été choisi pour son service : le PLM pour le studio et le développement, l’ERP pour les achats, la logistique et la finance, la plateforme e-commerce pour la vente en ligne. Personne n’a été chargé du passage de l’un à l’autre.
- Une référence, plusieurs vies : elle naît dans le PLM avec ses matières et sa nomenclature, devient un article dans l’ERP au lancement, puis une fiche produit sur le site. À chaque passage, quelqu’un recopie.
- Le calendrier ne pardonne pas : les articles doivent exister dans l’ERP avant le showroom et la prise des précommandes wholesale, et la fiche doit être en ligne le jour de la mise en vente : la ressaisie se fait toujours dans l’urgence.
- Des codes qui ne se ressemblent pas : code modèle du studio, code article de l’ERP, code coloris du fournisseur, couleur affichée sur le site, grille de tailles propre à chaque outil : rapprocher les deux bouts demande un tableau de correspondance tenu à la main.
- Les changements tardifs se perdent : une composition corrigée, un coloris abandonné ou un prix revu après le lancement n’arrivent pas jusqu’au site, ou y arrivent par un e-mail.
- L’information ne revient pas : ventes, retours et motifs de retour restent dans l’ERP et la plateforme ; le chef de produit les reconstitue en fin de saison, dans un tableur.
Le problème n’est pas l’un des outils, mais l’absence de règle sur qui tient chaque donnée, et sur le moment où elle passe à l’outil suivant.
Les six étapes, de la cartographie à la généralisation
- Cartographier les donnéesProposé, puis validé
- Poser le référentielProposé, puis validé
- Choisir les échangesProposé, puis validé
- Écrire les contrôlesAutomatique
- Piloter une collectionProposé, puis validé
- GénéraliserDécidé par une personne
Le détail de chaque étape : ouvrez-la.
Cartographier les données et leur maître
- Aujourd’hui
- Chaque service décrit son outil ; personne ne sait dire où la composition, le prix ou le coloris font foi.
- Automatisé
- Inventaire des champs de chaque outil, des fichiers échangés et des ressaisies, relevé dans les logiciels en place : une carte donnée par donnée, avec son maître et ses lecteurs.
- Reste humain
- Trancher, avec les services, l’outil maître de chaque donnée, et le moment où la référence passe du PLM à l’ERP.
Poser un référentiel commun
- Aujourd’hui
- Codes modèle, coloris, tailles et saisons différents d’un outil à l’autre, rapprochés dans un tableau de correspondance.
- Automatisé
- Une codification modèle, coloris, taille écrite une fois ; des grilles de tailles, des listes de coloris et de saisons partagées ; les tables de correspondance tenues à jour par l’outil, pas à la main.
- Reste humain
- Fixer les règles de codification, en particulier pour les références reconduites d’une saison à l’autre.
Choisir le mode d’échange de chaque flux
- Aujourd’hui
- Exports et imports de fichiers, lancés par la personne qui en a besoin.
- Automatisé
- Pour chaque flux, un mode et un rythme : API en temps réel pour le stock disponible, échange planifié pour les articles et les prix, fichier quand un outil ne sait pas faire autrement, middleware quand les flux se multiplient.
- Reste humain
- Arbitrer avec la DSI le niveau de temps réel nécessaire, flux par flux.
Écrire les règles de contrôle
- Aujourd’hui
- Les erreurs se découvrent sur le site : produit sans prix, taille manquante, composition fausse.
- Automatisé
- Contrôles avant chaque envoi : champs obligatoires, clé de contrôle et unicité des EAN, tailles et coloris présents dans le référentiel, composition renseignée ; alerte nommée en cas de rejet ou d’échec.
- Reste humain
- Décider de ce qui bloque l’envoi et de ce qui ne fait qu’alerter.
Piloter sur une collection
- Aujourd’hui
- Tout se joue en même temps, au moment du lancement d’une saison complète.
- Automatisé
- Une collection ou une ligne passe par la chaîne complète : création des articles, EAN, prix, fiches enrichies, publication, puis remontée des ventes et des retours.
- Reste humain
- Comparer avec l’ancienne façon de faire et corriger les règles avant d’aller plus loin.
Généraliser canal par canal
- Aujourd’hui
- Chaque nouveau canal (marketplace, grand magasin, pays) ajoute ses propres fichiers.
- Automatisé
- Les autres collections, puis les autres canaux, lisent les mêmes sources : marketplaces, fichiers articles des grands magasins et des revendeurs wholesale, sites par pays.
- Reste humain
- Choisir l’ordre des canaux et nommer un responsable du suivi des flux.
Les prérequis
- Un maître écrit pour chaque donnée validé par le produit, le commerce, la logistique et la finance, avant de brancher le premier flux.
- Une codification stable modèle, coloris, taille et saison, avec une règle pour les références reconduites et les déclinaisons ajoutées en cours de saison.
- Un statut de cycle de vie sur la référence qui dit quand elle quitte le développement pour devenir un article commercial, puis quand elle est arrêtée.
- Les interfaces des outils en place API, imports planifiés ou formats de fichiers acceptés par le PLM, l’ERP, le PIM et la plateforme e-commerce.
- Un responsable des flux qui reçoit les alertes et sait à qui renvoyer une erreur : au studio, à l’ADV, au catalogue ou à la DSI.
Quatre façons de relier les outils
| Options | Adaptée quand | Limites | À vérifier |
|---|---|---|---|
| Connecteurs standards des éditeurs | Peu d’outils, des flux proches des standards (article, prix, stock), un connecteur maintenu par l’un des éditeurs. | Couvre les champs prévus ; les règles propres à la marque restent à la main, et chaque connecteur a sa propre surveillance. | Champs réellement transmis (déclinaisons, composition, prix par pays), sens des échanges, alerte en cas d’échec, compatibilité avec les montées de version. |
| Middleware ou plateforme d’intégration | Plusieurs outils, plusieurs canaux et pays, des flux qui se multiplient : un seul endroit pour les transformer, les rejouer et les surveiller. | Un outil de plus, avec ses compétences, son abonnement et sa maintenance ; il ne règle pas à lui seul la question du maître de chaque donnée. | Connecteurs disponibles pour les outils en place, journal et reprise des échanges en erreur, qui maintient les règles. |
| PIM au centre de la diffusion | Beaucoup de canaux, de langues et de pays : la fiche enrichie une fois sert au site, aux marketplaces et aux revendeurs. | Ne remplace ni le PLM ni l’ERP ; s’il devient maître du prix ou du stock, les conflits reviennent. | Ce qu’il reçoit du PLM et de l’ERP, ce qu’il diffuse, contrôle de complétude par canal, lien avec le DAM. |
| Intégration sur-mesure | Règles propres à l’activité : codification maison, déclinaisons tardives, calendrier showroom et précommandes, canaux que les connecteurs ne couvrent pas. | Demande un cadrage précis et une maintenance ; à éviter quand un connecteur standard couvre déjà le besoin. | Propriété du code, documentation des flux, alertes, réversibilité. |
Les options se combinent : un connecteur standard pour le stock, un PIM pour la diffusion produit, une intégration sur-mesure pour ce que les deux ne savent pas faire.
Les pièges fréquents
- Deux maîtres pour la même donnée le prix modifié dans l’ERP et dans la plateforme e-commerce, ou la composition corrigée dans le PIM et pas dans le PLM : chaque synchronisation écrase la correction de l’autre.
- Une codification différente entre outils tailles, coloris ou saisons codés autrement dans chaque logiciel, rapprochés par un tableau que personne ne tient à jour : le premier nouveau coloris casse le flux.
- Des flux sans alerte d’échec un échange qui tombe en silence, et l’erreur se découvre sur le site, par un client, ou au showroom quand un article manque.
- L’enrichissement refait à chaque canal textes, attributs et visuels repris pour le site, chaque marketplace et chaque grand magasin, au lieu d’être préparés une fois et adaptés par canal.
- Relier les outils avant de nettoyer des doublons et des références mal codées transmis plus vite, partout à la fois.
Le contrôle interne
Relier les outils rend la chaîne traçable : chaque article créé garde la référence et la validation du PLM dont il vient, chaque échange est journalisé avec ses rejets, et la personne qui paramètre les règles n’est pas celle qui valide le lancement. Ce que voit l’acheteur engage la marque : la composition en fibres des textiles doit figurer aussi dans les catalogues et prospectus, et pour les produits concernés par la loi AGEC, la fiche relative aux qualités et caractéristiques environnementales doit être consultable au moment de l’achat, sous une forme exploitable automatiquement. Ces informations doivent donc venir de la source validée, pas d’une ressaisie. Le passeport numérique de produit prévu par le règlement européen sur l’écoconception, dont les vêtements et chaussures font partie des produits prioritaires, demandera la même discipline. La validation d’une référence, d’un prix et d’une composition reste aux personnes habilitées.
Par où commencer
- Dresser la carte des données de la référence (matières, nomenclature, coût, codes, EAN, prix, stock, textes, visuels) avec, pour chacune, son outil maître et les outils qui la lisent.
- Écrire le référentiel commun : codification modèle, coloris, taille, grilles de tailles, saisons, statut de cycle de vie.
- Relier une collection de bout en bout, de la validation dans le PLM au retour des ventes, puis généraliser canal par canal.
Questions fréquentes
Faut-il changer de PLM ou d’ERP pour les relier au site ?
Non, dans la plupart des cas. Les outils en place se gardent ; ce qui manque est une règle sur le maître de chaque donnée et des échanges contrôlés. Un changement d’outil ne se justifie que si l’un d’eux ne sait rien exposer ni recevoir.
Quel outil doit être maître du prix de vente ?
En général l’ERP, ou l’outil de prix qui l’alimente : c’est là que se tiennent les prix par pays et par canal, les prix de gros et les démarques. Le PLM porte le prix cible et le coût de revient, le site affiche le prix qu’il reçoit.
Faut-il un middleware pour relier le PLM, l’ERP et l’e-commerce ?
Pas toujours. Avec deux ou trois outils et des connecteurs maintenus, il ajoute un outil sans nécessité. Il devient utile quand les flux, les canaux et les pays se multiplient et qu’il faut les surveiller au même endroit.
Comment traiter les références reconduites d’une saison à l’autre ?
Par une règle écrite dans le référentiel : même code modèle et coloris quand le produit ne change pas, nouveau code dès qu’il change. Selon les règles GS1, chaque variante de taille et de coloris porte son propre GTIN.
Comment les ventes et les retours remontent-ils jusqu’au produit ?
Par la référence commune : ventes, retours et motifs de retour de l’ERP et de la plateforme sont rattachés au modèle et au coloris du PLM. Le chef de produit voit un défaut de taille ou de matière pendant la saison, pas à la fin.
Combien coûte l’intégration d’un PLM avec l’ERP et le site ?
Cela dépend du nombre d’outils, de flux, de canaux et de pays, et de l’état du référentiel. Un diagnostic permet de le dire précisément avant de s’engager.
Votre chaîne PLM, ERP et e-commerce, en diagnostic
Données, maîtres, codification, flux et ressaisies : une carte de votre chaîne produit et l’ordre réaliste dans lequel la relier.
Demander le diagnosticPour aller plus loin
Sources
- How many GS1 GTINs do I need when I have a product with many sizes and colours? — GS1
- Règlement (UE) n° 1007/2011 relatif aux dénominations des fibres textiles et à l’étiquetage, résumé de procédure — Parlement européen, Observatoire législatif
- FAQ sur le décret n° 2022-748 du 29 avril 2022 relatif à l’information du consommateur sur les qualités et caractéristiques environnementales des produits (article 13-I de la loi AGEC), novembre 2025 — ecologie.gouv.fr
- Règlement (UE) 2024/1781 du 13 juin 2024 établissant un cadre pour la fixation d’exigences en matière d’écoconception applicables aux produits durables — EUR-Lex
- Fiche d’informations UE 2024/1781, règlement sur l’écoconception des produits durables (ESPR), mars 2026 — ILNAS, Luxembourg