Zephyr vs FreeRTOS vs Linux : quel OS pour votre application temps réel ?

« Temps réel » est l’un des termes les plus utilisés — et les plus mal compris — de l’ingénierie embarquée. Quand un directeur technique demande un système temps réel, il peut vouloir dire qu’un airbag doit se déclencher en moins de 10 millisecondes, qu’un flux vidéo ne doit pas saccader, ou simplement qu’un capteur IoT doit répondre « assez vite ». Ces trois situations appellent des solutions radicalement différentes.

Le choix du système d’exploitation est une décision structurante qui impacte le coût du produit, sa fiabilité, sa consommation énergétique, sa capacité à évoluer et son time-to-market. Trois options dominent le paysage : Zephyr RTOS, le choix moderne porté par la Linux Foundation ; FreeRTOS, le standard établi déployé sur des milliards de dispositifs ; et Linux avec PREEMPT_RT, quand il faut combiner temps réel et richesse applicative.

Chez AESTECHNO, nous concevons des systèmes embarqués industriels depuis plus de 10 ans. Nous avons déployé Zephyr sur des capteurs IoT BLE basse consommation en production, et nous développons des BSP Linux custom sur plateformes Jetson pour du traitement vidéo temps réel. Nous concevons le hardware et le logiciel — cette double compétence nous permet d’optimiser le système dans son ensemble. Cet article vous donne les clés pour choisir le bon OS selon votre contexte.

Qu’est-ce que le temps réel en embarqué ?

Le temps réel en informatique embarquée désigne la capacité d’un système à garantir une réponse dans un délai borné et prédictible, indépendamment de la charge du système. Ce n’est pas une question de vitesse brute : c’est une question de déterminisme. Un système qui répond en moyenne en 1 µs mais occasionnellement en 50 ms n’est pas temps réel. Un système qui répond toujours en moins de 100 µs, même dans le pire cas, l’est.

Hard real-time (temps réel dur) : un dépassement de délai constitue une défaillance du système. Les conséquences peuvent être catastrophiques : airbags, contrôle moteur, dispositifs médicaux de maintien en vie, systèmes de freinage. Le pire cas est la seule métrique qui compte.

Soft real-time (temps réel souple) : un dépassement de délai dégrade les performances sans provoquer de défaillance critique. Exemples : streaming audio/vidéo, interfaces utilisateur, télémétrie. On tolère un glitch occasionnel, mais pas un comportement systématiquement dégradé.

« Assez rapide » (non temps réel) : le système doit répondre dans un temps raisonnable, mais sans garantie stricte. La plupart des capteurs IoT, passerelles et systèmes de monitoring entrent dans cette catégorie. Un capteur qui remonte une mesure toutes les 10 secondes n’a pas besoin d’un RTOS.

Latence vs déterminisme : un processeur rapide ne garantit pas le temps réel. Un Cortex-A à 2 GHz sous Linux standard peut avoir des pics de latence de plusieurs millisecondes à cause du garbage collector, de la pagination mémoire ou d’un driver réseau. Un Cortex-M à 64 MHz sous Zephyr peut garantir une réponse en moins de 10 µs, à chaque fois.

Le jitter — l’ennemi du temps réel : le jitter mesure la variation du temps de réponse entre deux exécutions. En contrôle moteur, un jitter de 100 µs sur une boucle à 10 kHz provoque des vibrations mécaniques. En audio, un jitter de quelques millisecondes produit des craquements audibles. Dans un système temps réel, c’est le pire cas qui dimensionne le système, pas la moyenne.

Zephyr RTOS : le choix moderne pour l’IoT industriel

Zephyr est un système d’exploitation temps réel open source gouverné par la Linux Foundation, conçu pour les microcontrôleurs et les dispositifs embarqués à ressources contraintes. Avec un support natif pour plus de 500 cartes, des piles de communication intégrées (BLE, Thread, Matter, LoRaWAN) et un footprint minimal de 8 Ko de RAM, Zephyr s’est imposé comme la plateforme de référence pour les produits IoT modernes.

Architecture et ordonnancement :

• Scheduler préemptif à priorités : les tâches critiques interrompent immédiatement les tâches de moindre priorité
• Gestion déterministe des interruptions : latence d’interruption mesurable et bornée
• Tickless idle : le timer système ne génère pas d’interruptions inutiles — économie d’énergie maximale
• Power management natif : modes System OFF, suspend-to-RAM, intégrés dans le framework

