Une étude analytique des forces physiques, économiques et architecturales qui déplacent le calcul du centre de données vers la passerelle industrielle, et un argument expliquant pourquoi la passerelle représente le point d'équilibre actuel de la vague de l'informatique de pointe.
Préambule
L’histoire de l’informatique a été, en une lecture, une séquence d’oscillations entre centralisation et distribution. Le mainframe a cédé la place au mini-ordinateur, qui a cédé la place à l’ordinateur personnel, qui a cédé la place au client-serveur, qui a cédé la place au web, qui a cédé la place au cloud. Chaque cycle a été raconté par ses participants comme la synthèse finale. Aucun ne l’a été.
L'oscillation actuelle – étiquetée différemment edge computing, fog computing, cloudlet computing et multi-access edge computing – représente un autre changement de phase. Le calcul migre des centres de données hyperscaler vers les points où les données sont générées. Le récit populaire traite cela comme un phénomène unifié. Ce n'est pas. Edge est devenu un terme générique qui cache au moins quatre modèles architecturaux distincts, chacun motivé par des forces différentes et contraint par des réalités différentes.
Cet article fait trois choses. Premièrement, il lève l'ambiguïté du terme edge computing en proposant une taxonomie à plusieurs niveaux. Deuxièmement, il étudie les forces physiques, économiques et réglementaires qui poussent le calcul vers la périphérie du réseau. Troisièmement, et c'est le point le plus central, il soutient que la couche passerelle — le niveau informatique industriel sur site entre l'appareil et le cloud — représente le point d'équilibre actuel de cette migration. La passerelle n’est pas la destination finale de la vague périphérique, mais c’est là que convergent les forces actuelles : la capacité matérielle, la topologie de sécurité, les limites administratives et les incitations économiques s’alignent ici d’une manière qui ne s’aligne pas à la périphérie des appareils ou du réseau.
Cet argument se veut utile à la fois aux architectes système qui conçoivent des déploiements industriels d’IoT et aux chercheurs qui étudient l’économie politique de l’informatique distribuée.
Une taxonomie de « Edge »
La confusion est la principale source de confusion dans le discours sur l'informatique de pointe. Lorsqu'un hyperscaler commercialise edge, cela signifie généralement un point de présence régional à environ 50-100 km des utilisateurs finaux. Lorsqu'un opérateur de télécommunications commercialise edge, cela signifie généralement un calcul colocalisé avec l'infrastructure du réseau d'accès radio. Lorsqu'un fournisseur d'automatisation industrielle commercialise edge, cela signifie généralement une passerelle ou un automate dans l'usine. Lorsqu'un fournisseur de microcontrôleurs commercialise edge, cela signifie généralement que l'inférence s'exécute directement sur le dispositif de détection. Ce n’est pas la même chose, et les recommandations architecturales tirées d’un contexte échouent régulièrement lorsqu’elles sont transférées à un autre.
Un traitement plus rigoureux distingue au moins quatre niveaux :
Bord de l'appareil. Calcul co-résident avec le capteur ou l'actionneur. Le matériel va des microcontrôleurs ARM Cortex-M 32 bits (fonctionnant sous 1 W) aux petits processeurs d'application ARM Cortex-A. La mémoire est généralement mesurée en kilo-octets jusqu'en mégaoctets faibles. Les piles logicielles sont nues, basées sur RTOS (FreeRTOS, Zephyr) ou Linux simplifié. Les charges de travail adaptées à ce niveau sont dominées par le conditionnement du signal, le seuillage simple, l'inférence légère (TinyML) et la traduction de protocole.
Passerelle / périphérie sur site. Calcul à un point d'agrégation colocalisé avec l'équipement qu'il dessert, mais non intégré dans des appareils individuels. Le matériel est généralement de classe passerelle : ARM Cortex-A53/A72/A76 ou modeste x86, avec 512 Mo à 16 Go de RAM, fonctionnant dans l'enveloppe 5-25 W. La caractéristique déterminante est une capacité suffisante pour exécuter une distribution Linux complète avec des conteneurs, plusieurs charges de travail simultanées et une inférence ML modeste, tout en restant suffisamment bon marché pour être déployée en quantité. C’est à ce niveau que porte principalement le présent article.
Network Edge / Multi-Access Edge Computing (MEC). Calcul opéré par un fournisseur de réseau, généralement un opérateur de télécommunications, hébergé sur ou à proximité d'une infrastructure de réseau d'accès radio ou de sites d'agrégation. Normalisé selon ETSI GS MEC 003 [1] et spécifications associées. Le matériel est de classe serveur. La latence aller-retour vers les appareils finaux est de l'ordre de 1 à 10 ms dans les scénarios URLLC 5G. La propriété administrative appartient au transporteur et non au propriétaire de l'application – un fait dont l'importance est souvent sous-estimée.
Bordure régionale. Calcul opéré par des hyperscalers ou des réseaux de diffusion de contenu dans des installations de zone métropolitaine. Les exemples incluent les zones locales AWS, les zones Azure Edge, Google Distributed Cloud Edge, Cloudflare Workers et la couche de calcul CDN plus large (Fastly Compute@Edge, Akamai EdgeWorkers). La latence aller-retour vers les appareils finaux est généralement de 10 à 40 ms au sein d'une région. Le matériel est de classe datacenter.
Ces niveaux diffèrent selon au moins sept dimensions indépendantes : latence aller-retour, enveloppe énergétique, capacité de calcul, propriété administrative, périmètre de sécurité, densité de déploiement et coût économique par unité de calcul. Le placement optimal d'une charge de travail est déterminé par les dimensions auxquelles elle est la plus sensible, et la confusion des niveaux obscurcit ces compromis.
Le reste de cet article concerne le deuxième niveau – la passerelle – et les raisons pour lesquelles il est devenu le lieu dominant du déploiement actuel de périphérie dans les contextes industriels.
Facteurs théoriques de la migration Edge
Pourquoi le calcul s’oriente-t-il vers l’extérieur ? Cinq forces, d’âge et de précision analytique variables, expliquent cette migration.
2.1 Le plancher de latence
Le facteur le plus cité est aussi le plus physiquement incontournable : la vitesse de la lumière. Dans la fibre, les signaux électromagnétiques se propagent à environ 200 000 km/s, soit environ les deux tiers de la vitesse de la lumière dans le vide. Un aller-retour entre Francfort et la Virginie du Nord, les centres géographiques de la capacité cloud européenne et nord-américaine, parcourt environ 6 200 km de chemin de fibre, ce qui donne un temps aller-retour minimum théorique de 62 ms avant toute commutation, mise en file d'attente ou surcharge de protocole. Les RTT observés dans la pratique sont de 80 à 100 ms.
Ce plancher n'est pas fonction de la bande passante, de la conception du protocole ou du budget. C'est une fonction de la physique. Pour les boucles de contrôle qui doivent se fermer dans un délai de 10 ms (une exigence courante dans le contrôle de mouvement, la robotique et certaines applications de contrôle de processus), l'intégralité du chemin de rétroaction doit résider dans environ 1 000 km de fibre. En pratique, cela signifie sur site ou, dans les scénarios les plus agressifs, en périphérie de la zone métropolitaine.
Un point plus subtil : la latence qui compte n'est pas la médiane (p50) mais la queue (p99 ou p99.9). Les chemins Internet présentent des écarts de latence importants en fonction des files d'attente, des événements de convergence BGP et des microrafales. Un chemin avec un RTT médian de 80 ms peut présenter une latence de queue de 200 à 500 ms. Les systèmes de contrôle doivent être conçus en fonction de la queue, et non de la médiane, ce qui réduit encore davantage le budget de latence effectif disponible pour les boucles de contrôle via le cloud.
2.2 Gravité des données et économie de la bande passante
L'ouvrage « Distributed Computing Economics » [2] de Jim Gray expliquait, en 2003, ce qui a depuis été redécouvert à plusieurs reprises : il est généralement moins coûteux d'envoyer des calculs vers des données que des données vers des calculs, une fois que les volumes de données dépassent un seuil modeste. Le principe a été repopularisé sous le nom de gravité des données [3].
La détection industrielle rend l’arithmétique concrète. Un capteur de vibrations sur un actif rotatif, échantillonnant à 25,6 kHz sur trois axes avec une résolution de 24 bits, produit environ 220 Ko de données brutes par seconde et par actif, soit 19 Go par jour. Une usine de taille moyenne dotée de 500 capteurs de ce type génère à elle seule 9,5 To par jour de données brutes sur les vibrations. Le streaming vers un hyperscaler aux tarifs de sortie standards est économiquement irréalisable. Même si cela était abordable, la liaison montante cellulaire ou fibre serait saturée.
L’argument économique est simple : la plupart des données industrielles brutes n’ont aucune valeur analytique sous leur forme brute. Les caractéristiques spectrales, les statistiques d'enveloppe et les scores d'anomalies véhiculent le signal de diagnostic. Le calcul qui extrait ces fonctionnalités au niveau de la passerelle réduit le volume des liaisons montantes de deux à trois ordres de grandeur tout en préservant – et souvent en améliorant – la fidélité analytique.
2.3 Tolérance de partition en tant qu'exigence opérationnelle
Le théorème CAP [4][5] formalise une contrainte à laquelle les systèmes industriels ont toujours été confrontés : en présence de partitions réseau, les systèmes distribués doivent choisir entre cohérence et disponibilité. Le choix n’est pas facultatif ; elle est forcée par la réalité physique de la panne du réseau.
Pour les applications critiques en matière de sécurité et de nombreuses applications critiques pour les processus, la disponibilité n'est pas négociable. La logique de contrôle doit continuer à fonctionner lorsque la liaison étendue vers le cloud est inaccessible. Le cloud est peut-être le système d’enregistrement, l’orchestrateur des politiques à long terme et le lieu de l’analyse, mais il ne peut pas être le lieu d’un contrôle instantané à moins que le réseau entre le cloud et les actifs ne soit traité comme une structure en temps réel – ce qui n’est pas le cas sur les liaisons cellulaires ou Internet commerciales.
L'implication architecturale est que le plan de contrôle peut vivre dans le cloud, mais le plan de données — la boucle qui ferme l'action de contrôle — doit résider localement. La passerelle est l'emplacement naturel du plan de données : suffisamment proche de l'actif pour être tolérante aux partitions, suffisamment capable d'héberger une logique substantielle.
2.4 Fragmentation réglementaire et souveraineté des données
L’environnement juridique du transfert transfrontalier de données est devenu considérablement plus restreint au cours de la dernière décennie. Le règlement général sur la protection des données [6], la directive NIS2 [7], la loi chinoise sur la cybersécurité et sa loi sur la protection des informations personnelles, la loi indienne sur la protection des données personnelles numériques, les règles spécifiques au secteur (automobile en Allemagne, données médicales dans la plupart des juridictions, données financières presque partout) et la décision Schrems II [8] ont collectivement fait de toutes les données circulent automatiquement vers le cloud un défaut architectural et juridiquement précaire.
Le traitement Edge prend en charge la souveraineté des données en permettant la minimisation des données à la source. Les données personnelles identifiables ou commercialement sensibles peuvent être traitées, transformées et agrégées sur le territoire ; seuls les résultats dérivés, anonymisés ou agrégés traversent les frontières juridictionnelles. Il ne s’agit pas d’un avantage marginal en matière de conformité : pour certaines charges de travail dans certaines juridictions, il s’agit de la seule architecture légalement autorisée.
2.5 La confidentialité en tant que primitive architecturale
Au-delà de la conformité réglementaire, un nombre croissant de techniques traitent la confidentialité comme une préoccupation architecturale de premier ordre. La confidentialité différentielle [9] ajoute un bruit calibré aux statistiques publiées pour limiter les fuites d'informations. L'apprentissage fédéré [10] entraîne des modèles sur des appareils distribués sans centraliser les données brutes. L'agrégation sécurisée [11] permet de calculer des sommes sur une population sans qu'aucune partie - y compris l'agrégateur - n'observe les contributions individuelles. L’informatique confidentielle [12] enclave le calcul lui-même.
Chacune de ces techniques déplace le travail vers l'emplacement des données. La passerelle, en tant que point d'agrégation d'une population d'appareils, est le lieu naturel pour les opérations d'ajout de bruit, de mise à jour fédérée ou d'agrégation sécurisée requises par ces techniques. La structure mathématique des techniques implique la localisation architecturale.
Pourquoi la passerelle, en particulier ?
Les forces de la section 2 poussent le calcul vers l’extérieur. Ils ne déterminent pas, par eux-mêmes, où sur le chemin il atterrit. La passerelle est devenue le lieu dominant dans les milieux industriels, et les raisons méritent d’être examinées attentivement.
Gateway equilibrium across edge placement criteria
bar chart3.1 Le seuil de viabilité informatique
La périphérie de l’appareil est fortement limitée en ressources. Un microcontrôleur de capteur industriel typique fonctionne sous 100 mW, avec des kilo-octets de RAM. Il peut exécuter un classificateur de réseau neuronal quantifié – TinyML – mais ne peut pas héberger un système d'exploitation à usage général, un environnement d'exécution de conteneur ou une pile d'applications non triviale. Son logiciel est livré sous forme de firmware monolithique, rarement mis à jour et difficile à faire évoluer.
La frontière régionale, en revanche, est compétente mais lointaine. Le RTT de 10 à 40 ms est acceptable pour de nombreuses applications mais exclut les boucles de contrôle les plus étroites. Plus important encore, la frontière régionale est administrativement hétérogène : les charges de travail sont soumises aux politiques opérationnelles de l'opérateur ou de l'hyperscaler qui les héberge, ce qui n'est pas toujours compatible avec le modèle de sécurité de l'opérateur industriel.
La passerelle occupe une position sans équivalent de part et d’autre. Une passerelle industrielle moderne dotée d'un quadricœur ARM Cortex-A53, d'une unité de traitement neuronal délivrant 2 à 6 TOPS [13] [14] et de 2 à 8 Go de RAM est capable de :
Il s'agit de la plus petite plate-forme informatique sur laquelle fonctionne une chaîne d'outils de systèmes distribués à usage général, et de la plus grande plate-forme informatique compatible avec les enveloppes énergétiques et de coûts acceptables dans un déploiement industriel.
- Exécuter une distribution Linux complète
- Hébergement d'un runtime de conteneur (containerd, Podman) ou d'un orchestrateur (K3s, KubeEdge)
- Exécution d'une inférence ML modeste (classification d'images, détection d'anomalies, modèles de maintenance prédictive)
- Maintenir l'état persistant des applications dans les bases de données intégrées
- Relier les protocoles industriels (Modbus, OPC UA, EtherNet/IP) aux protocoles cloud natifs (MQTT, HTTPS, gRPC)
3.2 Alignement des limites administratives et de sécurité
Dans tout réseau industriel non trivial, la passerelle constitue déjà la frontière entre la technologie opérationnelle (OT) et la technologie de l'information (IT). C'est là que se terminent les pare-feu, là où émergent les tunnels VPN, où s'effectue la traduction du protocole et où le contrôle d'accès est appliqué. Le modèle de zones et de conduits CEI 62443 [15] formalise cela : la passerelle se trouve au niveau d'un conduit entre une zone OT et une zone externe.
Localiser le calcul à cette limite aligne le périmètre de sécurité avec le périmètre de la charge de travail. Les charges de travail exécutées sur la passerelle peuvent accéder aux données OT sans franchir de limites de confiance supplémentaires, tandis que leurs sorties traversent le conduit informatique existant. L’alternative – exécuter des charges de travail dans le cloud et extraire les données brutes OT vers l’extérieur – crée une nouvelle surface d’attaque pour chaque charge de travail, multipliant ainsi les conduits à défendre.
Cet alignement est plus que pratique. Dans les modèles de menaces tirés d’incidents industriels réels – Triton, Industroyer, les différents événements de ransomware qui ont franchi la frontière IT/OT – la passerelle est précisément le lieu qui doit être renforcé. Mettre le calcul à cet endroit n’introduit pas de nouveau risque ; cela consolide le risque qui existait déjà.
3.3 Densité d'agrégation et charges de travail statistiques
La plupart des charges de travail analytiques les plus rentables dans les environnements industriels sont statistiques ou à l'échelle de la population : détection d'anomalies sur une flotte d'actifs similaires, modèles de maintenance prédictive formés sur le comportement d'une cohorte, optimisation énergétique sur une charge globale. Ces charges de travail nécessitent intrinsèquement une agrégation sur plusieurs appareils.
Par définition, la périphérie de l’appareil ne peut pas effectuer d’agrégation : elle se fait par appareil. Le cloud le peut, mais au prix de la diffusion de données brutes et de la tolérance au risque de partition. La passerelle est le plus petit niveau auquel l'agrégation N-à-1 se produit naturellement : elle dessert une population d'appareils, par construction. Les ressources de calcul n'ont pas besoin d'être répliquées par appareil ; ils peuvent être amortis.
Cela a des implications en particulier pour les charges de travail de ML. L'apprentissage fédéré fonctionne au niveau de la passerelle même s'il ne fonctionne pas au niveau des appareils : les passerelles disposent de la mémoire et du calcul nécessaires pour participer, de la connectivité pour se coordonner et de la portée d'agrégation pour produire des mises à jour locales statistiquement significatives.
3.4 Mobilité des charges de travail via l'orchestration
Jusqu'à récemment, le matériel de classe passerelle était géré comme des appareils à fonction fixe : une image de micrologiciel, rarement mise à jour, avec une flexibilité opérationnelle limitée. Le développement au cours des cinq dernières années qui a le plus modifié l’économie de l’edge computing est la maturation de l’orchestration légère : K3s [16], KubeEdge [17], OpenYurt, Akri et l’écosystème Edge CNCF plus large.
Ces outils apportent l'orchestration des conteneurs (spécification déclarative de la charge de travail, mises à jour progressives, observabilité, maillage de services) au matériel de classe passerelle. Une passerelle devient un nœud dans une flotte, gérée avec la même chaîne d'outils que le cloud. Les charges de travail sont spécifiées de manière déclarative (manifestes Kubernetes, graphiques Helm) et convergent vers l'état souhaité via les contrôleurs GitOps (Argo CD, Flux, Fleet).
La conséquence est que les passerelles ne sont plus des appareils statiques ; ce sont des plates-formes informatiques programmables avec une portabilité substantielle de la charge de travail entre le cloud et la périphérie. La même image de conteneur qui s'exécute dans le cloud pour le développement peut s'exécuter sur une passerelle en production avec un minimum de modifications. Cela élimine la pénalité historique du déploiement en périphérie (pipelines de construction sur mesure, procédures de mise à jour manuelles, gestion de flotte fragile) et constitue le catalyseur pratique qui a rendu l'informatique de pointe de niveau passerelle économiquement viable à grande échelle.
Modèles architecturaux
Une taxonomie et un ensemble de pilotes sont insuffisants ; les architectures qui ont émergé au niveau de la passerelle méritent d’être examinées à elles seules.
4.1 Traitement des flux à la périphérie
De nombreuses charges de travail industrielles s'expriment le plus naturellement sous forme de calculs en continu : les données de capteurs entrantes sont transformées, fenêtrées, agrégées et émises sous forme de flux dérivés. Les modèles architecturaux qui ont émergé dans le traitement de flux à l'échelle du cloud – variantes de l'architecture lambda [18] et de l'architecture kappa plus simple [19] – ont des analogues de niveau Edge.
Apache NiFi est devenu un outil de flux de travail courant au niveau de la passerelle (son sous-projet MiNiFi cible exactement ce créneau). Kafka avec des déploiements à nœud unique, ou des alternatives plus légères comme Redpanda, s'exécutent sur des passerelles performantes. Pour un traitement de flux plus sophistiqué, Apache Flink et l'émergence récente d'Arroyo et de projets similaires étendent le modèle.
La question analytique fondamentale au niveau de la passerelle est la même qu'à l'échelle du cloud : sémantique unique en cas de panne, filigrane pour les données dans le désordre, gestion de l'état lors des redémarrages, mais l'enveloppe des ressources est différente. Les processeurs de flux de passerelle doivent fonctionner avec des centaines de mégaoctets de RAM, et non des dizaines de gigaoctets, ce qui a donné naissance à une génération d'outils de traitement de flux conçus spécifiquement pour cette contrainte.
4.2 Inférence ML à la périphérie
Les arguments en faveur de l’inférence ML au niveau de la passerelle ne concernent pas principalement la formation ; il s'agit d'une question d'exécution. La formation d'un modèle est une charge de travail unique (ou périodique) à l'échelle du cloud. L’exécution du modèle entraîné (inférence) est une charge de travail continue et sensible à la latence qui bénéficie considérablement du placement en périphérie.
Les bases techniques sont bien établies. La formation prenant en compte la quantification [20] réduit les poids du modèle de 32 bits à virgule flottante à un entier de 8 bits avec une perte de précision minimale, réduisant l'empreinte mémoire de 4 × et accélérant l'inférence proportionnellement. La distillation des connaissances [21] forme des modèles « étudiants » compacts à partir de modèles « enseignants » plus grands. L'élagage structuré supprime les paramètres redondants. La recherche d'architecture neuronale [22] découvre des architectures compactes spécialement conçues pour le déploiement en périphérie.
Les outils d'exécution ont évolué en conséquence : TensorFlow Lite, ONNX Runtime, ExecuTorch, NVIDIA TensorRT pour les passerelles plus performantes avec GPU discrets. L'accélération matérielle a convergé vers des unités de traitement neuronal dédiées : le NPU du RK3588 de Rockchip offre 6 TOPS [13], l'accélérateur complémentaire Hailo-8 offre 26 TOPS [14], l'i.MX 8M Plus de NXP intègre un NPU 2,3 TOPS, et des unités similaires apparaissent dans presque tous les SoC industriels modernes.
Le résultat est que des charges de travail qui auraient été considérées comme uniquement cloud en 2018 (détection d'objets en temps réel, détection d'anomalies sur des séries temporelles multivariées, reconnaissance vocale conditionnelle) sont désormais régulièrement déployées au niveau de la passerelle.
4.3 Apprentissage fédéré et agrégation préservant la confidentialité
L'algorithme de moyenne fédérée d'origine [10] a été conçu pour les appareils mobiles, mais ses hypothèses (participation partielle, hétérogénéité statistique, mises à jour limitées par la communication) s'appliquent directement aux déploiements au niveau de la passerelle. Chaque passerelle forme une mise à jour locale sur sa population d'appareils observée localement ; les mises à jour périodiques sont regroupées sur les passerelles, généralement via un coordinateur dans le cloud, pour produire un modèle global qui bénéficie d'informations inter-populations sans centraliser les données brutes.
Le déploiement pratique doit faire face à plusieurs défis non triviaux. L'hétérogénéité statistique (la nature non-IID des données entre les passerelles) dégrade la convergence ; FedProx [23] et SCAFFOLD résolvent ce problème avec diverses formes de réduction de la variance. L'efficacité de la communication est améliorée par la compression de gradient et la quantification. Les attaques de confidentialité via l'inversion de gradient [24] motivent la confidentialité différentielle et l'agrégation sécurisée [11].
L’état actuel de la technique indique que l’apprentissage fédéré est opérationnellement viable pour de nombreuses charges de travail industrielles de ML, mais il reste nettement plus complexe à déployer et à exploiter que la formation centralisée. Le bénéfice doit justifier le coût opérationnel, ce qui est le plus souvent le cas lorsque les données centralisées seraient elles-mêmes sensibles sur le plan réglementaire ou commercial.
4.4 GitOps et gestion déclarative des périphéries
Le principe est simple : l'état souhaité de la flotte est décrit dans un référentiel à version contrôlée, et les passerelles convergent vers cet état via des contrôleurs pull. Le contrôleur (Argo CD, Flux) observe l'écart entre l'état observé et l'état souhaité et applique les changements nécessaires pour le combler.
Pour une flotte de milliers de passerelles, ce modèle présente des avantages opérationnels substantiels par rapport à la gestion impérative basée sur le push. Les mises à jour sont atomiques et peuvent être annulées. Le système tolère les passerelles temporairement hors ligne ; ils rattrapent leur retard lorsqu'ils sont reconnectés. L'historique opérationnel complet de la flotte est capturé dans l'historique Git, offrant une auditabilité qui satisfait à la plupart des régimes de conformité.
Le modèle a été emprunté presque sans modification aux opérations cloud natives. Sa traduction réussie vers le niveau Edge est l’une des avancées opérationnelles majeures de ces dernières années.
4.5 Gestion de l'état Edge-Native
L’état de l’application au niveau de la passerelle doit être durable lors des redémarrages, cohérent en cas d’accès simultané et synchronisable avec les systèmes centraux lorsque la connectivité le permet. Le cheval de bataille reste SQLite, qui est mature, intégré et bien compris. Pour les données de séries chronologiques, DuckDB s'est imposé comme une option analytique solide, tandis que VictoriaMetrics et InfluxDB à nœud unique servent les charges de travail de métriques opérationnelles.
Pour les scénarios multi-maîtres – dans lesquels plusieurs passerelles ou une passerelle et le cloud écrivent tous deux les mêmes données logiques – les types de données répliquées sans conflit (CRDT) [25] fournissent une base de principe pour une cohérence éventuelle sans coordination centralisée. La littérature sur les CRDT est mature ; la production à des fins industrielles de pointe est encore émergente mais s'accélère (Automerge, Yjs et des bibliothèques similaires sont de plus en plus utilisées).
Problèmes ouverts
Le niveau passerelle n’est pas un système résolu. Plusieurs problèmes ouverts méritent notre attention.
Observabilité de la flotte à grande échelle. Un millier de passerelles émettant chacune de la télémétrie produisent leur propre lance à incendie de télémétrie. La sélection des métriques à émettre, à quelle granularité, avec quel échantillonnage et comment les agréger de manière centralisée sans perdre la fidélité du diagnostic est un problème de conception non résolu. OpenTelemetry a amélioré la situation au niveau du cloud, mais les conseils spécifiques à la périphérie restent minces.
Informatique confidentielle à la périphérie. Les environnements d'exécution fiables (Intel SGX, ARM TrustZone, AMD SEV) offrent une exécution isolée du matériel, adaptée aux charges de travail traitant des données sensibles. Leur adoption dans le matériel de classe passerelle est inégale : TrustZone est largement disponible mais ses capacités sont limitées, tandis que les enclaves plus riches sont largement absentes des processeurs d'application ARM qui dominent le marché des passerelles. Pour les charges de travail qui nécessitent une protection au niveau de l’enclave au niveau de la passerelle, les options restent limitées.
Gestion du cycle de vie des modèles. Le déploiement d'un nouveau modèle d'inférence sur une flotte de milliers de passerelles sans interrompre les charges de travail qui en dépendent nécessite des tests A/B, des déploiements Canary et une discipline de restauration. Les outils existent au niveau cloud ; son adaptation au niveau Edge est incomplète.
Évolution du schéma. Lorsque le modèle de données évolue (un nouveau champ, une métrique renommée, une unité différente), les passerelles et le cloud doivent rester cohérents. Les registres de schémas, les tests de contrats et la gestion de versions explicite sont bien compris dans les architectures cloud natives. Leur application cohérente au-delà des limites de la passerelle est un domaine de pratique d’ingénierie continue plutôt qu’un problème résolu.
Calcul proportionnel à l'énergie. Les passerelles fonctionnent généralement 24h/24 et 7j/7. La consommation d’énergie au repos est importante, tant pour les enveloppes thermiques que pour les coûts d’exploitation. La mise à l'échelle dynamique de tension et de fréquence utilisée par les processeurs de bureau et de serveur est moins efficace sur les SoC intégrés qui dominent le marché des passerelles. L’efficacité énergétique au niveau de la passerelle est un domaine sous-exploré de la recherche sur les systèmes.
L’argument de l’équilibre
Pour revenir à l’affirmation centrale : la passerelle n’est pas la destination finale de la vague du Edge Computing. C'est le point d'équilibre actuel.
Les forces sont dynamiques. La densité du silicium continue de s'améliorer ; le niveau des appareils absorbera les charges de travail qui nécessitent aujourd’hui un calcul de classe passerelle. L'informatique confidentielle évoluera sur le silicium embarqué, dissolvant ainsi une partie de l'avantage de la passerelle en matière d'alignement du périmètre de sécurité. Les communications ultra-fiables à faible latence 5G et 6G, lorsqu'elles sont effectivement déployées à grande échelle, peuvent attirer certaines charges de travail vers la périphérie du réseau. Chacun de ces changements répartira les charges de travail entre les quatre niveaux.
Mais à l’horizon prévisible – appelons-le cinq à dix ans – c’est au niveau de la passerelle que convergent les forces actuelles. Son matériel est suffisamment performant pour exécuter des charges de travail à usage général. Sa position administrative s'aligne sur les périmètres de sécurité établis. Sa densité d'agrégation correspond à la structure statistique des charges de travail industrielles précieuses. Ses outils ont mûri au point qu’il ne s’agit plus d’un effort de développement sur mesure mais d’une extension des opérations cloud natives.
Pour le praticien qui conçoit aujourd’hui un déploiement industriel de l’IoT, les implications sont directes. Considérez la passerelle comme une plate-forme informatique de premier ordre et non comme un pont protocolaire. Investissez dans la portabilité des charges de travail entre la passerelle et le cloud, sans vous enfermer dans l'un ou l'autre. Planifiez l’orchestration, l’observabilité et la gestion du cycle de vie des modèles dès le départ, et non après coup. Le niveau passerelle récompense l’investissement en ingénierie proportionnellement à cet investissement et pénalise les déploiements qui le traitent comme une appliance statique.
La périphérie n’est pas l’endroit où va le calcul. C’est là que le calcul, en partie, réside déjà. La passerelle est l’endroit où, pour l’instant, la majeure partie s’installe.
References
[1] ETSI. Informatique mobile (MEC) ; Cadre et architecture de référence. ETSI GS MEC 003, 2016 (révisé).
[2] J. Gray. «Économie de l'informatique distribuée». Rapport technique de recherche Microsoft MSR-TR-2003-24, 2003.
[3] D. McCrory. «La gravité des données dans les nuages». 2010.
[4] E.A. Brewer. «Vers des systèmes distribués robustes». Discours d'ouverture, PODC 2000.
[5] S. Gilbert et N. Lynch. "Conjecture de Brewer et faisabilité de services Web cohérents, disponibles et tolérants aux partitions." ACM SIGACT Actualités, 33(2), 2002.
[6] Parlement européen et Conseil. Règlement (UE) 2016/679 (Règlement Général sur la Protection des Données). 2016.
[7] Parlement européen et Conseil. Directive (UE) 2022/2555 (NIS2). 2022.
[8] Cour de justice de l'Union européenne. Commissaire à la protection des données contre Facebook Ireland et Schrems (Affaire C-311/18), 2020.
[9] C. Dwork. «Confidentialité différentielle». Actes de l'ICALP, 2006.
[10] HB McMahan et al. "Apprentissage efficace en matière de communication des réseaux profonds à partir de données décentralisées." AISSTATS, 2017.
[11] K. Bonawitz et coll. "Agrégation sécurisée pratique pour un apprentissage automatique préservant la confidentialité." ACM CCS, 2017.
[12] Consortium informatique confidentiel. Une analyse technique de l'informatique confidentielle. 2021.
[13] Rockchip électronique. Manuel de référence technique RK3588. 2022.
[14] Hailo Technologies. Fiche technique de l'accélérateur AI Hailo-8. 2021.
[15] Commission électrotechnique internationale. CEI 62443-3-3 : Réseaux de communication industriels — Sécurité des réseaux et des systèmes — Partie 3-3 : Exigences de sécurité du système et niveaux de sécurité. 2013.
[16] Rancher Labs/SUSE. K3s : Kubernetes léger. https://k3s.io
[17] CNCF. KubeEdge : un framework Edge Computing natif de Kubernetes. https://kubeedge.io
[18] N. Marz et J. Warren. Big Data : principes et meilleures pratiques des systèmes de données en temps réel évolutifs. Manning, 2015.
[19] J. Kreps. «Remettre en question l'architecture Lambda». Radar O'Reilly, 2014.
[20] B. Jacob et coll. "Quantisation et formation des réseaux de neurones pour une inférence efficace uniquement en arithmétique entière." CVPR, 2018.
[21] G. Hinton, O. Vinyals et J. Dean. « Distiller les connaissances dans un réseau neuronal. » Atelier d'apprentissage profond NeurIPS, 2014.
[22] B. Zoph et Q. V. Le. "Recherche d'architecture neuronale avec apprentissage par renforcement." ICLR, 2017.
[23] T. Li et coll. "Optimisation fédérée dans les réseaux hétérogènes." MLSys, 2020.
[24] L. Zhu, Z. Liu et S. Han. "Fuite profonde des dégradés." NeurIPS, 2019.
[25] M. Shapiro et coll. «Types de données répliquées sans conflit». SSS, 2011.
Cet article fait partie de la série technique Modibus. La plate-forme de passerelle Modibus MB213, avec son environnement d'application conteneurisé, sa capacité d'inférence accélérée par NPU et sa gestion déclarative de flotte, est conçue autour des modèles architecturaux décrits ici. Pour toute discussion technique ou demande de renseignements sur la plateforme, contactez [info@modibus.com](mailto:info@modibus.com).