Guide de choix de plateforme¶

La meilleure plateforme n'existe pas en absolu — elle se définit toujours par rapport aux contraintes d'un projet précis, que cette matrice de décision vous aide à rendre explicites.

Pourquoi formaliser le choix¶

Les projets IoT échouent rarement à cause d'un mauvais capteur ou d'un bug firmware corrigible. Ils échouent parce que la plateforme choisie en phase de prototype s'avère inadaptée à la production :

• Le Raspberry Pi 4 en prototype est remplacé en production par le CM4... après 6 mois de retravail de la carrier board.
• L'ESP32 sélectionné pour son Wi-Fi intégré s'avère en rupture d'approvisionnement 18 mois plus tard.
• Le STM32F4 choisi pour sa puissance de calcul consomme 10× trop pour l'autonomie batterie requise.

Une matrice de décision formalisée dès la phase de spécification force l'équipe à prioriser les critères avant qu'ils ne deviennent des contraintes subies.

Les critères de décision¶

Critères techniques¶

Critères industriels / business¶

Matrice de décision pondérée¶

La matrice attribue une note de 1 à 5 à chaque plateforme pour chaque critère, multipliée par le poids du critère.

Grille de notation (exemple générique)¶

Score total pondéré :

ESP32-S3  : 5×5 + 3×4 + 5×4 + 3×3 + 2×4 + 5×3 + 4×3 = 25+12+20+9+8+15+12 = 101
STM32F4   : 3×5 + 4×4 + 1×4 + 5×3 + 5×4 + 4×3 + 1×3 = 15+16+4+15+20+12+3 = 85
nRF52840  : 2×5 + 5×4 + 4×4 + 4×3 + 4×4 + 3×3 + 4×3 = 10+20+16+12+16+9+12 = 95
RPi CM4   : 1×5 + 1×4 + 3×4 + 1×3 + 2×4 + 5×3 + 3×3 = 5+4+12+3+8+15+9  = 56

Cette matrice est un outil de discussion, pas un oracle. Les poids changent selon le projet — et c'est là tout son intérêt.

Cas d'usage 1 — Capteur agricole autonome sur batterie¶

Contexte¶

