Comment réussir la migration d’une GMAO legacy vers une solution Full Web ?

Un lundi, à 7 h 10, le seul PC qui fait tourner la vieille GMAO est en panne, et personne ne sait lancer un bon de travail ailleurs que dans cet atelier.

Pour réussir la migration d’une GMAO legacy vers une solution Full Web, il faut auditer l’existant, trier les données à reprendre, valider le paramétrage sur un périmètre pilote, basculer avec une cohabitation courte, puis accompagner les équipes. La technologie web accélère le déploiement ; la qualité des données et l’adoption décident du résultat.

Une GMAO « legacy » est un logiciel client-serveur installé sur des postes ou des serveurs internes, souvent ancien, peu mis à jour, dépendant d’une personne ou d’un prestataire qui en connaît les rouages. Elle fonctionne encore, et c’est précisément ce qui retarde la décision. Jusqu’au jour où une mise à jour de système d’exploitation, un départ à la retraite ou un nouveau site la rend intenable.

Cet article ne refait pas le choix d’un logiciel : il part du moment où la décision est prise. Il s’adresse aux responsables maintenance et aux administrateurs GMAO qui doivent transférer des années de mémoire technique sans casser la production. Nous détaillons les pièges réels, puis une méthode en étapes, avec les points de contrôle qui évitent les mauvaises surprises.

1. Pourquoi une migration de GMAO échoue-t-elle le plus souvent ?

Une migration échoue souvent pour des raisons autres que techniques : elle échoue parce qu’on transporte de mauvaises données vers un outil que personne n’a adopté. Quatre pièges reviennent systématiquement.

1.1 Le piège du « copier-coller » intégral

Reprendre toute la base existante sans tri reproduit les défauts de l’ancien système dans le nouveau. Des équipements démontés depuis des années, des doublons de fournisseurs, des gammes jamais exécutées, des libellés libres du type « pompe 2 bis » : tout migre, et l’outil neuf paraît aussi confus que l’ancien. Un avis tranché : la migration est la seule occasion de nettoyer sans conflit, il serait absurde de la gâcher.

1.2 L’historique sacralisé

Beaucoup d’équipes exigent de reprendre dix ans de bons de travail « au cas où ». Or un historique n’est utile que s’il est exploitable : rattaché au bon équipement, avec une cause de panne lisible. Un historique mal structuré pollue les indicateurs comme le MTBF et fausse les décisions de remplacement. On distingue donc l’historique à migrer en données actives de celui à archiver en consultation.

1.3 La dépendance à une seule personne

Dans beaucoup de sites, une seule personne comprend les tables, les macros et les états sur mesure de l’ancien outil. Si elle n’est pas associée dès le cadrage, des règles implicites disparaissent à la bascule : un calcul d’échéance particulier, un code de criticité maison, une alerte envoyée par un script oublié.

1.4 L’adoption traitée comme une formalité

Une GMAO parfaitement paramétrée peut échouer si les techniciens remplissent les bons de travail à la va-vite ou pas du tout. Les données deviennent fausses et les indicateurs mentent. Sur ce point, une migration comporte un risque particulier : les équipes ont des habitudes, parfois des contournements bien rodés, et voient arriver le changement comme une contrainte de plus.

Ces quatre pièges ont un point commun : ils se préparent avant le premier import. D’où une méthode qui commence par un audit, pas par un calendrier de bascule.

2. Comment auditer l’existant avant de migrer ?

L’audit de l’existant consiste à inventorier ce que fait réellement l’ancienne GMAO, pas ce qu’elle est censée faire. Il se mène en trois temps.

2.1 Cartographier les usages réels

Listez les fonctions effectivement utilisées : demandes d’intervention, préventif, stocks, achats, tournées, états réglementaires. Puis relevez les contournements : tableurs parallèles, fiches papier, messageries utilisées pour ordonnancer les urgences. Chaque contournement révèle un besoin que l’ancien outil ne couvrait pas, et que le nouveau devra traiter ou supprimer.

2.2 Qualifier les données par famille

Pour chaque famille de données, posez une seule question : sert-elle à décider ou à justifier ? Voici une grille simple de décision.

• Référentiel équipements : à migrer après nettoyage (arborescence, localisation, constructeur, criticité).
• Plans préventifs en vigueur : à migrer et à revoir, car c’est le cœur de la valeur du nouvel outil.
• Stocks de pièces et fournisseurs : à migrer après dédoublonnage et vérification des références.
• Historique des interventions : à migrer sur une profondeur utile aux indicateurs, le reste à archiver.
• Documents (notices, plans, certificats) : à rattacher aux équipements, pas à empiler dans un dossier.

