Dans une usine, chaque ligne de production génère des données en continu : température de cuisson, pression d’injection, couple de serrage, vibrations de roulement, consommation électrique par équipement. Pendant des décennies, ces données sont restées confinées dans les automates et les systèmes SCADA, inaccessibles à l’ERP qui gérait les finances, les stocks et les commandes de l’autre côté du mur applicatif.
L’Industrial Internet of Things (IIoT) change cette équation. La promesse : faire remonter en temps réel les données physiques de l’atelier jusqu’à l’ERP, pour déclencher automatiquement des ordres de réapprovisionnement, calculer l’OEE (Overall Equipment Effectiveness) sans saisie manuelle, ou créer un ordre de maintenance avant la panne. Selon les données de Deloitte (2025), 46 % des industriels ont déjà déployé des solutions IIoT au niveau de leurs sites, mais beaucoup s’arrêtent à la couche de visualisation sans connecter les données à leur ERP.
Ce guide couvre le “comment” technique : l’architecture en couches, les protocoles (OPC-UA, MQTT), les connecteurs natifs des principaux éditeurs ERP, et les cinq étapes d’un projet de connexion IIoT-ERP réussi.
Pourquoi brancher l’IIoT directement à l’ERP (et pas seulement au MES)
La limite du silo MES : des données de production inexploitées par la finance et la supply chain
Le MES (Manufacturing Execution System) capte les données de production opération par opération : quantités produites, temps de cycle, taux de rebut, traçabilité lot/série. C’est son rôle. Mais le MES reste un outil d’atelier. Il ne sait pas que le client a besoin de sa commande pour la fin du mois, que la trésorerie est tendue sur ce produit spécifique, ou que le fournisseur du composant A est en rupture à J+5.
La vraie valeur de la connexion IIoT-ERP se joue dans l’exploitation croisée des données. Quand un capteur de niveau bas dans un silo de matière première déclenche directement un ordre de réapprovisionnement dans le module achats de l’ERP, la chaîne est automatisée de bout en bout. Quand la consommation électrique réelle d’un équipement remonte dans le module de calcul de coût de revient de l’ERP, le coût de production intègre la réalité énergétique et non une estimation budgétaire.
Le MES gère le flux de production. L’ERP gère la valeur créée par ce flux. Les brancher directement via l’IIoT, c’est supprimer le délai de consolidation et les ressaisies qui dégradent la qualité de la donnée financière.
Cas d’usage concrets : ce que la connexion directe rend possible
OEE en temps réel dans l’ERP. L’OEE combine disponibilité, performance et qualité d’un équipement. Calculé manuellement une fois par semaine, il sert de constat rétrospectif. Calculé en temps réel depuis les capteurs et affiché dans le tableau de bord ERP du responsable de production, il devient un levier de décision opérationnel.
Déclenchement automatique d’ordres de réapprovisionnement. Un capteur de poids sur un convoyeur détecte un niveau de stock en-dessous du seuil de sécurité. L’information remonte via le broker MQTT, traverse le gateway edge, et déclenche une demande d’achat dans l’ERP. Sans intervention humaine, sans fichier Excel intermédiaire.
Facturation à la consommation réelle d’énergie. Pour les industriels qui refacturent l’énergie à leurs clients (façonniers, prestataires de transformation), l’ERP peut intégrer la consommation électrique mesurée par machine et par ordre de fabrication dans le calcul de la facture. La marge réelle remplace la marge théorique.
L’architecture technique en 3 couches
La connexion IIoT-ERP ne se fait pas directement entre un capteur et un serveur d’application d’entreprise. L’ERP ne peut pas absorber des millions de messages bruts par seconde. L’architecture se structure en trois couches qui filtrent, agrègent et normalisent les données avant qu’elles n’atteignent l’ERP.
Couche 1 — les capteurs et automates (PLC, SCADA, capteurs IoT)
C’est la couche physique. Elle comprend :
- Les automates programmables (PLC) : Siemens S7-1500/S7-300, Schneider Modicon M580, Beckhoff CX2000. Ce sont les ordinateurs industriels qui commandent les actionneurs (vannes, moteurs) et lisent les capteurs (température, pression, position). Ils communiquent historiquement avec des protocoles propriétaires (Siemens S7comm, Modbus TCP, Profinet).
- Les capteurs IoT de nouvelle génération : capteurs sans fil LoRaWAN ou Zigbee pour la température ou l’humidité, capteurs de vibration sur roulements, compteurs d’énergie communicants. Ces capteurs ne passent pas par un PLC — ils publient directement via MQTT.
- Les systèmes SCADA : Ignition (Inductive Automation), Aveva System Platform, Siemens WinCC. Ces logiciels supervisent l’ensemble de l’atelier et agrègent déjà les données des PLC et capteurs.
Cette couche génère des données hétérogènes, dans des formats différents, à des fréquences allant de 100 ms (contrôle de processus) à 10 minutes (compteur d’énergie). L’enjeu de la couche suivante est de les uniformiser.
Couche 2 — l’edge gateway et le broker (OPC-UA, MQTT, Ignition)
C’est la couche d’intelligence locale. Elle s’exécute sur des serveurs physiquement présents dans l’usine (on parle de “edge computing” par opposition au cloud centralisé). Son rôle : collecter les données des équipements, les filtrer, les agréger, les normaliser, et les transmettre vers l’ERP ou vers un broker cloud.
OPC-UA (IEC 62541) est le protocole standard pour la communication entre équipements industriels hétérogènes. Publié par l’OPC Foundation et normalisé IEC 62541 (dont l’édition EN IEC 62541-1:2026 vient d’être finalisée), OPC-UA offre deux atouts décisifs pour l’intégration ERP :
- Interopérabilité multi-fabricant : un serveur OPC-UA lit indifféremment un PLC Siemens, un automate Schneider et un capteur Beckhoff, sans développement propriétaire.
- Modèle d’information structuré : les données ne sont pas des flux bruts mais des objets typés avec des unités, des horodatages fiables et des métadonnées de contexte (quelle machine, quel capteur, quel process). L’ERP peut les interpréter sans transformation.
MQTT (Message Queuing Telemetry Transport) est le protocole pub/sub léger adopté pour les capteurs à faible bande passante ou à connexion intermittente. Un capteur IoT sur batterie publie sa mesure sur un “topic” MQTT (par exemple usine/ligne3/capteur_niveau/valeur), et un broker MQTT (Mosquitto, HiveMQ, EMQX) redistribue ce message à tous les abonnés — dont le connecteur ERP. MQTT et OPC-UA ne sont pas concurrents : l’architecture moderne les combine, OPC-UA pour les données temps réel structurées depuis les PLC, MQTT pour les capteurs légers en périphérie.
Les middlewares edge industriels qui implémentent ces protocoles sont nombreux. Les plus cités en contexte ERP :
- PTC Kepware : agrégateur universel (600 drivers PLC) avec sortie OPC-UA et connecteurs SAP natifs
- Cogent Datahub : pont OPC-UA/MQTT avec filtrage et mise en cache
- Ignition (Inductive Automation) : plateforme SCADA + gateway IIoT avec module de connexion ERP
- Siemens MindSphere : plateforme IoT cloud Siemens, native pour les équipements Siemens, avec API REST vers l’ERP
Le choix du middleware dépend du parc machine existant, du budget et du niveau de compétence OT de l’équipe IT.
Couche 3 — le connecteur ERP (API REST/SOAP, ESB, connecteur natif éditeur)
C’est la couche qui fait entrer la donnée dans l’ERP. Trois approches coexistent :
API REST ou SOAP : la quasi-totalité des ERP modernes exposent des API. Le gateway edge appelle l’API ERP pour créer un ordre de maintenance, mettre à jour une quantité en stock ou enregistrer une mesure de contrôle qualité. Cette approche est générique mais exige de gérer la fréquence des appels (ne pas surcharger l’ERP avec 10 000 requêtes par minute).
Bus de messages / ESB : un Enterprise Service Bus (MuleSoft, IBM MQ, Apache Kafka) s’intercale entre le gateway edge et l’ERP. Il gère les files d’attente, les retry en cas d’indisponibilité ERP, et les transformations de format. Recommandé dès que plusieurs ERP ou plusieurs systèmes source sont impliqués.
Connecteur natif éditeur : SAP propose SAP Edge Services, IFS propose des connecteurs MQTT natifs dans IFS Cloud. Ces connecteurs sont optimisés pour leur ERP respectif, mais leur périmètre fonctionnel et leur modèle de licence varient. Détails dans la section suivante.
Connecteurs natifs par éditeur : ce qui est livré, ce qui est à développer
SAP S/4HANA : SAP Edge Services et SAP IoT
SAP propose deux briques pour l’intégration IIoT :
SAP Edge Services est un runtime léger déployé en local (sur site ou VMs edge) qui collecte les données OPC-UA des équipements, applique des règles de traitement locales et les transmet à SAP S/4HANA ou à SAP IoT. Il supporte les scenarios de maintenance prédictive et de suivi d’équipement. SAP Edge Services est inclus dans certaines éditions de RISE with SAP, mais les scenarios avancés relèvent souvent d’un add-on distinct — la vérification du périmètre exact avec l’account SAP est indispensable avant de dimensionner le budget.
SAP IoT Application Enablement (rebaptisé et intégré dans SAP BTP) permet de définir des objets connectés (une machine, un capteur) avec leurs propriétés et de brancher leurs données à des processus métiers SAP (PM — Plant Maintenance, PP — Production Planning). Le développement reste nécessaire pour mapper les topics MQTT ou les tags OPC-UA aux objets SAP.
Connexion concrète avec PTC Kepware : Kepware publie les données OPC-UA vers SAP PCo (Plant Connectivity), qui les transmet à SAP MII (Manufacturing Integration and Intelligence) ou directement à SAP S/4HANA via RFC/BAPI. SAP PCo est limité à 128 sources de données simultanées dans sa configuration standard — un point à vérifier pour les grandes usines multi-lignes.
IFS Cloud : IFS Connected Assets et connecteurs MQTT natifs
IFS Cloud intègre nativement le concept d’asset connecté via le module IFS Connected Assets. Ce module expose un broker MQTT embarqué qui reçoit les données des équipements (via des IoT agents déployés en edge) et les rattache automatiquement aux enregistrements d’actifs dans IFS. Quand un capteur de vibration dépasse un seuil, IFS crée automatiquement un work order dans le module maintenance sans développement additionnel.
C’est un point fort d’IFS pour les industriels dont la maintenance et la gestion d’actifs sont critiques (énergie, transport, manufacturing lourd). Le modèle d’information asset-centrique d’IFS s’aligne naturellement avec la logique des données IoT liées à un équipement physique.
Infor CloudSuite Industrial : Infor OS et les hooks d’intégration
Infor CloudSuite Industrial (anciennement SyteLine) s’appuie sur Infor OS comme couche d’intégration et d’orchestration. Infor OS expose des API REST et des connecteurs ION (Intelligent Open Network) pour l’intégration de données externes. La connexion à un gateway IIoT passe typiquement par un webhook ION ou une API REST appelée depuis le middleware edge.
Infor ne propose pas de broker MQTT natif aussi avancé qu’IFS. L’intégration IIoT avec Infor CloudSuite passe souvent par une couche middleware tierce (MuleSoft ou Kepware) qui transforme les données IoT en messages ION compatibles avec l’ERP.
Odoo et Dynamics 365 Business Central : connecteurs communautaires
Odoo (versions 16, 17 et 18) ne dispose pas de connecteur IIoT natif en standard. Des modules OCA (Odoo Community Association) existent pour la connexion MQTT et la création automatique d’ordres de maintenance, mais leur maturité est variable. Pour un usage industriel critique, un développement spécifique ou un middleware dédié reste nécessaire. L’avantage d’Odoo est son API REST bien documentée qui facilite l’intégration custom.
Dynamics 365 Business Central s’intègre à l’IIoT principalement via Azure IoT Hub (Microsoft). Les données des capteurs transitent par IoT Hub, sont traitées par Azure Stream Analytics ou Azure Functions, puis remontent dans Business Central via des API ou le connecteur natif Azure. Cette architecture full-Azure est cohérente pour les industriels déjà dans l’écosystème Microsoft, mais ajoute une dépendance cloud que certains DSI préfèrent éviter pour des raisons de latence ou de souveraineté des données.
Tableau comparatif synthétique :
| Éditeur ERP | Connecteur IIoT natif | MQTT natif | OPC-UA natif | Commentaire |
|---|---|---|---|---|
| SAP S/4HANA | SAP Edge Services + PCo | Via SAP BTP IoT | Via PCo | Add-on selon édition, vérifier le scope de la licence |
| IFS Cloud | IFS Connected Assets | Oui (broker embarqué) | Via IoT agents | Forte intégration native maintenance/assets |
| Infor CloudSuite Industrial | ION via API REST | Non natif | Non natif | Middleware tiers recommandé (Kepware, MuleSoft) |
| Odoo | Modules OCA (communauté) | Modules communautaires | Modules communautaires | Développement spécifique probable pour usage critique |
| Dynamics 365 BC | Via Azure IoT Hub | Via Azure | Via Azure | Architecture cloud-first, dépendance Azure forte |
Mise en oeuvre pratique : les 5 étapes du projet IIoT-ERP
Étape 1 — Inventaire des sources de données
Avant tout déploiement, cartographier exhaustivement les équipements, leurs protocoles de communication et la qualité de leurs données. Questions clés : Quels PLC sont déjà en réseau ? Lesquels sont en “îlot” isolé ? Quels capteurs existent et quels paramètres ils mesurent ? Quelle est la fréquence de mise à jour de chaque source ?
Cette étape révèle souvent des surprises : des automates vieux de 15 ans qui ne supportent pas Ethernet, des capteurs sans possibilité de sortie numérique, ou des protocoles propriétaires sans documentation publique. Les conclusions de l’inventaire conditionnent directement le budget de la couche edge.
Étape 2 — Choisir le protocole selon le cas d’usage
La règle de base est simple :
- OPC-UA pour les données structurées, temps réel fiable, depuis les PLC et SCADA. Idéal quand la sémantique de la donnée compte (quelle variable, quel équipement, quelle alarme).
- MQTT pour les capteurs à faible bande passante, les communications distantes (plusieurs bâtiments, réseau LoRaWAN), ou les environnements où la légèreté du protocole prime.
Dans la majorité des projets industriels, les deux protocoles coexistent. L’architecture dite “Unified Namespace” (espace de noms unifié) standardise tous les topics MQTT et tags OPC-UA dans une arborescence cohérente (entreprise/site/zone/équipement/variable), accessible à tous les consommateurs de données — ERP, MES, SCADA, analytics.
Étape 3 — Sélectionner la couche edge
Le gateway edge est le composant central du projet. Il doit être :
- Physiquement proche des équipements (latence réseau OT faible)
- Redondant (si le gateway tombe, les données s’arrêtent de remonter)
- Administrable à distance (mises à jour de firmware sans intervention physique)
Les options matérielles vont du PC industriel DIN-rail (Siemens IPC227, Moxa V2401) au serveur edge plus musclé pour des sites complexes. Les options logicielles : Kepware (Windows), Ignition Edge (Linux/Windows), ou des solutions cloud-native edge (AWS IoT Greengrass, Azure IoT Edge) pour les sites bien connectés.
Étape 4 — Cartographier les flux vers l’ERP
Chaque flux de données IIoT doit être mappé à un processus métier ERP précis :
| Source IIoT | Processus ERP cible | Objet ERP créé/mis à jour |
|---|---|---|
| Compteur de pièces en sortie de ligne | PP — Production Planning | Déclaration de production, mouvement de stock |
| Capteur de vibration sur roulement | PM — Plant Maintenance | Avis de maintenance préventive |
| Capteur de niveau silo matière | MM — Materials Management | Demande d’achat automatique |
| Compteur électrique par machine | CO — Controlling | Imputation coût réel énergie sur ordre de fabrication |
| Capteur température four de cuisson | QM — Quality Management | Enregistrement paramètre process pour traçabilité |
Ce tableau de mapping est le document de gouvernance du projet. Chaque ligne représente une interface à développer, tester et maintenir. Plus le périmètre est large, plus le projet est complexe — commencer par 2 ou 3 flux à forte valeur et s’étendre progressivement.
Étape 5 — Gouvernance et qualité des données IoT
Les données IoT ne sont pas parfaites. Les capteurs tombent en panne, les connexions réseau s’interrompent, les valeurs aberrantes (mesures parasites) surgissent. Sans gouvernance, ces imperfections se propagent dans l’ERP.
Points de vigilance à mettre en place :
- Détection des doublons : un message MQTT peut être reçu deux fois (at-least-once delivery). L’ERP doit dédupliquer avant de créer une transaction.
- Gestion des valeurs manquantes : si un capteur n’envoie pas de données pendant 5 minutes, l’ERP doit-il considérer la dernière valeur comme valide ou déclencher une alerte ?
- Alarmes de qualité capteur : l’OPC-UA porte nativement un indicateur de qualité (Good/Bad/Uncertain) associé à chaque valeur. L’ERP doit en tenir compte avant d’agir.
- Fréquence de rafraîchissement adaptée : inutile d’appeler l’ERP 10 fois par seconde pour mettre à jour un stock. Le gateway edge agrège et n’envoie qu’une transaction ERP toutes les 30 secondes ou à chaque changement d’état significatif.
ROI mesurable : les métriques à suivre
L’intégration IIoT-ERP se justifie par des résultats concrets, mesurables avant et après déploiement. Voici les trois métriques qui font consensus dans les retours d’expérience industriels.
Réduction des saisies manuelles
Chaque fois qu’un opérateur saisit manuellement une quantité produite, un résultat de contrôle ou une durée d’arrêt dans l’ERP, il y a un risque d’erreur et un délai. Une usine de taille moyenne avec 50 opérateurs peut consacrer 5 à 10 % du temps de production à la saisie de données. La connexion IIoT automatise cette saisie pour les données mesurables (quantités, paramètres process, consommations), libérant du temps opérateur pour des tâches à valeur ajoutée.
OEE amélioré et temps d’arrêt réduits
Selon les données consolidées par IoT Mag (2025), la maintenance prédictive pilotée par des capteurs IIoT réduit les arrêts non planifiés de 35 à 50 % et améliore l’OEE de 20 à 25 %. Un exemple documenté par Siemens (2024) sur une ligne de production montre une réduction du temps d’arrêt mensuel de 39 heures à 27 heures après intégration de capteurs de vibration connectés au système de maintenance.
Ces gains supposent que la chaîne complète est en place : capteur -> alerte -> ordre de maintenance dans l’ERP -> planification de l’intervention -> approvisionnement de la pièce de rechange. Si l’alerte reste dans le SCADA sans remonter à l’ERP, la maintenance préventive reste manuelle.
Précision du coût de revient réel
Le coût de revient calculé par l’ERP intègre souvent des hypothèses sur la consommation matière et l’énergie. Quand les capteurs IIoT fournissent les consommations réelles machine par machine, ordre par ordre, le contrôle de gestion dispose enfin d’une vision exacte de la marge produit. Les décisions de pricing et de mix produit s’en trouvent considérablement améliorées.
Le payback d’un projet IIoT-ERP bien scoped se situe typiquement entre 6 et 18 mois pour les équipements de production critiques, selon l’analyse de Faclon Labs (2025) sur un panel de projets manufacturiers.
Pièges et points de vigilance
La latence réseau OT vs. la fréquence ERP. Le réseau d’atelier (OT) peut avoir des latences très faibles (< 1 ms sur Profinet). L’ERP, lui, n’est pas conçu pour absorber des transactions à cette fréquence. La couche edge doit absolument agréger et filtrer : ne remonter à l’ERP que ce qui a changé de façon significative, pas chaque mesure brute. Sans ce filtre, l’ERP est saturé et les performances dégradées pour tous les utilisateurs.
La séparation OT/IT : l’ERP ne doit pas être directement exposé au réseau atelier. Le réseau OT (automates, capteurs, machines) est soumis à des contraintes de sécurité différentes du réseau IT (bureau, ERP, AD). La norme IEC 62443 (sécurité des systèmes d’automatisation et de contrôle industriels) recommande une segmentation stricte avec une DMZ industrielle entre les deux réseaux. Le gateway edge se situe dans cette DMZ — il collecte côté OT et publie côté IT, sans créer de flux direct entre les deux zones. Exposer l’ERP directement au réseau atelier est une faute de sécurité grave.
La gestion des firmwares capteurs et la compatibilité protocoles. Un capteur IoT déployé aujourd’hui pourra nécessiter une mise à jour de firmware dans 18 mois pour corriger une vulnérabilité. En milieu industriel, une mise à jour ne peut pas se faire en période de production. La gestion du cycle de vie des capteurs (firmware, compatibilité protocole, fin de support) doit être intégrée au contrat de maintien en condition opérationnelle (MCO) dès le démarrage du projet.
Le cadre normatif à respecter. En plus d’IEC 62443 pour la cybersécurité OT/IT, deux référentiels structurent les projets IIoT industriels en Europe : le programme Industrie du Futur en France (porté par l’Alliance pour l’Industrie du Futur, avec des aides publiques via BPI et les Régions) et RAMI 4.0 (Reference Architecture Model Industrie 4.0) en Allemagne, qui définit les couches de communication et d’information pour les usines connectées. Ces référentiels ne sont pas des contraintes réglementaires mais des guides d’architecture qui ont fait leurs preuves.
Pour aller plus loin
Ce guide couvre l’architecture de connexion IIoT-ERP. Pour compléter votre vision de l’usine connectée, trois lectures directement liées sur ce blog :
- ERP et industrie manufacturière : MES, IoT et Industry 4.0 — la vue d’ensemble MES et les flux ERP-MES en temps réel, base indispensable avant de déployer la couche IIoT.
- ERP et jumeaux numériques — la prochaine étape après la connexion IIoT : construire des modèles numériques des équipements pour la simulation et l’optimisation.
- ERP et lean manufacturing : Kanban, OEE, Kaizen — comment les méthodes lean exploitent les données en temps réel que la connexion IIoT rend accessibles.
