Palettes de formats différents sur une même lisse de palettier
9 septembre 2026
Stock consigné, chez le client ou chez le fournisseur : ce qu’il faut paramétrer dans l’ERP et le WMS
30 septembre 2026Un article en six tailles n’est pas un article avec une variante secondaire.
Ce sont, pour un WMS, potentiellement six références actives, six codes-barres, six historiques de stock.
La difficulté du textile n’est pas la taille elle-même, c’est la multiplication de SKU qu’elle entraîne mécaniquement, et un référentiel mal construit au démarrage se paie ensuite en emplacements mal dimensionnés, en temps de préparation et en erreurs de picking.
Construire le référentiel avant de parler d’entrepôt
Deux architectures possibles.
- La première : un article parent qui porte les caractéristiques communes (matière, coloris, saison) et des articles enfants pour chaque taille, chacun avec son propre code-barres et son propre stock.
- La seconde : des références « à plat », une par taille, sans lien de parenté formalisé dans le système.
La première facilite le reporting par modèle et les analyses de vente toutes tailles confondues. La seconde est plus simple à mettre en œuvre mais rend parfois plus difficile de répondre à une question aussi banale que « combien ai-je vendu de ce modèle, toutes tailles comprises ». A noter que l’adjonction d’attributs dans la fiche article peuvent quand même considérablement aider à répondre à cette question ; même avec une stratégie de référence à plat.
Le choix se fait une fois, avant l’intégration WMS : le revoir après coup revient à ressaisir tout le référentiel.
Deuxième chantier, moins visible mais tout aussi structurant : la correspondance entre systèmes de tailles. Lettres, tailles numériques, tailles par pays, parfois plusieurs conventions coexistent sur une même gamme selon le fournisseur ou le marché. Sans table de correspondance centralisée et unique, chaque service finit par tenir sa propre traduction, et les divergences entre commercial, achats et logistique ne se découvrent qu’au moment où elles coûtent une erreur de préparation.
Troisième point, propre au textile : la gestion des rééditions saisonnières. Le même modèle revient d’une collection à l’autre, parfois avec une légère variation de coloris ou de coupe. La tentation est de dupliquer la référence à chaque saison. C’est ce qui fait exploser le nombre de SKU dormants dans le référentiel, avec un historique de vente dispersé sur plusieurs codes pour un produit que le client perçoit comme identique.
L’avis des éditeurs
Dans une récente consultation pour un choix de WMS, le retour de 3 éditeurs WMS a été homogène pour le pilotage des articles textiles :
Une référence par taille. Le pilotage est mieux géré en 1 pour 1. Une taille = 1 SKU
Ce que ça change pour les emplacements
Une fois le référentiel posé, la question des emplacements se pose différemment selon la stratégie retenue.
Ranger toutes les tailles d’une même référence ensemble facilite la préparation d’un client qui commande plusieurs tailles à la fois, fréquent en B2B. Ranger par taille, tous modèles confondus, peut avoir du sens si certaines tailles se vendent nettement moins que d’autres et méritent un emplacement à rotation plus lente, à l’écart du flux principal.
C’est là que le référentiel mal construit se paie concrètement : sans visibilité fiable sur le volume réel par taille, impossible de dimensionner les emplacements en connaissance de cause. On finit par réserver le même espace à une taille M qui tourne toutes les semaines et à une taille XXL qui tourne trois fois par saison.
Les lots pré-packés, un assortiment de tailles vendu comme une seule unité logistique, posent un problème différent : le WMS doit savoir gérer une unité composite sans casser le suivi de stock détaillé par taille à l’intérieur. Le réassort, très fréquent en textile, gagne à passer en cross-docking direct plutôt qu’à transiter par un emplacement de stockage classique, si le volume et la fréquence le justifient.
Ce que ça change pour la préparation
Un référentiel qui distingue clairement chaque taille permet un pick-to-light ou une préparation guidée réellement efficace : chaque taille a son propre emplacement identifié, sans ambiguïté au moment du prélèvement. Sans cette granularité, le préparateur doit interpréter, et c’est là que naît l’erreur de taille, la plus fréquente et la plus coûteuse en retour client sur ce type de produit.
La rupture partielle, une taille manquante sur une commande multi-tailles, doit être gérée comme un cas normal du process, pas comme une anomalie qui bloque toute la préparation. La stratégie de slotting doit être pensée dès le départ pour un très grand nombre de références à faible volume unitaire, ce qu’on appelle la longue traîne : ce n’est pas la même logique de dimensionnement qu’un entrepôt avec peu de références à fort volume.
L’œil de l’expert
Le nombre de références n’est jamais le vrai problème dans un projet textile. Le vrai problème, c’est de dimensionner l’entrepôt sur le nombre de modèles plutôt que sur le nombre réel de SKU, tailles comprises. C’est cet écart-là qui fait qu’un site soi-disant bien dimensionné manque déjà de place à la première collection suivante.
Saisonnalité et soldes
La gamme change à chaque collection, parfois plusieurs fois par an. Un référentiel bien construit absorbe cette variation par simple activation ou désactivation de références existantes. Un référentiel mal construit oblige à repasser par un reparamétrage complet du WMS à chaque nouvelle collection, avec le risque d’erreur que ça comporte à chaque fois.
Avant de démarrer
Trois points à trancher avant toute intégration WMS sur une gamme textile avec tailles :
- choisir une architecture parent-enfant ou à plat et s’y tenir,
- normaliser une table de correspondance des tailles unique pour tous les services, et
- dimensionner les emplacements sur le volume réel par taille plutôt que sur une moyenne par modèle qui masque les écarts entre les tailles qui tournent et celles qui dorment.
Questions fréquentes
Faut-il un code-barres différent pour chaque taille ?
Oui, sans exception. Un code-barres partagé entre plusieurs tailles d’un même modèle est la cause la plus fréquente d’erreur de préparation en textile, parce que rien ne distingue plus les unités au scan.
Comment gérer les tailles dans un référentiel multi-pays (UE, UK, US) ?
Par une table de correspondance centralisée, tenue par un seul service et non recopiée dans chaque système. C’est ce document, pas le WMS lui-même, qui doit faire foi en cas de désaccord entre deux équipes.
Faut-il stocker les lots pré-packés à part des unités au détail ?
Souvent oui, parce que ce sont deux logiques de préparation différentes : l’une par carton complet, l’autre à l’unité. Les mélanger dans le même emplacement complique le comptage et le picking des deux flux.
Le sur-mesure ou les tailles à la demande changent-ils la donne ?
Oui, largement : la taille n’est plus une variante prédéfinie du référentiel mais une donnée saisie à la commande, ce qui déplace une partie du sujet vers la gestion de production à la commande plutôt que vers le seul référentiel article.
Comment anticiper le volume de SKU avant même d’avoir les ventes ?
En partant du nombre de tailles proposées par modèle, multiplié par le nombre de modèles actifs sur une collection, plutôt qu’en attendant les premières ventes pour dimensionner les emplacements. Un dimensionnement fait après coup se traduit presque toujours par un réaménagement dès la collection suivante.
Faut-il désactiver les tailles qui ne se vendent presque jamais ?
Pas nécessairement les désactiver, mais les sortir du flux de préparation principal en les affectant à un emplacement à rotation lente. Les supprimer du référentiel complique le réassort si la demande revient l’année suivante.
