Valider une nomenclature migrée : comparer la structure et tester l'assemblage

Trente-huit mille articles, deux cent huit mille liens, rapport de chargement au vert. L’équipe de migration présente des comptages de réconciliation qui tombent juste à l’unité près : tout ce qui est sorti de Windchill est entré dans 3DEXPERIENCE, zéro rejet sur la passe finale.

Trois semaines plus tard, un ingénieur du bureau d’études ouvre l’assemblage de tête de la ligne de produits principale. Il résout 340 de ses 412 composants. Les 72 autres sont dans le système, correctement, avec tous leurs attributs, et l’assemblage ne les trouve pas.

Le chargement n’avait signalé aucun échec. Les comptages étaient bons. La validation était incomplète.

Un fichier arrivé intact n’est pas un article migré

Un chargement réussi vérifie ce que le mécanisme de chargement contrôle. Il ne remplace pas la validation des relations et des usages, en ERP comme en PLM.

Un centre de coûts ERP n’est pas autonome : ses affectations et sa validité doivent être cohérentes. SAP documente notamment les affectations à la société, au centre de profit et à la hiérarchie dans les données de base des centres de coûts.

En PLM, les contrôles portent notamment sur les composants, les associations aux plans et aux articles, et les révisions. Un fichier identique octet pour octet peut rester inutilisable si ses références ne se résolvent pas dans la cible. Les outils peuvent prendre en charge ces structures ; il faut vérifier leur couverture sur le périmètre réel.

Le rapport de chargement reste une preuve nécessaire. Pris seul comme recette, il laisse les contrôles suivants sans réponse.

Les références doivent se résoudre dans la cible

Selon l’outil CAO et son intégration au PLM, la résolution des composants s’appuie sur des identifiants, des noms de fichiers, des emplacements ou des relations gérées. Un changement de coffre ou de règles de résolution peut rompre des références alors que les fichiers sont présents.

La chaîne doit préserver ou transformer les références selon les exigences de la cible, puis vérifier leur résolution. Une réécriture systématique n’est pas une règle générale. Les cas à traiter restent concrets : fichiers déplacés entre coffres, correspondances historiques non documentées, objets exclus du périmètre mais encore référencés.

Certains défauts sont détectés dès le chargement ou le check-in. PTC indique que des dépendants CATIA V5 requis mais incomplets peuvent bloquer l’upload et le check-in ; les préférences influencent ce comportement. D’autres écarts échappent à ces contrôles. Vérifiez ce que détecte le connecteur utilisé, puis testez la résolution dans l’environnement cible.

Quatre niveaux, appliqués à un graphe

Les quatre niveaux de test se complètent : chacun répond à une question différente.

Objets acceptés. Le rapport de chargement identifie les objets acceptés, les rejets et les contrôles exécutés par le chargeur. Il ne démontre pas à lui seul la conformité de toute la structure.

Comptages réconciliés. Réconciliez les objets et les liens, en tenant compte des transformations et exclusions approuvées. Par exemple, 208 000 liens attendus et 204 000 liens chargés laissent 4 000 liens à expliquer, même si les comptages d’objets sont équilibrés.

Structures conformes. Comparez automatiquement les nomenclatures source et cible dans des configurations équivalentes, selon le mapping approuvé. La comparaison doit porter sur les relations et leurs attributs, pas uniquement sur la présence des enfants.

Le produit se comporte. Vérifiez la résolution CAO et les processus métier dans la cible. Une partie de ces tests peut être automatisée ; l’ingénieur complète la recette par les usages et les décisions métier que les contrôles techniques ne démontrent pas.

Par exemple, Creo TOOLKIT permet de charger des modèles par programme. PTC précise qu’un retour de chargement réussi peut masquer des composants inhibés ou figés après erreur : il faut aussi récupérer les erreurs de résolution. L’automatisation doit donc inspecter le résultat, et sa couverture dépend des interfaces CAO disponibles.

Comparer deux explosions, ligne à ligne

Un contrôle automatisé central consiste à exporter l’explosion multiniveau depuis la source et la cible, puis à comparer les lignes attendues après transformation.

Définissez d’abord la configuration à comparer. Dans Windchill, les spécifications de configuration sélectionnent les versions selon, notamment, une vue, un état, une baseline ou une effectivité. Comparer des extractions issues de filtres différents peut fabriquer un écart ou en masquer un.

Quatre précautions rendent le résultat exploitable :

• Comparez l’explosion, pas le premier niveau. Une comparaison de premier niveau passe alors qu’un enfant situé trois niveaux plus bas a perdu les siens. Le défaut que vous cherchez dépend de la profondeur.
• Fixez des configurations équivalentes, y compris les révisions et itérations attendues, la vue, les options et l’effectivité applicables au périmètre. Consignez les transformations approuvées quand les modèles diffèrent.
• Comparez chaque occurrence dans son chemin parent. Identifiant de l’enfant après mapping, révision ou itération attendue, quantité, unité, position et effectivité doivent correspondre aux règles convenues. Le même composant au mauvais endroit reste un défaut.
• Normalisez le tri et les formats avant de comparer, sans supprimer les occurrences répétées ni les différences significatives.

