ElectroTech · 1 September 2026

Zephyr RTOS en 2026 : la revanche de l’open source dans l’embarqué

Il fut un temps où choisir un RTOS revenait à signer un chèque et à s’en remettre à un éditeur propriétaire. En 2026, la donne a changé : Zephyr, le système d’exploitation temps réel open source hébergé par la Linux Foundation, s’est imposé comme une alternative crédible, soutenue par les fondeurs et adoptée aussi bien par l’industrie que par les makers. Tour d’horizon d’un écosystème qui a mué, entre architecture modulaire, correctifs de sécurité sous tension et outillage enfin mature.

Zephyr RTOS en 2026 : la revanche de l’open source dans l’embarqué

Il y a encore cinq ans, évoquer un RTOS open source dans un cahier des charges industriel déclenchait souvent un haussement de sourcils. Les équipes de développement préféraient s’appuyer sur des solutions éprouvées, propriétaires, avec un support commercial clair. En 2026, ce réflexe s’est inversé. Zephyr, projet hébergé par la Linux Foundation, s’est imposé comme un acteur central du paysage des systèmes embarqués, au point que même les géants historiques du propriétaire ont dû s’adapter : Microsoft a ainsi placé Azure RTOS (ThreadX) sous licence open source MIT sous l’égide de la fondation Eclipse, un mouvement qui en dit long sur la dynamique du marché.

Cette montée en puissance ne doit rien au hasard. Zephyr bénéficie d’un soutien actif des grands fondeurs de semi-conducteurs, qui voient dans ce RTOS un moyen de standardiser leurs offres logicielles autour d’un socle commun. Les cartes de développement, les SDK et les exemples fournis par les fabricants intègrent désormais Zephyr au même titre que les piles propriétaires. Côté communauté, les signaux sont au vert : les contributions affluent, les salons professionnels comme Embedded World consacrent des sessions entières au projet, et les formations spécialisées se multiplient. Le projet revendique plus de 600 cartes supportées et plus de 150 capteurs intégrés, un chiffre qui illustre l’ampleur de l’écosystème.

Mais l’adoption ne se limite pas aux laboratoires de R&D. Les makers, longtemps fidèles à Arduino et à FreeRTOS, découvrent les avantages d’un système complet avec une vraie gestion de la configuration matérielle. Les tutoriels et articles de vulgarisation se multiplient, à l’image de ceux publiés par Elektor Magazine, qui consacre des dossiers pratiques à la prise en main de Zephyr. Cette double dynamique — industrielle et communautaire — fait de Zephyr un cas d’école de l’open source qui infuse dans un domaine historiquement conservateur.

Kconfig, Devicetree et multi-cœurs : l’architecture qui respire

Ce qui distingue Zephyr des RTOS plus anciens, c’est d’abord son architecture modulaire, pensée dès l’origine pour s’adapter à des configurations très variées. Deux outils structurent cette modularité : Kconfig, hérité de l’écosystème Linux, permet de configurer le noyau et les sous-systèmes par une arborescence d’options ; Devicetree, quant à lui, décrit le matériel de façon déclarative — adresses, interruptions, périphériques — et génère automatiquement les structures de pilotes correspondantes. Cette séparation entre configuration logicielle et description matérielle simplifie considérablement le portage d’une application d’une carte à une autre.

Le modèle de pilotes, entièrement basé sur Devicetree, permet d’ajouter un capteur ou un écran sans toucher au code applicatif : il suffit de déclarer le nœud dans l’arbre et de s’appuyer sur l’API générique. Cette approche, qui peut dérouter au premier abord, devient rapidement un atout majeur pour les projets qui évoluent. Les sous-systèmes intégrés couvrent un large spectre : Bluetooth Low Energy 5.0, LoRaWAN, OpenThread, mais aussi des bibliothèques graphiques comme LVGL et des systèmes de fichiers comme littlefs. Le tout est scalable : Zephyr fonctionne de 8 Ko à plusieurs Go de mémoire, ce qui le rend aussi à l’aise sur un microcontrôleur 32 bits contraint que sur un processeur applicatif.

L’une des évolutions les plus attendues concerne la prise en charge des SoC hétérogènes, combinant par exemple des cœurs RISC-V et ARM sur une même puce, avec des DSP et de la mémoire partagée. Les sources disponibles en 2026 ne détaillent pas encore d’API spécifiques pour ces configurations, mais la direction est claire : Zephyr, qui supporte déjà ARM, x86, RISC-V, Xtensa, MIPS, Nios2 et MicroBlaze, travaille à une meilleure orchestration des clusters multi-cœurs. La gestion de l’énergie, cruciale pour les objets connectés sur batterie, fait également l’objet d’attention, avec des mécanismes de suspension et de réveil adaptés aux contraintes temps réel.

CVE 2026-13734/13735 : quand Zephyr a dû colmater les brèches

