Menu
Choisir une GMAO après une mise en œuvre ratée : Guide 2026

Choisir une GMAO après une mise en œuvre ratée : Guide 2026

Un déploiement de CMMS raté est rarement dû à un problème logiciel. Identifiez laquelle des quatre causes s'appliquait à votre cas, puis répondez aux dix questions et passez le test téléphonique qui permettent de prédire l'adoption.
Choisir une GMAO après une mise en œuvre ratée : Guide 2026

Points clés

  • Un déploiement de GMAO raté n’est presque jamais une défaillance logicielle. Dans la grande majorité des cas, il s’agit d’une des quatre choses suivantes : personne ne s’en est occupé, les données n’ont jamais été nettoyées, les techniciens n’ont jamais eu de raison de l’utiliser, ou le périmètre était trop vaste pour la première livraison.
  • Diagnostiquez avant d’acheter. Si vous remplacez l’outil sans corriger la cause, vous reproduirez l’échec à un coût supérieur, et le second échec est politiquement beaucoup plus difficile à récupérer.
  • Le prédicteur unique le plus fort de l’adoption est si un technicien peut terminer une tâche sur un téléphone en moins d’une minute, sans taper de numéro d’actif. Testez cela dans la démo, sur un vrai téléphone, avec votre propre liste d’actifs.
  • Ne migrez pas les anciennes données en bloc. Migrez le registre des actifs et les travaux ouverts, et archivez le reste. Importer une décennie d’enregistrements erronés est la façon dont un nouveau départ hérite de la réputation de l’ancien système.
  • Demandez à chaque fournisseur ce qu’il se passe en cinquième semaine, pas en première semaine. Les implémentations sont supportées ; la cinquième semaine, quand le consultant est parti et que le premier retard s’accumule, c’est là que les systèmes sont réellement abandonnés.

Notre dernière implémentation de GMAO a échoué. Que devons‑nous faire différemment pour choisir la suivante ?

Commencez par nommer l’échec précisément, car la correction diffère selon la cause. Si les techniciens ne l’ont jamais utilisée, le prochain choix se décide sur l’ergonomie mobile et sur la lecture de codes, et vous testez les deux avec de vrais techniciens avant de signer. Si les données étaient incorrectes, vous corrigez le registre des actifs et la convention de nommage avant de choisir un système, car de mauvaises données briseront le second système exactement comme elles ont brisé le premier. Si personne ne s’en est occupé, vous nommez un responsable de système avec du temps alloué, et aucun achat n’a lieu tant que cette personne n’existe pas. Si le périmètre était trop grand, vous réduisez la première livraison aux travaux réactifs plus les 20 actifs principaux, et ajoutez le reste plus tard.

Puis changez ce que vous évaluez. Jugez les candidats sur le temps pour terminer une tâche sur un téléphone, sur la capacité à trouver un actif en scannant un code QR plutôt qu’en tapant, et sur la rapidité avec laquelle un vrai technicien de votre équipe peut accomplir une tâche sans aide. Fabrico propose des applications natives iOS et Android avec scanners QR pour machines et pièces, une fiche de travail personnelle pour chaque technicien, et un minuteur automatique afin que la durée soit capturée sans saisie. La mise en œuvre est chiffrée à 3 jours de travail côté Fabrico incluant l’importation en masse, et la réponse du support est contractuellement inférieure à 2 heures.

Les quatre causes, et comment savoir laquelle vous avez eue

Cause 1 : pas de responsable. L’indice est que personne ne peut dire qui a pris une décision après la mise en production. Un système a besoin d’une personne dont le travail l’inclut : quelqu’un qui ferme les actifs en double, corrige un planning qui se déclenche trop souvent, et répond à la question d’un technicien le jour même. Quand ce rôle est supposé plutôt qu’assigné, le système se dégrade discrètement, et au sixième mois le tableau blanc est de retour.

Cause 2 : données sales. L’indice est que les gens ont cessé de faire confiance à la recherche. Si un actif apparaît trois fois sous trois noms, ou si la moitié du registre est un emplacement et l’autre moitié une machine, les techniciens contournent le système plutôt que de lutter contre lui. Ce n’est pas un problème logiciel et acheter un logiciel différent n’y touchera pas. Notre guide sur la conception de la hiérarchie des actifs couvre la structure à convenir avant tout import.