2.3 Identifier les dépendances techniques

Une GMAO legacy est rarement isolée : elle échange avec l’ERP, la comptabilité, la GTC, parfois un outil de pointage. Recensez chaque flux, son sens et sa fréquence. C’est aussi le bon moment de redéfinir qui est propriétaire de quelle donnée : le sujet est détaillé dans notre article sur GMAO et ERP. Les échanges de données du nouvel outil passent par des interfaces et API qu’il faut spécifier tôt, car elles conditionnent souvent le planning.

3. Que migrer, que transformer, que laisser derrière soi ?

Une migration réussie ne reproduit pas l’ancien système : elle transforme les données pour qu’elles servent le nouveau modèle. Trois traitements distincts s’appliquent.

3.1 Restructurer l’arborescence des équipements

L’arborescence conditionne tout : coûts par équipement, historique, criticité, rattachement des gammes. Profitez de la bascule pour la rendre cohérente : une logique site, ligne, machine, sous-ensemble, appliquée de la même façon partout. Sur un parc hétérogène, une codification unique évite que chaque atelier invente son vocabulaire.

3.2 Réécrire le préventif plutôt que le recopier

Le module préventif d’une GMAO est très souvent sous-exploité : d’après notre expérience terrain, les paramétrages avancés sont souvent peu activés. Recopier à l’identique les anciennes gammes revient à rater cette opportunité. Passez-les en revue : une tâche jamais exécutée est soit inutile, soit mal planifiée. Pour hiérarchiser, appuyez-vous sur une analyse de criticité ; l’outil AMDEC gratuit permet de coter vite les équipements, avec une gravité cotée sur une échelle de criticité, ce qui parle immédiatement au terrain. La méthode complète est décrite dans notre guide pour construire un plan de maintenance préventive.

3.3 Décider du sort de l’historique

Gardez en base active ce qui alimente les indicateurs de fiabilité et la preuve réglementaire. Le reste peut être archivé dans un format consultable (PDF, tableur horodaté) et référencé depuis la fiche équipement. La règle pratique : si personne n’a consulté une donnée depuis des années, elle n’a pas besoin de vivre dans le système actif.

Un exemple d’ampleur donne la mesure du chantier : 180 000 bons de travaux migrés en six mois chez Le Creuset, sans interrompre la maintenance industrielle. Le volume n’est pas l’obstacle ; le cadrage et la discipline de bascule le sont.

4. Quelle méthode suivre pas à pas ?

La méthode la plus sûre procède par étapes courtes, avec un point de validation à chaque palier, et non par une bascule unique. Voici une séquence éprouvée.

1. Cadrer le périmètre et la gouvernance. Nommez un propriétaire des données, un référent par site ou par atelier, et un chef de projet côté éditeur. Fixez ce qui est dans le périmètre initial et ce qui viendra ensuite.
2. Préparer les données. Extraction, nettoyage, dédoublonnage, codification. Cette étape prend presque toujours plus de temps que prévu : réservez-lui la plus grande part du planning, pas une ligne annexe.
3. Paramétrer le nouvel outil. Workflows de demande et de validation, profils, statuts, types de travaux, causes de panne. Restez sur du paramétrage standard autant que possible et réservez la personnalisation à ce qui a une vraie valeur métier.
4. Importer sur un jeu d’essai. Faites au moins un import complet à blanc, contrôlez les volumes, les rattachements, les échéances préventives recalculées. Chaque erreur trouvée ici est une erreur de moins en production.
5. Lancer un pilote. Un site, un atelier ou une famille d’équipements, avec des utilisateurs volontaires. L’objectif est de tester le terrain, pas de prouver que tout est parfait.
6. Corriger, puis généraliser. Ajustez les écrans, les libellés, les droits. Déployez ensuite par vagues.
7. Clôturer l’ancien système. Passage en lecture seule à date fixe, archivage, puis arrêt.

Cette progressivité est un atout du mode Full Web : l’absence d’installation sur chaque poste permet d’ouvrir de nouveaux utilisateurs plus rapidement. Les enseignements croisés de plusieurs déploiements sont synthétisés dans nos 10 bonnes pratiques pour structurer un projet de GMAO.

4.1 Cas particulier : plusieurs sites, plusieurs outils

