Edge computing : quand déporter le calcul en périphérie devient rentable

L'edge computing revient dans toutes les discussions infra depuis deux ans. Promesse : rapprocher le calcul de la donnée pour gagner en latence, réduire la bande passante, fonctionner hors-ligne. Réalité terrain : c'est vrai, mais ça vient avec une facture opérationnelle que beaucoup sous-estiment. Déployer du code sur une flotte de devices dispersés, les monitorer, les patcher, gérer les pannes réseau… c'est un métier à part entière.

On a accompagné plusieurs projets edge ces trois dernières années — du retail avec analyse vidéo temps réel aux sites industriels isolés. Le pattern se répète : l'architecture technique tient debout rapidement, mais c'est la partie ops qui fait mal. Cet article pose les vrais critères de décision et partage les écueils qu'on a vus en prod.

Pas de bullshit marketing : si votre use case tient avec 200 ms de latency et une connexion stable, restez dans le cloud. Mais si vous êtes dans l'un des cas ci-dessous, l'edge devient une vraie option.

Les quatre déclencheurs qui rendent l'edge rentable

L'edge computing ne se justifie pas par effet de mode. On l'envisage quand l'une de ces quatre contraintes devient bloquante en production.

1. Latence incompressible

Quand chaque milliseconde compte. Typiquement : vidéo surveillance avec détection d'intrusion en temps réel, contrôle-qualité sur chaîne de production, assistance à la conduite. Si votre SLA impose une décision sous 50 ms, un round-trip cloud vous fait sortir du budget. L'inférence locale devient obligatoire.

Exemple concret : un client retail analyse les flux en magasin pour détecter les comportements suspects. Le modèle tourne sur Jetson Nano (99 €/device), inférence à 30 FPS, décision en 15-20 ms. Impossible avec un aller-retour vers AWS, même en région proche.

2. Bande passante prohibitive

Envoyer des streams vidéo 4K, des nuages de points LiDAR ou des flux IoT haute fréquence dans le cloud coûte cher — en euros et en latence réseau. L'edge permet de filtrer, agréger et ne remonter que les anomalies ou les métadonnées.

On a vu un projet industriel passer de 12 To/jour remontés vers le cloud à 400 Go en déployant un traitement edge qui ne remonte que les événements qualifiés. Gain direct en egress costs AWS (~1 000 $/mois économisés) et en charge réseau.

3. Disponibilité offline obligatoire

Sites isolés, plateformes pétrolières, véhicules autonomes, entrepôts logistiques avec couverture réseau aléatoire. Si votre service doit continuer à fonctionner quand le lien WAN tombe, vous avez besoin d'autonomie locale. L'edge devient votre fallback par design.

4. Souveraineté des données

RGPD, réglementations sectorielles, clauses contractuelles : certaines données ne peuvent tout simplement pas sortir du site. Analyse vidéo dans les hôpitaux, données RH, process industriels confidentiels. L'edge computing permet de traiter sur place et de ne remonter que des données anonymisées ou agrégées.

Edge vs cloud : complémentaires, pas exclusifs

L'edge ne remplace pas le cloud. Les deux travaillent ensemble dans une architecture hybride bien pensée. Le cloud centralise l'entraînement des modèles, l'agrégation des métriques, le stockage long terme et la supervision globale. L'edge exécute l'inférence, filtre les données, prend les décisions critiques en local.

Pattern classique qu'on déploie chez nos clients :

• Edge : inférence temps réel (TensorRT, ONNX Runtime), décisions locales, cache des données critiques, continue à tourner offline.
• Cloud : entraînement et fine-tuning des modèles, agrégation cross-sites, dashboards globaux, stockage S3, distribution des mises à jour OTA.
• Sync bidirectionnel : l'edge remonte les anomalies et métriques, le cloud pousse les nouveaux modèles et configs. MQTT, gRPC ou HTTP/2 selon la contrainte réseau.

Ce découplage permet de garder la résilience locale tout en conservant la puissance du cloud pour tout ce qui n'est pas time-critical.

Edge AI : l'inférence au plus près du capteur

Déployer des modèles ML directement sur le device, c'est l'edge AI. Concrètement : vous entraînez dans le cloud (GPU A100, gros datasets), puis vous exportez un modèle optimisé pour l'embarqué (quantization INT8, pruning, distillation) et vous le déployez sur un accélérateur local.

Stack type qu'on utilise en prod :

• Hardware : NVIDIA Jetson (Nano, Xavier, Orin selon le budget), Google Coral Edge TPU, Intel NCS2, ou même Raspberry Pi 4 pour les workloads légers.
• Formats : ONNX (interop maximale), TensorRT (perf max sur Jetson), TFLite (mobile/edge).
• Optimisation : quantization post-training INT8 (4x plus rapide, 4x moins de mémoire), pruning si le modèle le tolère.

Exemple chiffré : un ResNet-50 classique fait ~25 FPS sur Jetson Nano. Quantizé INT8 + TensorRT, on monte à 90 FPS. Ça change tout pour de l'analyse vidéo multi-caméras.

Le piège : tous les modèles ne se quantizent pas bien. Testez la précision post-quantization sur vos données réelles. On a vu des cas où la précision chutait de 92 % à 78 % après INT8, rendant le modèle inutilisable. Dans ce cas, soit vous gardez FP16, soit vous revenez au cloud.

Le vrai défi : les opérations distribuées

