MAS 8.10 et 8.11 en fin de support standard : ce que cela change vraiment pour votre GMAO

Le 30 avril 2026, une bascule discrète mais lourde de conséquences s’est produite dans les environnements Maximo de plusieurs centaines d’organisations industrielles : IBM a officiellement retiré du support standard les versions 8.10 et 8.11 de la Maximo Application Suite. Pour les équipes qui n’avaient pas anticipé ce changement, la question est maintenant posée frontalement — et elle n’admet pas de réponse vague.

Ce n’est pas une alerte de plus dans un calendrier de mises à jour. C’est un signal structurant qui touche directement la sécurité des données, la continuité opérationnelle et la capacité de votre GMAO à évoluer. IBM a communiqué officiellement ces changements le 20 mars 2026 — soit moins de six semaines avant leur entrée en vigueur, en contradiction avec sa politique minimale de préavis de six mois à compter de l’annonce initiale du cycle de vie. Ceux qui attendaient un déclencheur externe l’ont désormais.

Cet article décrypte ce que signifie concrètement ce basculement : ce que l’Extended Support couvre réellement (et ce qu’il ne couvre pas), les différences de situation entre les versions MAS 8.x, et la trajectoire vers MAS 9 qu’IBM recommande explicitement. L’objectif n’est pas de créer de l’urgence artificielle, mais de vous donner les éléments de décision que votre direction technique et votre DSI attendent.

1. Ce qui s’est passé le 30 avril 2026 : trois situations très différentes selon votre version

Le 30 avril 2026 n’a pas produit le même effet pour toutes les versions MAS 8.x en production. IBM a appliqué des traitements distincts selon les versions concernées, et la confusion entre ces situations peut conduire à de mauvaises décisions.

1.1 MAS 8.7, 8.8, 8.9 : fin de vie complète, sans filet

Pour les versions 8.7, 8.8 et 8.9, le 30 avril 2026 marque une fin de cycle de vie sans exception et sans alternative : IBM ne propose aucun Extended Support pour ces trois versions. Concrètement, aucun patch de sécurité, aucun correctif de défaut, aucune assistance IBM ne sont plus disponibles. Si votre organisation fait tourner l’une de ces versions en production, elle opère sur un socle que son éditeur ne maintient plus, sous aucune forme. C’est la situation la plus exposée, et elle ne se résout pas par un contrat additionnel.

1.2 MAS 8.10 et 8.11 : Extended Support payant, couverture réduite

MAS 8.10 et 8.11 bénéficient quant à elles d’une option d’Extended Support — mais ce programme ne doit pas être confondu avec la continuation du support standard. Selon la documentation IBM officielle, l’Extended Support couvre le support d’utilisation produit, les correctifs sur le code existant et les correctifs de défauts critiques. Il n’inclut pas les mises à jour de sécurité proactives mensuelles, ni les nouvelles fonctionnalités. C’est un filet de sécurité partiel, payant, et conçu pour accompagner une transition — pas pour constituer une position stable à long terme.

Il est utile de rappeler que MAS 8.10 avait été désignée comme version LTS (Long Term Support) lors de sa sortie en mars 2023. Ce statut lui a permis de tenir plus longtemps en support standard que les versions CD classiques. Mais depuis le 30 avril 2026, même le statut LTS de 8.10 ne lui confère plus de support complet. La désignation LTS a repoussé l’échéance, elle ne l’a pas supprimée.

1.3 Ce que signifie concrètement l’absence de mises à jour de sécurité

Pour une GMAO qui pilote des actifs critiques — lignes de production, réseaux d’eau potable, infrastructure portuaire — l’absence de mises à jour de sécurité n’est pas une abstraction. Les vulnérabilités CVE sont publiées publiquement. Un environnement non patché dont les failles sont connues devient une cible identifiable. À cela s’ajoute une dimension réglementaire : les exigences de traçabilité et de continuité imposées par des référentiels comme NIS2 supposent que les outils de gestion des actifs soient eux-mêmes maintenus dans un état sécurisé. Une GMAO non supportée fragilise l’ensemble de la posture de conformité OT — un sujet que nous avons traité en détail dans notre analyse sur la GMAO comme maillon de conformité NIS2.

