.png)
Choisir un éditeur PLM revient à juger deux choses qu'on a tendance à confondre : ce que le logiciel sait faire, et la capacité de l'éditeur à le rendre réellement opérationnel chez vous. La plupart des processus de sélection s'attardent sur la première et négligent la seconde. C'est pour cette raison que tant de projets PLM passent l'évaluation fonctionnelle sans jamais être adoptés.
Ce guide présente les critères qui comptent sur ces deux plans, les questions qui font ressortir les vraies réponses, et une méthode pour construire votre propre grille d'évaluation.
📌 En bref
Les éditeurs se feront un plaisir de structurer votre évaluation à votre place, et cette structure avantagera la plateforme qu'ils vendent. Poser vos propres critères en amont, c'est ce qui vous permet de garder la main.
Identifiez les deux ou trois résultats que le PLM doit produire. Raccourcir les cycles de modification, supprimer les conflits de versions, être prêt pour un audit, obtenir une certification que vous n'avez pas encore. Des objectifs concrets déterminent quels critères pèsent, et un éditeur excellent sur des critères qui ne servent pas vos objectifs n'est pas le bon choix, aussi bonne soit la démonstration.
Un produit à niveau unique avec des configurations stables n'appelle pas la même plateforme qu'un produit de plusieurs centaines de composants, avec des variantes multiples et des modifications hebdomadaires. Surdimensionner coûte aussi cher que sous-dimensionner : vous payez une profondeur que vous n'utiliserez jamais et vous imposez à vos équipes une complexité qu'elles contourneront.
Listez les outils CAO qu'utilisent vos ingénieurs, l'ERP que vous exploitez, et tout MES ou SMQ en place. Cela ne détermine pas votre choix, les plateformes modernes s'intégrant largement, mais cela vous dit où le travail d'intégration sera nécessaire et ce qu'il coûtera en temps et en budget.
Un point souvent négligé au démarrage d'un projet PLM, et qui peut décider du modèle de déploiement à votre place. Si vous disposez d'une équipe informatique capable de prendre en charge le déploiement puis le support, l'on-premise vous est techniquement ouvert. Si vos ressources sont limitées, le cloud est la meilleure réponse : il ne demande presque rien à vos équipes au-delà du projet lui-même. Avoir les ressources pour l'on-premise ne veut pas dire que c'est le bon choix, seulement qu'il vous est accessible.
Une plateforme qui convient à 20 utilisateurs et votre site unique doit pouvoir en absorber 200 sur trois sites sans projet de migration. Demandez-vous où vous serez dans trois ans et évaluez à cette aune, pas seulement à celle d'aujourd'hui.
Le bureau d'études, les méthodes, la qualité, la production, les achats et l'informatique touchent tous aux données produit. Une sélection menée par la seule ingénierie produit une plateforme qui plaît à l'ingénierie et que personne d'autre n'utilise. Associez les fonctions qui vivront avec la décision.
Établissez le périmètre dont vous avez réellement besoin avant de comparer quoi que ce soit. La gestion des données techniques et la gestion documentaire constituent le socle. Au-delà, décidez si vous avez besoin de gestion de la qualité, de suivi de projet et de jalons produit, ou de gouvernance des instructions de fabrication. Tout ce qui sort de cette liste relève du confort, pas du besoin.
Le socle sur lequel tout le reste repose. Vérifiez quels types de données la plateforme gère nativement, si elle relie produits, articles et documents entre eux, et comment fonctionne la gestion des versions sur l'ensemble.
La visualisation compte plus qu'on ne le croit. Si vos équipes ont besoin d'une licence CAO pour consulter un plan, l'adoption restera cantonnée au bureau d'études, et le PLM ne deviendra jamais le référentiel unique qu'il est censé être.
Nomenclature d'ingénierie et nomenclature de fabrication comme structures distinctes mais liées, pas comme deux exports de la même liste. Vérifiez que vous pouvez comparer des versions, retrouver une pièce dans une nomenclature, et mesurer l'impact d'une modification sur toutes les nomenclatures qui utilisent un composant.
Pour un industriel qui gère des variantes, c'est le critère le plus lourd. Cherchez des nomenclatures configurables pilotées par des règles d'options plutôt qu'une nomenclature maintenue à la main par variante, et des dossiers « tel que construit » qui permettent de savoir, des années plus tard, ce qui a réellement été livré.
La maîtrise des modifications entre ici aussi. Des circuits ECR/ECO avec analyse d'impact font qu'une modification proposée identifie tout ce qu'elle affecte avant validation, et non après diffusion.
Comment les processus sont représentés dans la plateforme, quelle traçabilité ils produisent, et qui en est responsable. La vraie question, celle qui distingue les plateformes, est de savoir si vous pouvez créer et modifier vos circuits vous-même, ou si vous devez vous adapter à des modèles préétablis et passer par l'éditeur à chaque changement.
Cherchez des connecteurs natifs maintenus par l'éditeur pour chaque outil CAO que vous utilisez, et un support multi-CAO si vous en utilisez plusieurs ou comptez le faire. Les plateformes pour grands comptes ne se connectent en général qu'à la CAO de leur propre écosystème : tout le reste devient un contournement, sans garantie sur la qualité de la synchronisation. Des connecteurs prêts à l'emploi vous font gagner du temps et de l'argent au déploiement.
Posez aussi la question des grands assemblages : sont-ils pris en charge, et combien de temps faut-il pour en ouvrir un ? Les performances se dégradent d'une façon qui n'apparaît qu'à l'échelle, c'est-à-dire une fois que vous vous êtes engagé.
Même question que pour la CAO : le connecteur existe-t-il déjà, ou faut-il le développer ? Dans les deux cas, établissez qui le maintient, ce qui se passe lors des montées de version, et si la synchronisation fonctionne dans un sens ou dans les deux.
Aletiq s'intègre nativement aux principaux ERP, dont SAP, Oracle, Infor, Sage, Cegid, Divalto, Odoo, Dynamics 365 et Helios, avec des connecteurs construits et maintenus en interne plutôt que par des partenaires. Pour approfondir le fonctionnement d'une intégration PLM ERP, consultez notre guide dédié.
Souvent la partie la plus douloureuse d'un projet PLM côté client. Pendant l'évaluation, établissez la stratégie avec chaque éditeur : qui prépare les données, qui exécute le chargement, et de quel outillage il dispose pour cela.
Chez Aletiq, environ 90 % de nos clients arrivent avec des données à reprendre avant de pouvoir migrer. Nous les accompagnons sur la préparation, puis nous prenons en charge la migration. Nos outils développés en interne font correspondre les champs automatiquement et déplacent de gros volumes en une nuit.
Vérifiez si vous pouvez ajuster vous-même le modèle de données, les circuits, les champs et les droits d'accès, ou si chaque changement passe par un ticket de support et un devis.
Un PLM utilisé par la seule ingénierie n'est qu'un coffre-fort à fichiers CAO. Évaluez si une personne qui n'a jamais ouvert un outil de CAO peut y trouver ce dont elle a besoin, qui assure la formation et sous quelle forme, et demandez à chaque éditeur son taux d'adoption moyen chez ses clients.
Posez cette question même si vous vous attendez à une réponse vague. Un éditeur qui suit l'adoption la considère comme faisant partie de son travail. Un éditeur qui ne l'a jamais mesurée vous annonce que ce sera votre problème après le go-live.
Deux faces d'une même pièce : la sécurité de l'outil lui-même, et sa capacité à vous aider à rester conforme.
Côté sécurité, demandez des éléments précis plutôt que des assurances. Droits par rôle, chiffrement au repos et en transit, journaux d'audit, localisation des données, et quelles certifications l'éditeur détient. L'ISO 27001 est le minimum.
Côté conformité, demandez ce qui s'applique à votre secteur et comment la plateforme le soutient, qu'il s'agisse de l'AS9100 et de l'EN 9100 en aéronautique, des exigences FDA pour les dispositifs médicaux, ou de l'ISO 9001 plus largement. La question utile est ce que la plateforme produit le jour d'un audit, pas si l'éditeur se déclare conforme.
Un SaaS cloud-native se déploie en quelques semaines, sans infrastructure et avec des mises à jour automatiques. Les plateformes hébergées tournent sur des serveurs cloud mais conservent la charge de maintenance de leurs origines on-premise. L'on-premise offre un contrôle maximal, au prix de ressources informatiques et de délais plus longs.
Pour la plupart des PME et ETI industrielles, le cloud est la réponse pratique. Notre comparatif des PLM cloud détaille la distinction.
Un éditeur qui compte des références en aéronautique comprend les exigences de traçabilité AS9100. Un éditeur qui n'en a pas apprendra sur votre projet. Demandez des clients de votre secteur, à une échelle comparable, avec les mêmes obligations réglementaires.
L'échelle compte autant que le secteur. Un éditeur dont toutes les références sont des groupes de 2 000 personnes n'a pas résolu la question du déploiement en PME, et l'inverse est tout aussi vrai.
Un PLM peut être déployé directement par l'éditeur ou via un intégrateur. Le déploiement direct est préférable dans la plupart des cas : les personnes qui paramètrent la plateforme sont celles qui l'ont conçue. Si quelque chose doit être ajusté ou corrigé, aucun intermédiaire ne s'interpose.
Les intégrateurs peuvent être pratiques, et parfois moins chers, quand l'éditeur n'a pas d'équipe dans votre pays. La contrepartie est le délai de réaction. Quand un problème survient, l'intégrateur ne peut souvent pas le traiter seul et doit repasser par l'éditeur, ce qui transforme une correction rapide en attente longue.
Demandez ce que couvre le support à votre niveau d'abonnement, quels délais de réponse sont engagés, si vous disposez d'un interlocuteur nommé, et ce qui sort du contrat et se facture.
La question utile n'est pas de savoir si un support existe, mais ce qui se passe une fois l'onboarding terminé et les personnes qui ont mené le projet parties ailleurs.
À titre de repère, le score de satisfaction client d'Aletiq est de 95,7 %. Demandez le sien à chaque éditeur.
Vous achetez autant l'avenir d'une plateforme que son présent. Demandez à quelle fréquence elle évolue, comment les demandes clients rejoignent la feuille de route, et si des développements sont parfois réalisés sans surcoût.
La solidité de l'éditeur compte aussi. Changements d'actionnariat, rachats et évolutions de financement pèsent tous sur l'indépendance de la feuille de route, et le marché du PLM en a connu plusieurs ces dernières années.
Le prix d'achat en est la plus petite composante. Le coût total sur trois à cinq ans comprend les licences ou l'abonnement, les services de déploiement, la migration, le développement des intégrations, la formation, le support continu et le temps interne mobilisé, qui est la ligne la plus souvent oubliée et souvent la plus lourde.
Demandez à chaque éditeur présélectionné une estimation sur trois ans couvrant l'ensemble. L'écart entre éditeurs sur le coût total est généralement plus large que sur le prix des licences, et il joue en sens inverse : les plateformes affichant les tarifs les plus bas portent souvent les coûts de déploiement et de maintenance les plus élevés. Notre guide sur le ROI d'un PLM explique comment le modéliser.
Au-delà de ce que la plateforme permet, regardez ce que l'éditeur a déjà fait. Demandez des migrations de volume et de complexité comparables aux vôtres, quels outils ont été utilisés, et combien de travail est resté à la charge du client.
Un éditeur qui migre régulièrement des volumes comme le vôtre a rencontré les difficultés avant vous. Un éditeur pour qui ce serait une première les découvrira sur votre projet.
Posez les mêmes questions à tous les éditeurs présélectionnés et comparez les réponses côte à côte.
Cette dernière question est inconfortable à poser, et très instructive à entendre traiter.
Une notation pondérée rend la décision défendable et évite que la dernière démonstration vue ne pèse plus que les autres. Ce qu'elle ne peut pas être, c'est universelle. Un industriel avec 500 variantes produit et un seul outil CAO ne pondère pas les mêmes critères qu'un industriel avec trois outils CAO et un catalogue stable.
Construisez donc la vôtre. En quatre étapes.
Revenez aux deux ou trois résultats que vous avez définis avant de commencer à comparer. Cycles de modification plus courts, préparation aux audits, fin des conflits de versions. Passez ensuite les critères en revue et demandez-vous lesquels servent réellement ces objectifs.
Les critères qui servent un objectif reçoivent du poids. Ceux qui n'en servent aucun en reçoivent peu, ou pas du tout. Une gestion des configurations exceptionnelle ne vaut pas d'être payée si vous fabriquez un seul produit.
Certains critères ne se notent pas de 1 à 5 : ils passent ou ils ne passent pas. Si vous travaillez sous CATIA et qu'une plateforme n'a pas de connecteur CATIA, aucune note sur les autres dimensions ne la rattrape. Il en va de même pour une certification que vous devez détenir ou une contrainte de localisation des données incontournable.
Identifiez-les en premier et servez-vous-en pour présélectionner. Ne notez ensuite que ce qui reste, sur les critères où les éditeurs se distinguent réellement.
La bonne question, pour chaque critère, n'est pas de savoir s'il paraît important, mais ce qui se passe si vous vous trompez dessus.
Une intégration CAO faible pousse les ingénieurs à contourner la plateforme, ce qui vous coûte le projet. Un manque de visibilité sur la feuille de route vous vaudra une conversation inconfortable en troisième année. Les deux comptent, mais pas également, et c'est cet écart que vos pondérations doivent refléter.
C'est aussi pourquoi les critères de déploiement et d'adoption méritent plus de poids qu'on ne leur en donne habituellement. Une plateforme que personne n'utilise obtient zéro partout, quoi qu'en dise l'évaluation fonctionnelle.
Si vous définissez les pondérations après les démonstrations, elles dérivent vers celui qui a le mieux présenté. Arrêtez-les tant que la discussion reste abstraite, écrivez-les, et n'y revenez pas en cours d'évaluation.
Notez ensuite chacun de votre côté avant d'en discuter, pour que la voix la plus forte dans la salle ne fixe pas le point d'ancrage de tout le monde.
Le meilleur éditeur PLM est celui qui correspond à vos processus, s'intègre à vos outils existants, et dispose d'équipes qui ont déjà déployé dans votre secteur. C'est rarement celui dont la liste de fonctionnalités est la plus longue.
Définissez vos critères avant que les éditeurs ne les définissent pour vous, pondérez le risque de déploiement aussi lourdement que les capacités de la solution, comparez le coût total plutôt que le prix des licences, et parlez à des références qui exploitent votre ERP dans votre secteur. Une évaluation structurée prend plus de temps au départ et retire l'essentiel du risque de tout ce qui suit.
Demandez une démo pour voir comment Aletiq se situe sur ces critères, avec une démonstration construite autour de votre cas d'usage plutôt qu'une présentation générique.
Pour une comparaison de plateformes précises, consultez notre guide des meilleurs logiciels PLM pour l'industrie.
La couverture fonctionnelle, la profondeur d'intégration CAO et ERP, la configurabilité, l'ergonomie pour les équipes non techniques, l'expertise sectorielle, le pilotage du déploiement et le coût total de possession. L'intégration et le pilotage du déploiement sont les deux critères qui déterminent le plus souvent la réussite d'un projet, et les deux sont couramment sous-pondérés.
Définissez d'abord vos objectifs métier et vos critères, puis notez chaque éditeur présélectionné sur des critères pondérés plutôt que de comparer des listes de fonctionnalités. Posez les mêmes questions à tous, demandez des références dans votre secteur et à votre échelle, et comparez le coût total sur trois ans plutôt que le prix des licences.
Trois à cinq pour une évaluation détaillée, incluant démonstrations, ateliers et entretiens avec des références. Moins ne vous donne aucune base de comparaison réelle. Plus, et le processus s'enlise avant qu'une décision ne soit prise.
Un éditeur qui a déployé dans votre secteur, à votre échelle, avec des données comparables aux vôtres sait où les projets dérapent et dispose d'une méthode pour l'éviter. Un éditeur qui ne l'a pas fait apprendra sur votre projet, à vos frais. Demandez qui pilote le déploiement, ce que l'éditeur prend en charge, et ce qui incombe à vos équipes.
Oui, et plus précisément la question de savoir si la plateforme est réellement cloud-native ou une version hébergée d'un système on-premise. Les deux diffèrent sensiblement en délai de déploiement, en charge de maintenance et en coût total. Les plateformes cloud-native se déploient en semaines, les plateformes hébergées pour grands comptes en plusieurs mois.
Il couvre les licences ou l'abonnement, les services de déploiement, la migration des données, le développement des intégrations, la formation, le support continu et le temps interne mobilisé, sur trois à cinq ans. Le temps interne est la composante la plus souvent oubliée et souvent la plus lourde. Demandez à chaque éditeur une estimation complète plutôt qu'un montant d'abonnement annuel.