01 Une migration de données PLM, c'est quoi exactement ?
Une migration de données PLM consiste à transférer le référentiel technique d'un système vers un autre : de Windchill vers 3DEXPERIENCE, d'un legacy maison vers Teamcenter, ou de plusieurs instances vers une seule. Mais la définition honnête est plus exigeante. Il s'agit de reconstruire une structure produit dans un modèle objet qui ne la décrit pas de la même façon.
Ce qui fait la valeur d'un PLM, ce ne sont pas les fichiers. Ce sont les liens : références entre pièces, nomenclatures, documents CAO associés, états de maturité, dépendances. Copier les fichiers sans reconstruire ces liens, c'est livrer des pièces qui ne savent plus à quel produit elles appartiennent. C'est exactement ce que font les outils natifs.
La donnée technique sans sa structure, c'est du bruit. Toute la migration se joue là.
02 PLM vs ERP : ce qui change vraiment
Un ERP manipule des enregistrements tabulaires : articles, commandes, écritures. Un PLM manipule un graphe d'objets versionnés : des pièces avec leurs révisions et itérations, des structures avec leurs effectivités, des modèles CAO avec leurs dépendances entre fichiers.
Trois conséquences directes. L'ordre de chargement compte : une nomenclature chargée avant ses pièces échoue. La volumétrie se mesure en liens autant qu'en objets : dix mille pièces peuvent porter des centaines de milliers de relations. Et la CAO impose ses propres contraintes : intégrité binaire, références inter-fichiers, assemblages qui doivent se rouvrir dans le système cible.
Vous migrez un système de gestion plutôt qu'un référentiel technique ? Le versant ERP a ses règles propres : voir le guide de la migration de données ERP.
03 Quelles données migrer : structures, CAO, historique
Le périmètre PLM se décide par couche, chacune avec son arbitrage :
- Le référentiel articles (WTParts, Physical Products) : la colonne vertébrale. À dédoublonner et conformer au modèle cible en premier ;
- Les structures et nomenclatures, avec leurs effectivités et leurs vues : c'est là que vivent les liens, et les surprises aussi ;
- Les documents et modèles CAO, avec leurs dépendances inter-fichiers : un assemblage migré doit se rouvrir, pas seulement exister ;
- Les documents associés (spécifications, plans, dossiers de définition) et leurs rattachements ;
- L'historique de révisions : migrer la dernière révision libérée coûte dix fois moins cher que l'historique complet. La bonne réponse dépend de vos obligations réglementaires. C'est un arbitrage métier, pas un défaut de la migration.
04 Deux PLM ne décrivent jamais le produit de la même façon
Windchill raisonne en WTPart, documents CAO et relations. 3DEXPERIENCE, bâti sur ENOVIA, raisonne en Physical Product, références et états de maturité propres. Les outils natifs supposent une correspondance 1:1 entre ces mondes ; cette correspondance n'existe pas. Il faut la construire, attribut par attribut, état par état, type de lien par type de lien.
Et ce mapping ne se lit dans aucune documentation : il vit dans les personnalisations accumulées, les cycles de vie spécifiques et les conventions d'équipe jamais écrites. C'est un travail de modélisation métier autant que de technique. C'est d'ailleurs pour ça qu'un consultant dédié migration accompagne chaque projet.
05 L'audit : mesurer le graphe, pas compter les fichiers
Compter les objets ne suffit pas : il faut mesurer les liens, les révisions, les états, et surtout les anomalies. Objets orphelins, nomenclatures pointant vers des pièces supprimées, doublons de codification : l'audit de données les rend visibles avant qu'ils ne fassent dérailler le chargement.
Particularité PLM : la donnée ne vient presque jamais d'une seule source. Plusieurs instances, des coffres CAO annexes, des exports tableurs devenus la vraie référence... L'audit doit cartographier et confronter toutes les sources, pas photographier la plus propre.
06 Les cinq phases d'une migration maîtrisée
La démarche est la même que pour un ERP ; c'est le contenu de chaque phase qui s'adapte au PLM. Notre méthodologie complète les détaille ; en résumé :
- 01 · Audit : mesurer objets, liens, révisions et anomalies sur toutes les sources ;
- 02 · Build : construire une chaîne qui respecte l'ordre des dépendances et reconstruit les liens ;
- 03 · Run / Fix : exécuter par familles de produits et d'assemblages, corriger, boucler jusqu'à stabilisation ;
- 04 · Dry Run : la répétition générale à volumétrie réelle, CAO comprise ;
- 05 · Go-Live : la bascule quand chaque structure a déjà été reconstruite et validée.
07 Les pièges spécifiques au PLM
Aux pièges classiques de toute migration s'ajoutent ceux du graphe :
- Le fichier migré n'est pas la donnée migrée. Un modèle CAO intact mais coupé de ses liens est une pièce sans produit ;
- Les états de cycle de vie personnalisés. « En cours de validation site » n'a pas d'équivalent standard dans la cible : chaque état custom exige une décision de mapping ;
- Les révisions parallèles et les branches, que les passerelles linéaires ne savent pas représenter ;
- Les assemblages qui ne se rouvrent plus : les références inter-fichiers CAO doivent être réécrites, pas copiées ;
- Le chargement dans le désordre. Les dépendances imposent un séquencement strict. C'est précisément ce qu'une chaîne asynchrone avec files et rejeu sait orchestrer sans tout bloquer au premier écart.
08 Combien ça coûte, et combien ça évite
Les ordres de grandeur sont les mêmes que pour l'ERP : une expertise dédiée entre 200 000 € et 1 million d'euros selon le périmètre, face à des fiascos qui se chiffrent en dizaines de millions. Avec une aggravante côté PLM : une structure produit corrompue se découvre tard, au premier assemblage qu'un bureau d'études ne parvient plus à ouvrir.
La durée dépend du nombre d'objets, de liens et de sources à réconcilier. C'est l'audit qui rend l'estimation fiable. Les réponses aux questions fréquentes sont sur la page méthodologie.