Nous avons exploré, dans nos deux premiers articles, les origines de la coexistence de plusieurs générations de PLM et ses impacts multiples : coûts récurrents croissants, raréfaction des compétences, divergence des processus, frein à l’innovation. Face à ce constat, une question réside : que faire ?
La réponse n’est pas univoque. Contrairement à une idée reçue, la convergence vers un PLM unique n’est pas systématiquement l’objectif à atteindre. Selon votre contexte (cycles produits, niveau d’interdépendance entre programmes, besoins de partage d’information), plusieurs stratégies peuvent être pertinentes.
Parmi les différentes approches de maîtrise ou de sortie du multi-PLM, chacune répond à des situations spécifiques et nécessite des arbitrages différents. L’enjeu n’est donc pas de choisir « la bonne solution », mais celle qui correspond le mieux à votre réalité industrielle et à vos priorités stratégiques.
Face aux défis identifiés dans l’article précédent, plusieurs approches stratégiques peuvent être envisagées pour maîtriser ou sortir de la coexistence de plusieurs générations de PLM.
I - Convergence progressive vers un PLM unique
La convergence progressive vers un système PLM unique consiste à basculer progressivement l’ensemble des programmes et des produits vers une plateforme cible commune. Cette approche vise à terme la rationalisation complète du paysage applicatif PLM.
Toutefois, cette stratégie repose sur un prérequis fondamental : la standardisation des processus métiers. Avant toute bascule technique, il est essentiel d’harmoniser les méthodes de travail, les workflows de validation, les règles de gestion des configurations. Sans cette standardisation préalable, la convergence technique risque de simplement déplacer la complexité au lieu de la réduire. Les équipes continueront à travailler différemment, mais sur le même outil, ce qui limitera considérablement les bénéfices attendus.
Une fois ce prérequis satisfait, la démarche de convergence doit être progressive et priorisée. Il s’agit ici d’identifier les périmètres les plus critiques ou les plus porteurs de valeur : les nouveaux programmes, les produits nécessitant le plus de collaboration inter-équipes, ou encore ceux qui bénéficieront le plus de la réutilisation de composants. Ces programmes sont basculés en priorité vers le PLM cible.
Cette approche nécessite une méthodologie rigoureuse de bascule, qui va bien au-delà d’une simple migration IT. On parle de transférer non seulement les données techniques, mais aussi de faire évoluer les processus, de former les équipes, d’adapter les interfaces avec les systèmes tiers (ERP, MES, gestion documentaire). La bascule d’un programme est un projet de transformation métier à part entière !
Les programmes ou produits en fin de vie, dont les données doivent être conservées pour des raisons réglementaires mais qui ne nécessitent plus d’évolutions majeures, peuvent, eux, rester sur l’ancien système jusqu’à leur obsolescence naturelle. Cette approche pragmatique évite de mobiliser des ressources importantes pour migrer des données peu utilisées.
II - Intégrer sans fusionner : l'interopérabilité comme solution
Lorsque la convergence totale n’est pas envisageable, pour des raisons de coûts, de risques, ou encore de pertinence métier, une stratégie alternative consiste à maintenir plusieurs PLM tout en garantissant leur interopérabilité.
Cette approche s’appuie sur la mise en place de solutions middleware ou d’outils d’intégration qui permettent l’échange de données entre les différents systèmes PLM. Elles assurent la synchronisation des informations critiques (nomenclatures, données techniques, statuts de validation) sans nécessiter de fusion des plateformes.
L’utilisation de formats d’échange standards facilite grandement cette interopérabilité. Le format STEP (Standard for the Exchange of Product model data), est par exemple largement utilisé dans l’industrie pour garantir le transfert de modèles 3D et de données techniques entre systèmes hétérogènes. D’autres standards comme PLCS (Product Life Cycle Support) ou OMG (Object Management Group) peuvent également être mobilisés selon les besoins.
Cette stratégie présente l’avantage de la flexibilité : chaque entité conserve son outil adapté à ses spécificités métiers, tout en garantissant la circulation de l’information nécessaire à la collaboration. Elle évite également le risque et le coût d’une bascule massive.
En revanche, elle comporte des limites significatives. L’intégration par middleware crée une couche de complexité supplémentaire, avec des risques de désynchronisation, de perte de données, ou d’incohérences entre systèmes. La qualité des données devient alors un enjeu critique, car toute erreur dans un système peut se propager aux autres. Enfin, cette approche ne résout pas le problème des coûts récurrents multiples (licences, maintenance, expertises).
III - Coexistence organisée : gouvernance et maîtrise durable
Dans certains cas, la coexistence de plusieurs PLM peut être un choix stratégique rationnel et assumé, notamment lorsque les processus et les ensembles de données restent bien séparés entre eux. Si les gammes de produits sont distinctes, sans besoin de partage ou de synchronisation d’information entre elles, maintenir des environnements PLM dédiés peut être parfaitement justifié.
Cette approche nécessite toutefois une gouvernance centralisée et rigoureuse pour éviter que la situation ne devienne incontrôlable. Il s’agit alors de définir clairement :
- Les périmètres de responsabilité : quel PLM pour quel produit/programme ?
- Les règles de décision : qui arbitre l’affectation des nouveaux programmes ?
- Les standards communs : formats de données, règles de nommage, processus critiques
- Le pilotage des coûts : suivi unifié des budgets de run, renégociations groupées avec les éditeurs
Pour les programmes en fin de vie, des solutions d’archivage sécurisé permettent de conserver l’accès aux données techniques tout en décommissionnant les environnements actifs. Ces solutions répondent aux exigences réglementaires de traçabilité (notamment dans l’aéronautique ou la défense) tout en réduisant les coûts de maintenance.
Il est important de préciser que l’inaction peut aussi être un choix rationnel. Si les surcoûts liés à la coexistence restent maîtrisables et que le retour sur investissement d’une convergence n’est pas démontrable, maintenir un statu quo peut être la décision la plus raisonnable. Dans ce cas, l’effort doit porter sur l’optimisation de la gouvernance et la maîtrise des coûts récurrents.
IV - Piloter la décision par la valeur : Au-delà de la technique, une question stratégique
Quelle que soit la stratégie envisagée, le choix doit être guidé par une analyse rigoureuse de la valeur : quels gains attendre de chaque approche ? Quels investissements sont nécessaires ? Quel est le retour sur investissement réaliste ?
Une analyse qui doit intégrer non seulement les coûts techniques (licences, infrastructures, développements), mais aussi les bénéfices opérationnels (amélioration de la collaboration, accélération du time-to-market, renforcement de la réutilisation, capacité à exploiter les données pour l’analyse ou l’intelligence artificielle).
Ce qui distingue un projet PLM d’un projet SI classique, c’est son impact direct sur les processus métiers de conception, d’industrialisation et de maintien en condition opérationnelle. Il n’est pas simplement question de remplacer un outil, mais bien de transformer la façon dont l’entreprise conçoit, produit et maintient ses produits. Les gains d’un PLM unique vont au-delà du simple partage de données : optimisation du design, analyse des données produit, renforcement de la réutilisation, alimentation optimisée des systèmes en aval (ERP, MES).
Cette dimension métier implique une conduite du changement particulièrement soignée. La formation des équipes, l’accompagnement des utilisateurs, la communication sur les bénéfices attendus sont autant de facteurs clés de succès. Un projet de convergence PLM qui négligerait cet aspect humain risquerait de se heurter à des résistances fortes, même si la solution technique est pertinente.
Enfin, le pilotage de ces projets doit être itératif et agile. Plutôt que de viser une bascule massive en « big bang », il est préférable de procéder par étapes, de mesurer les résultats, d’ajuster la trajectoire. Cette approche permet de limiter les risques et de maintenir le sponsorship de la direction sur la durée.
Aucune stratégie universelle n’est donc à privilégier face à la coexistence de plusieurs PLM. La convergence progressive est pertinente lorsque le partage d’information entre programmes est critique et que les processus peuvent être standardisés. L’intégration sans fusion convient, elle, aux situations où la diversité métier justifie le maintien d’outils distincts, tout en garantissant l’interopérabilité nécessaire. La coexistence organisée peut enfin être un choix rationnel lorsque les périmètres sont clairement séparés et les surcoûts maîtrisables.
L’essentiel, c’est de passer d’une situation subie à une décision éclairée et assumée. Qualifier précisément votre contexte, mesurer les impacts réels, analyser les gains attendus de chaque stratégie, et arbitrer en fonction de vos priorités industrielles et de votre capacité d’investissement.
Des questions ? Nos expert.e.s sont là pour vous répondre !
Jean-Baptiste DIDIOT
Senior Partner
Olivia MARTIN
Partner
Adrien ROSSI
Senior Manager
Ludovic DODE
Senior Manager
