Choisir son protocole IoT¶

Une matrice de décision structurée, trois cas d'usage industriels réels et un arbre de décision visuel : tout ce qu'il faut pour justifier un choix de protocole dès la phase de conception.

Pourquoi le choix de protocole est une décision d'architecture¶

Un protocole mal choisi coûte cher : refonte firmware, remplacement de hardware radio, infrastructure réseau incompatible. Ce choix engage toute la durée de vie du produit (souvent 10–15 ans en industrie). Il doit intégrer simultanément des contraintes physiques (portée, énergie), opérationnelles (infrastructure, coût), techniques (débit, latence) et réglementaires (certification radio, sécurité).

Matrice de décision multi-critères¶

La matrice ci-dessous note chaque protocole de 1 (mauvais) à 5 (excellent) pour chaque critère. Les critères sont pondérés selon les priorités typiques d'un projet IoT industriel.

¹ Dépend de l'infrastructure réseau IP sous-jacente. ² MQTT seul, sans TLS.

Le score agrégé ne suffit pas : il faut identifier les critères éliminatoires avant d'utiliser la matrice. Un score global élevé ne compense pas un critère rédhibitoire (ex : portée insuffisante).

Arbre de décision¶

flowchart TD
    A{Portée nécessaire ?} -->|< 100 m| B{Temps réel < 10 ms ?}
    A -->|100 m – 10 km| C{Infrastructure privée ?}
    A -->|> 10 km| D{Débit > 1 kbit/s ?}

    B -->|Oui| B1{Bus ou embarqué ?}
    B -->|Non| B2{Mesh nécessaire ?}
    B1 -->|Bus câblé| CAN[CAN FD\nEtherCAT\nPROFINET IRT]
    B1 -->|Sans fil| BLE[BLE 5.x\nZigbee]
    B2 -->|Oui| MESH[Zigbee / Thread\n+ Matter]
    B2 -->|Non| MQTT2[MQTT / CoAP\nsur Wi-Fi / Ethernet]

    C -->|Oui| LORA[LoRaWAN privé\nChirpStack]
    C -->|Non| C2{Payload < 12 B ?}
    C2 -->|Oui| SFX[Sigfox]
    C2 -->|Non| C3{Mobilité ?}
    C3 -->|Oui| LTM[LTE-M]
    C3 -->|Non| NBIOT[NB-IoT]

    D -->|Oui| D1{Abonnement opérateur OK ?}
    D -->|Non| LORA2[LoRaWAN\nSF12]
    D1 -->|Oui| LTM2[LTE-M]
    D1 -->|Non| LORA3[LoRaWAN longue portée]

    style CAN fill:#1b4332,color:#fff
    style BLE fill:#2d6a4f,color:#fff
    style MESH fill:#2d6a4f,color:#fff
    style MQTT2 fill:#40916c,color:#fff
    style LORA fill:#40916c,color:#fff
    style SFX fill:#52b788,color:#fff
    style NBIOT fill:#52b788,color:#fff
    style LTM fill:#74c69d,color:#fff
    style LORA2 fill:#74c69d,color:#fff
    style LTM2 fill:#95d5b2,color:#fff
    style LORA3 fill:#95d5b2,color:#fff

Cas d'usage 1 — Monitoring agricole¶

Contexte¶

Réseau de 500 capteurs de sol (humidité, température, conductivité) déployés sur 1 200 ha. Alimentation exclusivement sur batterie (pile AA, 2 ans minimum). Relevé toutes les 15 minutes. Pas d'infrastructure cellulaire fiable. Coût matériel critique (< 20 € par nœud).

Analyse des contraintes¶

Choix : LoRaWAN privé (SF9, BW 125 kHz)¶

Justification :

• Portée : SF9 couvre 5–8 km en terrain dégagé (champs) avec un gain d'antenne de 3 dBi.
• Énergie : transmission de 50 octets en SF9 ≈ 144 ms ToA. Avec un courant TX de 40 mA et une veille à 2 µA, la consommation annuelle est ≈ 200 mWh → 3+ ans sur AA.
• Coût : module LoRa (ex : RAK3172) ≈ 4 €. 2 gateways LoRaWAN (couverture 10 km) ≈ 400 € chacune, amorties sur 500 nœuds = 1,6 €/nœud. Total nœud : < 15 €.
• Infrastructure : ChirpStack open-source sur Raspberry Pi à la ferme. Aucun abonnement opérateur.

Alternatives écartées :

• Sigfox : dépendance opérateur, 140 messages/jour max (OK ici) mais couverture agricole non garantie.
• NB-IoT : couverture rurale insuffisante, coût module + SIM élevé.

Architecture déployée :

graph LR
    A["500 × STM32WL<br/>(LoRa)"] --> B["2 × Gateway<br/>LoRaWAN"] --> C["ChirpStack<br/>(RPi)"] --> D["InfluxDB"] --> E["Grafana"]

Cas d'usage 2 — Domotique industrielle (bâtiment)¶

Contexte¶

