Windchill vers 3DEXPERIENCE : les outils natifs déplacent vos fichiers, pas vos données

« Il existe un outil pour ça. » C’est la phrase qui rassure en début de projet de migration PLM, et celle qui coûte le plus cher à la fin. Les passerelles natives entre Windchill et 3DEXPERIENCE déplacent très bien des fichiers. Le problème, c’est qu’un PLM ne stocke pas des fichiers. Il stocke une structure.

La donnée technique sans sa structure, c’est du bruit.

Piège n°1 : le fichier migré n’est pas la donnée migrée

Un modèle CAO transféré arrive intact dans la cible. Rassurant — et trompeur. Ce qui fait la valeur de ce modèle, ce sont ses liens : références entre pièces, nomenclatures, documents associés, dépendances. Copier le fichier sans reconstruire ces liens, c’est livrer une pièce qui ne sait plus à quel produit elle appartient.

Piège n°2 : les deux modèles objet ne décrivent pas le même produit

Windchill raisonne en WTPart, documents CAO, 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 deux mondes. Cette correspondance n’existe pas. Il faut la construire, attribut par attribut, état par état — pas la présumer.

Piège n°3 : l’outil natif décroche sur le réel

Une passerelle est conçue pour le cas standard : un objet propre, un cycle de vie par défaut, une révision linéaire. Le réel, lui, est fait de personnalisations, d’états de cycle de vie spécifiques, de révisions parallèles et d’historiques que personne n’a documentés. C’est précisément là, sur les exceptions, que l’outil natif s’arrête — et que la migration commence vraiment.

Piège n°4 : la donnée ne vient jamais d’une seule source

On planifie la migration depuis un Windchill unique et propre. Sur le terrain, la donnée réelle est éclatée : plusieurs instances, des sources annexes, des exports tableurs devenus la vraie référence. Un outil de point à point ne sait pas réconcilier ces sources. Il faut une logique capable de les ingérer, de les confronter et de les arbitrer.

Reconstruire, pas déplacer

C’est pour ça que nous traitons une migration PLM comme une reconstruction de structure, record par record : chaque objet est qualifié contre le modèle cible, ses liens sont rétablis, ses exceptions diagnostiquées et rejouées. Et c’est pour ça qu’un consultant dédié migration accompagne chaque projet : aucun outil ne remplace la compréhension du modèle métier qu’il faut reconstruire.

Déplacer des fichiers, n’importe quelle passerelle le fait. Migrer une donnée technique, c’est lui rendre la structure sans laquelle elle ne vaut rien.