Edge, MEC, Fog, Cloud-RAN et infrastructures distribuées

Edge, MEC, Fog, Cloud-RAN et infrastructures distribuées

Le cloud a concentré le calcul dans de très grands centres de données, loin des utilisateurs et des objets qui produisent les données. Une série d’architectures fait le chemin inverse : rapprocher calcul, stockage et fonctions réseau du terrain, dans une usine, une gare, au pied d’une antenne mobile ou dans un local technique de ville moyenne. Edge, MEC, fog, Cloud-RAN : les noms varient selon qui les promeut, l’idée reste la même, et elle a un prix. Cette fiche explique pourquoi distribuer, quelles architectures existent et ce que coûte l’exploitation d’une infrastructure éparpillée.

Explication de la marmotte

Plutôt que de tout préparer dans une grande cuisine centrale éloignée de la ville, une chaîne de restaurants peut installer de petites cuisines près de ses clients, pour servir plus vite. Ce chapitre présente cette idée appliquée à l’informatique : rapprocher les calculs des utilisateurs et des objets connectés, avec ce que cela coûte en surveillance et en entretien.

→ Lire l’explication complète de la marmotte

Pourquoi distribuer le calcul

Quatre raisons, rarement une seule

La première raison est la latence. La lumière parcourt environ 200 km par milliseconde dans une fibre ; un centre de données situé à 1000 km impose donc au moins 10 ms d’aller-retour, avant tout traitement et toute file d’attente. Pour un robot qui corrige sa trajectoire, une réalité augmentée qui suit les mouvements de la tête ou un automate de sécurité, ces millisecondes comptent. La physique ne négocie pas, et rapprocher le calcul est la seule manière de les récupérer.

La deuxième raison est le volume de trafic. Vingt caméras qui produisent chacune un flux de 4 Mbit/s représentent 80 Mbit/s montants permanents, soit environ 860 Go par jour. Les analyser sur place et n’envoyer vers le centre que les événements détectés et quelques extraits réduit ce volume de plusieurs ordres de grandeur.

La troisième raison est l’autonomie locale. Une usine ne peut pas arrêter sa ligne parce que la liaison vers le cloud est coupée. Un traitement local continue de fonctionner en mode dégradé, puis resynchronise ses données au retour du lien.

La quatrième raison tient au métier et au droit : garder sur place des images de personnes ou des secrets industriels, répondre à une exigence de souveraineté, maîtriser des coûts de transfert sortant facturés au volume par les fournisseurs cloud.

Cloud centralisé, edge et fog

Le cloud computing fournit à la demande des ressources mutualisées, facturées à l’usage, dans des centres de données de grande taille. Il excelle pour l’élasticité, le stockage durable et les traitements lourds sans contrainte de temps réel.

L’edge computing, ou informatique de périphérie, place le calcul au plus près de la source des données : passerelle industrielle, serveur dans une armoire technique, boîtier à côté des caméras. Le terme est large, et chaque fournisseur place la « périphérie » là où se trouve son produit.

Le fog computing (ou fog networking) désigne une couche intermédiaire entre les objets et le cloud, répartie sur plusieurs niveaux : passerelles, routeurs dotés de capacités de calcul, petits serveurs régionaux. Le terme a été popularisé par Cisco au début des années 2010 ; le consortium OpenFog en a publié une architecture de référence, reprise par l’IEEE dans la norme IEEE 1934-2018, avant de fusionner en 2019 avec l’Industrial Internet Consortium. Dans l’usage actuel, la distinction entre fog et edge s’est largement estompée au profit du second terme.

Le cloud continuum

Le cloud continuum décrit l’ensemble de ces niveaux comme un seul espace d’exécution : de l’objet à la passerelle, de la passerelle au site de proximité, puis au centre régional et au cloud public. L’idée est de placer chaque traitement au niveau qui satisfait ses contraintes de latence, de volume, d’autonomie et de coût, et de pouvoir le déplacer. En pratique, cela suppose des outils d’orchestration capables de déployer la même charge à plusieurs niveaux, souvent des conteneurs gérés par des distributions Kubernetes allégées, comme le décrit Conteneurs, Kubernetes et CNI.

Architectures associées

MEC

