Sur r/assetmanagement, une question simple a lancé un échange dense entre professionnels de la maintenance : une GMAO peut-elle échouer à réduire la maintenance réactive ? La première réponse, signée u/InigoMontoya313, tranche sans détour : « Une GMAO n'est pas une solution garantie pour réduire la maintenance réactive, et quiconque prétend le contraire raconte n'importe quoi. Une GMAO ne crée pas une culture de maintenance proactive, ne fournit pas les ressources pour être proactif, ni les méthodologies de gestion adaptées. Tout cela vient d'ailleurs. »
Ce n'est pas un point de vue isolé. C'est le fil conducteur de toute la discussion, portée par des gens qui vivent la maintenance industrielle au quotidien — y compris, fait rare et précieux, un commercial d'un éditeur de GMAO qui confirme le diagnostic depuis l'autre côté du comptoir.
Le piège du pompier permanent
La formule la plus marquante du fil vient de u/MYK_Maintenance, et elle résume à elle seule pourquoi tant d'équipes achètent un logiciel sans jamais sortir du curatif : « Le piège, c'est que vous êtes trop occupés à éteindre des incendies pour construire ce qui empêcherait les incendies de se déclarer. » Une équipe qui passe ses journées à réparer des pannes n'a, par définition, jamais le temps de s'arrêter pour analyser pourquoi ces pannes reviennent. Le logiciel peut bien exister, tant que personne n'a la capacité de s'en servir pour autre chose que documenter l'urgence du jour, rien ne change structurellement.
Alerter n'est pas agir
Un deuxième commentateur, u/GovTechVeteran, pointe une distinction que beaucoup de dirigeants oublient au moment d'acheter un logiciel : « Être alerté qu'une machine doit être entretenue, et faire réellement le travail, sont deux choses différentes — et la GMAO ne peut pas être tenue responsable d'un échec si les ressources pour répondre à l'alerte ne sont pas là. Que ce soit un manque de personnel ou de matériel, ce manque de ressources fera échouer une bonne GMAO à chaque fois. La maintenance proactive reste le travail des humains, pas du système. »
C'est un point souvent négligé dans les argumentaires commerciaux autour des GMAO : le logiciel peut planifier, notifier, historiser. Il ne peut pas envoyer quelqu'un faire l'intervention à la place de l'équipe. Un troisième commentaire, plus court, va dans le même sens : u/Conrad_noble résume la cause racine en une phrase — « Sous-effectif, ou mauvaise gestion des ressources. »
Le vrai problème, que même un vendeur de GMAO admet
Le commentaire le plus instructif du fil vient d'un endroit inattendu : u/eWorkOrders-CMMS, qui se présente explicitement comme travaillant côté éditeur de GMAO. Sa franchise mérite d'être citée en entier : « Je précise que je suis côté éditeur, donc à pondérer en conséquence — mais j'ai entendu ça très souvent, et la plupart du temps ce n'est pas le logiciel le problème. Un point dont on ne parle pas assez, c'est la planification. Les équipes chargent toutes leurs maintenances préventives dans le système, mais elles ne bloquent jamais le temps pour les réaliser vraiment. Les préventifs se retrouvent à se disputer les mêmes heures que le reste, et les pannes gagnent à chaque fois. Sur le papier, tout le monde a l'air occupé parce que beaucoup d'ordres de travail se ferment, mais la conformité au préventif baisse en silence. Quelques mois plus tard, les mêmes machines recommencent à tomber en panne, et tout le monde se demande pourquoi on est encore en train d'éteindre des incendies. »
Un vendeur de logiciel qui admet publiquement que le logiciel n'est généralement pas le problème, c'est un signal rare et honnête. Ça rejoint exactement ce que nous défendons dans nos articles sur le choix d'un outil métier : un bon outil rend une bonne pratique possible, il ne la remplace pas.
Sur le papier, tout le monde a l'air occupé. Le vrai test n'est pas le nombre d'ordres de travail fermés, c'est si les mêmes machines continuent de tomber en panne trois mois plus tard.
Voyez comment Rotor-FSM facilite la consignation terrain, sans alourdir la journée.
Essayer Rotor-FSM gratuitementComment voler un peu de capacité, sans tout arrêter
La partie la plus utile du commentaire de u/MYK_Maintenance est la méthode concrète qu'il propose pour sortir du cycle, sans prétendre que ce sera facile : « Il faut voler un peu de capacité, même quand ça fait mal. Ce qui marche en général : commencer à tout consigner, même en réactif. Chaque panne — ce qui a lâché, quelle machine, combien de temps ça a pris. Faites ça pendant un mois et des motifs apparaissent généralement — souvent une poignée de machines responsables de la majorité de vos urgences. Elles deviennent vos premières cibles de maintenance préventive. Corriger les pires libère du temps, qui libère encore plus de temps. Ça s'accumule, lentement. Il vaut aussi le coup de suivre le ratio réactif contre planifié en pourcentage, pour voir concrètement s'il bouge. Difficile d'améliorer un chiffre qu'on ne regarde pas. »
C'est un conseil qui ne dépend d'aucun logiciel en particulier — mais qui devient beaucoup plus facile à suivre quand la consignation de chaque intervention, même urgente, ne demande pas de ressaisie le soir depuis un carnet. C'est précisément ce que nous détaillons dans notre article sur la gestion des interventions terrain : la fiche remplie sur place, pas reconstituée de mémoire des heures plus tard.
Un outil comme Rotor-FSM ne remplace pas la discipline décrite dans ce fil — voler du temps, consigner systématiquement, cibler les pires offenseurs. Ce qu'il change, c'est le coût de cette discipline : consigner une panne depuis le terrain, en quelques secondes, plutôt que d'espérer s'en souvenir en fin de journée.
Pourquoi une GMAO ne suffit-elle pas à réduire la maintenance curative ?
Parce qu'un logiciel peut alerter qu'une machine doit être entretenue, mais il ne peut pas faire le travail à la place de l'équipe. Si personne n'a le temps de traiter les alertes, la GMAO documente mieux le curatif, elle ne le réduit pas.
Comment sortir du cycle de la maintenance uniquement curative ?
En commençant par consigner systématiquement chaque panne, même en urgence : quelle machine, quelle panne, combien de temps. Après quelques semaines, des motifs récurrents apparaissent, et ce sont eux qu'il faut traiter en priorité pour dégager du temps.
Quel est le vrai signe qu'une équipe maintenance progresse ?
Ce n'est pas le nombre d'ordres de travail clôturés, mais l'évolution du ratio entre maintenance planifiée et maintenance réactive dans le temps. Un nombre élevé d'ordres clos peut cacher une maintenance préventive jamais réellement réalisée.
Rotor-FSM aide-t-il à sortir de ce cycle ?
Rotor-FSM facilite la consignation de chaque intervention, y compris réactive, directement depuis le terrain, pour que le suivi ne dépende pas d'une ressaisie le soir. C'est une condition nécessaire pour identifier les motifs récurrents, pas une solution magique au manque de ressources.
Aucun logiciel ne remplace la décision, difficile et volontaire, de voler du temps à l'urgence pour construire ce qui l'empêchera de se reproduire. Mais un outil qui rend cette consignation triviale, plutôt que pénible, retire au moins une excuse pour ne pas commencer.