Quand chaque site tourne sur sa propre GMAO, la migration est aussi l’occasion d’uniformiser. Sans centralisation multi-sites, chaque site finit par fonctionner avec sa propre logique et ses propres urgences, ce qui fausse les décisions globales. On commence alors par définir un socle commun (codification, statuts, indicateurs), puis on déploie site après site. Le sujet de fond est traité dans notre article sur la maintenance multi-sites.

5. Comment réussir la bascule sans perdre la maintenance en cours ?

La bascule réussit quand la date de coupure est claire, la fenêtre courte, et les travaux en cours repris dans le nouvel outil avant la reprise d’activité. Quelques règles pratiques.

5.1 Traiter les travaux en cours

Les bons de travail ouverts, les préventifs échus ou à échéance proche, les commandes en attente : ce sont les trois flux qui trahissent une bascule mal préparée. Faites un état des lieux la veille, décidez ce qui se clôture avant, ce qui se recrée après, et qui s’en charge nommément. Vérifiez surtout que les échéances préventives sont recalculées à partir de la dernière réalisation effective, et non de la date de migration, sinon des visites reportées « de fait » créent un trou de couverture.

5.2 Prévoir un plan de repli

Gardez l’ancien système accessible en lecture, conservez une extraction complète datée, et préparez une procédure papier pour les urgences de la première semaine. Ce n’est pas un aveu de faiblesse : c’est ce qui permet de tenir la bascule en confiance, y compris sur un site fonctionnant en continu ou la nuit.

5.3 Surveiller les premiers jours

Pendant les premiers jours, mesurez des signaux simples : nombre de bons de travail créés par jour comparé au rythme habituel, part de bons clôturés avec cause renseignée, retours des techniciens. Une chute brutale du volume saisi ne signifie pas moins de pannes : elle signifie que des interventions se font hors outil. Un suivi du taux de réalisation du préventif dès la première période complète indique rapidement si le planning migré est réaliste.

6. Comment obtenir l’adhésion des techniciens ?

L’adhésion se gagne en présentant la GMAO comme un outil de fiabilité des équipements, pas de surveillance des personnes. Les résistances viennent surtout de la peur du contrôle, de la surcharge administrative et d’un langage trop complexe.

6.1 Simplifier avant de former

Trop de champs, de boutons et d’écrans découragent le technicien qui saisit entre deux tâches. Il faut distinguer paramétrage et personnalisation, différencier les écrans par profil et structurer l’interface selon la temporalité d’action : ce que l’on fait à l’ouverture d’un bon, pendant l’intervention, à la clôture. Pour aller plus loin, voyez comment adapter les écrans à chaque profil.

6.2 Associer les équipes dès le pilote

Un technicien qui a contribué à nommer les statuts, à choisir les causes de panne ou à tester l’application mobile défend l’outil au lieu de le subir. Les leviers de fond sont détaillés dans notre article sur la conduite du changement auprès des techniciens.

6.3 Penser terrain dès le départ

Si l’ancien outil imposait de revenir au bureau pour saisir, le gain le plus visible de la migration sera la saisie sur le lieu de l’intervention. Dans les environnements où le réseau disparaît, par exemple les terrains irréguliers de l’extraction, l’application doit fonctionner hors ligne ; c’est le cas de la version mobile d’Altair Enterprise, utilisable en ligne ou hors ligne. Autre détail pratique souvent oublié : les tablettes utilisées en environnement de maintenance exigeant nécessitent une coque de protection renforcée.

Reste que cette autonomie sur le terrain ne dit rien de l’endroit où vos données sont stockées ni de la manière dont elles se synchronisent une fois le réseau revenu. Or ce choix d’infrastructure conditionne la disponibilité de l’outil le lundi à 6 h comme la charge qui pèsera sur votre service informatique. Pour trancher en connaissance de cause, voici une analyse des critères de choix entre GMAO SaaS et serveur interne.

7. Pourquoi le Full Web change-t-il les règles de la migration ?

Le Full Web supprime l’installation sur les postes et déplace l’effort vers les données et l’organisation, ce qui rend la migration plus rapide à déployer mais pas moins exigeante. Une application Full Web est accessible depuis un simple navigateur ; la technologie Full Web évite les déploiements poste par poste, les versions disparates et les conflits avec le système d’exploitation.

7.1 Ce que cela simplifie

• Ouverture rapide de nouveaux utilisateurs ou de nouveaux sites, sans intervention sur chaque poste.
• Mises à jour centralisées, qui mettent fin aux versions qui divergent d’un atelier à l’autre.
• Accès à distance pour les responsables, les sous-traitants et les équipes en déplacement.
• Pilotage plus facile d’une montée en charge progressive, du premier équipement au multi-sites.