Le MEC (Multi-access Edge Computing) est une architecture normalisée par l’ETSI (European Telecommunications Standards Institute), dont le groupe de travail a été créé en 2014 sous le nom de Mobile Edge Computing, puis renommé en 2017 pour couvrir aussi le Wi-Fi et les accès fixes. Il place des serveurs d’applications dans le réseau de l’opérateur, près des stations de base ou dans les centraux régionaux, et définit des interfaces qui permettent à ces applications de connaître le contexte radio ou la localisation d’un terminal. Un MEC n’est pas un serveur posé dans un placard : c’est une plateforme intégrée au réseau mobile, avec ses interfaces de programmation, son orchestration et le routage du trafic des abonnés vers l’application locale. En 5G, cette sortie locale du trafic s’appuie sur une fonction du cœur de réseau appelée UPF (User Plane Function), déployable à proximité du site.

Cloud-RAN et vRAN

Le RAN (Radio Access Network) regroupe les antennes et les équipements qui traitent le signal radio. Traditionnellement, chaque site cellulaire embarque une unité de traitement en bande de base. Le Cloud-RAN (ou C-RAN), proposé au début des années 2010, centralise ces traitements dans un site commun qui sert de nombreuses antennes. Le vRAN (virtualized RAN) va plus loin en faisant tourner ces fonctions sous forme logicielle sur des serveurs génériques, éventuellement accélérés par du matériel spécialisé.

La 5G découpe la station de base en trois éléments : l’unité radio (RU, Radio Unit) près de l’antenne, l’unité distribuée (DU, Distributed Unit) et l’unité centrale (CU, Centralized Unit). L’O-RAN Alliance, créée en 2018, spécifie des interfaces ouvertes entre ces éléments pour permettre de mélanger les fournisseurs. Le lien entre l’unité radio et l’unité distribuée, le fronthaul, impose des contraintes sévères : débit élevé, latence comptée en microsecondes plutôt qu’en millisecondes, et synchronisation très précise, assurée par PTP (Precision Time Protocol, IEEE 1588), Ethernet synchrone ou des récepteurs GNSS (Global Navigation Satellite System). Le Cloud-RAN est donc d’abord un problème de transport et d’horloge, ensuite un problème de calcul. Sa maturité varie fortement selon les opérateurs et les régions, et les déploiements commerciaux restent minoritaires face aux stations de base intégrées.

Datacenters embarqués et centres de proximité

Un datacenter embarqué est un petit centre de données préfabriqué, parfois dans un conteneur maritime ou une armoire renforcée, installé sur un site industriel, un navire, un site minier ou un véhicule. Un centre de données de proximité est une installation de taille moyenne, en ville, à quelques kilomètres des utilisateurs. Les deux apportent les mêmes promesses de proximité, avec des contraintes de refroidissement, d’alimentation et d’accès physique sans commune mesure avec un grand centre.

Dépendances de connectivité

Un site edge ne vit pas seul. Il dépend d’un ou plusieurs liens vers le centre, souvent pilotés par du SD-WAN (Software-Defined Wide Area Network), qui choisit dynamiquement le lien selon sa qualité. Il dépend aussi des réseaux d’objets, filaires ou radio, détaillés dans Réseaux personnels et IoT, et souvent de la 5G pour les terminaux mobiles. Enfin, il dépend du centre pour l’identité, les mises à jour, la supervision et la résolution de noms. Recenser ces dépendances, c’est découvrir ce qui continue de fonctionner quand le lien tombe, et ce qui s’arrête avec lui.

Sécurité et exploitation

Un site moins maîtrisé qu’un datacenter

Un grand centre de données a des gardiens, des sas, des caméras et des procédures d’accès. Une armoire edge dans un atelier a une serrure, parfois la même clé que toutes les armoires du bâtiment. Il faut donc supposer qu’un attaquant peut toucher le matériel. Les protections adaptées sont connues : démarrage sécurisé (secure boot) qui refuse un système non signé, chiffrement des disques avec des clés scellées dans un TPM (Trusted Platform Module), désactivation des ports inutiles, détection d’ouverture du boîtier, attestation à distance de l’intégrité du système. Les secrets stockés sur le site doivent être limités à ce dont il a besoin, et révocables depuis le centre.

Journaliser et mettre à jour des nœuds dispersés