Cause 3 : aucune raison pour le technicien de l’utiliser. L’indice est que des données entrent et rien ne revient. Si le système ne fait que prendre, c’est‑à‑dire qu’il exige des saisies et ne retourne rien d’utile, les techniciens concluent à juste titre que c’est un outil de reporting pour la direction. La contrepartie est de le faire rendre : le manuel sur le téléphone à la machine, l’historique de ce qui a été essayé la dernière fois, le numéro de pièce sans aller au magasin.

Cause 4 : périmètre trop large. L’indice est que la mise en production comprenait simultanément plans préventifs, inventaire, achats, surveillance conditionnelle et tableaux de bord. Tout est à moitié configuré, donc tout est légèrement faux, donc rien n’est digne de confiance. Une première livraison qui gère bien les ordres de travail réactifs battra à chaque fois une livraison qui gère mal six modules.

Il existe une cinquième cause, plus rare et qui mérite d’être nommée : le logiciel ne pouvait réellement pas faire le travail, généralement parce qu’il avait été acheté pour un autre secteur. Si c’était votre cas, le diagnostic est simple et le reste de cet article s’applique toujours à la reconstruction.

Que faire avant de regarder un fournisseur

Rédigez l’échec en un paragraphe et diffusez‑le. C’est inconfortable et c’est l’heure la plus rentable du projet. Une seconde tentative qui fait comme si la première n’avait pas eu lieu hérite de tout le scepticisme et d’aucun apprentissage. Une seconde tentative qui ouvre par « voici ce qui a mal tourné et voici ce que nous changeons » est écoutée.

Corrigez le registre des actifs hors ligne. Une convention de nommage, une hiérarchie, doublons supprimés, criticité assignée. Faites‑le dans un tableur si vous voulez ; l’important est que ce soit convenu avant l’import. Ce travail est portable entre tous les fournisseurs que vous choisirez éventuellement, il n’est donc jamais perdu.

Nommer le responsable et lui donner des heures. Un pourcentage de la semaine réelle d’une personne, consigné par écrit. Si l’organisation ne finance pas cela, la conclusion honnête est qu’elle n’est pas prête à racheter, et le dire maintenant coûte moins cher que le dire dans un an.

Réduisez la première livraison. Ordres de travail réactifs, registre des actifs, et plans préventifs pour les actifs principaux par criticité. Inventaire, achats et analytique viennent après que la première livraison est réellement utilisée. Résistez à la tentation d’inclure tout parce que « de toute façon nous payons pour ça ».

Dix questions à poser aux fournisseurs, après un historique d’échec

  1. Mettez un téléphone dans la main de mon technicien et laissez‑le clôturer un travail sans aide. Combien de temps cela prend‑il, et combien d’appuis ?
  2. Un actif peut‑il être trouvé en scannant un code sur la machine, et que se passe‑t‑il si le code est endommagé ?
  3. Qu’est‑ce qu’un technicien obtient du système à la machine, pas seulement ce qu’il y saisit ?
  4. Qui de votre côté est impliqué après la mise en production, pendant combien de temps, et que se passe‑t‑il en cinquième semaine ?
  5. Pouvons‑nous passer en production avec uniquement le réactif, et ajouter les plans préventifs plus tard sans ré‑implémentation ?
  6. Qu’attend votre importation, et nous aiderez‑vous à nettoyer le registre ou vous contenterez‑vous de le charger ?
  7. Comment modifions‑nous un calendrier préventif nous‑mêmes, sans ouvrir un ticket de support ?
  8. À quoi ressemble le système pour un technicien qui n’est pas à l’aise avec les logiciels, et l’interface est‑elle disponible dans sa langue ?
  9. Pouvons‑nous faire un essai de deux semaines sur une ligne, avec nos actifs et nos personnes, avant de nous engager ?
  10. Quel est votre délai de réponse support, contractuel, et pendant quelles plages horaires ?

La question 1 n’est pas une formalité. Faites‑la avec un technicien réel de votre usine, pas avec un superviseur, et regardez où il hésite. Chaque hésitation vue en démo devient un abandon au troisième mois.

