Cas d’école · BTP · ERP Nexxio
Retour d’expérience sur un SI où Nexxio pilote les commandes et une application interne pilote les interventions d’entretien — et où une mauvaise intégration aurait rendu la donnée inutilisable.
Dans beaucoup d’environnements BTP, les outils sont déjà en place :
Sur le papier, chaque outil fait son travail.
Dans la réalité, la donnée circule mal.
Une commande existe dans l’ERP, mais :
👉 Résultat : ce n’est pas un problème technique.
C’est une chaîne métier qui devient incohérente.
Quand une commande ERP est mal intégrée dans votre application métier, les effets sont immédiats :
👉 Le problème n’est pas la ressaisie.
👉 Le problème, c’est que la donnée n’est plus fiable pour piloter.
L’objectif n’est pas de dupliquer Nexxio.
👉 L’objectif est de réutiliser les bonnes données, au bon moment, sans casser la logique métier interne.
Une approche classique consiste à :
👉 Problème :
👉 Résultat : une base « remplie »… mais inutilisable.
La synchronisation repose sur une API Nexxio, mais l’API seule ne fait rien. Ce qui fait la différence, ce sont les règles métier.
Chaque commande Nexxio est analysée avant import.
👉 Le bailleur doit exister dans l’application métier (SIRET, actif et connu). Sinon : commande ignorée, aucune intervention créée.
Objectif : éviter des interventions isolées ou incohérentes.
Deux cas : si la commande n’existe pas → création ; si elle existe déjà → mise à jour.
Identifiant Nexxio conservé, lien stable commande ↔ intervention.
👉 Pas de doublons, historique propre, synchronisation fiable dans le temps.
Toutes les données Nexxio ne sont pas importées. Sont alignés notamment : montants, dates, adresses chantier, marché, factures, statuts.
👉 Parce que ce sont ces données qui impactent valorisation, facturation et suivi opérationnel.
Les statuts Nexxio ne correspondent pas toujours à la logique interne.
👉 Couche de mapping : alignement ERP / métier, cas particuliers, cohérence côté équipes.
Exemples : certains blocs sous-traitants ou avancés Nexxio non utilisés ou pas encore stabilisés côté métier.
👉 Ne pas complexifier la synchronisation inutilement.
Période donnée, exécution automatique, rejou si nécessaire — avec visualisation avant import, contrôle administratif et possibilité de reprise.
👉 Garder la maîtrise du flux, pas le subir.
👉 La synchronisation ne « remplit pas une base »
👉 Elle préserve la chaîne métier
Une intégration ERP → application métier n’est pas un sujet uniquement technique.
C’est un sujet de :
👉 Une mauvaise synchronisation propage des erreurs
👉 Une bonne intégration les bloque à la source
ERP (Nexxio, EBP…), outil métier interne, données chantier / interventions / facturation — et vous constatez des écarts, des statuts incohérents ou des doutes sur la donnée ?
👉 On peut analyser vos flux existants et identifier où la donnée se dégrade, quelles règles métier manquent, et comment sécuriser la synchronisation.