Écosystème et connectivité :

• BLE 5.x intégré : stack Bluetooth complet avec profiles GATT, maillage Bluetooth
• Thread et Matter : les protocoles domotique/IoT de nouvelle génération, supportés nativement
• LoRaWAN : pour les réseaux longue portée basse consommation
• Support hardware : Nordic nRF (nRF52, nRF53, nRF54), STM32, NXP, ESP32, Intel, et bien d’autres
• Build system : CMake + west + devicetree — approche structurée et reproductible

Certification et sécurité :

• Certification-ready pour IEC 61508 (sécurité fonctionnelle industrielle) et ISO 26262 (automobile)
• MCUboot pour le secure boot et les mises à jour OTA signées
• TF-M (Trusted Firmware-M) pour les architectures ARM TrustZone

Limites à connaître :

• Courbe d’apprentissage plus raide que FreeRTOS : le build system (west, devicetree, Kconfig) demande un investissement initial
• API en évolution rapide : des breaking changes entre versions majeures nécessitent un effort de migration
• Communauté en croissance mais plus jeune que celle de FreeRTOS
• Support limité pour les MCU 16-bit et les architectures très anciennes

Notre expérience chez AESTECHNO : nous avons déployé Zephyr en production sur des capteurs IoT BLE basse consommation, avec des objectifs d’autonomie sur batterie de plusieurs années. La combinaison du scheduler tickless, de la pile BLE intégrée et du power management natif nous a permis de tenir ces objectifs sans recourir à des composants logiciels tiers. Nous accompagnons nos clients sur l’ensemble de la chaîne : choix du MCU, portage Zephyr, développement firmware, et conception de la carte électronique.

FreeRTOS : le standard établi de l’embarqué

FreeRTOS est le RTOS le plus déployé au monde, avec un écosystème mature et une simplicité qui en fait le point d’entrée naturel pour la plupart des projets embarqués temps réel. Soutenu par Amazon (AWS) depuis 2017, il offre un noyau minimaliste — tâches, files d’attente, sémaphores, timers — qui fonctionne sur pratiquement n’importe quel microcontrôleur 32 bits, et même certains 16 bits.

Architecture et footprint :

• Noyau ultra-léger : 6 à 10 Ko de ROM, moins de 1 Ko de RAM par tâche
• Scheduler préemptif ou coopératif : configurable selon les besoins
• Portabilité extrême : plus de 40 architectures supportées (Cortex-M, RISC-V, AVR, PIC, Xtensa…)
• API stable : le code écrit il y a 10 ans compile encore aujourd’hui

Écosystème AWS et extensions :

• FreeRTOS+TCP : pile TCP/IP intégrée pour la connectivité réseau
• coreMQTT, coreHTTP : bibliothèques certifiées pour la communication cloud
• AWS IoT Device SDK : intégration directe avec les services AWS (IoT Core, Greengrass, Device Shadow)
• FreeRTOS+CLI : interface en ligne de commande pour le debug
• SafeRTOS : version certifiée IEC 61508 SIL 3, développée par WITTENSTEIN

Limites à connaître :

• Pas de stack BLE intégré : il faut recourir à des stacks tiers (NimBLE, vendor SDK) ou au stack propriétaire du fondeur
• Pas de Thread ni Matter : les protocoles IoT modernes ne sont pas supportés nativement
• Pas de devicetree : la configuration hardware est manuelle, souvent liée au HAL du fondeur (STM32 HAL, nRF SDK…)
• Écosystème fragmenté : chaque fondeur fournit sa propre couche d’abstraction hardware, ce qui rend le portage entre plateformes coûteux
• Fonctionnalités réseau limitées : FreeRTOS+TCP est fonctionnel mais moins complet qu’un stack Linux

Quand choisir FreeRTOS : pour une boucle de contrôle temps réel simple et bien définie sur un MCU à ressources très contraintes. Pour un projet qui cible l’écosystème AWS IoT. Pour un produit où la stabilité de l’API et la maturité de la communauté sont prioritaires sur les fonctionnalités réseau avancées.

Quand éviter FreeRTOS : pour un produit IoT multiprotocole (BLE + Thread + Matter), pour un projet nécessitant des mises à jour OTA structurées, ou quand la productivité de développement sur des stacks de communication modernes est un enjeu.

