1. Contexte Stratégique et Impératifs de Migration
La fin du support standard pour IBM Maximo 7.6.1.x, fixée au 30 septembre 2025, n’est pas une simple échéance calendaire ; c’est un pivot critique pour la continuité de vos opérations. Maintenir une infrastructure sur une version héritée au-delà de cette date expose l’organisation à des risques majeurs : obsolescence de Java 8, vulnérabilités de sécurité non corrigées et non-conformité stricte avec les cadres ISO 55000.
Cette transition vers Maximo Application Suite 9 (MAS 9) impose un changement de paradigme. Il ne s’agit plus de gérer une application monolithique, mais de migrer vers un écosystème cloud-natif conteneurisé. MAS 9 offre des opportunités de transformation immédiates, notamment l’IA prédictive et une modularité accrue, mais exige une rigueur méthodologique absolue. L’urgence impose d’initier dès maintenant une phase d’évaluation exhaustive pour éviter les dérives de périmètre qui condamnent les projets mal préparés.
2. Phase 1 : Évaluation (Assessment) – L’Audit de l’Existant
L’évaluation est la fondation sur laquelle repose la réussite technique du projet. Sans un inventaire chirurgical de l’existant, les « surprises d’infrastructure » et les dettes techniques cachées allongeront inévitablement vos délais.
Activités clés de l’audit :
- Inventaire de l’architecture : Documentation des versions OS, serveurs d’application (WebSphere/WebLogic) et bases de données.
- Catalogage des personnalisations : Recensement des classes Java, scripts d’automatisation, triggers SQL et écrans. Notez que 30 % à 50 % des modifications héritées sont généralement obsolètes ou remplacées nativement par MAS 9.
- Cartographie des intégrations : Identification des flux via le Maximo Integration Framework (MIF) et, surtout, des accès directs à la base de données (Direct DB access), proscrits dans le modèle MAS.
Métriques de qualité de données attendues : Le succès de MAS 9 dépend de la pureté des données injectées. Nettoyer les données dans MAS est exponentiellement plus complexe et coûteux que de le faire dans l’environnement 7.6.
| Domaine de données | Métrique cible | Critères de succès |
| Actifs (Assets) | > 95 % | Hiérarchie complète, absence d’orphelins et doublons. |
| Emplacements (Locations) | > 98 % | Intégrité de la structure et absence de références circulaires. |
| Bons de travail (Work Orders) | 100 % (Actifs) | Migration limitée aux ordres actifs et historiques récents (< 2 ans). |
| Classifications | > 95 % | Standardisation des attributs et nettoyage des schémas inutilisés. |
3. Phase 2 : Rationalisation – Réduction de la Dette Technique
Le passage à MAS 9 signe la fin définitive du modèle « Lift-and-Shift ». La rationalisation consiste à démanteler la dette technique accumulée pour adopter un modèle optimisé et maintenable.
Db2 est désormais inclus nativement dans la licence MAS, éliminant ainsi les frais de licence tiers et simplifiant le support. C’est un levier de ROI majeur pour le projet.
Le « Rationalization Framework » :
- Retirer : Supprimer tout ce qui n’a pas été utilisé depuis 12 mois.
- Remplacer par la configuration : Exploiter les fonctions natives (ex: Maximo Spatial, Linear et Calibration sont désormais intégrés à Manage).
- Redessiner : Migrer les accès directs DB vers des APIs/Events.
- Conserver : Uniquement les processus métiers critiques.
Avertissement de l’Architecte : Le passage à Java 17 et la suppression totale du moteur Nashorn rendent vos anciens scripts JavaScript incompatibles. Une refonte vers les scripts d’automatisation Python/JS modernes est impérative. De même, tous les triggers de base de données personnalisés doivent être désactivés avant la migration, sous peine de faire échouer le pipeline de déploiement.
4. Phase 3 : Préparation des Données et Stratégie d’Archivage
La migration des données est souvent le goulot d’étranglement principal. Une base de données encombrée ralentit l’infrastructure OpenShift et gonfle inutilement les coûts de stockage.
La règle des trois horizons :
- Données Actives (< 2 ans) : Migration complète vers MAS pour garantir la continuité.
- Données Semi-Actives (2-7 ans) : Migration sélective (historiques PM critiques) ou transfert vers un entrepôt de données (Data Warehouse).
- Données Inactives (> 7 ans) : Archivage froid. L’instance 7.6 doit rester en lecture seule pour les obligations légales.
L’utilisation d’un pipeline ETL moderne et d’outils comme TARDOX Data Utility est fortement recommandée pour synchroniser les données en arrière-plan et réduire la fenêtre de coupure à quelques heures seulement.
5. Phase 4 : Architecture et Construction – L’Écosystème OpenShift
L’architecture passe d’un modèle statique WebSphere ND à un environnement dynamique orchestré par Red Hat OpenShift (OCP).
Spécifications des clusters OpenShift pour MAS 9 : MAS 9.0/9.1 exige OCP 4.14 ou 4.15. Pour une installation MAS 9.1 optimale, la version OCP 4.16 est recommandée.
| Composant | Spécification Minimale | Spécification Recommandée | Solutions de Stockage |
| Nœuds de Contrôle | 3 Nœuds | 3 Nœuds (Dédiés) | SSD Haute Performance |
| Nœuds de Travail | 3 Nœuds | 5+ Nœuds | Red Hat ODF ou IBM Storage Fusion |
| Ressources/Nœud | 8 vCPU / 32 GB RAM | 16+ vCPU / 64+ GB RAM | ReadWriteMany (RWX) Capable |
Composants Critiques & Opérateurs :
- MongoDB (v6.0/7.0) : Métadonnées et index.
- Kafka : Remplace JMS pour les flux d’événements.
- DRO (Data Reporter Operator) : Remplace l’ancien UDS pour le reporting des métriques plateforme.
- SLS (Suite License Service) : Centralisation des AppPoints.
Gestion des Personnalisations : Le déploiement s’effectue via une Customization Archive (.zip). Pro-tip : Avant de modifier le fichier web.xml, vous devez impérativement récupérer la version générée du conteneur actif via la commande oc rsync pour garantir la compatibilité avec Liberty.
6. Phase 5 : Validation et Tests – Garantir la Continuité
Les tests ne sont pas une formalité, mais une stratégie de réduction des risques opérationnels.
- Répétitions de mise en service (Cutover Rehearsals) : Deux répétitions complètes sont le minimum non-négociable. La première identifie les goulots d’étranglement du « Runbook », la seconde valide les corrections.
- Critères de succès Go/No-Go :
- Zéro défaut critique non résolu.
- Performance des APIs validée (temps de réponse < 1s).
- Réconciliation stricte des stocks et compteurs d’actifs.
7. Phase 6 : Mise en Service et Support Hypercare
Le « Week-end de Bascule » comprend le gel de la 7.6, la migration delta et la bascule DNS.
Modèle Hypercare (4 à 8 semaines) :
- War Room : Cellule d’experts dédiée (résolution des critiques en < 4h).
- Surveillance : Monitoring intensif des pods et de la santé des opérateurs via Grafana.
- Transition : Démantèlement progressif de l’instance 7.6 après stabilisation complète (3-6 mois minimum).
8. Gestion des Licences et Modèle AppPoints
MAS 9 introduit les AppPoints, un pool de jetons partagés. Notez les changements de noms : Maximo Assist devient Maximo Collaborate et Maximo Health est désormais un add-on intégré à Manage, et non plus une application autonome.
Coûts des AppPoints (Ratio de conversion) :
| Type d’utilisateur | Autorisé | Concurrent | Notes stratégiques |
| Self-Service | 0 | 0 | Requêtes et consultations limitées. |
| Limited | 2 | 5 | Max 3 modules Manage + Monitor. |
| Base | 3 | 10 | Manage, Health, IT, Collaborate. |
| Premium | 5 | 15 | Predict, Visual Inspection, etc. |
| Admin Base | 10 | N/A | Gestion des utilisateurs / Workspaces. |
| Admin Premium | 15 | N/A | Gestion complète de la Suite / Cluster. |
Points d’Installation (Install AppPoints) : Certaines solutions consomment des points par instance déployée :
- Civil Infrastructure : 50 pts.
- SAP / Oracle / Workday Connector : 80 pts.
- Maximo Optimizer : 220 pts (ou 60 pts en version Limited).
- Maximo Spatial : 20 pts.
Conseil : Utilisez l’utilitaire AppPoint Licensing sur votre version 7.6 actuelle pour simuler vos consommations réelles avant tout engagement contractuel.
9. Conclusion et Recommandations Finales
La migration vers MAS 9 est une transformation historique. Le succès repose sur trois piliers : la qualité des données, la maîtrise d’OpenShift et la rationalisation drastique des personnalisations Java.
Compte tenu de la complexité de l’orchestration Kubernetes et des nouveaux modèles de développement, l’accompagnement par un partenaire certifié comme NYR Solutions est indispensable pour sécuriser cette transition et exploiter pleinement la puissance de l’IA et du cloud hybride.