7.2 Ce que cela ne résout pas

Le Full Web ne nettoie pas les données et ne convainc personne à votre place. Les gains d’une GMAO dépendent de la conduite du changement : adoption des équipes, qualité des données et gouvernance. Un exemple de passage d’un outil client-serveur vers une solution web et mobile est présenté dans le cas du passage d’une GMAO client-serveur vers le Full Web chez Federal Mogul, avec une équipe de maintenance couvrant le 24 h/24.

8. Quels indicateurs suivre après la migration ?

Après la bascule, trois familles d’indicateurs disent si la migration tient ses promesses : qualité de saisie, discipline de planification, résultat sur les équipements.

• Qualité de saisie : part des bons clôturés avec cause, temps passé et pièces renseignés. Sans cela, aucun autre indicateur n’est fiable.
• Discipline de planification : taux de réalisation du préventif et ratio entre préventif et correctif.
• Résultat technique : disponibilité, MTBF et MTTR, comparés à la situation d’avant lorsqu’elle était mesurée. Si elle ne l’était pas, ne faites pas de comparaison trompeuse : fixez un point zéro après trois à six mois de saisie propre.

Le Calculateur KPI illimité aide à poser un langage commun dès les premières semaines, avant même que les tableaux de bord de la GMAO soient entièrement calibrés. Prévoyez aussi une revue à trois mois pour ajuster le paramétrage : ce n’est pas un échec de la migration, c’est sa phase de réglage normale.

Questions fréquentes

Peut-on migrer si l'éditeur de l'ancienne GMAO ne fournit plus d'export ?

Oui, mais il faut passer par la base de données elle-même. Demandez au moins un accès en lecture à la base ou un dump, faites établir le dictionnaire des tables par votre DSI ou un prestataire, puis extrayez équipements, gammes et bons de travail dans des fichiers à plat. Si même cela est impossible, le recensement terrain des équipements critiques et la reprise des seuls plans préventifs en vigueur restent une base de départ acceptable. Mieux vaut le savoir tôt : c’est la première question à poser lors du cadrage.

Que faire des anciens utilisateurs et de leurs droits d'accès ?

Ne recopiez pas les comptes à l’identique. Profitez de la migration pour supprimer les comptes dormants, regrouper les droits par profil (technicien, responsable, demandeur, achats) et rattacher chaque personne à un périmètre précis. Un compte partagé de type « atelier » est à proscrire : il rend impossible la traçabilité des interventions. Conservez simplement une table de correspondance entre anciens et nouveaux identifiants pour que les historiques restent attribués aux bonnes personnes.

Combien de temps doit durer la cohabitation entre ancien et nouveau système ?

Le plus court possible, avec une date de fin annoncée dès le départ. Une cohabitation qui dépasse un cycle de planification complet de votre périmètre pilote crée de la double saisie, et la double saisie tue l’adoption. En pratique, on garde l’ancien outil en lecture seule pour l’historique et on interdit toute nouvelle écriture dessus après la bascule.

Faut-il geler la maintenance pendant la bascule ?

Non, et ce serait même risqué. La maintenance réglementaire et les interventions urgentes ne s’arrêtent pas. On choisit une fenêtre de bascule courte, de préférence en période calme, on fige les créations de bons de travail dans l’ancien outil quelques heures, et on prévoit une procédure papier de secours pour les urgences, ressaisies ensuite dans le nouvel outil.

Comment convaincre une direction qui juge la GMAO actuelle « suffisante » ?

Chiffrez ce que coûte le statu quo plutôt que de vanter la nouveauté. Listez les contournements actuels : exports manuels, ressaisies, indicateurs recalculés sous tableur, accès impossible depuis le terrain ou à distance. Convertissez ces heures en coût, puis simulez le gain avec un calculateur de ROI en posant des hypothèses prudentes. Un pilote court sur un périmètre limité achève généralement de convaincre.

Conclusion

Migrer une GMAO legacy, c’est transférer une mémoire technique vers un outil plus ouvert, sans la dégrader en route. La réussite tient à des choix simples : auditer avant d’importer, trier au lieu de tout reprendre, réécrire le préventif, piloter un pilote avant de généraliser, et traiter l’adoption comme un chantier à part entière. Le mode Full Web accélère le déploiement ; il ne remplace ni la rigueur des données ni la confiance des techniciens.

Si vous préparez ce chantier et souhaitez en discuter avec une équipe qui l’a mené sur de nombreuses installations, vous pouvez obtenir une démo d’Altair Enterprise et évoquer votre périmètre avec un chef de projet.