Immeuble de bureaux de 10 000 m², 400 points de contrôle (éclairage, stores, thermostats, détecteurs de présence, serrures). Équipements de marques multiples (Somfy, Philips Hue, Schneider, Yale). Exigence : interopérabilité garantie, contrôle via application mobile (iOS et Android), fonctionne en local sans cloud.

Analyse des contraintes¶

Choix : Matter sur Thread¶

Justification :

• Interopérabilité : Matter est le seul standard signé par Apple, Google, Amazon et Samsung simultanément. Les 400 points de contrôle de marques différentes seront certifiés Matter d'ici 2025–2026.
• Local first : Matter fonctionne en local via Thread Border Router (HomePod mini, Nest Hub, hub Schneider). Aucune dépendance cloud.
• Thread : mesh IPv6 auto-guérissant, couverture 10 000 m² avec ~30 routeurs secteur (thermostats, interrupteurs). Capteurs batterie en Sleepy End Device (années d'autonomie).
• Sécurité : CASE (certificats X.509 par device) dépasse largement Zigbee/Z-Wave.
• Mobile : Apple Home, Google Home, Samsung SmartThings nativement compatibles Matter.

Alternatives écartées :

• Zigbee 3.0 : viable mais pas IP-natif, fragmentation historique des profils, Matter le remplace progressivement.
• Z-Wave : limite à 232 nodes (insuffisant pour 400 points), propriétaire Silicon Labs.
• KNX : câblage dédié coûteux, non adapté à la rénovation.

Architecture déployée :

graph LR
    A["400 × Devices Matter<br/>(Thread)"] --> B["4 × Thread Border<br/>Router (hubs)"] --> C["App Matter"] --> D["Local réseau<br/>IP bâtiment"]

Cas d'usage 3 — Usine (temps réel, SCADA existant)¶

Contexte¶

Ligne d'assemblage automobile : 80 PLC/variateurs Siemens et Beckhoff existants (Modbus RTU + PROFINET), SCADA Ignition en place. Projet Industrie 4.0 : exposer les données de production en temps réel au MES (Manufacturing Execution System) et permettre la supervision distante sécurisée depuis le siège.

Analyse des contraintes¶

Choix : OPC-UA + Modbus TCP (passerelle)¶

Justification :

• Compatibilité ascendante : les PLCs Siemens exposent nativement OPC-UA (S7-1500 depuis TIA Portal V14). Les équipements legacy Modbus RTU sont encapsulés via passerelles Modbus RTU→TCP→OPC-UA (ex : ProSoft, Kepware).
• Sécurité : OPC-UA avec mode Sign & Encrypt (AES-256) + certificats X.509. Le pare-feu n'expose que le port OPC-UA (4840) vers le DMZ. Le SCADA Ignition supporte OPC-UA nativement.
• Modèle d'information : OPC-UA modélise les données avec leur contexte (unités, limites d'alarme, type) — le MES reçoit des données signifiantes, pas des registres bruts.
• Pub/Sub vers MES : OPC-UA Pub/Sub sur MQTT (broker EMQX en DMZ) — le MES s'abonne aux topics de production sans polling.

Alternatives écartées :

• Modbus TCP seul vers MES : aucune sécurité, aucun modèle d'information, polling uniquement.
• REST/JSON custom : développement coûteux, pas standardisé, maintenance longue durée.
• MQTT seul : pas de modèle d'information natif (Sparkplug B serait l'alternative viable).

Architecture déployée :

graph LR
    subgraph OT Réseau isolé
        PLC1[PLC S7-1500\nOPC-UA natif] --> GW[OPC-UA Server\nKepware]
        PLC2[PLC Beckhoff\nOPC-UA natif] --> GW
        MOD[Capteurs\nModbus RTU] --> BRIDGE[Passerelle\nModbus→OPC-UA]
        BRIDGE --> GW
    end

    subgraph DMZ industrielle
        GW --> SCADA[SCADA Ignition\nOPC-UA Client]
        GW --> BROKER[EMQX Broker\nOPC-UA Pub/Sub]
    end

    subgraph IT Réseau entreprise
        BROKER --> MES[MES\nSubscribe MQTT]
        SCADA --> MES
        MES --> ERP[ERP SAP]
    end

Tableau récapitulatif des cas d'usage¶

Ce qu'il faut retenir¶

• Il n'existe pas de protocole universel : chaque cas d'usage a un ensemble de contraintes qui éliminent la majorité des options avant même d'évaluer les critères secondaires.
• La portée et la consommation sont les deux critères éliminatoires les plus fréquents — commencer par eux.
• LoRaWAN domine le monitoring outdoor longue portée sur batterie ; Matter/Thread s'impose pour la domotique multi-marques ; OPC-UA est le standard incontournable pour l'intégration Industrie 4.0.
• Un déploiement hybride est souvent la bonne réponse : CoAP sur le réseau de capteurs, MQTT comme backbone, OPC-UA vers le SCADA/MES.

Chapitre suivant : Edge, gateway & flottes — du traitement local à la gestion de milliers de devices.