Pourquoi l'Edge AI, plutôt que le cloud

La question n'est pas idéologique. Trois cas justifient l'inférence locale : la latence (sous les 50 ms, le réseau est trop lent), la confidentialité (la donnée ne doit pas sortir du capteur), et l'autonomie (le produit fonctionne hors couverture). Si aucune de ces conditions n'est réunie, le cloud reste plus simple et plus puissant.

Les ordres de grandeur honnêtes

Sur un STM32 Cortex-M4 à 80 MHz, on peut faire tourner un réseau quantifié de quelques centaines de kilo-paramètres pour de la classification simple — détection de mot-clé, anomalie sur série temporelle, gesture sensing. Au-delà, il faut basculer sur un M7 / H7 ou un ESP32-S3 qui dispose de SIMD, voire un NPU dédié.

La pipeline qu'on suit

  • Collecte. On capture des données représentatives sur le matériel cible, pas en simulation.
  • Étiquetage. En interne ou via un partenaire, avec une grille de qualité tracée.
  • Entraînement. En général TensorFlow ou PyTorch, modèle déjà conçu pour la quantification (QAT).
  • Conversion. Vers TFLite Micro, ONNX Runtime embarqué ou STM32Cube.AI selon la cible.
  • Intégration. Le moteur d'inférence devient un module C avec une API stricte ; le firmware applicatif l'appelle comme n'importe quel driver.
  • Validation. On compare la sortie embarquée à la sortie référence Python sur le même jeu, à la dérivée près de la quantification.

Les pièges qu'on évite

Le premier : oublier que la mémoire flash et la RAM sont finies. Un modèle de 800 ko en float32 ne rentre pas dans un MCU à 256 ko de RAM — il faut quantifier en int8, parfois plus bas, et valider que la précision tient.

Le deuxième : confondre inference time et cycle time. L'inférence sur 100 ms ne signifie pas qu'on peut classifier à 10 Hz : il reste l'acquisition, le pré-traitement, la communication. Sur certains projets, le pré-traitement coûte plus cher que l'inférence elle-même.

Le troisième : déployer un modèle qui marche en labo et plante en prod sur des données légèrement différentes. C'est un défaut de jeu d'entraînement, pas un défaut du modèle. Il faut prévoir une boucle de remontée de données dès le déploiement, pour réentraîner à froid.

En conclusion

L'Edge AI sur MCU n'est pas magique : c'est de l'ingénierie classique avec une couche de plus. La bonne nouvelle, c'est que pour un nombre croissant de cas d'usage industriels, les performances suffisent largement, et le coût total — capteur + traitement local — devient inférieur au coût d'un capteur connecté au cloud.

Si vous avez un projet où l'inférence locale a du sens, écrivez-nous. Le premier échange consiste souvent à clarifier si l'Edge AI est réellement la bonne réponse, et sinon à le dire franchement.