.png)
Le 31 décembre 2027, Oracle met fin au Premier Support d'Agile PLM 9.3.x. Plus de correctifs de sécurité, plus de corrections de bugs critiques, plus de certifications maintenues. Environ 2 000 industriels dans le monde font encore tourner leurs données produit sur cette plateforme : fabricants d'équipements industriels, entreprises électroniques, équipementiers automobiles, fabricants de dispositifs médicaux, donneurs d'ordres aéronautiques, spécialistes de l'énergie, marques de grande consommation. Pour tous, un logiciel non supporté en 2028 n'est pas qu'un problème informatique. C'est un frein à la vélocité engineering, une exposition sécurité croissante, et pour les organisations soumises à la FDA 21 CFR Part 11, l'EU MDR, l'ISO 13485, l'AS9100 / EN 9100, l'IATF 16949, l'ITAR, SOC 2 ou l'ISO 27001, un risque de conformité de plus en plus difficile à défendre.
Chaque éditeur PLM a publié son guide "migrez vers nous". Ils sont utiles, mais chacun conclut par la même réponse quelle que soit la question. Cet article prend le parti inverse : nous cartographions les options réalistes, nommons les compromis honnêtement, et vous donnons un cadre de sélection défendable devant votre direction.
Si vous faites tourner Agile depuis dix ou quinze ans, ce n'est pas un projet de migration. C'est une occasion de sauter une génération de PLM. La plupart des entreprises ne la saisiront pas. Celles qui le feront auront dix ans d'avance.
En bref : Oracle Agile PLM Premier Support prend fin le 31 décembre 2027. Ce guide cartographie cinq archétypes de remplacement réalistes, un plan de migration en six phases et un cadre de sélection défendable devant votre direction, avec les compromis honnêtes pour chaque éditeur.
Que signifie concrètement la fin de vie d'Oracle Agile PLM en 2027 ?
Le Premier Support d'Agile 9.3.x prend fin le 31 décembre 2027. À partir du 1er janvier 2028, les clients basculent en Sustaining Support : les correctifs existants restent accessibles, mais sans nouveaux correctifs de sécurité, sans corrections de bugs, sans certifications. La dernière version, 9.3.6, a été livrée en 2017. La version 9.3.7 prévue a été annulée.
Pour tout industriel, les conséquences pratiques sont identiques : exposition sécurité croissante, fidélisation des talents plus difficile, intégrations qui se dégradent lentement à mesure que les ERP, CAO et MES avancent, et absence d'accès aux capacités modernes (gestion des modifications assistée par IA, collaboration fournisseurs en temps réel, workflows configurables) que les concurrents déploient déjà. Pour les industriels des secteurs réglementés (aéronautique, médical, automobile, énergie), un système non corrigé complique également les audits.
CIMdata souligne la même dynamique dans son profil Oracle : les clients vont migrer, la question est de savoir vers quoi. Le classement PLM d'ABI Research positionne Oracle comme un suiveur (62/100), loin derrière les leaders. Le consensus du marché est établi. Votre décision, elle, ne l'est pas encore.
Oracle Cloud PLM est-il le bon remplaçant d'Agile PLM ?
L'argument d'Oracle est simple : restez dans la famille, migrez vers Fusion Cloud PLM, conservez vos compétences. C'est un point de départ raisonnable, et pour les organisations déjà engagées sur Oracle Fusion ERP, cela peut être la bonne destination. Le produit est mature et continue d'évoluer.
Ce qu'il faut savoir avant de supposer qu'il s'agit d'une mise à niveau à l'identique : Oracle Cloud PLM (lancé en 2015) repose sur une architecture et un modèle de données différents d'Agile, par conception, pour un monde cloud-first. La conséquence pratique est que la migration s'apparente davantage à une ré-implémentation qu'à une montée de version. Les workflows et personnalisations (y compris les Process Extensions) doivent généralement être reconfigurés plutôt que portés. Les connecteurs existants vers ECAD, MCAD, ERP, MES et portails fournisseurs ont été construits sur le SDK d'Agile et devront pour la plupart être repensés via l'API Fusion. Et le modèle de déploiement est SaaS uniquement, ce qui importe si vous avez besoin d'un mode hybride, d'une résidence spécifique des données ou d'une ségrégation stricte pour le contrôle des exportations.
Rien de cela ne disqualifie Oracle Cloud PLM. Mais cela signifie que l'effort de migration est comparable à l'évaluation d'autres plateformes. Une fois accepté que rester chez Oracle implique tout de même une ré-implémentation significative, la question devient : quelle plateforme mérite les dix prochaines années de vos données produit, sachant que vous faites le travail dans tous les cas ?
Alternatives à Oracle Agile PLM : cinq archétypes comparés
La plupart des articles sur les alternatives à Oracle Agile listent huit à dix éditeurs et vous laissent vous débrouiller. C'est peu utile. Les éditeurs se regroupent en cinq archétypes, et l'archétype compte davantage que la marque. Choisissez l'archétype adapté à votre activité, puis sélectionnez à l'intérieur.
Archétype 1 : Oracle Fusion Cloud PLM (rester chez Oracle)
Le chemin de moindre résistance culturelle. Même éditeur, même contrat, même commercial. Mais le chemin de plus grande résistance technique : ré-implémentation complète sous un autre nom. À retenir dans la liste restreinte uniquement si vous êtes profondément engagé sur Oracle Fusion ERP et souhaitez tout centraliser dans un seul écosystème. Pour la plupart des clients Agile, l'effort de migration est identique à celui d'un changement d'éditeur, la prime de fidélité est donc illusoire.
Archétype 2 : PTC Windchill et Siemens Teamcenter (Legacy enterprise, cloud-washed)
Les poids lourds du marché. Windchill (1998) et Teamcenter (milieu des années 1990) ont été conçus pour les plus grands industriels avec les architectures CAO les plus lourdes, et ils servent toujours bien ce segment. Les deux éditeurs proposent désormais des variantes SaaS (Windchill+, Teamcenter X), mais les modèles de données sous-jacents sont matures (pour ne pas dire anciens). Si vous êtes un donneur d'ordres aéronautique de premier rang, un équipementier automobile Tier 1 avec une intégration CATIA ou NX profonde, ou un industriel de défense, cet archétype est difficile à battre en termes de profondeur fonctionnelle. Si vous êtes un industriel de taille intermédiaire, vous achetez des capacités que vous n'utiliserez jamais, avec les coûts d'implémentation qui vont avec.
Archétype 3 : Arena (PTC), Autodesk Fusion Manage, Propel (PLM Cloud de première génération)
C'est là que se retrouvent la plupart des anciens clients Agile du marché intermédiaire. Arena (fondé en 2000, acquis par PTC en 2021), Autodesk Fusion Manage (anciennement Autodesk PLM 360, lancé en 2012) et Propel (construit sur Salesforce, fondé en 2015 par d'anciens membres de l'équipe Agile) sont nativement cloud et offrent une implémentation plus rapide que Windchill ou Teamcenter. Ils couvrent la gestion des nomenclatures, la gestion des modifications, le contrôle documentaire et la qualité de base, avec une bonne ergonomie et une tarification prévisible.
La critique honnête : ils ont été conçus pour l'électronique grand public et les produits de consommation, et la profondeur qu'ils offrent au-delà de ce cœur peut être inégale pour les industriels avec des besoins poussés en gestion de configuration ou en conformité sectorielle. Leurs capacités IA sont réelles mais ajoutées par-dessus (Arena AI Assistant, Propel One AI) plutôt que natives au modèle de données. Et ils ont chacun des dépendances écosystème qui comptent : Arena appartient désormais à PTC, Propel repose sur Salesforce, Autodesk Fusion Manage suppose que vous vivez dans l'écosystème Autodesk.
Archétype 4 : Aras Innovator (Legacy open / low-code)
Aras (fondé en 2000) a bâti sa réputation sur la configurabilité sans code : une plateforme model-driven que vous pouvez façonner pour s'adapter à des processus atypiques. Pour les clients Agile qui ont construit des personnalisations lourdes difficiles à abandonner, Aras offre une continuité d'intention : vous pouvez modéliser ce que vous aviez, souvent plus proprement. Le compromis : vous gérez toujours une plateforme du début des années 2000, et la promesse "open" s'accompagne de la responsabilité d'une équipe interne capable de la maîtriser.
Archétype 5 : Aletiq (PLM nouvelle génération, natif IA)
Le plus récent des archétypes, et celui que la plupart des articles concurrents ignorent. Construit après 2020 sur une architecture moderne, les PLM natifs IA sont conçus depuis le modèle de données pour tirer parti des grands modèles de langage, des workflows agentiques et des processus configurables sans code. Aletiq est un exemple de référence de cette catégorie, conçu pour les industriels du discret qui veulent un PLM rapide et configurable, capable de s'adapter aussi bien à des produits industriels standards qu'aux programmes les plus exigeants en aéronautique, médical, automobile, énergie et luxe.
L'argument en faveur de cet archétype est simple. Windchill, Teamcenter, Aras, Arena et Agile lui-même ont tous été conçus avant que le cloud soit répandu, et bien avant l'émergence des LLMs. Ils excellent dans ce pour quoi ils ont été conçus, dans l'architecture de leur décennie. La question est de savoir si la prochaine décennie de développement produit ressemble davantage aux vingt dernières années, ou si elle est suffisamment différente pour qu'une nouvelle fondation se justifie.
Comparatif des alternatives à Oracle Agile PLM (2026)
Le tableau ci-dessous compare les huit destinations réalistes sur les critères qui les différencient réellement. Il est délibérément tranché, et basé sur la documentation produit publique, le positionnement des éditeurs et les analyses sectorielles (CIMdata, ABI Research, Quadrant). Utilisez-le pour affiner votre liste restreinte, pas pour prendre la décision finale.
Note sur le délai avant valeur. Les chiffres ci-dessus sont des fourchettes réalistes pour un go-live en production sur un périmètre cœur (articles, nomenclatures, gestion des modifications, contrôle documentaire, deux à trois intégrations), pas les chiffres des plaquettes commerciales. Ils supposent un périmètre discipliné et des données propres.
Comment choisir un remplaçant à Oracle Agile PLM : 6 critères de sélection
La grille de comparaison PLM standard (gestion des nomenclatures, contrôle des modifications, gestion documentaire, collaboration fournisseurs) est désormais le minimum syndical. Tous les éditeurs sérieux cochent toutes les cases. Les critères qui différencient réellement les options sont plus difficiles à trouver dans une plaquette.
Adéquation avec votre façon de concevoir vos produits
Un PLM moderne doit correspondre à votre réalité engineering : la façon dont vous gérez les nomenclatures, les configurations, les révisions, les transferts fournisseurs et la gestion des modifications. Si vous opérez dans un environnement réglementé, l'éditeur doit également disposer d'un dossier de validation documenté (FDA 21 CFR Part 11, ISO 13485, EN 9100, IATF 16949 selon le cas) et d'une traçabilité défendable en audit. N'acceptez pas un langage générique sur la conformité, demandez les livrables.
Sécurité des données et hébergement
Où se trouvent physiquement vos données, et sous quelle juridiction ? L'ISO 27001 est le minimum. Selon votre contexte, vérifiez également la disponibilité FedRAMP ou d'un hébergement compatible ITAR (défense américaine), la disponibilité en région EU et l'alignement RGPD (opérations européennes), ou des engagements spécifiques sur la résidence des données (multinationales). Lisez attentivement le contrat sur la résidence des données, l'accès des sous-traitants et le traitement des demandes gouvernementales.
Configuration vs personnalisation
Un PLM moderne doit vous permettre de reproduire 80 % de vos personnalisations Agile en configuration no-code, les 20 % restants via des points d'extension documentés. Si vous remplacez une dépendance au code personnalisé (Agile) par une autre (Windchill ou Aras sur-personnalisé), vous avez déplacé le problème, pas résolu.
Maturité IA, native vs ajoutée
La plupart des éditeurs ont désormais un "assistant IA". Posez des questions plus précises : lit-il les plans, classe-t-il les composants, rédige-t-il des ordres de modification, les route-t-il dans votre workflow ? Une IA native est intégrée dans le modèle de données. Une IA ajoutée est un chatbot devant une barre de recherche.
Profondeur d'intégration, pas seulement nombre d'intégrations
Chaque éditeur affiche un mur de logos ERP, CAO et MES partenaires. Les vraies questions : le connecteur gère-t-il votre version de SAP S/4HANA ou Microsoft Dynamics ? Gère-t-il les allers-retours de vos configurations CAO (SolidWorks, CATIA, NX, Creo, Inventor) ? Le portail fournisseurs gère-t-il la visibilité multi-niveaux dont vous avez réellement besoin ? Assistez à une démo du connecteur avec votre scénario d'intégration réel.
Délai avant valeur honnête
Les plaquettes commerciales promettent un go-live "en quelques semaines". Les vraies migrations Agile, pour des entreprises avec des données et des intégrations sérieuses, prennent 8 à 12 mois. Pour des industriels de taille intermédiaire avec un périmètre discipliné, 4 à 6 mois est réaliste. Quiconque promet 30 jours vous vend un bac à sable, pas un système de production. Demandez deux clients de taille comparable dont le go-live date de moins de 18 mois.
TCO sur dix ans, pas sur trois ans de licence
Le coût de l'abonnement est le chiffre visible. Le coût réel comprend l'implémentation, l'intégration, la formation, la conduite du changement, l'administration courante et la charge de mise à jour cinq ans plus tard. Construisez un modèle sur dix ans qui intègre tout. La licence la moins chère devient souvent le programme le plus coûteux.
Migration Oracle Agile PLM : un plan en six phases
La plupart des projets de migration échouent dans les trois premiers mois, avant que la moindre donnée n'ait été déplacée. Voici la séquence qui fonctionne.
Phase 0 : audit interne honnête
Avant de parler à un éditeur, comptez vos utilisateurs actifs (pas les "licenciés"), votre volume de données, vos Process Extensions, vos intégrations en production et les groupes d'utilisateurs susceptibles de résister. Sauter cette étape est la cause la plus fréquente d'échec des migrations.
Phase 1 : définissez la cible, pas la migration
Ne cadrez pas le nouveau PLM comme "Agile, dans le cloud". Cela garantit que vous transportez dix ans de compromis vers l'avenir. Définissez comment la gestion des modifications, le contrôle documentaire et la collaboration fournisseurs devraient fonctionner, puis choisissez la plateforme qui supporte le mieux cette cible.
Phase 2 : nettoyez les données dans Agile, pas dans le nouveau système
Toute instance contient des articles en doublon, des documents orphelins et des lignes de nomenclature que personne ne fait confiance. Nettoyer dans le nouveau système coûte deux fois plus cher et donne deux fois moins de résultats.
Phase 3 : pilote
Choisissez une ligne de produits ou une division. Migrez-la de bout en bout, intégrations comprises, faites tourner de vraies demandes de modification pendant 60 jours. Le pilote est le seul test honnête des promesses de l'éditeur.
Phase 4 : bascule
Le big bang est plus propre techniquement mais plus risqué sur l'adoption. Une migration progressive est plus douce pour les équipes mais plus complexe sur les intégrations. La plupart des industriels réglementés choisissent une migration progressive pour les données engineering, et un big bang pour le référentiel documentaire, avec une période de gel entre les deux.
Phase 5 : adoption
Les échecs de migration sont généralement des échecs d'adoption. Identifiez vos champions avant le go-live, formez par rôle, communiquez le pourquoi, et planifiez un renforcement du support pendant les 90 jours post go-live.
Le piège 2026
Les capacités des intégrateurs se resserrent à mesure que la date limite approche. Les entreprises qui démarrent en 2025 ou début 2026 ont le choix des équipes. Celles qui attendent 2027 paieront plus pour moins.
Qu'est-ce qu'un PLM nouvelle génération et pourquoi cela compte en 2027 ?
Les articles concurrents traitent "PLM moderne" comme un synonyme de "PLM cloud". C'était une distinction utile en 2015. En 2026, c'est le minimum requis, et une mauvaise façon de choisir une plateforme pour dix ans.
Un PLM véritablement nouvelle génération repose sur quatre ruptures intervenues depuis la conception de la génération PLM précédente.
L'IA comme acteur, pas comme barre de recherche. Les LLMs permettent au PLM de lire des plans, classer des composants, rédiger des ordres de modification, suggérer des analyses d'impact, rédiger des justifications de dérogation et proposer des évaluations de risques fournisseurs. Le système cesse d'être un référentiel passif pour devenir un assistant de l'ingénieur. Cela n'est possible que si l'IA a été intégrée dans le modèle de données, pas ajoutée comme une fonctionnalité.
Configuration sans code. Les PLM modernes permettent aux administrateurs métier de modéliser de nouveaux workflows, modifier des types d'objets et ajouter des attributs par configuration. La promesse "low-code" pionnière d'Aras est désormais le plancher. Les systèmes récents vont plus loin : configuration en heures, pas en sprints, sans escalade IT.
Un fil numérique qui traverse vraiment les fonctions. Exigence, conception, pièce, nomenclature, fournisseur, fabrication, événement qualité, incident terrain. Les PLM legacy touchent chacun de ces éléments mais les connectent rarement d'une façon qu'un ingénieur ou un responsable qualité peut tracer en deux clics. Les systèmes nouvelle génération traitent ce fil comme la structure de données primaire.
Conçu pour l'industrie discrète, pas adapté. La plupart des PLM cloud ont été conçus pour l'électronique grand public. La gestion de configuration, la profondeur supply chain et les workflows sectoriels dont a besoin un industriel du discret sont des couches ajoutées. Les PLM nouvelle génération, dont Aletiq, ont démarré depuis la contrainte du discret industriel et ont construit à partir de là.
Si vous évaluez des options PLM en 2026, la décision d'architecture que vous prenez ressemble davantage au choix cloud-vs-on-prem de 2010 qu'à un simple changement d'éditeur. Choisissez la génération, puis l'éditeur à l'intérieur.
Oracle Agile PLM : votre décision 2027
Oracle a pris la décision pour vous en octobre 2023 en annonçant la fin de vie. La décision maintenant n'est pas de savoir si vous devez migrer, mais si vous migrez vers une plateforme qui paraîtra encore moderne en 2030, ou vers une autre qui montre déjà son âge.
L'option facile est de choisir la destination la plus familière, d'accepter que ce soit fonctionnellement une ré-implémentation, et de laisser passer l'opportunité de moderniser l'architecture avec la licence. L'option plus intelligente est de traiter cela comme une décision stratégique : nettoyez vos données, définissez vos processus cibles, et choisissez une plateforme conçue pour la prochaine décennie.
Aletiq est dans cette conversation parce que nous avons construit notre PLM dans cette génération, pour les industriels du discret des deux côtés de l'Atlantique, avec une IA native au modèle de données et une configuration native à la plateforme. Le produit s'adapte aussi bien aux cas d'usage industriels standards qu'aux programmes réglementés les plus exigeants, avec un hébergement en régions US et EU. Si cet archétype correspond à la façon dont vous souhaitez opérer, nous devrions en parler. Si ce n'est pas le cas, le cadre ci-dessus vous aidera quand même à prendre une meilleure décision.
Les entreprises qui traitent 2027 comme une migration forcée passeront deux ans pour arriver là où elles étaient. Celles qui y voient une remise à zéro générationnelle arriveront là où leurs concurrents ne pourront pas les suivre pendant une décennie.
Vous souhaitez aller plus loin ? Demandez une démo Aletiq ou échangez avec l'un de nos experts pour faire le point sur votre situation de migration, sans engagement.
FAQ Oracle Agile PLM
Quand exactement Oracle Agile PLM arrive-t-il en fin de vie ?
Le Premier Support d'Agile PLM 9.3.x prend fin le 31 décembre 2027. À partir de cette date, les clients basculent en Sustaining Support, ce qui signifie accès aux correctifs existants mais plus de nouveaux correctifs de sécurité, corrections de bugs ou certifications.
Oracle continuera-t-il à vendre Agile PLM après 2027 ?
Aucune nouvelle activité commerciale. Les clients existants peuvent rester en Sustaining Support, mais sans nouveaux contrats ni feuille de route. Oracle oriente ses clients vers Fusion Cloud PLM.
Peut-on simplement migrer vers Oracle Cloud PLM ?
Techniquement oui, pratiquement non. Oracle Fusion Cloud PLM repose sur une architecture et un modèle de données différents. Les workflows, personnalisations et intégrations doivent être reconstruits. L'effort est comparable à un changement d'éditeur.
Combien de temps prend réellement une migration depuis Agile ?
Pour les entreprises avec un volume de données, des intégrations et des personnalisations significatifs, comptez 8 à 12 mois. Pour les industriels de taille intermédiaire avec un périmètre discipliné, 4 à 6 mois est atteignable. Quiconque promet 30 jours vend un bac à sable.
Quelle est la meilleure alternative à Oracle Agile PLM pour les industriels de taille intermédiaire ?
Les PLM cloud de première génération (Arena, Autodesk Fusion Manage, Propel) couvrent bien les besoins de base, avec une tarification prévisible et des implémentations de 3 à 6 mois. Les plateformes nouvelle génération natives IA comme Aletiq offrent une configuration plus rapide et des capacités IA plus robustes pour les industriels qui souhaitent sauter une génération. Le bon choix dépend de votre écosystème CAO et ERP, de votre appétit pour l'IA et de la spécificité de vos processus.
Quand faut-il commencer sa migration depuis Oracle Agile PLM ?
Maintenant. Les capacités des intégrateurs se resserrent à mesure que la date limite approche, les coûts augmentent, et la migration n'est pas un projet de quatre semaines. Les entreprises qui démarrent en 2025 ou début 2026 ont le choix des équipes et des délais. Celles qui attendent 2027 paieront plus pour moins.
