Fleet management¶

Gérer dix devices manuellement est faisable ; gérer mille devices sans orchestration est impossible — le fleet management industrialise le cycle de vie complet de chaque appareil.

Le problème d'échelle¶

Un déploiement IoT démarre souvent modestement — vingt capteurs, une gateway, un serveur. Puis l'infrastructure grandit : 200 capteurs sur trois sites, 15 gateways, des smartphones de terrain, des tablettes de supervision. La gestion manuelle, qui fonctionnait en phase pilote, devient un gouffre opérationnel.

Sans outillage de fleet management, chaque opération banale devient un problème :

• Reconfiguration : changer l'adresse du broker MQTT sur tous les devices implique une connexion SSH manuelle sur chaque gateway, ou un accès physique à chaque capteur.
• Diagnostics : identifier quel device présente un problème nécessite de parcourir des dizaines de logs dispersés.
• Mises à jour : déployer un patch de sécurité sur 500 devices sans procédure automatisée prend plusieurs jours.
• Conformité : vérifier que tous les devices exécutent la bonne version du firmware est impossible sans inventaire centralisé.

Le fleet management répond à ces défis en établissant un jumeau numérique (device twin) pour chaque appareil et en offrant des primitives de gestion à l'échelle.

Cycle de vie d'un device¶

stateDiagram-v2
    [*] --> Fabrication : Commande / réception
    Fabrication --> Provisioning : Configuration initiale
    Provisioning --> Enregistrement : Certificat + identité
    Enregistrement --> Déploiement : Installation terrain
    Déploiement --> Actif : Premier heartbeat reçu
    Actif --> Maintenance : Anomalie détectée
    Maintenance --> Actif : Intervention terminée
    Actif --> MiseAJour : OTA déclenchée
    MiseAJour --> Actif : Mise à jour réussie
    MiseAJour --> Maintenance : Mise à jour échouée
    Actif --> Suspendu : Désactivation temporaire
    Suspendu --> Actif : Réactivation
    Actif --> Décommissionnement : Fin de vie
    Maintenance --> Décommissionnement : Non réparable
    Décommissionnement --> [*] : Certificats révoqués, données archivées

Provisioning zero-touch¶

Le provisioning zero-touch permet de configurer un device sans aucune interaction manuelle lors de son premier démarrage sur site. Le device se connecte, s'authentifie, et reçoit automatiquement sa configuration complète.

Mécanisme de provisioning par certificat X.509¶

Le workflow standard pour les gateways Linux et les MCU connectés :

Phase manufacture (usine ou entrepôt)

1. Générer une paire de clés asymétriques sur le device (idéalement dans un TPM ou un élément sécurisé)
2. Créer une Certificate Signing Request (CSR) contenant l'identifiant de l'appareil (numéro de série, MAC address)
3. Signer la CSR avec la CA de l'entreprise → certificat device
4. Enregistrer le certificat dans le serveur de fleet management
5. Graver le certificat et la clé privée sur le device (stockage sécurisé)

Phase déploiement (terrain)

1. Le device démarre et se connecte au réseau
2. Il contacte le point de provisioning (DPS — Device Provisioning Service) via MQTT TLS
3. Le DPS vérifie le certificat (signé par la CA connue)
4. Le DPS renvoie la configuration initiale : endpoint MQTT de production, configuration réseau, paramètres applicatifs
5. Le device s'enregistre auprès du fleet management et commence à reporter son état

# Extrait : client de provisioning sur une gateway Linux
import ssl
import paho.mqtt.client as mqtt
import json

def provision_device(device_id: str, cert_path: str, key_path: str, ca_path: str):
    """
    Connexion au service de provisioning et récupération de la config initiale.
    Le device s'authentifie par certificat client X.509.
    """
    client = mqtt.Client(client_id=device_id, protocol=mqtt.MQTTv5)

    # Authentification mutuelle TLS
    client.tls_set(
        ca_certs=ca_path,
        certfile=cert_path,
        keyfile=key_path,
        tls_version=ssl.PROTOCOL_TLS_CLIENT
    )

    received_config = {}

    def on_message(client, userdata, msg):
        nonlocal received_config
        received_config = json.loads(msg.payload)
        print(f"[PROVISION] Config reçue : {received_config}")
        client.disconnect()

    def on_connect(client, userdata, flags, rc, properties):
        # S'abonner au topic de réponse avant de publier la demande
        client.subscribe(f"provision/response/{device_id}")
        client.publish(f"provision/request", json.dumps({
            "device_id": device_id,
            "firmware_version": "2.3.1",
            "hardware_revision": "B"
        }))

    client.on_connect = on_connect
    client.on_message = on_message
    client.connect("dps.industrial.local", 8883)
    client.loop_forever(timeout=30.0)
    return received_config