Cette fragilité est d’autant plus préoccupante que la question de l’hébergement lui-même monte en puissance dans les audits de sécurité industrielle : où résident les données de maintenance, sous quelle juridiction, avec quelles garanties de souveraineté ? Les arbitrages entre performance, coût et localisation des données ne sont plus laissés à la seule discrétion des DSI — ils s’inscrivent désormais dans un cadre normatif en rapide évolution. C’est précisément ce que bouscule la nouvelle réglementation européenne sur le cloud, dont les implications concrètes pour l’hébergement d’une GMAO méritent d’être examinées attentivement.

2. Comprendre la nouvelle politique de support de MAS 9 : Support Cycle-3

La migration vers MAS 9 n’est pas seulement une fuite en avant face à la fin de support des versions 8.x : c’est un changement de modèle de cycle de vie, plus lisible et plus stable pour les organisations industrielles.

2.1 Du modèle Continuous Delivery au Support Cycle-3

Les versions MAS 8.7 à 8.11 suivaient la politique IBM Continuous Delivery (CD). Dans ce modèle, le support est conditionnel au fait de rester sur l’une des deux versions mineures les plus récentes — ce qui implique une cadence de mise à jour soutenue que peu d’équipes maintenance ont pu tenir rigoureusement. C’est précisément l’une des raisons pour lesquelles de nombreuses organisations se sont retrouvées sur des versions en retard le 30 avril 2026.

À partir de MAS 9.0, IBM a adopté la politique Support Cycle-3 : un support technique complet, couvrant défauts et hors défauts, pendant une période d’au moins trois ans à compter de la date de disponibilité générale du produit. MAS 9.0 est disponible depuis juin 2024, MAS 9.1.x depuis le 24 juin 2025. MAS 9.2.x est également référencé dans les ressources de support actives d’IBM. Cette politique offre aux équipes une fenêtre de stabilité prévisible — ce que le modèle CD ne garantissait pas de la même façon.

2.2 Ce que MAS 9 apporte au-delà du seul maintien du support

Raisonner uniquement en termes de « rester sous support » revient à minimiser ce que représente MAS 9 sur le fond. La Maximo Application Suite en version 9 est architecturalement différente de ses prédécesseurs : elle est construite nativement sur Red Hat OpenShift, ce qui ouvre des capacités de déploiement, de scalabilité et d’intégration IoT que MAS 8.x ne pouvait pas atteindre dans les mêmes conditions.

C’est également la base sur laquelle s’articulent les fonctionnalités d’intelligence artificielle les plus récentes — Maximo Monitor, Maximo Predict, Maximo Health — qui transforment la maintenance réactive en maintenance conditionnelle ou prédictive. Pour les organisations qui souhaitent aller au-delà de la simple gestion des ordres de travail et commencer à exploiter leurs données d’actifs pour anticiper les défaillances, MAS 9 constitue le socle technique indispensable. La question n’est donc pas seulement « quand migrer ? » mais aussi « quelles capacités est-ce que je veux pour ma maintenance dans trois ans ? ».

3. Les vraies questions opérationnelles que pose ce basculement

Au-delà des définitions techniques, ce changement soulève des questions concrètes que les responsables maintenance et les DSI doivent traiter — sans attendre que la situation se dégrade.

3.1 L’Extended Support est-il une position tenable à moyen terme ?

La réponse courte est non — du moins pas comme stratégie principale. L’Extended Support est conçu pour offrir un délai supplémentaire pendant lequel une organisation peut préparer sa migration sans être totalement exposée. Il ne restaure pas le niveau de service du support standard, et il a lui-même une durée limitée. Y recourir sans définir en parallèle une feuille de route vers MAS 9, c’est reporter l’inévitable en payant pour un service réduit. C’est parfois la bonne décision tactique pour quelques mois — jamais une stratégie de moyen terme.

3.2 L’information dispersée : le vrai risque d’une migration différée

