Le nuage ne disparaîtra pas. Mais l’idée selon laquelle tout doit fonctionner dans un centre de données centralisé, à des centaines de kilomètres de l’endroit où les données sont générées, commence à montrer ses fissures. Lorsqu'une ligne de production doit détecter un défaut en temps réel, lorsqu'un véhicule autonome décide de freiner en quelques millisecondes ou lorsqu'un détaillant doit traiter les stocks d'un magasin sans s'appuyer sur une connectivité stable, la latence aller-retour vers le cloud n'est pas un détail technique : c'est un problème commercial avec des conséquences directes sur l'exploitation.
Pourquoi la centralisation a un coût
Le cloud public fonctionne extraordinairement bien pour les charges de travail qui tolèrent une latence de plusieurs dizaines de millisecondes, qui disposent d'une bande passante disponible pour transférer des données en continu et qui ne sont pas soumises à des restrictions strictes quant à l'endroit où les données peuvent résider. Pour tout ce qui ne correspond pas à cette description, la centralisation commence à jouer contre vous.
Un capteur industriel typique peut générer des gigaoctets de données par heure. Envoyer tout cela vers le cloud, traiter et renvoyer une décision n'est pas seulement coûteux en termes de bande passante : c'est aussi trop lent pour tout processus nécessitant une réponse en temps réel. Ici, le modèle centralisé n’est pas seulement inefficace ; il n'est pas viable. La latence n'est pas optimisable dans le modèle actuel, car le problème est physique : les signaux électromagnétiques ont une limite de vitesse.
La souveraineté des données ajoute une autre couche. Des réglementations telles que la LGPD, mais aussi des règles sectorielles dans les domaines de la santé, de la finance et des infrastructures critiques, restreignent ou compliquent l'envoi de certaines catégories de données vers des serveurs extérieurs au périmètre contrôlé. Le traitement localement, ou en bordure du réseau, n'est plus une option architecturale et devient une exigence réglementaire.
Qu'est-ce que l'informatique de pointe
L’Edge Computing consiste à déplacer une partie de la capacité informatique vers des points physiquement proches de la source de données : l’usine, l’antenne d’une tour 5G, le point de vente d’une chaîne de vente au détail, le matériel embarqué dans un véhicule. Au lieu que chaque élément de données soit acheminé jusqu'au cloud central, une quantité importante de traitement a lieu avant même que ces données ne quittent l'environnement dans lequel elles ont été générées.
Cela ne remplace pas le cloud. Il remplace une partie spécifique de ce que faisait le cloud : la partie qui nécessite une réponse rapide, qui traite les données sensibles localement ou qui ne peut pas dépendre d'une connectivité constante. Le cloud central reste l'endroit où vous regroupez l'historique, formez des modèles et orchestrez la vue d'ensemble. Le bord est l'endroit où vous agissez.
La distinction entre edge computing et fog computing apparaît ici. Fog est une couche intermédiaire (serveurs dans une sous-station, dans un entrepôt régional) qui regroupe les données de plusieurs appareils avant de les envoyer vers le cloud. Edge est le nœud le plus proche possible de l'origine. En pratique, de nombreuses architectures combinent les deux.
Là où l'informatique de pointe change la donne
La fabrication est le cas le plus clair. Vision par ordinateur en temps réel, détection d'anomalies dans les équipements, ajustement des paramètres de production à partir de capteurs : tout cela nécessite une réponse en millisecondes que le cloud central ne peut pas fournir. Les processeurs Edge présents dans les usines résolvent le problème de latence sans sacrifier le lien avec les systèmes de gestion centraux.
Les télécommunications et la 5G sont un autre vecteur. Les opérateurs développent des capacités de traitement dans leurs propres tours, ce qui leur permet d'exécuter des applications directement à la périphérie de leur réseau. Pour les jeux dans le cloud, la chirurgie assistée à distance, la réalité augmentée industrielle – tout ce qui nécessite une latence inférieure à 10 millisecondes – cette architecture est la seule qui fonctionne.
Le commerce de détail physique présente des défis spécifiques en matière de connectivité et de traitement local. Systèmes de caisse autonomes, surveillance des stocks par caméra, personnalisation en temps réel dans les allées : ces applications ne peuvent pas attendre une réponse du cloud à chaque image vidéo. Le traitement en magasin, avec une synchronisation périodique, résout le problème.
Les véhicules autonomes en sont peut-être l’exemple le plus dramatique. La voiture doit prendre des décisions en une fraction de seconde sur la base des caméras, du lidar et du radar. Attendre le cloud n'est pas une limitation technique acceptable : c'est un problème de sécurité physique. Tous les processus de perception et de décision ont lieu dans le véhicule, sans dépendance au réseau.
Comment concevoir une architecture pour la périphérie sans fragmenter l'opération
Le plus gros risque à la frontière n’est pas technologique. Il est opérationnel. La répartition de la capacité de calcul sur des dizaines, des centaines ou des milliers de nœuds crée une complexité qui peut contrebalancer les avantages si l'architecture n'est pas conçue pour cela dès le départ.
La première décision est de définir quels processus et où. Tout ce qui peut fonctionner en périphérie ne doit pas nécessairement fonctionner en périphérie. Le traitement haute fréquence et faible latence appartient à la périphérie. L'agrégation historique, la formation de modèles et les corrélations globales appartiennent au cloud central. Garder cette division claire évite la duplication de logique et la création d’incohérences entre les environnements.
Le deuxième problème est l’orchestration. La gestion des mises à jour logicielles sur les nœuds distribués nécessite une stratégie de déploiement différente de celle utilisée dans le cloud. Des solutions telles que Kubernetes dans des configurations hybrides, ou des plateformes dédiées à la gestion de périphérie comme AWS IoT Greengrass ou Azure IoT Edge, offrent une visibilité centralisée sans nécessiter d'intervention manuelle sur chaque nœud.
Le troisième est le modèle de données. Ce qui est synchronisé, quand et comment les conflits sont résolus doivent être décidés avant la construction. L'Edge Computing n'est pas une extension du cloud, c'est une architecture distribuée avec tout ce que ce terme implique : un partitionnement, une cohérence éventuelle, des états locaux qui doivent converger.
La sécurité dans les environnements distribués change également de profil. Chaque nœud périphérique est une surface d'attaque physique. Le chiffrement au repos et en transit, l'authentification mutuelle entre les nœuds et le cloud et la possibilité de désactiver à distance un appareil compromis doivent tous figurer dans le plan architectural avant de passer en production.
A lire aussi
- Edge computing : pourquoi le traitement distribué va redéfinir votre architecture
- Architecture Edge Computing : Stratégies pour le traitement distribué
- Edge computing dans les usines : quand traiter localement a plus de sens
- RISC-V à la périphérie et IoT : pourquoi l'architecture ouverte est importante
- Informatique autonome : lorsque le système se corrige avant que vous ne remarquiez l'erreur
- Énergie : le goulot d'étranglement que personne n'a mis sur la feuille de route informatique