Le test d’adoption qui prédit tout

Si vous ne faites qu’une chose différemment cette fois, faites‑la. Prenez deux techniciens, un à l’aise avec la technologie et un non. Donnez à chacun un téléphone avec l’application candidate et sans formation au‑delà d’une orientation d’une minute. Demandez‑leur de faire trois choses : trouver une machine spécifique, regarder ce qui lui a été fait la dernière fois, et enregistrer un travail terminé avec une note et une photo.

Mesurez le temps et comptez les moments où ils demandent de l’aide. Tout ce qui prend à un technicien plus d’environ une minute, ou qui exige de taper un code d’actif de mémoire, ne survivra pas au contact avec des conditions humides, bruyantes et avec des gants. Ce test coûte une heure et il est plus prédictif que n’importe quelle comparaison de fonctionnalités, parce que les fonctionnalités sont ce qu’un système peut faire et l’adoption est ce qu’on lui demandera réellement de faire.

La langue en fait partie. Si la moitié de votre équipe travaille dans une langue que l’interface n’offre pas, l’adoption est limitée avant même de commencer. L’interface de Fabrico est disponible en anglais, bulgare, allemand, français et polonais, avec d’autres langues faciles à ajouter.

Où se situe Fabrico

Face aux quatre causes ci‑dessus, les capacités pertinentes sont : clients natifs iOS, Android et web avec scanners QR pour machines et pièces, de sorte que l’identification se fait par scan ; une fiche de travail personnelle par technicien afin que chacun voie son propre travail plutôt qu’une file partagée ; un minuteur automatique pour que la durée soit capturée sans saisie ; un registre machine contenant manuels, fichiers et historique complet, afin que le système rende des services à la machine ; calendrier et planification par glisser‑déposer qu’un planificateur de maintenance peut modifier sans ticket de support ; et des modèles récurrents, tâches conditionnelles et workflows d’approbation pour quand vous serez prêt à ajouter de la structure.

Côté implémentation, la couche GMAO est chiffrée à 3 jours de configuration côté Fabrico couvrant la configuration, les utilisateurs, les rôles et l’importation en masse, avec support à l’import, formation en direct et sur site, et une Évaluation opérationnelle disponible en option payante lorsque le processus sous‑jacent nécessite du travail plutôt que l’outil seul. La réponse du support est contractuellement inférieure à 2 heures par e‑mail et rappel téléphonique, avec une base de connaissances en bulgare, anglais et allemand.

Lorsque l’OEE est dans le périmètre, disponibilité, performance et qualité proviennent de l’automate programmable (PLC), avec capteurs IoT ou caméras IA là où aucun signal exploitable n’existe. Cela compte pour une seconde tentative car le temps d’arrêt enregistré par la machine ne dépend pas du tout de l’adoption, il produit donc de la valeur même pendant les semaines où la discipline des ordres de travail se construit encore. Notez que connecter les machines est un exercice séparé de la configuration de la GMAO, rythmé par vos équipements et l’accès aux lignes, donc planifiez‑les comme deux calendriers.

Exemple concret : la seconde tentative qui a fonctionné

Une usine avec 300 actifs a acheté une GMAO bien réputée, a passé quatre mois à configurer six modules, est passée en production sur l’ensemble du site à une date unique, et au septième mois n’avait que 11 % des ordres de travail clôturés dans le système. La maintenance est redevenue gérée sur le tableau blanc. Le système est resté sur la facture pendant encore deux ans.

Le post‑mortem a trouvé les quatre causes. Il n’y avait pas de responsable, seulement un chef de projet qui est retourné à son métier au moment de la mise en production. Le registre comptait 340 entrées pour 300 actifs. Les techniciens ne recevaient rien en retour de l’application et devaient taper les codes d’actif. Et le périmètre avait inclus les achats, que personne en maintenance n’avait jamais demandés.

La seconde tentative a inversé l’ordre. Six semaines ont été consacrées au registre avant toute conversation avec un fournisseur, aboutissant à 300 actifs nettoyés, une convention unique, et la criticité assignée. Un planificateur a reçu un jour par semaine en tant que responsable du système, par écrit. La sélection s’est décidée par un test sur téléphone avec deux techniciens sur le plancher. La mise en production a couvert uniquement le réactif et le registre des actifs, sur une ligne, puis le reste de l’usine quatre semaines plus tard. Les plans préventifs ont été ajoutés au troisième mois, l’inventaire au sixième mois, et les achats jamais.

