Quand on gère des équipements, des audits et des interventions sur plusieurs sites, la ressaisie devient vite un frein. Une connexion GMAO API REST évite ce doublon et remet la donnée au bon endroit.
Le gain ne se limite pas au confort. On améliore la qualité des historiques du logiciel de maintenance, on réduit les écarts entre terrain et système, et on fiabilise les décisions de maintenance. Pour que ça marche, il faut cadrer le métier avant de coder le premier appel.
Points clés
- Une connexion GMAO API REST à LPS Manager évite la ressaisie, améliore les historiques et fiabilise les décisions de maintenance.
- Définir un référentiel partagé clair (sites, équipements en GMAO ; audits, rapports en LPS) avant de coder, pour éviter les pièges courants.
- Mapper les flux simplement : GMAO pousse les références, LPS renvoie les résultats terrain, via une approche phasée en 6 étapes.
- Assurer la durabilité avec monitoring des erreurs, propriétaires métier/IT et métriques clés comme le taux d’échec des échanges.
- Le code vient après le métier : un cadre métier solide rend l’intégration fluide et pérenne.
Pourquoi relier la GMAO à LPS Manager change le quotidien
Dans beaucoup d’organisations, dans le système d’information, la GMAO assure la gestion des actifs, les plans de maintenance préventive, l’ordre de travail et les indicateurs. De son côté, LPS Manager centralise le cycle de vie des protections foudre, avec les dossiers d’installation, les vérifications, les audits, les rapports et, selon le périmètre retenu, les alertes météo et foudre.
Sans passerelle, on finit avec deux vérités qui cohabitent mal. Une inspection est clôturée dans un outil, mais pas dans l’autre. Un site change de responsable, pourtant l’information ne suit pas partout. À petite échelle, on compense à la main. À dix sites, on perd du temps. À cent, on perd le fil.
La bonne nouvelle, c’est que LPS Manager met en avant cette logique d’échange de données dans son guide sur la connexion d’un CMMS au logiciel de gestion foudre. On retrouve la même idée dans l’écosystème LPS, avec les fiches produit, le wiki, le blog et les démonstrations vidéo de la chaîne LPS CEMASO, qui aident à bien poser le vocabulaire métier.
Le vrai intérêt de la connexion API REST, ce n’est pas d’avoir deux outils reliés pour le principe. C’est d’orchestrer un flux simple et utile. La GMAO garde souvent la main sur les références patrimoniales et les ordres d’intervention. LPS Manager porte la logique foudre, les objets métier dédiés, les contrôles et les rapports associés.
Une intégration utile ne commence pas par le code. Elle commence par une donnée de référence claire et partagée.
Quand on pose ce cadre dès le départ, on évite la plupart des projets qui patinent. Et on sait aussi ce qu’on attend de chaque système, sans brouiller les responsabilités.
Ce qu’il faut verrouiller avant d’ouvrir l’API
Avant toute chose, on doit décider quel outil fait foi pour chaque donnée. C’est la règle la plus importante dans une intégration ERP. Si la GMAO reste maître des sites, des équipements et des codes actifs, LPS Manager doit consommer ces références sans les réinventer. À l’inverse, si LPS Manager devient la source des audits foudre ou des événements liés à la conformité, la GMAO doit les récupérer sans les transformer à l’excès.
Une intégration fiable repose sur un schéma de flux compris par la maintenance et par l’IT.
Ensuite, on prépare le dictionnaire de données pour assurer l’interopérabilité. Dans la pratique, il faut aligner les noms, les identifiants, les dates, les statuts et les pièces jointes en format JSON. Ce travail paraît basique, pourtant c’est lui qui bloque le plus souvent. Un « site » dans la GMAO n’est pas toujours une « installation » côté LPS. Un « contrôle périodique » peut correspondre à un audit, à un événement, ou à un rapport selon l’usage réel.
Il faut aussi traiter trois points techniques tôt dans le projet : l’authentification, les droits et le rythme d’échange. Les pages publiques de LPS Manager mentionnent une API REST et une documentation dédiée. En revanche, les détails disponibles publiquement restent limités au moment où on écrit ces lignes. On a donc intérêt à valider rapidement avec l’équipe LPS les endpoints ouverts, les méthodes HTTPS pour l’accès et le niveau de service attendu. La page Développeurs / IT team de LPS Manager confirme d’ailleurs cette logique d’ouverture vers des intégrations applicatives, y compris avec des environnements techniques plus larges.
Enfin, on ne mélange pas tous les flux d’un coup. Une première phase réduite marche mieux, particulièrement pour un déploiement multi-sites. Par exemple, on peut démarrer avec les installations, puis ajouter les audits, puis les rapports. Cette montée progressive limite les régressions et donne des repères clairs à la maintenance.
Méthode concrète pour connecter la GMAO à LPS Manager via API REST
Le plus simple est d’écrire le projet comme un flux métier, pas comme un projet purement informatique. Autrement dit, on part des événements réels, puis on traduit cela en appels API via des web services.
Ce tableau donne une base de mapping utile avant le développement :
| Donnée côté GMAO | Donnée côté LPS Manager | Sens du flux le plus fréquent |
|---|---|---|
| Site, bâtiment, zone | Installation | GMAO -> LPS Manager |
| Actif ou repère technique | Équipement rattaché à l’installation | GMAO -> LPS Manager |
| Plan de contrôle | Audit planifié | GMAO -> LPS Manager |
| Compte rendu d’intervention | Événement, rapport, résultat d’audit | LPS Manager -> GMAO |
| Alerte ou anomalie | Événement à traiter | LPS Manager -> GMAO |
On voit vite l’idée centrale : la GMAO pousse le référentiel utile, puis LPS Manager renvoie la donnée métier produite sur le terrain.
On peut ensuite dérouler une méthode simple en six étapes.
- On fixe d’abord un périmètre métier étroit, avec un ou deux types de données comme la maintenance corrective et un petit groupe de sites.
- Puis on définit un identifiant unique partagé, car sans clé commune, aucune synchronisation des données ne tient.
- Ensuite, on documente les statuts attendus, avec leurs règles de passage et leurs dates de référence.
- On construit après cela les appels API REST nécessaires, lecture, création ou mise à jour, en définissant les paramètres de requête selon le sens du flux.
- On teste sur des cas réels, y compris les erreurs, les doublons, les champs vides et les pièces jointes.
- Enfin, on passe en production avec journalisation, reprise sur incident et tableau de suivi.
À cette étape, beaucoup d’équipes veulent tout automatiser en temps réel. Ce n’est pas toujours le meilleur choix. Un échange planifié toutes les heures ou toutes les nuits suffit souvent au début, sans impliquer de données en temps réel ni de flux automatisés complexes. Il réduit la complexité et permet de valider le modèle sans bruit inutile. Si le besoin terrain l’impose, on affine ensuite la fréquence ou le mode d’appel.
Il faut aussi prévoir la reprise. Une API tombe, un réseau coupe, un jeton d’authentification expire via le protocole OAuth, un champ change. Si on ne gère pas ces cas, la passerelle marche un mois, puis elle s’use. On met donc en place des règles simples : journal des appels, code d’erreur lisible, tentative de relance, et alerte quand le volume d’échecs dépasse un seuil normal.
Si l’équipe travaille avec des profils francophones et anglophones, le guide en anglais sur la connexion d’une CMMS via API REST peut aussi servir de support commun. Ce type de ressource aide à aligner l’IT, l’OT et la maintenance autour d’une même logique d’échange.
Ce qui fait tenir l’intégration dans la durée
Une connexion réussie le jour du démarrage n’est qu’un début. Pour la garder saine, on doit nommer un propriétaire côté métier et un propriétaire côté technique. Le premier valide les règles de gestion. Le second surveille les flux, les versions et les erreurs. Si personne n’endosse ce rôle, les écarts reviennent vite.
La sécurité des données demande aussi une discipline simple, alignée sur la certification ISO 27001. On limite les droits de l’API au strict besoin. On stocke les secrets proprement. On trace qui a fait quoi, surtout si les données servent à des vérifications, des audits ou des rapports liés aux protections contre la foudre. Cette traçabilité compte autant pour l’exploitation que pour la conformité.
Autre point souvent sous-estimé, le contrôle des changements. Une nouvelle version de la GMAO SaaS, un champ ajouté dans LPS Manager, l’intégration de capteurs IoT, un statut renommé, et le flux dérive sans bruit. On gagne donc à maintenir un document de mapping vivant, relu à chaque évolution. Le wiki, le blog, la bibliothèque d’API et les supports vidéo de l’écosystème LPS sont utiles ici, car ils rappellent le sens métier derrière les connecteurs métiers.
Enfin, on mesure la performance opérationnelle avec peu d’indicateurs, mais les bons. Le taux d’échec des échanges, le délai de mise à jour, le nombre de ressaisies supprimées et le nombre d’écarts de statut suffisent souvent. Si ces quatre points s’améliorent, la connexion remplit son rôle.
Questions fréquentes
Pourquoi connecter la GMAO à LPS Manager via API REST ?
Cette connexion élimine la double saisie entre gestion des actifs et cycle de vie des protections foudre. Elle synchronise sites, audits et rapports, réduisant les écarts terrain-système. Le gain porte sur la qualité des données et la fiabilité des décisions.
Quelles données synchroniser en priorité ?
Commencez par les références comme sites et équipements (GMAO → LPS), puis plans d’audit et résultats d’intervention (LPS → GMAO). Utilisez un identifiant unique partagé pour aligner les dictionnaires de données. Une phase étroite limite les risques.
Comment gérer les erreurs et la reprise d’intégration ?
Implémentez journalisation des appels, relance automatique et alertes sur seuils d’échecs. Prévoyez les cas comme expiration OAuth ou réseaux coupés. Un échange planifié (horaire ou nocturne) suffit souvent au démarrage.
Qui doit superviser l’intégration à long terme ?
Désignez un propriétaire métier pour valider les règles et un technique pour les flux/versions. Maintenez un mapping vivant et mesurez via taux d’échec, délais et ressaisies supprimées. Alignez IT, OT et maintenance autour des ressources LPS.
Quelle fréquence d’échange choisir ?
Évitez le temps réel au début : toutes les heures ou nuits planifiées pour valider sans complexité. Affinez ensuite si le terrain l’exige. Cela réduit les régressions lors des déploiements multi-sites.
Conclusion
Quand on connecte une GMAO à LPS Manager via API REST, on ne branche pas seulement deux logiciels. On met en place une chaîne de confiance entre le patrimoine, le terrain et la preuve de maintenance.
Le facteur décisif reste le même du début à la fin : un référentiel clair, avec des rôles bien posés et un flux limité au juste besoin. Le code vient après.
Si la donnée circule proprement, on gagne du temps, on réduit les erreurs et on atteint l’interopérabilité pour une maintenance qui s’appuie sur des faits, pas sur des ressaisies.