Exécutez ces contrôles sur tous les assemblages de tête et toutes les configurations du périmètre convenu. Les rapprochements d’objets, de relations et d’attributs couvrent également les objets hors de ces assemblages. L’échantillon de recette manuelle vient compléter cette couverture complète. Chaque écart doit être corrigé ou faire l’objet d’une dérogation explicitement approuvée et tracée avant la bascule.

Les états de cycle de vie qui survivent au chargement, pas au processus

La présence d’un état cible valide ne prouve pas que le droit d’usage de l’article a été conservé.

Si la source a onze états et la cible six, certaines correspondances demandent un arbitrage. Un objet peut alors se charger dans un état techniquement valide tout en perdant une restriction métier.

Le problème apparaît plus tard, dans le processus. Un article migré en « Validé » qui était en réalité en « Validé, sous réserve de qualification site » devient consommable par la production, trois semaines plus tôt qu’il ne devrait. La donnée est valide. L’état métier est faux.

Faites valider le mapping par les responsables métier, puis contrôlez automatiquement l’état attendu de chaque objet à partir de son état source et des conditions applicables. Comparer à un mapping erroné ne détectera pas l’erreur de décision.

Complétez par des parcours de processus couvrant les états, transitions, rôles et restrictions de site concernés. Certains scénarios peuvent être automatisés ; les ingénieurs vérifient aussi que les droits et usages proposés correspondent au besoin réel. Un seul article par état suffit uniquement si les autres conditions n’introduisent pas de comportement différent.

Choisir les assemblages de recette selon les risques

La capacité de recette manuelle est limitée. Vingt assemblages peuvent constituer un jeu de départ, pas une norme de couverture. La sélection doit couvrir les familles de produits, les configurations et les risques du périmètre, puis être étendue si les défauts trouvés l’exigent.

Incluez notamment :

• la structure la plus profonde du parc, quelle qu’elle soit ;
• l’assemblage qui compte le plus de composants ;
• des assemblages couvrant les articles de chaque coffre source, s’il y en a plusieurs ;
• des composants portant chacun des états de cycle de vie correspondants, en particulier les états fusionnés et les restrictions de site ;
• les configurations et effectivités critiques, notamment les variantes et les changements de révision ;
• des structures contenant les articles les plus anciens, créés sous des conventions dont personne ne se souvient ;
• tout article connu pour exister en branches de révision parallèles ;
• les assemblages de la ligne de produits qui pèse le plus au chiffre d’affaires, parce que le risque métier est un critère aussi légitime que le risque technique.

Consignez pour chaque cas le risque couvert, la configuration ouverte et le résultat attendu. Un jeu composé uniquement d’assemblages faciles laisse les cas difficiles sans preuve : c’est le piège de la validation sur un échantillon propre. Cette sélection ne réduit pas le périmètre des contrôles automatisés.

Ce que la validation ne rattrape plus après le Go-Live

Un défaut découvert après la bascule peut déjà avoir produit des données dérivées, en ERP comme en PLM.

En PLM, une erreur peut n’apparaître qu’à l’ouverture d’un modèle, des mois après la bascule. Entre-temps, des évolutions techniques, de nouvelles révisions et des données de production aval peuvent reposer sur la structure migrée. Corriger l’objet d’origine ne corrige pas automatiquement ce qui en a été dérivé.

Le dry run doit donc inclure les comparaisons complètes, les tests de résolution et la recette métier des assemblages. Reporter ces vérifications à l’hypercare reporte aussi la découverte des dépendances à corriger.

Le critère d’acceptation à écrire dans le plan

Écrivez un critère qui couvre les différents niveaux de preuve :

Les contrôles automatisés réconcilient les objets, relations et attributs sur tout le périmètre. Les explosions de tous les assemblages de tête et de toutes les configurations convenues correspondent à la source après mapping : chemin parent et occurrence, identifiant, révision ou itération, quantité, unité, position et effectivité. Les états correspondent au mapping métier validé. Aucun écart bloquant ne reste ouvert ; les éventuelles dérogations sont approuvées et tracées.

Les tests de résolution CAO vérifient les composants attendus et les erreurs remontées. Chaque assemblage de l’échantillon de recette, défini selon les risques et les familles de produits, s’ouvre et résout tous les composants attendus dans les configurations prévues, puis passe les usages métier attendus. Les parcours de processus couvrent les états, transitions, rôles et restrictions concernés. Cette recette complète les contrôles automatisés sur le périmètre entier.

Le dossier de recette doit identifier les extractions, les règles de comparaison, les résultats et les approbateurs. La suite de l’enchaînement est dans le guide de la migration de données PLM, et le temps d’arbitrage que cette validation génère appartient au plan, comme chantier à part entière.

Si vous ne savez pas encore combien de liens votre structure produit contient réellement, ni combien de références ne se résolvent plus, c’est exactement ce que mesure un audit de préparation avant que le moindre planning soit engagé.