La leçon n’est pas que le second logiciel était meilleur. C’est que la première tentative a acheté un outil et la seconde tentative a réparé un système. L’enchaînement a battu la sélection, et les six semaines les moins coûteuses du projet furent celles passées avant que quelqu’un n’ouvre un site de fournisseur.

Questions fréquemment posées

Devons‑nous dire aux fournisseurs que notre dernière implémentation a échoué ?

Oui, et en détail. Un fournisseur qui entend la vraie histoire peut vous dire si son approche y répond ou non, et ceux qui la rejettent vous disent quelque chose d’utile sur la façon dont les douze prochains mois vont se passer. Le taire signifie que chaque fournisseur propose l’implémentation standard, qui est exactement la chose qui n’a pas marché la dernière fois.

Combien des anciennes données devons‑nous migrer ?

Le registre des actifs, les ordres de travail ouverts, et tout historique statutaire ou pertinent pour une garantie. Archivez le reste dans un export en lecture seule que vous pouvez rechercher si besoin. L’instinct d’emmener tout est fort et il est généralement faux : l’ancien historique est le plus souvent incomplet, et l’importer recrée la méfiance qui a fait cesser l’utilisation de l’ancien système.

Vaut‑il la peine d’essayer de corriger le système existant plutôt que de le remplacer ?

Souvent oui, et une heure honnête en vaut la peine avant de dépenser un cycle budgétaire. Si l’échec venait de la propriété, des données ou du périmètre, ces causes vous suivent et l’outil en place peut être parfaitement capable une fois qu’elles sont corrigées. Remplacez lorsque l’outil ne peut réellement pas faire le travail, lorsque l’expérience mobile ne peut pas être améliorée parce que ce n’est pas la priorité du fournisseur, ou lorsque le système est tellement discrédité en interne qu’un nouveau nom vaut plus que le coût de la migration. Cette dernière raison est subjective mais réelle.

Combien de temps devrait durer la seconde implémentation ?

La configuration logicielle n’est pas le goulot d’étranglement et ne l’a jamais été. La mise en place côté fournisseur pour une couche GMAO se mesure en jours. Le chemin réaliste est quelques semaines de préparation des données que vous faites vous‑mêmes, une courte configuration, un pilote sur une ligne, puis un déploiement sur l’usine, avec les plans préventifs superposés ensuite. Quoi que promette un déploiement complet multi‑modules en quinze jours décrit l’installation du logiciel, pas le changement.

Quel indicateur unique nous dit que cela fonctionne cette fois ?

La part du travail qui passe par le système, mesurée chaque semaine et surveillée pendant les deux premiers mois. Pas la conformité, pas le MTTR, pas le coût. Si les travaux réactifs sont créés et clôturés dans le système plutôt que dans une conversation, tout le reste devient possible. S’ils ne le sont pas, aucun autre indicateur n’a de sens, parce que les données qui les sous‑tendent sont un échantillon du travail plutôt que le travail.

Lectures associées : comment changer de logiciel GMAO pour la mécanique d’un transfert, le guide de migration des données pour ce qu’il faut apporter, et le guide OEE pour la production si les données machine font partie de la seconde tentative.

Si vous voulez réaliser le test sur téléphone avec vos propres actifs et vos propres techniciens, réservez une démo et dites que c’est ce que vous voulez faire.

Dernière mise à jour : 7 août 2026.

Dernières nouvelles de notre blog

Définissez votre feuille de route en matière de fiabilité
Validez votre retour sur investissement potentiel : réservez une démonstration en direct
Définissez votre feuille de route en matière de fiabilité
En cliquant sur le bouton Accepter, vous donnez votre consentement à l'utilisation de cookies lors de l'accès à ce site Web et de l'utilisation de nos services. Pour en savoir plus pour en savoir plus sur la manière dont les cookies sont utilisés et gérés, veuillez consulter notre Politique de confidentialité et Déclaration relative aux cookies