Choisir la bonne SIM M2M pour votre parc d'équipements IoT industriels est une décision structurante : couverture réseau, tarifs au volume, SLA, roaming international, sécurité APN, compatibilité LTE-M/NB-IoT et — point souvent négligé — la fin programmée de la 2G et de la 3G qui rend obsolètes des milliers de modems déjà déployés. Ce comparatif 2026, appuyé sur les données ARCEP les plus récentes, analyse les offres des grands opérateurs français, des MVNO spécialisés (1NCE, Tele2 IoT) et de la SIM multi-opérateurs, pour vous aider à faire un choix qui tienne sur 10 ans.
\nAvant le détail, voici les conclusions principales pour les décideurs pressés :
\nUne SIM M2M (Machine-to-Machine), aujourd'hui plus souvent appelée SIM IoT, est une carte SIM conçue spécifiquement pour les équipements industriels et connectés. Elle se distingue d'une SIM de smartphone sur presque tous les plans :
\n| Caractéristique | SIM grand public | SIM M2M IoT |
|---|---|---|
| Température de fonctionnement | 0 °C à +40 °C | −40 °C à +85 °C |
| Durée de vie | 2-3 ans | 10-15 ans |
| Format | Nano SIM (4FF) | Industriel 2FF/3FF soudable (MFF2), eSIM |
| Résistance | Standard | Vibrations, humidité, corrosion |
| Volume de données | Illimité (partage) | Faible (1 Mo - 5 Go/mois) |
| Roaming | « Roam Like Home » UE | Contrats M2M dédiés (≠ RLH) |
| APN privé | Non | Disponible |
| IP fixe | Non | Optionnelle |
| Monitoring | Non | Dashboard / API de flotte |
| eUICC (profil à distance) | Non | Disponible |
| Résiliation | Au mois | Contrats 12-36 mois |
Format SIM industriel : les gateways et routeurs IoT intègrent le plus souvent un slot SIM au format 2FF (mini-SIM, 25×15 mm) ou 3FF (micro-SIM), voire une eSIM soudée (MFF2) pour les environnements à fortes vibrations. À vérifier impérativement avant toute commande — un mauvais format immobilise tout un déploiement.
\n\n\nÀ retenir : une SIM M2M, ce n'est pas qu'un « forfait pas cher ». C'est un composant industriel pensé pour durer aussi longtemps que la machine qui l'héberge.
\n
La couverture est le premier critère d'une SIM M2M. Voici l'état réel du réseau, sur la base des données ARCEP du T4 2025 (publiées en mars 2026), plutôt que sur les arguments commerciaux des opérateurs.
\nGrâce aux obligations contraignantes du New Deal Mobile de 2018, les quatre opérateurs couvrent aujourd'hui plus de 99 % de la population française en 4G. La bataille ne se joue donc plus sur la population, mais sur :
\nPoint important pour la résilience d'un parc : SFR et Bouygues Telecom partagent une partie de leur réseau dans les zones les moins denses (accord de mutualisation dit « Crozon »). Concrètement, dans ces zones, choisir SFR ou Bouygues peut revenir à se connecter à la même antenne physique — ce qui réduit l'intérêt d'un failover entre ces deux-là et renforce l'intérêt d'une bascule incluant Orange (réseau indépendant). Free, de son côté, bénéficie d'une itinérance sur le réseau Orange dans les zones qu'il ne couvre pas encore.
\n| Bande | Fréquence | Usage IoT |
|---|---|---|
| B28 | 700 MHz | Longue portée, pénétration indoor, rural |
| B20 | 800 MHz | Couverture rurale, sous-sols |
| B8 | 900 MHz | Couverture étendue |
| B3 | 1800 MHz | Capacité urbaine, débit |
| B1/B7 | 2100/2600 MHz | Forte densité urbaine |
| n78 | 3,5 GHz (5G) | Très haut débit, zones denses |
Pour un capteur en sous-sol ou en zone rurale, ce sont les bandes basses (700/800 MHz) qui comptent — pas la 5G urbaine mise en avant en publicité.
\nC'est le sujet le plus sous-estimé d'un déploiement IoT en 2026, et il mérite une section dédiée.
\nConséquence directe : tout modem ou module IoT uniquement 2G (encore très répandu sur les anciens compteurs et alarmes) cessera de fonctionner dès l'automne 2026. Un module 2G/3G sans repli 4G deviendra muet vers 2028.
\nQue faire ?
\n\n\nConseil Eziwan : les gateways et la SIM Eziwan sont 4G/LTE-M avec repli, conçus pour traverser ces extinctions sans intervention sur site.
\n
Orange est l'opérateur historique avec la couverture la plus étendue, particulièrement en zones rurales et en outre-mer.
\nOffres M2M :
\nPoints forts :
\nPoints faibles :
\nTarifs indicatifs (data seule, hors options) :
\n| Volume / mois | Prix indicatif / SIM / mois |
|---|---|
| 1-5 Mo | 2-4 € |
| 50-100 Mo | 4-8 € |
| 500 Mo - 1 Go | 8-15 € |
SFR propose des offres M2M compétitives, avec un bon rapport qualité/prix sur les déploiements de volume et un système de pooling apprécié.
\nOffres M2M :
\nPoints forts :
\nPoints faibles :
\nTarifs indicatifs :
\n| Volume / mois | Prix indicatif / SIM / mois |
|---|---|
| 10 Mo | 1,50-3 € |
| 100 Mo | 3-6 € |
| 1 Go | 6-12 € |
Bouygues a fortement amélioré sa couverture et propose souvent les tarifs les plus bas du marché sur les volumes.
\nOffres M2M :
\nPoints forts :
\nPoints faibles :
\nTarifs indicatifs :
\n| Volume / mois | Prix indicatif / SIM / mois |
|---|---|
| 10 Mo | 1,20-2,50 € |
| 100 Mo | 2,50-5 € |
| 1 Go | 5-10 € |
Pour les applications basse consommation et faible débit (télérelève eau/gaz, géolocalisation d'actifs, capteurs environnementaux), le LoRaWAN est une alternative au cellulaire :
\n\n\nNote : l'écosystème LoRaWAN évolue (rachats, repositionnements d'acteurs). Vérifiez la pérennité du réseau et de l'offre commerciale avant un engagement long.
\n
1NCE propose un modèle radical : un paiement unique d'environ 10 $/12 € pour 500 Mo de données + 250 SMS valables 10 ans, sur le réseau Deutsche Telekom et ses partenaires (dont Orange en France), avec couverture dans 170+ pays. La SIM supporte 2G, 3G, 4G/LTE-M, NB-IoT et est annoncée « 5G-ready ».
\nPour :
\nContre :
\n\n\n1NCE est excellent pour des objets simples et sobres. Pour de la supervision industrielle, de l'accès distant VPN régulier ou de la vidéo, il faut une offre opérateur ou multi-opérateurs.
\n
Opérateurs européens spécialisés IoT, avec des offres multi-pays attractives pour les déploiements internationaux et une gestion de flotte mature.
\nSolutions eUICC / multi-IMSI permettant de basculer entre opérateurs selon la couverture, avec un cœur de réseau unifié — très adaptées aux déploiements dans plusieurs pays et pour éviter le verrouillage opérateur (vendor lock-in).
\nLa SIM multi-opérateurs (multi-IMSI / eUICC) est une carte capable de se connecter automatiquement à l'opérateur offrant le meilleur signal sur chaque site, et de rebasculer en cas de panne d'un réseau.
\n| Critère | SIM mono-opérateur | SIM multi-opérateurs |
|---|---|---|
| Couverture nationale | Opérateur-dépendant | Meilleure des 3 réseaux |
| Zone blanche d'un opérateur | Coupure | Basculement automatique |
| Panne réseau opérateur | Coupure totale | Repli sur un autre réseau |
| Résilience globale | Faible | Haute |
| Coût | Faible | Légèrement supérieur (+10-20 %) |
| Gestion | 1 contrat | 1 contrat multi-opérateurs |
| Roaming UE | Variable / option | Souvent inclus |
| Déploiement « à l'aveugle » | Risqué (couverture à vérifier site par site) | Sécurisé (le meilleur réseau est choisi sur place) |
Cas d'usage idéal : stations de pompage, parcs éoliens et solaires, sites agricoles, télérelève multi-sites, véhicules en déplacement, déploiements multi-pays, et tout site où vérifier la couverture opérateur par opérateur avant installation serait trop coûteux.
\n\n\nRappel « Crozon » : pour une vraie redondance, la bascule doit inclure Orange (réseau indépendant) et pas seulement SFR + Bouygues, qui partagent leur réseau en zones peu denses.
\n
La SIM Eziwan est une SIM M2M multi-opérateurs intégrée à nos offres :
\nL'APN privé (Access Point Name) crée un réseau virtuel dédié entre vos SIM et votre infrastructure cloud, sans transiter par l'internet public.
\n\nLe trafic ne transite jamais par l'internet public : tunnel dédié entre la SIM et le datacenter, IP fixe possible par SIM.\nAvantages de l'APN privé :
\nAPN public vs APN privé :
\n| APN public | APN privé | |
|---|---|---|
| Exposition internet | Oui | Non (tunnel dédié) |
| IP fixe | Rare | Possible |
| Isolation client | Non | Oui |
| Conformité NIS2 | Insuffisant seul | Recommandé |
| Surcoût | — | ~+1-3 €/SIM/mois |
Disponibilité : Orange, SFR et Bouygues proposent tous des APN privés ; la SIM Eziwan l'inclut nativement.
\nDimensionner le forfait au plus juste évite de surpayer (ou de tomber en rupture). Ordres de grandeur observés :
\n| Cas d'usage | Variables | Polling | Consommation mensuelle |
|---|---|---|---|
| Télérelève compteur | 3-5 | 15 min | 1-5 Mo |
| Station de pompage (automate M340) | 10-20 | 30 s | 10-50 Mo |
| Supervision énergie | 20-50 | 10 s | 50-200 Mo |
| SCADA multi-équipements | 100-500 | 1 s | 200-500 Mo |
| Vidéosurveillance 720p | — | Continu | 3-10 Go |
| Accès distant VPN (veille) | — | — | 5-20 Mo (keepalive) |
| Accès distant VPN (session 30 min) | — | — | 50-500 Mo selon activité |
Optimisation par l'edge computing : un gateway qui filtre les données localement (dead band, agrégation, compression) avant transmission réduit la consommation 4G de 70 à 95 %. Un site M340 à 30 variables peut passer de ~150 Mo/mois à 15-25 Mo/mois — soit, sur 500 sites, une bascule d'un forfait « 200 Mo » vers un forfait « 50 Mo » et une économie substantielle à l'échelle du parc.
\nPour les équipements déployés hors de France :
\nUnion européenne : attention, les offres M2M ne bénéficient pas automatiquement du « Roam Like Home » réservé aux forfaits grand public. Le roaming M2M relève de conditions contractuelles spécifiques : vérifiez systématiquement les clauses M2M de votre opérateur (volumes, durée de roaming permanent autorisée, restrictions de « permanent roaming »).
\nHors UE : la facturation au Mo peut être très élevée (de l'ordre de +0,5 à 2 €/Mo). Pour un déploiement international, préférez une SIM locale ou une SIM globale multi-IMSI (Eziwan, Tele2 IoT, Onomondo) qui négocie l'accès aux réseaux pays par pays.
\nPermanent roaming : certains pays (et certains opérateurs hôtes) limitent ou interdisent le roaming permanent d'objets fixes. Un déploiement durable à l'étranger doit s'appuyer sur une offre multi-IMSI ou une SIM locale, pas sur du roaming « toléré ».
\n| Critère | Orange | SFR | Bouygues | 1NCE | SIM Eziwan |
|---|---|---|---|---|---|
| Couverture FR | ★★★★★ | ★★★★ | ★★★★ | ★★★★ (via partenaires) | ★★★★★ |
| Prix | ★★★ | ★★★★ | ★★★★★ | ★★★★★ (faible conso) | ★★★★ |
| APN privé | ✅ | ✅ | ✅ | ❌ | ✅ inclus |
| Multi-opérateurs | ❌ | ❌ | ❌ | ❌ (mono via partenaire) | ✅ |
| LTE-M / NB-IoT | ✅ | ✅ | ✅ | ✅ | ✅ |
| eSIM / eUICC | ✅ | ✅ | Partiel | ✅ | ✅ |
| Dashboard flotte | ✅ | ✅ | ✅ | ✅ | ✅ intégré |
| IP fixe | ✅ option | ✅ option | ✅ option | ❌ | ✅ option |
| Roaming UE M2M | ✅ option | ✅ option | ✅ option | ✅ 170+ pays | ✅ inclus |
| Min. commande | ≈100 SIM | ≈50 SIM | ≈50 SIM | 1 SIM | 1 SIM |
| Engagement | 24-36 mois | 12-24 mois | 12-24 mois | Aucun (achat unique) | Sans engagement |
| Support FR dédié IoT | ✅ | ✅ | ✅ | Premium | ✅ |
★ = appréciation indicative Eziwan, à pondérer selon votre géographie et vos volumes.
\nDans tous les cas : modules 4G/LTE-M minimum (jamais 2G/3G seul) et APN privé dès que les données sont sensibles.
\nPuis-je utiliser une SIM grand public dans un gateway IoT ?\nTechniquement oui, mais ce n'est pas recommandé. Les SIM grand public supportent une plage de température limitée (0-40 °C), ont une durée de vie plus courte et ne proposent ni APN privé, ni monitoring de flotte, ni SLA industriel. Sur un parc déployé sur le terrain, le surcoût d'une SIM M2M est largement compensé par la fiabilité et la gestion centralisée.
\nMes objets en 2G ou 3G vont-ils continuer à fonctionner ?\nNon, à terme. Orange ferme son réseau 2G entre le 22 septembre et le 20 octobre 2026, les autres opérateurs suivent, et la 3G s'éteint vers 2028. Tout module uniquement 2G sera hors service dès l'automne 2026 ; un module 2G/3G sans repli 4G le sera vers 2028. Pour tout nouveau projet, exigez du matériel 4G / LTE-M / NB-IoT.
\nQuelle est la consommation minimum d'une SIM M2M en veille ?\nSans trafic métier, une SIM M2M ne consomme que les signaux de maintien réseau (keep-alive, heartbeat) : selon l'opérateur et la configuration, 1-10 Mo/mois. Avec APN privé et tunnel VPN (OpenVPN/IPSec) maintenu en permanence, comptez plutôt 5-15 Mo/mois de keepalive, hors données applicatives.
\nPeut-on changer d'opérateur sans tout reconfigurer ?\nAvec une SIM eUICC (eSIM), oui : le profil opérateur se reconfigure à distance, sans intervention sur site. Avec une SIM physique classique mono-opérateur, il faut changer la carte physiquement. La SIM multi-opérateurs Eziwan élimine le problème : une seule SIM gère automatiquement les trois réseaux français.
\nQuelle différence entre LTE-M et NB-IoT ?\nLTE-M offre un débit plus élevé, une faible latence et gère la mobilité (objets en déplacement, voix possible) — adapté à l'asset tracking et à la télémétrie réactive. NB-IoT vise les objets statiques très sobres (compteurs en sous-sol), avec une excellente pénétration mais un débit et une latence moindres. Les deux survivront à la fin de la 2G/3G.
\nLes SIM M2M sont-elles conformes à la réglementation française ?\nOui. Les offres M2M des opérateurs français sont régulées par l'ARCEP. Les SIM IoT data ne requièrent pas d'identification de l'utilisateur final (pas de pièce d'identité), sauf pour les offres incluant de la voix ou des SMS sortants vers des numéros grand public.
\nComment gérer 500 SIM réparties sur 500 sites ?\nVia un portail de gestion de flotte : consommation data en temps réel par SIM, détection des SIM inactives ou en surconsommation, activation/désactivation à distance, visualisation du signal (RSRP/RSRQ), alertes par seuil. Le portail Eziwan intègre cette gestion dans le même dashboard que la supervision de vos équipements, évitant de jongler entre plusieurs interfaces.
\nUne SIM multi-opérateurs coûte-t-elle beaucoup plus cher ?\nEn général +10 à +20 % vs une SIM mono-opérateur équivalente. Sur un site critique, ce surcoût est marginal face au coût d'une coupure ou d'un déplacement technique pour cause de zone blanche mal anticipée.
\nPour une recommandation personnalisée selon votre parc et vos zones géographiques, contactez notre équipe — nous réalisons une analyse de couverture gratuite sur vos sites, opérateur par opérateur.
\nGrafana est devenu l'outil de référence pour la visualisation de données industrielles. Gratuit, open-source, et extensible, il transforme vos données Modbus, OPC-UA ou MQTT en tableaux de bord opérationnels. Ce guide vous montre comment architecturer une supervision industrielle complète avec Grafana — ou comment Eziwan vous l'offre clé en main.
\nGrafana s'est imposé dans l'industrie pour plusieurs raisons :
\nComparé à un SCADA traditionnel :
\n| Grafana (+ stack IoT) | SCADA Wonderware/Ignition | |
|---|---|---|
| Coût licence | 0 (open source) | 5 000–50 000€ |
| Coût hébergement | 50–200€/mois (cloud) | Serveur dédié + maintenance |
| Variables illimitées | ✅ | ❌ (facturation par tag) |
| Interface web native | ✅ | ✅ (Ignition) / ❌ (Wonderware) |
| Mobile ready | ✅ | Partiel |
| Intégration cloud | Natif | Complexe |
La stack complète pour superviser des automates Modbus dans Grafana :
\n\nAlternative pour volumes importants :
\n\nSolution Eziwan (tout-en-un) :
\nEziwan intègre la stack complète (collecte Modbus/OPC-UA, cloud time series, dashboards Grafana préconfigurés, alertes SMS/email) sans que vous ayez à installer et maintenir les composants individuellement.
\n# docker-compose.yml
version: '3.8'
services:
influxdb:
image: influxdb:2.7
ports:
- \"8086:8086\"
environment:
DOCKER_INFLUXDB_INIT_MODE: setup
DOCKER_INFLUXDB_INIT_USERNAME: admin
DOCKER_INFLUXDB_INIT_PASSWORD: mot_de_passe_securise
DOCKER_INFLUXDB_INIT_ORG: eziwan
DOCKER_INFLUXDB_INIT_BUCKET: industrie
DOCKER_INFLUXDB_INIT_RETENTION: 1825d # 5 ans
volumes:
- influxdb_data:/var/lib/influxdb2
grafana:
image: grafana/grafana:10.4.0
ports:
- \"3000:3000\"
environment:
GF_SECURITY_ADMIN_PASSWORD: grafana_securise
volumes:
- grafana_data:/var/lib/grafana
depends_on:
- influxdb
telegraf:
image: telegraf:1.29
volumes:
- ./telegraf.conf:/etc/telegraf/telegraf.conf:ro
depends_on:
- influxdb
volumes:
influxdb_data:
grafana_data:
# telegraf.conf
[[inputs.mqtt_consumer]]
servers = [\"tcp://localhost:1883\"]
topics = [\"usine/#\"]
qos = 1
data_format = \"json\"
# Parsing du topic MQTT : usine/site/station/variable
[[inputs.mqtt_consumer.topic_parsing]]
topic = \"usine/+/+/+\"
tags = \"_/_/station/_\"
fields = \"_/_/_/value\"
[[outputs.influxdb_v2]]
urls = [\"http://influxdb:8086\"]
token = \"votre_token_influxdb\"
organization = \"eziwan\"
bucket = \"industrie\"
Pour afficher l'évolution de la pression d'une station dans le temps :
\nQuery InfluxDB (Flux) :
\nfrom(bucket: \"industrie\")
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) => r[\"_measurement\"] == \"mqtt_consumer\")
|> filter(fn: (r) => r[\"station\"] == \"station1\")
|> filter(fn: (r) => r[\"_field\"] == \"pression\")
|> aggregateWindow(every: v.windowPeriod, fn: mean, createEmpty: false)
|> yield(name: \"mean\")
Paramètres panel :
\nTime seriesbar (Pressure)Pour afficher la valeur courante d'une variable :
\nQuery InfluxDB :
\nfrom(bucket: \"industrie\")
|> range(start: -1m)
|> filter(fn: (r) => r[\"station\"] == \"station1\" and r[\"_field\"] == \"pression\")
|> last()
Paramètres panel :
\nGaugebarPour afficher le TRS ou un compteur de production :
\nQuery InfluxDB :
\nfrom(bucket: \"industrie\")
|> range(start: -24h)
|> filter(fn: (r) => r[\"_field\"] == \"pieces_produites\")
|> sum()
Paramètres panel :
\nStatpcs (custom)Background (rouge si < objectif)Pour afficher l'état de tous vos sites en temps réel :
\nfrom(bucket: \"industrie\")
|> range(start: -5m)
|> filter(fn: (r) => r[\"_field\"] == \"pression\" or r[\"_field\"] == \"debit\" or r[\"_field\"] == \"etat\")
|> last()
|> pivot(rowKey: [\"_time\", \"station\"], columnKey: [\"_field\"], valueColumn: \"_value\")
Résultat : tableau avec colonnes Station / Pression / Débit / État, une ligne par site.
\nDans Grafana 10+ (Unified Alerting) :
\nEdit → AlertCondition: WHEN last() OF query(A, 5m, now) IS ABOVE 10
maintenance@usine.frPour éviter les \"alert storms\" quand plusieurs sites tombent simultanément :
\n# alertmanager.yml
route:
group_by: ['alertname', 'site']
group_wait: 30s
group_interval: 5m
repeat_interval: 3h
receiver: 'maintenance-team'
receivers:
- name: 'maintenance-team'
email_configs:
- to: 'maintenance@usine.fr'
send_resolved: true
webhook_configs:
- url: 'https://api.sms-provider.fr/send'
Ajouter des annotations automatiques sur les graphes lors d'alarmes :
\n// Créer une annotation InfluxDB lors d'un défaut
from(bucket: \"industrie\")
|> range(start: v.timeRangeStart)
|> filter(fn: (r) => r[\"_field\"] == \"defaut\" and r[\"_value\"] == 1)
|> map(fn: (r) => ({r with _value: \"Défaut détecté sur ${r.station}\"}))
Les Template Variables permettent de créer un dashboard générique réutilisable pour tous vos sites.
\nDashboard Settings → Variables → New Variable :
siteQueryimport \"influxdata/influxdb/schema\"
schema.tagValues(bucket: \"industrie\", tag: \"station\")
from(bucket: \"industrie\")
|> range(start: v.timeRangeStart)
|> filter(fn: (r) => r[\"station\"] == \"${site}\")
|> filter(fn: (r) => r[\"_field\"] == \"pression\")
L'opérateur peut maintenant choisir le site dans un menu déroulant en haut du dashboard.
\n┌─────────────────────────────────────────────────────────────────┐
│ Station : [dropdown] │ Période : [6h|24h|7j|30j] │
├──────────────┬──────────────┬──────────────┬────────────────────┤
│ Pression │ Débit │ Niveau │ État Pompe │
│ [gauge] │ [gauge] │ [gauge] │ [stat 🟢/🔴] │
├──────────────┴──────────────┴──────────────┴────────────────────┤
│ Tendances 24h : Pression / Débit / Niveau │
│ [time series graph] │
├─────────────────────────────────────────────────────────────────┤
│ Alarmes actives │ Dernières interventions │
│ [table] │ [table annotations] │
└─────────────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────────────────┐
│ Vue globale — 15 sites │
├──────────┬──────────┬──────────┬──────────┬──────────┬────────────┤
│ Site 1 │ Site 2 │ Site 3 │ Site 4 │ Site 5 │ ... │
│ TRS: 87% │ TRS: 91% │ TRS: 73% │ TRS: 94% │ TRS: 82% │ │
│ 🟢 OK │ 🟢 OK │ 🔴 Alrm │ 🟢 OK │ 🟡 Warn │ │
├──────────┴──────────┴──────────┴──────────┴──────────┴────────────┤
│ Production cumulée 24h : objectif vs réel [bar chart] │
└────────────────────────────────────────────────────────────────────┘
Eziwan propose deux modes d'intégration avec Grafana :
\nLa plateforme Eziwan intègre Grafana nativement. Vos données Modbus/OPC-UA sont déjà dans notre time series database hébergée en France. Vous accédez directement aux dashboards depuis votre navigateur, avec :
\nSi vous avez déjà un Grafana interne :
\nGET /api/v1/variables/{id}/historyGrafana peut-il remplacer un SCADA en production ?\nPour la visualisation et les alertes, oui dans beaucoup de cas. Pour le contrôle en temps réel (écriture sur automate, séquences de commande), un SCADA ou un système HMI dédié reste recommandé. Grafana excelle en historisation, analyse de tendances et monitoring multi-sites.
\nQuelle base de données pour stocker des données industrielles dans Grafana ?\nInfluxDB est le choix standard pour les time series industrielles (haute fréquence, compression native, requêtes Flux puissantes). TimescaleDB (extension PostgreSQL) convient si vous avez déjà PostgreSQL. Prometheus est adapté aux métriques infrastructure mais moins pertinent pour les données process.
\nComment sécuriser l'accès à Grafana depuis Internet ?\nMettre Grafana derrière un reverse proxy (Nginx/Traefik) avec TLS, activer l'authentification OIDC/LDAP, désactiver l'accès anonyme, configurer des alertes sur tentatives de connexion échouées. Ne jamais exposer InfluxDB directement sur Internet.
\nGrafana peut-il gérer 1 000 sites et 100 000 variables ?\nOui avec la bonne architecture. InfluxDB 2.x supporte des milliards de points. Grafana Enterprise gère le clustering. Pour des volumes très importants, envisager Apache Kafka en amont pour le streaming, et des politiques de rétention différenciées (données 1s gardées 30j, données 1min gardées 5 ans).
\nPuis-je avoir un synoptique P&ID dans Grafana ?\nOui avec le plugin Flowcharting (basé sur draw.io). Vous dessinez votre schéma P&ID, attachez des variables Grafana à chaque équipement, et les valeurs s'affichent en temps réel sur le synoptique avec changement de couleur selon l'état.
\nEnvie de dashboards Grafana sans gérer l'infrastructure ? Testez Eziwan gratuitement 30 jours — vos données Modbus dans Grafana en moins d'une heure.
\nOPC-UA (OPC Unified Architecture) est devenu le protocole de référence pour l'interopérabilité dans l'industrie 4.0. Pourtant, sa complexité apparente freine encore beaucoup d'implémentations. Ce guide pratique démystifie OPC-UA : architecture, sécurité, NodeId, implémentation Python/Node.js, et intégration cloud.
\nOPC-UA (IEC 62541) est un protocole de communication indépendant de la plateforme, conçu pour l'échange sécurisé de données industrielles. Contrairement à son prédécesseur OPC-DA (Windows only, DCOM), OPC-UA fonctionne sur n'importe quel OS (Linux, Windows, embedded RTOS) et sur n'importe quel réseau (Ethernet, 4G, Wi-Fi).
\nLe modèle de base OPC-UA est client-serveur :
\n\nUn même équipement peut être serveur et client simultanément (ex. gateway qui agrège plusieurs PLCs et expose les données consolidées).
\nL'Address Space est l'arbre d'information exposé par un serveur OPC-UA. Chaque nœud a un NodeId unique :
\n\nFormat NodeId :
\nns=2;i=1234 — namespace 2, identifiant entier 1234ns=2;s=Station_1.Pression — namespace 2, identifiant chaînens=0;i=2258 — namespace 0 (standard), ServerStatusNamespaces :
\nns=0 : namespace OPC-UA standard (types, méthodes)ns=1 : souvent le namespace constructeurns=2+ : namespaces applicatifs (vos données)| Mode | Description | Cas d'usage |
|---|---|---|
| Read | Lecture ponctuelle d'un nœud | Polling toutes les N secondes |
| Subscription | Abonnement à des changements (MonitoredItem) | Événements, alarmes |
| Browse | Exploration de l'Address Space | Configuration, discovery |
| Write | Écriture d'une valeur | Setpoints, commandes |
| Method Call | Appel de méthode | Actions complexes |
| Pubsub | Publication/abonnement MQTT ou UDP | Architectures cloud massives |
Les Subscriptions sont la bonne approche pour la supervision temps réel : au lieu de poller toutes les secondes, le client s'abonne à un nœud et reçoit une notification uniquement quand la valeur change au-delà d'un seuil configurable (DeadbandValue).
\nLa sécurité est l'un des points forts d'OPC-UA — et aussi l'une des sources de complexité. Voici les concepts essentiels.
\n| Mode | Confidentialité | Intégrité | Authentification | Usage |
|---|---|---|---|---|
None | Aucune | Aucune | Aucune | Tests, réseau isolé |
Sign | Non | Signature | Certificat | Réseau sécurisé |
SignAndEncrypt | AES-256 | Signature | Certificat | Internet, cloud |
Ne jamais utiliser SecurityMode: None en production sur un réseau accessible depuis l'extérieur.
OPC-UA utilise des certificats X.509 pour l'authentification mutuelle client-serveur :
\n\nCréation d'un certificat auto-signé pour tests :
\n# Avec OpenSSL
openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \\
-keyout client_key.pem -out client_cert.pem \\
-subj \"/CN=EziwanGateway/O=Eziwan/C=FR\" \\
-extensions v3_req \\
-config <(cat /etc/ssl/openssl.cnf; echo \"[v3_req]\"; echo \"subjectAltName=URI:urn:eziwan:gateway:client\")
En production : utiliser une PKI interne ou un CA reconnu. Les certificats doivent être échangés manuellement entre client et serveur la première fois.
\nEn plus des certificats machine, OPC-UA gère l'authentification utilisateur :
\nLa bibliothèque python-opcua (ou sa fork asyncua) est la référence en Python.
\npip install asyncua
import asyncio
from asyncua import Client
async def main():
url = \"opc.tcp://192.168.1.10:4840/freeopcua/server/\"
async with Client(url=url) as client:
# Lire un nœud par NodeId
node = client.get_node(\"ns=2;s=Station_1.Pression\")
value = await node.read_value()
print(f\"Pression: {value} bar\")
# Lire plusieurs nœuds en batch
nodes = [
client.get_node(\"ns=2;s=Station_1.Pression\"),
client.get_node(\"ns=2;s=Station_1.Debit\"),
client.get_node(\"ns=2;s=Station_1.Defaut\"),
]
values = await client.read_values(nodes)
for node, val in zip(nodes, values):
print(f\" {node}: {val}\")
asyncio.run(main())
import asyncio
from asyncua import Client
from asyncua.common.subscription import SubHandler
class DataChangeHandler(SubHandler):
def datachange_notification(self, node, val, data):
print(f\"[CHANGE] {node} = {val}\")
def event_notification(self, event):
print(f\"[EVENT] {event}\")
async def main():
url = \"opc.tcp://192.168.1.10:4840\"
async with Client(url=url) as client:
handler = DataChangeHandler()
subscription = await client.create_subscription(500, handler) # 500ms
nodes = [
client.get_node(\"ns=2;s=Station_1.Pression\"),
client.get_node(\"ns=2;s=Station_1.Debit\"),
]
monitored_items = await subscription.subscribe_data_change(nodes)
print(\"Subscriptions actives, attente changements...\")
await asyncio.sleep(30) # écouter 30 secondes
await subscription.unsubscribe(monitored_items)
asyncio.run(main())
from asyncua.crypto.security_policies import SecurityPolicyBasic256Sha256
from asyncua.crypto.cert_man import CertificateManager
async def connect_secure():
client = Client(\"opc.tcp://192.168.1.10:4840\")
await client.set_security(
SecurityPolicyBasic256Sha256,
certificate=\"./client_cert.der\",
private_key=\"./client_key.pem\",
server_certificate=\"./server_cert.der\"
)
await client.connect()
# ... vos opérations
await client.disconnect()
La bibliothèque node-opcua est la référence JavaScript/TypeScript.
\nnpm install node-opcua
const opcua = require(\"node-opcua\");
const client = opcua.OPCUAClient.create({
endpointMustExist: false,
connectionStrategy: { maxRetry: 5, initialDelay: 2000 }
});
const endpointUrl = \"opc.tcp://192.168.1.10:4840\";
async function main() {
await client.connect(endpointUrl);
const session = await client.createSession();
const nodeToRead = {
nodeId: \"ns=2;s=Station_1.Pression\",
attributeId: opcua.AttributeIds.Value
};
const dataValue = await session.read(nodeToRead);
console.log(`Pression: ${dataValue.value.value} bar`);
console.log(`Timestamp: ${dataValue.serverTimestamp}`);
await session.close();
await client.disconnect();
}
main().catch(console.error);
Le S7-1500 supporte OPC-UA serveur natif depuis le firmware 2.0 :
\nDevice Configuration → OPC UA → ServerLe S7-1200 supporte OPC-UA depuis le firmware 4.1.
\nM580 : OPC-UA via module BMENOC0311 (firmware ≥ V2.0)\nM340 : pas de support OPC-UA natif → Modbus TCP recommandé, ou gateway OPC-UA to Modbus (ex. Kepware KEPServerEX)
\nLes automates Rockwell ne supportent pas OPC-UA natif. Options :
\nTwinCAT 3 intègre un serveur OPC-UA natif via TF6100 (module OPC-UA). Configuration via TwinCAT System Manager.
\nLa plupart des PLC modernes de ces constructeurs supportent OPC-UA. Vérifier le firmware et activer le serveur dans la configuration réseau.
\nOPC-UA PubSub (IEC 62541-14) est l'extension qui rend OPC-UA compatible avec les architectures IoT cloud :
\nTransports supportés :
\nEncodages :
\nExemple de message OPC-UA PubSub JSON :
\n{
\"MessageId\": \"abc123\",
\"PublisherId\": \"urn:station1:plc\",
\"DataSetWriterId\": 1,
\"MetaDataVersion\": {\"MajorVersion\": 1, \"MinorVersion\": 0},
\"Timestamp\": \"2026-08-14T10:30:00.000Z\",
\"Payload\": {
\"Station_1.Pression\": {\"Value\": 4.2, \"StatusCode\": 0, \"SourceTimestamp\": \"2026-08-14T10:29:59.950Z\"},
\"Station_1.Debit\": {\"Value\": 125.3, \"StatusCode\": 0, \"SourceTimestamp\": \"2026-08-14T10:29:59.950Z\"}
}
}
Si vous avez des installations sous OPC-DA (OPC Classic, Windows DCOM), la migration vers OPC-UA apporte :
\nOutil de migration : OPC UA Wrapper (ex. Kepware) crée un serveur OPC-UA qui expose les données d'un serveur OPC-DA existant, permettant une migration progressive.
\nLe Eziwan Gateway intègre un client OPC-UA capable de se connecter aux serveurs OPC-UA de vos équipements :
\nNone, Sign, SignAndEncryptAvantage clé : vous n'avez pas besoin d'écrire un client OPC-UA vous-même. Le gateway fait le travail et expose une API REST vers votre SCADA ou ERP.
\nOPC-UA est-il plus complexe que Modbus ?\nOui, mais justifié pour les installations multi-constructeurs et les projets industrie 4.0. Pour une installation avec 2-3 automates du même constructeur, Modbus TCP peut être suffisant. OPC-UA s'impose quand vous avez des équipements hétérogènes, des exigences de sécurité, ou des besoins d'interopérabilité ERP/MES.
\nLe port 4840 doit-il être ouvert sur mon firewall ?\nEn architecture \"zero-inbound-port\" (comme Eziwan), le gateway initie la connexion vers le serveur OPC-UA en interne. Aucun port n'est ouvert depuis l'extérieur. Le tunnel VPN chiffré porte les données vers le cloud.
\nOPC-UA peut-il remplacer MQTT dans une architecture IoT ?\nOPC-UA PubSub avec transport MQTT combine le meilleur des deux : le modèle d'information sémantique d'OPC-UA avec la légèreté et la scalabilité de MQTT. C'est la direction prise par les référentiels Industrie 4.0 (Industrie 4.0 Architecture Reference Model, IDS-R).
\nQuelles performances attendre d'un serveur OPC-UA embarqué ?\nUn Siemens S7-1500 CPU 1515 peut traiter ~10 000 nœuds OPC-UA en lecture par seconde. Pour les PLCs moins puissants (M221, petits WAGO), limiter le polling OPC-UA à 100-500 nœuds/s. Les abonnements (Subscription) sont beaucoup plus efficaces que le polling pour les volumes importants.
\nExiste-t-il des serveurs OPC-UA gratuits pour tester ?\nOui : ProsysOPC UA Simulation Server (gratuit, Windows), Node-RED avec node-red-contrib-opcua (gratuit, multi-plateforme), python-opcua en mode serveur (exemple dans la doc GitHub). Ils permettent de tester un client sans avoir de PLC physique.
Besoin d'aide pour connecter vos serveurs OPC-UA au cloud ? Demandez une démo gratuite — notre équipe vous accompagne du POC au déploiement.
\nVos automates Schneider Electric Modicon M340, M221 ou M580 tournent depuis des années, mais leur supervision reste locale — panneau opérateur sur site, pas d'accès distant, pas de tendances historiques. Ce guide vous montre comment les connecter au cloud IoT sans modifier votre programme PLC ni interrompre la production.
\nLes automates Schneider Electric de la gamme Modicon sont présents dans des milliers d'installations industrielles françaises : traitement des eaux, stations de pompage, process agroalimentaires, lignes de conditionnement. Robustes et fiables, ils ont souvent une durée de vie de 15-20 ans.
\nMais leurs capacités de communication natives sont limitées :
\nLa solution : un gateway IoT industriel qui lit les données Modbus de votre M340/M221 et les remonte vers le cloud, sans modifier le programme automate.
\nLe M221 (TM221CE16R, TM221CE24T, etc.) intègre un port Modbus RTU en natif sur sa prise RJ45 (RS-485 via adaptateur TM3TI4 ou câble spécifique) et un port Modbus TCP sur son port Ethernet.
\nRegistres accessibles :
\n%MW0 à %MW255 — mots mémoire%QW — sorties analogiques%IW — entrées analogiques%M — bits mémoire (bobines 0-255)Configuration Modbus esclave sur M221 :
\nDans EcoStruxure Machine Expert - Basic :
\nConfiguration → Modbus Serial ou Modbus TCPLe M340 (BMX P34 2020, BMX P34 2030, etc.) dispose d'un port série Modbus RTU (RS-485, connecteur SUB-D 9 broches) et d'un module ETH (BMX NOE 0100 ou BMX NOC 0401) pour Modbus TCP.
\nRegistres accessibles via Modbus :
\n| Zone PLC | Type Modbus | Fonction lecture | Plage |
|---|---|---|---|
%MW | Holding Registers | FC03 | 400001–465535 |
%IW | Input Registers | FC04 | 300001–365535 |
%M | Coils | FC01 | 000001–065536 |
%I | Discrete Inputs | FC02 | 100001–165536 |
Adresse Modbus → adresse Unity Pro :
\n%MW0%MW99%MW500Le M580 dispose de Modbus TCP natif sur son port Ethernet CPU et supporte les mêmes tables de registres que le M340, avec en plus :
\nPrérequis :
\nAvantages :
\nPour le M221 : utiliser le câble TCSMCNAM3M002P (RJ45 vers RS-485) ou l'adaptateur VW3A8306 selon la gamme.
\nPour le M340 : connecteur SUB-D 9 broches côté PLC, bornes 3 (+), 8 (-) pour RS-485.
\nParamètres série M221/M340 (défauts) :
\nUne fois le gateway connecté, la configuration se fait depuis l'interface cloud Eziwan en quelques clics.
\nFlotte → Site → + Équipement192.168.1.10 (ou adresse de votre M340)5021| Variable | Registre Modbus | Type | Description |
|---|---|---|---|
| Niveau cuve | %MW10 → 400011 | Holding (FC03) | 0-100% |
| Débit pompe | %MW20 → 400021 | Holding (FC03) | 0-500 m³/h |
| Pression | %IW0 → 300001 | Input (FC04) | 0-16 bar |
| Défaut général | %M0 → 000001 | Coil (FC01) | Booléen |
| Marche pompe | %M1 → 000002 | Coil (FC01) | Booléen |
Conversion engineering : appliquer un facteur multiplicateur si l'automate renvoie une valeur brute (ex. ×0.01 pour passer de 1500 à 15.00 bar).
| Criticité | Polling | Cas d'usage |
|---|---|---|
| Temps réel | 1 s | Sécurité, process critique |
| Supervision | 5 s | Production, énergie |
| Tendances | 30 s | Comptages, statistiques |
| Archive | 5 min | Télérelève simple |
Dès la première connexion du gateway, les données remontent en temps réel dans le dashboard Eziwan :
\nConfigurez des alertes précises sur chaque variable :
\nAlerte : Niveau cuve
Condition : %MW10 < 10 (niveau bas)
Canal : SMS + Email
Destinataires : equipe@maintenance.fr, astreinte@maintenance.fr
Acquittement : requis
Alerte : Défaut pompe
Condition : %M5 = 1 (bit défaut actif)
Canal : SMS immédiat
Priorité : Critique
Toutes les données sont archivées 5 ans en standard, sans surcoût. Vous pouvez :
\nContexte : une collectivité gère 12 stations de pompage équipées de M340 BMX P34 2020. Maintenance actuelle : 3 rondes terrain/semaine, 2 techniciens.
\nConfiguration déployée :
\nRésultats après 6 mois :
\nSi vous utilisez SoMachine (M221) ou Unity Pro (M340/M580), aucune modification du programme PLC n'est nécessaire. Le gateway Eziwan se connecte en lecture seule par défaut.
\nSi vous souhaitez également écrire des consignes (setpoints, commandes) depuis le cloud :
\n%MW200-MW220)L'écriture sur automate depuis le cloud doit faire l'objet d'une analyse de risques (HAZOP). Protéger impérativement les adresses critiques (arrêt urgence, consignes sécurité) en accès lecture seule.
Le gateway Eziwan est compatible avec EcoStruxure de plusieurs façons :
\nLe gateway lit les mêmes registres que votre SCADA EcoStruxure, sans interférence. Idéal pour ajouter :
\nSi votre licence EcoStruxure Plant arrive en fin de vie, vous pouvez migrer progressivement :
\n| M221 | M340 | M580 | |
|---|---|---|---|
| Modbus RTU natif | ✅ (via câble) | ✅ (SUB-D 9) | ✅ |
| Modbus TCP natif | ✅ (port ETH) | ✅ (module BMX NOE) | ✅ natif |
| Max variables Eziwan | 128 | 512 | 1024 |
| Polling min | 1 s | 1 s | 500 ms |
| Écriture registres | ✅ FC06 | ✅ FC06/FC16 | ✅ FC06/FC16 |
| Compatibilité store&forward | ✅ | ✅ | ✅ |
Faut-il modifier le programme SoMachine/Unity Pro ?\nNon. Le gateway Eziwan se connecte en Modbus maître sur l'automate esclave. Aucune ligne de code n'est ajoutée au PLC. Si l'automate est déjà configuré comme esclave Modbus (ce qui est le cas par défaut), la connexion est immédiate.
\nMon M340 a déjà un SCADA Unity Pro — est-ce compatible ?\nOui. Plusieurs maîtres Modbus TCP peuvent interroger le même esclave simultanément. Le gateway Eziwan et votre SCADA coexistent sans conflit, à condition de configurer une fréquence de polling raisonnable (≥ 1 s).
\nPuis-je superviser des modules d'entrées analogiques (BMX AMI 0410) ?\nOui. Les modules analogiques sont adressés dans les tables %IW (entrées) et %QW (sorties). Consultez la documentation Unity Pro pour le mappage registres de vos modules spécifiques.
Le gateway fonctionne-t-il si le réseau 4G est coupé ?\nOui. Le gateway Eziwan intègre un buffer SD card : les données continuent d'être acquises localement et sont transmises en bloc dès le rétablissement de la connectivité (store-and-forward). Les alertes locales (SMS direct) restent opérationnelles sans cloud.
\nEst-ce compatible avec la gamme Zelio Logic ?\nZelio Logic Smart Relay supporte Modbus RTU limité. Selon le modèle (SR2/SR3), l'accès aux registres internes peut être restreint. Contactez-nous pour une validation de compatibilité sur votre modèle exact.
\nVous avez un M340, M221 ou M580 sur site et souhaitez valider la connexion cloud ?
\nEziwan propose un POC 30 jours gratuit incluant :
\nDémarrer le POC gratuit → | Calculer votre ROI →
\nVous utilisez d'autres gammes Schneider Electric (Altivar, Easergy, PowerLogic) ? Contactez-nous pour valider la compatibilité avec votre équipement spécifique.
\nLe choix du protocole de communication sans fil est l'une des décisions les plus importantes dans un projet IoT industriel. LoRaWAN, Zigbee, 4G LTE ou Wi-Fi : chaque technologie a ses forces, ses faiblesses et ses cas d'usage idéaux. Choisir la mauvaise technologie peut rendre votre déploiement impossible à scaler, trop cher à opérer, ou insuffisamment fiable pour votre contexte industriel.
\nCe guide compare les 4 principales technologies sans fil utilisées dans l'IoT industriel en France, avec des recommandations concrètes par cas d'usage.
\nAvant d'entrer dans les détails, voici l'essentiel en une phrase par technologie :
\n| Critère | LoRaWAN | Zigbee | 4G LTE | Wi-Fi 802.11n/ac |
|---|---|---|---|---|
| Portée | 1-15 km (rural) / 0,5-3 km (urbain) | 10-100 m (mesh jusqu'à 300 m) | 0,5-30 km | 30-150 m |
| Débit | 250 bps à 50 Kbps | 20-250 Kbps | 5-100 Mbps | 50-1000 Mbps |
| Latence | 1-10 s | 10-30 ms | 30-100 ms | 1-10 ms |
| Consommation | Très faible (µA en veille) | Faible (µA-mA) | Moyenne (mA-W) | Haute (W) |
| Autonomie batterie | 5-15 ans | 1-5 ans | 6-24 mois | Jours à semaines |
| Coût infrastructure | Faible (concentrateur LoRa) | Moyen (coordinateur + maillage) | Faible (SIM M2M) | Élevé (AP + switches) |
| Coût par nœud | 10-80 € | 20-150 € | 100-500 € | 50-300 € |
| Fréquence | 868 MHz (EU) | 2,4 GHz | 700/800/1800/2600 MHz | 2,4 / 5 GHz |
| Sécurité native | AES-128 | AES-128 | 3GPP (TLS, SIM) | WPA3 |
| Standardisation | LoRa Alliance | Zigbee Alliance (CSA) | 3GPP | IEEE 802.11 |
| Topologie | Étoile (via concentrateur) | Maillage (mesh) | Point-to-point (via réseau mobile) | Étoile (via AP) |
| Nombre de nœuds par gateway/AP | 2 000 à 10 000 | 65 000 (Zigbee 3.0) | N/A (réseau opérateur) | 30-100 clients actifs |
LoRaWAN est idéal pour les scénarios où vous avez besoin de très longues distances et de très faible consommation, mais où le débit est faible (quelques octets par message toutes les minutes à heures).
\nCas d'usage industriels parfaits pour LoRa :
\nAvantages LoRaWAN :
\nLimites LoRaWAN :
\nArchitecture type LoRa industriel :
\n\nZigbee est idéal pour les réseaux denses de capteurs en intérieur à courte portée, notamment dans les bâtiments (smart building) et les usines où les distances sont courtes mais le nombre de nœuds est important.
\nCas d'usage industriels parfaits pour Zigbee :
\nAvantages Zigbee :
\nLimites Zigbee :
\nLa 4G LTE est la technologie de choix pour les connexions WAN longue distance, les sites isolés sans infrastructure réseau, et les applications nécessitant un débit suffisant pour la supervision et l'accès distant.
\nCas d'usage industriels parfaits pour la 4G :
\nAvantages 4G LTE industriel :
\nLimites 4G LTE :
\nLe Wi-Fi est adapté aux sites avec infrastructure réseau existante, aux équipements nécessitant un haut débit, et aux zones totalement couvertes par des points d'accès.
\nCas d'usage industriels parfaits pour le Wi-Fi :
\nAvantages Wi-Fi industriel :
\nLimites Wi-Fi industriel :
\n| Secteur | Recommandation principale | Secondaire | Éviter |
|---|---|---|---|
| Eau/assainissement (stations isolées) | 4G LTE | LoRaWAN (compteurs) | Wi-Fi |
| Eau/assainissement (réseau urbain) | LoRaWAN | 4G LTE | — |
| Énergie ENR (parcs ruraux) | 4G LTE | LoRaWAN (météo) | Wi-Fi |
| Manufacturing (usine couverte) | Wi-Fi / 4G | Zigbee | LoRaWAN |
| Logistique entrepôt | Wi-Fi / Zigbee | 4G LTE | LoRaWAN |
| Agriculture (exploitation rurale) | 4G LTE | LoRaWAN | Wi-Fi |
| Smart building (tertiaire) | Zigbee / Wi-Fi | LoRaWAN | 4G LTE |
| Télémaintenance (accès distant) | 4G LTE | — | LoRaWAN, Zigbee |
En pratique, les déploiements IoT industriels matures utilisent plusieurs technologies en combinaison, choisies selon la nature de chaque équipement.
\nExemple d'architecture hybride : site industriel 10 hectares
\n\nLe gateway Eziwan agit comme concentrateur multi-protocoles : il parle Modbus sur le réseau OT local, est compatible avec des concentrateurs LoRa et Zigbee pour les capteurs sans fil, et remonte tout vers le cloud via 4G LTE. Un seul abonnement, un seul dashboard.
\n| Critère | LoRaWAN (réseau public) | Zigbee (réseau privé) | 4G LTE | Wi-Fi industriel |
|---|---|---|---|---|
| Matériel par nœud | 30-60 € | 50-120 € | 300-500 € | 100-250 € |
| Infrastructure | 0 € (réseau public) | 500-2000 € (hub) | 0 € | 3000-15000 € (APs) |
| Abonnement par nœud/an | 5-15 € | 0 € | 120-240 € | 0 € |
| Total matériel 100 nœuds | 3 000-6 000 € | 5 000-14 000 € | 30 000-50 000 € | 10 000-25 000 € |
| Total abonnement 5 ans | 2 500-7 500 € | 0 € | 60 000-120 000 € | 0 € |
| TCO 5 ans (100 nœuds) | 5 500-13 500 € | 5 000-14 000 € | 90 000-170 000 € | 13 000-40 000 € |
Note : le 4G LTE est nettement plus cher par nœud, mais donne accès à une connectivité WAN longue distance que LoRa et Zigbee ne peuvent pas offrir. La comparaison est pertinente uniquement pour des capteurs de collecte de données, pas pour les gateways industriels qui doivent assurer la connexion internet.
\nIl n'existe pas de \"meilleure\" technologie IoT universelle. Le choix dépend de trois critères fondamentaux :
\nLa solution Eziwan est optimisée pour la 4G LTE comme technologie de connexion WAN industrielle, car c'est la plus adaptée aux gateways qui doivent relier des réseaux OT locaux (Modbus, OPC-UA) au cloud de supervision. Elle peut être complétée par des concentrateurs LoRaWAN ou Zigbee pour les capteurs basse consommation.
\nBesoin d'aide pour choisir la bonne architecture pour votre projet ? Contactez notre équipe d'ingénieurs pour un audit gratuit de votre contexte.
\nPeut-on combiner LoRaWAN et 4G LTE sur le même site ?\nOui — c'est même recommandé. Les capteurs LoRaWAN sur batterie (compteurs eau, sondes environnementales, capteurs de niveau) remontent via un concentrateur LoRa. La gateway Eziwan 4G LTE consolide les données des capteurs LoRa locaux et des équipements Modbus, et les envoie au cloud. Le 4G n'est utilisé que pour la connexion WAN, pas pour chaque capteur individuel.
\nLoRaWAN est-il fiable pour une supervision industrielle critique ?\nLoRaWAN convient à la supervision non critique (relevés de compteurs, environnement, présence). Pour les supervisions critiques (alarmes de pompe, valeurs process), le 4G LTE est préférable pour sa latence faible et sa fiabilité. Les deux protocoles coexistent souvent : LoRaWAN pour les capteurs auxiliaires, 4G pour les automates et IHM critiques.
\nQuelle est la différence entre LoRa et LoRaWAN ?\nLoRa est la technologie radio (modulation CSS de Semtech). LoRaWAN est le protocole réseau qui s'appuie sur LoRa : il définit l'architecture réseau (nœuds → concentrateurs → Network Server → Application Server), la gestion des adresses, la sécurité (AES-128), les classes de dispositifs (A, B, C). LoRa sans LoRaWAN peut fonctionner en mode point-à-point propriétaire — moins interopérable.
\nPeut-on utiliser Zigbee dans un environnement industriel avec perturbations électromagnétiques ?\nZigbee (2,4 GHz) est sensible aux interférences radio industrielles (moteurs, variateurs, soudure). En environnement fortement perturbé, privilégiez des canaux Zigbee sur 915 MHz (disponible en version sub-GHz) ou utilisez le filaire (RS-485 Modbus) pour les équipements les plus critiques. Le maillage Zigbee améliore la résilience mais ne supprime pas les limitations physiques.
\nLe Wi-Fi industriel est-il adapté à une machine en mouvement (AGV, convoyeur) ?\nLe Wi-Fi avec roaming 802.11r (Fast Transition) est utilisé pour les AGV (chariots guidés automatiques) et les convoyeurs. Un réseau d'access points couvrant tout le trajet permet un handover rapide (<50 ms) entre APs. C'est un déploiement plus complexe et plus coûteux qu'un réseau fixe, mais c'est la solution standard pour les machines en mouvement en environnement indoor.
\nEziwan est expert en connectivité IoT industrielle 4G LTE. Notre gateway multi-protocoles (Modbus, OPC-UA, MQTT, LoRaWAN, Zigbee) s'adapte à votre architecture existante. Découvrir le gateway Eziwan →
\nLa machine que vous livrez aujourd'hui ne génère du chiffre d'affaires qu'une seule fois. La même machine connectée génère des revenus récurrents tout au long de sa vie — en maintenance, en abonnement, en améliorations firmware.
\nPour un constructeur de machines industrielles (OEM), intégrer la télémaintenance n'est pas seulement un argument commercial. C'est une transformation du modèle économique. Cet article vous donne les bases techniques, économiques, et contractuelles pour réussir cette transformation.
\nIl y a dix ans, proposer la télémaintenance était un avantage concurrentiel. Aujourd'hui, dans de nombreux secteurs, c'est une condition d'entrée sur certains marchés.
\nAgroalimentaire et boissons : les lignes de production modernes fonctionnent 20h/24, 6j/7. Un arrêt non planifié coûte entre 5 000 et 50 000 €/h selon la capacité. Les donneurs d'ordres exigent des engagements de reprise d'activité sous 2 à 4 heures, impossibles à tenir sans diagnostic à distance.
\nPharmacie et cosmétique : les équipements sont sous dossier de qualification (IQ/OQ/PQ). Chaque modification ou intervention doit être documentée. La télémaintenance avec traçabilité complète des sessions répond exactement à cette exigence.
\nIndustrie automobile et mécanique : les clients grands comptes intègrent la connectivité des équipements dans leurs critères de sélection pour les appels d'offres. Les équipements non connectés sont exclus d'emblée dans certains cahiers des charges.
\nÉnergies renouvelables : turbines éoliennes, centrales solaires, pompes à chaleur industrielles — la maintenance préventive basée sur les données de fonctionnement est un facteur clé de compétitivité.
\nLes constructeurs qui ont intégré la télémaintenance dans leur offre témoignent d'impacts commerciaux significatifs :
\nL'approche la plus efficace est d'intégrer la gateway Eziwan comme un composant standard de la machine, au même titre que le variateur de fréquence ou le boîtier IHM. Elle figure dans la nomenclature, dans le schéma électrique, dans la notice.
\nCette intégration dès la conception évite les problèmes d'intégration a posteriori (adaptation du câblage, justification du coût à l'acheteur) et permet de proposer la télémaintenance de manière transparente comme une fonctionnalité de la machine.
\n┌──────────────────────────────────────────────────────────────────┐
│ Machine industrielle (OEM) │
│ │
│ [Capteurs et actionneurs] │
│ ├── Températures, pressions, débits │
│ ├── Moteurs, variateurs, servomoteurs │
│ └── Codeurs, capteurs de position │
│ ↓ Analogique / TOR │
│ [Automate / Motion controller] │
│ ├── Programme de production (protégé Know-How) │
│ ├── Variables de process (accessibles supervision) │
│ ├── Compteurs et historique local │
│ └── Codes défaut et diagnostics │
│ ↓ Modbus TCP ou RS-485 │
│ [Gateway Eziwan] ← Intégrée en standard dans l'armoire │
│ ├── Collecte Modbus (poll 1-60s configurable) │
│ ├── Bufferisation locale (perte 4G jusqu'à 48h) │
│ ├── 4G LTE Dual SIM (SIM multi-opérateurs incluse) │
│ └── Tunnel OpenVPN sortant → zéro port entrant │
└──────────────────────────────────────────────────────────────────┘
│ Tunnel OpenVPN chiffré
▼
[Cloud Eziwan]
↙ ↘
[Espace OEM] [Espace client]
- Toutes variables - Variables autorisées
- Firmware update - Supervision process
- Diagnostics - Alertes et historique
- Accès toutes machines - Ses machines seulement
La séparation entre l'espace OEM et l'espace client est l'un des points les plus importants de l'architecture. Elle répond à deux besoins contradictoires :
\nVariables protégées (OEM uniquement) :\nParamètres de calibration, recettes de fabrication, paramètres PID de régulation, seuils de protection internes.
\nVariables partagées (visibles par le client) :\nTempératures de process, pressions, débits, états machine, compteurs de production, codes défaut génériques.
\nVos clients posent toujours la même question : \"Si vous avez accès à ma machine à distance, comment je suis sûr que vous ne pouvez pas voir mes données de production confidentielles ?\"
\nEt ils posent parfois la question inverse : \"Si un hacker compromet votre accès constructeur, il peut accéder à ma machine ?\"
\nLa réponse technique à ces deux questions est le cloisonnement cryptographique.
\nIndépendance des espaces d'accès :\nL'espace OEM et l'espace client utilisent des credentials complètement distincts, sans relation entre eux. La compromission d'un credential client n'ouvre pas l'accès à l'espace OEM, et vice versa.
\nSélection fine des variables visibles :\nLa configuration de la gateway définit explicitement quelles variables sont visibles par quel niveau d'accès :
\nvariables:
- nom: \"Temperature_Etuve\"
modbus_addr: 100
access_oem: read_write # OEM peut lire et modifier
access_client: read # Client peut lire
- nom: \"PID_Kp_Etuve\"
modbus_addr: 200
access_oem: read_write
access_client: hidden # Client ne voit pas ce paramètre
- nom: \"Compteur_Cycles\"
modbus_addr: 300
access_oem: read
access_client: read # Les deux peuvent lire les compteurs
Traçabilité des accès OEM chez le client :\nLe client peut voir dans son tableau de bord quand les techniciens OEM se sont connectés à sa machine, pendant combien de temps, et sur quelles variables. Cette transparence renforce la confiance.
\nIndépendamment de la gateway, il est recommandé d'activer les protections natives de l'automate :
\nSiemens S7-1500 :
\nSchneider M340 :
\nQuand votre machine est en production chez 100 clients, vous avez accès à quelque chose d'unique : des données de fonctionnement réelles, dans des conditions variées, sur une durée longue. C'est une richesse que les équipes de R&D des grandes entreprises consacrent des millions à obtenir.
\nDurée de vie réelle des composants :\nLe roulement à billes de l'axe Y de votre machine lâche statistiquement à combien d'heures de fonctionnement ? Les données de votre parc de 100 machines répondent précisément à cette question. Ce que vous pensiez être une MTBF de 8 000h est peut-être 6 500h en production réelle, ou 12 000h si les opérateurs suivent bien les procédures de lubrification.
\nCorrélation paramètres / incidents :\nQuelle combinaison de température ambiante + charge moteur + durée de cycle précède une panne de régulateur thermique ? Ces corrélations permettent d'améliorer les algorithmes de maintenance préventive sur les prochaines générations.
\nUsage réel vs usage prévu :\nVotre machine est-elle utilisée selon ses spécifications ? Certains clients poussent la machine au-delà de ses limites nominales. D'autres l'utilisent très en dessous. Ces informations guident les décisions de conception (surspécifier un composant qui est systématiquement sollicité à 95 %).
\nSegmentation du parc :\nCertains clients ont des taux de défaut 3× supérieurs à la moyenne. Pourquoi ? L'analyse des données de fonctionnement peut révéler des corrélations avec l'environnement (température, humidité, vibrations) ou avec les pratiques opérateur.
\nLa télémaintenance crée les conditions d'un abonnement annuel de maintenance connectée. Ce modèle transforme la relation commerciale :
\nModèle traditionnel :
\nModèle connecté :
\n──────────────────────────────────────────────────────────────────
OFFRE STANDARD — Supervision opérationnelle
• Tableau de bord client en temps réel
• Alertes SMS/email sur défauts machine
• Historique 1 an
• 2 utilisateurs client inclus
──────────────────────────────────────────────────────────────────
OFFRE MAINTENANCE CONNECTÉE
• Tout le Standard +
• Accès technicien OEM à distance (illimité)
• SLA : diagnostic à distance sous 4h ouvrées
• Mise à jour firmware automate à distance
• Historique 3 ans
• 5 utilisateurs client inclus
──────────────────────────────────────────────────────────────────
OFFRE PERFORMANCE GARANTIE
• Tout le Maintenance Connectée +
• Rapport mensuel de performance machine
• Analyse prédictive (détection dérive)
• Engagement disponibilité machine
• Accès API données pour intégration client
──────────────────────────────────────────────────────────────────
Pour un OEM avec 150 machines installées, en estimant 1,8 intervention corrective par machine par an :
\n| Indicateur | Sans télémaintenance | Avec télémaintenance |
|---|---|---|
| Interventions/an | 270 | 108 (60 % résolues à distance) |
| Coût intervention sur site | 1 200 € (déplacement + 4h technicien) | 200 € (session 1h à distance) |
| Coût maintenance corrective | 324 000 € | 128 600 € |
| Économie annuelle | ~195 400 € |
Hypothèses indicatives. Le ROI réel dépend de la localisation du parc, de la nature des pannes, et de l'organisation interne.
\nAlimentation dédiée :\nDériver 24 V DC depuis une alimentation permanente (avant l'interrupteur principal de la machine). La gateway doit rester accessible même machine principale coupée — c'est précisément dans ces moments qu'un diagnostic à distance est le plus utile.
\nRéseau automate :\nConnecter la gateway sur un port Ethernet dédié (séparé du port IHM si possible). Sur les automates à port unique (S7-1200 CPU 1211C, M221...), utiliser un switch industriel manageable pour séparer les flux IHM / gateway / ingénierie.
\nAntenne 4G :\nPour les armoires en acier, prévoir systématiquement un passage de câble pour antenne déportée. En intérieur avec armoire fermée, le signal est souvent insuffisant. Un câble LMR-200 de 3 m avec antenne directionnelle à l'extérieur de l'armoire suffit dans la grande majorité des cas.
\nEziwan fournit aux partenaires OEM les éléments de documentation à intégrer dans vos notices machine :
\nVoir aussi la page dédiée : Constructeurs de machines OEM pour l'architecture détaillée et les modalités du programme partenaire.
Le client peut-il désactiver la gateway de télémaintenance sur sa machine ?
\nTechniquement oui — le client peut débrancher physiquement la gateway. Sur le plan contractuel, la réponse dépend du contrat de maintenance : les OEM qui proposent des SLA de reprise sous 4h peuvent conditionner ce SLA à l'activation permanente de la télémaintenance. En pratique, les clients désactivent rarement la gateway car ils y ont aussi accès pour superviser leur production.
\nComment protéger le programme automate (savoir-faire OEM) tout en permettant la supervision client ?
\nDeux niveaux de protection complémentaires : (1) au niveau automate, activer la protection Know-How (S7-1500) ou la protection par mot de passe (M340) pour empêcher la lecture du programme même via TIA Portal. (2) Au niveau Eziwan, configurer les variables comme access_client: hidden pour les paramètres confidentiels. Le client ne voit que les variables de process, pas les paramètres de réglage.
Combien de machines peut-on gérer dans un seul compte OEM Eziwan ?
\nIl n'y a pas de limite fixe — les comptes OEM sont dimensionnés pour les flottes industrielles (des dizaines à des milliers de machines). Le tableau de bord OEM permet de filtrer par client, par modèle de machine, par état (alerte, normal, hors ligne), et de comparer les performances entre machines du même modèle.
\nComment facturer l'abonnement de télémaintenance aux clients en cas de revente Eziwan ?
\nEziwan propose un programme partenaire OEM avec une tarification grossiste. L'OEM intègre la connectivité dans son propre abonnement de maintenance, avec la marge qu'il souhaite. Le client final n'a pas connaissance de la relation avec Eziwan — il souscrit un \"abonnement maintenance connectée\" auprès de l'OEM.
\nQue se passe-t-il à la fin de contrat de maintenance : l'accès OEM est-il coupé ?
\nOui, si le contrat prévoit cette clause. Depuis le tableau de bord OEM, les accès au compte d'un client peuvent être désactivés instantanément (fin de contrat, litige) ou transférés vers un autre prestataire. Les données historiques du client restent dans son compte et lui appartiennent — elles ne sont pas perdues.
\nVous construisez des machines industrielles et souhaitez intégrer la télémaintenance dans votre prochaine série ?
Rejoindre le programme partenaire OEM →
Entretien de qualification (30 min), présentation des tarifs partenaires, et envoi d'un kit de démarrage (gateway de développement + accès compte OEM de test).
Les stations de pompage — relevage d'eaux usées, adduction d'eau potable, irrigation, drainage industriel — partagent un défi commun : elles sont dispersées sur de vastes territoires, souvent dans des zones difficiles d'accès, et pourtant critiques. Une pompe en défaut non détectée peut provoquer un débordement, une rupture d'approvisionnement, ou un dommage matériel significatif.
\nLa supervision à distance n'est plus un luxe pour ces installations : c'est une nécessité opérationnelle et, dans certains secteurs réglementés (eau potable, assainissement), une exigence de conformité.
\nUn exploitant multi-sites de stations de pompage gère typiquement entre 20 et 200 sites, avec une équipe de quelques techniciens de maintenance couvrant des centaines de kilomètres carrés. Les stations sont souvent :
\nSans supervision à distance, le mode de fonctionnement est réactif : un appel d'usager, une alarme locale (sirène, voyant rouge), ou une ronde périodique signale le problème. Le temps de réponse se compte en heures, parfois en jours pour les sites les plus éloignés.
\nDéplacements inutiles :\nEntre 30 et 50 % des interventions suite à alarme sont des \"faux déplacements\" — l'opérateur arrive sur site pour constater que le problème s'est résolu seul (re-démarrage automatique de la pompe, coupure électrique transitoire) ou que le problème ne nécessite pas d'intervention immédiate. Un déplacement coûte entre 400 et 700 € (véhicule, temps, indemnités).
\nInterventions mal préparées :\nSans diagnostic à distance, le technicien ne sait pas ce qu'il va trouver et ne peut pas emporter les pièces de rechange adéquates. Un aller-retour supplémentaire pour chercher une pièce peut doubler le coût d'intervention.
\nDétection tardive des incidents :\nUne pompe qui cavite (aspiration d'air), qui fonctionne à sec, ou dont le rotor commence à se dégrader peut fonctionner plusieurs jours dans un état dégradé avant la panne franche. Pendant ce temps, la durée de vie de la pompe se réduit, et le risque d'arrêt brutal augmente.
\nConformité réglementaire difficile :\nProduire les rapports annuels de qualité de service (RPQS pour l'eau potable, rapport annuel de l'exploitant pour l'assainissement) demande un travail de consolidation manuelle conséquent si les données ne sont pas archivées automatiquement.
\n┌──────────────────────────────────────────────────────────────────┐
│ Station de pompage SP-42 │
│ │
│ [Capteurs de mesure] │
│ ├── Niveau bâche : sonde à ultrasons ou pression relative 4-20mA │
│ ├── Débit : débitmètre électromagnétique (impulsions ou 4-20mA) │
│ ├── Courant moteur P1 : transformateur de courant (TA) │
│ ├── Courant moteur P2 : transformateur de courant │
│ └── Présence alimentation : contact sec sur TGBT │
│ ↓ │
│ [Coffret de régulation / Automate] │
│ ├── Siemens LOGO! 8 / S7-1200 │
│ ├── Schneider M221 / M241 │
│ ├── Wago PFC200 │
│ └── Coffret \"vrai de vrai\" relais + télémesure ancienne │
│ ↓ Modbus TCP ou RTU │
│ [Gateway Eziwan] ← Rail DIN, 24V DC │
│ └── 4G LTE Dual SIM ──────────────────────────────────────────┤
│ │
└──────────────────────────────────────────────────────────────────┘
│ Tunnel OpenVPN
▼
[Cloud Eziwan]
├── Base time-series (données horodatées)
├── Moteur d'alertes
└── Tableau de bord web + app mobile
│
▼
[Salle de conduite — téléopération]
[Application mobile — astreinte]
[Email/SMS — responsable exploitation]
| Automate | Protocole | Remarques |
|---|---|---|
| Siemens S7-1200 (firmware V4+) | Modbus TCP | MB_SERVER dans OB1 |
| Siemens LOGO! 8 (firmware ≥ 1.80) | Modbus TCP | Activer dans LOGO! Soft Comfort |
| Schneider M221 / M241 | Modbus TCP | EcoStruxure Machine Expert |
| Schneider M340 | Modbus TCP | EcoStruxure Control Expert |
| Wago PFC100 / PFC200 | Modbus TCP ou MQTT | MQTT natif sur PFC200 |
| Automates anciens sans Ethernet | Modbus RTU (RS-485) | Via port RS-485 de la gateway |
| Coffrets relais sans automate | Entrées TOR directes | Via module d'extension Eziwan |
Pour les nombreuses petites stations de relevage qui n'ont pas d'automate programmable — simplement un coffret de démarrage avec des contacteurs et des relais — la gateway Eziwan peut être connectée directement aux signaux terrain via un module d'extension d'entrées/sorties TOR :
\n[Contact sec \"Pompe 1 en marche\"] ──→ [Entrée TOR 1 gateway]
[Contact sec \"Défaut thermique\"] ──→ [Entrée TOR 2 gateway]
[Sonde niveau 4-20mA] ──→ [Entrée analogique gateway]
Cette approche permet d'équiper des stations existantes sans modifier le câblage ni installer un automate.
\nPour une station à 2 groupes moto-pompe (configuration la plus courante), voici les variables minimales à superviser :
\nVariables d'état (valeurs booléennes) :
\n%MW300 bits :
bit 0 : Pompe 1 en marche
bit 1 : Pompe 2 en marche
bit 2 : Défaut thermique pompe 1 (disjoncteur déclenché)
bit 3 : Défaut thermique pompe 2
bit 4 : Défaut disjoncteur général
bit 5 : Alimentation électrique présente
bit 6 : Niveau haut bâche atteint (pré-alarme)
bit 7 : Niveau très haut bâche (alarme)
bit 8 : Niveau bas bâche (risque fonctionnement à sec)
bit 9 : Mode manuel activé (maintenancier sur place)
bit 10 : Défaut sonde niveau (valeur hors plage ou absence signal)
Variables analogiques (registres 16 ou 32 bits) :
\n%MW100 : Niveau bâche (% × 10 → ex. 752 = 75.2%)
%MW101 : Débit instantané (L/min)
%MW102-103 : Volume journalier pompé (m³ × 1000, int32 sur 2 registres)
%MW104 : Courant moteur pompe 1 (A × 10 → ex. 142 = 14.2 A)
%MW105 : Courant moteur pompe 2 (A × 10)
%MW106 : Nombre de démarrages pompe 1 (compteur)
%MW107 : Nombre de démarrages pompe 2 (compteur)
%MW108-109 : Durée de marche cumulée P1 (minutes, int32)
%MW110-111 : Durée de marche cumulée P2 (minutes, int32)
%MW112 : Tension secteur (V × 10)
%MW113 : Code défaut détaillé (bitfield constructeur)
La surveillance du courant moteur est l'indicateur le plus riche pour la maintenance préventive des pompes :
\nDétection de cavitation : une pompe qui aspire de l'air présente un courant moteur inférieur à la normale (le fluide est moins dense). Indicateur précoce d'un problème de niveau ou d'aspiration.
\nDétection de fonctionnement à sec : le courant chute brutalement en dessous du courant nominal à vide. Risque de destruction de la garniture mécanique en quelques minutes.
\nDégradation du rotor : un rotor usé ou encrassé consomme plus de courant pour le même débit. Une dérive progressive du courant à débit constant indique une maintenance nécessaire.
\nProblème d'alimentation électrique : un courant déséquilibré entre les phases (sur une pompe triphasée) peut indiquer un câble défectueux ou un problème sur le réseau électrique du site.
\nConfigurer dans Eziwan une alerte sur le courant moteur : alerte si le courant dépasse 115 % de la valeur de référence (surcharge) ou descend en dessous de 60 % (cavitation/à sec). Ces deux seuils permettent de détecter les problèmes les plus courants avant la panne.
Un système d'alertes efficace pour une station de pompage doit être gradué pour éviter la fatigue d'alarme (trop d'alertes → les opérateurs les ignorent) tout en garantissant que les incidents critiques sont signalés immédiatement.
\nNiveau 1 — Information (email équipe conduite) :
\nDémarrage pompe 2 alors que pompe 1 est déjà en marche
→ Information uniquement (situation normale en pointe)
Niveau bâche > 75% alors que les deux pompes sont en marche
→ Vérification débit entrant inhabituellement élevé
Niveau 2 — Pré-alarme (email + notification app mobile) :
\nNiveau bâche > 85%
→ Situation anormale, surveiller l'évolution
Courant moteur > 110% de la valeur de référence pendant > 2 minutes
→ Surcharge légère, vérifier à la prochaine ronde
Aucune mise en marche des pompes depuis > 24h alors que niveau > 30%
→ Pompes peut-être en défaut silencieux
Niveau 3 — Alarme (SMS + email + webhook astreinte) :
\nNiveau bâche > 95%
→ Risque de débordement, intervention urgente
Défaut thermique pompe 1 ET pompe 2 simultanément
→ Station hors service, intervention immédiate
Courant moteur < 40% de la valeur nominale pendant > 30 secondes
→ Fonctionnement à sec probable, arrêt automatique conseillé
Perte d'alimentation électrique
→ Toutes les pompes s'arrêtent, vérifier groupe électrogène si disponible
Perte de connectivité gateway > 15 minutes
→ Impossible de savoir l'état de la station
Les alertes peuvent être configurées avec des plages horaires et une logique d'escalade :
\nDéfaut thermique pompe :
Heure ouvrée (8h-18h) → SMS technicien de service
Nuit / week-end → SMS astreinte + email responsable
Si pas d'acquittement en 30 minutes :
→ Appel téléphonique (webhook vers système de téléphonie)
→ SMS responsable de service
L'historique de données d'une station de pompage est un actif opérationnel précieux qui s'accumule dans le temps :
\nAnalyse de tendances à long terme :\nComparer les courbes de courant moteur de la pompe 1 en janvier 2024 et janvier 2025. Une dérive de +8 % indique un rotor en cours d'usure — programmez la maintenance préventive avant la panne, pendant l'arrêt hivernal.
\nCorrélation pluviométrie / débit entrant :\nPour les stations de relevage d'eaux usées, la corrélation entre les épisodes pluvieux et le débit entrant permet de dimensionner les capacités de stockage et d'identifier les intrusions d'eaux parasites dans le réseau.
\nOptimisation des paramètres de régulation :\nAnalyser les cycles de marche/arrêt : une pompe qui démarre plus de 15 fois par heure indique un problème de dimensionnement (pompe trop puissante, bâche trop petite) ou de régulation.
\nPour les exploitants sous délégation de service public (DSP) ou contrat d'affermage, plusieurs obligations de reporting s'appliquent :
\nRPQS — Rapport sur le Prix et la Qualité du Service :\nExigé chaque année par le Code Général des Collectivités Territoriales (CGCT) pour les services d'eau potable et d'assainissement. Doit inclure des indicateurs de performance : taux de conformité des prélèvements, taux de coupures, volume produit/distribué, rendement du réseau.
\nLe tableau de bord Eziwan génère automatiquement les données brutes pour ces indicateurs (volumes pompés, durées d'indisponibilité, nombre d'incidents).
\nRapports de surveillance autorisés :\nCertains ouvrages de prélèvement ou de rejet nécessitent des rapports périodiques pour la DREAL (Direction Régionale de l'Environnement, de l'Aménagement et du Logement). Les données d'historique Eziwan peuvent être exportées en CSV pour alimenter ces rapports.
\nConservation des données :\nPour l'eau potable, les données de surveillance doivent être conservées au minimum 5 ans. Eziwan permet de configurer la rétention des données jusqu'à plusieurs années selon l'abonnement.
\nUn syndicat intercommunal d'assainissement dans les Pays de la Loire supervise 65 stations de relevage réparties sur un territoire de 1 500 km². Avant le déploiement Eziwan :
\nDéplacements évités grâce au diagnostic à distance :
\nRésultats mesurés :
\nNos clients exploitants de stations de pompage constatent en moyenne une réduction de 35 à 55 % des déplacements dans les 12 premiers mois après déploiement.
\nPour la configuration sécurisée de l'accès distant sur les automates de station de pompage, voir VPN industriel vs TeamViewer et Comment connecter un S7 à distance.
La gateway fonctionne-t-elle sur les coffrets de relevage anciens sans automate programmable ?
\nOui. Via le module d'extension d'entrées/sorties TOR, la gateway peut lire directement les contacts secs des coffrets de démarrage électromécaniques : état pompe, défaut thermique, présence alimentation. Pour les sondes de niveau analogiques 4-20 mA, une entrée analogique directe est disponible. Cette approche évite d'installer un automate sur des stations existantes.
\nCombien de variables peut-on superviser sur une petite station (LOGO! 8 ou M221) ?
\nLe LOGO! 8 Siemens supporte jusqu'à 64 blocs Modbus configurables et le M221 Schneider jusqu'à 100 mots %MW en Modbus TCP. Pour une station standard à 2 pompes, le plan de supervision décrit dans cet article (environ 20 variables) est largement dans les limites de ces automates. La gateway Eziwan elle-même n'a pas de limite pratique sur le nombre de variables collectées.
\nLes données de volume pompé sont-elles suffisamment précises pour les rapports RPQS ?
\nCela dépend de la précision du débitmètre installé (typiquement ±0,5 % à ±2 % pour un débitmètre électromagnétique). La gateway collecte et horodate les impulsions ou la valeur analogique du débitmètre avec une résolution configurable (toutes les secondes si nécessaire). L'historique Eziwan peut être exporté en CSV avec toutes les mesures brutes pour les calculs de volume intégrés requis par le RPQS.
\nComment gérer les micro-coupures électriques fréquentes sur certains sites ruraux ?
\nLa gateway Eziwan démarre en moins de 30 secondes après une coupure d'alimentation et rétablit le tunnel VPN automatiquement. Les données collectées avant la coupure sont déjà transmises au cloud. Si la coupure dure plus de 30 s, la gateway bufférise les données dès le redémarrage et les retransmet. Pour les sites avec coupures très fréquentes (plusieurs fois par jour), un UPS 24 V DC de petite capacité (quelques minutes d'autonomie) suffit à absorber les micro-coupures.
\nEst-il possible d'envoyer des commandes à distance vers les pompes (réarmement, démarrage) ?
\nOui, via l'écriture de registres Modbus (FC=06 ou FC=16). Cette fonctionnalité doit être activée explicitement dans la configuration Eziwan et protégée par des droits d'accès restrictifs (seuls certains comptes peuvent écrire). La traçabilité complète est assurée : chaque écriture de registre est journalisée avec l'identité de l'opérateur et l'horodatage.
\nVous exploitez des stations de pompage dispersées et souhaitez mettre en place une supervision centralisée ?
Voir la solution pour exploitants multi-sites →
Présentation de l'architecture, des fonctionnalités dédiées aux exploitants eau/énergie, et des formules d'abonnement adaptées aux flottes de 10 à 500 sites.
Modbus TCP est le protocole de collecte de données automate le plus répandu dans l'industrie française. Il équipe des dizaines de millions d'équipements installés depuis plus de 40 ans. Si vous intégrez la connectivité distante dans vos projets, vous allez rencontrer Modbus TCP — autant le comprendre en profondeur.
\nCe guide couvre l'essentiel pour un praticien : histoire, structure de trame byte par byte, Function Codes, comparatif avec les protocoles concurrents, optimisation des performances, sécurité, et exemple de code Python complet et fonctionnel.
\nModbus a été créé en 1979 par Modicon (aujourd'hui absorbé par Schneider Electric) pour faire communiquer les premiers automates programmables Modicon 084. C'était un protocole série (RS-232 puis RS-485), maître/esclave, conçu pour une chose unique : lire et écrire des valeurs numériques sur des équipements de terrain.
\nLa simplicité était le principe fondamental de conception :
\nModbus RTU (Remote Terminal Unit) : version binaire compacte pour RS-485. Les données sont transmises en binaire, avec un CRC 16 bits pour la détection d'erreurs. Toujours très répandu sur les instruments de terrain (compteurs d'énergie, capteurs de pression, variateurs de fréquence).
\nModbus ASCII : version lisible en ASCII, pour les liaisons RS-232. Moins efficace (2 octets par byte de données), obsolète dans les nouvelles installations.
\nVers 1996-1999, avec la généralisation d'Ethernet dans les usines, Modbus TCP a encapsulé le protocole dans des trames TCP/IP. La révision a été chirurgicale :
\nL'avantage : tout équipement existant connaissant Modbus RTU pouvait migrer vers Modbus TCP avec des changements minimes. L'inconvénient : les lacunes de sécurité originales ont été conservées.
\n┌─────────────────────────────────────────────────────────────────────┐
│ Trame Modbus TCP │
├──────────────────────────────────────────┬──────────────────────────┤
│ MBAP Header (7 octets) │ PDU │
├──────────┬──────────┬──────────┬─────────┼────────────┬─────────────┤
│ Trans.ID │ Proto.ID │ Length │ Unit ID │ Func.Code │ Data │
│ 2 bytes │ 2 bytes │ 2 bytes │ 1 byte │ 1 byte │ n bytes │
└──────────┴──────────┴──────────┴─────────┴────────────┴─────────────┘
Transaction Identifier (2 octets) :\nNuméro libre choisi par le client, retourné à l'identique dans la réponse. Permet de corréler les réponses aux requêtes dans le cas de connexions persistantes avec plusieurs requêtes en vol. En pratique, la plupart des clients utilisent un compteur simple (00 01, 00 02, 00 03...) ou un identifiant fixe (00 00) s'ils fonctionnent en mode requête/réponse séquentiel.
\nProtocol Identifier (2 octets) :\nToujours 00 00 pour Modbus. Cette constante existe pour permettre une éventuelle extension à d'autres protocoles via le même port, mais n'a jamais été utilisée.
Length (2 octets) :\nNombre d'octets qui suivent, en big-endian. Inclut le Unit ID et le PDU, mais pas les 4 premiers octets du MBAP Header. Pour une requête FC=03 de 10 registres : 6 octets (1 Unit ID + 1 FC + 2 adresse + 2 count) → 00 06.
Unit Identifier (1 octet) :\nIdentifiant de l'esclave Modbus. Sur les automates directement connectés (S7-1200 avec MB_SERVER, M340 avec serveur Modbus intégré), la valeur est typiquement 1 ou 255. Sur les passerelles Modbus RTU→TCP, cet identifiant correspond à l'adresse de l'esclave RTU sur le bus RS-485.
\nLecture de 10 registres holding à partir de l'adresse 100 (ex: %MW100 sur Schneider M340) :
\nRequête client (hex) : 00 01 00 00 00 06 FF 03 00 64 00 0A
Décodage byte par byte :
00 01 → Transaction ID = 1
00 00 → Protocol ID = 0 (Modbus standard)
00 06 → Length = 6 (Unit ID + FC + 2 adresse + 2 count)
FF → Unit ID = 255 (0xFF = CPU locale M340)
03 → Function Code = Read Holding Registers
00 64 → Starting Address = 100 (0x0064 en big-endian)
00 0A → Quantity = 10 registres (0x000A)
Réponse automate (hex) : 00 01 00 00 00 17 FF 03 14 [20 octets]
Décodage :
00 01 → Transaction ID = 1 (même que la requête — corrélation)
00 00 → Protocol ID = 0
00 17 → Length = 23 (1 UID + 1 FC + 1 ByteCount + 20 données)
FF → Unit ID = 255
03 → Function Code = 3 (confirme que c'est une réponse normale)
14 → Byte Count = 20 (10 registres × 2 octets = 0x14 hex)
[suivi de 20 octets de données — 10 valeurs uint16 big-endian]
Quand l'automate ne peut pas traiter une requête, il renvoie un code d'exception :
\nRéponse exception (hex) : 00 01 00 00 00 03 FF 83 02
83 → FC + 0x80 = 3 + 128 = 131 → indique une réponse d'exception sur FC=3
02 → Exception code : Illegal Data Address
| Code | Nom | Signification | Cause courante |
|---|---|---|---|
| 01 | Illegal Function | FC non supporté | Automate ne supporte pas cette FC |
| 02 | Illegal Data Address | Adresse hors plage | Registre > limite automate |
| 03 | Illegal Data Value | Valeur de données invalide | Count > 125 (FC=03) |
| 04 | Server Device Failure | Erreur interne | Serveur Modbus pas initialisé |
| 05 | Acknowledge | Traitement long en cours | Rare en pratique |
| 06 | Server Device Busy | Serveur occupé | Trop de connexions simultanées |
| 0A | Gateway Path Unavailable | Chemin passerelle indisponible | Esclave RTU non joignable |
| 0B | Gateway Target Device Failed | Esclave non répondant | Esclave RTU éteint ou en panne |
FC=01 : Read Coils → bits de sortie (écriture autorisée)
FC=02 : Read Discrete Inputs → bits d'entrée (lecture seule)
Requête : FC AddrH AddrL QuantH QuantL
01 00 00 00 00 00 10 (lecture 16 coils depuis @0)
Réponse : FC ByteCount Coil_Data
01 02 [2 bytes = 16 bits d'état]
Note : les coils sont packés en bits, LSB first.
Byte1 bit0 = Coil@0, Byte1 bit1 = Coil@1, etc.
Lecture de registres de 16 bits en lecture/écriture. Limite : 125 registres maximum par requête.
\nIdentique à FC=03 mais pour les registres \"entrée\" (lecture seule). Sur Schneider M340, correspond aux %IW. Sur la plupart des automates, peu utilisé car les mesures analogiques sont copiées dans des %MW (Holding Registers).
FC=06 : Write Single Register
Requête : FC AddrH AddrL ValueH ValueL
06 00 64 00 64 01 F4 (écriture 500 à l'adresse 100)
FC=16 : Write Multiple Registers (jusqu'à 123 registres par requête)
Requête : FC AddrH AddrL CountH CountL ByteCount Values...
10 00 64 00 05 01 2C [données]
Attention en écriture (FC=06, FC=16) : n'écrire des registres que si vous êtes certain de l'adressage et de l'impact sur le programme automate. Une écriture sur un registre de consigne modifie immédiatement le comportement du process. Tester toujours sur un automate de développement ou hors production avant déploiement.
Ces trois protocoles coexistent dans les architectures IIoT modernes. Ils servent des couches différentes et ne sont pas en compétition directe.
\n| Critère | Modbus TCP | OPC-UA | MQTT |
|---|---|---|---|
| Ancienneté | 1979 (RTU), ~1996 (TCP) | 2008 | 1999 |
| Modèle | Client/Serveur (polling) | Client/Serveur + Pub/Sub | Pub/Sub (broker) |
| Couche | Communication terrain | Interopérabilité systèmes | Transport IoT/cloud |
| Sécurité native | Aucune | TLS + authentification certificat | TLS + authentification |
| Charge CPU automate | Très faible | Élevée | Faible à moyenne |
| Automates anciens | Universel (40 ans) | Automates modernes seulement | Via gateway |
| Découverte automatique | Non | Oui (namespace OPC) | Non |
| Données structurées | Non (registres plats) | Oui (types, structs, arrays) | Oui (JSON/CBOR) |
| Latence | Faible (polling) | Très faible (pub/sub) | Très faible |
Utilisez Modbus TCP si :
\nUtilisez OPC-UA si :
\nUtilisez MQTT pour le transport cloud si :
\nL'architecture cible pour l'IIoT cloud :
\n[Automate] ──Modbus TCP / OPC-UA──→ [Gateway] ──MQTT over TLS──→ [Cloud]
La gateway convertit et transporte. Elle fait le pont entre le monde OT (Modbus/OPC-UA) et le monde cloud (MQTT/REST).
\nModbus TCP n'a aucun mécanisme de sécurité natif :
\nConséquence pratique : si votre automate est accessible depuis Internet (port 502 ouvert), il est totalement vulnérable. Si quelqu'un se connecte à votre réseau OT (physiquement ou via une brèche), il peut lire et modifier tous les registres.
\nSegmentation réseau (mesure primaire) :\nConfiner le trafic Modbus TCP à un réseau OT isolé. La gateway Eziwan est dans ce réseau OT ; la communication vers le cloud passe par un tunnel VPN, pas par une exposition du port 502.
\nFiltrage IP sur l'automate (mesure secondaire) :\nCertains automates récents (Schneider M340 firmware ≥ 2.60, Siemens S7-1200 firmware V4.x avec fonctions FIREWALL) supportent un filtrage IP : seule l'adresse IP de la gateway Eziwan est autorisée à se connecter sur le port 502.
\nModbus Security (mesure avancée) :\nLa Modbus Organization a publié en 2018 une extension \"Modbus Security\" (transport TLS pour Modbus TCP) sur le port 802. Cette extension n'est pas encore largement supportée par les automates du marché, mais est disponible sur certains équipements récents.
\nLa règle d'or : regrouper les lectures en plages contiguës. Lire 100 registres contigus en une requête est beaucoup plus efficace que 100 requêtes d'un registre chacune :
\nConfiguration inefficace (100 requêtes) :
Lire %MW0 → 1 requête (2 octets de données)
Lire %MW50 → 1 requête
Lire %MW99 → 1 requête
... 97 requêtes supplémentaires ...
Latence totale : 100 × (aller-retour réseau) ≈ 100 × 5ms = 500ms
Configuration optimisée (1 requête) :
Lire %MW0 à %MW99 → 1 requête (200 octets de données)
Latence totale : 1 × 5ms = 5ms
La gateway Eziwan groupe automatiquement les variables configurées en plages contiguës. Pour maximiser ce grouping, organiser vos variables de supervision dans des zones mémoire adjacentes.
\nChaque requête Modbus TCP reçue est traitée par l'automate en fin de cycle programme. Sur un M340 avec un cycle de 10 ms, 10 requêtes Modbus simultanées peuvent allonger le cycle de 1 à 3 ms.
\nRecommandation : ne pas dépasser 1 requête Modbus par cycle automate pour les applications avec contrainte temps-réel. Réduire la fréquence de polling si le cycle s'allonge.
\n\"\"\"
Collecte Modbus TCP industrielle avec gestion d'erreurs robuste
Compatible Schneider M340, Siemens S7-1200, Wago, Allen-Bradley...
Testé avec pymodbus >= 3.0
Installation :
pip install pymodbus loguru
\"\"\"
from pymodbus.client import ModbusTcpClient
from pymodbus.exceptions import ModbusException, ConnectionException
from loguru import logger
import struct
import time
from dataclasses import dataclass
from typing import Optional
# ─── Configuration ────────────────────────────────────────────────────────────
HOST = \"192.168.1.20\" # IP automate Schneider M340
PORT = 502 # Port Modbus TCP
UNIT_ID = 255 # 255 pour CPU locale M340, 1 pour S7-1200
TIMEOUT = 3 # Timeout en secondes
RETRIES = 3 # Nombre de tentatives avant abandon
# ─── Structure de données ─────────────────────────────────────────────────────
@dataclass
class VariablesProcess:
temperature_c: float = 0.0
debit_lmin: int = 0
pression_bar: float = 0.0
pompe_1_marche: bool = False
pompe_2_marche: bool = False
code_defaut: int = 0
compteur_production: int = 0
timestamp: float = 0.0
# ─── Client Modbus avec reconnexion automatique ───────────────────────────────
class ModbusCollecteur:
\"\"\"Collecteur Modbus TCP avec gestion de reconnexion et retry.\"\"\"
def __init__(self, host: str, port: int = 502, unit_id: int = 1):
self.host = host
self.port = port
self.unit_id = unit_id
self.client: Optional[ModbusTcpClient] = None
self._connexions_ok = 0
self._connexions_echec = 0
def connecter(self) -> bool:
\"\"\"Établit la connexion TCP vers l'automate.\"\"\"
try:
self.client = ModbusTcpClient(
self.host,
port=self.port,
timeout=TIMEOUT,
retries=1, # Retries gérés par notre code
reconnect_delay=0, # Pas de reconnexion automatique
)
if self.client.connect():
self._connexions_ok += 1
logger.info(f\"Connecté à {self.host}:{self.port}\")
return True
else:
self._connexions_echec += 1
logger.warning(f\"Connexion refusée par {self.host}:{self.port}\")
return False
except Exception as e:
logger.error(f\"Erreur connexion : {e}\")
return False
def deconnecter(self):
if self.client:
self.client.close()
self.client = None
def lire_holding_registers(
self, adresse: int, count: int
) -> Optional[list[int]]:
\"\"\"Lit des registres avec retry automatique.\"\"\"
for tentative in range(1, RETRIES + 1):
try:
if not self.client or not self.client.is_socket_open():
if not self.connecter():
time.sleep(1)
continue
result = self.client.read_holding_registers(
address=adresse, count=count, slave=self.unit_id
)
if result.isError():
exception_code = getattr(result, 'exception_code', '?')
logger.warning(
f\"Erreur Modbus addr={adresse} count={count} \"
f\"exception_code={exception_code}\"
)
# Exception 04 (server busy) → attendre avant retry
if exception_code == 6:
time.sleep(0.5)
self.deconnecter()
continue
return result.registers
except ConnectionException:
logger.warning(f\"Connexion perdue (tentative {tentative}/{RETRIES})\")
self.deconnecter()
time.sleep(0.5)
except Exception as e:
logger.error(f\"Erreur inattendue : {e}\")
self.deconnecter()
time.sleep(1)
logger.error(f\"Échec lecture après {RETRIES} tentatives — addr={adresse}\")
return None
@staticmethod
def registres_to_float32_abcd(reg_high: int, reg_low: int) -> float:
\"\"\"Décode 2 registres 16-bit en float32 IEEE754 big-endian (ABCD).\"\"\"
raw = struct.pack(\">HH\", reg_high, reg_low)
return struct.unpack(\">f\", raw)[0]
@staticmethod
def registres_to_int32(reg_high: int, reg_low: int) -> int:
\"\"\"Décode 2 registres en entier 32-bit signé big-endian.\"\"\"
raw = struct.pack(\">HH\", reg_high, reg_low)
return struct.unpack(\">i\", raw)[0]
# ─── Lecture des variables process ───────────────────────────────────────────
def lire_variables(collecteur: ModbusCollecteur) -> Optional[VariablesProcess]:
\"\"\"
Lecture optimisée : 1 seule requête Modbus pour toutes les variables.
Plan mémoire (M340 EcoStruxure) :
%MW100 : Temperature (int16, ×0.1 → °C)
%MW101 : Débit (int16, L/min)
%MW102-103 : Pression (float32 ABCD, bar)
%MW104 : États machine (bits 0-7)
%MW105 : Code défaut actif
%MW106-107 : Compteur production (int32)
\"\"\"
# 1 requête pour %MW100 à %MW107 (8 registres)
registres = collecteur.lire_holding_registers(adresse=100, count=8)
if registres is None:
return None
vars_process = VariablesProcess(
temperature_c = registres[0] * 0.1, # %MW100
debit_lmin = registres[1], # %MW101
pression_bar = ModbusCollecteur.registres_to_float32_abcd( # %MW102+103
registres[2], registres[3]),
pompe_1_marche = bool(registres[4] & 0x0001), # %MW104 bit0
pompe_2_marche = bool(registres[4] & 0x0002), # %MW104 bit1
code_defaut = registres[5], # %MW105
compteur_production = ModbusCollecteur.registres_to_int32( # %MW106+107
registres[6], registres[7]),
timestamp = time.time(),
)
return vars_process
# ─── Boucle principale ────────────────────────────────────────────────────────
def main():
collecteur = ModbusCollecteur(HOST, PORT, UNIT_ID)
INTERVALLE = 5 # secondes entre chaque collecte
logger.info(f\"Démarrage collecte Modbus TCP — {HOST}:{PORT} — cycle {INTERVALLE}s\")
while True:
try:
vars_process = lire_variables(collecteur)
if vars_process:
logger.info(
f\"T={vars_process.temperature_c:.1f}°C \"
f\"Q={vars_process.debit_lmin}L/min \"
f\"P={vars_process.pression_bar:.2f}bar \"
f\"P1={'ON' if vars_process.pompe_1_marche else 'OFF'} \"
f\"Défaut={vars_process.code_defaut}\"
)
# Ici : publier via MQTT, API REST, ou base time-series
# mqtt_client.publish(\"usine/ligne3/variables\", vars_process)
else:
logger.warning(\"Collecte échouée — attente 10s avant retry\")
time.sleep(10)
continue
time.sleep(INTERVALLE)
except KeyboardInterrupt:
logger.info(\"Arrêt demandé.\")
collecteur.deconnecter()
break
if __name__ == \"__main__\":
main()
Ce code illustre les bonnes pratiques pour une collecte Modbus TCP en Python : regroupement des lectures, gestion des exceptions, reconnexion automatique, et décodage des types complexes. En production, la gateway Eziwan gère toutes ces fonctions nativement — sans nécessiter de script Python sur site.
Pourquoi le port Modbus TCP est-il 502 et non un port standard comme 80 ou 443 ?
\nLe port 502 a été officiellement assigné à Modbus par l'IANA (Internet Assigned Numbers Authority) lors de la standardisation de Modbus TCP dans les années 1990. Il n'y avait alors pas de raison de réutiliser des ports applicatifs IT existants. C'est un port enregistré (< 1024), donc son usage en serveur nécessite des droits root sur Linux — ce que les firmwares industriels gèrent nativement.
\nQuelle est la limite de registres lisibles en une seule requête FC=03 ?
\nLa limite est de 125 registres par requête FC=03 (Read Holding Registers), définie dans la spécification Modbus officielle. Soit 250 octets de données utiles maximum par requête. Pour FC=16 (Write Multiple Registers), la limite est de 123 registres par requête. La gateway Eziwan gère automatiquement le découpage si une plage demandée dépasse ces limites.
\nModbus TCP supporte-t-il plusieurs connexions client simultanées ?
\nOui, mais c'est l'automate qui définit la limite. Le Schneider M340 accepte jusqu'à 16 connexions simultanées, le Siemens S7-1200 jusqu'à 8 (via MB_SERVER). Au-delà, l'automate renvoie une exception 06 (Server Busy). En pratique, une gateway de collecte + un outil de diagnostic + un SCADA local atteignent facilement 3 connexions simultanées — à surveiller.
\nModbus TCP peut-il être chiffré ?
\nLe standard Modbus TCP natif (port 502) n'est pas chiffré. Une extension \"Modbus Security\" sur port 802 avec TLS existe depuis 2018, mais est rarement supportée par les automates actuels. La réponse pratique est de confiner Modbus TCP à un réseau OT isolé et de faire passer toute communication vers l'extérieur via un tunnel VPN chiffré (comme OpenVPN d'Eziwan) — le chiffrement est assuré par la couche de transport, pas par Modbus lui-même.
\nEst-ce que pymodbus est la seule bibliothèque Python pour Modbus TCP ?
\nNon. Les alternatives principales sont minimalmodbus (plus simple pour Modbus RTU), umodbus (léger, faible empreinte mémoire), et pyModbusTCP (purement TCP, sans dépendances). Pour des projets industriels en Python, pymodbus >= 3.0 reste le choix le plus complet avec gestion des exceptions, reconnexion et support des deux modes (RTU et TCP).
Comment déboguer un échange Modbus TCP sans accès à l'automate ?
\nUtiliser Modbus Slave (Windows) comme simulateur d'automate local, ou diagslave (ligne de commande, multiplateforme). Ces outils simulent un serveur Modbus TCP répondant à des adresses configurables. Idéal pour tester une configuration de collecte sans risquer de toucher un automate en production.
\nVotre automate parle Modbus TCP mais vous n'êtes pas sûr de la compatibilité avec votre version firmware ?
Tester la compatibilité de votre automate →
Voir aussi : Modbus TCP avec un Schneider M340 et la documentation Siemens S7 pour les configurations spécifiques.
La France est le premier pays agricole d'Europe. Pourtant, les exploitations agricoles françaises font face à une pression croissante : hausse des coûts de l'énergie, réglementations environnementales renforcées, manque de main-d'œuvre qualifiée, et exigences de traçabilité des filières agroalimentaires. L'Internet des Objets industriel (IIoT) offre des réponses concrètes à ces défis.
\nCe guide présente les principaux cas d'usage de l'IoT agricole en France, les équipements compatibles, les coûts et le ROI, et comment mettre en œuvre une solution de supervision agricole robuste en zone rurale — même sans connexion fibre.
\nL'agriculture moderne utilise déjà de nombreux équipements électroniques et électromécaniques : systèmes d'irrigation automatisés, ventilateurs de bâtiments d'élevage, tanks de refroidissement du lait, silos de stockage, serres climatisées, pompes de forage. La grande majorité de ces équipements disposent d'interfaces de communication (Modbus RTU, 4-20mA, sorties impulsions) qui permettent une connexion IoT sans remplacement.
\nCe que l'IoT apporte à l'agriculture :
\nLes bâtiments d'élevage hors-sol (porcheries, poulaillers, vacheries laitières) sont particulièrement adaptés à la supervision IoT. Les paramètres critiques à surveiller sont :
\nConditions climatiques bâtiment :
\nÉquipements de ventilation :
\nAlimentation et eau :
\nCapteurs compatibles et interfaces :
\n| Paramètre | Capteur recommandé | Interface |
|---|---|---|
| Température/Humidité bâtiment | Sensirion SHT31, Rotronic HF5 | Modbus RS-485 ou 4-20mA |
| CO₂ | Senseair S8, COZIR-Blink | Modbus RTU ou UART |
| NH₃ (ammoniac) | Membrapor NH3/M-100, Winsen ZE07 | 4-20mA ou Modbus |
| Niveau silo | Pepperl+Fuchs UC6000, SICK UM30 | 4-20mA ou IO-Link |
| Débitmètre eau | Sontex Supercal 5, Itron Actaris | Impulsion ou Modbus |
Seuils d'alerte typiques pour les bâtiments d'élevage :
\n| Paramètre | Zone verte | Zone orange (alerte) | Zone rouge (urgence) |
|---|---|---|---|
| Température porcherie engraissement | 18-22°C | < 15°C ou > 26°C | < 10°C ou > 30°C |
| Humidité bâtiment avicole | 50-70% | > 80% | > 90% |
| CO₂ volaille | < 3000 ppm | > 3000 ppm | > 5000 ppm |
| NH₃ porc | < 10 ppm | > 10 ppm | > 20 ppm (seuil réglementaire) |
Le refroidissement du lait est une obligation réglementaire (arrêté du 15 septembre 2004 modifié) : le lait de vache doit être refroidi à 8°C dans les 2 heures suivant la traite, et maintenu à 4°C maximum jusqu'à l'enlèvement.
\nUn non-respect de ces températures entraîne :
\nSupervision IoT du tank à lait :
\nLa plupart des tanks à lait récents (Boumatic, Mueller, DeLaval, GEA, Lemmer-Fullwood) disposent d'un port RS-232 ou RS-485 Modbus pour la supervision. Les paramètres accessibles incluent :
\nLe Gateway Eziwan se connecte au tank via RS-232 ou RS-485 et remonte les données vers le cloud avec un polling configurable de 5 minutes. Une alerte SMS est envoyée si la température dépasse 8°C pendant plus de 15 minutes.
\nCas client : un éleveur laitier breton gérant 3 tanks à lait (exploitation de 120 vaches) a évité 2 refus de collecte en 6 mois grâce aux alertes SMS de nuit (panne compresseur détectée à 2h du matin, intervention à 4h avant la collecte à 6h). Économie : 2 × 800 L × 0,40€/L = 640€ de perte évitée, plus les pénalités qualité.
\nLes serres horticoles représentent un investissement important (50 à 300 €/m²) dont la rentabilité dépend du maintien des conditions climatiques optimales. La supervision IoT permet de détecter les défauts (panne de chauffage, ventilation bloquée, rupture de film plastique) avant qu'ils ne provoquent des dommages irréversibles sur les cultures.
\nParamètres à surveiller en serre :
\n| Paramètre | Importance | Interface |
|---|---|---|
| Température air (°C) | Critique | PT100/PT1000 ou Modbus |
| Humidité relative (%) | Haute | Modbus RS-485 |
| Rayonnement solaire (W/m²) | Moyenne | 4-20mA (pyranomètre) |
| CO₂ ambiant (ppm) | Haute (si enrichissement CO₂) | Modbus RS-485 |
| Température feuille (°C) | Optionnelle | Thermocouple |
| Consommation eau irrigation (m³/j) | Haute | Impulsion ou Modbus |
| Température eau nutrition (°C) | Haute (hors-sol) | PT100 ou 4-20mA |
| EC eau nutrition (mS/cm) | Haute (hors-sol) | 4-20mA |
| pH eau nutrition | Haute (hors-sol) | 4-20mA |
Équipements de serre supervisables :
\nROI supervision serre maraîchère :\nPour une serre de 5 000 m² de tomates (production annuelle ~500 t, prix revente ~0,80€/kg = 400 000€ CA/an), une panne de chauffage non détectée la nuit en mars peut détruire l'intégralité d'une plantation — perte de 100 000 à 200 000€. Le coût d'un gateway Eziwan avec alerte SMS : 500€ + 100€/an d'abonnement. ROI immédiat.
\nL'irrigation représente 45% de la consommation d'eau industrielle en France. La réglementation se durcit (arrêtés de restriction en étiage, redevances eau), rendant le pilotage précis de l'irrigation indispensable.
\nSupervision IoT de l'irrigation :
\nConformité réglementaire :\nLes exploitations prélevant plus de 1 000 m³/an d'eau souterraine ou superficielle doivent déclarer leurs prélèvements (article L214-1 du Code de l'environnement). Eziwan génère automatiquement les rapports mensuels de prélèvement pour transmission à la DDT/DREAL.
\nLe stockage des céréales représente un enjeu économique majeur. Des conditions de stockage inadéquates (température, humidité) peuvent provoquer des mycotoxines (aflatoxines, DON) ou des moisissures qui déclassent ou rendent la marchandise invendable.
\nParamètres à surveiller :
\nInterface : la plupart des systèmes de contrôle de silos modernes (Superchief, GSI Fan Controller, Brock NECO) disposent d'une sortie Modbus RS-485 ou d'un port RS-232.
\nLa grande majorité des exploitations agricoles françaises ne dispose pas de connexion fibre. La 4G LTE couvre 99,2% des communes françaises (source : Arcep 2025) mais la couverture à l'intérieur des bâtiments peut être faible.
\nSolutions pour les zones de faible couverture :
\nAntenne 4G externe directionnelle : gain de 9 à 15 dBi, portée jusqu'à 30 km en ligne de vue directe, compatible avec tous les opérateurs. Montage en bout de pignon de bâtiment ou sur mât.
\nSIM multi-opérateurs Eziwan : teste les 3 opérateurs français (Orange, SFR, Bouygues) et se connecte au meilleur signal disponible. Augmente significativement la disponibilité en zone rurale.
\nLoRa + Gateway 4G : pour les capteurs très basse consommation et très éloignés (jusqu'à 15 km), une architecture LoRaWAN avec concentrateur LoRa connecté en 4G via l'Eziwan Gateway peut couvrir l'ensemble d'une exploitation.
\nConnexion satellite (dernier recours) : pour les sites sans aucune couverture 4G, une option satellite (Starlink low-latency ou Eutelsat ViaSat) peut être interfacée avec l'Eziwan Gateway. Latence 20-40 ms avec Starlink.
\nLa directive européenne 2008/120/CE (porcs), 2007/43/CE (poulets de chair) et 1999/74/CE (poules pondeuses) impose des niveaux minimaux de température, d'espace, de ventilation et d'éclairage. La supervision IoT permet de :
\nLes exploitations en zone vulnérable nitrates sont soumises au Programme d'Action Régional (PAR). La supervision des épandages et de la gestion des effluents (compteur de débit sur rampe d'épandage, niveau de fosse) facilite le respect des dates d'interdiction et des calculs de doses.
\nDe nombreuses filières (Label Rouge, AOP, IGP, agriculture biologique) exigent une traçabilité des conditions d'élevage ou de culture. Les données IoT Eziwan sont archivées et exportables pour alimenter les outils de traçabilité (Bluerex, Kite Consulting, OAD-Systèmes).
\n| Équipement | Coût indicatif |
|---|---|
| Gateway Eziwan + SIM M2M | 350 – 500 € |
| Antenne 4G externe (si nécessaire) | 80 – 150 € |
| Capteurs de température/humidité (×3) | 150 – 400 € |
| Câblage RS-485 (50 m) | 40 – 80 € |
| Installation (2h technicien) | 200 – 400 € |
| Total installation (1 bâtiment) | 820 – 1 530 € |
| Abonnement | Coût annuel |
|---|---|
| Plateforme Eziwan (1 gateway) | 120 – 240 € |
| SIM M2M (forfait 200 Mo/mois) | 60 – 120 € |
| Total annuel | 180 – 360 € |
Le plan France 2030 et les aides PCAE (Plan de Compétitivité et d'Adaptation des Exploitations) financent partiellement les équipements de modernisation agricole numérique. Les taux d'aide varient selon les régions et les dispositifs (30 à 50% des investissements éligibles). Consultez votre chambre d'agriculture ou votre conseiller FranceAgriMer pour les dispositifs applicables à votre projet.
\nL'IoT industriel est désormais accessible aux exploitations agricoles françaises, grâce à la 4G omniprésente, des capteurs Modbus standardisés, et des plateformes cloud économiques comme Eziwan. Les barrières techniques et financières qui freinaient l'adoption ont considérablement diminué.
\nPour un investissement initial de 1 000 à 2 000 € par bâtiment et moins de 400 €/an d'abonnement, un agriculteur bénéficie d'une supervision 24h/24 de ses équipements critiques, d'alertes SMS immédiates et d'un historique documenté pour ses obligations réglementaires.
\nProchaine étape : contactez l'équipe Eziwan pour une étude de faisabilité gratuite adaptée à votre exploitation et à votre type de production.
\nLa 4G est-elle disponible dans les zones rurales agricoles françaises ?\nLa couverture 4G en France métropolitaine dépasse 99% de la population mais seulement ~80% du territoire en superficie — certaines exploitations en zone blanche restent exclues. Pour ces zones : le réseau NB-IoT (NarrowBand-IoT) offre une meilleure pénétration en bâtiment et une plus grande portée, et des solutions satellite (Starlink) deviennent accessibles pour les sites totalement isolés. La vérification préalable de la couverture sur le site exact est indispensable avant tout déploiement.
\nPeut-on connecter un silo de stockage ou une cave coopérative existants sans remplacer les équipements ?\nDans la grande majorité des cas, oui. Les silos modernes ont des sondes de température et d'humidité avec sorties 4-20 mA ou RS485 Modbus — un gateway IoT se connecte directement. Pour les équipements plus anciens sans interface numérique, des capteurs de remplacement compatibles Modbus RTU sont disponibles à partir de 50 à 100 € par point de mesure.
\nQuelles obligations réglementaires la supervision IoT peut-elle aider à documenter ?\nEn élevage : les obligations de traçabilité sanitaire (prophylaxie, identification animale, conditions de transport — règlement UE 2016/429), le bien-être animal (températures, ventilation, densité), et les contrôles DPE/PAC peuvent s'appuyer sur les historiques de données IoT comme preuves. Le journal automatique de toutes les mesures avec horodatage certifié est un avantage significatif lors des contrôles.
\nEziwan accompagne les exploitants agricoles, les coopératives et les organismes stockeurs dans la supervision IoT de leurs installations. Notre solution s'adapte aux équipements existants sans remplacement, avec une connectivité 4G optimisée pour les zones rurales. Découvrir nos solutions →
\nLa question revient régulièrement lors des projets d'accès distant industriel : \"Pourquoi ne pas simplement utiliser TeamViewer ? C'est ce qu'on fait déjà pour le support informatique.\"
\nLa réponse courte : les réseaux OT ne sont pas des réseaux IT. Les automates qui y tournent pilotent des machines physiques — une commande erronée ou une intrusion peut avoir des conséquences industrielles, voire humaines. Les outils grand public ont été conçus pour un contexte radicalement différent.
\nCet article va au-delà de la réponse courte. Il explique le modèle de menace réel, détaille ce que la norme IEC 62443 exige, et présente les critères techniques pour évaluer une solution d'accès distant industriel.
\nPour comprendre pourquoi les accès distants OT sont différents, il faut connaître le modèle de Purdue (Purdue Enterprise Reference Architecture), référence internationale pour la segmentation des réseaux industriels.
\nNiveau 5 : Réseau d'entreprise (ERP, email, bureautique)
─────────────────────────────────────────────
Niveau 4 : Réseau IT de site (serveurs, SGBD, Active Directory)
─────────────────────────────────────────────
Niveau 3 : Réseau supervision (SCADA, MES, historiens)
─────────────────────────────────────────────
Niveau 2 : Réseau contrôle (IHM, ingénierie)
─────────────────────────────────────────────
Niveau 1 : Réseau terrain (automates, variateurs, capteurs)
─────────────────────────────────────────────
Niveau 0 : Process physique (capteurs, actionneurs, moteurs)
L'accès distant industriel concerne typiquement les niveaux 1 et 2 — les automates et les outils d'ingénierie. Ces niveaux ne doivent jamais être directement accessibles depuis les niveaux supérieurs sans contrôle, et encore moins depuis Internet.
\nLa segmentation entre les niveaux est la première ligne de défense. L'accès distant, par définition, traverse cette segmentation — d'où les exigences de sécurité renforcées.
\nUn réseau OT typique héberge :
\nCes équipements ont été conçus pour la fiabilité dans des environnements isolés, pas pour résister à des attaques réseau. Le protocole Modbus ne prévoit aucune authentification. S7Comm (Siemens) n'avait historiquement aucun chiffrement. Profinet, EtherNet/IP — la majorité des protocoles industriels supposent un réseau de confiance.
\nVoici comment se déroule typiquement une compromission d'un accès distant industriel non sécurisé :
\nPhase 1 — Reconnaissance (automatique, passive) :\nUn scanner automatique (Shodan, Censys, ou un script personnalisé) identifie l'IP publique de l'usine et découvre un port ouvert (VPN classique sur UDP 1194, port Modbus 502, port S7Comm 102). Cette phase ne génère aucun log suspect et dure quelques secondes.
\nPhase 2 — Exploitation de l'accès :\nSi le VPN n'est protégé que par un mot de passe faible (ou si les credentials ont été volés par phishing), l'attaquant entre. S'il s'agit d'un port Modbus directement exposé, il peut lire et écrire sans aucune authentification.
\nPhase 3 — Reconnaissance interne :\nDepuis l'accès obtenu, l'attaquant cartographie le réseau OT : quels automates sont accessibles, quelles variables sont lisibles, quelles zones process sont pilotées.
\nPhase 4 — Action malveillante :\nLes actions peuvent être immédiates (arrêt de production, modification de paramètres) ou discrètes (modification progressive de setpoints pour dégrader la qualité produit sans déclencher d'alarme).
\nLes attaques les plus dangereuses ne sont pas les plus spectaculaires. Une modification de ±5 % d'une consigne de dosage dans une installation chimique ou pharmaceutique peut rester indétectable pendant des jours, avec des conséquences sur la qualité du produit fini potentiellement catastrophiques.
L'ANSSI et le CISA (Cybersecurity and Infrastructure Security Agency, États-Unis) documentent régulièrement des incidents sur des accès distants industriels mal sécurisés :
\n[Internet] ──→ [Pare-feu usine : port ouvert] ──→ [Réseau OT] ──→ [Automate]
Ce modèle expose un point d'entrée sur Internet. Que ce soit un port VPN (UDP 1194 pour OpenVPN, UDP 500/4500 pour IPsec) ou un port applicatif (502, 102, 443), ce port est scruté en permanence.
\nCycle de vie d'un port exposé :
\n[Réseau OT] ──→ [Gateway : connexion sortante] ──→ [Cloud] ←── [Opérateur]
Ce qui change fondamentalement :
\nSi l'infrastructure cloud Eziwan était compromise (scénario hypothétique), un attaquant ne pourrait pas rebondir vers le réseau de l'usine — la connexion est unidirectionnelle du point de vue de l'initiation.
\nTeamViewer utilise bien un relay cloud (pas de connexion directe de l'attaquant à l'usine), mais les problèmes structurels sont différents :
\n| Problème | Explication |
|---|---|
| Infrastructure tierce | Les sessions passent par des serveurs TeamViewer. Si TeamViewer est compromis (comme en 2016), vos sessions le sont aussi. |
| Traçabilité dépendante de l'abonnement | Les journaux complets ne sont disponibles que sur les abonnements premium. En version gratuite, pas de log exportable. |
| Modèle d'authentification inadapté | Un code à 9 chiffres échangé par email n'est pas une authentification forte. |
| Pas d'isolation OT | TeamViewer donne accès au poste Windows qui l'exécute — et depuis ce poste, potentiellement au réseau OT entier. |
La norme IEC 62443 définit les exigences de cybersécurité pour les systèmes industriels. Pour l'accès distant, le Security Level 2 (SL2) — niveau recommandé pour la majorité des installations industrielles — exige :
\nSR 1.1 — Identification et authentification humaine :\nTout utilisateur accédant au système doit être individuellement identifié et authentifié. Les comptes partagés (un seul compte \"maintenance\" pour toute l'équipe) sont explicitement exclus.
\nSR 1.7 — Authenticité renforcée (Enhancement SL2) :\nL'authentification à deux facteurs (MFA) est requise pour les accès distants au niveau SL2. Un mot de passe seul n'est pas suffisant.
\nSR 2.6 — Accès via des réseaux non fiables :\nTout accès depuis Internet vers le réseau OT doit être chiffré, authentifié, et journalisé. Cette exigence est la traduction normative du tunnel sortant + MFA + logs d'audit.
\nSR 6.2 — Surveillance en continu :\nLes accès distants doivent être journalisés en permanence — qui s'est connecté, quand, depuis quelle adresse, pendant combien de temps.
\nL'ANSSI publie des guides spécifiques aux systèmes industriels. Ses cinq principes pour l'accès distant industriel :
\nL'ANSSI publie ces recommandations dans son guide \"Maîtrise du risque numérique lié aux systèmes industriels\", téléchargeable gratuitement sur ssi.gouv.fr. Sa lecture est recommandée à tout responsable de maintenance industrielle.
Tous les VPN ne se valent pas pour des gateways embarquées sur CPU ARM avec contraintes de reconnexion et de mémoire.
\n| Critère | OpenVPN | IPSec (IKEv2) | L2TP / PPTP |
|---|---|---|---|
| Transport | UDP ou TCP 443 | UDP 500/4500 (ESP/IKE) | UDP 1701 / TCP 1723 |
| Traversée pare-feu / NAT | Excellente (TCP 443 passe partout) | Moyenne (NAT-T requis) | Variable |
| Reconnexion après coupure 4G | Rapide (persist-tun, ~2-5 s) | Excellente (MOBIKE, quasi transparente) | Lente (15-60 s) |
| Primitives crypto | TLS, AES-256-GCM | AES-256, SHA-2 (IKEv2) | Faible (PPTP/MS-CHAPv2 déconseillé) |
| Authentification | Certificat X.509 par client | PSK ou certificats X.509 | Identifiant / mot de passe |
| Charge CPU (ARM Cortex-A) | Modérée | Faible (accélération matérielle possible) | Faible |
| Maturité / certifications | Largement audité, adoption massive | Certifié FIPS 140-2 | Ancien (PPTP à éviter) |
Le point clé pour l'industriel : la traversée des pare-feux et la reconnexion après coupure 4G. OpenVPN encapsule le tunnel dans TLS sur le port TCP 443 — le même que le HTTPS — ce qui lui permet de passer là où d'autres protocoles sont bloqués (pare-feu d'opérateur, proxy d'entreprise). Combiné à persist-tun, le tunnel se rétablit en quelques secondes après une bascule Dual SIM, sans renégociation complète.
Chaque technicien dispose de son propre certificat X.509, révocable individuellement depuis le dashboard cloud — une exigence forte pour la traçabilité NIS2.
\nIPSec reste le standard en entreprise et dans les environnements industriels régulés qui imposent des protocoles certifiés FIPS 140-2. Son mécanisme MOBIKE gère le changement d'adresse IP de façon quasi transparente — particulièrement adapté au failover Dual SIM. La configuration est plus complexe (PKI, certificats X.509, SA policies), mais l'interopérabilité avec les équipements réseau existants est maximale. Le Eziwan Gateway supporte également L2TP, PPTP et GRE pour les cas d'interopérabilité hérités.
\nL'architecture Eziwan applique les principes précédents de manière systématique :
\nSi vous utilisez actuellement TeamViewer sur des postes de supervision industriels, voici un processus de migration progressif :
\nPhase 1 — Déploiement parallèle (semaines 1-4) :
\nPhase 2 — Basculement progressif (semaines 5-8) :
\nPhase 3 — Désinstallation et nettoyage (semaine 9+) :
\nAprès le déploiement d'Eziwan, vérifier les points suivants :
\n| Critère | TeamViewer / AnyDesk | VPN classique (site-to-site) | Eziwan |
|---|---|---|---|
| Ports entrants exposés | Non (relay cloud tiers) | Oui | Non |
| Traçabilité des sessions | Partielle (abonnement) | Dépend de l'équipement | Complète + export |
| Conformité IEC 62443 SL2 | ✗ | Partielle | ✓ |
| Conformité recommandations ANSSI | ✗ | Partielle | ✓ |
| Authentification MFA intégrée | Optionnelle | Optionnelle | Intégrée |
| Intervention réseau sur site | Non | Oui | Non |
| Isolation OT complète | ✗ | Partielle | ✓ |
| Journaux d'audit exportables | Abonnement premium | Selon équipement | Standard |
| Reconnexion après coupure 4G | 30–60 s | 5–30 s | < 2 s (OpenVPN) |
| Déploiement sans compétence réseau | Oui | Non | Oui (ZTP) |
Pour une mise en œuvre concrète sur automate Siemens S7, lire Comment connecter un S7 à distance sans ouvrir de port. Pour les exigences IEC 62443 dans le détail, voir IEC 62443 et accès distant industriel.
TeamViewer n'est-il pas suffisant si l'on n'accède qu'à un poste de supervision, pas directement à l'automate ?
\nPas nécessairement. Le poste de supervision a généralement accès au réseau de niveau 1 (automates) via le logiciel SCADA. Une compromission du poste — que ce soit via TeamViewer ou via une autre faille — donne indirectement accès aux automates. L'isolation OT doit être pensée en termes de réseau, pas d'application.
\nWireGuard est-il une alternative viable à OpenVPN pour les gateways industrielles ?
\nWireGuard offre des performances supérieures et une codebase plus petite (mieux auditée), mais il présente une contrainte : il fonctionne uniquement en UDP, sans option TCP. Dans les réseaux où UDP est filtré (certains opérateurs mobiles, proxys d'entreprise), WireGuard peut échouer là où OpenVPN sur TCP 443 passerait. Pour les gateways 4G industrielles avec des connexions potentiellement capricieuses, OpenVPN reste le choix le plus universel.
\nPeut-on utiliser une solution VPN IPsec existante de l'entreprise plutôt qu'Eziwan ?
\nOui, si la solution existante répond aux critères IEC 62443 SL2 (comptes nominatifs, MFA, journaux exportables, moindre privilège). Le problème récurrent des VPN site-to-site d'entreprise appliqués à l'OT est l'absence de granularité : le VPN donne accès à tout un segment réseau plutôt qu'à un équipement spécifique. Eziwan peut compléter une solution VPN d'entreprise en ajoutant la granularité et les journaux d'audit.
\nL'ANSSI liste-t-elle des solutions d'accès distant approuvées pour l'OT ?
\nL'ANSSI ne publie pas de liste de solutions \"approuvées\" mais des critères d'évaluation. Pour les OIV et OSE, des prestataires qualifiés PRIS (Prestataires de Réponse aux Incidents de Sécurité) peuvent effectuer une évaluation formelle. Les critères ANSSI sont cohérents avec les exigences IEC 62443 SL2 décrites dans cet article.
\nCombien de temps faut-il pour migrer de TeamViewer à une solution VPN industrielle ?
\nSur un parc de moins de 20 sites, la migration peut se faire en 2 à 4 semaines : déploiement parallèle, formation des équipes, basculement progressif. Le point critique est la formation des techniciens au client VPN — prévoir 1 à 2 heures par personne. Le processus est détaillé dans la section 6 de cet article.
\nVotre organisation utilise actuellement TeamViewer ou un accès VPN classique sur un réseau OT ?
Télécharger le livre blanc cybersécurité OT →
Le document détaille l'architecture cible recommandée, la démarche de migration depuis un accès existant, et les critères d'évaluation d'une solution conforme IEC 62443.
La modernisation de la télégestion des réseaux d'eau potable est devenue une priorité pour les collectivités françaises. Entre les obligations réglementaires croissantes (autosurveillance, NIS2, RGPD), la vétusté des équipements de télésurveillance des années 2000, et les exigences de performance des contrats DSP, les services eau doivent repenser leur architecture de supervision.
\nCe guide pratique s'adresse aux responsables techniques, aux directeurs eau/assainissement et aux DSI de collectivités — syndicats des eaux, régie municipale, communautés de communes — qui supervisent des réseaux d'eau potable.
\nLa télégestion des réseaux d'eau potable en France repose aujourd'hui largement sur des équipements installés entre 2000 et 2015. Les technologies dominantes sont :
\nOrange a officiellement annoncé la fermeture du réseau 2G en 2026 (après plusieurs reports). SFR a déjà fermé son 2G dans plusieurs zones. Bouygues Telecom suit la même trajectoire.
\nLes modems SOFREL S4W et autres RTU 2G/GPRS utilisés sur les châteaux d'eau, stations de pompage et stations de relevage ne fonctionneront plus après ces fermetures.
\nC'est une opportunité majeure de modernisation vers des solutions 4G LTE avec une plateforme cloud de supervision centralisée.
\n| Type de site | Paramètres clés | Équipements terrain |
|---|---|---|
| Station de pompage | Débit refoulé, pression, niveau bâche, heures de marche, consommation électrique | Automate Schneider M340 ou Siemens S7-1200, capteurs 4-20mA |
| Château d'eau / réservoir | Niveau d'eau, pression entrée/sortie, vanne de remplissage | Sonde de niveau ultrason ou pression, débitmètre Modbus |
| Station de traitement | Turbidité, chlore résiduel, pH, conductivité, température, débit traité | Sondes multiparamètres YSI, Hach, WTW en Modbus RS-485 |
| Station de surpression | Pression aval, débit, état des groupes, défauts moteurs | Variateurs de fréquence Modbus, automate local |
| Compteur sectoriel | Débit, index, détection fuite nocturne | Compteur MID avec sortie impulsion ou Modbus |
Le SOFREL S4W est le modem le plus répandu sur les réseaux d'eau français. La migration vers l'Eziwan Gateway est conçue pour être non invasive.
\nÉtapes de migration :
\nCompatibilité : L'Eziwan Gateway lit tous les registres Modbus configurés sur votre automate (Schneider M340, Siemens S7-1200, Lacroix E30...). La migration ne nécessite aucune modification de l'automate terrain.
\nCoût de migration : Le Gateway Eziwan est moins cher qu'un SOFREL S4W neuf, avec des fonctionnalités étendues (VPN, multi-protocoles, OTA). Pour une flotte de 50 stations, le retour sur investissement vs achat de S4W neufs est immédiat.
\nLors d'un retour en régie ou d'un changement de délégataire, la collectivité perd souvent l'accès au système de supervision propriétaire de l'opérateur sortant. La transition peut laisser des semaines ou mois sans supervision centralisée.
\nApproche Eziwan pour les transitions DSP :
\nL'arrêté du 21 juillet 2015 modifiant l'arrêté du 2 mai 2007 impose des obligations d'autosurveillance pour les STEP (Stations de Traitement des Eaux usées) et les UPEP (Unités de Production d'Eau Potable) :
\nParamètres à surveiller et archiver (UPEP) :
\nExigences d'archivage :
\nComment Eziwan répond à ces exigences :
\nLa transposition de la directive NIS2 en France (loi du 16 avril 2024) classe les opérateurs d'eau en catégories selon leur taille :
\nEntités essentielles :
\nEntités importantes :
\nObligations NIS2 pertinentes pour la télégestion eau :
\n| Obligation | Exigence | Comment Eziwan y répond |
|---|---|---|
| Segmentation réseau OT/IT | Gateway OT isolé du réseau bureautique | Gateway opère dans zone OT, pas de flux entrant |
| Contrôle des accès distants | MFA + journalisation | VPN OpenVPN/IPSec + MFA + log de session complet |
| Gestion des vulnérabilités | Patch management | OTA automatique du firmware gateway |
| Notification d'incident | < 24h à l'ANSSI | Log d'incidents exportable, procédure documentée |
| Chaîne de sous-traitance | Audit fournisseurs | Eziwan ISO 27001, hébergement France, RGPD |
Contexte : Un syndicat intercommunal gère 80 stations de pompage (12 à 350 m³/h) et 6 châteaux d'eau sur un territoire rural de 45 communes. Équipement existant : modems SOFREL S4W 2G, supervision locale limitée, 3 techniciens.
\nProblèmes :
\nDéploiement Eziwan :
\nRésultats à 6 mois :
\n| Protocole | Compteurs compatibles | Paramètres collectés |
|---|---|---|
| M-Bus (EN 13757) | Sensus iPERL, Itron Actaris BDE, Landis+Gyr E120, Sagemcom | Index (m³), débit instantané, alarmes (manipulation, sec) |
| Impulsion (entrée TOR) | Tout compteur avec sortie impulsion (sortie reed switch) | Index cumulé, débit calculé (nb impulsions × volume/impulsion) |
| Modbus RTU | Endress+Hauser Promag, Krohne Optiflux, Siemens Sitrans FM | Débit (m³/h), vitesse (m/s), température, index cumulé |
| MBUS LoRaWAN | Compteurs LoRaWAN pour secteurs sans couverture | Via concentrateur LoRaWAN + gateway Eziwan (MQTT) |
| Paramètre | Capteurs compatibles | Interface |
|---|---|---|
| Chlore résiduel | Hach CL17sc, YSI MultiLab, Bürkert Type 8905 | Modbus RS-485 ou 4-20mA |
| pH/Redox | WTW IQ SensorNet, Endress+Hauser CPS11D | Modbus RS-485 ou 4-20mA |
| Turbidité | Hach TU5200, Yokogawa FLXA21 | Modbus RS-485 |
| Conductivité | Endress+Hauser Liquiline CM44 | Modbus RS-485 |
| Niveau | Vega Vegapuls, Endress+Hauser FMR51, Keller Serie 26 | 4-20mA ou Modbus |
| Automate | Interface | Compatibilité |
|---|---|---|
| Schneider Electric M340 | Modbus RTU RS-485 | ✅ Testé et validé |
| Schneider Electric M221/M241 | Modbus RTU RS-485 + Modbus TCP | ✅ Testé et validé |
| Siemens S7-1200/S7-1500 | Modbus TCP (via Ethernet) | ✅ Testé et validé |
| Lacroix Tbox LT2 / MS3 | Modbus RTU / TCP | ✅ Compatible |
| Wago 750-860 | Modbus TCP | ✅ Compatible |
| CODESYS Modbus Slave | Modbus RTU / TCP | ✅ Compatible |
Déplacements techniciens :
\nDégâts évités (fuites, pannes, débordements) :
\nAstreintes :
\nConformité réglementaire :
\n| Poste | Valeur annuelle |
|---|---|
| Déplacements évités | 40 750 € |
| Fuites détectées précocement | 15 000 € |
| Réduction astreintes | 15 000 € |
| Évitement non-conformités réglementaires | 10 000 € |
| Total économies annuelles estimées | 80 750 € |
| Investissement | Montant |
|---|---|
| 80 Gateways Eziwan + installation | 48 000 € |
| Abonnement cloud (80 sites/an) | 14 400 € |
| SIM 4G M2M (80 sites × 10€/mois) | 9 600 € |
| Total investissement année 1 | 72 000 € |
ROI année 1 : 80 750 − 72 000 = +8 750 € dès la première année\nROI à partir de l'année 2 : 80 750 − (14 400 + 9 600) = +56 750 €/an
\nLes projets de modernisation de la télégestion des réseaux d'eau potable peuvent bénéficier de financements FEDER (Fonds Européen de Développement Régional) dans le cadre des programmes opérationnels régionaux 2021-2027, sous l'axe \"Transition numérique des services publics\".
\nLes 6 Agences de l'eau françaises (Artois-Picardie, Rhin-Meuse, Seine-Normandie, Loire-Bretagne, Adour-Garonne, Rhône-Méditerranée Corse) proposent des aides à la modernisation de la gestion des réseaux d'eau. Les critères de soutien incluent la réduction des fuites (rendement de réseau), la conformité réglementaire et la transition numérique.
\nContactez votre Agence de l'eau locale pour connaître les programmes en cours et les taux d'aide applicables à votre projet.
\nLa DSIL et la DETR (Dotation d'Équipement des Territoires Ruraux) peuvent financer des projets numériques pour les collectivités rurales. Les projets de modernisation IoT des réseaux d'eau s'inscrivent dans les objectifs \"services de proximité\" et \"transition numérique\" de ces dotations.
\nLa supervision IoT est-elle éligible au Plan France Relance ou à des aides régionales ?\nOui, plusieurs dispositifs peuvent s'appliquer. La DSIL (Dotation de Soutien à l'Investissement Local) finance les projets numériques des collectivités. La DETR (Dotation d'Équipement des Territoires Ruraux) couvre les communes rurales. Les Agences de l'eau (Seine-Normandie, Loire-Bretagne, etc.) ont des programmes spécifiques pour la réduction des pertes et l'autosurveillance. Un dossier technique avec ROI chiffré (économies sur fuites, coûts évités) est généralement requis.
\nLa migration depuis un système SOFREL existant est-elle invasive ?\nNon. La gateway Eziwan se connecte en parallèle des équipements SOFREL existants via Modbus RTU/TCP ou 4-20 mA. Il n'est pas nécessaire de couper le système existant pendant la transition. La migration peut se faire par phases : d'abord lecture des données, puis bascule progressive des stations pilotes, enfin remplacement complet selon votre calendrier de renouvellement des équipements.
\nComment la solution répond-elle aux exigences de rapport d'autosurveillance ARS ?\nLa plateforme Eziwan permet l'export des données d'autosurveillance dans les formats requis (CSV, Excel) avec les horodatages certifiés. Les indicateurs de performance (taux de pertes, débit nominal vs réel, incidents de pression) sont calculés automatiquement depuis les relevés et peuvent être extraits sur les périodes demandées par l'ARS.
\nLa modernisation de la télégestion eau potable n'est plus une option pour les collectivités françaises. La fermeture 2G, les obligations NIS2, les exigences d'autosurveillance ARS et la pression sur les coûts d'exploitation convergent pour rendre l'investissement incontournable.
\nLa bonne nouvelle : le ROI est rapide (généralement < 18 mois), la migration depuis les systèmes existants (SOFREL, etc.) est documentée et non invasive, et les solutions modernes (gateway 4G + cloud) sont nettement moins chères que les équipements propriétaires de première génération.
\nVos prochaines étapes :
\nContactez l'équipe Eziwan pour un audit gratuit de votre infrastructure de télégestion eau.
\nEziwan est partenaire de collectivités, syndicats des eaux et régies municipales pour la modernisation de leur télégestion. Nous accompagnons les transitions DSP et les migrations depuis les systèmes SOFREL, Lacroix et autres RTU eau. Découvrir notre solution eau →
\nCloud ou on-premise ? C'est la question que se posent aujourd'hui la majorité des responsables automation et DSI industriels. La supervision SCADA évolue : les solutions cloud SaaS gagnent du terrain face aux installations on-premise traditionnelles, mais le choix n'est pas toujours évident.
\nCe guide compare objectivement les deux architectures sur 7 critères clés — coût total, sécurité, latence, scalabilité, conformité, maintenabilité et résilience — pour vous aider à prendre la bonne décision selon votre contexte industriel.
\nSCADA on-premise (classique) :\nServeur(s) physiques installés dans vos locaux ou votre salle serveur. Logiciel SCADA installé localement (Wonderware InTouch/System Platform, Ignition, PCVue, WinCC). Historique de données sur serveur SQL local. Accès depuis le réseau local (LAN) ou via VPN pour l'accès distant.
\nSCADA cloud / IIoT SaaS :\nPlateforme hébergée dans le cloud (AWS, Azure, GCP ou cloud souverain français). Gateways industriels sur site qui collectent les données terrain et les envoient vers le cloud. Dashboard accessible depuis n'importe quel navigateur. Historique en cloud. Exemples : Eziwan, Axonize, Samsara, Siemens MindSphere, AWS IoT SiteWise.
\n| Poste | Coût (3 ans) |
|---|---|
| Licences logiciel SCADA (Wonderware System Platform 10 connexions) | 45 000 – 80 000 € |
| Serveurs physiques (2 serveurs redondants) | 18 000 – 30 000 € |
| Infrastructure réseau (switches managés, routeurs) | 8 000 – 15 000 € |
| Installation et configuration (intégrateur) | 20 000 – 40 000 € |
| Maintenance et support annuel (15-20% du coût licence) | 20 000 – 45 000 € |
| Mises à jour majeures (1 version par 3 ans) | 15 000 – 25 000 € |
| Ressources IT internes (administration, sauvegardes) | 15 000 – 30 000 € |
| Total 3 ans | 141 000 – 265 000 € |
| Poste | Coût (3 ans) |
|---|---|
| Abonnement plateforme cloud (10 sites, 500 points de données) | 18 000 – 36 000 € |
| Gateways industriels (1 par site × 10) | 8 000 – 15 000 € |
| Installation et mise en service (plus simple) | 5 000 – 15 000 € |
| Connectivité 4G/SIM M2M (si pas de fibre) | 3 600 – 7 200 € |
| Formation équipe | 2 000 – 5 000 € |
| Total 3 ans | 36 600 – 78 200 € |
Verdict TCO : Le cloud SaaS est 2 à 4 fois moins cher sur 3 ans pour les déploiements multi-sites. L'avantage se creuse avec le nombre de sites. Pour un site unique avec un SCADA existant déjà amorti, l'on-premise peut rester pertinent.
\nC'est souvent l'argument principal des défenseurs de l'on-premise. Analysons ce qui est réellement vrai.
\nVerdict sécurité : À niveau de maturité égal, le cloud certifié ISO 27001 hébergé en France est généralement plus sécurisé qu'un on-premise non-géré. Pour les OIV (Opérateurs d'Importance Vitale) ou secteurs très sensibles, le cloud souverain français (SecNumCloud qualifié ANSSI) est recommandé.
\nLa latence aller-retour entre un gateway terrain et un serveur cloud hébergé à Paris est de 50 à 200 ms selon la qualité de la connexion 4G ou fibre.
\nEst-ce acceptable pour votre application ?
\n| Application | Latence requise | Cloud OK ? |
|---|---|---|
| Boucle de régulation PLC (PID) | 1 – 10 ms | ❌ Non — reste sur l'automate local |
| Asservissement motion control | 1 – 5 ms | ❌ Non — reste sur le drive/servo |
| Alarmes de sécurité (SIL, PLe) | 10 – 100 ms | ❌ Non — reste sur le safety PLC |
| Supervision état machine | 100 ms – 1 s | ✅ Oui |
| Alertes et notifications | 1 – 30 s | ✅ Oui |
| Tableaux de bord production | 1 – 60 s | ✅ Oui |
| Rapports et historique | Sans contrainte | ✅ Oui |
| Maintenance à distance (VNC/SSH) | 50 – 500 ms | ✅ Oui (acceptable) |
Règle d'or : le contrôle temps réel reste TOUJOURS sur l'automate local. Le cloud gère la supervision, les alertes, l'historique et la maintenance à distance. Cette séparation des responsabilités est la clé d'une architecture IIoT correcte.
\nVerdict latence : La latence cloud est parfaitement acceptable pour 95% des cas de supervision industrielle. Seule la boucle de contrôle temps réel doit rester locale.
\nPasser de 10 à 50 sites surveillés en on-premise nécessite :
\nDélai typique : 4 à 12 semaines. Coût marginal élevé.
\nAjouter un nouveau site en cloud SaaS :
\nDélai typique : 1 à 2 semaines (délai matériel dominant). Coût marginal faible.
\nVerdict scalabilité : Le cloud gagne largement. Particulièrement décisif pour les déploiements multi-sites ou les intégrateurs qui gèrent des parcs de plusieurs dizaines à plusieurs centaines de sites clients.
\nPour les entités essentielles et importantes soumises à NIS2 (eau, énergie, industrie critique), les exigences de cybersécurité sont les mêmes quelle que soit l'architecture. La différence est dans la capacité à démontrer la conformité :
\nSi votre SCADA traite des données personnelles (horaires de présence d'opérateurs, accès biométriques), la localisation des données est importante :
\nFDA 21 CFR Part 11 (traçabilité électronique pharma) et EU GMP Annex 11 sont compatibles avec le cloud, à condition de choisir un prestataire qui peut fournir les attestations de validation (IQ/OQ/PQ) requises par les auditeurs.
\nVerdict conformité : Le cloud hébergé en France par un prestataire ISO 27001 est compatible avec NIS2, RGPD et les principales réglementations industrielles. Vérifiez les attestations du prestataire.
\nLes industriels sous-estiment souvent la charge de maintenance d'un SCADA on-premise :
\nEn pratique, un SCADA on-premise nécessite 0,3 à 0,5 ETP IT sur la durée (partage avec d'autres systèmes).
\nSur une plateforme cloud SaaS, le prestataire gère :
\nVotre équipe ne maintient que les gateways terrain (firmware OTA automatisable) et la configuration applicative.
\nVerdict maintenabilité : Le cloud réduit la charge opérationnelle de 70-80%. Décisif pour les PMI sans équipe IT dédiée.
\nPoints forts :
\nPoints faibles :
\nLes plateformes cloud industrielles sérieuses s'engagent sur 99,9% de disponibilité (SLA contractuel = < 8,76 heures d'arrêt/an) voire 99,95%.
\nArchitecture multi-AZ (multi-datacenter) : la panne d'un datacenter n'impacte pas le service. Le DR (Disaster Recovery) est automatique.
\nRisque cloud principal : si la connexion Internet/4G du site est coupée, le gateway perd la liaison avec le cloud. Les données sont bufferisées localement (store-and-forward) et retransmises à la reconnexion. La supervision à distance est indisponible pendant la coupure.
\nRéponse : pour les sites critiques, déployer une connexion de secours (SIM 4G dual-operator en failover sur fibre, ou VSAT satellite en dernier recours).
\nVerdict résilience : Le cloud offre une meilleure disponibilité de la plateforme. L'on-premise est plus résilient pour la supervision locale sans dépendance réseau. Un hybride (contrôle local + supervision cloud) donne le meilleur des deux.
\nLa majorité des nouveaux déploiements industriels adoptent une architecture hybride :
\n\nAvantages de l'hybride :
\nC'est exactement l'architecture qu'Eziwan déploie : un gateway industriel sur chaque site (edge), une plateforme cloud pour la supervision centralisée.
\n| Critère | On-premise | Cloud SaaS | Hybride |
|---|---|---|---|
| TCO 3 ans (10 sites) | 141-265 k€ | 37-78 k€ | 50-100 k€ |
| Sécurité | Dépend de votre IT | ISO 27001 | ISO 27001 + isolation OT |
| Latence contrôle | Excellent | Non applicable | Excellent (local) |
| Latence supervision | Excellent | 50-200 ms | 50-200 ms |
| Scalabilité | Difficile | Facile | Facile |
| Maintenabilité | Charge IT 0.3-0.5 ETP | Minimale | Minimale |
| Disponibilité plateforme | ~99% (si redondant) | 99.9%+ (SLA) | 99.9%+ |
| Résistance coupure Internet | Totale | Limitée | Bonne (store-and-fwd) |
| Conformité NIS2/RGPD | Possible | Possible | Possible |
| Délai déploiement | 4-12 semaines | 1-2 semaines | 1-2 semaines |
Il n'y a pas de réponse universelle. Le choix dépend de votre nombre de sites, de votre maturité IT, de vos contraintes réglementaires et de vos ambitions de scalabilité.
\nCe qui est certain : pour les déploiements multi-sites, la balance TCO penche nettement vers le cloud SaaS. Et l'argument sécurité ne tient que si votre on-premise est correctement maintenu — ce qui est rarement le cas en PMI sans équipe cybersécurité dédiée.
\nL'architecture hybride edge + cloud, représentée par des solutions comme Eziwan, permet aujourd'hui de combiner le contrôle local (latence zéro, fonctionnement hors-ligne) avec la puissance du cloud (supervision centralisée, accès distant, historique illimité) — sans avoir à choisir.
\nUn SCADA cloud peut-il fonctionner si Internet est coupé ?\nAvec une architecture hybride (gateway edge + cloud), le process industriel continue de fonctionner (l'automate fonctionne de manière autonome), et les données sont bufferisées localement par le gateway (store-and-forward). La supervision temps réel est interrompue pendant la coupure, mais les données ne sont pas perdues — elles remontent dès la reconnexion. Pour les alarmes critiques, configurez des alertes locales (relais, SMS depuis le gateway edge) qui fonctionnent sans Internet.
\nQuels SCADA on-premise sont compatibles avec une passerelle IoT cloud ?\nWonderware AVEVA, Ignition (Inductive Automation), CODESYS, FactoryTalk (Rockwell), WinCC (Siemens), Citect — tous s'intègrent à des passerelles IoT cloud via OPC-UA, Modbus TCP ou API REST. L'architecture hybride consiste à laisser le SCADA on-premise gérer le contrôle local et d'ajouter un gateway IoT cloud pour la supervision distante et l'accès distant des techniciens.
\nLe cloud SaaS est-il adapté aux secrets industriels (formules, process propriétaires) ?\nLes données process critiques (recettes, paramètres propriétaires) peuvent être exclues de la remontée cloud — vous ne transmettez que ce dont vous avez besoin pour la supervision (temperatures, pressions, états machines). Pour les données les plus sensibles, l'hébergement cloud en France (OVHCloud, Scaleway) soumis au droit français offre un niveau de protection supplémentaire vs hébergeurs américains soumis au CLOUD Act.
\nQuelle durée de migration d'un SCADA on-premise vers le cloud ?\nPour un site avec SCADA existant, le déploiement d'une couche cloud (accès distant, supervision multi-sites) prend 1 à 4 semaines sans perturber le SCADA on-premise. Le SCADA existant reste en place ; la gateway IoT cloud s'ajoute en parallèle. Une migration complète vers un SCADA cloud (sans SCADA on-premise) prend 2 à 6 mois selon la complexité de l'installation.
\nVous hésitez entre cloud et on-premise pour votre projet de supervision ? Contactez notre équipe pour un conseil personnalisé basé sur votre contexte industriel.
\nLes systèmes industriels sont devenus la cible prioritaire des cybercriminels. En 2025, 68% des incidents de cybersécurité déclarés à l'ANSSI concernaient des systèmes OT (Operational Technology), contre 41% en 2022. L'interconnexion croissante entre les réseaux IT et OT, accélérée par l'Industrie 4.0, a considérablement élargi la surface d'attaque des usines, centrales électriques et réseaux d'eau.
\nCe guide présente les principales menaces OT identifiées en 2025-2026, les secteurs les plus exposés en France, et les mesures concrètes pour réduire votre exposition.
\nPendant des décennies, les systèmes industriels étaient protégés par l'air gap : leur isolation physique totale des réseaux IT et d'Internet. Cette protection naturelle a disparu avec la numérisation industrielle.
\nLes facteurs qui ont changé la donne :
\nConséquence : les systèmes OT cumulent les vulnérabilités non corrigées, les protocoles non sécurisés, et une exposition réseau croissante. Pour un attaquant, c'est une cible idéale.
\nLe ransomware reste la menace numéro 1. Mais en 2025-2026, les groupes cybercriminels ont développé des variantes spécifiques aux systèmes industriels, capables de :
\nGroupes actifs en Europe : LockBit 3.0, BlackCat/ALPHV, Play, Cl0p ont tous ciblé des industries françaises en 2024-2025. Le secteur manufacturier représente 28% des victimes de ransomware en Europe.
\nImpact moyen d'un ransomware industriel :
\nVecteurs d'entrée les plus fréquents :
\nLes automates programmables sont désormais ciblés directement. Les attaques les plus sophistiquées modifient la logique de programme (firmware ou ladder logic) pour :
\nVulnérabilités récurrentes identifiées par l'ANSSI (2024-2025) :
\n| Fabricant | Type de vulnérabilité | CVE |
|---|---|---|
| Siemens S7-1500 | Buffer overflow dans le serveur Modbus TCP | CVE-2023-46156 |
| Schneider Electric M340 | Authentification absente sur port FTP | CVE-2024-8935 |
| Rockwell Automation ControlLogix | RCE via EtherNet/IP sans authentification | CVE-2024-6077 |
| Mitsubishi MELSEC iQ-R | Déni de service via paquets malformés | CVE-2024-7419 |
| Wago 750 Series | Credentials par défaut non changés | CVE-2023-4156 |
Mesure préventive clé : isoler les automates dans des VLAN dédiés, interdire les connexions directes depuis le réseau IT, utiliser des DMZ industrielles conformes à l'architecture Purdue.
\nModbus, DNP3, BACnet et Profinet ont été conçus dans les années 1970-1990 pour la fiabilité et la rapidité. Aucun n'intègre d'authentification native. N'importe quel équipement sur le même réseau peut :
\nAttaque type : un attaquant qui accède au réseau OT (via VPN compromis, poste de maintenance infecté ou câble branché physiquement) peut directement envoyer des commandes Modbus à l'automate de pilotage d'une pompe ou d'un compresseur.
\nMitigation :
\nLes interfaces homme-machine (IHM) et les serveurs SCADA sont souvent les maillons faibles car :
\nScénario d'attaque courant :
\nFact check 2025 : La plateforme Shodan répertorie plus de 15 000 IHM industrielles accessibles directement depuis Internet en France, dont environ 3 400 sans authentification configurée.
\nLa menace supply chain OT est en forte croissance. Elle consiste à compromettre un équipement, un logiciel ou un prestataire avant qu'il n'arrive chez la victime finale.
\nVecteurs identifiés :
\nExigences NIS2 directement liées : l'article 21 de la directive NIS2 impose explicitement la gestion de la sécurité de la chaîne d'approvisionnement pour les entités essentielles et importantes.
\nLes menaces internes sont souvent sous-estimées dans l'industrie. Elles concernent :
\nStatistiques 2024 (rapport Verizon DBIR) : 18% des incidents OT impliquent un acteur interne ou un prestataire de confiance compromis.
\nMesure clé : Zero Trust Access — chaque accès doit être authentifié (MFA), limité dans le temps, et audité. Un sous-traitant ne doit jamais avoir un accès permanent illimité.
\nLe secteur de l'eau est la cible numéro 1 des attaques OT selon l'ANSSI et Europol. Les raisons :
\nIncident de référence : En février 2021, un attaquant a modifié le niveau de soude caustique dans une usine de traitement d'eau en Floride via un accès TeamViewer non sécurisé. Un opérateur attentif a détecté l'anomalie à temps. Le même type d'attaque est possible sur n'importe quel SCADA eau sans contrôle d'accès rigoureux.
\nEn France, NIS2 classe les opérateurs d'eau desservant > 10 000 habitants comme entités essentielles, avec des obligations renforcées de cybersécurité depuis le 17 octobre 2024.
\nLes attaques contre les infrastructures énergétiques (production, transport, distribution) ont triplé en Europe depuis 2022. Les gestionnaires de réseaux de distribution (GRD), les producteurs ENR et les sites industriels avec sous-station électrique sont exposés.
\nProtocoles ciblés : IEC 60870-5-101/104, IEC 61850 GOOSE, DNP3 — tous sans authentification native dans leurs versions de base.
\nCes secteurs combinent une forte réglementation (FDA 21 CFR Part 11, EU GMP Annex 11) avec des systèmes OT critiques. La contamination d'un process de fabrication par manipulation d'automates peut avoir des conséquences sanitaires graves.
\nLes attaques visant l'arrêt de production (sabotage concurrentiel) se multiplient dans ces secteurs à forte valeur ajoutée.
\nLes villes intelligentes déploient des capteurs, actionneurs et gateways IoT en masse, souvent avec des budgets sécurité insuffisants. L'éclairage public, la gestion du stationnement et les systèmes de transport urbain sont désormais tous connectés — et potentiellement compromissibles.
\n1. Inventaire de tous les actifs OT\nVous ne pouvez pas protéger ce que vous ne connaissez pas. Cartographiez tous les automates, SCADA, IHM, gateways et équipements réseau avec leur OS, firmware, protocoles et connexions. Utilisez des outils de découverte passifs (Nozomi Networks, Claroty, Dragos) qui ne perturbent pas le réseau OT.
\n2. Segmentation réseau IT/OT\nIsolez votre réseau OT du réseau IT avec un pare-feu industriel ou une DMZ dédiée. L'architecture Purdue (niveaux 0 à 5) reste la référence. À minima : interdire toute communication directe entre PC de bureau et automates terrain.
\n3. Suppression des accès distants non sécurisés\nAuditez tous les accès distants existants (VPN, TeamViewer, AnyDesk, RDP). Désactivez ceux qui ne sont pas strictement nécessaires. Pour les accès légitimes, implémentez le MFA et limitez les plages horaires d'accès.
\n4. Changement des credentials par défaut\nTous les équipements (automates, switches, IHM, routeurs) livrés avec des identifiants par défaut (admin/admin, root/root) doivent être changés à la première mise en service. Documentez les credentials dans un coffre-fort de mots de passe (Bitwarden, HashiCorp Vault).
\n5. Sauvegarde des configurations automates\nExportez et sauvegardez les projets TIA Portal, Unity Pro, Studio 5000 hors ligne, dans un emplacement isolé du réseau OT. En cas de ransomware, la restauration depuis une sauvegarde propre doit pouvoir se faire en heures, pas en semaines.
\n6. Authentification forte sur les accès distants\nDéployez un VPN industriel avec MFA (TOTP ou FIDO2) pour tous les accès distants — techniciens internes, sous-traitants, intégrateurs. Chaque session doit être enregistrée (session recording) pour l'audit.
\n7. Surveillance des comportements réseau OT (NDR)\nDéployez une sonde de surveillance passive sur votre réseau OT pour détecter les anomalies de communication : nouveaux équipements, function codes Modbus inhabituels, communications vers des IP inconnues, changements de firmware. Les solutions Nozomi Networks, Claroty et Dragos sont les leaders du marché.
\n8. Gestion des vulnérabilités OT\nAbonnez-vous aux bulletins de sécurité de vos fabricants (Siemens ProductCERT, Schneider Electric PSIRT, Rockwell Automation Security Advisories). Évaluez les CVE critiques (CVSS ≥ 7.0) et planifiez les correctifs lors des prochaines fenêtres de maintenance.
\n9. Plan de réponse aux incidents OT\nDocumentez le processus de réponse spécifique OT : qui contacter (ANSSI si entité NIS2), comment isoler un segment compromis sans arrêter la production, procédures de restauration depuis les sauvegardes. Testez le plan une fois par an en simulation.
\n10. Formation des équipes (OT Security Awareness)\nLes ingénieurs d'automation n'ont généralement pas reçu de formation cybersécurité. Des sessions de 2-4 heures sur les menaces OT spécifiques, le phishing, la gestion des clés USB et les accès distants sécurisés réduisent significativement le risque interne.
\nLa passerelle et la plateforme Eziwan ont été conçues dès l'origine avec la sécurité OT comme exigence non fonctionnelle critique.
\nArchitecture Zero Trust :
\nContrôle d'accès distant granulaire :
\nSurveillance OT intégrée :
\nHébergement souverain :
\nUtilisez cette checklist pour évaluer votre niveau de maturité cybersécurité OT :
\nGouvernance
\nArchitecture réseau
\nAccès et identités
\nMaintenance et mises à jour
\nDétection et réponse
\nUn ransomware qui touche le réseau IT peut-il atteindre les automates OT ?
\nOui, si les réseaux OT et IT sont interconnectés sans segmentation stricte. C'est exactement le vecteur de propagation de NotPetya (2017) et de nombreux incidents industriels depuis. Le ransomware chiffre les serveurs IT, se propage via Active Directory et les partages réseau, et si le réseau OT est sur le même LAN ou accessible via le même domaine Windows, les postes de supervision SCADA et parfois les automates sont atteints.
\nLes automates Siemens ou Schneider peuvent-ils être directement infectés par un malware ?
\nLes automates industriels ne \"s'infectent\" pas au sens classique (pas de système de fichiers standard, pas d'exécution de code arbitraire via des vecteurs usuels). Mais ils peuvent être reprogrammés à distance si l'accès est obtenu (cf. Stuxnet). Le risque réel est plus souvent l'arrêt ou la manipulation des automates via un opérateur compromis ou un accès distant mal sécurisé, plutôt qu'une infection directe du firmware.
\nQuelle est l'obligation de notification à l'ANSSI en cas d'incident OT sous NIS2 ?
\nPour les entités soumises à NIS2 (Entités Essentielles et Entités Importantes), l'obligation est : notification préliminaire dans les 24h si l'incident est susceptible d'avoir un impact significatif, rapport intermédiaire dans les 72h, rapport final dans le mois. L'ANSSI peut être notifiée via le formulaire dédié sur son site. Le non-respect expose à des sanctions pouvant atteindre 10M€ ou 2% du CA mondial.
\nLes solutions de segmentation réseau OT sont-elles très coûteuses pour une PMI ?
\nNon. Une segmentation basique (VLAN OT/IT sur un switch manageable à 200-400€, avec règles inter-VLAN restrictives) est accessible à toute PMI. Pour un niveau supérieur, des pare-feux industriels compacts (Stormshield SNi40, Fortinet FortiGate Rugged) démarrent à 500-800€. La segmentation est le meilleur rapport coût/efficacité en cybersécurité OT — elle contient les incidents avant qu'ils ne se propagent.
\nFaut-il désactiver les protocoles non sécurisés comme Modbus TCP sur le réseau OT ?
\nSur le réseau OT interne, Modbus TCP peut rester actif — son absence d'authentification est acceptable dans un réseau physiquement isolé et segmenté. L'erreur critique est d'exposer le port Modbus (502) sur Internet ou sur le réseau IT sans contrôle. La priorité est d'assurer qu'aucun port OT n'est accessible depuis l'extérieur, pas nécessairement de remplacer Modbus par un protocole plus sécurisé à court terme.
\nLa cybersécurité OT n'est plus une option pour les industriels français. La directive NIS2, les exigences de la norme IEC 62443 et la réalité des incidents (ransomwares, attaques sur les réseaux d'eau, sabotages d'infrastructure énergétique) rendent la protection des systèmes OT indispensable.
\nLa bonne nouvelle : contrairement à ce que pensent beaucoup d'industriels, il n'est pas nécessaire de tout refaire pour progresser significativement. Les 5 mesures fondamentales présentées dans ce guide — inventaire, segmentation, suppression des accès non sécurisés, credentials par défaut, sauvegardes — réduisent de 80% le risque d'incident majeur, pour un coût et une complexité raisonnables.
\nVotre prochaine étape : réalisez un audit OT de votre infrastructure (Eziwan propose un audit gratuit de vos connexions distantes) et identifiez les 3 actions prioritaires à mettre en œuvre dans les 30 prochains jours.
\nArticle rédigé par l'équipe Eziwan. Eziwan est éditeur de passerelles IIoT et de plateforme de supervision industrielle pour les PMI, collectivités et intégrateurs automation français. Découvrez notre approche de la sécurité OT →
\nLa norme IEC 62443 est devenue la référence internationale pour la cybersécurité des systèmes de contrôle industriels (ICS/SCADA/OT). Avec l'entrée en vigueur de la directive NIS2 en France, elle est désormais citée explicitement comme référentiel technique applicable aux entités essentielles et importantes.
\nPourtant, la norme est réputée complexe et volumineuse. Ce guide pratique extrait l'essentiel pour les industriels français : ce que la norme exige concrètement, comment s'y conformer, et les priorités 2026.
\nL'IEC 62443 (anciennement ISA-99) est une famille de normes développée par l'ISA (International Society of Automation) et publiée par l'IEC. Elle couvre la cybersécurité des systèmes d'automatisation et de contrôle industriels (IACS).
\nLa norme est organisée en 4 séries :
\n| Série | Titre | Public cible |
|---|---|---|
| 62443-1.x | Général (concepts, modèles, terminologie) | Tous |
| 62443-2.x | Politiques & procédures | Opérateurs industriels, RSSI |
| 62443-3.x | Système (architecture, niveaux de sécurité) | Architectes, intégrateurs |
| 62443-4.x | Composants (sécurité des produits) | Fabricants d'équipements |
Pour un industriel français souhaitant se conformer à NIS2, les parties les plus pertinentes sont :
\nLa notion centrale de l'IEC 62443 est le Security Level — le niveau de protection requis selon la criticité du système.
\n| Security Level | Description | Contre quelle menace ? |
|---|---|---|
| SL 0 | Aucune protection spécifique | — (systèmes non connectés) |
| SL 1 | Protection contre les attaques accidentelles | Erreurs humaines, malveillances non ciblées |
| SL 2 | Protection contre les attaques délibérées avec faibles moyens | Hacktivistes, opportunistes |
| SL 3 | Protection contre les attaques avec moyens sophistiqués | Groupes criminels organisés |
| SL 4 | Protection contre les attaques d'États | APT étatiques |
Pour la grande majorité des industriels français : le niveau SL 2 est la cible appropriée. SL 3 est réservé aux opérateurs d'importance vitale (OIV) avec des systèmes très critiques. SL 4 est quasi-exclusivement pour les infrastructures militaires et nucléaires.
\nLa démarche se fait en 3 étapes :
\n1. Identifier les zones et les conduits (IEC 62443-3-2)
\nCommencez par cartographier vos systèmes OT en zones de sécurité (Security Zones) :
\nPuis identifiez les conduits (Conduits) — les voies de communication entre zones (VPN d'accès distant, liens SCADA, passerelles IT/OT).
\n2. Évaluer la criticité de chaque zone (CASC)
\nPour chaque zone, évaluez les conséquences d'une compromission selon les critères CASC :
\n3. Définir le SL cible par zone
\nLa criticité évaluée détermine le SL cible : une zone avec des automates de sécurité (SIL) dans une installation SEVESO visera SL 3, tandis qu'une zone de supervision d'une station de pompage d'eau potable vise généralement SL 2.
\nLa norme IEC 62443-3-3 définit 7 exigences fondamentales (FR) pour les systèmes. Chaque FR est déclinée en exigences détaillées selon le niveau SL.
\nCe que ça signifie en pratique :
\nApplication Eziwan : chaque technicien dispose d'une clé VPN OpenVPN/IPSec individuelle. L'authentification MFA est disponible sur la plateforme cloud.
\nCe que ça signifie :
\nApplication : le RBAC Eziwan permet de définir des droits d'accès par site, par équipement et par plage horaire pour chaque technicien.
\nCe que ça signifie :
\nApplication : toutes les communications Eziwan sont chiffrées par OpenVPN (authentification + chiffrement). Les configurations sont signées numériquement.
\nCe que ça signifie :
\nApplication : chiffrement AES-256-GCM de toutes les communications, données stockées chiffrées sur l'infrastructure cloud française.
\nCe que ça signifie :
\nApplication Eziwan : architecture zero-inbound-port — le réseau OT n'est jamais exposé directement. Le trafic passe par le cloud Eziwan qui fait office de point de contrôle centralisé.
\nCe que ça signifie :
\nApplication : journalisation complète de tous les événements de sécurité, alertes configurables sur les anomalies de connexion, export des logs pour SIEM.
\nCe que ça signifie :
\nApplication : Dual SIM failover, infrastructure cloud multi-AZ, sauvegardes automatiques des configurations gateway.
\nVoici une démarche pragmatique pour les industriels français qui doivent se conformer à NIS2 en référençant l'IEC 62443.
\nListez tous vos systèmes OT :
\nPour chaque actif : version firmware/logiciel, connectivité réseau, date de dernière mise à jour sécurité, accès distants existants.
\nDessinez le schéma réseau OT actuel avec les zones de sécurité et les flux de communication. Identifiez :
\nPour chaque zone, évaluez :
\nPriorisez les zones à traiter en premier : criticité élevée + vulnérabilité élevée = priorité 1.
\nSur la base de l'analyse de risque :
\nPour chaque zone dont le niveau actuel est inférieur au SL cible, définissez les mesures correctives :
\nActions prioritaires SL 2 :
\nActions importantes SL 2 :\n7. Mettre à jour les firmwares des équipements OT (gateways, switches industriels)\n8. Documenter les procédures de réponse aux incidents\n9. Former les équipes de maintenance aux risques cybersécurité OT
\nLa conformité IEC 62443 n'est pas un projet ponctuel mais un processus continu. Planifiez :
\nLa directive NIS2 (transposée en France par la loi du 8 octobre 2024) ne cite pas explicitement l'IEC 62443, mais les mesures qu'elle impose y correspondent directement.
\nEntités essentielles : énergie (électricité, gaz, pétrole), transport (aérien, ferroviaire, maritime, routier), banque, infrastructures financières, eau (distribution, eaux usées), santé, infrastructures numériques.
\nEntités importantes : services postaux, gestion des déchets, produits chimiques, alimentation, fabrication industrielle (dispositifs médicaux, équipements électroniques, mécanique), fournisseurs numériques.
\nBeaucoup d'industriels commandent des politiques de sécurité rédigées avant d'avoir fait l'inventaire réel. Résultat : des documents théoriques déconnectés de la réalité terrain. Commencez toujours par l'inventaire et la cartographie.
\nLa sécurité OT a des contraintes spécifiques : les équipements ne peuvent pas être mis hors ligne pour mise à jour, les protocoles sont hérités (Modbus de 1979), les équipes sont des automaticiens — pas des informaticiens. Impliquez les équipes de production dès le départ.
\nSL 3 et SL 4 ont des exigences très strictes (authentification forte sur les automates, chiffrement de tous les protocols industriels y compris Modbus) qui nécessitent souvent de remplacer des équipements OT. Pour la majorité des industriels, SL 2 est la cible réaliste et suffisante.
\nLes incidents OT les plus courants impliquent des accès distants de sous-traitants de maintenance. Traiter la sécurité des accès tiers en priorité (comptes nominatifs, MFA, traçabilité) avant de s'attaquer aux aspects plus techniques.
\nNIS2 impose des mesures de sécurité mais ne certifie pas à l'IEC 62443. La certification IEC 62443 (par un organisme accrédité) est distincte de la conformité NIS2. Pour la plupart des industriels, une conformité documentée à l'IEC 62443 sans certification formelle est suffisante pour satisfaire NIS2.
\nEst-ce obligatoire de se certifier IEC 62443 pour être conforme NIS2 ?\nNon. La directive NIS2 impose des mesures techniques et organisationnelles de sécurité mais ne requiert pas de certification IEC 62443 formelle (qui est délivrée par des organismes accrédités comme TÜV, Bureau Veritas, etc.). En revanche, documenter que vos pratiques sont alignées avec IEC 62443 est un excellent moyen de démontrer votre conformité NIS2 à l'ANSSI.
\nPar quelle partie de l'IEC 62443 une PMI industrielle doit-elle commencer ?\nPour une PMI, commencez par IEC 62443-2-1 (politiques et procédures) et IEC 62443-3-3 (exigences système Security Level 1 et 2). Ce sont les parties les plus directement applicables et les plus demandées par les donneurs d'ordre. Les parties 4.x (composants) intéressent plutôt les fabricants d'équipements.
\nQu'est-ce qu'une zone de sécurité (Security Zone) dans IEC 62443 ?\nUne zone de sécurité est un groupe de systèmes ayant le même niveau de sécurité requis, séparés des autres zones par des conduits (canaux de communication contrôlés). Exemple : Zone 1 = automates de production (SL2), Zone 2 = SCADA (SL2), Zone 3 = IT (SL1). Les communications entre zones passent obligatoirement par un firewall ou une DMZ contrôlée.
\nComment évaluer le Security Level (SL) à cibler pour mon installation ?\nLe SL cible dépend de la conséquence d'un incident : SL1 pour un risque limité (arrêt temporaire d'un process non critique), SL2 pour un risque significatif (impact sur la production ou la sécurité des personnes), SL3 pour des systèmes critiques (énergie, eau, santé). La plupart des PMI industrielles visent SL2 pour leurs systèmes SCADA et SL1 pour les systèmes supports.
\nIEC 62443 couvre-t-il la sécurité des accès distants VPN ?\nOui. IEC 62443-3-3 traite explicitement l'authentification (SR 1.1, SR 1.2), le chiffrement des communications (SR 4.1), la gestion des sessions (SR 1.3) et la traçabilité (SR 2.8). Un VPN OpenVPN/IPSec avec authentification par certificat et journalisation répond aux exigences des Security Levels 1 et 2 sur ces points.
\nL'un des principaux freins à l'adoption de l'IoT industriel est la difficulté à justifier l'investissement auprès des décideurs : quel est le ROI réel ? Comment le mesurer ? Dans quels délais l'atteindre ?
\nCe guide propose une méthode structurée pour calculer le retour sur investissement d'un projet de supervision IoT industrielle, avec des exemples chiffrés issus de déploiements réels.
\nLa plupart des calculs de ROI IoT se concentrent sur les économies directes et évidentes. Mais l'IoT industriel génère des bénéfices dans quatre catégories souvent sous-estimées :
\nLes projets qui ne mesurent que la catégorie 1 attribuent systématiquement un ROI trop faible à l'IoT.
\nLe ROI se calcule sur une période donnée (généralement 1, 2 ou 3 ans) :
\nROI (%) = [(Bénéfices totaux - Coûts totaux) / Coûts totaux] × 100
Coûts totaux = Investissement initial + Coûts récurrents
\nBénéfices totaux = somme des économies et gains dans les 4 catégories
\nC'est souvent le poste le plus important et le plus facile à quantifier.
\nCoût réel d'un déplacement technicien (France, 2026) :
\n| Composante | Coût estimatif |
|---|---|
| Temps de trajet (2h aller-retour) | 60-120€ |
| Indemnités kilométriques (50km × 0.33€) | 33€ |
| Temps intervention sur site (1-2h) | 60-120€ |
| Astreinte (majoration 25-50%) | +30-80€ |
| Total déplacement d'astreinte | 180-350€ |
| Total déplacement de journée | 150-250€ |
Comment la supervision IoT réduit les déplacements :
\nÉconomies typiques constatées :
\nUne panne non anticipée coûte en moyenne 3 à 5× plus cher qu'une intervention préventive équivalente.
\nCoût d'un arrêt non planifié (exemple PME industrielle) :
\nAvec la supervision IoT et les alertes précoces, les indicateurs de dérive sont détectés avant la panne : la vibration monte progressivement, la température dépasse son seuil, le courant moteur augmente anormalement. L'intervention est planifiée pendant un arrêt programmé.
\nROI de la prévention : éviter 1 à 2 arrêts non planifiés par site par an suffit souvent à rembourser l'investissement IoT total.
\nSans supervision IoT, les opérateurs et techniciens passent du temps à :
\nEstimation du temps libéré (pour 20 équipements supervisés) :
\n| Tâche supprimée ou réduite | Temps/semaine avant | Temps/semaine après | Économie |
|---|---|---|---|
| Tournées de surveillance | 8h | 2h | 6h |
| Saisie manuelle des relevés | 3h | 0h | 3h |
| Compilation rapports | 2h | 0h (automatique) | 2h |
| Gestion des appels d'astreinte | 4h | 1h | 3h |
| Total | 17h | 3h | 14h/semaine |
14 heures/semaine × coût horaire chargé (60€) = 840€/semaine d'économies de productivité, soit 43 000€/an.
\nAvec l'historique des données disponible dans le cloud, le diagnostic d'une panne prend 10-15 minutes au lieu de 1-2 heures sur site. Le technicien visualise la courbe de tendance, identifie l'anomalie et planifie l'intervention ciblée.
\nPour les secteurs soumis à NIS2 (eau, énergie, transport, santé), les amendes pour non-conformité peuvent atteindre 2% du chiffre d'affaires annuel mondial pour une entité essentielle.
\nLa supervision IoT avec journalisation des accès, traçabilité des interventions et rapports d'audit automatiques réduit significativement le risque de non-conformité.
\nPour les entreprises sous SLA (prestataires de maintenance, exploitants de réseaux), chaque heure de non-disponibilité peut déclencher des pénalités contractuelles.
\nExemple : un prestataire d'exploitation d'un réseau d'eau avec pénalité de 2 000€/heure de non-conformité sur la pression. 1 panne détectée 4h plus tôt grâce à l'IoT = 8 000€ de pénalités évitées.
\nLes données de consommation électrique collectées en temps réel permettent d'identifier les pics de consommation inutiles, les équipements sous-optimisés et les opportunités d'effacement.
\nÉconomies typiques : 5 à 15% de réduction de la facture électrique sur les équipements supervisés.
\nExemple concret : une station de pompage avec pompes tournant à pleine puissance 24h/24. L'analyse IoT révèle que la demande la nuit est 40% inférieure. Réduction de la vitesse des pompes via variateur de vitesse (déjà présent) → économie de 22% sur la consommation électrique.
\nAvant l'IoT, les décisions de maintenance reposent sur l'expérience et l'historique papier. Après l'IoT, elles reposent sur les données réelles :
\nInvestissement initial :
\nCoûts récurrents annuels :
\nÉconomies annuelles :
\nROI année 1 : (103 600 - 24 000 - 19 200) / 43 200 = 140%\nPayback period : 4 à 5 mois
\nInvestissement initial :
\nCoûts récurrents annuels :
\nÉconomies annuelles :
\nROI année 1 : (54 000 - 9 000 - 7 200) / 16 200 = 234%\nPayback period : 3 mois
\nLe ROI est maximal sur les équipements à coût de panne élevé et sur les sites les plus éloignés (coût de déplacement élevé). Priorisez :
\nUn système IoT non intégré dans les workflows de maintenance génère peu de valeur. Le ROI est maximal quand :
\nÉtablissez des KPIs de suivi au démarrage :
\nComparez trimestriellement pour identifier les opportunités d'amélioration.
\nUne installation bâclée génère des reprises coûteuses. Prévoyez 30 à 50% du coût matériel pour l'installation, la configuration et la formation.
\nLe ROI maximal nécessite que les équipes adoptent réellement les nouvelles pratiques. Un technicien qui n'utilise pas l'accès distant avant de se déplacer n'économise rien.
\nLe coût de migration d'une plateforme IoT à une autre est souvent supérieur au coût initial. Vérifiez la scalabilité, l'API ouverte et la pérennité du fournisseur avant de vous engager.
\nLe ROI de l'IoT industriel est rarement le problème qu'on imagine : pour la grande majorité des déploiements industriels, il est atteint en moins de 12 mois, souvent en 3 à 6 mois.
\nLa vraie question n'est pas \"est-ce rentable ?\" — c'est \"par où commencer ?\" La réponse : commencez par 5 à 10 sites ou équipements à forte criticité, mesurez le ROI réel sur 3 mois, puis déployez à grande échelle en vous appuyant sur des données concrètes.
\nComment calculer le ROI d'un projet IoT industriel sans données historiques de pannes ?\nUtilisez les estimations sectorielles comme point de départ : une panne non planifiée coûte en moyenne 5 à 15% de la valeur annuelle de production pour l'industrie manufacturière. Pour les collectivités eau, comptez 2 500 à 5 000 € par intervention d'urgence non planifiée. Affinez les estimations avec vos données réelles après 3 mois de déploiement pilote.
\nLe ROI de l'IoT industriel est-il identique pour une PME et pour un grand groupe ?\nNon. Les grands groupes bénéficient d'économies d'échelle sur les gateways et les abonnements, et ont davantage d'équipements critiques — le ROI absolu est plus élevé. En revanche, le ROI relatif (% d'économies vs budget maintenance) est souvent meilleur pour les PME, car elles n'ont pas de ressources IT dédiées et économisent proportionnellement plus en automatisant la supervision.
\nFaut-il calculer le ROI avant de lancer un pilote ou après ?\nLes deux. Avant : un ROI estimé justifie le budget du pilote auprès de la direction. Après : le ROI mesuré (avec données réelles) justifie le déploiement complet et crédibilise les hypothèses initiales. L'expérience montre que le ROI réel est souvent supérieur au ROI estimé, car des bénéfices inattendus apparaissent lors du pilote (meilleure visibilité, décisions plus rapides, etc.).
\nQuels coûts cacher dans un projet IoT industriel ?\nLes coûts sous-estimés classiques : installation câblage RS-485 (prévoir 200–500 € par site), formation des équipes maintenance (2 jours minimum), configuration SCADA (intégration des nouvelles données dans les outils existants), et gestion du changement (faire adopter les nouveaux outils par les techniciens terrain).
\nLa supervision industrielle à distance est devenue un enjeu stratégique pour les industriels français. Entre la fin du réseau GPRS 2G (arrêt Bouygues et SFR fin 2026), la directive NIS2 qui impose des mesures de cybersécurité renforcées, et la pression sur les coûts de maintenance, les entreprises doivent moderniser leur approche de la télésurveillance.
\nCe guide couvre l'intégralité du sujet : définitions, architectures techniques, choix des protocoles, cybersécurité et mise en œuvre pratique pour des déploiements de 1 à 1 000 sites.
\nLa supervision industrielle à distance (ou télésurveillance industrielle) désigne l'ensemble des technologies permettant de :
\nElle s'applique à tous les secteurs : industrie manufacturière, eau et assainissement, énergie, agriculture, bâtiment technique.
\nCes termes sont souvent confondus. Voici les distinctions :
\n| Terme | Portée | Infrastructure |
|---|---|---|
| SCADA (Supervisory Control and Data Acquisition) | Site unique ou réseau de sites avec architecture centralisée | Serveur on-premise + IHM locales |
| Télésurveillance / Supervision à distance | Multi-sites, accès depuis n'importe où | WAN (4G, fibre) + cloud ou serveur central |
| IIoT (Industrial Internet of Things) | Capteurs & équipements connectés en réseau | Cloud, edge computing, APIs |
En 2026, les frontières s'estompent : les plateformes IIoT modernes (dont Eziwan) offrent des capacités SCADA cloud tout en intégrant les protocoles industriels historiques (Modbus, OPC-UA).
\nAvantages :
\nCas d'usage typiques : collectivités eau, réseaux de distribution d'énergie, parcs photovoltaïques, flottes d'équipements industriels géographiquement dispersés.
\nAvantages :
\nCas d'usage typiques : grandes entreprises industrielles avec SCADA existant, industries avec contraintes de souveraineté des données.
\nPour les sites générant beaucoup de données (lignes de production, presses, machines CNC), l'edge computing permet de traiter localement les données critiques et de n'envoyer au cloud que les données synthétiques.
\n\nModbus est le protocole le plus répandu dans l'industrie. Il existe dans deux variantes :
\nCe que Modbus permet de superviser : tous les automates industriels modernes (Siemens S7, Schneider Modicon, ABB, Allen Bradley), la grande majorité des compteurs d'énergie, variateurs de vitesse et capteurs industriels.
\nLimitation : architecture maître/esclave uniquement. Pas de notification d'événement — le maître doit interroger (poll) les esclaves régulièrement.
\nMQTT (Message Queuing Telemetry Transport) est un protocole publish/subscribe léger conçu pour les connexions à faible bande passante.
\nPoints forts pour la supervision à distance :
\nusine/ligne1/pompe3/courant — structure de données logiqueIntégration cloud : MQTT est supporté nativement par AWS IoT Core, Azure IoT Hub, Google Cloud IoT, HiveMQ.
\nOPC-UA (Unified Architecture) est le standard interopérable de l'Industrie 4.0.
\nPoints forts :
\nQuand choisir OPC-UA : intégrations avec SCADA existant, MES, ERP SAP. Environnements où la sémantique des données (pas juste les valeurs brutes) est importante.
\nLa supervision industrielle à distance est un vecteur d'attaque majeur si mal sécurisée. En 2024-2025, plusieurs incidents ont impliqué des accès distants non sécurisés à des équipements OT.
\n1. Aucun port entrant ouvert sur le réseau industriel
\nL'architecture zero-inbound-port est le principe fondamental : les équipements industriels initient eux-mêmes la connexion vers le cloud de supervision. Aucun port RDP, VNC ou Modbus n'est exposé directement sur Internet.
\n2. VPN et chiffrement obligatoires
\nToutes les communications entre les sites industriels et la plateforme de supervision doivent être chiffrées. OpenVPN avec chiffrement AES-256-GCM est la recommandation 2026 pour les nouveaux déploiements.
\n3. Authentification forte pour les accès distants
\nChaque technicien accédant à distance doit s'authentifier avec une clé cryptographique personnelle (pas un mot de passe partagé). L'authentification multi-facteurs (MFA) est obligatoire pour les entités soumises à NIS2.
\n4. Principe du moindre privilège
\nUn technicien de maintenance d'un automate spécifique n'a accès qu'à cet automate — pas à l'ensemble du réseau OT. La segmentation fine des accès limite la propagation en cas de compromission.
\n5. Journal d'audit complet
\nToutes les connexions distantes, modifications de paramètres et interventions sont enregistrées avec horodatage, identité et IP source. Ces logs sont requis par la directive NIS2 pour les entités essentielles et importantes.
\nLa directive NIS2 (transposée en droit français depuis octobre 2024) impose aux entités essentielles et entités importantes des mesures spécifiques pour les accès distants :
\nLes secteurs concernés : eau et assainissement, énergie, transport, santé, gestion des déchets, production industrielle critique.
\nMatériel nécessaire :
\nTemps de déploiement : 2 à 4 heures pour un technicien (installation matérielle + configuration cloud + validation des données Modbus).
\nCoût indicatif : 300-600€ de matériel + 30-80€/mois d'abonnement platform + SIM M2M.
\nÀ cette échelle, le Zero-Touch Provisioning (ZTP) devient essentiel pour réduire les coûts de déploiement.
\nProcessus ZTP Eziwan :
\nÉconomie vs configuration manuelle : sur 50 sites, le ZTP économise typiquement 2 à 3 jours-homme de configuration réseau.
\nPour les grandes flottes, les fonctionnalités de gestion centralisée deviennent critiques :
\nSituation avant : tournées hebdomadaires de supervision, 2-3 astreintes/semaine pour interventions urgentes.
\nSolution déployée : 80 gateways 4G LTE avec Modbus RTU, alertes temps réel sur niveaux et défauts pompes, accès distant techniciens via VPN OpenVPN/IPSec.
\nRésultats :
\nSituation avant : chaque site avait son propre SCADA local, aucune visibilité consolidée au niveau groupe.
\nSolution déployée : 3 gateways IoT consolidant les données Modbus de chaque site vers un dashboard cloud unique. Accès distant pour l'équipe maintenance groupe.
\nRésultats :
\nSituation avant : dataloggers propriétaires incompatibles entre fabricants d'onduleurs.
\nSolution déployée : gateways IoT avec parseur Modbus universel supportant les protocols SunSpec, SMA, ABB et Fronius. Dashboard de supervision de performance (kWh, performance ratio, disponibilité).
\nRésultats :
\nAvant de lancer votre projet de supervision à distance, vérifiez ces points :
\nLa supervision industrielle à distance n'est plus une option en 2026 : la fin du GPRS 2G, la directive NIS2 et la pression économique sur les coûts de maintenance l'imposent à toutes les entreprises industrielles ayant des sites distants.
\nLa bonne nouvelle : les solutions 4G LTE avec Zero-Touch Provisioning permettent aujourd'hui de connecter un site industriel en moins d'une heure, pour moins de 50€/mois tout compris.
\nLa clé du succès est de choisir une architecture cloud-native sécurisée dès le départ — pas d'ajouter la sécurité en couche par dessus une architecture non prévue pour ça.
\nQuelle est la différence entre SCADA et supervision IoT cloud ?
\nUn SCADA traditionnel est un système centralisé (souvent on-premise) avec des clients lourds (logiciels PC dédiés), une historisation locale, et une architecture en étoile. La supervision IoT cloud est une architecture distribuée : chaque site envoie ses données vers un cloud via la gateway, sans serveur central sur site. Le cloud offre l'accès multi-sites, le mobile, et l'API REST pour l'intégration — là où le SCADA traditionnel nécessite un VPN site-to-site et une licence par client. Les deux peuvent coexister via des connecteurs OPC-UA ou Modbus vers le SCADA existant.
\nCombien de variables peut-on superviser sur 100 sites simultanément ?
\nIl n'y a pas de limite fixe côté cloud — les plateformes IIoT modernes sont architecturées pour des millions de points de mesure. La limite pratique vient du côté gateway et réseau : une gateway standard collecte jusqu'à 500 variables Modbus par site avec un polling de 5 s, soit 6 000 valeurs/minute par site. Sur 100 sites, c'est 600 000 valeurs/minute — gérable si le cloud est dimensionné en conséquence (séries temporelles, partitionnement par site).
\nLa supervision à distance peut-elle fonctionner si l'automate est en STOP (arrêt programme) ?
\nOui pour la supervision de l'état de l'automate (CPU en STOP, heure de dernière alarme, état des entrées/sorties). Non pour la collecte Modbus des variables de process — le serveur Modbus TCP de l'automate cesse de répondre en STOP sur certains modèles (S7-1200 en STOP arrête MB_SERVER). Vérifier le comportement spécifique de l'automate en STOP avant de compter sur la collecte Modbus pour détecter les arrêts CPU.
\nQuelle est la latence minimale entre un changement d'état sur l'automate et sa visibilité dans le tableau de bord ?
\nAvec un polling Modbus de 1 s et un cloud bien dimensionné, la latence totale est typiquement de 2 à 5 s (1 s d'attente de polling + 1 à 2 s de transit 4G + 1 à 2 s de traitement cloud). Pour des alarmes critiques (dépassement de seuil), Eziwan peut envoyer des notifications SMS/email en moins de 10 s après détection du dépassement. Pour une réaction en temps réel (< 100 ms), il faut une logique locale sur l'automate ou la gateway — pas le cloud.
\nPeut-on superviser des équipements non Ethernet (compteurs RS-485, capteurs 4-20mA) ?
\nOui, via le port RS-485 de la gateway pour le Modbus RTU, et via les entrées analogiques pour les signaux 4-20 mA ou 0-10 V. Les capteurs sans protocole numérique (simples contacts secs, interrupteurs de niveau) se connectent aux entrées TOR de la gateway ou d'un module d'extension. L'objectif est de superviser l'ensemble du site depuis une seule gateway, indépendamment de l'hétérogénéité des équipements.
\nLa question \"quel protocole utiliser pour mon projet IoT industriel ?\" revient systématiquement dans les projets de modernisation d'usine. Modbus, MQTT et OPC-UA sont les trois protocoles les plus cités — mais ils ne sont pas des alternatives symétriques. Ils opèrent à des couches différentes, répondent à des besoins différents, et souvent se complètent plutôt que se concurrencent.
\nCet article clarifie leurs différences fondamentales, leurs forces et leurs limites, et vous donne un guide de décision pour choisir le bon protocole selon votre cas d'usage.
\nAvant de comparer, il faut comprendre que Modbus, MQTT et OPC-UA n'opèrent pas au même niveau :
\nModbus est un protocole de lecture de données : il permet d'interroger un équipement pour lire ses registres (mesures, états). C'est un protocole de terrain, maître/esclave, conçu pour l'acquisition de données sur des équipements industriels.
\nMQTT est un protocole de messagerie : il permet de publier et de s'abonner à des flux de données via un broker centralisé. C'est un protocole de transport de messages, pas d'acquisition directe sur un équipement.
\nOPC-UA est une architecture de services : il combine acquisition de données, accès au modèle de données, sécurité, alarmes, et historique en un seul standard industriel unifié. C'est la solution la plus complète — et la plus complexe.
\nEn pratique : La plupart des architectures IoT industrielles modernes utilisent les trois. Modbus pour lire les équipements de terrain. MQTT pour transporter les données vers le cloud. OPC-UA pour l'interopérabilité entre systèmes complexes.
\nModbus a été créé en 1979 par Modicon (aujourd'hui Schneider Electric). C'est le protocole industriel le plus ancien encore en service actif — et de loin le plus répandu sur le terrain industriel français.
\nModbus RTU fonctionne sur liaison série RS-485 (ou RS-232). Il est asynchrone, maître/esclave, avec une topologie bus linéaire (multidrop). Jusqu'à 247 esclaves sur un même bus RS-485.
\nModbus TCP est Modbus encapsulé dans des paquets TCP/IP. Il fonctionne sur Ethernet, port 502. Il conserve le modèle maître/esclave mais permet des topologies réseau arbitraires (étoile, arbre). Pas de limite stricte d'esclaves au niveau du réseau.
\nModbus expose 4 types de données :
\nPour lire une mesure de température sur un capteur : le maître envoie une requête \"lire les registres 3x01 à 3x02\", l'esclave répond avec les deux registres contenant la valeur (en general un float 32-bit sur deux registres contigus).
\nUniversalité absolue : Si vous avez un équipement industriel avec un port RS-485 ou un port Ethernet et ne savez pas quel protocole il utilise, commencez par tester Modbus. La probabilité est très élevée qu'il supporte Modbus.
\nSimplicité : Le protocole est simple — des registres numérotés, des fonctions de lecture/écriture standard. N'importe quel développeur peut implémenter un client Modbus en quelques heures.
\nRésilience : Pas de dépendance à un broker ou un serveur central. Le maître poll directement chaque esclave. Une panne du maître n'affecte pas les esclaves entre eux.
\nMaturité : 45 ans de déploiement industriel. Les bibliothèques Modbus existent dans tous les langages de programmation (Python, C, Java, JavaScript...).
\nArchitecture pull uniquement : Le maître doit interroger proactivement chaque esclave. Les équipements n'envoient pas de données spontanément. Sur un bus avec 50 esclaves interrogés toutes les secondes, la fréquence réelle par esclave peut descendre à 20 secondes.
\nPas de sécurité native : Modbus RTU et Modbus TCP n'ont aucun mécanisme d'authentification ni de chiffrement. N'importe quel appareil sur le réseau peut lire ou écrire les registres d'un équipement Modbus exposé. La sécurité doit être ajoutée au niveau réseau (VPN, segmentation).
\nPas de découverte automatique : Il n'existe pas de mécanisme de découverte des équipements Modbus sur un bus. Vous devez connaître l'adresse esclave et les adresses de registres de chaque équipement.
\nPas de nommage sémantique : Le registre 40001 ne dit pas ce qu'il contient — vous avez besoin de la documentation constructeur pour savoir que c'est \"température entrée eau\". Pas d'auto-description.
\nMQTT a été créé en 1999 par IBM pour la télémétrie sur des liaisons satellitaires à faible débit. Il a été standardisé par OASIS en 2014 (MQTT 3.1.1) et 2019 (MQTT 5.0).
\nMQTT est un protocole publish/subscribe : les publishers envoient des messages sur des topics, les subscribers reçoivent les messages sur les topics auxquels ils sont abonnés. Un broker MQTT central route les messages entre publishers et subscribers.
\nLe broker est le cœur de l'architecture MQTT. Les clients (publishers et subscribers) se connectent au broker — ils ne communiquent jamais directement entre eux.
\nArchitecture push : Les publishers envoient des données quand ils ont quelque chose à dire. Pas de polling — le subscriber reçoit les données immédiatement à la publication. Latence typique : 10-50ms end-to-end.
\nLightweight : Le protocole a été conçu pour des appareils contraints (microcontrôleurs, modems 2G). Un message MQTT peut tenir dans 2 octets (header minimum). Très économe en bande passante.
\nQoS configurable : Trois niveaux de qualité de service : QoS 0 (at most once), QoS 1 (at least once), QoS 2 (exactly once). Pour les applications critiques, QoS 2 garantit la livraison exactement une fois.
\nInteropérabilité cloud : Tous les grands cloud providers (AWS IoT Core, Azure IoT Hub, Google Cloud IoT) exposent un broker MQTT natif. MQTT est le protocole de facto pour les architectures IoT cloud.
\nTLS natif : MQTT supporte TLS 1.3 nativement. La sécurité est intégrée au protocole, pas un ajout.
\nNe peut pas lire les équipements directement : Un équipement Modbus RTU ne parle pas MQTT nativement. Il faut un gateway ou une passerelle qui lit les données Modbus et les publie en MQTT. C'est pourquoi Modbus et MQTT sont souvent utilisés ensemble dans les architectures IoT industrielles.
\nDépendance au broker : Si le broker MQTT tombe, toute l'architecture de messagerie s'effondre. La résilience du broker est critique. Les brokers managés (AWS IoT, HiveMQ Cloud) sont très fiables, mais créent une dépendance à un service externe.
\nPas de modèle de données standardisé : MQTT ne définit pas le format des messages ni la structure des topics. Chaque implémentation est libre — ce qui nuit à l'interopérabilité. Deux systèmes MQTT d'éditeurs différents ne communiquent pas forcément sans adaptation.
\nPas de requête/réponse natif : MQTT est orienté événements unidirectionnels. Pour implémenter un pattern requête/réponse (ex: demander un paramètre à un équipement), il faut utiliser MQTT 5.0 avec des topics de réponse corrélés — c'est possible mais plus complexe.
\nOPC-UA (IEC 62541) a été développé par l'OPC Foundation à partir de 2006 comme successeur de l'OPC Classic (basé sur COM/DCOM Windows). C'est le standard industriel le plus ambitieux : il combine acquisition de données, modèle sémantique, sécurité, historique, alarmes, et accès aux méthodes en un seul protocole.
\nOPC-UA est aujourd'hui le protocole préféré des constructeurs d'automates pour les architectures Industry 4.0 : Siemens TIA Portal (S7-1500), Rockwell ControlLogix, Beckhoff TwinCAT, B&R Automation — tous supportent OPC-UA nativement depuis 5 à 10 ans.
\nModèle de données sémantique : Contrairement à Modbus (des registres numérotés anonymes), OPC-UA expose un arbre d'objets nommés et typés. Le nœud \"ns=2;i=1001\" peut s'appeler \"Machine1/MoteurPrincipal/TemperatureRoulement\" avec des métadonnées (unité, plage, description). L'auto-description est native.
\nSécurité intégrée : Authentification, autorisation, chiffrement, intégrité des messages — tout est dans le protocole. OPC-UA supporte plusieurs profils de sécurité (None, Sign, SignAndEncrypt) avec des algorithmes modernes (AES-256, RSA-2048+).
\nPublish/Subscribe depuis OPC-UA PubSub (2017) : OPC-UA peut maintenant fonctionner en mode publication asynchrone (push), pas seulement en mode requête/réponse (pull). Il peut publier sur des brokers MQTT, rendant OPC-UA et MQTT complémentaires plutôt que concurrents.
\nAccès aux méthodes : OPC-UA permet d'appeler des méthodes sur les équipements — pas seulement lire des valeurs. Un actionnement de vanne, une commande de démarrage moteur — tout est modélisé comme un objet OPC-UA.
\nSémantique et interopérabilité : Les \"Companion Specifications\" OPC-UA définissent des modèles standardisés par secteur : OPC-UA for Plastics, for Robotics, for PackML (emballage), for Mining... Un logiciel SCADA supportant OPC-UA for PackML peut se connecter à n'importe quelle ligne d'emballage conforme, sans configuration spécifique.
\nComplexité : OPC-UA est le protocole le plus complexe à implémenter et à configurer. Les spécifications font plus de 1000 pages. La courbe d'apprentissage est significative pour les équipes sans expérience OPC-UA préalable.
\nRessources requises : Un serveur OPC-UA complet nécessite plus de ressources qu'un esclave Modbus. Les automates anciens ou les microcontrôleurs contraints ne peuvent pas embarquer un stack OPC-UA complet (il existe cependant des profils \"nano\" allégés).
\nPas universel sur le terrain : Les équipements anciens (avant 2010-2015) ne supportent pas OPC-UA. Sur un parc industriel hétérogène, vous rencontrerez beaucoup plus de Modbus que d'OPC-UA sur les équipements de terrain existants.
\nOverhead réseau : Les messages OPC-UA sont plus volumineux que les messages Modbus (XML ou Binary selon le transport). Sur des liaisons 4G à faible débit, cela peut être un facteur.
\nUsage : Supervision de process, alertes, historique. 80% des projets IoT industriels français correspondent à ce schéma.
\nUsage : Projets avec plusieurs consommateurs des données (SCADA + ERP + BI). MQTT comme bus d'intégration.
\nUsage : Usines avec automates récents, projets Industry 4.0, intégration MES.
\n| Besoin | Modbus RTU | Modbus TCP | MQTT | OPC-UA |
|---|---|---|---|---|
| Lire capteurs terrain RS-485 | ✓✓ | — | — | — |
| Lire automates sur réseau | ✓ | ✓✓ | — | ✓ |
| Envoyer données vers cloud | — | — | ✓✓ | ✓ |
| Interopérabilité SCADA/MES | ✗ | ✗ | Partiel | ✓✓ |
| Sécurité intégrée | ✗ | ✗ | TLS | ✓✓ |
| Équipements anciens | ✓✓ | ✓ | — | ✗ |
| Automates récents (>2015) | ✓ | ✓ | — | ✓✓ |
| Architectures cloud-native | ✗ | ✗ | ✓✓ | ✓ |
| PME sans expertise protoco | ✓✓ | ✓✓ | ✓ | ✗ |
Le gateway Eziwan est agnostique aux protocoles côté terrain :
\nCôté cloud, les données sont normalisées en interne et exposées via :
\nVous pouvez combiner Modbus RTU sur les équipements de terrain et MQTT vers votre cloud AWS/Azure sans modifier quoi que ce soit — le gateway fait la translation.
\nEn 2026, la réponse à \"Modbus ou MQTT ou OPC-UA ?\" est généralement \"les trois ensemble\" :
\nCe n'est pas une compétition — c'est une architecture en couches. Le choix n'est pas \"quel protocole\" mais \"quel protocole à quelle couche pour quel équipement\".
\nPeut-on utiliser Modbus et MQTT simultanément sur la même gateway ?
\nOui, et c'est l'architecture la plus courante en IIoT. La gateway collecte les données des automates en Modbus TCP ou RTU (couche terrain) et les publie en MQTT vers le cloud (couche transport). Modbus s'arrête à la gateway — il n'est jamais exposé sur Internet. MQTT prend le relais pour le transport vers le cloud, avec TLS 1.3 et authentification.
\nOPC-UA peut-il remplacer Modbus sur des automates existants (S7-1200, M340) ?
\nSur les Siemens S7-1200, OPC-UA serveur n'est disponible qu'à partir du firmware V4.4 et nécessite une configuration explicite dans TIA Portal. Sur les S7-1500, c'est natif depuis le firmware V2.0. Sur les Schneider M340, OPC-UA n'est pas natif — il faudrait un module additionnel. En pratique, pour les parcs existants, Modbus TCP reste la solution universelle ; OPC-UA est pertinent principalement pour les nouveaux projets avec des automates récents.
\nMQTT avec QoS 0 vs QoS 1 vs QoS 2 — que choisir pour la supervision industrielle ?
\nPour la supervision de données process (températures, pressions), QoS 1 (At Least Once) est le bon équilibre : la livraison est garantie même après reconnexion, au risque de quelques doublons (acceptables pour des données de monitoring). QoS 2 (Exactly Once) est plus lourd à cause de l'aller-retour de confirmation et rarement nécessaire pour des mesures. QoS 0 (At Most Once) convient pour des données très fréquentes (> 1/s) où une perte occasionnelle est acceptable.
\nUn broker MQTT public (HiveMQ, EMQX cloud) est-il suffisant pour l'industriel ?
\nPour des pilotes ou des non-critiques, oui. Mais pour une production avec contraintes de confidentialité (données process, identités des équipements), un broker privé hébergé en France est préférable. Les données MQTT passant par des brokers publics américains sont potentiellement soumises au CLOUD Act — à évaluer selon la sensibilité des données et le secteur d'activité.
\nOPC-UA a-t-il un impact sur les performances de l'automate par rapport à Modbus ?
\nOPC-UA est nettement plus gourmand en CPU et mémoire que Modbus TCP. Sur un S7-1500 CPU 1511 avec un serveur OPC-UA actif et 50 connexions clients, le temps de cycle peut augmenter de 5 à 15 %. Sur un S7-1200, les ressources sont plus limitées — tester systématiquement l'impact avec le programme de production complet avant de déployer OPC-UA en production.
\nLe marché des gateways IoT industriels s'est considérablement enrichi ces dernières années. Face à une offre pléthorique — des marques taïwanaises à 80€ aux solutions intégrées à 2000€, des boîtiers Modbus simples aux gateways avec VPN et edge computing — comment s'y retrouver ?
\nCe guide décrit les 9 critères qui permettent de distinguer un gateway vraiment adapté aux environnements industriels d'un produit grand public mal reconditionné. Il s'adresse aux responsables maintenance, automaticiens et DSI industriels qui ont un projet de connexion ou de supervision.
\nC'est le critère numéro un. Si votre gateway ne \"parle pas\" le protocole de vos équipements, tous les autres critères deviennent secondaires.
\nModbus RTU (RS-485) — Le standard absolu dans l'industrie française. Compteurs d'énergie, automates HVAC, sondes de mesure, variateurs de fréquence : si votre équipement a un port série RS-485, il parle probablement Modbus RTU. Tout gateway industriel digne de ce nom doit le supporter nativement.
\nModbus TCP (Ethernet) — La version réseau de Modbus. Automates récents, passerelles Modbus-Ethernet, équipements à interface RJ45. À vérifier : le gateway supporte-t-il le rôle de maître Modbus (polling actif) ou seulement de serveur (passif) ?
\nMQTT — Le protocole de messagerie IoT par excellence. Utilisé pour publier des données vers des brokers cloud (AWS IoT, Azure IoT Hub, MQTT Mosquitto local). Essentiel pour les architectures cloud-native.
\nOPC-UA — Standard industriel IEC 62541, adopté par Siemens, Rockwell, Beckhoff pour les automates récents. Si votre SI comprend des PLC Siemens S7-1500/1200 ou TIA Portal récent, vérifiez la compatibilité OPC-UA.
\nProtocoles spécifiques :
\nChecklist protocoles :
\nUn gateway industriel en 2026 doit embarquer un module 4G LTE Cat-M1/Cat-4 minimum. La 4G couvre 97% du territoire français en population et suffit pour 95% des applications IoT industrielles (supervision temps réel, alertes, accès distant).
\nPoints de vigilance :
\nUne seule SIM = un seul opérateur = un seul point de défaillance. Sur certaines zones industrielles (zones blanches partielles, tunnels, zones à faible couverture), un opérateur peut tomber pendant que l'autre maintient le signal.
\nLe Dual SIM avec deux SIM de deux opérateurs différents et bascule automatique est la solution pour les applications critiques. Eziwan embarque le Dual SIM nativement.
\nQuestions à poser :
\nPour les sites avec fibre ou Ethernet disponible, un gateway avec port Ethernet WAN permet d'utiliser la fibre comme connexion principale et la 4G comme backup. Les deux connexions doivent être gérées simultanément avec un failover automatique et transparent.
\nLa cybersécurité des gateways IoT industriels est devenue un critère non négociable, accélérée par NIS2 qui couvre désormais un large périmètre d'entreprises industrielles.
\nArchitecture outbound-only : Le gateway doit établir des connexions sortantes uniquement. Aucun port entrant ne doit être ouvert sur votre réseau OT. Cela élimine la surface d'attaque accessible depuis Internet. C'est l'architecture Zero Trust : \"Ne jamais faire confiance, toujours vérifier.\"
\nProtocole VPN : OpenVPN est aujourd'hui la référence : robuste, largement audité, il traverse les pare-feux via TCP 443 et s'authentifie par certificat X.509 (chiffrement AES-256-GCM). IPSec (IKEv2) reste pertinent pour les environnements régulés FIPS 140-2.
\nChiffrement des données en transit : TLS 1.3 minimum pour les communications cloud. Vérifiez que le gateway ne communique pas en clair avec un broker MQTT non chiffré.
\nAuthentification : Clés cryptographiques par device, révocables individuellement. Évitez les gateways avec mot de passe administrateur partagé entre tous les appareils.
\nMise à jour firmware sécurisée (OTA) : Les gateways non mis à jour deviennent des vecteurs d'attaque. Vérifiez que le gateway supporte les mises à jour OTA signées cryptographiquement.
\nDepuis octobre 2024, NIS2 impose aux entités essentielles et importantes de gérer la sécurité de leur chaîne d'approvisionnement numérique, incluant les gateways IoT. Un gateway qui ouvre des ports entrants sur le réseau OT ou communique en clair est une non-conformité NIS2.
\nUn gateway \"industriel\" doit survivre aux environnements industriels réels. Voici les certifications et spécifications à vérifier :
\n| Application | Température min | Température max |
|---|---|---|
| Local technique climatisé | -10°C | +40°C |
| Armoire non climatisée | -20°C | +60°C |
| Extérieur / zone froide | -40°C | +70°C |
Un gateway standard IT fonctionne entre 0°C et +40°C. Un gateway industriel réel fonctionne typiquement entre -20°C et +70°C.
\nIP20 : Protection minimale, usage uniquement en armoire fermée dans un local propre.
\nIP40 : Protection contre les corps solides de plus de 1mm. Armoire technique standard.
\nIP65 : Étanche aux poussières + jets d'eau. Pour les environnements poussiéreux (agroalimentaire, BTP, extérieur sous abri).
\nIP67 : Immersion temporaire jusqu'à 1 mètre. Pour les environnements très humides.
\nIP68 : Immersion prolongée. Rarement nécessaire mais utile pour les équipements enterrés.
Pour les applications sur véhicules industriels, ponts roulants, compresseurs ou environnements vibrants : vérifiez la conformité EN 61131-2 ou IEC 60068 pour les essais mécaniques.
\nPour une installation en armoire électrique, le montage sur rail DIN 35mm est le standard industrie. Évitez les gateways qui nécessitent des vis murales ou un montage sur rack 19\" non standard pour les installations industrielles.
\nCE (obligatoire UE) : Marquage CE est obligatoire pour tout équipement électronique vendu en Europe.
\nATEX (zones explosibles) : Pour les sites chimiques, pétroliers, avec atmosphères explosives potentielles. ATEX zone 1/2 ou zone 21/22 selon l'application.
\nEN 61131-2 : Standard spécifique pour les équipements utilisés avec des automates programmables industriels.
Le ZTP est un critère souvent sous-estimé, surtout lors d'un déploiement de plusieurs dizaines ou centaines de gateways.
\nSans ZTP : Chaque gateway doit être configuré manuellement avant déploiement. Un technicien doit se connecter à l'interface locale, entrer l'IP du serveur cloud, les credentials, les paramètres réseau... Pour 50 sites, c'est 50 interventions de 30 minutes minimum = 25 heures de travail technique, plus les déplacements.
\nAvec ZTP : Le gateway se connecte automatiquement au cloud de gestion à sa première mise sous tension (via SIM M2M pré-configurée). Il télécharge sa configuration depuis le serveur et est opérationnel en moins de 5 minutes sans intervention locale.
\nQuestions à poser au fournisseur :
\nLes gateways les plus avancés embarquent de la puissance de calcul permettant d'exécuter de la logique localement, sans dépendre du cloud :
\nAgrégation locale : Calculer des moyennes, min/max, sommes sur une période (ex: énergie consommée en kWh par heure) avant d'envoyer au cloud. Réduit la bande passante nécessaire.
\nAlertes locales : Déclencher une alarme locale (relai, buzzer, SMS direct) sans passer par le cloud. Utile en cas de coupure réseau — la gateway continue de surveiller et d'alerter localement.
\nFiltrage des données : N'envoyer que les données qui ont changé de plus d'un seuil défini. Réduit drastiquement les coûts de données mobiles sur les sites nombreux.
\nScripts de logique : Sur les gateways avancés (Eziwan, certains modèles Teltonika), possibilité d'exécuter des scripts Python ou JavaScript localement pour de la logique métier complexe.
\nPour les projets multi-sites (à partir de 3-4 sites), la console de gestion centralisée est un critère différenciant majeur :
\nTableau de bord flotte : Vue en temps réel de l'état de tous les gateways (connecté/déconnecté, niveau signal, alertes actives).
\nMises à jour firmware à distance : Déployer une mise à jour de sécurité sur 50 gateways en quelques clics, sans déplacement terrain.
\nConfiguration à distance : Modifier un seuil d'alarme, ajouter un nouveau capteur, changer un paramètre réseau — tout depuis la console web.
\nAlertes flotte : Recevoir une notification quand un gateway perd sa connexion ou quand un équipement dépasse un seuil.
\nCe critère est devenu stratégique pour les entreprises françaises avec NIS2 et les exigences de souveraineté numérique.
\nQuestions clés :
\nPour les entités essentielles NIS2 et les opérateurs d'importance vitale, l'hébergement des données en France chez un prestataire non soumis à des lois extraterritoriales étrangères est une exigence de fait.
\nLe meilleur gateway du monde ne vaut rien sans un support capable de répondre à vos questions techniques en temps réel :
\nSLA de support : Quel délai de réponse garanti ? 4h, 8h, 24h ? Pour les applications industrielles critiques, un SLA de moins de 4h heures ouvrées est recommandé.
\nExpertise industrielle : Le support connaît-il les protocoles industriels Modbus, PROFIBUS, Siemens S7 ? Ou est-ce un support généraliste IT ?
\nDocumentation : API documentée (OpenAPI 3.0) ? Exemples de code ? Librairies Python/Node ?
\nAccompagnement projet : Le fournisseur propose-t-il un accompagnement lors du premier déploiement ?
\n□ Protocoles
□ Modbus RTU (RS-485) maître
□ Modbus TCP maître
□ MQTT TLS
□ Protocoles spécifiques de votre secteur
□ Connectivité
□ 4G LTE intégré
□ Dual SIM avec deux opérateurs
□ Port Ethernet WAN (optionnel)
□ Délai failover < 30 secondes
□ Sécurité
□ Architecture outbound-only (zero inbound port)
□ VPN OpenVPN/IPSec ou équivalent moderne
□ TLS 1.3 pour les communications cloud
□ Authentification par clé cryptographique
□ Mise à jour OTA signée
□ Robustesse
□ Température -20°C / +70°C minimum
□ IP40 minimum (IP65 si environnement poussiéreux)
□ Montage rail DIN 35mm
□ Certifications CE (+ ATEX si nécessaire)
□ ZTP
□ Déploiement sans intervention locale
□ SIM M2M pré-configurée
□ Edge computing
□ Agrégation locale
□ Alertes locales sans cloud
□ Logique locale configurable
□ Console centralisée
□ Dashboard flotte temps réel
□ Mises à jour firmware OTA
□ Configuration à distance
□ Hébergement données
□ Hébergement France ou UE
□ Non soumis au CLOUD Act
□ ISO 27001 minimum
□ Support
□ SLA documenté
□ Expertise protocoles industriels
□ API documentée OpenAPI
Quelle différence entre un gateway IoT industriel et un routeur 4G industriel ?\nUn routeur 4G industriel assure la connectivité réseau IP (routage, NAT, VPN). Un gateway IoT industriel ajoute des capacités terrain : port RS-485 pour le Modbus RTU, edge computing, intégration cloud native (MQTT, API REST). Certains produits, comme l'Eziwan Gateway, combinent les deux fonctions en un seul équipement.
\nPeut-on utiliser un gateway IoT industriel sans abonnement cloud Eziwan ?\nLe hardware Eziwan Gateway peut fonctionner en mode autonome avec votre propre broker MQTT ou API. La plateforme cloud Eziwan (dashboard, ZTP, gestion de flotte, alertes) est optionnelle. Cela dit, elle est incluse dans l'abonnement et élimine la gestion d'infrastructure serveur.
\nCombien de registres Modbus peut-on collecter simultanément ?\nL'Eziwan Gateway peut gérer jusqu'à 500 registres Modbus (RTU ou TCP) par intervalle de polling. Pour les déploiements avec des besoins supérieurs (compteurs d'énergie multi-circuits, lignes avec de nombreux capteurs), le polling peut être distribué sur plusieurs créneaux temporels configurables.
\nQu'est-ce que l'edge computing sur un gateway industriel et en ai-je besoin ?\nL'edge computing permet d'exécuter de la logique directement sur le gateway (agrégation, filtrage, détection d'anomalie locale, alertes sans cloud). Utile quand : la connectivité est intermittente (les données sont traitées et bufferisées localement), le volume de données brutes est trop important à envoyer au cloud, ou une réaction rapide est requise (<1 s) sans passer par le cloud.
\nComment vérifier qu'un gateway respecte la réglementation NIS2 ?\nLa conformité NIS2 pour les gateways concerne : le chiffrement des communications (TLS 1.3 minimum), l'authentification forte (certificats X.509, pas de mot de passe par défaut), la traçabilité des accès (journal d'audit), les mises à jour de sécurité (OTA signées), et l'hébergement des données en UE (RGPD). Demandez à votre fournisseur son attestation de conformité ou ses certifications ISO 27001.
\nLa terminologie autour de la maintenance industrielle est souvent source de confusion : maintenance prédictive, conditionnelle, préventive, corrective — ces termes sont régulièrement utilisés de manière interchangeable, mais ils désignent des approches fondamentalement différentes avec des ROI très différents.
\nCet article clarifie les définitions, compare les approches sur des critères concrets, et vous aide à choisir la stratégie adaptée à votre contexte en 2026 — qu'il s'agisse d'une petite usine avec 20 équipements ou d'un grand site industriel avec 500+ actifs.
\nDéfinition : On intervient après la panne. L'équipement tombe, on répare.
\nVariantes :
\nCoût typique : 4 à 5× plus élevé que la maintenance préventive équivalente (pièces express, heures supplémentaires, pertes de production).
\nQuand c'est acceptable : Équipements non critiques facilement remplaçables, avec un coût de surveillance supérieur au coût de défaillance.
\nDéfinition : On remplace ou révise selon un calendrier fixe (intervalles de temps ou de production), indépendamment de l'état réel.
\nExemple : Changement de l'huile d'un réducteur toutes les 2000 heures, même si elle est encore en bon état.
\nProblème principal : 30 à 40% des pièces remplacées lors de visites préventives sont encore utilisables. On gaspille des ressources ET des composants.
\nCoût typique : 2 à 3× plus élevé que la maintenance conditionnelle bien calibrée.
\nQuand c'est pertinent : Équipements avec modes de dégradation bien connus et prévisibles dans le temps, contexte réglementaire imposant des révisions périodiques.
\nDéfinition : On intervient quand l'état réel de l'équipement l'indique, basé sur des mesures physiques continues (vibration, température, courant, acoustique, etc.).
\nPrincipe : Chaque équipement \"parle\" à travers ses données. On l'écoute.
\nExemple : On change le roulement quand la vibration dépasse un seuil critique établi lors de la mise en service, pas à date fixe.
\nROI documenté : Réduction de 25 à 55% des arrêts non planifiés, économies de 10 à 30% sur les coûts de maintenance totaux.
\nCe qu'il faut : Capteurs installés sur les équipements, acquisition de données en temps réel, seuils d'alerte configurés.
\nDéfinition : On prédit la date de défaillance future avec un modèle mathématique (statistique ou ML) alimenté par les données historiques et temps réel.
\nDifférence avec le conditionnel : La CBM dit \"l'équipement est en mauvais état, intervenez bientôt.\" La PdM dit \"l'équipement tombera en panne dans 3 à 5 jours avec 87% de probabilité.\"
\nCe qu'il faut : Données historiques d'au moins 12-18 mois par équipement, expertise en modélisation, équipes capables d'exploiter les prédictions.
\nRéalité terrain 2026 : La vraie maintenance prédictive (ML + modèles physiques) est aujourd'hui accessible aux grandes entreprises et aux ETI avec des équipes data. Pour les PME, la maintenance conditionnelle offre 80% des bénéfices pour 20% de la complexité.
\n| Critère | Corrective | Préventive | Conditionnelle | Prédictive |
|---|---|---|---|---|
| Coût de mise en place | Très faible | Faible | Moyen | Élevé |
| Coût d'exploitation | Très élevé | Moyen | Faible | Moyen |
| Complexité technique | Nulle | Faible | Moyenne | Élevée |
| Données nécessaires | Aucune | Calendrier | Temps réel | Historique + RT |
| ROI délai | Immédiat | 12-18 mois | 8-14 mois | 18-36 mois |
| Prévisibilité | Aucune | Bonne | Bonne | Excellente |
| Adapté aux PME | Oui | Oui | Oui | Parfois |
La maintenance conditionnelle repose sur des mesures physiques. Voici les capteurs les plus utilisés, classés par ROI :
\nCe qu'on détecte : Déséquilibre de rotation, désalignement arbres, dégradation de roulements, cavitation pompes, usure engrenages.
\nApplications : Moteurs électriques, pompes centrifuges, compresseurs, ventilateurs, convoyeurs.
\nSignaux précurseurs : Augmentation du niveau global de vibration (RMS), apparition de fréquences harmoniques caractéristiques, augmentation du kurtosis (impulsivité).
\nCoût capteur : 50€ (industriel basique) à 500€ (large bande + ICP).
\nDélai avant défaillance : Détection 2 à 12 semaines avant panne roulement.
\nCe qu'on détecte : Échauffement anormal moteurs, transformateurs, connexions électriques, paliers, freins.
\nApplications : Tableaux électriques, moteurs, roulements, circuits de refroidissement.
\nSignaux précurseurs : Augmentation de la température de fonctionnement au-delà de la valeur de référence établie.
\nCoût capteur : 20€ (sonde contact PT100) à 2000€ (caméra thermique fixe).
\nCe qu'on détecte : Déséquilibre de charge, dégradation isolant, harmoniques anormales, démarrage difficile.
\nApplications : Moteurs asynchrones, servomoteurs, systèmes d'entraînement.
\nAvantage : Pas d'installation mécanique — la mesure est non intrusive. Idéal pour les équipements difficiles d'accès.
\nCe qu'on détecte : Fuites de gaz comprimé, arc électrique, dégradation roulement à faible charge, défauts de lubrification.
\nApplications : Réseau air comprimé, armoires électriques HT, paliers lents.
\nROI typique : Un audit ultrasons air comprimé identifie en général 15 à 30% de fuites — économies immédiates sur la consommation électrique du compresseur.
\nCe qu'on détecte : Contamination particules, dégradation viscosité, présence eau, métaux d'usure.
\nApplications : Réducteurs, boites de vitesses, turbines, compresseurs.
\nCapteurs in-line : Permettent une surveillance continue sans prélèvement, avec alerte automatique sur particules ou diélectrique.
\nListez vos équipements et évaluez pour chacun :
\nConcentrez les capteurs CBM sur les équipements avec criticité élevée + défaillances progressives.
\nPour chaque équipement critique, définissez quels paramètres mesurer. Exemple pour une pompe centrifuge :
\nLes capteurs se connectent au gateway Eziwan via RS-485/Modbus RTU pour les capteurs industriels standard, ou via les sorties 4-20mA pour les transmetteurs de processus. Le gateway remonte toutes les mesures vers la plateforme cloud en temps réel.
\nLors de la mise en service, enregistrez les valeurs de référence de chaque paramètre sur un équipement neuf ou en bon état. Ces valeurs de référence servent à :
\nTrop sensible = fausses alarmes qui découragent les équipes. Pas assez sensible = pannes manquées. La calibration des seuils nécessite 2 à 4 semaines d'observation en conditions normales pour affiner.
\nEziwan permet de modifier les seuils depuis la plateforme cloud sans intervention terrain.
\nL'alarme CBM n'a de valeur que si elle déclenche une action planifiée dans la GMAO. L'API REST Eziwan permet de créer automatiquement un bon d'intervention dans votre GMAO (SAP PM, Infor EAM, Hive Maintenix) dès qu'une alarme est déclenchée.
\nContexte : Réducteur de 800 kW, coût de remplacement 180 000€, délai de livraison 6 semaines.
\nAvant CBM : 2 pannes catastrophiques en 4 ans. Chaque panne = 6 semaines d'arrêt partiel = 420 000€ de perte de production.
\nAprès CBM (vibration + température + analyse huile): Détection d'une dégradation progressive 8 semaines avant défaillance. Intervention planifiée pendant un arrêt programmé. Coût de l'intervention préventive : 28 000€ vs 180 000€ de remplacement catastrophique.
\nROI : 9 mois.
\nContexte : 12 motoréducteurs sur ligne critique. Maintenance préventive à 3000h (changement d'huile systématique + inspection).
\nAprès CBM (courant + vibration): Sur les 12 motoréducteurs surveillés, le CBM a permis de :
\nROI : 11 mois.
\nPour une PME industrielle (moins de 50 équipements):\nCommencez par la maintenance conditionnelle sur vos 5 à 10 équipements les plus critiques. L'investissement est abordable, le ROI rapide, et la complexité maîtrisable sans équipe data dédiée.
\nPour une ETI ou grande entreprise :\nLa maintenance conditionnelle reste la base. Sur les équipements les plus critiques avec des données historiques suffisantes, enrichissez avec des modèles prédictifs (sur 2 à 3 équipements prioritaires d'abord).
\nCe qu'on observe en 2026 : La majorité des industriels français qui ont réellement amélioré leur performance maintenance l'ont fait avec la maintenance conditionnelle basée sur IoT — pas avec des projets ML complexes. Le ROI est mesurable en moins d'un an.
\nQuelle différence entre maintenance prédictive et maintenance conditionnelle (CBM) ?\nLa maintenance conditionnelle déclenche une action quand un seuil est dépassé (ex : température > 85°C → alerte immédiate). La maintenance prédictive analyse les tendances sur le temps pour anticiper la dégradation avant que le seuil critique soit atteint (ex : la température monte de 2°C/semaine depuis 3 semaines → planifier une intervention dans 2 semaines). La maintenance conditionnelle est plus simple à déployer, le prédictif offre un lead time d'intervention plus long.
\nQuel type de capteur est le plus utile pour démarrer une maintenance conditionnelle ?\nPour les moteurs et pompes : le capteur de courant (transformateur de courant sur le câble d'alimentation) est le plus universel — il détecte la surcharge, le démarrage difficile et la dégradation mécanique sans aucune modification de l'équipement. Pour les transmissions mécaniques (réducteurs, paliers) : le capteur de vibration acceleromètre. Ces deux types de capteurs couvrent 80% des cas de défaillance préventable en industrie.
\nLa question de la localisation des données industrielles est passée d'un débat technique à un enjeu réglementaire majeur en 2025-2026. Entre l'entrée en application progressive de NIS2, les nouvelles sanctions RGPD sur les transferts hors UE, et la prise de conscience des risques liés au CLOUD Act américain, les entreprises industrielles françaises doivent impérativement savoir où sont hébergées leurs données de supervision OT/IoT.
\nCet article explore pourquoi l'hébergement en France est devenu un critère de sélection non négociable pour de nombreux industriels, et ce que cela implique concrètement pour votre choix de solution IIoT.
\nLes données industrielles générées par vos gateways IoT, automates, capteurs et systèmes SCADA couvrent un spectre large :
\nCes données, prises ensemble, constituent une carte détaillée de votre infrastructure industrielle : sa capacité de production, ses vulnérabilités, ses modes de défaillance. Si elles tombent entre de mauvaises mains — concurrents, acteurs étatiques hostiles, cybercriminels — les conséquences peuvent être sévères.
\nLa question n'est donc pas \"mes données sont-elles sensibles ?\" mais \"qui peut y accéder et sous quelle juridiction ?\"
\nDepuis 2018, le Clarifying Lawful Overseas Use of Data Act (CLOUD Act) impose aux entreprises américaines de fournir aux autorités fédérales américaines les données qu'elles hébergent — même si ces données sont physiquement stockées en Europe.
\nConcrètement, cela signifie que si vous utilisez AWS, Microsoft Azure, ou Google Cloud, vos données industrielles peuvent être saisies par le FBI ou la NSA, même si vos serveurs sont situés à Paris ou Francfort, sans que vous en soyez nécessairement informé, et sans recours juridique européen effectif.
\nPour les données industrielles, ce risque est particulièrement préoccupant :
\nLa Commission européenne et l'ANSSI ont tous deux recommandé d'éviter les prestataires soumis au CLOUD Act pour les données sensibles. NIS2 renforce cette recommandation en obligation de facto pour les entités essentielles.
\nNIS2 ne stipule pas explicitement une obligation d'hébergement en France ou en UE pour toutes les données. Mais plusieurs de ses exigences y conduisent indirectement :
\nL'article 21 de NIS2 exige une gestion des risques liés à la chaîne d'approvisionnement, incluant les fournisseurs de services cloud. Cela implique une évaluation formelle de chaque prestataire cloud : où est-il domicilié ? Sous quelle juridiction ses données peuvent-elles être saisies ? Quelles sont ses certifications de sécurité ?
\nPour les entités essentielles (EE) — dont font partie de nombreux industriels dans les secteurs énergie, eau, transport, santé, infrastructure numérique — cette évaluation doit être documentée et défendable en cas d'audit ANSSI.
\nNIS2 impose des délais de notification très courts : 24 heures pour l'alerte initiale, 72 heures pour le rapport d'incident. Pour respecter ces délais, vous devez avoir un accès immédiat aux journaux d'audit, logs de connexion, et données de supervision. Si ces données sont hébergées chez un prestataire américain soumis à des procédures légales, vous risquez de ne pas y accéder en temps voulu.
\nNIS2 exige un plan de continuité d'activité incluant la résilience des systèmes d'information. Un prestataire cloud dont l'opérabilité peut être compromise par une décision judiciaire américaine (injonction, gel d'actifs) représente un risque de continuité non acceptable pour les entités essentielles.
\nPour les entités essentielles, les sanctions NIS2 peuvent atteindre 10 millions d'euros ou 2% du chiffre d'affaires mondial. La responsabilité personnelle des dirigeants est également engagée. Dans ce contexte, le choix d'un hébergement \"pas cher mais risqué\" n'est plus rationnel économiquement.
\nLe RGPD s'applique aux données à caractère personnel — ce qui peut inclure des données industrielles si elles permettent d'identifier une personne physique. Exemples typiques :
\nPour ces données, le RGPD interdit tout transfert hors de l'Espace Économique Européen sans mécanisme de protection adéquat (Standard Contractual Clauses, Binding Corporate Rules, etc.). Depuis l'invalidation du Privacy Shield en 2020 (arrêt Schrems II), les transferts vers les États-Unis sont particulièrement fragiles juridiquement.
\nHéberger en France élimine toute ambiguïté : les données restent dans l'EEE, sous juridiction RGPD, sans mécanisme de transfert à justifier.
\nTous les hébergeurs français ne se valent pas. Pour une infrastructure IoT industrielle critique, recherchez ces certifications :
\nCertification de référence pour la sécurité de l'information. Indispensable. Exige un SMSI (Système de Management de la Sécurité de l'Information) documenté, audité annuellement.
\nObligatoire pour les données de santé (pharma, hôpitaux, dispositifs médicaux). Référentiel ANSSI/MiPih.
\nLe label de l'ANSSI pour les services cloud de confiance. Niveau de sécurité le plus élevé disponible pour le cloud français. Recommandé pour les OIV et les entités essentielles NIS2. Prestataires actuels : OVHcloud, Outscale (Dassault Systèmes), Oodrive.
\nListe des prestataires qualifiés pour les systèmes d'information sensibles.
\nAttention : certains prestataires annoncent un \"hébergement France\" tout en étant des filiales d'entreprises américaines soumises au CLOUD Act. Exigez une attestation que le prestataire n'est pas soumis à une loi extraterritoriale permettant l'accès à vos données sans notification.
\nLes 12 secteurs OIV en France (énergie, eau, transport, alimentation, finance, santé, etc.) ont des obligations de sécurité numérique spécifiques depuis la Loi de Programmation Militaire (LPM) de 2013. Pour eux, l'hébergement des données de supervision dans des centres de données français qualifiés n'est pas une option — c'est une exigence contractuelle de l'ANSSI.
\nAvec NIS2, le périmètre s'élargit considérablement :
\nUne PME sous-traitante d'Airbus, de Dassault Aviation, ou d'un laboratoire pharmaceutique peut être contractuellement tenue d'héberger ses données dans des conditions conformes aux exigences du donneur d'ordre. Les grands groupes industriels intègrent de plus en plus ces clauses dans leurs appels d'offres fournisseurs.
\nVoici 5 questions à poser à votre prestataire IIoT actuel ou futur :
\n1. Où sont physiquement hébergées mes données ?\nExigez une adresse de datacenter précise, pas juste \"en Europe\". Un hébergement \"Europe\" peut signifier Irlande (Amazon), Hollande (Microsoft), ou Finlande (Google) — tous soumis au CLOUD Act.
\n2. La société mère est-elle soumise au CLOUD Act ?\nSi votre prestataire est une filiale d'une entreprise américaine, il est soumis au CLOUD Act quelle que soit la localisation de ses serveurs.
\n3. Quelles sont vos certifications de sécurité ?\nISO 27001 minimum. SecNumCloud si vous êtes OIV ou entité essentielle NIS2.
\n4. Avez-vous signé un DPA (Data Processing Agreement) RGPD ?\nObligatoire dès que des données personnelles sont traitées (ce qui est souvent le cas pour les logs d'accès).
\n5. Pouvez-vous me fournir un rapport de pénétration récent ?\nLes prestataires sérieux publient des résumés de leurs tests d'intrusion ou les partagent sous NDA.
\nLa plateforme Eziwan est hébergée exclusivement en France, chez des prestataires certifiés ISO 27001. Nous sommes une entreprise française (SAS de droit français) et ne sommes soumis à aucune loi extraterritoriale permettant l'accès à vos données sans votre consentement et sans décision judiciaire française.
\nNos engagements concrets :
\nPour les entités essentielles NIS2 et les OIV, nous pouvons fournir un dossier complet incluant la politique de sécurité, les certifications, et les SLA contractuels adaptés aux exigences réglementaires.
\nEn 2026, la question \"où sont hébergées mes données industrielles ?\" est devenue aussi importante que \"mes équipements sont-ils redondants ?\" ou \"ai-je un backup de mes configurations automates ?\".
\nLes risques sont réels et documentés :
\nLa bonne nouvelle : les solutions d'hébergement souverain performantes et accessibles existent en France. Il ne s'agit plus de choisir entre sécurité et praticité — les plateformes IIoT modernes hébergées en France offrent les mêmes fonctionnalités que leurs homologues américaines, avec la garantie de souveraineté numérique.
\nLa localisation du datacenter ne suffit pas : les données industrielles traversent toute une chaîne qu'il faut évaluer maillon par maillon.
\n| Maillon | Question à poser | Point de vigilance |
|---|---|---|
| Carte SIM / opérateur | Où transitent les données mobiles (APN) ? | Un APN public route par l'Internet ouvert ; un APN privé garde le flux dans le réseau opérateur |
| Gateway / routeur | Le firmware et sa télémétrie remontent-ils vers un cloud tiers ? | Certains constructeurs asiatiques imposent leur cloud de gestion |
| Transport | Le chiffrement est-il de bout en bout (VPN, TLS) ? | Un tunnel terminé chez un intermédiaire crée un point de lecture |
| Plateforme cloud | Qui est l'hébergeur final et quel droit s'applique ? | Une interface française sur AWS reste soumise au CLOUD Act |
| Sauvegardes | Où sont répliquées les données ? | Les backups partent parfois dans une autre juridiction |
| Support | Depuis où les équipes support accèdent-elles aux données ? | Un support offshore = un accès extra-européen de fait |
Cet audit de bout en bout prend une demi-journée et évite les mauvaises surprises lors d'un questionnaire de sécurité client ou d'un contrôle NIS2.
\nToutes les données IoT industrielles sont-elles soumises au RGPD ?
\nLe RGPD s'applique aux données personnelles — typiquement les données de localisation liées à des véhicules identifiables, les données d'accès nominatifs, ou les données de production liées à des opérateurs identifiables. Les données purement process (températures, pressions, débits d'une ligne anonymisée) ne sont pas des données personnelles. Mais les journaux d'accès VPN (avec identités des techniciens) et les données de géolocalisation des actifs mobiles sont bien des données personnelles soumises au RGPD.
\nLe CLOUD Act américain concerne-t-il un prestataire cloud basé en Europe ?
\nOui, si ce prestataire est une filiale ou une société soumise au droit américain (siège aux États-Unis, cotation au NYSE/Nasdaq, groupe américain). AWS Europe (Frankfurt), Azure Europe, Google Cloud EU sont toutes des entités soumises au CLOUD Act via leur maison mère américaine. Seuls les hébergeurs de droit exclusivement français/européen (OVHcloud, Scaleway, 3DS Outscale, Outscale) sont hors du périmètre du CLOUD Act.
\nNIS2 impose-t-elle explicitement l'hébergement en France ou en UE ?
\nNIS2 n'impose pas explicitement un pays d'hébergement, mais exige des \"mesures techniques et organisationnelles appropriées\" incluant la sécurité de la chaîne d'approvisionnement et la protection des données. Pour les OIV (Opérateurs d'Importance Vitale) régis par la LPM, le SGDSN impose souvent l'hébergement sur des infrastructures qualifiées SecNumCloud — ce qui exclut de fait les clouds non-européens pour les données les plus sensibles.
\nQu'est-ce que la qualification SecNumCloud et qui l'obtient ?
\nSecNumCloud est le référentiel de l'ANSSI pour les prestataires de cloud \"de confiance\". Les prestataires qualifiés doivent entre autres garantir l'immunité au droit extra-européen (pas de CLOUD Act), la localisation des données en France, et des niveaux de sécurité audités. À fin 2025, les prestataires qualifiés SecNumCloud incluent OVHcloud, Outscale (3DS), et quelques autres.
\nUn industriel peut-il imposer à son client final l'hébergement de ses données en France ?
\nOui, via des clauses contractuelles (SLA, DPA — Data Processing Agreement). Dans les contrats B2B industriels, notamment dans les secteurs réglementés (défense, énergie, eau), il est courant d'imposer contractuellement l'hébergement en France ou en UE. Ces clauses peuvent être contrôlées par des audits annuels.
\n