Device twins et desired state¶

Le concept de device twin (jumeau de device) est central dans les plateformes de fleet management modernes (AWS IoT Core, Azure IoT Hub, Thingsboard). Il représente l'état d'un device sous deux faces :

• Reported state : l'état tel que le device le rapporte actuellement (firmware installé, température CPU, configuration active, connectivité)
• Desired state : l'état que l'opérateur souhaite atteindre (firmware cible, configuration souhaitée, paramètres de reporting)

Le fleet management réconcilie en permanence ces deux états. Si un device est hors ligne, le desired state est mis en attente et appliqué dès la reconnexion.

{
  "device_id": "gateway-usine-nord-07",
  "reported": {
    "firmware_version": "2.3.0",
    "config_hash": "a3f8c2d1",
    "uptime_s": 1847203,
    "cpu_temp_c": 52.3,
    "memory_free_mb": 892,
    "mqtt_broker": "mqtt-prod-01.industrial.local:8883",
    "reporting_interval_s": 60,
    "connected_devices": 47,
    "last_seen": "2026-04-15T09:12:33Z"
  },
  "desired": {
    "firmware_version": "2.4.0",
    "config_hash": "b5e9d4f2",
    "reporting_interval_s": 30,
    "mqtt_broker": "mqtt-prod-02.industrial.local:8883"
  },
  "delta": {
    "firmware_version": "2.3.0 → 2.4.0",
    "config_hash": "a3f8c2d1 → b5e9d4f2",
    "reporting_interval_s": "60 → 30"
  }
}

Le device souscrit à son topic de desired state et applique les changements de configuration dès réception. Si le changement implique une mise à jour firmware, il déclenche le processus OTA (voir chapitre suivant).

Groupes et politiques¶

Un fleet manager industriel ne gère pas les devices un par un — il les organise en groupes et applique des politiques à ces groupes.

Taxonomie de groupes¶

graph TD
    ROOT[Flotte globale\n1 247 devices] --> SITE1[Site Usine Nord\n412 devices]
    ROOT --> SITE2[Site Usine Sud\n387 devices]
    ROOT --> SITE3[Site Logistique\n448 devices]

    SITE1 --> GW1[Gateways\n18 devices]
    SITE1 --> SENS1[Capteurs\n347 devices]
    SITE1 --> MOBILE1[Mobiles terrain\n47 devices]

    GW1 --> GW_PROD[Gateways production\n12 devices]
    GW1 --> GW_UTIL[Gateways utilités\n6 devices]

    GW_PROD --> CANARY[Canary group\n1 device\npour tests OTA]
    GW_PROD --> STABLE[Stable group\n11 devices]

Politiques de groupe¶

Chaque groupe porte une politique qui définit :

• La version firmware cible
• L'intervalle de reporting
• La retention des logs locaux
• Les règles d'alerte spécifiques au groupe
• Les plages de maintenance autorisées (fenêtres de mise à jour)

# Politique appliquée au groupe "Gateways production — Usine Nord"
group_id: gw-prod-usine-nord
firmware:
  target_version: "2.4.0"
  update_window:
    - weekday: saturday
      time_utc: "02:00–04:00"
  rollout:
    canary_pct: 10     # 10 % des devices d'abord
    canary_wait_h: 48  # attendre 48 h avant rollout complet
    auto_rollback_on_error_rate: 5  # rollback si > 5 % d'erreurs

reporting:
  interval_s: 30
  heartbeat_interval_s: 60

alerts:
  cpu_temp_threshold_c: 75
  memory_free_min_mb: 200
  device_silence_timeout_min: 5

Tableaux de bord d'état de flotte¶

Un bon fleet manager expose une vue d'état synthétique qui répond à la question de l'opérateur : "est-ce que tout va bien, et si non, où est le problème ?"

Outils de fleet management open-source et commerciaux¶

Ce qu'il faut retenir¶

• Le device twin est l'abstraction centrale du fleet management : il sépare l'état reported (réel) du desired state (souhaité) et gère la réconciliation automatique.
• Le provisioning zero-touch par certificat X.509 est la base sécurisée pour l'enregistrement automatique de devices à grande échelle.
• Les groupes et politiques permettent d'appliquer des configurations et des stratégies de mise à jour à des centaines de devices en une seule opération.
• Le cycle de vie complet (fabrication → provisioning → déploiement → maintenance → décommissionnement) doit être tracé dans le fleet manager.

Chapitre suivant : Mises à jour OTA — déployer des firmwares en production sans couper le service ni risquer de bricker des devices terrain.