Migration PLM : pourquoi faut-il d’abord comprendre son patrimoine CAO ?

Migrer vers un PLM est souvent présenté comme un projet de choix de solution, de définition des processus et de reprise des données. Mais avant de décider quoi migrer et comment le migrer, une question mérite d’être posée : Que contient réellement le patrimoine CAO de l’entreprise ?

Après plusieurs années de conception, un bureau d’études peut avoir accumulé des milliers, voire des centaines de milliers de fichiers : pièces, assemblages, plans, composants standards, variantes, références fournisseurs… À cela s’ajoutent les évolutions des méthodes de conception, les changements de règles de nommage, les propriétés renseignées différemment selon les équipes et les historiques parfois difficiles à exploiter. Le risque est alors le suivant : transférer dans le nouveau PLM les problèmes qui existaient déjà dans les données CAO.

Avant la migration, il est donc utile de prendre le temps d’analyser ce patrimoine pour comprendre sa structure, identifier ses incohérences et déterminer ce qui mérite réellement d’être repris.

La qualité des données conditionne la migration

Un PLM a vocation à centraliser les données produit et à en assurer la gestion tout au long de leur cycle de vie : références, nomenclatures, versions, propriétés, statuts et relations entre les différents objets. Mais le PLM ne peut pas, à lui seul, rendre cohérent un patrimoine qui ne l’est pas. On peut notamment retrouver :

• plusieurs fichiers correspondant à une même pièce ;
• des références ou composants qui ne sont plus disponibles ;
• des nomenclatures incomplètes ;
• des conventions de nommage différentes selon les projets ;
• des propriétés absentes ou renseignées de façon hétérogène ;
• des fichiers obsolètes dont le statut est difficile à déterminer ;
• des liens entre pièces et assemblages qui ne sont plus maîtrisés.

Ces situations ne sont pas nécessairement problématiques lorsqu’elles sont connues et traitées. Elles le deviennent lorsqu’elles sont découvertes après la migration. L’enjeu n’est donc pas simplement de déplacer les fichiers d’un environnement à un autre. Il s’agit d’abord de comprendre les données et les relations qui constituent le produit.

Commencer par cartographier le patrimoine CAO

La première étape consiste à obtenir une vision suffisamment précise de l’existant.

• Quels types de fichiers sont présents ?
• Comment les assemblages sont-ils structurés ?
• Quelles références sont utilisées ?
• Quelles propriétés sont renseignées ?
• Quels fichiers sont encore utilisés ?
• Quels composants sont partagés entre plusieurs produits ?

Cette cartographie permet de passer d’une vision fragmentée — fichier par fichier — à une vision plus globale du patrimoine produit. Elle constitue également une base utile pour définir les règles qui devront être appliquées dans le futur PLM.

Comprendre les nomenclatures

La nomenclature est l’une des informations centrales d’un produit. Elle décrit les relations entre les différents composants d’un assemblage et permet notamment de distinguer les pièces fabriquées, les composants achetés, les sous-ensembles ou encore les variantes. Encore faut-il que cette structure soit cohérente.

Avant une migration, il peut être nécessaire d’identifier les niveaux d’assemblage, les références utilisées, les composants manquants ou encore les différences de structuration entre projets. L’objectif n’est pas de tout normaliser à tout prix, mais de comprendre les règles réellement utilisées et de décider lesquelles doivent être conservées ou adaptées.

Aller au-delà du nom des fichiers

Le nom d’un fichier CAO ne suffit généralement pas à décrire un composant. Les fichiers contiennent également des propriétés qui peuvent être importantes pour les métiers : matière, masse, fournisseur, désignation, famille produit, référence interne, informations de fabrication ou d’achat, etc. Or, ces informations peuvent avoir été renseignées progressivement, avec des pratiques différentes selon les personnes ou les périodes.

Une analyse préalable permet de répondre à des questions concrètes :

• Quelles propriétés sont réellement présentes ?
• Lesquelles sont utilisées ?
• Lesquelles sont obligatoires ?
• Les valeurs sont-elles homogènes ?
• Existe-t-il plusieurs façons de renseigner la même information ?
• Quelles données doivent être conservées dans le futur PLM ?

Ce travail permet de distinguer les problèmes de données des simples différences de pratiques.

Les doublons : le problème n’est pas toujours celui que l’on croit

Les doublons sont un cas classique dans les patrimoines CAO historiques.

Deux fichiers peuvent représenter une même pièce avec des noms différents. À l’inverse, deux géométries très proches peuvent correspondre à des composants réellement différents. C’est pourquoi une simple comparaison des noms de fichiers ne suffit pas toujours.

