Topologies edge-to-cloud¶

Avant d'écrire une ligne de code backend, choisir la bonne topologie d'ingestion détermine la latence, le coût réseau et la résilience de l'ensemble du système.

Les trois patterns fondamentaux¶

Pattern 1 — Connexion directe (direct-to-cloud)¶

Chaque appareil ouvre une connexion persistante vers le broker cloud. C'est la topologie la plus simple : pas d'intermédiaire, pas de logique de routage à maintenir.

Quand l'utiliser : appareils connectés en permanence, réseau fiable (Wi-Fi, LTE), faible nombre de devices (< 500), données non critiques.

Limite principale : un pic de reconnexions simultanées (reboot secteur, coupure réseau) peut saturer le broker. Au-delà de quelques centaines de clients, le thundering herd devient un risque réel.

Pattern 2 — Gateway concentrateur¶

Une passerelle locale (Raspberry Pi, PC industriel, gateway dédiée) agrège les données de plusieurs capteurs et les transmet en un seul flux vers le cloud. Elle fait le pont entre des protocoles locaux (Modbus, OPC-UA, BACnet) et le protocole cloud (MQTT, AMQP, HTTP).

Quand l'utiliser : protocoles hétérogènes sur le terrain, réseau industriel isolé, normalisation des données requise avant envoi.

Limite principale : la gateway est un point de défaillance unique si elle n'est pas redondée. Sa gestion (firmware, certificats) s'ajoute à la charge opérationnelle.

Pattern 3 — Store-and-forward¶

La gateway stocke localement les données pendant les périodes de déconnexion et les transmet en différé dès que la liaison est rétablie. Elle garantit qu'aucune mesure n'est perdue, même sur une liaison satellite intermittente.

Quand l'utiliser : sites isolés (offshore, montagne, agriculture), liaisons à faible disponibilité (< 95 %), données à valeur réglementaire (traçabilité, qualité).

Limite principale : la gestion de l'ordre des événements lors du replay peut compliquer les traitements temps réel en aval.

Fog computing — quand traiter au bord¶

Le fog computing (ou edge computing au sens large) déplace une partie du traitement entre le capteur et le cloud. Plutôt que de tout envoyer, la gateway filtre, agrège et prend des décisions locales.

Cas d'usage typiques :

• Filtrage de bruit : un accéléromètre émet 1 000 points/s ; seule la variance sur 100 ms est utile.
• Pré-agrégation : envoyer min/max/moyenne sur 1 minute plutôt que 60 valeurs brutes réduit la bande passante de 60×.
• Détection locale d'anomalies : un modèle ML embarqué déclenche une alerte sans attendre le cloud.
• Actionnement sans latence réseau : couper une vanne en < 10 ms n'est possible qu'en local.

La règle pratique : traiter au plus près ce qui requiert une latence < 100 ms ou ce dont le volume réseau est prohibitif.

Architecture de référence 3-tiers¶

L'architecture industrielle standard distingue trois niveaux :

graph TB
    subgraph "Tier 1 — Terrain"
        S1[Capteur température]
        S2[Capteur pression]
        S3[Automate PLC]
        A1[Actionneur vanne]
    end

    subgraph "Tier 2 — Edge / Fog"
        GW[Gateway industrielle\nOPC-UA / Modbus bridge\nStore-and-forward\nML embarqué]
        LOCAL_DB[(Cache local\n24h de données)]
    end

    subgraph "Tier 3 — Cloud / Datacenter"
        BROKER[Broker MQTT\nEMQX cluster]
        STREAM[Bus événements\nKafka / Redpanda]
        TSDB[(Time-series DB\nInfluxDB / TimescaleDB)]
        PROC[Stream processor\nFlink / Kafka Streams]
        DASH[Grafana\nTableaux de bord]
        SI[ERP / MES / SCADA]
    end

    S1 -->|Modbus RTU| GW
    S2 -->|4-20 mA → ADC| GW
    S3 -->|OPC-UA| GW
    GW -->|MQTT TLS| BROKER
    GW <-->|Store-and-forward| LOCAL_DB
    GW -->|Actionnement| A1
    BROKER --> STREAM
    STREAM --> PROC
    STREAM --> TSDB
    PROC --> TSDB
    PROC --> DASH
    TSDB --> DASH
    PROC --> SI

Comparaison des topologies¶

Dimensionnement : quelques ordres de grandeur¶

Un site industriel de taille moyenne génère typiquement :

• 200 à 2 000 capteurs actifs
• 1 à 10 messages/capteur/seconde selon la criticité
• Soit 200 à 20 000 messages/seconde en pic

Un broker MQTT single-node (EMQX) tient ~100 000 connexions et ~1 million de messages/seconde sur un serveur 8 cœurs / 16 Go RAM. En dessous de 5 000 devices, une architecture single-node suffit ; au-delà, un cluster de 3 nœuds devient recommandé.

Choix d'une topologie en pratique¶

flowchart TD
    A{Réseau fiable\net permanent ?} -->|Non| B[Store-and-forward\nobligatoire]
    A -->|Oui| C{Protocoles\nterrain non-IP ?}
    C -->|Oui| D[Gateway concentrateur]
    C -->|Non| E{Volume > 500 devices\nou traitement local ?}
    E -->|Oui| D
    E -->|Non| F[Direct-to-cloud]
    B --> G{Volume réseau\nproblématique ?}
    G -->|Oui| H[Fog + compression\navant envoi]
    G -->|Non| I[Replay brut\nhorodaté]

Ce qu'il faut retenir¶

• Trois patterns couvrent 90 % des cas IoT industriels : direct, gateway, store-and-forward.
• Le fog computing n'est pas un luxe : il est indispensable dès que la latence ou le volume réseau le justifie.
• L'architecture 3-tiers (terrain / edge / cloud) est le modèle de référence industriel.

Chapitre suivant : Ingestion et messaging — scaler le broker MQTT et introduire Kafka comme bus d'événements.