Sur le terrain, une réalité frappe régulièrement les équipes qui abordent un projet de migration tardivement : la connaissance critique sur le fonctionnement réel de la GMAO est dispersée. Les paramétrages spécifiques ont été réalisés par des consultants qui ne sont plus là, documentés dans des fichiers Excel locaux ou dans des emails retrouvés difficilement. Les personnalisations Maximo ont été construites au fil des années sans que leur logique soit capitalisée dans un référentiel accessible. Quand vient le moment de migrer, cette information dispersée devient un facteur de ralentissement majeur — et parfois de risque de perte irréversible si un technicien référent part entre-temps.

C’est précisément pourquoi capitaliser le savoir des techniciens avant qu’il ne parte n’est pas une préoccupation accessoire d’un projet de migration : c’est une condition de sa réussite. La connaissance la plus précieuse n’est pas dans les manuels — elle est dans la tête des personnes qui ont vécu les versions successives de votre Maximo.

3.3 La résistance au changement : le facteur d’échec le plus sous-estimé

Les projets de migration GMAO n’échouent pas sur la technologie. Ils échouent parce que les équipes terrain n’ont pas été impliquées, parce que les nouveaux workflows ont été conçus en chambre sans confrontation aux réalités opérationnelles, ou parce que la communication autour du changement a été insuffisante. MAS 9, avec son interface repensée et son architecture différente, représente un changement visible pour chaque technicien qui utilise la GMAO quotidiennement. Ignorer la dimension humaine de ce projet, c’est programmer des difficultés d’adoption qui dégraderont la qualité des données et, in fine, l’efficacité de la maintenance.

Une approche structurée en trois phases — préparer, gérer, consolider — s’impose ici comme elle s’impose dans tout projet GMAO d’envergure. Nous avons détaillé cette mécanique dans notre article sur la résistance au changement dans un projet GMAO.

4. Construire la trajectoire de migration : principes et points d’attention

Poser la question « comment migrer vers MAS 9 ? » sans avoir d’abord répondu à « dans quel état est mon environnement actuel ? » mène droit dans le mur. La migration n’est pas un projet de remplacement à l’identique — c’est une opportunité de remise à plat qui se prépare méthodiquement.

4.1 Partir de l’audit de l’existant, pas de la version cible

La première étape n’est pas de choisir entre MAS 9.0, 9.1 ou 9.2 : c’est d’auditer précisément votre environnement MAS 8.x actuel. Quelles personnalisations ont été développées hors du cadre standard ? Quelles intégrations ERP, IoT ou achats sont en place, et comment sont-elles documentées ? Quels scripts Automation, quels workflows spécifiques, quelles structures de données ont été ajustés au fil des ans ? Cet audit conditionne l’estimation réaliste de l’effort de migration et l’identification des risques techniques.

Une migration bien préparée depuis MAS 8.10 vers MAS 9.x n’a pas le même profil qu’une migration depuis MAS 8.7 — l’écart d’architecture est plus marqué dans le second cas. La version de départ compte autant que la version d’arrivée.

4.2 Choisir la version cible en fonction de la fenêtre de support résiduelle

MAS 9.0 est disponible depuis juin 2024, MAS 9.1.x depuis juin 2025. Puisque la politique Support Cycle-3 garantit au minimum trois ans de support à compter de la date de disponibilité générale, cibler la version la plus récente en support actif au moment du démarrage du projet maximise mécaniquement la fenêtre de tranquillité opérationnelle après migration. Ce n’est pas une logique de « toujours dernière version » pour son propre compte — c’est une logique de calcul de la durée de vie utile de la version cible.

4.3 Le SaaS managé comme accélérateur et simplificateur

Pour beaucoup d’organisations, la migration vers MAS 9 est aussi l’occasion de reposer la question de l’architecture d’hébergement. MAS 9 est cloud-native par conception : le déployer sur une infrastructure on-premise ou gérer soi-même l’environnement OpenShift implique des compétences et une charge opérationnelle que peu d’équipes IT ont en interne. Un modèle IBM Maximo en SaaS managé transfère cette charge à un opérateur spécialisé, avec des SLAs définis contractuellement, et libère l’équipe IT pour se concentrer sur les usages métiers plutôt que sur l’administration de la plateforme.

La question de la souveraineté des données se pose naturellement dans ce choix. Pour les organisations industrielles soumises à des exigences de conformité OT ou les acteurs du service public, une architecture Single Tenant — environnement dédié, isolé, hébergé en France — répond à des contraintes que le SaaS mutualisé ne peut pas satisfaire. Ce n’est pas un luxe : c’est souvent une exigence non négociable de la RSSI ou du donneur d’ordre.

