Edge computing vs cloud pour l'industrie : comment choisir en 2026 ?

· 14 minutes de lecture
14 min read
Équipe Eziwan
Équipe Eziwan
Infrastructure IoT

"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.

En 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.

Définitions : edge, cloud, fog — sans jargon​

Avant de comparer, clarifions ce que ces termes signifient concrètement dans un contexte industriel.

Le 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.

L'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.

Le 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.

La hiérarchie dans une usine :

  • Niveau 0 : capteurs, actionneurs (pas de traitement)
  • Niveau 1 : automates PLC, RTU (traitement temps réel, cycle <10 ms)
  • Niveau 2 : SCADA local, IHM (supervision et contrôle site)
  • Niveau 3 : Edge gateway (collecte, normalisation, pre-processing, alertes locales)
  • Niveau 4 : Cloud (historisation long terme, analytique, supervision multi-sites)

Le 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.

Quand l'edge computing est obligatoire​

Il existe trois situations dans lesquelles le traitement en cloud seul est techniquement insuffisant ou inadmissible.

Contrainte de latence temps réel

La 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.

Les applications qui nécessitent du traitement local pour fonctionner :

  • Coupure d'urgence sur dépassement de seuil (arrêt machine si température > 85 °C)
  • Régulation de débit ou de pression (boucle PID fermée via gateway edge)
  • Détection de vibration anormale avec déclenchement d'alarme local
  • Contrôle qualité par vision avec rejet de pièce défectueuse sur la ligne

Contrainte de bande passante

Un 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.

L'edge résout ce problème par deux mécanismes :

  • Downsampling : réduire la fréquence d'échantillonnage de 10 kHz à 1 Hz pour la supervision courante, et ne transmettre les données haute fréquence que sur événement (dépassement de seuil)
  • Feature extraction : calculer localement des indicateurs pertinents (RMS vibratoire, fréquences caractéristiques FFT) et ne transmettre que ces indicateurs, au lieu des données brutes

En pratique, l'edge peut réduire le volume de données transmises au cloud de 70 à 95 % selon les applications.

Contrainte de souveraineté des données

Certaines données industrielles ne peuvent pas sortir de l'entreprise ou du territoire national :

  • Données de production liées à des marchés confidentiels (défense, aéronautique, nucléaire)
  • Formules de produits, paramètres de procédé constituant des secrets industriels
  • Données couvertes par des accords de confidentialité clients
  • Données dont la localisation est réglementairement encadrée (données de santé avec SNDS, données financières)

Dans 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.

Quand le cloud seul suffit​

Pour la majorité des applications de supervision industrielle, le cloud seul est parfaitement adapté et simplifie considérablement l'architecture.

Supervision et monitoring non critiques

La 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.

Analytics et machine learning sur données historiques

Les 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.

Supervision multi-sites centralisée

Un 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.

Gestion des mises à jour et configuration

La 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.

L'architecture hybride edge + cloud : le meilleur des deux mondes​

L'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.

Rôles de l'edge (gateway industriel local) :

  • Collecte locale des données terrain via Modbus RTU/TCP, OPC-UA, Profibus, SNMP
  • Normalisation et mise en forme des données (conversion d'unités, horodatage local, identifiants d'équipements)
  • Évaluation locale des règles d'alarme et déclenchement d'alertes sans dépendance réseau
  • Store & forward : stockage temporaire si la connectivité est interrompue, retransmission automatique à la reconnexion
  • Pre-processing : downsampling, feature extraction, filtrage des valeurs aberrantes
  • Tunnel VPN vers le cloud : chiffrement TLS, authentification mutuelle

Rôles du cloud :

  • Réception et historisation des données normalisées
  • Tableaux de bord temps réel et historiques
  • Moteur d'alertes avancé (corrélation multi-sites, alertes basées sur des tendances)
  • Analytique et machine learning
  • Gestion des utilisateurs, droits d'accès, audits de sécurité
  • API pour l'intégration avec les ERP, CMMS, systèmes BI
  • Supervision de la flotte des gateways (santé réseau, connectivité, versions firmware)

Le protocole de synchronisation : La 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.

Supervision de la gateway elle-même : L'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.

Edge computing dans la pratique : exemples par secteur​

Industrie agroalimentaire — monitoring chambre froide

Une 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.

Distribution d'eau — régulation de pression

Une 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.

Énergie — parc solaire

Un 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.

Construction et BTP — suivi d'engin

Un 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.

Edge computing avec Eziwan : ce que le gateway fait en local​

Le gateway Eziwan est conçu comme un nœud d'edge computing industriel, pas comme un simple routeur transparent.

Collecte et normalisation locale : Le 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).

Règles d'alarme locale : Les 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.

Store and forward : Les 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.

Tunnel VPN permanent : La 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.

Protocoles supportés en local :

  • Modbus RTU (RS-232, RS-485)
  • Modbus TCP
  • MQTT broker local
  • SNMP
  • M-Bus (sous-compteurs énergie, eau, gaz)
  • API REST locale pour les intégrations personnalisées

Comment planifier votre architecture edge/cloud​

Une architecture edge/cloud réussie se définit avant de choisir les équipements. Voici le processus recommandé.

Étape 1 : Cartographier les sources de données Listez 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.

Étape 2 : Classifier les contraintes par cas d'usage Pour 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 ?).

Étape 3 : Appliquer la règle de décision

ContrainteTraitement edgeTraitement cloud
Latence < 500 msObligatoireImpossible
Disponibilité sans réseauObligatoireImpossible
Volume > 1 Mo/min par sourceRecommandéCoûteux
Données sensibles (souveraineté)ObligatoireAvec conditions
Analytique ML sur historiqueOptionnelRecommandé
Supervision multi-sitesOptionnelRecommandé
Interface utilisateurOptionnelRecommandé

Étape 4 : Dimensionner l'edge Calculez 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é).

Étape 5 : Valider la connectivité Estimez 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.

Cette 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.

FAQ​

Qu'est-ce que l'edge computing industriel concrètement — est-ce compliqué à déployer ? En 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.

Quand le edge computing ne suffit-il pas et faut-il absolument le cloud ? Quand 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.

La latence 4G LTE (30-100 ms) empêche-t-elle le cloud pour les alertes critiques ? Pour 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.

L'edge computing sur gateway IoT permet-il d'écrire sur l'automate (commandes) ? Oui. 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.

Quelle est la différence entre store-and-forward et l'edge computing ? Le 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.

Pour aller plus loin​

Envie 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.

Ressources complémentaires​