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.
Un PLM conserve des liens autant que des fichiers : références entre pièces, nomenclatures, associations CAO, états de maturité et dépendances. Copier les fichiers sans préserver ces relations laisse une structure produit incomplète. Vérifiez la couverture des outils de migration sur les modèles source et cible réels.
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 : décidez quelles révisions et preuves doivent rester accessibles, puis comparez une reprise complète avec un périmètre opérationnel réduit et une archive. Le coût dépend des liens, des besoins de consultation et de conservation.
04 Rapprocher les modèles produit source et cible
Windchill et 3DEXPERIENCE organisent différemment articles, documents CAO, relations et états de maturité. Définissez et vérifiez le mapping sur vos modèles paramétrés, attribut par attribut, état par état et type de lien par type de lien.
La documentation fournit un point de départ. Les personnalisations, cycles de vie locaux et conventions d’équipe demandent une analyse avec les responsables métier. Notre article sur la migration Windchill détaille les questions à examiner.
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.
Recherchez les sources complémentaires : autres instances PLM, coffres CAO annexes et référentiels locaux. L’audit cartographie leurs responsables et dépendances pour éviter d’omettre une partie de la structure produit.
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 : basculer après réconciliation des structures, contrôles de recette CAO et revue des exceptions restantes.
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 Ce qui détermine le budget
L’estimation doit couvrir objets, types de liens, révisions, états de cycle de vie, dépendances CAO et systèmes sources. Les règles spécifiques et arbitrages métier peuvent demander plus d’effort que le seul nombre d’objets ne le suggère.
Une structure produit rompue peut rester inaperçue jusqu’à l’ouverture d’un assemblage concerné. Prévoyez la réconciliation des structures et la recette CAO avant la bascule, au-delà du rapport de chargement.
L’audit de préparation établit le périmètre et les analyses nécessaires au devis. Les dépenses de programmes ERP décrites dans notre article sur les coûts ne sont pas un barème pour une migration PLM.
09 Big bang, phasé ou fil de l’eau : choisir la bascule
La frontière entre vagues doit respecter les assemblages et les composants partagés. Le graphe produit détermine les dépendances à gérer pendant la coexistence.
Comparer les stratégies de bascule PLM | Stratégie | Organisation | Contrainte principale | Preuve avant bascule |
|---|
| Big bang | Une fenêtre pour le référentiel convenu | Durée du gel et vérification des assemblages | Répétition chronométrée à volumétrie réelle et réconciliation des structures |
| Phasée | Vagues par famille produit ou site cohérent | Composants partagés entre vagues | Responsabilités et synchronisation des objets partagés |
| Fil de l’eau | Transfert progressif pendant la coexistence | Révisions et liens modifiés dans les deux systèmes | Capture des changements, arbitrage des conflits et cohérence des assemblages |
10 Un cas réel anonymisé : l’assemblage qui ne s’ouvrait pas
Un fabricant d’équipements mécaniques migrait de Windchill vers 3DEXPERIENCE : environ 38 000 WTParts, 210 000 relations et vingt ans d’historique. Une preuve de concept avec un outil natif avait été déclarée réussie.
Constat de l’audit. Le pilote portait sur 500 articles simples. L’extraction complète a révélé 4 200 documents CAO dont les références dépendaient d’une ancienne table de correspondance entre coffres. Le cycle de vie comptait onze états personnalisés, dont six sans équivalent cible et trois encore utilisés. Enfin, 1 100 articles possédaient deux branches de révision parallèles.
Intervention. La table historique a été explicitée et intégrée à la résolution des références CAO. Les états ont été mappés avec l’équipe qualité ; deux ont été regroupés, avec une décision tracée. Les bureaux d’études ont arbitré les branches parallèles pendant six semaines.
Résultat. La chaîne a exécuté les reprises par familles d’assemblages, dans l’ordre des dépendances, avec rejeu des erreurs. Le chargement final portait sur 37 800 articles et 208 000 relations ; 940 objets rejetés ont été résolus avant bascule. La recette comprenait l’ouverture des vingt plus grands assemblages en cible par un ingénieur, avec vérification complète des références.
Le pilote était insuffisamment représentatif pour dimensionner l’ensemble : les articles simples ne couvraient pas les références rompues. Ces chiffres décrivent cette mission, sans constituer une promesse de résultat pour un autre référentiel.
11 Checklist de migration des données PLM
Les contrôles propres au graphe produit, à rattacher à un responsable et à une preuve de recette.
- Inventorier chaque source, y compris les coffres CAO annexes et référentiels locaux ;
- Compter objets et liens, révisions par pièce et états de cycle de vie utilisés ;
- Mapper chaque état personnalisé, avec un responsable métier pour chaque décision ;
- Lister les types de relations et vérifier la préservation de chaque type nécessaire ;
- Tester tôt la résolution des références CAO sur des assemblages complets ;
- Identifier les branches de révision parallèles et décider comment les conserver ou les rapprocher ;
- Convenir de la profondeur historique, des besoins de consultation et de conservation ;
- Séquencer les chargements selon les dépendances et vérifier les relations une fois leurs objets présents ;
- Valider l’ouverture et la structure des assemblages en cible avec les ingénieurs ;
- Réserver le temps d’arbitrage métier et suivre les décisions restantes dans le planning.