Notre guide complet sur réussir la transition vers MAS 9 détaille la méthodologie en cinq étapes que nous recommandons, des enjeux techniques aux décisions organisationnelles.

Questions fréquentes

MAS 8.10 était une version LTS : cela lui offre-t-il une protection supplémentaire après le 30 avril 2026 ?

Non. La désignation LTS (Long Term Support) de MAS 8.10 lui a permis de bénéficier d’une fenêtre de support standard plus longue que les versions CD classiques — c’est précisément ce qui a différé son basculement par rapport à 8.7, 8.8 ou 8.9. Mais depuis le 30 avril 2026, même le statut LTS de 8.10 ne lui confère plus de support standard. La version est désormais en Extended Support payant, avec une couverture réduite. La désignation LTS ne constitue pas un filet de sécurité perpétuel : elle a simplement repoussé l’échéance, elle ne la supprime pas.

Peut-on continuer à utiliser MAS 8.10 ou 8.11 en production sans souscrire à l'Extended Support ?

Techniquement, rien n’empêche de faire tourner un environnement sans contrat de support. En pratique, cela signifie qu’aucun correctif de sécurité, aucun patch de défaut et aucune assistance IBM ne seront disponibles en cas d’incident. Pour une GMAO qui pilote des actifs critiques — équipements de production, infrastructures d’eau potable, flottes portuaires — cette situation expose l’organisation à des risques opérationnels et réglementaires significatifs, notamment au regard des exigences de traçabilité et de continuité imposées par des référentiels comme NIS2.

La migration vers MAS 9 implique-t-elle de revoir toutes les personnalisations et interfaces existantes ?

C’est la question que pose systématiquement chaque équipe avant de lancer le chantier — et c’est une préoccupation légitime. MAS 9 repose sur une architecture cloud-native (Red Hat OpenShift) substantiellement différente de la pile technique de MAS 8.x. Les personnalisations développées hors du cadre standard, les scripts Automation et certaines intégrations ERP ou IoT devront être auditées et adaptées. C’est précisément pourquoi la méthodologie en étapes — audit, cartographie des flux, remontée vers la version cible, recette — est indispensable, plutôt qu’une bascule directe.

Quelle est la différence entre MAS 9.0, 9.1 et 9.2 ? Vers quelle version migrer en priorité ?

MAS 9.0 est disponible depuis juin 2024, MAS 9.1.x depuis juin 2025 et MAS 9.2.x est référencé dans les ressources de support IBM. Ces versions suivent toutes la politique Support Cycle-3, qui garantit un support technique complet pendant au moins trois ans à compter de leur date de disponibilité générale. En règle générale, il est recommandé de cibler la version la plus récente en support actif au moment du démarrage du projet de migration, afin de maximiser la fenêtre de support résiduel et de bénéficier des dernières fonctionnalités IA et cloud-native.

Conclusion

Le basculement de MAS 8.10 et 8.11 en Extended Support au 30 avril 2026 n’est pas un événement qu’on peut gérer par l’inaction. Rester en Extended Support sans feuille de route définie, c’est payer pour un service réduit tout en laissant le risque technique s’accumuler. Continuer sur MAS 8.7, 8.8 ou 8.9 sans plan de migration, c’est opérer en dehors de tout filet de sécurité éditeur.

La bonne nouvelle, c’est que MAS 9 — avec sa politique Support Cycle-3 et son architecture cloud-native — offre une plateforme nettement plus stable et plus capable que ce que les versions 8.x permettaient. La migration est un effort réel, qui demande un audit rigoureux, une conduite du changement structurée et un choix d’architecture d’hébergement adapté aux contraintes de souveraineté de votre organisation. Mais c’est un effort qui, bien préparé, repositionne votre maintenance sur une trajectoire à trois ans au minimum.

Si vous souhaitez faire le point sur votre situation — version actuelle, écart vers MAS 9, options d’architecture — les experts Odexio peuvent vous accompagner dès la phase de diagnostic. Demander une démo est la première étape pour transformer cette contrainte calendaire en levier de modernisation concret.