Linux avec PREEMPT_RT : quand il faut tout à la fois

Linux standard n’est pas un système temps réel. Son scheduler est conçu pour la répartition équitable du temps CPU (fairness), pas pour le respect de délais stricts. Les interruptions, la pagination mémoire, les locks du noyau et les drivers peuvent introduire des latences de plusieurs millisecondes, imprévisibles et non bornées. Cependant, le patch PREEMPT_RT transforme Linux en un système temps réel souple capable de garantir des latences inférieures à 100 µs dans la plupart des configurations.

PREEMPT_RT — le temps réel dans le noyau :

• Rend le noyau Linux entièrement préemptible : les sections critiques du noyau peuvent être interrompues par des tâches prioritaires
• Convertit les spinlocks en mutex avec héritage de priorité
• Les interruptions matérielles deviennent des threads ordonnançables avec des priorités configurables
• Intégré dans le noyau mainline depuis la version 6.12 : plus besoin de patch out-of-tree
• Latences typiques : 20 à 100 µs sur Cortex-A, mesurables avec cyclictest

Xenomai et RTAI — le hard real-time sous Linux :

• Approche dual-kernel : un micro-noyau temps réel (co-kernel) s’exécute en parallèle de Linux
• Le co-kernel gère les tâches temps réel critique avec des latences inférieures à 10 µs
• Linux tourne en « idle task » du co-kernel : il conserve tout son écosystème mais sans garantie de latence
• Cas d’usage : contrôle moteur, CNC, robotique de précision, acquisition à haute fréquence
• Limite : complexité accrue, API spécifiques (POSIX skin, Alchemy), maintenance du patch Xenomai

Avantages de l’écosystème Linux :

• Pile réseau complète : TCP/IP, Wi-Fi, Ethernet, VPN, pare-feu
• Systèmes de fichiers avancés : ext4, btrfs, SquashFS, overlayFS
• Interface graphique : Qt, GTK, frameworks web embarqués
• Écosystème logiciel : Python, Docker, bases de données, frameworks d’IA, OpenCV
• Drivers : la plus large base de pilotes matériels au monde
• Mise à jour OTA : swupdate, RAUC, Mender — solutions industrielles matures
• Intégration Yocto : construire un Linux RT custom avec meta-rt et les couches BSP adaptées

Limites :

• Empreinte : 32 Mo de RAM minimum, 128 Mo+ de stockage — incompatible avec les MCU
• Temps de démarrage : plusieurs secondes (optimisable mais jamais aussi rapide qu’un RTOS)
• Consommation : un processeur Cortex-A sous Linux consomme des ordres de grandeur au-dessus d’un Cortex-M sous Zephyr
• Complexité du tuning RT : isoler les cœurs CPU (isolcpus), configurer les priorités d’interruption, désactiver les sources de latence (SMI, frequency scaling) demande une expertise spécifique
• Certification difficile : la taille du noyau rend la certification IEC 61508 ou DO-178C extrêmement coûteuse

Notre expérience chez AESTECHNO : nous développons des BSP Linux custom sur plateformes NVIDIA Jetson pour des applications de traitement vidéo temps réel et de vision industrielle. Nous intégrons PREEMPT_RT dans nos images Yocto quand le projet exige à la fois des performances temps réel et l’écosystème Linux complet (réseau, IA, interface graphique). Notre bureau d’études dimensionne le hardware et le logiciel ensemble pour garantir que les objectifs de latence sont atteints en production.

Tableau comparatif : Zephyr vs FreeRTOS vs Linux RT

Ce tableau synthétise les caractéristiques clés des trois plateformes pour vous aider à positionner rapidement votre choix. Les valeurs sont des ordres de grandeur représentatifs de configurations typiques en contexte industriel.

