Avant une bascule PLM, la question qui revient toujours est la même : comment être certain que les données arrivées dans le nouveau système sont bien celles qu’on a quittées ? La réponse habituelle consiste à comparer des nombres d’objets avant et après. C’est nécessaire, mais très insuffisant : une migration peut afficher les mêmes comptages des deux côtés et livrer un environnement inexploitable.
Le contrôle ne se joue pas à l'arrivée
Une migration passe par au moins trois états : les données telles qu’elles existent dans la plateforme source, leur extraction vers un environnement intermédiaire, puis leur import dans la plateforme cible. Chacune de ces étapes peut dégrader le résultat, et une anomalie constatée à l’arrivée ne dit pas à quel moment elle est née.
Nous produisons donc un relevé à chaque étape, conçu pour être comparable aux autres. On ne cherche pas seulement à savoir si le compte est bon, mais à suivre pas à pas le trajet de la donnée et à situer précisément l’endroit où deux plateformes cessent de dire la même chose.
Cette traçabilité change la nature du travail de correction. Sans elle, une anomalie détectée après import déclenche une investigation générale. Avec elle, on sait immédiatement si le problème vient de la préparation, de l’extraction ou du chargement, et le correctif porte sur la bonne étape.
Ce que contient un relevé
Un relevé utile va bien au-delà du dénombrement. Il porte sur :
- les comptages, par type d’objet et par périmètre ;
- les droits d’accès, car une donnée arrivée dans le mauvais contexte de travail est présente sans être utilisable ;
- la somme des éléments portés par chaque objet, qui révèle les pertes partielles invisibles à un simple comptage ;
- les attributs définis pour la transformation, ceux dont la valeur change de forme entre source et cible ;
- les liens, c’est-à-dire l’ensemble des relations qui constituent la maquette numérique.
Ce dernier point est le plus coûteux à contrôler et le plus coûteux à négliger. Un objet peut arriver intact et se retrouver détaché de l’ensemble auquel il appartenait. Les comptages restent justes, la structure est fausse.
Diffusion ou migration : deux transferts que l'on confond
Deux modes de transfert coexistent et se ressemblent à l’écran. La diffusion transmet une donnée sans transfert de droits : elle reste la propriété de l’entreprise source. La migration transmet la donnée avec ses droits : elle devient la propriété de l’entreprise cible.
La distinction est sans effet sur les comptages, et décisive à l’usage. Une donnée diffusée existe, s’affiche, se consulte, mais ne peut pas recevoir de nouvelle version : sans la pleine propriété, aucune évolution n’est possible dans le système cible. Le jour où un bureau d’études tente de la faire évoluer, le projet découvre que ce qu’il croyait migré ne l’était pas.
Contrôler le mode de transfert objet par objet fait donc partie du travail de validation, et ce contrôle doit intervenir avant la bascule : une donnée chargée en diffusion ne sera pas rattrapée par une mise à jour ultérieure. Le seul recours est de recommencer.
S’y ajoute la question des attributs. Les informations qui décrivent une donnée dans la cible proviennent souvent de plusieurs sources agrégées au moment du chargement. Le processus est complexe et surtout non répétable : ce qui n’a pas été correctement composé à l’import ne se corrige pas par un simple rechargement.
Ce qui casse le plus souvent
Trois causes reviennent, et aucune n’est technique au sens strict.
Les données ont bougé entre-temps. Des adaptations faites dans la source pour d’autres chantiers modifient la structure : des branches d’arbre manquent, sans que personne ait songé à prévenir l’équipe de migration.
La cible a été retouchée. Des reprises manuelles appliquées dans la plateforme cible après la première image créent une déviation par rapport à l’attendu, et l’import échoue ou produit un résultat différent de la campagne de test.
Les données ne sont pas préparées comme prévu. L’outil ne peut alors plus opérer le transfert de droits attendu, et les objets concernés basculent en diffusion au lieu d’être migrés, avec les conséquences décrites plus haut.
Le point commun de ces trois cas : ce ne sont pas des défaillances de l’outil, mais des écarts entre l’état supposé et l’état réel des données. C’est précisément ce que les relevés servent à rendre visible.
Ce qu'on oublie de contrôler
L’attention se porte spontanément sur la cible. Or l’essentiel se joue en amont, dans la préparation de la source.
Le gel des données à transférer, sans lequel le périmètre migré n’est jamais celui qui a été testé.
Le niveau d’imbrication des assemblages, qui rend le contexte d’export plus ou moins difficile à constituer.
Le régime de propriété intellectuelle applicable à chaque donnée. Le transfert doit respecter le cadre légal entre les entités concernées, selon qu’un accord d’usage existe ou non sur une donnée. Le format d’extraction diffère en conséquence, avec ou sans protection de la propriété intellectuelle, ce qui fait varier le résultat technique entre succès et échec. Ce point ne se règle pas au moment de l’extraction : il suppose d’avoir qualifié en amont le statut de chaque donnée.
La conformité du format, une donnée stockée dans un format inadapté révélant simplement qu’elle n’aurait jamais dû l’être.
Ces contrôles ne relèvent pas de la migration mais de la qualité du patrimoine existant. La migration ne fait que la mettre en lumière, souvent au plus mauvais moment.
Du relevé à la décision
Les relevés ne valent que par ce qu’ils permettent de décider. Nous les consolidons dans un document de synthèse destiné aux équipes métiers, qui présente les impacts et les points critiques à arbitrer : reprise sur erreur, redéfinition d’une donnée, exclusion d’un périmètre, report d’une vague.
Ces décisions appartiennent au métier, pas à l’équipe technique. Le rôle du contrôle est de les rendre possibles avant la bascule, plutôt que de les subir après.
Article rédigé par Emilien Dessalles, dirigeant et consultant PLM chez Essancio.
Vous préparez une migration PLM ?
Nous intervenons à vos côtés pour définir la stratégie de contrôle, qualifier vos données sources et préparer les arbitrages métier avant la bascule.