Les 5 risques d’une migration de données PLM CAO mal préparée

Avant d’entrer dans les 5 risques spécifiques à la migration PLM/CAO, il faut regarder en face la réalité statistique des migrations de données dans l’industrie IT.

Ces statistiques concernent les migrations IT en général. En contexte PLM et CAO, les facteurs d’aggravation sont spécifiques : les données techniques sont structurellement plus complexes que les données de gestion (relations hiérarchiques multi-niveaux, liens natifs entre fichiers CAD et métadonnées, historiques de révision qui doivent être intacts pour la traçabilité réglementaire). Une corruption de données dans un ERP se traduit en erreur comptable. Une corruption dans un PLM peut se traduire en arrêt de production ou en non-conformité lors d’un audit client.

Derrière chaque non-conformité récurrente se cache une cause systémique. Dans un contexte industriel où l’ERP est le référentiel central, et où il dialogue avec un PLM, un MES, des outils qualité et des fournisseurs, ces causes remontent presque toujours à la qualité des données de référence.

Les fichiers CAD natifs (CATIA, CREO, NX, SolidWorks) ne sont pas de simples fichiers bureautiques. Ils contiennent des métadonnées structurées, révision, statut, auteur, liens vers les assemblages parents, qui doivent être préservées intactes lors d’une migration PLM. Quand ces métadonnées ne sont pas correctement mappées vers le modèle de données cible, le fichier migre mais ses relations sont perdues. Le plan est dans le système, mais il ne peut plus être retrouvé via la BOM ou le numéro de pièce.

Dans des environnements Windchill ou Teamcenter, les relations entre les objets (Part — Document — CAD Document) sont gérées via des structures de vault dont la logique varie selon les versions et les configurations. Une migration sans cartographie préalable de ces structures est une migration à l’aveugle.

> Exemple terrain : Équipementier aéronautique
Après une migration Windchill vers ENOVIA/3DEXPERIENCE, 12 % des plans CAD d’une famille produit critique ne sont plus accessibles via l’arborescence produit. Ils sont physiquement présents dans le vault, mais les métadonnées de version et les relations aux Part Numbers ont été tronquées lors du mapping. Reconstruction manuelle : 6 semaines, 3 ingénieurs méthodes mobilisés, production sur ce périmètre suspendue. Coût estimé : supérieur au budget initial du projet de migration pour ce seul périmètre.

La BOM (Bill of Materials) dans un PLM industriel n’est pas une liste plate. C’est une structure hiérarchique multi-niveaux avec des relations typées (composant-assemblage, variante-configuration), des révisions versionées, des statuts de workflow (Inwork, Released, Obsolete) et des liens vers les ECO/ECN qui ont justifié chaque modification. Cette complexité structurelle est précisément ce que les outils de migration généralistes ne gèrent pas correctement.

Lors d’une migration, une erreur de mapping sur la gestion des révisions peut produire des BOMs migrées à la bonne révision « texte » mais avec les liens vers les composants de la révision précédente. Résultat : une BOM qui semble correcte à l’affichage mais qui pointe vers des composants obsolètes en production.

> Exemple terrain : Industrie automobile
Une migration Teamcenter vers une nouvelle instance Teamcenter (upgrade majeur) produit des BOMs où les statuts de révision « Released » et « Inwork » ont été inversés pour 8 % des articles du périmètre concerné. Les opérateurs de production ont lancé des ordres de fabrication sur des spécifications en cours de modification, non validées. Détection de la non-conformité : lors du contrôle qualité final, 3 semaines après le go-live. Coût direct (rebuts + retouches + analyse cause racine) : estimé à plusieurs centaines de milliers d’euros.

Dans un industriel mâture, le PLM et l’ERP partagent un référentiel commun d’articles et de nomenclatures. Le PLM est la source de création et de validation des données de conception ; l’ERP consomme ces données pour les achats, la planification et la production. Cette intégration repose sur des interfaces (APIs, connecteurs, middlewares) qui sont configurées sur des identifiants de données précis : les Part Numbers, les révisions, les statuts.

Quand une migration PLM modifie les identifiants ou les structures de données sans mettre à jour les interfaces ERP en parallèle, le fil numérique se coupe. Les commandes d’achat continuent de s’appuyer sur des références qui n’existent plus dans le nouveau PLM, ou des BOMs de production dans l’ERP ne reflètent plus la structure validée dans le PLM. L’intégration silencieuse est le risque le plus difficile à détecter, tout semble fonctionner jusqu’au premier vrai besoin de traçabilité croisée.

> Exemple terrain : Industriel multi-sites
Suite à la migration de Windchill vers ENOVIA, le connecteur d’intégration PLM-SAP utilise les anciens identifiants Windchill comme clés de jointure. Ces identifiants sont transformés lors de la migration. Pendant 4 semaines, les mises à jour de BOM validées dans ENOVIA ne se propagent plus dans SAP. Les planificateurs travaillent sur des nomenclatures gelées. Les écarts ne sont détectés qu’au premier lancement d’OF sur un produit modifié après la migration.

