Windchill vers 3DEXPERIENCE : vérifier la couverture des outils de migration
« Il existe un outil pour ça. » Avant d’en déduire un planning, faites passer un assemblage réel : fichiers, articles, liens, révisions et états. Le résultat attendu est une structure utilisable dans la cible, avec un rapport qui explique les écarts.
Les outils natifs ont des capacités de structure et de mapping. PTC documente, pour son export/import Windchill, l’export de structures produit et CAO ainsi que des règles de transformation d’attributs. Cela ne démontre pas une couverture complète de Windchill vers 3DEXPERIENCE : il faut vérifier les opérations prises en charge par l’outil retenu, dans les versions et configurations du projet.
La couverture d’un outil se vérifie sur les objets, les liens et les usages à migrer.
Piège n°1 : le fichier migré n’est pas la donnée migrée
Un modèle CAO peut arriver intact dans la cible sans que tous ses liens soient exploitables : références entre pièces, nomenclatures, documents associés, dépendances. Vérifiez séparément l’intégrité du fichier, la présence des relations attendues et la résolution de l’assemblage dans la configuration retenue. Un chargement réussi ne démontre pas, à lui seul, ces trois résultats.
Piège n°2 : présumer la correspondance entre les modèles objet
Un WTPart, son document CAO et leurs relations doivent trouver des objets et des liens cibles dont le sens métier est validé. Les types, attributs, révisions et états disponibles dépendent de la configuration des deux environnements. Certaines correspondances peuvent être directes ; d’autres demandent une transformation ou un arbitrage.
Consignez, pour chaque type source, le type cible, les attributs repris, les relations attendues, les règles de version et les états autorisés. Testez cette table de correspondance sur des objets réels. L’outil peut exécuter un mapping sans que ce mapping soit le bon pour le bureau d’études.
Piège n°3 : valider l’outil uniquement sur le cas simple
Personnalisations, états spécifiques, révisions parallèles et historiques anciens doivent entrer dans l’essai de couverture. Selon l’outil et sa configuration, ces cas peuvent être pris en charge directement, demander un paramétrage ou nécessiter un traitement complémentaire.
Pour chaque cas, exigez un résultat vérifiable : données conservées ou transformées selon une règle approuvée, écart explicite, puis correction et rejeu possibles. Un type d’objet absent d’une démonstration reste à tester ; il n’est ni automatiquement couvert, ni nécessairement impossible à migrer.
Piège n°4 : découvrir trop tard les sources annexes
Le périmètre peut tenir dans une instance Windchill. Il peut aussi inclure plusieurs instances, des sources annexes ou des tableurs utilisés comme référence métier. Établissez l’inventaire avant de figer les flux.
Si plusieurs sources décrivent le même article, définissez laquelle fait autorité pour chaque donnée et comment résoudre les conflits. Vérifiez ensuite si l’outil retenu assure cette réconciliation ou s’il faut l’ajouter à la chaîne. C’est l’un des livrables d’un audit de données en début de projet.
Rendre la couverture vérifiable
Dans notre méthodologie en cinq phases, chaque objet est qualifié contre le modèle cible, ses liens sont contrôlés et ses exceptions sont diagnostiquées et rejouées. Le choix de l’outil suit cette couverture attendue et les résultats des essais.
La recette combine comparaison des structures et vérification des usages CAO : voir comment valider une nomenclature migrée. Pour définir le périmètre et les modèles à reprendre, poursuivez avec le guide de la migration de données PLM.