L’edge computing traite les données au plus près de l’endroit où elles naissent : sur la machine, dans la caméra ou sur une passerelle locale, plutôt que dans un centre de données distant. Le calcul descend vers le terrain pour gagner en réactivité, économiser de la bande passante et garder la main sur des données sensibles.
Traiter la donnée là où elle naît
Le principe tient en une phrase : rapprocher le calcul de la source du signal. Un capteur de vibration, une caméra de contrôle, un automate produisent un flux continu. Plutôt que de pousser ce flux vers un centre de données situé à des centaines de kilomètres, une architecture de périphérie installe la puissance de traitement dans l’atelier, dans le local technique ou dans le boîtier lui-même.
Trois traits séparent cette approche d’une architecture centralisée classique :
- le calcul s’exécute à quelques mètres ou quelques kilomètres du capteur, pas à quelques centaines
- la décision qui compte se prend localement, sans attendre une réponse distante
- une fraction seulement des données remonte vers le cloud, agrégée, filtrée, horodatée
Le terme recouvre des réalités très différentes selon l’échelle :
- un microcontrôleur qui classe une signature vibratoire dans un ventilateur de machine
- une caméra intelligente qui juge une pièce sans rien envoyer au-delà du poste
- un serveur logé dans le local technique d’une usine ou d’un entrepôt
- une baie installée dans un central d’opérateur télécom, à quelques kilomètres des utilisateurs
Le point commun tient à la proximité, jamais à la taille du matériel.
Ce qui a poussé le calcul vers la périphérie
Le nombre de sources explique une bonne part du mouvement. Selon IoT Analytics, 2025, le monde comptait 21,1 milliards d’objets connectés fin 2025, avec une projection à 39 milliards en 2030. Chacun produit un flux qu’il faudrait transporter, stocker, puis traiter quelque part.
Le coût de ce « quelque part » a suivi la même courbe. D’après le rapport Energy and AI de l’Agence internationale de l’énergie, publié en 2025, les centres de données ont consommé environ 415 térawattheures en 2024, soit près de 1,5 % de l’électricité mondiale, avec une trajectoire vers 945 térawattheures en 2030. À l’échelle française, l’étude ADEME-Arcep publiée en janvier 2025, sur données 2022, attribue 46 % de l’empreinte carbone du numérique aux centres de données et 50 % aux terminaux.
Gartner annonçait dès 2018 que 75 % des données produites par les entreprises seraient créées et traitées hors d’un centre de données centralisé ou d’un cloud à l’horizon 2025, contre 10 % à l’époque. Le chiffre exact se discute encore, la direction beaucoup moins. Quatre forces poussent dans le même sens :
- des applications qui n’acceptent plus l’aller-retour, du freinage automatisé au tri sur convoyeur
- des liaisons montantes coûteuses, surtout pour la vidéo et les signaux échantillonnés vite
- des exigences réglementaires sur la localisation des données et leur minimisation
- des sites isolés, mobiles ou mal couverts, où la coupure réseau est une certitude, pas un risque
Comment fonctionne l’edge computing, étage par étage
Une architecture de périphérie s’organise en couches, du silicium embarqué jusqu’au cloud. Chaque étage traite ce que le précédent ne sait pas faire, et remonte le reste.
- le terminal : microcontrôleur, caméra intelligente, automate ou variateur, qui exécute un modèle léger en quelques millisecondes
- la passerelle : elle agrège plusieurs équipements, traduit les protocoles industriels, met en tampon et arbitre ce qui monte
- le serveur de périphérie, parfois appelé micro-centre de données : une baie dans un local technique, avec conteneurs, base de séries temporelles et modèles plus lourds
- la périphérie opérateur : des ressources de calcul installées dans le réseau mobile, cadrées depuis 2014 par le groupe ETSI ISG MEC, rebaptisé Multi-access Edge Computing en 2017 pour couvrir aussi les accès non mobiles
- le cloud : entraînement des modèles, archivage long, supervision de la flotte et déploiement des versions
La passerelle edge mérite une mention particulière, car elle porte le travail ingrat. Un atelier accumule des protocoles hérités de trois décennies, des horloges désynchronisées et des équipements qui parlent chacun leur dialecte. Cette couche normalise, horodate et chiffre avant que la donnée serve à quoi que ce soit.
Le trajet d’une décision, de la caméra à l’actionneur
Prenez une cellule de contrôle qualité sur convoyeur. Le cycle se déroule toujours dans le même ordre :
- acquisition : la caméra déclenche sur un signal d’automate et produit une image
- préparation : recadrage, correction d’exposition, mise à l’échelle, sur le processeur local
- classification : le modèle de détection rend un score en quelques dizaines de millisecondes
- décision : l’automate reçoit un verdict binaire et commande l’éjecteur
- remontée : seuls le verdict, quelques métriques et les images douteuses partent vers le serveur
- amélioration : le cloud réentraîne le modèle sur les cas litigieux, puis redescend une version signée
Rien dans cette boucle n’interdit le cloud. La règle d’architecture tient en deux temps : ce qui pilote reste en bas, ce qui apprend monte. L’inférence locale occupe l’étape 3, mais elle ne vaut que par la qualité des étapes 1 et 2, un enchaînement qui dépend directement du réseau d’atelier, sujet que détaille notre article sur l’industrie 4.0.
Edge, fog et cloud : où passe vraiment la frontière
La confusion vient du vocabulaire commercial, pas de la technique. Le NIST a publié en 2018 la note SP 500-325, Fog Computing Conceptual Model, qui pose une hiérarchie explicite entre les niveaux :
- le cloud : ressources mutualisées, quasi illimitées, mais distantes, avec un aller-retour qui se compte en dizaines de millisecondes et davantage sur un lien mobile chargé
- le fog : une couche intermédiaire, souvent hiérarchisée, qui orchestre le calcul entre plusieurs sites et le centre, où un nœud fog sait router, virtualiser et répartir des tâches
- l’edge : le dernier mètre, au contact du capteur et de l’actionneur, avec des ressources contraintes et une exigence temps réel
Le NIST ajoute un quatrième niveau, le mist computing, pour le calcul embarqué dans les microcontrôleurs les plus modestes. La distinction entre fog et edge reste débattue chez les praticiens, et les fournisseurs entretiennent volontiers le flou.
La différence avec le cloud, elle, se joue sur quatre axes concrets :
- la distance physique, donc une latence plancher imposée par la propagation du signal
- le modèle économique : investissement matériel réparti sur des sites, contre abonnement à la ressource
- l’élasticité : un serveur d’atelier ne double pas sa capacité en un appel d’API
- la responsabilité d’exploitation : votre équipe intervient physiquement, ou personne n’intervient
Aucun des trois niveaux n’annule les autres. Les architectures qui tiennent dans la durée les combinent, et documentent où chaque donnée est calculée, stockée, puis effacée.
Les gains réels, et ce qu’ils coûtent
Quatre bénéfices se mesurent sur le terrain :
- réactivité : une boucle locale se ferme en millisecondes, quand un aller-retour distant dépend du réseau, de sa charge et de la distance
- bande passante : filtrer une vidéo sur place évite de transporter des flux continus qui saturent la liaison montante d’un site
- confidentialité : garder images, voix ou données de santé dans l’enceinte du site réduit la surface d’exposition et simplifie la conformité
- continuité : une ligne de production, un tunnel ou un navire continuent de fonctionner pendant une coupure, avec un tampon local rejoué au retour
La souveraineté des données pèse de plus en plus lourd dans les arbitrages européens, puisqu’une donnée qui ne quitte jamais le site échappe mécaniquement aux questions de localisation et de transfert. Mesurez la latence de bout en bout, capteur et actionneur compris, jamais le seul temps d’inférence affiché par la carte : l’écart entre les deux atteint souvent un facteur trois.
Ce que le déploiement fait payer
Quatre contreparties, que les démonstrations passent sous silence, arrivent avec le premier site équipé :
- un parc à administrer : cent sites, ce sont cent machines à inventorier, superviser, dépanner et remplacer, avec des versions qui divergent
- une sécurité physique réelle : un boîtier accessible dans un couloir ou sur un mât n’a pas les défenses d’un centre de données
- un risque de rupture au déploiement : pousser un modèle ou un correctif sur des milliers d’équipements exige des mises à jour signées, un déploiement progressif et un retour arrière automatique
- une hétérogénéité matérielle : architectures processeur, accélérateurs et systèmes d’exploitation varient d’un lot à l’autre, et vos images logicielles avec eux
Le poste le plus sous-estimé reste l’observabilité. Un modèle qui dérive en périphérie ne se signale pas tout seul : sans remontée de métriques, la qualité se dégrade pendant des semaines avant qu’un opérateur ne s’en aperçoive.
Là où la périphérie tourne déjà en production
Le marché donne l’échelle du phénomène. D’après IDC, dans sa prévision publiée en 2025, les dépenses mondiales en solutions d’edge computing approchent 261 milliards de dollars sur l’année et progressent à un rythme annuel de 13,8 % pour atteindre près de 380 milliards en 2028. Le commerce et les services pèsent 28 % de ce total, l’industrie et les ressources 25 %.
Les usages sérieux se reconnaissent à une contrainte physique, pas à un effet d’annonce :
- vision industrielle : sur un convoyeur, la décision d’éjecter une pièce tient dans le temps de cycle, ce qui interdit tout aller-retour distant, un mécanisme détaillé dans notre article sur la vision industrielle en contrôle qualité
- véhicules autonomes et engins mobiles : perception, fusion de capteurs et freinage s’exécutent à bord, le réseau servant à la cartographie et à la collecte des cas difficiles
- maintenance prédictive : l’analyse vibratoire haute fréquence se traite sur place, seules signatures et alertes remontent, une logique développée dans notre article sur la maintenance prédictive industrielle
- santé : imagerie, surveillance de patients et blocs opératoires traitent localement des données à caractère personnel, un terrain que recoupe notre analyse de l’intelligence artificielle en diagnostic médical
- commerce : comptage de flux, prévention des pertes, étiquetage dynamique et bornes continuent de servir quand la liaison du magasin tombe
- télécoms : les opérateurs hébergent des applications au plus près de l’antenne, dans le cadre spécifié par ETSI
Le lien avec la 5G mérite une précision technique. Depuis la version 15 de ses spécifications, le 3GPP vise pour les communications ultra-fiables à faible latence une latence d’une milliseconde sur l’interface radio et une fiabilité de 99,999 %. Ce budget temps ne laisse aucune place à un trajet vers un centre de données lointain : la 5G industrielle suppose des serveurs installés à côté de l’antenne. Les répliques virtuelles d’équipements exploitent la même proximité pour rester synchronisées, comme le montre notre dossier sur le jumeau numérique.
IA embarquée : des modèles taillés pour la périphérie
Un modèle entraîné dans un centre de données ne se déploie pas tel quel sur une carte à quelques watts. Trois techniques dominent la mise au régime :
- quantification : convertir des poids en virgule flottante 32 bits vers des entiers 8 bits divise par quatre l’empreinte mémoire et exploite l’arithmétique entière des processeurs embarqués
- élagage : supprimer les connexions dont la contribution reste négligeable, puis réajuster le réseau
- distillation : entraîner un petit modèle à imiter les sorties d’un grand, plutôt qu’à apprendre seul sur les données brutes
Ces modèles compressés s’exécutent ensuite sur des supports matériels très variés :
- des unités de traitement neuronal intégrées aux processeurs récents
- des cartes graphiques compactes, au format module embarqué plutôt que carte serveur
- des circuits logiques programmables, quand la latence doit rester constante au cycle près
- des microcontrôleurs simples, terrain du courant TinyML, dont la mémoire vive se compte en centaines de kilooctets
La consommation tombe alors à quelques watts, parfois quelques milliwatts, ce qui ouvre des emplacements interdits à un serveur classique : mât, véhicule, équipement sur batterie.
Deux précautions accompagnent cette compression :
- la précision se vérifie sur vos données à vous, jamais sur le jeu de test du fournisseur
- la version du modèle et celle du prétraitement voyagent ensemble, sous peine de dérive silencieuse
L’apprentissage fédéré prolonge la démarche. Chaque site entraîne localement puis partage des mises à jour de paramètres, jamais ses données brutes. Les images restent dans l’usine ou dans l’hôpital, la connaissance circule.
Local ou cloud : la grille de tri
Cinq questions suffisent à trancher la majorité des cas. Posez-les dans l’ordre, usage par usage.
- Quel délai maximal sépare la mesure de l’action ? Sous cent millisecondes, le traitement descend.
- Quel volume brut génère la source, et que coûte son transport sur douze mois ?
- Que se passe-t-il pendant une coupure de trente minutes ? Si la production s’arrête, prévoyez une autonomie locale.
- La donnée est-elle personnelle, stratégique ou soumise à une contrainte de localisation ?
- Combien de sites faudra-t-il exploiter, avec quelle équipe disponible sur place ?
Le traitement en périphérie se justifie dès que deux réponses au moins pointent vers le terrain. Un signal isolé, une latence confortable et un volume modeste plaident au contraire pour le cloud, bien plus simple à exploiter.
Trois erreurs reviennent projet après projet :
- déployer un serveur par site avant d’avoir mesuré le besoin réel en calcul
- oublier le budget d’exploitation, supervision, pièces de rechange et interventions comprises
- coupler l’application au matériel d’un fournisseur unique, ce qui interdit toute bascule ultérieure
Prochaine étape : listez vos flux, notez pour chacun le délai admissible, le débit et la sensibilité, puis instrumentez le cas le plus contraignant sur un seul site pendant un mois. Ce relevé dira si votre projet d’edge computing commence par un achat de serveurs ou par une remise à plat de la chaîne de mesure.