Mettre du code en prod sur 10 devices, c'est faisable avec SSH et un script bash. Gérer 500 devices hétérogènes répartis sur 50 sites, c'est un problème d'ingénierie à part entière. C'est le point de friction qu'on voit systématiquement sous-estimé en phase de conception.

Déploiement OTA (Over-The-Air)

Vous devez pouvoir déployer une nouvelle version du modèle ou du runtime sur toute la flotte sans intervention physique. Ça impose :

• Un registry centralisé (Harbor, ECR, Artifactory) pour les artefacts (containers, modèles, configs).
• Un agent local sur chaque device qui poll ou reçoit les updates (balenaOS, AWS IoT Greengrass, Azure IoT Edge, ou custom avec MQTT).
• Une stratégie de rollout progressif : canary sur 5 % de la flotte, validation métriques, puis déploiement complet. Si ça pète, rollback automatique.
• Un mécanisme de rollback robuste. Les devices doivent pouvoir revenir à la version N-1 sans intervention manuelle.

On a vu un projet bloquer pendant 3 mois parce qu'une mise à jour OTA défectueuse avait brické 40 % de la flotte, et qu'il a fallu envoyer des techniciens sur site pour reflasher manuellement. Coût : plusieurs dizaines de k€ en intervention + perte de service.

Observabilité par device

Vous devez savoir en temps réel l'état de chaque device : version déployée, CPU/RAM/disk, erreurs applicatives, connectivité réseau. Sans ça, vous déboguez à l'aveugle.

Stack type :

• Métriques système : Telegraf ou Prometheus node_exporter, remontée vers Victoria Metrics ou Prometheus central.
• Logs applicatifs : Fluent Bit en local, agrégation vers Loki ou CloudWatch. Avec sampling intelligent pour éviter de saturer le lien WAN.
• Alerting : basé sur des métriques critiques (device offline > 5 min, inférence rate < seuil, disk > 90 %).

L'erreur classique : monitorer uniquement l'applicatif et oublier la couche système. Résultat : vous découvrez que le device est en swap constant ou que le stockage est plein seulement quand tout plante.

Sécurité distribuée

Chaque device edge est une surface d'attaque. Surtout s'ils sont physiquement accessibles (magasins, entrepôts, sites industriels). Checklist minimale :

• Chiffrement au repos : full disk encryption (LUKS, dm-crypt).
• Authentification mutuelle : certificats TLS pour la communication device ↔ cloud.
• Patching automatique : des vulnérabilités OS sortent régulièrement, vous devez pouvoir patcher sans intervention.
• Principe de moindre privilège : les devices ne doivent avoir accès qu'aux ressources cloud strictement nécessaires (IAM policies ou équivalent).
• Signed artifacts : vérifiez les signatures des images/modèles avant déploiement pour éviter l'injection de code malveillant.

On a audité un projet où les devices utilisaient tous la même clé SSH hardcodée dans l'image. Un device compromis = toute la flotte compromise. Ne faites pas ça.

Quand ne PAS faire de l'edge

Parce que ce n'est pas toujours la bonne réponse. Quelques signaux qui doivent vous faire rester dans le cloud :

• Latence tolérable : si 200-500 ms de round-trip passent, le cloud est plus simple.
• Connectivité fiable : si vos sites ont de la fibre ou 4G/5G stable, l'argument offline tombe.
• Volumes faibles : quelques devices (< 20) ne justifient pas la mise en place d'une infra OTA complète.
• Équipe ops limitée : gérer du edge distribué demande des compétences DevOps/SRE. Si vous n'avez pas la bande passante, le cloud reste plus sûr.
• Budget contraint : le coût initial (hardware + dev infra OTA) est non négligeable. Si le ROI n'est pas clair, validez d'abord un PoC cloud.

L'edge ajoute de la complexité. Ne la payez que si un gain mesurable — en latence, en coûts réseau, en disponibilité — la justifie. Sinon, vous accumulez de la dette pour rien.

Checklist avant de se lancer

Si après tout ça vous êtes toujours convaincu que l'edge est la bonne option, voici les jalons à poser avant de scaler :

1. PoC sur 3-5 devices : validez la stack technique (hardware, runtime, modèle) et mesurez les perf réelles.
2. Automatisez le déploiement OTA : ne scalez pas sans ça. Testez rollout + rollback sur le PoC.
3. Mettez en place l'observabilité : métriques, logs, alerting. Validez que vous voyez ce qui se passe en prod.
4. Simulez une panne réseau : coupez le lien cloud et vérifiez que le device continue à fonctionner, puis resync correctement.
5. Testez la sécurité : pen test basique, vérifiez le chiffrement, les certificats, les policies IAM.
6. Documentez les runbooks : que fait-on si un device est offline ? Si une version pose problème ? Si le stockage sature ?

Une fois ces six points validés sur le PoC, vous pouvez scaler progressivement (10, 50, 200 devices). Mais pas avant.

Ce qu'on retient du terrain

L'edge computing est une vraie réponse technique quand la latence, la bande passante ou la disponibilité offline deviennent contraignantes. Mais c'est aussi un vrai défi opérationnel qu'il ne faut pas sous-estimer. Les projets qui réussissent sont ceux qui investissent dès le départ dans l'outillage OTA, l'observabilité et la sécurité — pas ceux qui se disent qu'ils optimiseront « plus tard ».

Si vous évaluez un projet edge et que vous voulez challenger l'architecture ou la roadmap ops avec des gens qui l'ont déjà fait en prod, [on est là pour ça](https://abbeal.com/contact). On préfère poser les bonnes questions en amont plutôt que déboguer une flotte briquée six mois après le go-live.