Mettre à jour un serveur est simple ; en mettre à jour quatre cents, dont trente sont hors ligne et dix derrière une liaison radio saturée, l’est beaucoup moins. Les pratiques qui fonctionnent sont l’installation sans intervention locale (zero-touch provisioning), les mises à jour atomiques avec deux partitions système (schéma A/B) qui permettent de revenir à la version précédente si le démarrage échoue, et des déploiements par vagues, avec un petit groupe pilote d’abord. Les journaux doivent remonter vers le centre ; quand le lien est coupé, ils sont conservés localement puis transmis au retour. Un nœud qui ne se signale plus doit déclencher une alerte, au même titre qu’un nœud qui signale un problème.

Prévoir le fonctionnement dégradé

Chaque site doit savoir ce qu’il fait quand le centre est injoignable : continuer avec les dernières politiques connues, mettre en file les données à transmettre, refuser les nouvelles authentifications ou les accepter avec un cache limité dans le temps. Ces choix relèvent du métier autant que de la technique, et se décident avant la coupure, pas pendant. La synchronisation du temps fait partie du sujet : un site isolé dont l’horloge dérive produit des journaux impossibles à corréler et peut rejeter des certificats valides ; voir DNS, DHCP, NTP.

Exemples et ateliers

Choisir entre cloud central, edge ou hybride

Cas	Contrainte dominante	Choix raisonnable
Usine : contrôle qualité par vision sur une ligne	latence, autonomie	edge sur site, modèles entraînés dans le cloud et déployés localement
Transport : billettique dans les bus	autonomie, liaisons intermittentes	traitement embarqué, synchronisation différée vers le centre
Vidéosurveillance de cent caméras	volume, confidentialité des images	analyse en edge, envoi des seuls événements et extraits
Tableau de bord commercial	aucune contrainte de temps réel	cloud central, sans hésitation

Le dernier cas n’est pas une plaisanterie : bon nombre de projets edge auraient gagné à rester dans le cloud, où l’exploitation est faite par quelqu’un d’autre.

Dessiner un site edge avec secours mobile

Un site type comprend deux serveurs en grappe pour supporter la perte de l’un d’eux, un commutateur, un pare-feu, un lien fibre principal et un routeur 4G ou 5G de secours. Le pare-feu bascule sur le lien mobile quand le lien principal tombe ; le SD-WAN réserve alors la capacité réduite aux flux critiques (télémétrie, alertes, administration) et suspend les transferts volumineux. L’accès d’administration passe par un tunnel initié depuis le site vers le centre, de sorte qu’aucun port n’est ouvert vers le site depuis Internet. Une alimentation secourue de quelques dizaines de minutes couvre les microcoupures et permet un arrêt propre.

Lister les flux edge vers cloud

Flux	Sens	Protocole type	Criticité
Télémétrie et métriques	site vers centre	HTTPS, MQTT sur TLS	haute
Journaux	site vers centre	syslog sur TLS	haute
Mises à jour et images	centre vers site, tiré par le site	HTTPS	moyenne, différable
Administration	tunnel initié par le site	SSH, VPN	haute, très restreinte
Synchronisation du temps	site vers sources de temps	NTP	haute
Données métier agrégées	site vers centre	API HTTPS	selon le métier

Ce tableau sert ensuite de base à la politique de filtrage du site, décrite dans Filtrage, segmentation, NAC et Zero Trust.

Pièges classiques

Le premier piège est de déployer de l’edge sans exploitation. Le projet pilote fonctionne parce que l’équipe qui l’a monté s’en occupe ; à cent sites, sans outillage ni astreinte, il se dégrade sans bruit.

Le deuxième piège est de sous-estimer la mise à jour distribuée. Chaque site non mis à jour est une vulnérabilité exposée dans un local peu surveillé, et la tentation de « ne pas toucher à ce qui marche » y est plus forte qu’ailleurs.

Le troisième piège est de confondre faible latence et haute disponibilité. Un serveur unique au pied de la machine répond très vite, et tombe aussi très bien. La disponibilité vient de la redondance et du fonctionnement dégradé, pas de la proximité.

À ne pas confondre

Edge et CDN : un CDN (Content Delivery Network) distribue des copies de contenus, essentiellement en lecture, au plus près des utilisateurs. L’edge exécute des traitements sur des données produites localement. Les CDN proposent désormais du calcul à leur périphérie, ce qui brouille la frontière sans la supprimer.