Aucun système n’est infaillible, et l’open source n’échappe pas à la règle. L’année 2026 a vu la publication de deux vulnérabilités majeures dans Zephyr, référencées CVE-2026-13734 et CVE-2026-13735. Si les détails techniques de la première restent largement confidentiels dans les sources publiques, la seconde a été identifiée comme touchant la pile réseau, plus précisément le protocole WireGuard, utilisé pour les tunnels VPN. Le titre de la notification, rapporté par une source tierce (cvefeed.io), évoque des « messages de données de transport keepalive » — un vecteur d’attaque qui pourrait permettre à un attaquant distant de perturber le fonctionnement d’un nœud.

Il faut ici faire preuve de prudence : aucune source officielle de la Zephyr Foundation ni base nationale de vulnérabilités (NVD) n’a fourni, à la date de notre enquête, de score CVSS précis ni de liste exhaustive des versions affectées. Ce que l’on sait, c’est que la fondation a publié des advisories et coordonné les correctifs avec les distributions qui embarquent Zephyr. Ce processus, bien rodé dans l’écosystème Linux, est un signal positif : la sécurité est prise au sérieux, avec une divulgation responsable et des correctifs rapidement intégrés aux branches stables.

Ces événements rappellent toutefois que l’adoption d’un RTOS open source implique une veille active. Les équipes doivent suivre les annonces de sécurité, mettre à jour leurs chaînes de compilation et tester leurs produits après chaque correctif. C’est le prix à payer pour bénéficier d’un code auditable et d’une communauté réactive — un avantage que les solutions propriétaires peinent à offrir avec la même transparence.

De West à Tracealyzer : la boîte à outils du développeur Zephyr

L’écosystème d’outils a longtemps été le point faible des RTOS open source. Ce n’est plus le cas. Benjamin Cabé, Developer Advocate pour le projet Zephyr, le rappelait en novembre 2025 : Zephyr est « bien plus qu’un simple RTOS », il inclut des outils comme West et Twister. West est le méta-outil de build et de flash, qui gère les dépendances entre le noyau, les pilotes et les applications ; Twister automatise l’exécution des tests sur de multiples configurations et cibles. Ces deux outils, intégrés au workflow standard, offrent une expérience comparable à celle des IDE propriétaires, mais en open source.

Le Zephyr SDK fournit les chaînes de compilation croisées pour toutes les architectures supportées, et l’intégration avec VS Code s’est nettement améliorée : l’extension officielle permet de configurer, compiler et débugger directement depuis l’éditeur, avec une visualisation des threads et des files d’attente. Pour le debugging temps réel, Percepio Tracealyzer, dans sa version 4.6, supporte Zephyr aux côtés de ThreadX, comme l’a annoncé NeoMore. Cet outil trace l’exécution des tâches, les appels système et les communications inter-thread, ce qui s’avère précieux pour diagnostiquer les problèmes de concurrence ou de latence. Percepio a d’ailleurs animé des ateliers pratiques lors du Microchip MASTERs 2026, confirmant l’intérêt du marché pour ces capacités.

Comparé aux workflows des RTOS propriétaires, l’outillage Zephyr présente un avantage décisif : la transparence. Les scripts de build sont lisibles, modifiables, et l’ensemble du processus est reproductible. Pour les équipes qui viennent de FreeRTOS, l’apprentissage de West et de Kconfig représente un investissement initial, mais il est rapidement rentabilisé par la puissance de configuration offerte. Les développeurs expérimentés recommandent de commencer par un projet simple, avec une carte supportée officiellement, avant de se lancer dans des configurations complexes.

Du wearable au contrôle industriel : Zephyr en action

Les cas d’usage concrets illustrent la polyvalence de Zephyr. Dans le domaine des wearables, les montres connectées et les bracelets d’activité exploitent la pile Bluetooth Low Energy 5.0 et les mécanismes de gestion d’énergie pour tenir des semaines sur une petite batterie. L’empreinte mémoire réduite — dès 8 Ko — permet d’utiliser des microcontrôleurs économiques, ce qui abaisse le coût matière des produits grand public.

Côté IoT industriel, Zephyr est devenu un choix naturel pour les capteurs sans fil : les bibliothèques LoRaWAN et MQTT sont intégrées, et le support des protocoles comme OpenThread facilite la construction de réseaux maillés robustes. Les intégrateurs comme Witekio, qui proposent des services de développement firmware autour de Zephyr, soulignent les gains de productivité : la configuration par Devicetree évite de réécrire les pilotes à chaque changement de carte, et la maintenance est simplifiée par la standardisation du code. Les coûts de licence, nuls, représentent également un argument de poids face aux solutions propriétaires, surtout pour les séries à bas volume.

Dans l’automatisme industriel, où les contraintes temps réel sont strictes, Zephyr offre un ordonnancement préemptif et des primitives de communication inter-thread éprouvées. Les retours d’expérience font état d’une réduction significative du temps de développement par rapport au bare metal, grâce aux sous-systèmes prêts à l’emploi. Bien sûr, chaque projet a ses spécificités, et il faut évaluer la pertinence de Zephyr au cas par cas — mais la tendance de fond est indéniable : le RTOS open source s’est installé dans les chaînes de production.

FreeRTOS, ThreadX, Mbed OS : Zephyr a-t-il vraiment gagné ?

