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 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 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\"Mettez tout dans le cloud\" était le mantra de la transformation digitale industrielle jusqu'en 2020. Puis les projets ont rencontré la réalité terrain : une station de pompage avec 500 ms de latence réseau ne peut pas fermer une boucle de contrôle par le cloud. Un site de production qui génère 2 To de données par jour ne peut pas tout envoyer vers AWS sans des coûts de bande passante prohibitifs. Et un industriel du secteur défense ne peut pas héberger ses données de production sur un serveur dont la localisation physique lui échappe.
\nEn 2026, l'architecture dominante dans l'IoT industriel est hybride : traitement local à la source pour ce qui doit l'être, cloud pour ce qui bénéficie de l'échelle et de la centralisation. Ce guide vous aide à prendre la bonne décision pour chaque cas d'usage.
\nAvant de comparer, clarifions ce que ces termes signifient concrètement dans un contexte industriel.
\nLe cloud est un ensemble de serveurs distants accessibles via Internet ou un réseau privé WAN. En pratique industrielle, le cloud héberge les tableaux de bord de supervision, les bases de données historiques, les algorithmes d'analyse avancée et les outils collaboratifs. Les hyperscalers dominants sont AWS, Microsoft Azure et Google Cloud, mais des offres cloud souverains français (OVHcloud, Outscale/Dassault, Scaleway) gagnent en pertinence pour les données sensibles.
\nL'edge computing désigne le traitement des données au plus près de leur source — physiquement sur le site, dans l'armoire de contrôle ou dans l'équipement lui-même. Le \"edge\" dans \"edge computing\" est la frontière entre le réseau OT terrain et le reste — c'est là que se trouve le gateway industriel. En pratique, edge = votre gateway ou votre serveur local.
\nLe fog computing est un terme intermédiaire désignant un traitement distribué dans les couches entre le terrain et le cloud (agrégateurs de zone, serveurs de bâtiment, serveurs d'usine). En 2026, le terme \"fog\" est moins utilisé dans l'industrie que dans les publications académiques — la plupart des industriels parlent simplement d'architecture hybride edge + cloud.
\nLa hiérarchie dans une usine :
\nLe gateway industriel Eziwan opère au niveau 3 de cette hiérarchie : il est le point de jonction entre le réseau OT terrain et le cloud de supervision.
\nIl existe trois situations dans lesquelles le traitement en cloud seul est techniquement insuffisant ou inadmissible.
\nContrainte de latence temps réel
\nLa boucle de contrôle d'un automate industriel doit être bouclée en moins de 1 à 10 ms selon le processus. Cette exigence est physiquement incompatible avec un aller-retour réseau vers un cloud distant, qui prend au minimum 10 à 50 ms sur une liaison 4G LTE, et 5 à 20 ms sur une liaison fibre avec le serveur le plus proche en France.
\nLes applications qui nécessitent du traitement local pour fonctionner :
\nContrainte de bande passante
\nUn capteur de vibration industriel haute fréquence (accéléromètre à 10 kHz) génère environ 80 Mo de données brutes par minute. Une ligne de production avec 100 capteurs de ce type génère 8 Go par minute, soit 11,5 To par jour. Transmettre l'ensemble en temps réel vers le cloud coûterait des dizaines de milliers d'euros par mois en bande passante et en stockage cloud.
\nL'edge résout ce problème par deux mécanismes :
\nEn pratique, l'edge peut réduire le volume de données transmises au cloud de 70 à 95 % selon les applications.
\nContrainte de souveraineté des données
\nCertaines données industrielles ne peuvent pas sortir de l'entreprise ou du territoire national :
\nDans ces cas, le traitement edge et le stockage sont locaux. Le cloud peut recevoir des données anonymisées ou agrégées (KPI de performance) mais pas les données brutes sensibles.
\nPour la majorité des applications de supervision industrielle, le cloud seul est parfaitement adapté et simplifie considérablement l'architecture.
\nSupervision et monitoring non critiques
\nLa supervision d'une station de pompage à distance (relevé de niveau, pression, débit toutes les 5 secondes) n'a aucune contrainte de latence inférieure à 1 seconde. L'alarme \"niveau bas\" qui remonte en 200 ms plutôt qu'en 10 ms n'a pas d'impact opérationnel : l'opérateur voit l'alarme dans la seconde, et le processus de pompage a des temps de réponse de l'ordre de la minute ou de l'heure.
\nAnalytics et machine learning sur données historiques
\nLes algorithmes de maintenance prédictive entraînés sur 18 mois d'historique s'exécutent très efficacement dans le cloud, où les ressources de calcul sont élastiques et le stockage peu coûteux. Un modèle de détection d'anomalie qui s'exécute une fois par heure sur les données des 24 dernières heures n'a aucun besoin d'être déployé sur edge.
\nSupervision multi-sites centralisée
\nUn gestionnaire de réseau supervisant 50 stations de traitement d'eau réparties sur un département a tout intérêt à centraliser les données dans le cloud : tableaux de bord unifiés, corrélation entre sites, benchmarking de performance, rapports réglementaires automatisés. Implémenter ces fonctions sur 50 edges locaux serait non seulement coûteux mais quasi-impossible à maintenir.
\nGestion des mises à jour et configuration
\nLa gestion centralisée des configurations de routeurs, des versions firmware, et des règles d'alertes est nativement une fonction cloud. Le Zero Touch Provisioning (ZTP) est par définition un service cloud qui configure les équipements à distance.
\nL'architecture recommandée en 2026 pour les projets IoT industriels sérieux est hybride, avec une répartition claire des responsabilités entre edge et cloud.
\nRôles de l'edge (gateway industriel local) :
\nRôles du cloud :
\nLe protocole de synchronisation :\nLa gateway publie les données vers le cloud via MQTT over TLS ou HTTPS REST selon la configuration. En cas de perte de connectivité, les données sont tamponnées localement (typiquement dans un stockage flash de 4 à 32 Go) et renvoyées en bloc à la reconnexion. Cette architecture garantit qu'aucune donnée n'est perdue même en cas de coupure réseau de plusieurs heures.
\nSupervision de la gateway elle-même :\nL'edge gateway doit elle-même être supervisée depuis le cloud : disponibilité, signal LTE (RSRP/RSRQ), consommation CPU/RAM, espace disque, version firmware. Un gateway tombé en panne silencieuse pendant 48 heures sans être détecté n'est pas acceptable sur un site critique.
\nIndustrie agroalimentaire — monitoring chambre froide
\nUne chambre froide de stockage nécessite une alarme locale en cas de dépassement de température (> +4 °C pour une chambre positive), indépendamment de la connectivité réseau. Le gateway edge évalue localement la température et déclenche une alarme sonore locale + SMS + appel d'astreinte en moins de 30 secondes, sans aucun aller-retour cloud. En parallèle, les données de température sont remontées au cloud toutes les 5 minutes pour traçabilité et conformité HACCP.
\nDistribution d'eau — régulation de pression
\nUne station de pompage équipée d'un variateur de fréquence sur la pompe principale utilise l'edge pour la régulation locale de pression (consigne 3,5 bars, mesure toutes les 100 ms, ajustement de la vitesse de la pompe). Cette boucle de régulation s'exécute intégralement en local — elle ne peut pas tolérer la latence d'un aller-retour cloud. Le cloud reçoit les tendances de pression et de consommation d'énergie toutes les minutes.
\nÉnergie — parc solaire
\nUn parc solaire de 500 kWc avec 10 onduleurs génère environ 50 000 valeurs Modbus par heure. L'edge calcule localement le Performance Ratio et l'indicateur de soiling toutes les 5 minutes, compare les strings entre eux et génère une alerte si un string est à plus de 15 % sous la médiane. Le cloud reçoit les indicateurs calculés (pas les 50 000 valeurs brutes), les courbes de production agrégées et les alertes.
\nConstruction et BTP — suivi d'engin
\nUn compacteur sur chantier génère des données de vibration, de vitesse et de position GPS. L'edge calcule localement les \"passes de compactage\" (combinaison de position GPS et d'énergie de compactage) et remonte uniquement le résultat métier (carte de compactage) au cloud. Cela réduit le volume de données LTE transmis de 100× et permet de travailler même en zone de couverture faible.
\nLe gateway Eziwan est conçu comme un nœud d'edge computing industriel, pas comme un simple routeur transparent.
\nCollecte et normalisation locale :\nLe gateway interroge les équipements terrain (automates Modbus RTU, compteurs M-Bus, capteurs MQTT locaux) sur des cycles configurables de 100 ms à 24 heures selon le type de donnée. Les valeurs sont normalisées (unité, facteur d'échelle, décalage) et horodatées précisément (NTP synchronisé sur les serveurs temps français).
\nRègles d'alarme locale :\nLes règles d'alarme simples (seuil haut, seuil bas, valeur hors plage, absence de communication) sont évaluées sur le gateway. L'envoi d'alerte par SMS, email ou webhook peut se faire directement depuis l'edge, sans dépendance au cloud Eziwan. Cela garantit les alertes critiques même en cas de maintenance de la plateforme cloud.
\nStore and forward :\nLes données collectées sont tamponnées localement sur la mémoire flash du gateway. En cas de coupure de connectivité (perte de signal LTE, maintenance réseau), les données s'accumulent localement et sont transmises automatiquement au cloud à la reconnexion. La capacité de stockage locale permet de couvrir des coupures de plusieurs jours sans perte de données.
\nTunnel VPN permanent :\nLa connexion entre le gateway et le cloud Eziwan s'établit via OpenVPN, initié depuis le gateway (zero inbound port sur l'équipement). L'accès distant aux équipements OT locaux passe exclusivement par ce tunnel chiffré, sans jamais exposer un port sur Internet.
\nProtocoles supportés en local :
\nUne architecture edge/cloud réussie se définit avant de choisir les équipements. Voici le processus recommandé.
\nÉtape 1 : Cartographier les sources de données\nListez chaque équipement ou capteur, son protocole de communication, sa fréquence de génération de données, le volume de données brutes et la criticité métier des données.
\nÉtape 2 : Classifier les contraintes par cas d'usage\nPour chaque cas d'usage (alarme, régulation, reporting, analytique), identifiez la contrainte principale : latence (< 100 ms ? < 1 s ?), disponibilité sans réseau (oui/non), souveraineté (données sensibles ?), volume (> 1 Mo/min par source ?).
\nÉtape 3 : Appliquer la règle de décision
\n| Contrainte | Traitement edge | Traitement cloud |
|---|---|---|
| Latence < 500 ms | Obligatoire | Impossible |
| Disponibilité sans réseau | Obligatoire | Impossible |
| Volume > 1 Mo/min par source | Recommandé | Coûteux |
| Données sensibles (souveraineté) | Obligatoire | Avec conditions |
| Analytique ML sur historique | Optionnel | Recommandé |
| Supervision multi-sites | Optionnel | Recommandé |
| Interface utilisateur | Optionnel | Recommandé |
Étape 4 : Dimensionner l'edge\nCalculez le CPU, la RAM et le stockage nécessaires pour les traitements locaux identifiés à l'étape 3. Un gateway entry-level avec 512 Mo de RAM et 1 Go de stockage couvre 90 % des besoins d'edge industriel classique. Les applications d'analyse vidéo ou d'inférence ML embarquée nécessitent des gateways plus puissants (4–8 Go de RAM, GPU embarqué).
\nÉtape 5 : Valider la connectivité\nEstimez le débit réseau nécessaire après edge preprocessing. Une bande passante de 1 Mbps montant suffit pour la plupart des installations IoT industrielles avec edge (quelques centaines de points de données normalisés toutes les minutes). Comparez avec les forfaits SIM M2M disponibles sur votre zone.
\nCette démarche prend 2 à 4 heures pour un site industriel standard et conduit à des architectures mieux dimensionnées, moins coûteuses sur le long terme et plus robustes aux conditions réelles d'exploitation.
\nQu'est-ce que l'edge computing industriel concrètement — est-ce compliqué à déployer ?\nEn pratique, le edge computing industriel c'est votre gateway IoT qui exécute une logique de traitement local : calcul de moyennes, détection de seuils, filtrage, agrégation. Chez Eziwan, ces règles se configurent via le dashboard cloud (pas de programmation). Pour des traitements avancés (ML embarqué, Docker containers), un déploiement plus complexe est requis, mais la plupart des besoins industriels sont couverts par la configuration de règles.
\nQuand le edge computing ne suffit-il pas et faut-il absolument le cloud ?\nQuand les données doivent être corrélées entre plusieurs sites (ex : comparer la performance de 50 usines), quand l'analyse nécessite un historique long (18 mois de tendance), ou quand des équipes distantes doivent accéder à la supervision. Le edge seul ne peut pas offrir de visibilité multi-sites consolidée — c'est le rôle du cloud.
\nLa latence 4G LTE (30-100 ms) empêche-t-elle le cloud pour les alertes critiques ?\nPour les alertes critiques avec une réponse en moins de 500 ms, oui — le cloud seul n'est pas fiable. Mais avec l'edge, la détection et le déclenchement de l'alerte locale (SMS, relais, alarme sonore) se font en quelques millisecondes. Le cloud reçoit la notification de l'alerte quelques secondes après. La combinaison edge + cloud offre le meilleur des deux mondes.
\nL'edge computing sur gateway IoT permet-il d'écrire sur l'automate (commandes) ?\nOui. L'edge peut envoyer des commandes Modbus TCP en écriture sur l'automate (setpoints, commandes TOR). Cette fonction est à utiliser avec précaution : elle nécessite une analyse de sécurité (qui peut écrire quoi), des limites sur les valeurs autorisées, et une journalisation complète. NIS2 impose une traçabilité de toutes les actions distantes sur les systèmes OT.
\nQuelle est la différence entre store-and-forward et l'edge computing ?\nLe store-and-forward est une fonction de l'edge computing : les données sont collectées localement et bufferisées si la connexion cloud est indisponible, puis transmises dès la reconnexion. L'edge computing au sens large inclut aussi le traitement local (calculs, alertes, régulation), pas seulement le stockage tampon. Les deux sont utiles et complémentaires.
\nEnvie d'en savoir plus ? L'équipe Eziwan accompagne les industriels dans la conception et le déploiement d'architectures edge/cloud adaptées à leurs contraintes. Découvrez les capacités edge du gateway Eziwan ou consultez notre offre de télégestion industrielle pour un premier échange sur votre projet.
\nLa directive NIS2 (Network and Information Security 2) est transposée en droit français depuis octobre 2024. En 2026, les entités industrielles qui n'ont pas encore initié leur mise en conformité naviguent sur un terrain à risque : les premières sanctions par l'ANSSI sont attendues, et les attaques cyber sur les infrastructures industrielles continuent de progresser — selon le CERT-FR, les incidents OT ont augmenté de 38 % entre 2023 et 2025.
\nCet article vous donne une lecture claire de ce que NIS2 impose à l'industrie et une checklist de 30 points structurée pour évaluer votre niveau de conformité.
\nNIS2 succède à NIS1 (2016) avec un périmètre d'application considérablement élargi. La directive européenne 2022/2555 a été transposée en France par une loi spécifique qui donne à l'ANSSI les pouvoirs de supervision, d'audit et de sanction.
\nCe qui change fondamentalement par rapport à NIS1 :
\nLe périmètre s'élargit massivement : NIS1 concernait principalement les opérateurs d'importance vitale (OIV) et quelques prestataires critiques. NIS2 ajoute des dizaines de milliers d'entreprises supplémentaires, notamment dans l'industrie manufacturière, la fabrication de dispositifs médicaux, l'industrie chimique et la fabrication de matériaux critiques.
\nLa responsabilité remonte au niveau de la direction : les dirigeants peuvent être tenus personnellement responsables en cas de non-conformité grave. Ils doivent approuver les mesures de sécurité et suivre une formation cyber basique.
\nLes délais de notification sont courts : 24 heures pour la notification initiale en cas d'incident significatif, 72 heures pour le rapport intermédiaire, un mois pour le rapport final.
\nLes obligations s'étendent à la chaîne de sous-traitance : vous devez évaluer la sécurité de vos fournisseurs critiques et des prestataires qui accèdent à vos systèmes.
\nLa directive distingue deux catégories d'entités selon leur taille et leur secteur d'activité, avec des obligations légèrement différentes.
\nEntités essentielles (EE)
\nSont classées entités essentielles les organisations de grande taille (> 250 employés OU > 50 M€ de CA OU > 43 M€ de bilan) dans les secteurs :
\nLes entités essentielles sont soumises à une supervision proactive de l'ANSSI : audits planifiés, inspections sur place, obligation de déclaration d'incertitudes.
\nEntités importantes (EI)
\nSont classées entités importantes les organisations de taille moyenne (> 50 employés OU > 10 M€ de CA) dans les secteurs :
\nLes entités importantes sont soumises à une supervision réactive : l'ANSSI n'audite pas spontanément, mais peut déclencher un audit sur notification d'incident ou sur signalement.
\nCas des PME industrielles françaises
\nUne PME industrielle de 75 salariés avec 12 M€ de CA est une entité importante au titre de NIS2. Elle est soumise à l'ensemble des obligations techniques, même si les délais de mise en conformité peuvent être accordés selon les secteurs.
\nL'ANSSI a publié un outil d'auto-évaluation du périmètre disponible sur le site anssi.fr. Si vous n'avez pas encore effectué cette vérification, c'est la première étape.
\n☐ A1. Inventaire complet des actifs IT\nVous disposez d'un inventaire à jour de tous les équipements informatiques (serveurs, postes, équipements réseau) incluant version du système d'exploitation, version des logiciels critiques, responsable et criticité métier. Mis à jour au moins tous les 6 mois.
\n☐ A2. Inventaire complet des actifs OT\nVotre inventaire couvre les automates (PLC, RTU), IHM, superviseurs SCADA, passerelles IoT, routeurs industriels, et tout équipement connecté au réseau OT. Le firmware version et la date de dernière mise à jour sont documentés.
\n☐ A3. Cartographie des flux de données\nLes flux de communication entre les systèmes IT et OT sont documentés sous forme de diagramme de flux de données. Les flux non documentés sont bloqués par défaut (politique de whitelist).
\n☐ A4. Classification des actifs par criticité\nChaque actif est classifié selon sa criticité pour la continuité d'activité : critique (arrêt de production immédiat si compromis), important (dégradation significative), standard. Cette classification guide les priorités de sécurité.
\n☐ A5. Gestion du cycle de vie\nUn processus documenté gère les fins de vie des équipements : retrait des équipements hors support, décommissionnement sécurisé (effacement des données, retrait des comptes), recyclage.
\n☐ B1. MFA pour les accès distants\nL'authentification multi-facteurs (MFA) est obligatoire pour tout accès distant aux systèmes d'information, y compris les accès VPN aux réseaux OT. Les solutions SMS OTP sont déconseillées par l'ANSSI ; préférez TOTP (Google Authenticator, Aegis) ou clés FIDO2.
\n☐ B2. Principe du moindre privilège\nLes comptes utilisateurs disposent uniquement des droits nécessaires à leur mission. Les comptes administrateurs dédiés sont distincts des comptes de travail quotidien. Les droits sont revus au minimum annuellement et lors de chaque changement de poste.
\n☐ B3. Gestion des comptes partagés et de service\nLes comptes partagés (comptes génériques \"admin\", \"operator\") sont supprimés ou remplacés par des comptes nominatifs. Les comptes de service applicatifs sont gérés dans un coffre-fort (CyberArk, Hashicorp Vault, Bitwarden Business) avec rotation automatique des mots de passe.
\n☐ B4. Contrôle des accès physiques\nL'accès physique aux salles serveurs, armoires de contrôle et locaux techniques est contrôlé par badging ou clé, avec journalisation. Les accès des intervenants extérieurs sont tracés.
\n☐ B5. Révocation des accès\nUn processus formalisé garantit la révocation immédiate des accès lors d'un départ ou d'un changement de fonction. Le délai de révocation est documenté et inférieur à 24 heures pour les accès critiques.
\n☐ C1. VPN pour tous les accès distants OT\nTout accès distant à un réseau OT (SCADA, supervision, automates) passe obligatoirement par un VPN chiffré (IPsec, OpenVPN ou TLS mutuel). Les accès directs Internet vers des équipements OT sont interdits et techniquement bloqués.
\n☐ C2. Segmentation IT/OT\nLe réseau OT est physiquement ou logiquement séparé du réseau IT (bureau, entreprise). La communication entre zones passe par une DMZ ou un firewall dédié avec règles explicites. La politique par défaut est \"deny all\".
\n☐ C3. Chiffrement des communications cloud\nToutes les communications entre les équipements terrain et les plateformes cloud (MQTT, HTTPS, API REST) utilisent TLS 1.2 minimum (TLS 1.3 recommandé). Les certificats sont valides, non auto-signés, et leur expiration est monitorée.
\n☐ C4. Zéro port entrant ouvert sur Internet\nAucun équipement OT, aucune IHM, aucun superviseur n'est directement accessible depuis Internet sur un port entrant. Tout accès distant est initié depuis l'équipement vers la plateforme (modèle \"call home\" ou accès via VPN client).
\n☐ C5. Gestion des clés et certificats\nUn inventaire des certificats TLS, clés VPN et secrets applicatifs est maintenu. Les clés et certificats arrivant à expiration dans les 30 jours déclenchent une alerte. Un processus de rotation est documenté.
\n☐ D1. Journalisation des événements de sécurité\nLes équipements critiques (firewall, VPN, IHM, serveurs SCADA) génèrent des logs de sécurité collectés dans un système centralisé (SIEM, syslog server). La rétention est d'au moins 12 mois pour les entités essentielles, 6 mois pour les entités importantes.
\n☐ D2. Surveillance des anomalies\nDes règles de détection d'anomalies sont actives sur les flux réseau OT : connexions vers des destinations inconnues, volumes de trafic inhabituels, connexions hors horaires de production, tentatives d'authentification échouées répétées.
\n☐ D3. Procédure de réponse aux incidents documentée\nUn plan de réponse aux incidents (PRI) est documenté, approuvé par la direction, et testé au moins une fois par an (exercice de simulation ou test tabletop). Il couvre les phases de détection, containment, éradication, récupération et communication.
\n☐ D4. Contacts CERT-FR et ANSSI à jour\nL'entreprise a enregistré ses coordonnées auprès de l'ANSSI via le portail NIS2. Les coordonnantes du responsable sécurité et de la direction sont à jour. Le contact du CERT-FR (cert-fr.cert.gouv.fr, +33 3 51 14 17 41) est connu des équipes concernées.
\n☐ E1. Plan de continuité d'activité (PCA) documenté\nUn PCA couvrant les scénarios de cyberattaque (ransomware, compromission SCADA) est documenté et testé. Il définit les procédures de fonctionnement dégradé (mode manuel, redémarrage à partir de backups propres).
\n☐ E2. Sauvegardes régulières et testées\nLes configurations des automates, SCADA, IHM et serveurs sont sauvegardées selon une politique documentée. Les sauvegardes sont stockées hors ligne ou dans un environnement isolé. Leur restauration est testée au minimum semestriellement.
\n☐ E3. Redondance des accès réseau\nLes sites critiques disposent d'une redondance de connectivité (Dual SIM multi-opérateur, fibre + 4G LTE) pour maintenir l'accès distant de supervision en cas de défaillance d'un opérateur.
\n☐ E4. Délais de reprise documentés (RTO/RPO)\nLes objectifs de reprise après incident (RTO : Recovery Time Objective, RPO : Recovery Point Objective) sont définis et documentés pour chaque système critique. Ces objectifs sont cohérents avec les engagements contractuels envers les clients.
\n☐ F1. Formation cyber obligatoire pour la direction\nNIS2 impose que les dirigeants soient formés aux risques cyber et aux mesures de sécurité applicables à l'organisation. Cette formation (au minimum 4 heures) doit être documentée avec date et attestation.
\n☐ F2. Sensibilisation régulière des employés\nUne session de sensibilisation aux risques cyber (phishing, ingénierie sociale, mots de passe) est organisée au minimum une fois par an pour l'ensemble du personnel. Les sous-traitants ayant accès aux systèmes sont inclus.
\n☐ F3. Exercice de phishing\nUn exercice de phishing simulé est réalisé au minimum annuellement pour mesurer le niveau de vigilance des employés et identifier les personnes à risque pour une formation renforcée.
\n☐ G1. Inventaire des sous-traitants critiques\nLes prestataires qui accèdent à vos systèmes d'information ou OT (intégrateurs, mainteneurs, éditeurs de logiciels) sont listés avec la criticité de leur accès. Cet inventaire est maintenu à jour.
\n☐ G2. Clauses contractuelles de sécurité\nLes contrats avec les prestataires critiques incluent des clauses de sécurité : obligation de signalement des incidents, conformité NIS2 pour les entités soumises, droit d'audit, confidentialité.
\n☐ G3. Accès sous-traitants limités et tracés\nLes accès distants accordés aux sous-traitants (accès maintenance PLC, téléassistance) sont limités dans le temps, tracés dans un journal et révocables immédiatement. Les VPN dédiés par prestataire sont préférables aux comptes partagés.
\n☐ G4. Évaluation de sécurité des fournisseurs critiques\nLes fournisseurs de logiciels ou de matériels critiques font l'objet d'une évaluation minimale de leur posture de sécurité (questionnaire, certifications ISO 27001, audit).
\nL'accès distant sécurisé aux systèmes OT est souvent l'angle mort le plus critique des entreprises industrielles. C'est aussi l'un des vecteurs d'attaque les plus exploités — le rapport ENISA 2025 sur les incidents OT cite les accès distants mal sécurisés comme le vecteur d'entrée principal dans 42 % des incidents documentés.
\nLes mauvaises pratiques les plus fréquentes :
\nL'approche conforme NIS2 :
\nCette architecture est accessible pour une PMI industrielle avec des équipements modernes — un routeur industriel Eziwan avec VPN OpenVPN/IPSec intégré et accès distant via la plateforme Eziwan Cloud répond à ces exigences sans nécessiter d'infrastructure complexe.
\nNIS2 impose des délais stricts de notification en cas d'incident de sécurité significatif, défini comme un incident ayant ou susceptible d'avoir un impact significatif sur la continuité du service.
\nNotification initiale (Early Warning) — 24 heures :\nSignalement à l'ANSSI via le portail dédié si l'incident est susceptible d'avoir un impact transfrontière, s'il résulte d'une infraction pénale, ou s'il peut affecter d'autres entités. Cette notification est succincte : nature de l'incident, systèmes touchés, impact initial estimé.
\nNotification intermédiaire — 72 heures :\nRapport plus détaillé incluant une évaluation préliminaire de la sévérité, de la cause probable et des mesures de containment en cours.
\nRapport final — 1 mois :\nDescription complète de l'incident, cause identifiée, impact réel, mesures de remédiation appliquées, mesures de prévention de récurrence.
\nConseil pratique : les délais commencent à courir à partir du moment où l'entreprise a connaissance de l'incident — pas à partir du moment où l'incident a réellement commencé. Un incident de ransomware découvert 3 semaines après l'intrusion initiale déclenche le compteur à la date de découverte, pas à la date de l'intrusion. Documentez précisément la chronologie de la découverte.
\nNIS2 introduit un régime de sanctions administratives significativement plus sévère que NIS1.
\nEntités essentielles :
\nEntités importantes :
\nLes critères d'appréciation des sanctions :
\nEn pratique, les premières sanctions françaises seront probablement ciblées sur les entités essentielles grandes tailles avant de s'étendre aux entités importantes. Mais l'expérience RGPD montre que l'administration monte rapidement en puissance une fois le cadre établi.
\nResponsabilité des dirigeants : en cas d'infraction grave résultant d'une négligence manifeste, NIS2 prévoit que les dirigeants peuvent être personnellement poursuivis. Cette disposition est une nouveauté importante qui place la cybersécurité au niveau du comité de direction.
\nPour les petites structures, l'ANSSI recommande de commencer par le diagnostic CyberDC disponible via cybermalveillance.gouv.fr, puis de prioriser les mesures selon le résultat.
\nMa PME industrielle est-elle concernée par NIS2 ?\nSi vous avez entre 50 et 249 employés (ou un CA entre 10 M€ et 50 M€) et que vous opérez dans un secteur listé dans NIS2 (industrie manufacturière critique, eau, énergie, santé, etc.), vous êtes probablement une entité importante (EI). En dessous de ces seuils, vous n'êtes a priori pas directement soumis, mais vos donneurs d'ordre (EE ou EI) peuvent vous imposer des obligations contractuelles de sécurité. Utilisez l'outil d'auto-évaluation ANSSI disponible sur cert.ssi.gouv.fr/nis2 pour vérifier.
\nQuand les premières sanctions NIS2 sont-elles attendues en France ?\nLa transposition française est effective depuis octobre 2024. L'ANSSI priorise dans un premier temps la notification des entités concernées et l'accompagnement à la mise en conformité. Les premières sanctions administratives sont attendues à partir de 2026, en commençant par les entités essentielles de grande taille. Les PME auront généralement un délai d'accompagnement avant sanctions.
\nNIS2 couvre-t-il les systèmes OT/SCADA ou uniquement l'informatique de gestion ?\nNIS2 s'applique explicitement aux systèmes OT (Operational Technology), SCADA, ICS et systèmes de contrôle industriel. L'ANSSI a publié un guide spécifique \"Sécurité des systèmes industriels\" qui décrit les mesures concrètes pour les automates, IHM, SCADA et réseaux OT. La segmentation IT/OT et la sécurisation des accès distants aux PLC sont des obligations directes.
\nUn seul incident NIS2 peut-il déclencher des sanctions automatiquement ?\nNon. Une obligation de notification n'est pas une sanction. L'obligation de notifier un incident à l'ANSSI dans les 24h n'entraîne pas automatiquement une sanction — c'est une obligation procédurale. Les sanctions interviennent en cas de non-conformité aux mesures techniques et organisationnelles (accès non sécurisés, absence de sauvegardes, pas de gestion des vulnérabilités), ou en cas de non-coopération avec l'ANSSI.
\nComment prouver sa conformité NIS2 à l'ANSSI ?\nL'ANSSI peut demander des preuves documentaires : politiques de sécurité approuvées par la direction, logs de sécurité, résultats d'audits, plans de formation, PCA testé. Pour les entités essentielles, des audits sur place sont possibles. La meilleure préparation est de documenter systématiquement vos mesures dès maintenant : date d'implémentation, responsable, résultats.
\nEnvie d'en savoir plus ? Eziwan aide les industriels à sécuriser leurs accès distants OT conformément aux exigences NIS2 : VPN OpenVPN/IPSec, segmentation réseau, zéro port entrant ouvert. Consultez notre guide sur la cybersécurité OT ou contactez-nous pour un audit de vos accès distants.
\nLa France dispose aujourd'hui de plus de 21 GWc de puissance photovoltaïque installée, avec des objectifs de 100 GWc à horizon 2050. Derrière ces chiffres se cache une réalité opérationnelle souvent sous-estimée : chaque watt-heure non produit coûte de l'argent, et sans supervision active, un parc solaire laisse systématiquement de la production sur la table.
\nUn string court-circuité, un onduleur en alerte silencieuse, un capteur de température hors plage : ces incidents mineurs passent inaperçus pendant des semaines ou des mois sans monitoring, générant des pertes de production cumulées significatives. Ce guide explique comment mettre en place une supervision IoT efficace pour un parc photovoltaïque, de la toiture industrielle de 10 kWc au champ solaire au sol de plusieurs mégawatts.
\nL'absence de supervision d'un parc solaire n'est pas une économie — c'est un report de coût avec intérêts.
\nPertes de production non détectées : une cellule partielle ombrée ou encrassée dans un string peut réduire la production de ce string de 20 à 60 % selon la technologie des modules (sans ou avec optimiseurs). Sur un parc de 500 kWc, un string défaillant représente une perte de 5 000 à 15 000 kWh par an selon l'ensoleillement, soit 600 à 1 800 € de revente non réalisée (au tarif de rachat ou au prix spot EPEX).
\nDégradation accélérée non détectée : les modules photovoltaïques se dégradent en moyenne de 0,5 % par an. Certains défauts accélèrent cette dégradation : points chauds (hot spots), délaminages, microfissures post-grêle. Détectés tôt par thermographie ou analyse de courbes IV, ces défauts coûtent 200–500 € à traiter par module. Détectés tard, après 2 ou 3 ans, ils imposent un remplacement complet.
\nInvalidation des garanties constructeur : la plupart des garanties de performance des modules (25 ans) et des onduleurs (5–10 ans) exigent un suivi des conditions d'exploitation. Sans données de monitoring horodatées, une réclamation en garantie est difficile à défendre.
\nNon-conformité ENEDIS : les producteurs d'énergie raccordés au réseau public sont soumis à des obligations de comptage et de déclaration. Une installation qui manque des données de production peut se voir contester ses droits de rachat lors des audits.
\nChiffres représentatifs : une étude européenne (2023) portant sur 400 parcs de 10 kWc à 10 MWc a montré que les parcs sans monitoring présentaient des écarts de performance de 3 à 8 % par rapport aux parcs supervisés de caractéristiques équivalentes. Sur un parc de 1 MWc produisant 1 200 MWh/an, cela représente 36 à 96 MWh perdus, soit 3 600 à 14 400 € par an selon le prix de l'énergie.
\nUne architecture de supervision photovoltaïque efficace s'organise en trois couches.
\nCouche terrain (capteurs et équipements) :
\nCouche communication (passerelle IoT) :
\nCouche cloud (supervision et analytique) :
\nPour une installation de moins de 36 kWc en toiture industrielle, l'architecture peut être simplifiée : un seul onduleur avec interface de communication intégrée, une gateway 4G avec Modbus RTU, et une plateforme SaaS de supervision.
\nPour un parc au sol de 1 MWc, la complexité augmente : plusieurs boîtiers de regroupement, une station météo dédiée, un compteur ENEDIS séparé, et potentiellement un sous-réseau Ethernet industriel entre la gateway et les équipements.
\nLe secteur photovoltaïque a convergé vers SunSpec Alliance comme référentiel d'interopérabilité. SunSpec définit des modèles de données standardisés implémentés sur Modbus TCP (port 502) ou Modbus RTU (RS-485).
\nPourquoi SunSpec est important : avant SunSpec, chaque constructeur d'onduleurs avait son propre registre Modbus propriétaire. Intégrer des onduleurs SMA, Huawei, SolarEdge, Fronius et Sungrow dans un même système de supervision nécessitait autant de drivers que de marques. SunSpec standardise les adresses et le format des données essentielles.
\nLes modèles SunSpec principaux :
\nEn pratique, l'implémentation SunSpec varie selon les constructeurs et les versions firmware. Vérifiez toujours la liste des modèles SunSpec supportés dans la documentation de l'onduleur, et testez la lecture de registres avant le déploiement.
\nAlternatives : pour les onduleurs qui n'implémentent pas SunSpec, des protocoles propriétaires sont disponibles via RS-485 ou via des applications constructeur (SMA Sunny Portal, Huawei FusionSolar, SolarEdge Monitoring). Ces solutions sont fonctionnelles mais créent une dépendance au cloud du constructeur qui peut être problématique pour la souveraineté des données et la continuité de service.
\nUn système de supervision doit collecter les données à des granularités et des fréquences adaptées à chaque usage.
\nDonnées onduleur (toutes les 1 à 5 minutes) :
\nDonnées string (toutes les 5 à 15 minutes) :
\nStation météo (toutes les 1 à 5 minutes) :
\nCompteur de production (toutes les 15 minutes) :
\nIndicateurs calculés (Performance Ratio, PR) :\nLe Performance Ratio est le KPI fondamental d'un parc PV. Il se calcule comme le rapport entre l'énergie réellement produite et l'énergie théoriquement produisible dans les mêmes conditions d'irradiance. Un PR de 80 % est typique pour une installation bien entretenue en France. Un PR en dessous de 75 % doit déclencher une investigation.
\nLes alertes en temps réel signalent les pannes déjà avérées. Les alertes prédictives permettent d'intervenir avant que la perte de production soit significative.
\nDétection d'encrassement (soiling)
\nL'encrassement progressif des modules est souvent la première cause de sous-performance sur les parcs en zones agricoles, près de routes ou en région semi-aride. La détection repose sur le suivi du Soiling Index :
\nSoiling Index = PR_mesuré / PR_référence_modules_propres
\nQuand le Soiling Index descend en dessous de 0,97 (perte de 3 %), le lavage est économiquement justifié dans la plupart des configurations. Sur un parc de 1 MWc, une perte de 3 % représente ~36 MWh/an, soit 3 600 à 7 200 € selon le prix de l'énergie — le coût d'un lavage professionnel est généralement de 0,01 à 0,02 €/Wc.
\nDétection d'anomalie par string
\nLa comparaison entre strings de même orientation, inclinaison et nombre de modules permet de détecter les anomalies :
\nDétection de dérive progressive
\nUne analyse de tendance sur 30 ou 90 jours normalisant par l'irradiance permet de détecter une dégradation progressive de 1 à 2 % en dessous du taux annuel normal, indicateur de vieillissement accéléré (point chaud, microfissures).
\nLa grande majorité des parcs solaires au sol sont situés en zones rurales ou en plaine, loin des zones urbanisées. La connectivité filaire (fibre, ADSL) n'est souvent pas disponible ou économiquement justifiable pour les quelques données journalières d'un parc de taille modeste.
\nLa connectivité 4G LTE est la solution standard pour la grande majorité des installations :
\nAvantages :
\nArchitecture recommandée :
\nDimensionnement de la bande passante : pour un parc de 1 MWc avec 20 onduleurs et une station météo, la collecte toutes les 5 minutes représente environ 200–500 Mo par mois, très confortablement couvert par un forfait M2M de 1 Go/mois.
\nStore and forward : la gateway doit stocker les données localement en cas de perte de connectivité (maintenance réseau opérateur, incident météo) et les remonter automatiquement à la reconnexion. Un historique local de 72 heures minimum est recommandé.
\nLes installations raccordées au réseau public français sont soumises aux exigences de comptage définies par ENEDIS dans ses Prescriptions Techniques de Raccordement (PTR).
\nCompteur de production :
\nCourbe de charge :\nLes producteurs en obligation d'achat avec puissance > 36 kVA doivent fournir des courbes de charge à pas 10 minutes à ENEDIS. Cette obligation implique un système de comptage local avec stockage et transmission automatique.
\nInterface ENEDIS pour l'auto-consommation :\nPour les installations en auto-consommation avec vente du surplus, le compteur ENEDIS mesure simultanément l'injection et le soutirage. La supervision IoT peut récupérer ces données via l'API Enedis (Flux accès aux données de comptage) pour les intégrer dans le tableau de bord.
\nContrat d'achat :\nLes données de production sont généralement auto-déclarées ou relevées par le gestionnaire selon le type de contrat. Une supervision avec historique horodaté constitue une pièce justificative en cas de litige sur les volumes de production.
\nL'investissement dans un système de supervision se justifie à partir d'une puissance installée d'environ 10 kWc, selon la valeur de l'énergie et le type de contrat de vente.
\nCoûts typiques d'un système de supervision (2026) :
\nGains quantifiables :
\nCalcul simplifié pour un parc de 200 kWc :
\nPour un parc de 1 MWc, le calcul devient clairement positif : gain monitoring 2,5 % × 1 100 MWh = 27,5 MWh, soit 2 750 à 5 500 € selon le prix de l'énergie, pour un coût de supervision de 2 400 à 9 600 €/an. Le ROI est atteint en 1 à 2 ans sur la plupart des projets.
\nL'architecture type d'une supervision solaire couvre la chaîne complète, de la string au tableau de bord :
\nOnduleurs et trackers (Modbus SunSpec, RS-485) + compteur de production + station météo → gateway 4G industrielle Eziwan → carte SIM M2M multi-opérateur → tunnel VPN sortant → cloud Eziwan → performance ratio, alertes de sous-production et accès distant aux onduleurs.
\nSur un parc au sol isolé, la gateway s'alimente sur le réseau auxiliaire du poste de livraison et fonctionne en autonomie complète : aucune infrastructure télécom à tirer, aucune intervention réseau chez l'exploitant. L'accès distant permet aux équipes O&M de diagnostiquer un onduleur en défaut avant de déclencher un déplacement — souvent l'écart entre une perte de production de 2 heures et de 2 jours.
\nPeut-on superviser des onduleurs Enphase, SMA, Fronius et ABB avec une seule gateway ?\nOui, à condition que les onduleurs exposent leurs données en Modbus TCP ou SunSpec. SMA (SunSpec Modbus), ABB (Modbus TCP), Fronius (Modbus TCP SunSpec) et certains modèles Enphase via leur gateway locale sont compatibles. Eziwan propose des profils pré-configurés pour les marques courantes, ce qui réduit le temps de configuration initial à quelques heures.
\nLa gateway fonctionne-t-elle avec un réseau sans fibre, uniquement 4G ?\nC'est le cas de déploiement le plus courant pour les centrales au sol ou les toitures industrielles éloignées des centres : la gateway 4G LTE embarquée se connecte directement via le réseau mobile. Pour les parcs en zones rurales, le Dual SIM garantit la continuité de la remontée des données même en cas de panne d'un opérateur.
\nQuelle est la fréquence minimale de collecte pour détecter une défaillance en temps réel ?\nPour la détection rapide d'une string hors tension : toutes les 5 minutes suffisent. Pour le calcul du Performance Ratio : toutes les 15 minutes. Pour la conformité ENEDIS (courbes de production 10 min) : toutes les 10 minutes. La gateway Eziwan permet de configurer des fréquences différentes par variable selon l'importance.
\nEnvie d'en savoir plus ? Eziwan propose des solutions de supervision IoT pour parcs photovoltaïques, de la petite toiture industrielle aux grandes centrales au sol. Découvrez notre offre de supervision énergétique ou contactez-nous pour un devis adapté à votre installation.
\nLa 5G industrielle fait l'objet d'une communication abondante depuis 2020 : latence infime, débits révolutionnaires, connexion de millions de capteurs, transformation numérique de l'usine. En 2026, la réalité est plus nuancée. Oui, la 5G tient ses promesses techniques dans les conditions où elle est correctement déployée. Non, elle ne remplace pas la 4G LTE pour la majorité des cas d'usage industriels actuels. Et non, un réseau 5G privé ne se déploie pas pour 50 000 euros.
\nCe guide vous donne une vision honnête de ce que la 5G apporte réellement à l'industrie en 2026, dans quels cas elle se justifie, et comment évaluer si votre projet fait partie de ceux qui peuvent en bénéficier.
\nLes spécifications 5G NR (New Radio) définissent trois profils d'usage qui couvrent des besoins distincts :
\neMBB (Enhanced Mobile Broadband) : débits pouvant atteindre 10 Gbps en théorie, typiquement 1 à 4 Gbps en conditions réelles avec un réseau privé bien dimensionné. Utile pour la vidéo HD temps réel, les applications de réalité augmentée et les mises à jour firmware massives.
\nURLLC (Ultra-Reliable Low-Latency Communications) : latence garantie sous 1 ms pour les applications de contrôle temps réel critiques (commande de cobots, fermeture de boucle de contrôle). C'est la caractéristique la plus difficile à déployer — elle requiert architecture 5G SA (Standalone) et une infrastructure radio dense.
\nmMTC (Massive Machine Type Communications) : jusqu'à 1 million de connexions par km², pertinent pour les déploiements massifs de capteurs. Dans la pratique industrielle, les usines qui approchent ces densités sont rares.
\nIl faut distinguer deux architectures :
\nEn 2026, les déploiements 5G SA dans l'industrie française restent concentrés sur un nombre limité de sites pilotes et de grandes installations. L'écosystème équipements (terminaux 5G industriels, capteurs, automates) est encore en phase de montée en maturité.
\nLa 5G se justifie quand au moins l'un de ces trois facteurs est réuni : latence temps réel critique, densité de connexions extrême, ou débit très élevé en mobilité.
\nVéhicules à guidage automatique (AGV / AMR) : les flottes denses d'AGV nécessitent une coordination temps réel et une couverture homogène de l'ensemble du sol d'usine. La 5G offre une itinérance sans coupure (handover < 1 ms) que le Wi-Fi ne peut pas garantir en mobilité rapide. Une flotte de 50+ AGV est un cas d'usage 5G solide.
\nCobots et robotique collaborative : les boucles de contrôle fermées d'un cobot (arrêt d'urgence, détection de collision) nécessitent des latences sous 5 ms. Cette exigence est accessible en 5G SA URLLC, pas en 4G (latence typique : 10–30 ms).
\nRéalité augmentée et assistance technique distante : les casques AR (Microsoft HoloLens, Magic Leap) ou les lunettes connectées (RealWear) pour l'assistance à la maintenance ou la formation nécessitent un débit symétrique élevé (>100 Mbps) et une latence faible pour une expérience acceptable. La 5G eMBB couvre ce besoin.
\nVision industrielle temps réel : inspection qualité par caméras haute résolution avec traitement embarqué sur edge MEC. Le débit montant requis pour des flux vidéo 4K multi-caméras dépasse les capacités utiles de la 4G LTE Cat 16.
\nCommande à distance de machines dangereuses : opération télécommandée d'engins de chantier, de robots en zone ATEX ou de machines de découpe avec retour vidéo. La 5G réduit le délai perçu à un niveau qui rend l'opération intuitive.
\nMalgré l'enthousiasme autour de la 5G, la réalité des projets industriels en France en 2026 est que la 4G LTE reste la technologie de référence pour la grande majorité des déploiements.
\nLes raisons sont techniques et économiques :
\nLa télégesion classique n'a pas besoin de plus : remonter des relevés Modbus toutes les 5 secondes d'une dizaine de capteurs, c'est 1 à 5 kbps de débit moyen. La 4G LTE Cat 1 (10 Mbps descendant) est surdimensionnée pour ce besoin. La 5G est inutile.
\nLes latences 4G sont suffisantes pour 90 % des applications SCADA : la supervision d'une station de pompage, la télégestion d'un réseau de distribution électrique ou le monitoring d'une installation photovoltaïque fonctionnent parfaitement avec les latences 4G (10–50 ms). L'alarme qui remonte en 50 ms vs en 5 ms n'a pas d'impact opérationnel.
\nL'écosystème 4G industriel est mature et riche : des centaines de modèles de routeurs, passerelles et modems 4G industriels sont disponibles, avec des années de retour d'expérience terrain. L'écosystème 5G industriel en est encore à ses premières années de production de masse.
\nLe rapport coût/bénéfice ne s'inverse pas avant des besoins très spécifiques : tant que vous n'avez pas de contrainte de latence sous 10 ms, de mobilité dense ou de débit supérieur à 150 Mbps, la 4G LTE est le meilleur investissement.
\nLa bonne approche en 2026 est d'identifier précisément les quelques processus qui ont un besoin réel de 5G, et de garder la 4G pour tout le reste.
\nUn réseau 5G privé en usine est une infrastructure cellulaire déployée sur site, dédiée à une seule organisation. Il existe deux modèles principaux :
\nRéseau 5G privé dédié : spectre radio propre (bande 3.4–3.8 GHz, allocation ANFR), équipements RAN (base stations) et cœur de réseau installés sur le site. L'entreprise est opérateur de son propre réseau. C'est le modèle le plus performant et le plus cher.
\nSlice de réseau 5G opérateur : le réseau public d'un opérateur (Orange, SFR, Bouygues) est segmenté pour créer une tranche dédiée à l'entreprise, avec SLA garanti. Moins d'investissement initial, mais dépendance à la couverture opérateur et latences légèrement supérieures au réseau dédié.
\nLes équipements RAN (Radio Access Network) pour les réseaux privés 5G sont principalement fournis par :
\nEn France, les opérateurs proposent des offres de réseau privé 5G :
\nLe déploiement d'un réseau privé dédié requiert une demande d'autorisation auprès de l'ANFR pour l'utilisation de fréquences dans la bande 3.4–3.8 GHz. Des bandes spécifiques sont réservées aux réseaux privés depuis la décision de l'ARCEP en 2020.
\nLa question du coût est celle qui fait souvent basculer la décision. Voici des fourchettes réalistes pour 2026, basées sur des déploiements réels en Europe :
\nRéseau 5G privé SA (Standalone) pour une usine de 10 000 m²
\nRéseau 5G privé SA pour une grande usine (50 000 m²)
\nSlice réseau 5G opérateur
\nCes chiffres expliquent pourquoi le marché des réseaux 5G privés en Europe est encore concentré sur les grands comptes industriels (automotive, chimie, énergie) avec des sites de grande taille et des cas d'usage à fort ROI démontré.
\nPour une PMI de 5 000 m² avec des besoins de supervision standard, la 4G LTE reste le choix rationnel en 2026 dans la grande majorité des cas.
\nAvant de comparer 5G et Wi-Fi 6E, il faut reconnaître que ce sont deux technologies complémentaires, pas concurrentes dans tous les cas.
\n| Critère | 5G SA privée | Wi-Fi 6E |
|---|---|---|
| Latence | < 1 ms (URLLC) | 2–5 ms |
| Débit max réel | 2–4 Gbps | 1–2 Gbps |
| Couverture en mobilité | Excellente (handover sans coupure) | Problématique au-delà de la cellule |
| Densité de connexions | 1 M/km² | ~500 appareils/AP pratique |
| Coût d'infrastructure | Très élevé (300 K€+) | Faible (10 K€ pour une usine moyenne) |
| Interférence avec l'existant | Nulle (spectre dédié) | Risque (coexistence 6 GHz) |
| Sécurité native | SIM-based, chiffrement L1 | WPA3, dépend de la configuration |
| Terminaux disponibles | Écosystème en développement | Très large (tablettes, laptops, capteurs) |
Choisissez Wi-Fi 6E pour les applications où les équipements se déplacent lentement ou peu (tablettes d'opérateurs, terminaux de picking en entrepôt), où les terminaux Wi-Fi sont largement disponibles, et où le budget d'infrastructure est limité.
\nChoisissez la 5G pour les AGV rapides, la robotique collaborative, les applications URLLC, et les déploiements où la sécurité par SIM est une exigence.
\nCombinez les deux dans les grandes usines : 5G pour les îlots robotisés critiques, Wi-Fi 6E pour l'outillage connecté et les terminaux opérateur.
\nAvant d'engager un budget 5G, parcourez cet arbre de décision :
\nAvez-vous des AGV ou robots mobiles nécessitant une couverture homogène en mouvement ?
├── OUI → La 5G (ou Wi-Fi 6E avec roaming) est pertinente
│ ├── Vitesse > 10 km/h ou latence < 5 ms requise → 5G SA URLLC
│ └── Vitesse < 10 km/h et latence 5–15 ms suffisante → Wi-Fi 6E
└── NON
├── Avez-vous des équipements qui nécessitent > 100 Mbps en mobilité ?
│ ├── OUI → 5G eMBB ou Wi-Fi 6E si mobilité faible
│ └── NON
│ ├── Avez-vous des contraintes de latence < 10 ms critiques (cobots, arrêts d'urgence) ?
│ │ ├── OUI → 5G SA URLLC obligatoire
│ │ └── NON
│ │ ├── Avez-vous plus de 500 capteurs IoT sur un même espace de 1000 m² ?
│ │ │ ├── OUI → 5G mMTC (rare en pratique industrielle)
│ │ │ └── NON → La 4G LTE couvre votre besoin. Restez en 4G.
La grande majorité des usines se situe dans la branche \"NON\" de chaque question — et la conclusion est systématiquement \"la 4G LTE suffit\". C'est une réalité que les vendeurs de 5G omettent souvent de mentionner.
\nLes contrats de réseau 5G privé incluent généralement des SLA (Service Level Agreements) sur les métriques suivantes. Voici ce que valent réellement ces garanties :
\n| Métrique SLA | Ce qui est garanti | Ce qui ne l'est pas |
|---|---|---|
| Disponibilité réseau | 99,9% (87 min/an downtime) | Disponibilité des équipements terminaux |
| Latence | \"Optimisée pour l'URLLC\" (< 5 ms dans les zones radio dense) | Latence bout en bout applications |
| Débit | \"Jusqu'à X Gbps\" (débit crête, pas garanti) | Débit minimum garanti par terminal |
| Temps de rétablissement | 4–8 heures (incidents réseau) | Impact sur votre production |
| Pénalités | Avoirs sur facture mensuelle | Indemnisation de votre perte de production |
Ce qui manque souvent dans les contrats : la garantie de latence URLLC (< 1 ms) est conditionnelle à une architecture 5G SA complète avec infrastructure radio dense. Sur un réseau 5G NSA ou avec une infrastructure radio insuffisante, cette latence n'est pas atteignable.
\nAvant de signer, exigez : la distance inter-antennes garantie sur votre surface, le nombre minimum d'UEs supportés simultanément, les conditions de résiliation si les SLA ne sont pas atteints après 3 mois.
\nMême si votre projet 5G est à 2 ou 3 ans, les décisions d'architecture prises aujourd'hui conditionnent la facilité et le coût de la migration.
\nAdoptez une architecture edge dès maintenant : un gateway industriel local capable d'héberger des applications peut demain accueillir une fonction MEC (Multi-access Edge Computing) 5G. Déployez des équipements edge-capables plutôt que de simples modems 4G transparents.
\nStandardisez sur des protocoles ouverts : MQTT, OPC-UA et REST sont indépendants du réseau de transport. Un système conçu sur ces standards migre vers la 5G sans réécriture applicative.
\nPlanifiez votre prise en compte CBRS/ANFR : si vous envisagez un réseau 5G privé dédié, commencez les démarches de réservation de spectre tôt. Les processus ANFR prennent plusieurs mois.
\nÉvaluez vos cas d'usage réels : documentez les latences actuellement observées sur vos processus critiques, les débits utilisés, les densités de connexion. Cet inventaire est la base d'une décision 5G rationnelle plutôt que d'une décision marketing.
\nFormez vos équipes : les compétences 5G SA (core network, RAN, slicing) sont différentes des compétences Wi-Fi et 4G. Le déficit de compétences est actuellement l'un des principaux freins aux déploiements 5G privés en France.
\nLe passage à la 5G ne change pas les fondamentaux de la connectivité industrielle : il faut toujours une carte SIM M2M adaptée, un APN maîtrisé et une supervision de la consommation. Trois points d'attention spécifiques :
\nAutrement dit : pour un parc de sites de télégestion classiques, la migration 5G n'a pas d'urgence — la bonne SIM et le bon routeur 4G restent l'investissement rationnel.
\nUne approche pragmatique consiste à déployer une architecture identique quel que soit l'accès radio :
\nÉquipements de production (Modbus, OPC-UA, profinet) → gateway industrielle Eziwan (modem 4G aujourd'hui, module 5G interchangeable demain) → SIM M2M multi-opérateur → tunnel VPN sortant → cloud Eziwan → supervision et accès distant.
\nLe jour où un cas d'usage justifie la 5G (AGV, vision industrielle), seul le module radio change : la sécurité, la supervision, la gestion de flotte et les intégrations restent identiques. C'est la meilleure protection de l'investissement face à un standard qui évolue encore.
\nLa 5G privée est-elle disponible pour les PME industrielles françaises aujourd'hui ?\nDes réseaux 5G privés sont déployés en France depuis 2022-2023, principalement dans des grandes usines et ports (PSA, Airbus, Port de Marseille). Pour les PME, la 5G privée reste coûteuse (300 000 € à 1 M€+ pour l'infrastructure radio). La 5G publique (opérateurs) avec network slicing est plus accessible, mais la couverture industrielle reste limitée aux zones urbaines et péri-urbaines en 2026.
\nQuels sont les cas d'usage industriels qui justifient vraiment la 5G vs la 4G LTE ?\nLes cas qui justifient la 5G : AGV (chariots autonomes) nécessitant une latence < 5 ms, vision industrielle temps réel (caméras 4K pour contrôle qualité), réalité augmentée pour les techniciens de maintenance (haute bande passante + faible latence), et densités de connexion extrêmes (1000+ capteurs par m²). Pour la supervision SCADA, la maintenance prédictive et l'accès distant — la 4G LTE suffit largement.
\nLe réseau 5G public des opérateurs peut-il remplacer un réseau 5G privé en usine ?\nPour la plupart des usines : oui, avec le network slicing 5G qui permet de réserver une tranche de réseau dédiée. Les SLAs de latence garantis sont moins stricts qu'un réseau privé, mais suffisants pour 95% des applications industrielles. Un réseau 5G privé est justifié uniquement si vous avez des exigences de latence ultra-strictes (< 1 ms) ou de confidentialité absolue des données.
\nBesoin d'une analyse pour votre projet ? L'équipe Eziwan accompagne les industriels dans l'évaluation de leurs besoins de connectivité et le choix entre 4G LTE, 5G privée et Wi-Fi. Contactez-nous pour une étude de cas adaptée à vos contraintes de site.
\n