Migration Coswin 8i vers IBM Maximo : les 5 pièges que personne ne signale

La décision est prise : Coswin 8i a rendu service, mais le projet EAM évolue, les exigences de reporting changent, et Maximo s'impose comme la prochaine étape. Ce que votre intégrateur ne vous dira pas avant la signature, c'est que les deux outils ne fonctionnent pas de la même façon — et que mapper Coswin sur Maximo sans préparation produit, dans le meilleur des cas, un Maximo qui ressemble à Coswin en moins pratique.

Les 5 pièges décrits ici ne sont pas des anecdotes. Ils sont documentés sur des projets de migration CMMS dans plusieurs secteurs industriels. Et ils ont un point commun : ils surviennent toujours avant le go-live, mais ne sont jamais signalés avant le démarrage.

Piège 1 — Mapper le modèle Coswin sur Maximo sans repenser la structure des actifs

Dans Coswin 8i, la structure des actifs est relativement plate : un équipement, un emplacement, une fiche. Dans Maximo, le modèle distingue les Locations (emplacements fonctionnels permanents) des Assets (équipements physiques déplaçables), avec une hiérarchie qui peut descendre sur 4 à 6 niveaux. Ce n'est pas une nuance technique — c'est la colonne vertébrale de tous vos rapports de fiabilité, de coûts de maintenance et de MTBF pour les années suivantes.

Comme le documente Epsilon LLC, "la migration des données actifs est presque toujours sous-estimée — les équipes se concentrent sur l'export de fichiers sans se demander si les données doivent exister dans Maximo de la même façon que dans le système legacy." Le résultat le plus fréquent : une hiérarchie à 2 niveaux là où il en faudrait 4, et des work orders rattachés au site plutôt qu'aux équipements. Impossible de calculer un coût de maintenance par sous-système ou un MTBF par pompe.

La correction post go-live prend 3 à 6 mois de nettoyage — et invalide tout l'historique accumulé entre-temps.

Piège 2 — Migrer l'historique work orders brut sans nettoyage préalable

L'historique Coswin, c'est la mémoire de votre maintenance : défaillances récurrentes, fréquence des pannes par équipement, consommation pièces réelle. Le piège classique est de migrer cet historique tel quel, sans passer par une phase de nettoyage.

Selon TeroTAM, 70 % des projets de migration de données échouent faute de processus de validation insuffisants et de formats incompatibles entre système source et cible. Dans Coswin 8i, les champs de description sont souvent libres : un technicien écrit "pompe HS", un autre "défaillance pompe P-12", un autre "panne habituelle". Migré tel quel dans Maximo, cet historique est illisible par les modules de maintenance prédictive et inutilisable pour calculer des indicateurs MTBF ou MTTR.

La fenêtre optimale à migrer est de 5 à 10 ans d'historique nettoyé (MaintainX) — soit l'amplitude qui couvre un cycle MTBF sur la plupart des actifs industriels majeurs. En deçà, les données de fiabilité sont incomplètes. Au-delà, le coût de nettoyage n'est généralement pas justifié par la valeur des données récupérées.

Piège 3 — Ignorer les différences de nomenclature pièces de rechange

Le référentiel pièces de Coswin est souvent construit à la main, sur plusieurs années, par plusieurs équipes. Résultat courant : "Pompe centrifuge 50mm", "Pompe centrifuge DN50", "Pompe 50" et "PC-050" coexistent pour désigner la même pièce. Dans Coswin, les équipes s'en accommodent parce qu'elles connaissent leur catalogue par cœur.

Dans Maximo, cette ambiguïté est fatale. Le module Inventory gère des stocks basés sur des références uniques. Un doublon non détecté, c'est du stock fantôme, des commandes inutiles et une consommation pièces qui ne correspond plus à la réalité terrain.

Comme le note Osapiens, "le plus grand défi de la migration CMMS est la standardisation — un technicien appelle la pompe 'Pompe #1 Principal', un autre 'P-101', et le CMMS les traite comme deux actifs différents." Le travail de normalisation du catalogue pièces représente souvent 20 à 30 % du temps total de préparation de la migration — et il est rarement anticipé dans les plannings initiaux.

Piège 4 — Transposer les workflows Coswin à l'identique dans Maximo

Coswin 8i et Maximo ont des logiques de workflow fondamentalement différentes. Dans Coswin, les circuits de validation des demandes de travaux et des bons de commande sont souvent configurés par accumulation de pratiques locales, sur plusieurs années. Dans Maximo, le moteur de workflow est plus structuré mais aussi plus exigeant : il faut modéliser les processus explicitement avant de les paramétrer.

