Intégration ERP pour l’industrie : connecter SAP, Dynamics et Navision à l’atelier

Tout industriel exploitant à la fois un ERP et des systèmes d’atelier finit par se heurter au même écart. L’ERP affiche l’ordre comme terminé ; l’atelier sait que deux palettes ont été retouchées. L’ERP affiche une consommation matière à la quantité standard ; la consommation réelle incluait des rebuts que personne n’a saisis. Aucun des deux systèmes ne ment. Ils décrivent des instants différents — l’ERP décrit le plan et ses conséquences financières, l’atelier décrit la réalité physique — et l’intégration est la discipline qui maintient ces deux descriptions réconciliées.

La première décision de conception porte sur le sens de la propriété, et s’y tromper est la cause la plus fréquente des intégrations qui ne se stabilisent jamais. Les données de référence — clients, fournisseurs, articles, nomenclatures, gammes, prix — appartiennent à l’ERP et descendent. Les données d’exécution — heures réelles de début et de fin, quantités réellement produites, rebuts, motifs d’arrêt, états machine, affectations d’opérateurs, consommation matière réelle — sont générées en atelier et remontent. Quand les deux systèmes sont autorisés à modifier la même entité, vous n’avez pas une intégration ; vous avez une dispute récurrente assortie d’un planning de synchronisation.

Le flux descendant est en général la moitié la plus simple. Les ordres de fabrication lancés dans l’ERP apparaissent dans le MES avec leurs opérations, leurs gammes et leurs listes matière. Les modifications d’articles se propagent. Les données clients et livraisons atteignent les systèmes qui en ont besoin. La vraie difficulté pratique est la granularité : un ordre de fabrication ERP correspond souvent à plusieurs opérations d’atelier réparties sur différents postes de charge, et la correspondance entre la structure ERP et la structure exécutable doit être définie délibérément et non supposée.

Le flux montant est là où réside la valeur et où se concentre la difficulté. Les confirmations — les messages disant que cette opération a produit cette quantité, consommé cette matière, duré ce temps et rebuté ce volume — alimentent les chiffres de stock, de coût et de capacité de l’ERP. Quand elles sont captées automatiquement depuis les machines et les terminaux opérateurs au lieu d’être saisies de mémoire en fin d’équipe, les chiffres de l’ERP cessent d’être des approximations. Le calcul de coût s’améliore immédiatement, car les temps réels remplacent les temps standards.

Les schémas d’intégration disponibles diffèrent surtout par leur latence et leur couplage. L’échange de fichiers est simple, universellement supporté et inévitablement orienté batch. L’accès direct à la base est rapide et fragile, et casse aux montées de version des éditeurs de manière difficile à anticiper. Les API REST et SOAP — SAP via IDoc, BAPI ou OData ; Dynamics 365 et Business Central via leurs API publiées — sont le standard moderne et supportent bien mieux les changements de version. Les files de messages ajoutent de la résilience pour les événements à haute fréquence, car l’atelier continue de produire des données que l’ERP soit disponible ou non.

Ce dernier point mérite d’être souligné, car c’est là que les intégrations fragiles se révèlent. La production ne s’arrête pas quand l’ERP s’arrête. Si votre intégration est synchrone et que l’ERP est indisponible pour une maintenance planifiée, soit l’atelier s’arrête, soit les données sont perdues. Une conception avec file d’attente et tampon permet au MES de continuer à capter et de livrer l’arriéré au retour de la connexion — et dans une usine à plusieurs équipes, ce n’est pas un cas limite mais une réalité mensuelle.

Les ERP locaux et régionaux compliquent le tableau d’une manière spécifique. Les suites mondiales ont des interfaces documentées et de vastes écosystèmes d’intégration. Les produits régionaux — Panteon, Logo, Nebim et leurs équivalents sur d’autres marchés — sont très répandus chez les industriels de taille moyenne, souvent fortement personnalisés, et disposent rarement d’un connecteur MES sur étagère. Ce n’est pas une raison pour remplacer un ERP qui fonctionne. C’est une raison de traiter la couche d’intégration comme une composante à part entière du projet plutôt que comme un détail supposé acquis.

La réconciliation est la partie omise des plans de projet, qui consomme ensuite les trois premiers mois d’exploitation. Des messages échouent. Une confirmation est rejetée parce qu’une matière était bloquée. Un ordre de fabrication est supprimé dans l’ERP alors que l’atelier l’a déjà démarré. Toute intégration a besoin d’une file inspectable, d’un mécanisme de reprise, d’un état d’erreur qui alerte un humain, et d’un rapport de réconciliation périodique prouvant que ce que l’atelier a enregistré et ce que l’ERP détient concordent toujours. Les intégrations qui en sont dépourvues ne tombent pas bruyamment ; elles dérivent en silence, ce qui est pire.

Le conseil de cadrage qui résiste à la réalité : commencer par un type d’ordre sur une ligne, prouver l’aller-retour complet — lancement ERP, exécution en atelier, confirmation de retour dans l’ERP — et n’élargir qu’ensuite. Les intégrations big bang menées simultanément sur tous les sites et tous les types d’ordres échouent d’une manière extrêmement difficile à diagnostiquer, car lorsque tout est neuf, rien ne peut servir de référence.