Un technicien attend depuis trois jours un roulement commandé dans l’ERP, que le magasin ne retrouve nulle part dans la GMAO, quand elle existe.
Ce scénario révèle l’enjeu réel de la question GMAO et ERP : il ne s’agit pas de choisir un logiciel contre l’autre, mais de décider quelle donnée vit où.
La GMAO et l’ERP répondent à deux logiques différentes. L’ERP gère les flux financiers, commerciaux et logistiques de l’entreprise. La GMAO gère le patrimoine technique : équipements, interventions, plannings, pièces et conformité. Dans la plupart des cas, il faut les deux, reliés par une interface ciblée.
Beaucoup de directions techniques se voient proposer, au moment d’un projet ERP, le « module maintenance » inclus dans la suite. L’argument est séduisant : un seul éditeur, une seule base, une seule facture. Sur le papier. Sur le terrain, la réalité est plus nuancée, et c’est ce que cet article détaille.
Nous écrivons ici depuis l’expérience de centaines d’installations de GMAO : ce qui fait réussir ou échouer l’articulation entre les deux outils tient rarement à la technique. Cela tient à la clarté des responsabilités entre le service maintenance, la finance et la DSI.
👉 L’essentiel à retenir
- Une GMAO et un ERP ne se substituent pas : l'ERP pilote les flux financiers et logistiques de l'entreprise, la GMAO pilote la vie des équipements et le travail des techniciens.
- Le module maintenance d'un ERP suffit rarement dès qu'il faut du préventif fin, du terrain mobile, de la criticité ou de la conformité.
- L'intégration la plus rentable échange peu de données : référentiel articles, fournisseurs, commandes, imputations analytiques, et non l'historique technique.
- Définir qui est maître de chaque donnée avant de coder la moindre interface évite les doublons et les indicateurs qui mentent.
- Le bon chemin est progressif : GMAO d'abord sur un périmètre pilote, interface ensuite sur les flux à plus forte valeur.
1. Quelle différence réelle entre une GMAO et un ERP ?
Une GMAO organise le travail de maintenance autour des équipements, alors qu’un ERP organise l’activité de l’entreprise autour des transactions. La différence tient au point de départ de chaque outil.
1.1 Deux objets métier distincts
L’objet central d’un ERP est la transaction : commande, facture, écriture comptable, mouvement de stock. L’objet central d’une GMAO est l’équipement, avec sa hiérarchie, son historique, ses gammes préventives, ses pièces et ses défaillances. Un ERP sait dire combien a coûté une pièce. Une GMAO sait dire pourquoi la pompe P-204 est tombée en panne trois fois en huit mois.
1.2 Deux utilisateurs différents
L’ERP est utilisé par des acheteurs, des comptables, des gestionnaires de stock, devant un poste fixe. La GMAO est utilisée par des techniciens entre deux interventions, souvent debout, parfois sans réseau. Cette différence dicte l’ergonomie : un écran trop chargé fait renoncer le technicien, et un bon de travail mal renseigné fausse tous les indicateurs derrière.
1.3 Une règle simple pour trancher
- Ce qui touche à l’argent et aux tiers (fournisseurs, commandes, factures, comptabilité analytique) : domaine de l’ERP.
- Ce qui touche à l’équipement et au geste technique (arborescence, gammes, bons de travail, rondes, criticité, historique de pannes) : domaine de la GMAO.
- Ce qui est partagé (références articles, centres de coût, stocks de pièces) : à arbitrer explicitement, donnée par donnée.
2. Le module maintenance de l’ERP suffit-il ?
Le module maintenance d’un ERP suffit lorsque le parc est réduit, les équipements peu critiques et les besoins limités à l’enregistrement des interventions et des coûts. Au-delà, il atteint vite ses limites fonctionnelles.
2.1 Les cas où il peut convenir
Une structure avec quelques dizaines d’équipements, des interventions essentiellement correctives et un technicien polyvalent peut s’en contenter. Le besoin est alors comptable : tracer le temps passé et les pièces consommées pour imputer les coûts. Dans ce cas précis, ajouter un outil supplémentaire peut être disproportionné.
2.2 Les signaux qui montrent qu’il ne suffit plus
- Le préventif devient un vrai programme : gammes, fréquences calendaires et d’usage, conditionnel, rondes de niveau 1. Pour structurer ce programme, on peut s’appuyer sur la démarche décrite dans notre guide pour construire un plan de maintenance préventive.
- Le terrain a besoin d’un outil mobile : saisie sur tablette, photos, consignes, fonctionnement hors ligne en zone sans couverture.
- La criticité guide les décisions : AMDEC, hiérarchisation des équipements, suivi des mesures de maîtrise des risques sur site Seveso.
- Les indicateurs doivent être exploitables : MTBF, MTTR, taux de réalisation du préventif, ratio préventif/correctif, sans retraitement sous tableur.
- Plusieurs sites travaillent sur le même référentiel et ont besoin de comparer leurs pratiques.
2.3 Mon avis tranché
Un module maintenance d’ERP est rarement pensé par des mainteneurs. Il se juge sur la cohérence du modèle de données, pas sur la brochure. La question à poser est simple : un technicien peut-il clôturer un bon de travail en moins d’une minute, sur le terrain, sans réseau ? Si la réponse est non, les données seront saisies tard, mal, ou pas du tout, et les indicateurs seront faux.
3. Quand faut-il intégrer les deux outils ?
L’intégration est pertinente quand la même information serait sinon saisie deux fois ou quand une décision de maintenance dépend d’un flux financier ou logistique. Elle devient indispensable dès que des pièces, des achats ou des centres de coût sont en jeu.
3.1 Les flux qui justifient une interface
- Référentiel articles et pièces de rechange : un seul code article, créé dans l’outil maître, repris dans l’autre.
- Fournisseurs : évitez deux fiches fournisseurs divergentes.
- Demandes d’achat et commandes : la GMAO exprime le besoin, l’ERP gère la validation et la commande. C’est le cœur du sujet pour qui veut bien gérer les achats MRO.
- Réceptions et mouvements de stock : la pièce reçue dans l’ERP doit devenir disponible pour le technicien.
- Imputations analytiques : le coût d’une intervention remonte vers le centre de coût ou l’affaire concernée.
- Ressources humaines : temps passés, absences, habilitations, selon le besoin.
3.2 Les flux qu’il vaut mieux ne pas synchroniser
L’historique technique détaillé, les gammes, les relevés de rondes ou les commentaires de diagnostic n’ont aucune raison d’aller dans l’ERP. Y copier tout l’historique crée du volume, de la latence et des conflits de mise à jour, sans valeur décisionnelle. L’interface idéale est maigre et robuste.
3.3 Ce que permet une architecture ouverte
Une GMAO moderne expose des webservices pour dialoguer avec les autres systèmes. Altair Enterprise propose cet interfaçage par webservices avec ERP, MES et RH, ce qui évite les doubles saisies et fait circuler les données dans les deux sens. Le sujet n’est donc pas la faisabilité technique, mais la définition précise de ce que l’on échange.
4. Comment décider qui est maître de chaque donnée ?
Chaque donnée partagée doit avoir un seul système maître, désigné avant le début du développement de l’interface. Sans cette règle, deux bases se contredisent en quelques mois.
4.1 La grille de gouvernance à remplir avant de coder
Pour chaque objet, répondez à quatre questions : qui le crée, qui le modifie, qui le supprime, et dans quel sens circule-t-il ? Un exemple de répartition courante :
- Article / pièce : créé dans l’ERP, enrichi techniquement dans la GMAO (équipements concernés, criticité, stock de sécurité).
- Équipement : créé et maintenu dans la GMAO ; l’ERP n’en conserve éventuellement que le rattachement comptable (immobilisation).
- Fournisseur : maître dans l’ERP.
- Bon de travail : maître dans la GMAO ; seul le coût consolidé remonte à l’ERP.
- Commande d’achat : maître dans l’ERP, déclenchée depuis une demande d’achat émise par la GMAO.
4.2 Le piège de la double vérité
Quand la finance voit un stock de pièces dans l’ERP et que le magasinier en voit un autre dans la GMAO, la direction ne sait plus lequel croire. Pire : chacun défend son chiffre. Une règle de réconciliation périodique et un maître unique par donnée suppriment l’essentiel de ces débats.
4.3 L’adoption terrain reste la condition de tout le reste
Une interface parfaite n’arrange rien si les techniciens remplissent leurs bons à la va-vite : les données qui montent vers l’ERP sont alors fausses. Les résistances viennent surtout de la peur du contrôle, de la surcharge administrative et d’un langage trop complexe. Le sujet est détaillé dans notre article sur les enjeux d’adoption côté techniciens. Une version mobile utilisable hors ligne aide à saisir au bon moment plutôt qu’en fin de poste.
5. Que montrent les déploiements qui ont relié GMAO et ERP ?
Les projets réussis partent d’un périmètre restreint et migrent les données utiles, pas toutes les données. Deux retours clients illustrent des situations très différentes.
5.1 Un groupe multi-usines avec de nombreuses liaisons ERP
Le cas Paprec et ses 30 liaisons ERP montre ce qui se passe quand un groupe de 15 à 20 usines synchronise ses données de maintenance avec ses systèmes de gestion. Le sujet n’est plus seulement technique : il faut gérer la réticence de collaborateurs et l’hétérogénéité des sites. Une gouvernance claire des données devient alors le vrai chantier. Pour la dimension organisationnelle, voir aussi notre article sur la maintenance multi-sites.
5.2 Une migration d’ampleur sans rupture de service
Le cas de la migration de plus de 180 000 bons de travaux chez Le Creuset rappelle un point souvent oublié : l’historique technique a de la valeur et doit être repris proprement, indépendamment de l’ERP. C’est la preuve qu’une GMAO peut être un socle autonome pour la mémoire technique.
5.3 Le point commun
Dans ces deux situations, la réussite vient de la même discipline : un périmètre défini, des responsables identifiés, et une reprise de données pensée comme un projet à part entière. L’outil est un moyen, pas la finalité. Les gains dépendent de la conduite du changement : adoption des équipes, qualité des données et gouvernance.
6. Comment bâtir l’argumentaire économique ?
Le bon argumentaire compare des coûts complets, pas des lignes de licence. Il met en regard le coût de l’indisponibilité, le temps perdu en double saisie et le coût d’un module insuffisamment adopté.
6.1 Les coûts à inclure
- Le coût direct : licences ou abonnement, intégration, formation, accompagnement.
- Le coût de la double saisie : prenons un cas à 10 techniciens, chacun perdant 20 minutes par semaine à ressaisir une information dans un second outil. Cela représente plus de trois heures par semaine, soit plus de 150 heures par an. Valorisées au coût horaire interne, elles justifient à elles seules une interface.
- Le coût de l’outil non adopté : un module que personne ne renseigne correctement fait payer des licences sans produire de pilotage.
- Le coût de l’arrêt non planifié : c’est lui qui pèse le plus lourd, et c’est précisément ce que la rigueur du préventif cherche à réduire.
6.2 Un chiffrage à faire soi-même
Plutôt que de croire un chiffre générique, simulez votre propre situation avec l’outil pour calculer le ROI de votre GMAO : saisissez vos coûts de maintenance, d’arrêts et de sous-traitance actuels. Vous aurez un ordre de grandeur de gains à présenter à la direction financière, avec ses propres hypothèses.
6.3 Le cas particulier des stocks de pièces
Le stock de pièces est le point où ERP et GMAO se chevauchent le plus. Si l’ERP gère la valorisation et la GMAO le besoin technique, il faut une règle claire. Pour comprendre ce que la GMAO apporte côté seuils critiques et alertes, consultez la page dédiée aux stocks et achats de la GMAO.
7. Quelle feuille de route adopter ?
La feuille de route la plus sûre procède par étapes : cartographier, prioriser par criticité, déployer sur un pilote, puis ouvrir les interfaces. Elle évite de bloquer la maintenance pendant que l’ERP se stabilise.
- Cartographier les flux existants : qui saisit quoi, où, avec quels doublons.
- Prioriser les équipements par criticité. L’outil AMDEC gratuit aide à coter la gravité en durée d’arrêt de production (moins d’1 h, 1 h à 1 jour, 1 jour à 1 semaine, plus d’1 semaine), ce qui parle immédiatement au terrain.
- Déployer la GMAO sur un périmètre pilote : un atelier, un site, une famille d’équipements.
- Fixer la gouvernance des données : maître par objet, responsable par donnée.
- Construire les interfaces à plus forte valeur : articles, achats, imputations. Pas davantage au départ.
- Mesurer et ajuster : qualité de saisie, taux de réalisation du préventif, délais d’approvisionnement.
Chaque étape peut s’appuyer sur un accompagnement structuré. Chez Altair Enterprise, chaque projet est suivi par un chef de projet dédié, et la solution modulaire permet de démarrer petit avant d’étendre, du premier équipement jusqu’au multi-sites.
Questions fréquentes
Peut-on commencer par une GMAO et brancher l'ERP deux ans plus tard ?
Oui, et c’est souvent la meilleure séquence. Une GMAO déployée seule sur un périmètre pilote prouve sa valeur et stabilise les données techniques. L’interface avec l’ERP se conçoit ensuite sur des flux précis. Il suffit de prévoir dès le départ des identifiants communs (code article, code fournisseur, centre de coût) pour que le branchement ultérieur ne demande pas de reprise lourde.
Une DSI peut-elle refuser une GMAO au motif qu'elle a déjà un ERP ?
Ce refus arrive, généralement par souci de simplifier le parc applicatif. L’argument à poser sur la table : la DSI garde la maîtrise des flux et de la sécurité grâce à une interface documentée, et le métier gagne un outil conçu pour le terrain. Un échange en amont sur l’architecture, les accès et la gouvernance des données lève la plupart des blocages.
Que faire si l'ERP est en cours de changement ?
Évitez de faire dépendre la GMAO d’une interface propriétaire à l’ERP sortant. Conservez dans la GMAO l’historique technique, qui est indépendant de la comptabilité, et reconstruisez les liaisons financières sur le nouvel ERP une fois son référentiel figé. Une GMAO indépendante joue alors le rôle de socle stable pendant la transition.
Les petites structures ont-elles intérêt à s'équiper d'une GMAO si elles n'ont pas d'ERP ?
Oui. L’absence d’ERP n’est pas un frein : une GMAO suffit à structurer interventions, stocks de pièces et planning. Elle couvre alors une partie des besoins de gestion de stock et d’achats liés à la maintenance. Une interface avec un logiciel comptable pourra être ajoutée plus tard si le volume de flux l’exige.
Conclusion
La bonne question n’est pas « GMAO ou ERP », mais « quelle donnée, dans quel outil, pour quel utilisateur ». L’ERP garde la main sur la finance, les achats et les tiers. La GMAO garde celle des équipements, des interventions et de la mémoire technique. Entre les deux, une interface sobre, bâtie sur un petit nombre de flux bien choisis, vaut mieux qu’une synchronisation totale. Et rien ne remplace des techniciens qui renseignent leurs bons de travail : sans cela, aucune architecture ne sauve vos indicateurs.
Si vous hésitez entre module d’ERP et GMAO dédiée, ou si vous voulez cadrer l’interface avec votre système existant, une démonstration sur vos propres cas d’usage est le moyen le plus rapide de trancher. Vous pouvez obtenir une démo pour examiner votre situation avec un expert.