Identifier ces situations avant la migration permet ensuite de décider, au cas par cas, quelles références conserver, lesquelles rapprocher et lesquelles maintenir distinctes. Cette rationalisation peut avoir un impact direct sur la qualité du futur référentiel : moins de références inutiles, des nomenclatures plus lisibles et une meilleure maîtrise des composants réutilisés.

Les références manquantes révèlent les dépendances cachées

Un autre problème apparaît fréquemment lorsqu’on analyse des assemblages anciens : certains composants ne sont plus accessibles.

Un fichier peut avoir été déplacé, renommé ou supprimé. Une référence peut également pointer vers un emplacement qui n’existe plus. Le problème ne concerne alors plus un fichier isolé, mais la relation entre plusieurs fichiers.

Pour préparer une migration, il est donc important de pouvoir identifier ces dépendances et de savoir quels assemblages pourront être reconstruits correctement dans le nouvel environnement. Cela permet de traiter les cas problématiques en amont plutôt que de les découvrir au moment de l’import.

Une analyse qui ne doit pas rester réservée à l’informatique

La préparation d’une migration PLM est souvent considérée comme un sujet informatique. Pourtant, les données concernées sont produites et utilisées par les métiers.

Le bureau d’études connaît les pratiques de conception. Les méthodes et l’industrialisation connaissent les contraintes de fabrication. Les achats utilisent certaines informations fournisseurs. La qualité s’intéresse à la traçabilité. L’informatique, de son côté, doit garantir la cohérence et la pérennité du système.

Une vision partagée du patrimoine permet donc de confronter les données existantes aux besoins réels de l’entreprise. L’analyse des données devient ainsi un support de décision, et pas uniquement une opération technique préalable à la migration.

Que faut-il réellement migrer ?

Une question revient alors naturellement : faut-il vraiment tout migrer ? La réponse est rarement oui. Selon leur valeur et leur état, certaines données pourront être :

• migrées telles quelles ;
• nettoyées avant migration ;
• rationalisées ;
• complétées ;
• renommées ;
• conservées uniquement à des fins d’archivage ;
• ou écartées du nouveau référentiel.

Encore faut-il disposer des éléments nécessaires pour prendre ces décisions. Une analyse du patrimoine CAO permet justement de mieux cibler le périmètre de migration et d’éviter de traiter de la même manière des données très différentes.

KAD4ALL pour analyser son patrimoine CAO

C’est dans cette phase de préparation que KAD4ALL peut intervenir.

L’objectif n’est pas de remplacer un PLM, mais de fournir une vision exploitable du patrimoine CAO avant son intégration dans un nouveau système. KAD4ALL permet notamment d’explorer les données existantes, leurs propriétés et leurs relations afin de mettre en évidence les éléments qui méritent une attention particulière.

Cette approche peut être utilisée pour :

• analyser les propriétés présentes dans les fichiers ;
• repérer des situations de doublonnage ;
• identifier les références nécessaires aux assemblages ;
• visualiser les relations entre les données ;
• mieux comprendre la structure du patrimoine ;
• préparer les règles de nettoyage et de migration.

L’intérêt est surtout de partir de ce qui existe réellement dans les données, plutôt que de s’appuyer uniquement sur les procédures ou standards théoriquement appliqués.

Préparer le PLM en partant des données réelles

Une migration PLM est aussi une occasion de faire le point sur les pratiques de gestion des données produit. Avant de définir les règles du futur référentiel, l’entreprise peut ainsi confronter trois éléments : ce qu’elle pense avoir, ce qu’elle possède réellement et ce dont elle aura besoin demain.

Cette comparaison permet de mieux cibler les travaux de préparation et d’éviter de consacrer du temps à des données sans valeur pour le nouveau système. Elle facilite également les discussions entre les équipes techniques, les métiers et les responsables du projet PLM.

Conclusion : avant de migrer, savoir ce que l’on possède

La migration vers un PLM ne commence pas au moment où les fichiers sont importés. Elle commence lorsque l’entreprise est capable de répondre à quelques questions simples :

Quelles données possède-t-elle ? Comment sont-elles structurées ? Quelles relations existent entre elles ? Quelles informations sont fiables ? Et lesquelles doivent être traitées avant d’être reprises ?

Cette connaissance de l’existant permet ensuite de définir un périmètre de migration plus pertinent et de construire un référentiel PLM sur des bases maîtrisées.

Avant de migrer ses données CAO, il faut donc commencer par savoir ce que l’on migre.