Le piège est de vouloir reproduire à l'identique ce qui existait dans Coswin. Comme le documente Epsilon LLC, "le mode d'échec le plus courant est de démarrer par le logiciel plutôt que par les processus — les équipes configurent les types de work orders et les classifications avant d'avoir cartographié comment la maintenance fonctionne réellement dans l'organisation." Le second danger est la sur-configuration : activer des fonctionnalités parce qu'elles existent dans Maximo, pas parce que les opérations en ont besoin. Le résultat est un système plus complexe que Coswin, sans en être plus utile.

La règle à appliquer avant d'ouvrir le configurateur : documenter les processus critiques (demande → diagnostic → intervention → clôture → approvisionnement pièces) sur papier d'abord.

Piège 5 — Sous-estimer la résistance terrain des équipes formées sur Coswin

Un technicien qui utilise Coswin 8i depuis 8 ans ne change pas d'outil le jour du go-live. Ce n'est pas de la mauvaise volonté — c'est la mémoire musculaire d'un système qu'il maîtrise parfaitement. Et quand Maximo est présenté comme "le même outil en mieux", la déception est proportionnelle à l'écart ressenti.

Epsilon LLC documente que le taux d'adoption initial typique sur les projets Maximo atteint 30 à 40 % des utilisateurs cibles. Un cas documenté par OXMaint illustre précisément le problème : une organisation forme ses équipes lors d'une session classique de 3 heures couvrant 47 fonctionnalités — taux d'adoption à 30 jours : 22 %. La même organisation refait la formation en séances de 10 minutes, centrées sur 3 actions quotidiennes uniquement — taux d'adoption à 30 jours : 89 %.

Par ailleurs, les déploiements progressifs (périmètre pilote avant généralisation) améliorent l'adoption de 33 % par rapport aux déploiements big-bang (FTMaintenance). En Algérie ou au Cameroun, où les équipes ont souvent développé des habitudes très ancrées sur Coswin et où le turn-over est limité, cet écart est encore plus marqué.

Point terrain — Migration CMMS, industrie, Afrique centrale

Une société industrielle avait décidé de migrer 12 ans d'historique Coswin vers Maximo. L'audit des données réalisé en amont a identifié que 40 % des work orders ne comportaient pas de code équipement exploitable, et que le référentiel pièces contenait plus de 1 200 doublons sur 4 000 références. Le périmètre de migration a été ramené à 6 ans d'historique nettoyé et 60 % du catalogue pièces normalisé. La migration a pris 4 semaines supplémentaires — mais le système livré était utilisable dès le go-live.

FAQ

Peut-on migrer de Coswin 8i vers Maximo Application Suite (MAS) directement, sans passer par Maximo 7.6.x ?

Une migration directe vers MAS est techniquement possible, mais rarement recommandée comme premier pas depuis Coswin. MAS introduit une nouvelle architecture (cloud ou on-premise sur OpenShift), un nouveau modèle de licences et une interface redessinée. Pour une organisation qui migre depuis Coswin, il est généralement préférable de stabiliser les processus sur Maximo 7.6.x avant d'envisager la bascule vers MAS — sauf si le projet démarre sur une infrastructure cloud déjà en place.

Faut-il tout migrer depuis Coswin ou peut-on repartir de zéro dans Maximo ?

Repartir de zéro est une option valide si l'historique Coswin est de mauvaise qualité. Dans ce cas, seuls la liste des actifs actifs et le catalogue pièces normalisé sont migrés. L'historique work orders reste dans Coswin, accessible en consultation pendant 12 à 18 mois. Cette approche est plus rapide au démarrage mais implique une rupture dans les données de fiabilité — à peser selon la qualité réelle des données existantes.

Combien de temps faut-il prévoir pour la phase de préparation des données ?

La phase d'audit, nettoyage et normalisation représente généralement 30 à 40 % du temps total du projet. Sur un projet de 6 mois, cela correspond à 6 à 10 semaines dédiées aux données — avant de toucher au paramétrage Maximo. C'est la phase la plus souvent sous-estimée dans les plannings initiaux présentés par les intégrateurs.

Coswin et Maximo peuvent-ils coexister pendant la transition ?

Oui, et c'est même recommandé. Maintenir Coswin en lecture pendant 6 à 12 mois après le go-live Maximo permet aux équipes de consulter l'historique des équipements sans interruption opérationnelle. La clé est de définir dès le départ une date de coupure claire : à partir de cette date, tous les nouveaux work orders sont créés dans Maximo uniquement.

Une migration Coswin → Maximo bien préparée produit un système opérationnel, adopté et utile. Une migration précipitée produit un Maximo que personne n'utilise, avec un historique inutilisable et des équipes qui reviennent à leurs fichiers Excel.

Le problème n'est pas Coswin, ni Maximo — c'est le temps investi dans la préparation des données et la modélisation des processus, dans les semaines qui précèdent la configuration.

Réservez une consultation de 45 minutes pour évaluer l'état de vos données Coswin avant de démarrer la migration.