Réseau de 500 nœuds de mesure déployés dans des parcelles agricoles. Mesure : température sol, humidité sol, luminosité. Remontée des données toutes les 15 minutes. Alimentation sur batterie Li-SOCl2 (Lithium-Thionyle Chlorure, non rechargeable, haute densité d'énergie). Durée de vie minimale : 5 ans sans maintenance.

Contraintes¶

• Courant moyen < 20 µA pour atteindre 5 ans sur 3,6 Ah (120 µAh/an, soit ~13,7 µA en moyenne)
• Portée radio : 2–15 km selon terrain agricole
• Coût cible BOM : < 25 € en volume 5 000 pièces
• Température : -20°C à +60°C en extérieur

Choix argumenté : nRF52832 + module LoRa SX1262¶

Le Wi-Fi est éliminé dès le départ : son courant d'émission (100 mA+) est incompatible avec 5 ans de batterie. Le BLE seul ne couvre pas la portée requise en champ ouvert.

Architecture retenue :

• MCU : nRF52832 (Cortex-M4F, 64 MHz, BLE 5.0)
• Radio LoRa : SX1262 en SPI, piloté par le nRF
• Capteurs : BME280 (T/H/P), DS18B20 (T sol), BH1750 (luminosité)
• MCU en deep sleep 99,8 % du temps (réveil toutes les 15 min)

Calcul d'autonomie simplifié :

• Phase active (acquisition + LoRa TX) : 15 mA × 2 s = 8,3 µAh
• Deep sleep 15 min : 1,5 µA × 0,25 h = 0,375 µAh
• Courant moyen : 8,3/0,25 + 1,5 ≈ 35 µA → batterie 5 Ah → 5,7 ans

Résumé du cas 1¶

Cas d'usage 2 — Gateway d'usine multi-protocole¶

Contexte¶

Gateway industrielle dans une usine automobile. Doit agréger des données de 50 équipements via Modbus RTU, 10 équipements via Profibus DP (adaptateur), et 5 robots via EtherNet/IP. Publie vers un broker MQTT sur le réseau de production. Exécute des règles de pré-traitement locales. Mise à jour OTA via Balena Cloud.

Contraintes¶

• Multi-protocole : Modbus, MQTT, HTTP, Profibus via adaptateur
• Calcul local (règles, agrégation) : Python ou Node-RED
• Alimentation 24 V DC DIN Rail
• Temperature : 0°C à +55°C (armoire électrique non climatisée)
• Disponibilité : 99,5 % (maximum 44 h d'arrêt/an)

Choix argumenté : Raspberry Pi CM4 + carrier board industrielle¶

Un MCU est insuffisant : la pile réseau complète, TLS, le moteur de règles Python et la mise à jour OTA nécessitent Linux. L'ESP32 et le STM32 sont éliminés.

Architecture retenue :

• SBC : Raspberry Pi CM4 (4 Go RAM, 32 Go eMMC, module Lite sans Wi-Fi pour réduire les interférences)
• Carrier board : conçue sur mesure ou basée sur Waveshare CM4-NANO-B (DIN Rail, 9–28 V)
• OS : Raspberry Pi OS Lite + Balena OS pour la gestion de flotte
• Interfaces : 2 × RS-485 (MAX485), 1 × Ethernet Gigabit, 1 × mini PCIe pour carte Profibus
• Stockage : SSD NVMe 64 Go via adaptateur PCIe (fiabilité supérieure à l'eMMC)

Résumé du cas 2¶

Cas d'usage 3 — Contrôle moteur temps réel¶

Contexte¶

Système d'enroulage précis pour l'industrie textile. Contrôle en boucle fermée de 3 axes servo DC brushless. Fréquence de boucle de contrôle : 5 kHz (jitter max ±2 µs). Communication avec un superviseur PC via EtherCAT. Interface opérateur via écran TFT 4".

Contraintes¶

• Temps réel dur : boucle de contrôle 5 kHz, jitter < ±2 µs garanti
• Calcul DSP : filtre PID 3 axes, Clarke/Park transforms (FOC)
• Interface haute vitesse : encodeurs incrémentaux 10 000 imp/tr, 3 axes
• Certification : IEC 61800-5-1 (sécurité des entraînements électriques)

Choix argumenté : STM32F446RE + RTOS FreeRTOS¶

Linux est totalement exclu : pas de temps réel dur garanti. L'ESP32 a un jitter trop élevé en mode Wi-Fi. Le STM32F4 avec son FPU Cortex-M4 et ses timers haute résolution est parfaitement adapté.

Architecture retenue :

• MCU principal : STM32F446RE (Cortex-M4F 180 MHz, FPU, DSP)
• RTOS : FreeRTOS avec tâche contrôle à priorité maximale, pinned sur un cœur
• Timers : TIM1/TIM8 en mode encoder pour les 3 axes ; TIM2 pour la boucle de contrôle à 5 kHz
• Communication EtherCAT : carte EtherCAT ET1100 (Beckhoff) en SPI
• Écran TFT : SSD1963 via FSMC (mémoire externe) pour rafraîchissement sans charge CPU

Garantie temps réel :

Période interruption TIM2 = 1/5000 = 200 µs
Durée ISR (PID 3 axes + FOC) = ~15 µs @ 180 MHz
Marge disponible = 185 µs = 92,5 %
Jitter interruption STM32 (NVIC latence) = 12 cycles = 67 ns → << 2 µs ✓

Résumé du cas 3¶

Tableau récapitulatif des 3 cas¶

Processus de sélection en entonnoir¶

flowchart TD
    A["Spécification projet\n(besoins fonctionnels et non-fonctionnels)"] --> B["Filtre 1 — Éliminatoires\nTemps réel dur ? Alimentation batterie ?\nOS Linux requis ?"]
    B --> C["Filtre 2 — Connectivité\nWi-Fi / BLE / LoRa / Cellular / Ethernet"]
    C --> D["Filtre 3 — Contraintes supply chain\nVolume, second source, LTB, certifications"]
    D --> E["Filtre 4 — Coût total\nBOM + NRE + coût développement"]
    E --> F["Matrice de décision pondérée\nScore sur critères priorisés par le projet"]
    F --> G["Prototype de validation\nBenchmark sur les points critiques"]
    G --> H{"Critères de GO\nvalidés ?"}
    H -->|Oui| I["Plateforme sélectionnée\nGelée pour la production"]
    H -->|Non| D

    style I fill:#2d8a4e,color:#fff

Ce qu'il faut retenir¶

• La matrice de décision pondérée doit être construite par l'équipe projet, pas copiée depuis un article de blog : les poids reflètent les priorités du projet, pas des vérités universelles.
• Les contraintes éliminatoires (temps réel dur → pas de Linux ; batterie longue durée → pas de Wi-Fi) filtrent la liste avant même la matrice.
• Le coût total n'est pas le BOM seul : le coût de développement (maturité SDK, courbe d'apprentissage) représente souvent 3 à 10× le coût matériel sur la durée du projet.
• Valider la plateforme sur un prototype ciblant les points de risque technique (latence, consommation, thermique) avant de geler l'architecture.

Chapitre suivant : Développement firmware — de l'environnement de développement au binaire déployé.