Dans les secteurs réglementés, aéronautique (DO-178, AS9100), automobile (IATF 16949), défense, médical (ISO 13485), la traçabilité des décisions de conception n’est pas une option : c’est une obligation contractuelle et réglementaire. Chaque modification de composant doit être traçable vers un ECO/ECN approuvé, avec la justification, les validations et les signatures correspondantes.

Lors d’une migration PLM, les historiques de workflow ECO (statuts intermédiaires, commentaires, approbateurs, dates) sont souvent les premières données sacrifiées, soit parce qu’elles ne correspondent pas au modèle de données cible, soit parce qu’elles représentent des volumes énormes qui alourdissent la migration. Le choix pragmatique de « migrer uniquement les données actives » se traduit alors en risque de non-conformité lors du prochain audit.

Le cinquième risque est le plus systémique, et le plus difficile à visualiser en phase de cadrage. Quand les 4 risques précédents se matérialisent simultanément au go-live, l’équipe projet se retrouve à gérer une crise opérationnelle en urgence : des ingénieurs mobilisés pour reconstruire des données manuellement, une production qui ne peut pas lancer d’OF faute de BOMs fiables, des interfaces ERP silencieusement cassées, et une direction qui attend des explications.

Ce scénario n’est pas le cas extrême, c’est le cas médian. Seulement 16 % des migrations de données se terminent dans les délais et le budget prévus (Bloor Research). Les projets en dépassement enregistrent en moyenne un surcoût de 30 % et un retard de 41 %, ce qui, sur un projet de migration PLM de 6 mois budgété à 500 000 €, se traduit par 150 000 € de surcoût non planifié et 2,5 mois de retard sur le go-live.

> Ce que révèle McKinsey sur les causes de dépassement
McKinsey identifie la qualité des données sources comme l’une des causes les plus fréquentes de dépassement dans les grands projets IT. Pour les migrations spécifiquement, 44 % des équipes citent la sous-estimation du volume et de la complexité des données comme principale cause de dérapage budgétaire (Experian). La donnée n’est jamais « juste un transfert de A à B », c’est une transformation, et la profondeur de cette transformation est directement proportionnelle à l’état des données en entrée.

Certains signaux opérationnels indiquent que le problème qualité remonte à la qualité des données de référence plutôt qu’à un dysfonctionnement process ou machine. Les voici.

La norme ISO 9001:2015 impose un processus structuré de traitement des non-conformités. Mais dans la pratique industrielle, ce processus s’arrête souvent à l’action corrective immédiate, sans remonter à la cause documentaire systémique. Voici comment structurer un traitement qui va jusqu’à la source.

La pression sur les migrations PLM n’a jamais été aussi forte qu’en 2026, sous l’effet de trois tendances convergentes qui raccourcissent les fenêtres de décision des DSI et Directeurs Manufacturing.

1. La fin des licences legacy Windchill et la bascule vers Windchill+

PTC a introduit son nouveau modèle de licence ePLM le 1er juillet 2025. Les anciens packages de licences Windchill sont passés en mode « renouvellement uniquement ». À partir du 30 septembre 2026, les licences legacy ne pourront plus être renouvelées. Les entreprises encore sur Windchill 12 (dont le support standard a pris fin en juin 2024) ou Windchill 13 (support prévu jusqu’en juin 2027) sont sous double pression : fin de support et fin de licence. Cette contrainte force une décision de migration que certains industriels auraient préféré différer.

2. L’obligation de migration SAP S/4HANA entraîne le PLM

La migration vers SAP S/4HANA (échéance 2027 pour le support ECC standard) n’est pas un projet ERP isolé. Elle oblige à revoir les interfaces PLM-ERP existantes — ce qui, dans la plupart des architectures industrielles, équivaut à une remigration ou au moins à une refonte majeure des connecteurs PLM. Les deux projets se déroulent souvent en parallèle, créant une pression double sur les équipes IT et méthodes.

3. L’ambition Industrie 4.0 suppose un fil numérique propre

Les projets de digital twin, de maintenance prédictive et d’IA industrielle que déploient les entreprises reposent tous sur un prérequis commun : un fil numérique de données propres, traçables et cohérentes entre PLM, ERP et MES. Gartner prévoit que d’ici 2030, plus de 30 % des fabricants industriels s’appuieront sur un fil numérique basé sur le PLM pour contextualiser les données nécessaires à l’entraînement de leurs modèles d’IA (Manufacturing Predicts 2026, Gartner, décembre 2025). Mais ces systèmes ne fonctionnent pas sur des données dégradées. Une migration mal préparée est le meilleur moyen de dégrader durablement la qualité des données techniques de référence.

Le problème principal dans les migrations PLM mal préparées n’est pas la technologie, c’est l’ordre des opérations. Les entreprises décident du système cible, signent les licences, lancent le projet de migration, et traitent la qualité des données sources comme une tâche de fin de projet. À ce stade, il est trop tard pour prévenir : on est déjà en mode curatif.

La méthode Zero-Backlog Engine™ de Kleria inverse cet ordre. L’audit des données sources est la première chose qui se passe, avant la configuration du système cible, avant le mapping, avant les tests. Nous prenons en charge cette analyse et ce travail de préparation, pour que votre équipe puisse conduire la migration sur des données déjà qualifiées plutôt que de découvrir les problèmes au go-live.