La migration de données produit est le processus de transfert d'informations produit d'un système à un autre. Cela semble simple sur le papier, mais en pratique, c'est l'une des phases les plus sujettes aux erreurs dans toute implémentation PIM, consolidation ERP ou migration de plateforme e-commerce.
Les raisons varient. Certaines entreprises lancent une migration parce qu'elles implémentent un PIM pour la première fois et doivent extraire les données de feuilles de calcul ou d'un ERP. D'autres changent de prestataire PIM après avoir dépassé les limites de leur système actuel. Un groupe moins important consolide les données produit issues de plusieurs systèmes isolés vers une source unique de vérité. Le chemin de migration diffère dans chaque cas, tout comme la stratégie appropriée. Mais les schémas d'échec sont remarquablement constants.
Selon Gartner, 83 % des projets de migration de données échouent complètement ou dépassent leurs budgets et calendriers. Les causes ne sont pas mystérieuses : complexité sous-estimée et préparation insuffisante aux problèmes de qualité des données déjà présents dans la source.
Ce que contiennent réellement les « données produit »
Avant toute migration, il est utile d'être précis sur ce que vous transférez. Les données produit ne se limitent pas aux SKU et aux noms.
Un enregistrement produit classique chez un fabricant ou distributeur de taille moyenne contient des attributs de base (dimensions, poids, matériaux, certifications), des données commerciales (tarification, unités d'emballage, délais de livraison), du contenu enrichi (descriptions marketing, spécifications techniques, images, documents), des données de classification (hiérarchies produit, catégories, codes ETIM ou GS1) et des données relationnelles (variantes produit, accessoires, pièces de rechange, liens de nomenclature).
Chaque type de données a des exigences structurelles différentes, des problèmes de qualité distincts et une complexité de mappage variable. Les actifs numériques seuls peuvent représenter une part importante de l'effort de migration, car les images et documents doivent être correctement liés aux bons enregistrements produit et livrés dans les bons formats.
En pratique, l'enregistrement produit contient souvent plus de 200 attributs répartis dans plusieurs groupes d'attributs, avec une logique de variante construite par-dessus. Migrer cela dans un nouveau système n'est pas un simple transfert de fichier. C'est un projet de transformation de données.
Les trois scénarios de migration les plus courants
Des feuilles de calcul vers un PIM.
La plupart des entreprises du marché intermédiaire commencent par là. Les données produit se trouvent dans plusieurs fichiers Excel gérés par différentes équipes, parfois dans des formats différents, parfois désynchronisés. Le défi est d'imposer une structure cohérente pour la première fois. Vous ne migrez pas un modèle. Vous en créez un.
D'un ERP ou d'un système legacy vers un PIM.
Les systèmes ERP stockent les données produit de manière à optimiser le traitement des transactions, non la gestion de contenu. Les systèmes MDM sont plus structurés, mais leurs modèles d'attributs sont conçus pour la gouvernance, pas pour la publication multicanale. Dans les deux cas, le modèle de données source ne correspond que rarement de manière nette à un PIM. La migration implique l'extraction d'enregistrements plats, leur enrichissement, la restructuration des relations et le mappage vers une architecture d'attributs complètement différente.
PIM vers PIM.
Les entreprises qui changent de prestataire font face à un problème différent. Les données source sont structurées, mais le système cible possède son propre modèle de données, ses conventions de nommage d'attributs et sa logique de classification. Ce qui se casse le plus souvent est l'arborescence de catégories : les hiérarchies construites dans un système ne se traduisent que rarement 1:1, et les règles d'affectation de canal liées à l'ancienne taxonomie doivent être reconstruites de zéro. Le mappage entre deux systèmes matures nécessite une analyse minutieuse champ par champ, et les hypothèses intégrées dans l'ancien système se transfèrent rarement.
Le processus de migration de données produit, étape par étape
C'est là que se déroule la majorité du travail réel, et c'est là que les projets rencontrent des problèmes si des étapes sont ignorées.
1. Audit des données source.
Avant tout mappage ou transformation, inventoriez ce que vous avez réellement. Quels systèmes contiennent les données produit, dans quel format, gérés par qui et avec quelle actualité ? Le profilage des données est le terme formel pour cela : trouvez les doublons, comptabilisez les valeurs nulles, identifiez les incohérences dans les unités, les noms et les formats. Cette phase prend généralement plus de temps que prévu et révèle presque toujours des surprises. De nombreuses organisations découvrent que leurs données sont « globalement propres » seulement après avoir supposé qu'elles étaient réellement propres.
2. Définition du modèle de données cible.
Définissez la structure des attributs, la hiérarchie de classification et le modèle de relation dans le système de destination avant de commencer le mappage. C'est une décision transversale qui implique les parties prenantes de la gestion des produits, du marketing, de la vente et de l'informatique. Effectuer le mappage avant la finalisation du modèle cible garantit une refonte.
3. Mappage des données.
Faites correspondre chaque champ de la source à un champ de la cible. Identifiez les lacunes (attributs existants dans la source mais sans équivalent dans la cible, ou vice versa), les conflits (différentes valeurs représentant le même concept) et les exigences de transformation (conversions d'unités, normalisation de taxonomie, standardisation de listes de valeurs). Les petites erreurs de mappage s'ajoutent sur des dizaines de milliers de SKU. Une erreur dans la façon de mapper une unité de mesure affecte chaque produit qui l'utilise.
4. Nettoyage des données.
Corrigez les problèmes de qualité dans les données source avant la migration, pas après.
La tentation est de placer les données sales dans le PIM et de « les nettoyer plus tard ». C'est là que vivent la plupart des échecs de migration. Les données sales migrées à grande échelle ne deviennent pas plus propres. Elles deviennent plus ancrées.
Le nettoyage signifie déduplication, remplissage des champs obligatoires, standardisation des formats de valeurs, correction des erreurs de classification et validation des liens d'actifs numériques. Pour un fabricant avec 15 000 SKU actifs, cette phase peut prendre des semaines. Elle n'est pas optionnelle.
5. Transformation et chargement.
Appliquez les règles de transformation définies à l'étape 3 et exécutez l'import réel. Utilisez le moteur d'import du système cible ou un outil ETL (extract, transform, load) dédié, selon le volume et la complexité des données. Les décalages de format entre la source et la cible sont courants à ce stade : les problèmes d'encodage de caractères, les conflits de format de date et les différences de précision numérique peuvent corrompre les valeurs silencieusement. Effectuer un test de chargement sur un petit lot avant l'import complet détecte la plupart de ces problèmes.
6. Migration de test.
Effectuez une migration test sur un sous-ensemble représentatif, idéalement couvrant vos types de produits les plus complexes, pas seulement les simples. Validez les résultats par rapport aux critères d'acceptation définis. Corrigez les problèmes avant la migration complète. Pour les projets plus importants, une phase formelle d'acceptation utilisateur (UAT) avec les vrais propriétaires de données vaut la peine d'être intégrée au calendrier.
7. Migration complète et validation.
Exécutez la migration complète et vérifiez les résultats : réconciliation du nombre d'enregistrements, audit de complétude des attributs, vérifications d'intégrité des relations, vérification des liens d'actifs. Un journal de migration réussi sans erreurs n'est pas une validation suffisante en soi.
8. Période de rodage post-migration.
Les utilisateurs métier et les gestionnaires de données ont besoin de temps pour examiner les données migrées dans le système en direct. Prévoyez une période de 6 à 8 semaines après la mise en direct. Des problèmes vont émerger que les vérifications automatisées n'ont pas détectés : une dimension dans la mauvaise unité, un produit affecté à la mauvaise catégorie, une traduction manquante pour un marché clé. Ceux-ci doivent être documentés, priorisés et résolus avant que le système soit considéré comme prêt pour la production.
Où les migrations s'égarent
Les modes d'échec sont bien documentés et encore fréquemment répétés. Nos clients viennent souvent nous voir après une tentative de migration qui a stagné ou a été annulée, et la cause première est presque toujours l'une des suivantes.
- Ignorer l'audit des données. Les équipes supposent que leurs données sont plus propres qu'elles ne le sont réellement, passent directement au mappage et découvrent l'état réel des choses en pleine migration.
- Finaliser le modèle de données trop tard. Le travail de mappage effectué avant le verrouillage du modèle cible nécessite une refonte partielle ou complète.
- Migrer des données sales. La logique selon laquelle « nous la nettoierons dans le nouveau système » ne sera presque jamais mise en œuvre. Les données sales deviennent la nouvelle normalité.
- Sous-estimer la migration d'actifs. Les images et documents sont souvent traités comme une idée après coup. Les actifs manquants, mal liés ou mal nommés figurent parmi les plaintes post-migration les plus courantes.
- Migration d'enregistrements plats. Les produits avec variantes, accessoires ou relations de nomenclature nécessitent une migration relationnelle. Migrer les enregistrements plats et essayer de reconstruire les relations après coup est bien plus coûteux.
- Pas de plan de secours. Si une migration complète échoue en cours de route, la capacité à revenir aux systèmes source de manière nette n'est pas optionnelle. La perte de données lors du basculement est rare mais permanente quand elle se produit.
- Ignorer l'intégrité des données entre les relations. Migrer les enregistrements produit sans leurs variantes liées, leurs actifs et leurs affectations de catégorie produit des enregistrements techniquement complets qui sont fonctionnellement cassés.
Migration par phases ou migration « big bang »
Une migration big bang déplace toutes les données en un seul basculement. Elle est plus rapide à planifier et plus simple à coordonner, et elle fonctionne quand la source est propre, le catalogue relativement petit et le modèle de données cible simple.
Pour la plupart des fabricants et distributeurs avec des hiérarchies de produits complexes, plusieurs groupes d'attributs et des milliers de SKU répartis sur plusieurs familles de produits, une approche par phases est plus sûre. Commencez avec une vague de catalogue principal : une seule catégorie de produit, les attributs essentiels seulement. Vérifiez que le processus de mappage et de chargement fonctionne comme prévu. Puis ajoutez des catégories supplémentaires, des attributs plus riches et des structures relationnelles plus complexes dans les vagues suivantes.
Une migration par phases n'est pas plus lente. C'est un moyen de découvrir ce que vous avez mal fait avant que cela n'affecte tout.
La règle générale : si vous avez plus de 5 000 SKU, des relations de produits multi-niveaux ou plus d'un système source, prévoyez une migration par phases.
Les outils dont vous avez réellement besoin
Aucun outil unique ne gère tout. Une pile de migration réaliste comprend généralement :
- Un outil ETL ou d'intégration de données pour l'extraction, la transformation et le chargement (Talend, Informatica ou pipelines simples basés sur Python, selon le volume)
- Un système PIM cible avec des capacités flexibles d'import et export : support des imports en masse CSV et Excel, ingestion API REST, mappage de champs configurable et validation à l'import
- Une capacité DAM ou de gestion d'actifs qui gère la liaison de fichiers et la conversion de format pendant l'import
- Des outils intégrés de qualité et de complétude des données pour le profilage pré-migration et la validation post-migration
AtroPIM est construit sur la plateforme AtroCore, ce qui lui confère un modèle d'attributs et de relations hautement configurable. Cela importe lors de la migration car cela signifie que la structure des données cibles peut être façonnée pour correspondre à la complexité des données entrantes, plutôt que de forcer les données dans un modèle de système rigide. AtroPIM supporte les imports en masse CSV et Excel, l'ingestion de données API REST, les ensembles d'attributs configurables par famille de produits et les relations de produits multi-niveaux, y compris les variantes et les accessoires. Sa fonctionnalité de score de complétude est particulièrement utile lors de la validation de la migration : vous pouvez définir les attributs requis par type de produit et mesurer la complétude par rapport à ces critères avant de signer chaque vague de migration.
La nature open-source d'AtroPIM importe aussi dans les contextes de migration. Quand les données source ont des structures inhabituelles ou nécessitent une logique de transformation personnalisée, pouvoir étendre le pipeline d'import sans dépendances de fournisseur réduit significativement le risque du projet.
La période post-migration est une phase à part entière
Introduire les données dans le système est le point médian, pas la ligne d'arrivée. La validation post-migration est son propre flux de travail, et elle doit être délimitée et dotée de ressources avant que la migration ne commence.
La réconciliation du nombre d'enregistrements confirme que rien n'a été perdu entre la source et la cible. Les audits de complétude des attributs vérifient que les champs obligatoires sont remplis aux seuils définis pour chaque type de produit. Les vérifications de classification et de hiérarchie confirment que les affectations de catégories ont survécu à la migration intactes. La vérification de liaison d'actifs confirme que les images et documents sont correctement liés, pas orphelins. Les vérifications de disponibilité du canal vont plus loin : elles confirment que les produits répondent réellement aux critères de complétude pour être publiés, pas seulement qu'ils existent dans le système.
En pratique, ce travail de validation se fait mieux par les personnes qui travaillent avec les données au quotidien, pas l'équipe d'implémentation. Les gestionnaires de produits et les responsables de catégorie savent quels attributs importent pour quels types de produits. Leur donner des outils d'examen structurés dans un environnement intermédiaire avant la mise en direct détecte les erreurs que les vérifications automatisées manquent.
Réussir la migration
La migration de données produit est autant un exercice de gouvernance des données qu'un exercice technique. La qualité des données que vous introduisez dans un nouveau système détermine ce que le système peut réellement faire pour vous. Un PIM bien structuré chargé avec un catalogue de produits propre et complet génère de la valeur dès le premier jour, pour les équipes internes gérant les données et pour chaque canal aval le consommant. Le même système chargé avec des problèmes de qualité migrés mais non résolus coûte des mois de nettoyage avant de gagner la confiance, et rend l'intégration des produits en cours plus difficile qu'elle ne devrait l'être.
L'investissement dans l'audit, le nettoyage et l'exécution par phases n'est pas une surcharge. Les équipes qui sautent ces étapes passent généralement la première année après la mise en direct à faire le travail de nettoyage qu'elles ont différé, à l'intérieur d'un système en direct, sous la pression de la production, sans filet de sécurité.
Pour plus de détails sur la façon dont AtroPIM gère les structures de catalogues complexes et ce qu'il faut rechercher dans un PIM prêt pour la migration, consultez la présentation des fonctionnalités AtroPIM.