« Le PLM est mort » — je l’entends sans cesse. Vrai, peut-être. Et pas vrai non plus. Tout dépend de ce qu’on entend par PLM. Sous un certain angle, l’affirmation peut avoir du sens. Pas sous le mien, cela dit. Car je pense que le PLM est plus vivant que jamais. Et j’explique volontiers pourquoi.
Logiciel PLM ou discipline PLM ? La différence décisive
Commençons par la question de ce que le PLM veut être, au fond.
Première lecture
Le PLM, ce sont les grandes suites — Teamcenter, Windchill, ENOVIA. Des systèmes monolithiques qui promettent de couvrir tout le cycle de vie du produit. Spoiler : pour cette lecture, la phrase « le PLM est mort » a — peut-être — sa légitimité. Pas forcément, mais c’est défendable.
Deuxième lecture
Le PLM, c’est la discipline qui englobe tout ce qui relève du cycle de vie produit. Gestion de configuration, gestion des modifications, traçabilité, intégration des systèmes sur tout le cycle de vie. Pour cette lecture, le PLM est tout sauf en train de mourir. Il ne fait que devenir enfin ce qu’il a toujours voulu être.
Ma vision du PLM a toujours été la deuxième lecture. Pour moi, elle décrit ce que le PLM signifie réellement — et pour qui cela paraît trop personnel : Gartner définit le PLM comme “philosophy, process and discipline supported by software”. La discipline d’abord, le logiciel comme outil. Pourtant, beaucoup considèrent encore le PLM comme une catégorie de produits pour les suites dans le contexte de l’ingénierie.
Ce qui meurt : les suites PLM monolithiques
Que ces suites PLM connues, souvent monolithiques, restent le modèle dominant, c’est aujourd’hui plus incertain que jamais. Car la direction que prend la trajectoire est claire, même si le processus est lent. Trois réflexions à ce sujet :
Premièrement : la conviction qu’un seul système puisse tout couvrir n’est, dans bien des cas, pas tenable. Les éditeurs PLM historiques ont grandi par rachats, pas (seulement) par innovation architecturale. Le résultat, comme le décrit l’analyste PLM Oleg Shilovitsky (qui vend lui-même, il est vrai, une approche PLM décentralisée), ce sont des “conglomérats d’outils, maintenus ensemble par des intégrations — parfois avec des modèles de données incompatibles”. Qui en a fait l’expérience douloureuse acquiesce. Qui ne l’a pas encore faite l’apprendra.
Deuxièmement : le pendule make-or-buy bascule vers le make — et l’IA accélère ce mouvement. Pas parce que les développeurs codent dix fois plus vite. Mais parce que des domaines PLM périphériques bien délimités — plateformes de release, workflows de gestion des modifications, solutions de traçabilité spécifiques — deviennent soudain réalistement développables en interne. Ce qui échouait autrefois à cause de l’effort et du risque de maintenance se fait aujourd’hui avec des équipes bien plus réduites. Cela ne vaut peut-être pas (encore) pour une architecture PLM complète. Mais pour les endroits où les solutions monolithiques sont surdimensionnées tout en générant des coûts de licence annuels, le calcul évolue.
Retour en arrière sur un projet auquel j’ai moi-même participé il y a quelques années : un client voulait construire sa propre plateforme de release logicielle. Tout en développement interne. J’étais sceptique à l’époque, et j’avais recommandé de vérifier quelles solutions existaient déjà sur le marché. Le codage assisté par l’IA, qui rend aujourd’hui ce genre de projet bien plus abordable, n’existait pas encore. Le client s’était décidé, et vu sa taille, c’était faisable, quoique coûteux, de ne pas prendre de solution standard. Peut-être même trop coûteux. Avance rapide : avec les possibilités d’aujourd’hui, mon avis serait très probablement différent, ce qui ne veut pas dire que je rejetterais le « standard » aujourd’hui. Mais les tendances changent.
Troisièmement : le PLM comme simple archive documentaire, c’était avant — les attentes ont toujours été plus grandes. Que le PLM doive être plus qu’une archive documentaire glorifiée, c’est aujourd’hui un consensus. Mais ce consensus est loin d’être opérationnalisé, et dans la réalité opérationnelle, les actes restent en retard sur cette prise de conscience. Pourtant, ce qu’un PLM moderne devrait vraiment fournir ne semble pas si surhumain : un modèle de données produit structuré, qui représente de façon exploitable par machine les pièces, les variantes, les dépendances et les historiques de modification. Une traçabilité continue, de l’exigence au code et à la CAO jusqu’au produit fini sur le terrain. L’intégration de tous les processus pertinents, de A comme après-vente à Z comme archive de plans.
Seulement : un outil qui convient à tout ne convient vraiment à personne. C’est vrai pour les couteaux suisses, et c’est vrai pour les suites PLM monolithiques. Le modèle de données est générique, parce qu’il doit l’être. L’intégration totale n’existe pas, parce qu’il y a toujours, dans l’entreprise, d’autres mondes de systèmes (mot-clé : ERP). Et : qui veut vraiment construire un modèle de données produit profond et spécifique à son domaine — un modèle qui représente avec précision ses propres pièces, variantes et processus — se heurte, dans le monolithe, à des efforts d’adaptation susceptibles d’engloutir toute la valeur ajoutée. Des outils spécialisés aux standards ouverts contournent au moins partiellement ce problème, car ils sont conçus dès le départ pour l’interopérabilité, pas pour l’exhaustivité.
Ce qui ne meurt pas : le PLM comme discipline — car le besoin augmente
Fait : les produits deviennent plus complexes. Les frontières entre mécanique, électronique et logiciel s’estompent.
Exemple automobile : selon les estimations, les constructeurs perdent entre 500 millions et un milliard de dollars par an à cause de rappels physiques qui seraient techniquement possibles par une mise à jour OTA (eSync Alliance, 2023 ; ABI Research, 2023). Que les mises à jour OTA ne soient toujours pas généralisées là où elles seraient techniquement possibles tient aussi à la complexité des produits. Une voiture n’est plus une machine simple comme avant, qu’on peut, au pire, réparer dans n’importe quel garage perdu. Pour qu’une mise à jour OTA fonctionne — et je parle d’expérience — il faut une mécanique bien huilée, qui garde une vue d’ensemble sur tous les produits sur le terrain, leur configuration, leur version logicielle et toutes les dépendances.
D’où : gestion de configuration, gestion des modifications, traçabilité sur tout le cycle de vie… le besoin de professionnaliser ces disciplines ne diminue en rien. Au contraire, il devient plus exigeant.
Bien sûr, je comprends celui qui dit « le PLM est mort » après un projet PLM qui a capoté et n’a pas tenu ses promesses. Seulement, cette personne a peut-être confondu le symptôme avec la maladie. L’outil a trébuché, mais la discipline, la cohérence de bout en bout et l’état d’esprit qui va avec n’ont peut-être jamais été vraiment vécus — ni vraiment compris.
Une phrase attribuée au vétéran du PLM Rob Ferrone en dit plus que dix jeux de slides : « Pendant mes cinq premières années, je ne savais même pas que nous faisions du PDM ou du PLM — mais nous le faisions. ». Si l’inverse est vrai aussi, si des entreprises achètent le logiciel mais n’implémentent jamais la discipline, alors la frustration est compréhensible — mais elle vise la façon dont le PLM a été introduit, pas la discipline elle-même.
Seules 13 % pensent ne pas pouvoir travailler sans PLM
Un chiffre à ce sujet qui fait réfléchir : seules 13 % des entreprises qui utilisent le PLM disent qu’elles ne pourraient pas travailler sans lui. Que ce soit 10, 13 ou 20 %, peu importe. Le vrai message tient dans la réciproque : la plupart des entreprises croient pouvoir se passer du PLM. Non. Elles ne peuvent pas. Toute entreprise qui développe et fabrique des produits pratique le PLM — sous une forme ou une autre. La seule question est de savoir si elle comprend ce qu’elle fait…
Le vrai défi : l’architecture manquante et une organisation insuffisante
Le Digital Thread — la trace de données bidirectionnelle et continue, de l’exigence jusqu’à l’exploitation — est la vision qui a toujours été étroitement liée à la notion de PLM. « Single Source of Truth », traçabilité de l’exigence jusqu’au terrain : les éditeurs le promettent déjà depuis les années 2000. Trop souvent, cette promesse n’a hélas pas été tenue, pour des raisons très diverses :
Car ce qui fait échouer, c’est étonnamment rarement le logiciel. C’est ce qui manque autour du logiciel : des structures d’information et de données. Des ontologies. Une organisation prête à vraiment s’attaquer à ses processus. Bref : de l’architecture. Et celle-ci ne naît pas d’elle-même — qu’on achète ou qu’on construise.
Qui achète achète une maison préfabriquée. Et qui achète une maison préfabriquée doit accepter des plans déjà fixés. Même si cela veut dire abandonner des habitudes chères et s’adapter à de nouveaux modes de travail. Cela ne se fait évidemment pas tout seul. C’est un travail. Et c’est précisément ce travail qu’on préfère éviter — les processus existants sont souvent une sorte de graal, et le succès passé semble parfois le confirmer. Seulement : qui tord quand même le logiciel standard plutôt que de s’adapter s’inflige des efforts d’adaptation susceptibles d’engloutir toute la valeur ajoutée. L’échec n’est alors pas un problème logiciel. C’est un problème de devoirs non faits.
Qui construit n’a pas le problème des plans — mais un autre. Des outils PLM à qui il manque encore telle ou telle fonctionnalité souhaitée, plus la nouvelle disponibilité du développement logiciel assisté par l’IA : cela incite vite à vouloir construire quelque chose en propre. Que ce soit entièrement « from scratch », ou sous forme d’un assemblage très sur mesure de divers outils. C’est possible, voir plus haut — le calcul a effectivement évolué. Mais : la mise en place d’un Digital Thread de bout en bout a d’autant plus besoin d’une architecture. Qui construit sans réfléchir se retrouve avec un paysage d’outils qui fonctionne plus ou moins au début, devient vite difficile à maintenir — et finit par lui exploser à la figure un jour. Bonjour l’informatique bricolée sous Excel.
Donc : investir dans l’organisation et l’architecture de l’information n’est pas une option, c’est le ticket d’entrée. Sur les deux voies. Qui l’a compris — et seulement celui-là — voit l’option make devenir intéressante : car si le travail d’architecture est de toute façon nécessaire, l’avance du monolithe est plus faible que son étiquette de prix ne le suggère. Une approche décentralisée, loin des suites établies, vaut alors aujourd’hui plus que jamais la réflexion. Cela pourrait en valoir la peine.
Mais revenons à la question de départ. Le PLM est-il mort ?
❤️ Le PLM est vivant
Si l’on entend par PLM la discipline (et j’y tiens), alors la réponse est claire : le PLM est plus vivant que jamais. Les exigences ne diminuent pas. Les produits ne deviennent pas plus simples. Et le coût de négliger cette discipline, lui, augmente.
Les grands monolithes PLM vont-ils rendre l’âme ? Je ne sais pas, et je me garde de toute prophétie. Les arguments qui vont dans ce sens sont au moins plausibles. Mais les éditeurs PLM ne sont pas naïfs non plus — eux aussi voient les changements que nous voyons tous. Architectures plus ouvertes, offres plus modulaires, SaaS — cela arrive déjà, plus chez certains éditeurs que chez d’autres. C’est le marché qui décidera si cela prend.
Long live PLM 😉🖖
Questions fréquentes
Le PLM est-il mort ou non ?
Cela dépend de la lecture. En tant que suite monolithique (Teamcenter, Windchill, ENOVIA), l’affirmation mérite au moins d’être discutée. En tant que discipline — gestion de configuration, gestion des modifications, traçabilité, etc. — elle est simplement fausse. Cette discipline devient plus importante, pas superflue.
Quelle est la différence entre le logiciel PLM et le PLM comme discipline ?
Le logiciel est l’outil, la discipline en est la finalité. Gartner définit le PLM comme “philosophy, process and discipline supported by software” — la discipline d’abord, l’outil ensuite. Un projet PLM qui échoue ne veut donc pas dire que la discipline a échoué, mais souvent seulement qu’elle n’a jamais été vraiment vécue.
Vaut-il mieux aujourd’hui développer son PLM en interne (make) que d’acheter une suite PLM (buy) ?
Le calcul évolue, car le développement assisté par l’IA rend réalistement constructibles en interne des domaines PLM périphériques bien délimités. Pour une architecture PLM complète, ce n’est généralement pas (encore) le cas. Et le make non plus n’épargne pas le travail d’architecture : qui construit sans réfléchir se retrouve avec un paysage d’outils qui devient vite impossible à maintenir.
Qu’est-ce que le Digital Thread, et pourquoi est-il important ?
La trace de données bidirectionnelle et continue, de l’exigence jusqu’au terrain, en passant par la CAO et le code — la vision que le PLM promet depuis les années 2000. Elle n’est souvent pas tenue parce que l’architecture derrière fait défaut, pas parce que le logiciel en serait incapable.