MEC et simple serveur local : le MEC est intégré au réseau de l’opérateur, avec des interfaces normalisées et un routage du trafic des abonnés. Un serveur dans l’armoire d’une agence est un serveur local, utile mais sans ces propriétés.

Fog et cloud privé : le cloud privé reproduit dans un centre de données de l’organisation le modèle de services du cloud public. Le fog répartit le traitement sur plusieurs niveaux entre les objets et le centre. L’un est un mode d’hébergement, l’autre une topologie.

🐝 Ce qui arrive si on s’en passe

Déployer des nœuds de périphérie sans les exploiter comme de vrais sites revient à semer des serveurs dans des locaux que personne ne surveille. Un nœud qui n’est plus mis à jour conserve ses vulnérabilités aussi longtemps qu’il reste branché, souvent bien après que l’équipe qui l’a installé est passée à autre chose. Sans journalisation remontée vers le centre, une compromission locale ne laisse de trace que sur l’équipement compromis, donc à la disposition de l’intrus. Et un site physiquement accessible permet à qui passe devant de brancher, débrancher ou emporter, d’autant plus tranquillement que le fonctionnement dégradé prévu pour les coupures fera passer l’arrêt pour une simple panne de liaison.

🦫 Explication de la marmotte 🍫

Dans le modèle du cloud centralisé, les calculs et les données sont traités dans de grands centres de données éloignés. L’informatique de périphérie, appelée edge, place au contraire des ressources de calcul, de stockage et de réseau près des utilisateurs ou des objets connectés : dans une usine, sur un site de transport, près d’une antenne de téléphonie ou dans un petit centre de données de proximité. Le fog désigne un niveau intermédiaire entre ces équipements locaux et le cloud, et l’on parle de continuum pour l’ensemble qui va de l’objet au grand centre. Certaines architectures placent ces calculs directement dans les réseaux mobiles, et transforment même une partie des équipements d’antenne en logiciels tournant sur des serveurs. Ces choix répondent à plusieurs besoins : réduire le temps de réponse, limiter le trafic envoyé au loin, continuer à fonctionner si la liaison est coupée, garder certaines données sur place ou contrôler les coûts. Distribuer crée pourtant des difficultés. Un site de périphérie est souvent moins protégé physiquement qu’un grand centre. Il faut mettre à jour, surveiller et journaliser des nœuds dispersés, et prévoir leur fonctionnement dégradé quand la connexion au centre est perdue. Chaque site dépend aussi de sa connectivité, qu’il faut parfois doubler par un lien de secours mobile. Enfin, un temps de réponse court ne signifie pas que le service reste disponible en cas de panne.

À lire aussi

• Accès hertziens, mobiles, satellites et small cellsComprendre les réseaux d’accès hertziens et mobiles : générations cellulaires, satellites, small cells, backhaul, handover et architectures mobiles modernes.
• Cloud IaaS, PaaS, SaaS et modèles de déploiement, qui sécurise quoiDéfinition du cloud computing selon le NIST, modèles de service IaaS, PaaS, SaaS et modèles de déploiement, avec ce que chacun délègue réellement en sécurité et ce qu'il laisse au client.
• Cloud networking, VPC/VNet, CDN et équilibrageExpliquer les objets réseau cloud comme composants pratiques : VPC/VNet, subnets, routes, gateways, security groups, NACL, load balancers, endpoints privés, CDN et journaux.
• Comprendre pourquoi les systèmes communiquentDonner une vision claire de ce qu’un réseau permet : relier des systèmes, partager des ressources, distribuer des services, transporter des données et exposer des surfaces de sécurité.

Pages voisines

La citent

• Accès hertziens, mobiles, satellites et small cells
• Performance, QoS, capacité et sobriété énergétique

Edge, MEC, Fog, Cloud-RAN et infrastructures distribuées

Elle cite

• Conteneurs, Kubernetes, CNI et service mesh
• Attestation distante TPM et démarrage mesuré
• Brouillage et leurrage GNSS, détection, OSNMA et repli du temps
• DNS, DHCP, NTP : services d'infrastructure réseau
• Filtrage, segmentation, NAC et Zero Trust
• Réseaux personnels, IoT et objets contraints
• Sécuriser les caméras IP et le stockage vidéo cloud