Critère	Zephyr RTOS	FreeRTOS	Linux (PREEMPT_RT)
RAM minimum	8 Ko	4 Ko	32 Mo+
Flash / stockage minimum	64 Ko	16 Ko	128 Mo+
Type de temps réel	Hard	Hard	Soft (PREEMPT_RT) / Hard (Xenomai)
Latence pire cas	<10 µs	<10 µs	<100 µs (PREEMPT_RT)
Stack BLE	Intégré	Non (tiers)	BlueZ (non temps réel)
Thread / Matter	Intégré	Non	OpenThread (séparé)
Wi-Fi	Partiel	FreeRTOS+TCP	Complet
Système de fichiers	LittleFS, FAT	FreeRTOS+FAT	Complet (ext4, btrfs…)
OTA / DFU	MCUboot	AWS OTA	swupdate, RAUC, Mender
Power management	Natif (tickless idle)	Manuel	Complexe (suspend/hibernate)
Interface graphique	LVGL	LVGL	Complet (Qt, GTK, web)
Taille de l’écosystème	Croissance rapide	Plus grand RTOS	Plus grand globalement
Certification	IEC 61508, ISO 26262	IEC 61508 (SafeRTOS)	Difficile
Courbe d’apprentissage	Moyenne-élevée	Faible	Faible (Linux) / Élevée (tuning RT)
MCU / MPU cible	Cortex-M, nRF, ESP32	Tout Cortex-M	Cortex-A, x86

Arbre de décision : quel OS pour votre projet

Choisir entre Zephyr, FreeRTOS et Linux RT dépend de plusieurs critères croisés : le type de processeur, les exigences de latence, les protocoles de communication, les contraintes de consommation et le contexte réglementaire. Voici un cadre de décision qui couvre la majorité des cas que nous rencontrons en contexte industriel.

Choisir Zephyr RTOS quand :

• Vous concevez un produit IoT avec BLE, Thread ou Matter
• Vous ciblez un MCU Nordic (nRF52, nRF53, nRF54), NXP, STM32 ou ESP32
• Vous avez besoin de mises à jour OTA sécurisées (MCUboot)
• L’autonomie sur batterie est un enjeu critique (tickless idle, System OFF)
• Vous visez une certification IEC 61508 ou ISO 26262
• Vous voulez un écosystème moderne, structuré, avec une communauté en forte croissance

Choisir FreeRTOS quand :

• Vous avez une boucle de contrôle temps réel simple et bien définie
• Le MCU est très contraint en ressources (quelques Ko de RAM)
• Vous ciblez l’écosystème AWS IoT (MQTT, Device Shadow, Greengrass)
• La stabilité de l’API et la maturité de la communauté sont prioritaires
• Le projet est relativement simple, sans stack réseau avancé

Choisir Linux avec PREEMPT_RT quand :

• Le système combine temps réel et richesse applicative (réseau, GUI, IA, filesystem)
• Vous ciblez un MPU Cortex-A ou x86 (Jetson, i.MX8, Raspberry Pi)
• Le produit intègre de la vision industrielle, de la robotique ou un HMI complexe
• Vous avez besoin de Docker, Python, ou de frameworks logiciels riches
• La latence requise est de l’ordre de 100 µs (soft real-time)

Vous ne savez pas ? En règle générale : si votre processeur est un MCU (Cortex-M, pas de MMU), partez sur Zephyr. Si c’est un MPU (Cortex-A, avec MMU), partez sur Linux. FreeRTOS reste pertinent quand vous avez besoin d’une extrême simplicité ou d’une intégration AWS IoT native.

L’approche hybride : quand un seul OS ne suffit pas

L’approche hybride consiste à faire cohabiter Linux et un RTOS sur le même produit, en exploitant les architectures multiprocesseurs asymétriques (AMP). Le processeur applicatif (Cortex-A) exécute Linux pour les tâches complexes, tandis qu’un cœur temps réel (Cortex-M) exécute Zephyr ou FreeRTOS pour les boucles de contrôle critiques. Cette architecture combine le meilleur des deux mondes sans compromis.

Architectures supportées :

• NXP i.MX8 : cœurs Cortex-A53 (Linux) + Cortex-M4/M7 (RTOS)
• STM32MP1 : Cortex-A7 (Linux) + Cortex-M4 (RTOS)
• Systèmes multi-cartes : un SBC Linux + un MCU dédié connectés par SPI, UART ou USB

Communication inter-processeur :

• RPMsg : protocole de messagerie basé sur virtio, standard pour la communication A-core / M-core
• OpenAMP : framework open source pour le multiprocessing asymétrique
• Mémoire partagée : zones de RAM accessibles par les deux cœurs, avec synchronisation par mailbox

Cas d’usage typiques :

