.png)
Le délai dépend d'abord du type de solution retenue : on-premise ou cloud.
Un PLM on-premise se déploie généralement en 12 à 24 mois. Un PLM cloud-native, sur un premier périmètre, se déploie en 8 à 12 semaines. Les deux chiffres sont réels, et l'écart entre eux en dit plus long sur le modèle de déploiement que sur la taille de l'entreprise.
Voici le calendrier phase par phase, ce qui explique l'écart, et les six raisons pour lesquelles un projet dépasse ce qui avait été prévu.
📌 En bref
- Un PLM on-premise se déploie en 12 à 24 mois. Un PLM cloud-native en 8 à 12 semaines.
- La préparation des données est la phase la plus longue dans les deux cas, et elle incombe au client.
- Environ 90 % des industriels doivent corriger des problèmes de qualité de données avant de migrer.
- Le cloud raccourcit le calendrier : le paramétrage remplace le développement et les phases se chevauchent.
- Le périmètre et la qualité des données pèsent bien plus lourd que la taille de l'entreprise.
Les phases d'un déploiement PLM et leur durée
Tout projet PLM passe par les mêmes 8 phases, quelle que soit la plateforme. Ce qui change, c'est la durée de chacune et ce qui peut être mené en parallèle.
Le détail de chaque phase de déploiement
Cadrage
L'équipe de l'éditeur cherche à comprendre le métier du client et examine ses données. Ensemble, l'éditeur et le client s'alignent sur les résultats attendus, identifient les équipes concernées et arrêtent le calendrier de déploiement.
Cartographie des processus et conception
Cartographier les pratiques actuelles du bureau d'études, de la production et de la qualité, puis décider de la façon dont elles doivent se dérouler dans le PLM. C'est ici que vous identifiez quels processus deviennent des circuits, lesquels doivent être optimisés avant d'être figés dans l'outil, et comment la standardisation sera traitée entre les sites. La définition du modèle de données cible fait également partie de cette phase.
Préparation des données
Généralement la phase la plus longue dans les deux modèles. Auditer l'existant, supprimer les doublons, harmoniser la codification, compléter les champs manquants et faire correspondre l'ensemble au modèle cible.
Ce travail revient au client, puisque personne d'autre ne peut décider laquelle de deux références en double est la bonne, mais les éditeurs modernes l'accompagnent. La durée dépend de l'état des données et de leur volume, pas de la plateforme, et c'est pourquoi cette phase est celle qui se comprime le moins.
Migration des données
Une migration de test d'abord, puis le chargement complet, qui peut être mené progressivement par type de donnée. L'éditeur s'en charge une fois les données suffisamment propres pour être déplacées.
La durée dépend surtout du volume. Ne migrer que les données actives et courantes, plutôt que tout l'historique, est généralement ce qui permet de tenir l'estimation. Notre guide sur la migration de données PLM détaille le processus.
Paramétrage
Cycles de vie, statuts de révision, structures de nomenclature, circuits de demande de modification, règles de validation, rôles et droits. L'éditeur s'en charge, à partir de ce que les phases précédentes ont arrêté.
La durée dépend presque entièrement du niveau de personnalisation. Un paramétrage depuis l'interface prend quelques jours. Un développement sur mesure prend des mois, et il faudra ensuite le maintenir.
Intégration
Connecter la CAO, l'ERP, et le cas échéant le MES et le SMQ. Les connecteurs natifs maintenus par l'éditeur se paramètrent. Tout le reste se construit.
À ce stade, l'éditeur sait quel outil fait référence pour quelle donnée, si chaque liaison fonctionne dans un sens ou dans les deux, et ce qui doit réellement être synchronisé. Pour approfondir le fonctionnement d'une intégration PLM ERP, consultez notre guide dédié.
Tests et formation
Les tests se déroulent généralement avec l'équipe projet, sur le périmètre le plus critique. C'est là que l'éditeur ajuste le paramétrage pour coller à la façon dont les gens travaillent vraiment. La formation peut être menée en parallèle, et elle porte mieux ses fruits par métier qu'en une session commune.
Chez Aletiq, nous sommes convaincus que l'adoption se joue sur la formation. C'est pourquoi nous continuons à programmer des sessions après le go-live dès qu'une équipe le demande, plutôt que de traiter la formation comme une phase qui se referme.
Go-live et stabilisation
Mise en production, support pendant les premières semaines, traitement de ce qui remonte, suivi des utilisateurs qui se servent réellement de l'outil.
Le go-live est une phase, pas une date. Les deux premières semaines font apparaître des questions qu'aucune campagne de tests ne fait remonter à l'avance.
Pourquoi un PLM cloud se déploie plus vite qu'un on-premise
L'écart tient à cinq différences de conception entre les deux modèles.
Il n'y a pas d'infrastructure à monter. Un projet on-premise commence par des serveurs, des environnements et la mobilisation de vos équipes informatiques, avant même que quiconque ne touche aux données produit. Un projet cloud saute tout cela et démarre directement à la première phase du tableau.
Le paramétrage remplace le développement. Les plateformes on-premise sont paramétrées par des spécialistes, souvent à coups de développements sur mesure. Les plateformes cloud-native se paramètrent depuis l'interface. C'est la différence entre une phase de 16 semaines et une phase de deux, et l'écart se creuse encore parce que chaque développement doit ensuite être testé.
Les intégrations sont des connecteurs. Quand un connecteur natif existe, l'intégration se paramètre au lieu de se construire, ce qui permet de la mener en parallèle du paramétrage plutôt qu'à sa suite.
La migration est outillée. Les plateformes cloud-native comme Aletiq disposent d'outils de migration internes qui font correspondre les champs automatiquement et déplacent de gros volumes en une nuit, là où le chargement manuel prend des semaines.
Les montées de version cessent d'être des projets. En on-premise, chaque version est un chantier en soi et mobilise vos équipes informatiques. Les mises à jour cloud se font sans aucune intervention du client, ce qui retire du calendrier un travail qui s'y trouverait sinon.
Les 6 raisons pour lesquelles un projet PLM prend du retard
1. Une qualité de données découverte trop tard
De loin la cause la plus fréquente. Chez Aletiq, environ 90 % des clients arrivent avec des données à reprendre avant de pouvoir migrer : doublons, codification incohérente, champs non renseignés, liens rompus entre articles.
L'essentiel est visible au quotidien sans jamais devenir assez urgent pour être corrigé, alors les équipes font avec. Cela ne devient un problème qu'au moment de la préparation des données, quand le nouveau système cesse de tolérer ce que l'ancien acceptait. Auditer ses données dès le cadrage, plutôt que de les supposer correctes, est le geste le plus efficace pour tenir un calendrier.
2. Un outil trop rigide
Un PLM peut sembler adapté sur le papier et se révéler trop lourd pour la façon dont vos équipes travaillent réellement. Les plateformes traditionnelles en particulier ont été conçues pour de grandes organisations disposant de spécialistes PLM, pas pour des utilisateurs qui n'ont jamais manipulé ce type d'outil.
Le retard apparaît au paramétrage. Quand la plateforme ne peut pas s'adapter à vos circuits ou à votre modèle de données, chaque écart devient une demande de développement, et le développement est précisément la phase qui transforme des semaines en mois.
Demandez une démonstration construite autour de votre propre cas d'usage, pas des vidéos produit qui présentent des fonctionnalités isolées. Une démonstration sur votre structure produit vous dit si la plateforme convient. Une vidéo vous dit qu'elle existe.
3. Un périmètre qui ne cesse de s'élargir
Le PLM touche toutes les fonctions, et les besoins continuent donc d'arriver. Sans préparation solide ni alignement entre les équipes au départ, des manques sont repérés tard et s'ajoutent à ce qui avait déjà été arrêté, et la date de go-live recule d'autant.
4. Les développements sur mesure
Chaque personnalisation allonge le paramétrage, allonge les tests et ajoute du risque à chaque montée de version. La plupart des demandes de personnalisation cherchent à reproduire un contournement hérité de l'ancien système plutôt qu'à répondre à un vrai besoin.
5. Des intégrations qui se révèlent être des chantiers
Un éditeur annonce qu'il s'intègre à votre ERP. Savoir si cela signifie un connecteur maintenu ou un projet de développement mérite une question directe, parce que la réponse fait la différence entre des semaines et des mois.
6. Des décisions que personne n'est habilité à prendre
Quel processus l'emporte, qui est responsable d'une référence article, ce qui est reporté. Ces arbitrages traversent les frontières des services, et sans quelqu'un habilité à trancher, ils partent en comité et y restent.
Pour un traitement plus complet de ce qui dérape et pourquoi, consultez notre guide sur les défis d'un déploiement PLM.
Peut-on accélérer un projet PLM ?
Oui, et surtout par des décisions prises avant le lancement plutôt que par des efforts consentis en cours de route.
Privilégiez le cloud à l'on-premise. Un projet cloud est plus léger à chaque phase : moins à paramétrer, moins de décisions à prendre, aucune infrastructure à monter. Au vu des durées ci-dessus, un PLM cloud se déploie six à douze fois plus vite qu'un équivalent on-premise.
Choisissez un éditeur souple. Certains éditeurs travaillent pour tenir votre échéance, d'autres vous annoncent la durée de leur processus. Les plateformes modernes comme Aletiq ont plus de marge pour resserrer un projet, notamment parce que le déploiement est assuré en interne plutôt que par un intégrateur, ce qui supprime une couche de coordination et les délais qui vont avec. Demandez directement à chaque éditeur s'il peut tenir votre date, et ce dont il aurait besoin de votre part pour y arriver.
Auditez vos données avant le cadrage, pas avant la migration. Connaître l'état de vos données vous permet de bâtir un calendrier réaliste et de décider ce qui entre dans chaque vague de déploiement. C'est l'action qui a le plus d'effet.
Restreignez volontairement la première vague. Un site, une ligne de produits ou un type de donnée, avec une seconde vague réellement programmée. Un déploiement progressif laisse aux équipes le temps de s'approprier l'outil et les nouveaux circuits, et vous permet de tester sur un périmètre plus large et d'ajuster avant de généraliser.
Vérifiez les intégrations existantes. Des connecteurs natifs maintenus par l'éditeur sont le meilleur choix, puisqu'il suffit de les paramétrer pour votre environnement. Des connecteurs à développer prennent des mois plutôt que des semaines, et leur coût s'ajoute au budget de déploiement.
Nommez un référent projet. Une personne qui garde le projet sur les rails, veille à ce que les décisions soient prises plutôt que reportées, et fait le lien entre vos équipes et l'éditeur.
Menez les phases en parallèle quand la plateforme le permet. L'intégration pendant le paramétrage, la formation pendant les tests. C'est de là que vient l'essentiel du gain de temps d'un déploiement cloud.
Pour ce que tout cela représente en budget, notre guide du déploiement PLM traite du coût en parallèle du processus.
Conclusion
Il n'existe pas de calendrier PLM universel, mais il existe un schéma constant. Les déploiements on-premise s'étalent sur 12 à 24 mois parce que le paramétrage y est un projet de développement et que les phases s'enchaînent. Les déploiements cloud-native tiennent en 8 à 12 semaines parce que le paramétrage se fait depuis l'interface et que l'intégration avance en parallèle.
Le point commun aux deux, c'est la préparation des données. C'est la phase la plus longue dans les deux cas, la seule que l'éditeur ne peut pas faire à votre place, et celle où la plupart des calendriers cèdent. Tout le reste se comprime avec la bonne plateforme et le bon périmètre.
D'où la conclusion utile : les variables qui décident de votre calendrier sont celles que vous arrêtez avant que quiconque ne commence à construire. Le modèle de déploiement, le périmètre du projet et l'état de vos données.
Prenez rendez-vous avec l'équipe Aletiq pour savoir à quoi ressemblerait un calendrier réaliste pour votre organisation.
FAQ
Combien de temps prend un déploiement PLM ?
Un déploiement on-premise s'étale généralement sur 12 à 24 mois pour une première vague. Un déploiement cloud-native tient en 8 à 12 semaines, migration des données et intégrations comprises. L'écart vient du paramétrage, qui se fait depuis l'interface plutôt que par développement, et de l'intégration qui avance en parallèle du paramétrage au lieu de lui succéder.
Quelle est la phase la plus longue d'un déploiement PLM ?
La préparation des données, dans les deux modèles. Elle prend 8 à 16 semaines sur un projet on-premise et 2 à 4 semaines sur un déploiement cloud. C'est la phase la moins influencée par le choix de la plateforme, puisque sa durée dépend de l'état de vos données existantes. C'est aussi la seule que l'éditeur ne peut pas faire à votre place.
Qu'est-ce qui retarde le plus souvent un projet PLM ?
Une qualité de données découverte au moment de la préparation plutôt qu'au cadrage, une plateforme trop rigide pour être paramétrée sans développement, un périmètre qui s'élargit, des intégrations qui se révèlent être des chantiers, et l'absence de référent projet désigné. La qualité des données reste de loin la cause la plus fréquente.
Peut-on déployer un PLM par étapes ?
Oui, et c'est généralement préférable. Une première vague restreinte à un site, une ligne de produits ou un processus réduit le risque, apporte de la valeur plus tôt, et génère les retours qui rendront la seconde vague meilleure. À condition que cette seconde vague soit réellement programmée et non reportée indéfiniment.
Comment raccourcir un déploiement PLM ?
Privilégier le cloud à l'on-premise, qui est le levier le plus puissant. Ensuite : auditer les données dès le cadrage, restreindre volontairement la première vague, accepter le paramétrage standard plutôt que le développement sur mesure, vérifier que les intégrations reposent sur des connecteurs maintenus, et nommer une personne habilitée à trancher.
La taille de l'entreprise détermine-t-elle la durée du déploiement ?
Moins qu'on ne le croit. Le périmètre, la qualité des données et le nombre d'intégrations pèsent bien plus lourd que l'effectif. Un industriel de 500 personnes qui déploie sur une ligne de produits avec des données propres ira plus vite qu'un industriel de 50 personnes qui déploie tout d'un coup sur des données que personne n'a auditées.