Pour répondre à cette question, il faut comparer ce qui est comparable. FreeRTOS reste le RTOS le plus répandu dans l’embarqué, grâce à sa simplicité et à sa licence permissive. Mais il s’agit d’un noyau minimal, sans les sous-systèmes intégrés de Zephyr : pas de pile Bluetooth native, pas de Devicetree, pas d’outillage standardisé. Pour un projet simple, FreeRTOS suffit ; pour un produit connecté complexe, Zephyr apporte une valeur ajoutée nette.

ThreadX, désormais Eclipse ThreadX, a été ouvert par Microsoft en 2024 — un aveu de la pression exercée par l’open source. Avec plus de 12 milliards d’équipements déployés, il conserve une base installée massive, mais son écosystème d’outils reste marqué par son héritage propriétaire. Mbed OS, quant à lui, a vu son support communautaire décliner, et son avenir est incertain dans un marché où Zephyr concentre les investissements.

Le verdict est nuancé. Zephyr n’a pas « gagné » au sens où FreeRTOS disparaîtrait — il serait plus juste de dire que le marché se structure autour de deux pôles : FreeRTOS pour le simple, Zephyr pour le complexe. ThreadX conserve ses bastions industriels, mais son ouverture tardive montre que la tendance est à la standardisation ouverte. Pour un nouveau projet en 2026, Zephyr apparaît comme le choix le plus pérenne, à condition d’accepter sa courbe d’apprentissage.

Passer à Zephyr : mode d’emploi pour les équipes et les makers

Se lancer dans Zephyr demande un changement de mentalité. Les prérequis sont modestes — une bonne connaissance du C et une familiarité avec les concepts de configuration — mais il faut accepter d’apprendre Devicetree et Kconfig. La documentation officielle et les tutoriels d’Elektor constituent une porte d’entrée efficace. Le plus simple est de commencer avec une carte supportée officiellement parmi les 600+ disponibles : les exemples fournis permettent de compiler et de flasher un premier programme en quelques minutes.

Les pièges classiques sont bien identifiés par la communauté. La gestion des overlays Devicetree, qui permettent de personnaliser une carte sans modifier les fichiers d’origine, est souvent mal comprise au début. La configuration Kconfig, avec ses dépendances implicites, peut générer des erreurs obscures si l’on n’active pas les bons symboles. Enfin, la multiplicité des versions — LTS et versions de développement — exige de choisir sa branche avec soin, en fonction des besoins de stabilité.

Pour les équipes qui migrent depuis FreeRTOS ou le bare metal, la stratégie recommandée est progressive : commencer par porter un module non critique, mesurer les performances, puis étendre. Les formations professionnelles, comme celles proposées par AC6, accélèrent la montée en compétence. La communauté, active sur les forums et GitHub, répond rapidement aux questions — un atout précieux pour les débutants. Enfin, il ne faut pas négliger l’aspect culturel : Zephyr encourage une approche structurée, où la configuration est explicite et le code réutilisable. C’est un investissement, mais qui porte ses fruits sur le long terme.

Vers une certification ISO 26262 : les prochains défis de Zephyr

L’avenir de Zephyr se jouera en grande partie sur le terrain de la sécurité fonctionnelle. Les secteurs de l’automobile, de l’industrie et du médical exigent des certifications rigoureuses — ISO 26262 pour l’automobile, IEC 61508 pour l’industrie. Les sources disponibles évoquent une conformité à l’architecture de sécurité PSA d’ARM, un premier pas, mais la certification complète reste un chantier colossal. La Zephyr Foundation travaille à documenter les processus de développement, à fournir des preuves de conformité et à établir des chaînes d’outils qualifiées.

Ces efforts sont cruciaux pour convaincre les secteurs les plus conservateurs. L’aérospatiale, qui exige des normes encore plus strictes, observe avec intérêt les avancées du projet, mais la route est longue. Pour les développeurs, ces évolutions signifient une chose : Zephyr n’est plus un simple outil de prototypage, mais une plateforme qui vise le cœur des systèmes critiques. La gouvernance de la fondation, adossée à la Linux Foundation, apporte une stabilité institutionnelle rassurante pour les industriels.

En attendant, les équipes qui adoptent Zephyr dès aujourd’hui se positionnent sur une trajectoire ascendante. Les compétences acquises — configuration Devicetree, maîtrise de Kconfig, utilisation de West — seront valorisables dans les années à venir, quel que soit le secteur. L’open source a gagné la bataille de la crédibilité ; il lui reste à gagner celle de la certification. Et si l’histoire récente est un indicateur, elle a de bonnes chances d’y parvenir.

Sources

• Witekio — Zephyr RTOS
• ecinews.fr — De grandes opportunités pour Zephyr RTOS
• L’Embarqué — Zephyr conforme à l’architecture PSA d’ARM
• Elektor Magazine — Commencer avec le RTOS Zephyr
• AC6 Formation — Zephyr RTOS
• L’Embarqué — Eclipse ThreadX
• Percepio — Hands-On Zephyr RTOS Debugging at Microchip MASTERs 2026
• Zephyr Project — Site officiel

Article recherché et rédigé automatiquement · Magazine Electrosens