• Robotique : Linux gère la navigation, la vision et l’IHM ; le RTOS contrôle les moteurs en temps réel
• Instruments médicaux : Linux affiche l’interface utilisateur ; le RTOS pilote les capteurs et les actionneurs critiques
• Systèmes industriels : Linux communique avec le cloud et le réseau ; le RTOS assure la boucle de régulation

Notre expérience chez AESTECHNO : nous concevons des systèmes où Linux (sur Jetson ou i.MX) cohabite avec un MCU sous Zephyr au sein du même produit. Notre bureau d’études conçoit les deux parties — la carte électronique, le BSP Linux et le firmware RTOS — avec une vision système cohérente. Cette approche intégrée évite les problèmes d’intégration tardive entre sous-systèmes développés séparément.

FAQ : Zephyr, FreeRTOS et Linux temps réel

Zephyr ou FreeRTOS : lequel choisir ?
Si vous développez un produit IoT moderne avec BLE, Thread ou Matter, Zephyr est le choix naturel : ces piles sont intégrées nativement. FreeRTOS reste pertinent pour les boucles de contrôle simples sur des MCU très contraints ou quand vous ciblez l’écosystème AWS IoT. Les deux sont open source et offrent du hard real-time.

Linux est-il un système temps réel ?
Linux standard n’est pas temps réel : son scheduler privilégie l’équité plutôt que le respect de délais stricts. Avec le patch PREEMPT_RT (intégré au noyau mainline depuis la version 6.12), Linux devient un système temps réel souple avec des latences inférieures à 100 µs. Pour du hard real-time sous Linux, il faut recourir à Xenomai ou RTAI (approche dual-kernel).

Qu’est-ce que PREEMPT_RT ?
PREEMPT_RT est un ensemble de modifications du noyau Linux qui le rend entièrement préemptible. Les spinlocks sont convertis en mutex avec héritage de priorité, et les interruptions matérielles deviennent des threads ordonnançables. Résultat : les tâches critiques peuvent interrompre n’importe quelle section du noyau, ce qui réduit drastiquement les latences worst-case.

Peut-on combiner Linux et un RTOS dans le même produit ?
Oui, c’est l’approche hybride AMP (Asymmetric Multiprocessing). De nombreux SoC modernes intègrent des cœurs Cortex-A (pour Linux) et Cortex-M (pour un RTOS) sur la même puce. Les cœurs communiquent par RPMsg ou mémoire partagée. C’est courant en robotique, vision industrielle et systèmes médicaux.

Quel RTOS pour un produit BLE ?
Zephyr est le choix le plus adapté : il intègre une pile BLE 5.x complète, supportant les profils GATT, le maillage Bluetooth, et les protocoles Thread/Matter. FreeRTOS ne dispose pas de stack BLE natif — il faut utiliser le SDK propriétaire du fondeur de la puce radio, ce qui réduit la portabilité et complexifie la maintenance.

AESTECHNO peut-elle développer sur Zephyr et Linux ?
Oui. Nous déployons Zephyr en production sur des capteurs IoT BLE basse consommation et développons des BSP Linux custom avec Yocto sur des plateformes NXP et NVIDIA Jetson. Notre bureau d’études conçoit le hardware et le logiciel ensemble, ce qui nous permet d’optimiser le système dans son intégralité — du choix du processeur au firmware, en passant par la sécurité embarquée.

Quelle est la différence entre Zephyr et un Linux embarqué minimaliste ?
Zephyr est un RTOS pour microcontrôleurs (Cortex-M) : il offre du hard real-time, un footprint de quelques Ko, et fonctionne sans MMU ni système de fichiers avancé. Linux, même minimaliste (via Yocto ou Alpine), nécessite un processeur avec MMU (Cortex-A ou x86), au minimum 32 Mo de RAM, et fournit un écosystème applicatif complet. Ce sont des outils complémentaires, pas concurrents.

Articles connexes

• Distributions Linux embarqué : systemd, Alpine, Yocto — guide pour décideurs
• Logiciel embarqué industriel : guide complet
• Bureau d’études électronique AESTECHNO
• Conception de cartes FPGA
• Processeurs Jetson de NVIDIA
• L’IA embarquée avec NVIDIA Jetson
• Bluetooth et BLE pour l’embarqué
• Cybersécurité des systèmes embarqués