Distribution Linux embarqué : 5 critères pour bien choisir

Une installation Debian minimale dépasse 500 Mo et démarre en 5 à 30 secondes ; une image Yocto optimisée tient en 10 à 50 Mo et démarre en 1 à 3 secondes, mais son BSP devient un cycle de maintenance de 5 à 10 ans. Le choix d'une distribution Linux embarquée engage donc toute la vie série du produit. Elle assemble un kernel Linux, une libc (glibc ou musl), un init et un Board Support Package (BSP) adapté au SoC cible. Trois approches dominent : Ubuntu de Canonical et Debian (5-10 ans de Long-Term Support), Alpine Linux (proche de 50 Mo sur musl libc) et le Yocto Project, hébergé par la Linux Foundation, en reproductibilité totale.

Ce guide tranche selon votre BSP, votre Time To Boot (TTB) et votre durée de vie série. Liens de référence : Ubuntu, Debian, Alpine Linux, Yocto Project.

Linux domine l'embarqué industriel et l'IoT. Le kernel Linux mainline supporte tous les SoC modernes. La Linux Foundation coordonne les cycles LTS. Mais « Linux » recouvre des réalités très différentes. Le spectre va d'une distribution Ubuntu généraliste avec systemd à une image Yocto sur mesure de quelques mégaoctets, en passant par Alpine Linux et son init minimaliste. Si vous débutez dans l'embarqué, notre article sur les principes de base du logiciel embarqué donne le contexte nécessaire. Chaque approche a ses forces et ses cas d'usage.

Chez AESTECHNO, notre équipe conçoit des systèmes Linux embarqués pour des produits industriels depuis plus de 10 ans. Nous construisons des Board Support Package (BSP) sur Yocto pour des plateformes NXP et NVIDIA Jetson. Nous déployons aussi des distributions standard pour le prototypage et les passerelles. Cet article donne les clés pour choisir la bonne approche. Nous couvrons ici les compromis de Real-Time Operating System (RTOS), de Memory Management Unit (MMU) et de Root File System (rootfs) à connaître.

Quelles distributions Linux utilisent systemd ? Ubuntu, Debian, Fedora, RHEL

Une distribution Linux avec systemd est une distribution généraliste dont l'init remplace SysVinit par un PID 1 monolithique gérant les services, les sockets, les devices et les cgroups. D'après la documentation Debian et Ubuntu, systemd gère le démarrage des services, la journalisation (journald), la gestion des périphériques (udev) et la configuration réseau.

L'intégration de systemd simplifie le boot parallèle, d'après Red Hat, mais alourdit l'empreinte rootfs au-delà de 300 Mo d'après Debian (debian.org). Le kernel Linux mainline, comme le souligne Linus Torvalds dans les discussions LKML, ne prescrit aucun init particulier et tolère systemd, OpenRC ou BusyBox indifféremment.

Ce que systemd apporte :

• Gestion des services : démarrage parallèle, dépendances, redémarrage automatique, watchdog
• Journalisation centralisée : journald remplace syslog avec filtrage structuré
• Gestion des périphériques : udev intégré, règles de nommage réseau prédictibles
• Configuration réseau : networkd ou NetworkManager, résolution DNS (resolved)
• Conteneurs et sandboxing : intégration native avec cgroups v2, namespaces

Avantages pour l'embarqué :

• Familiarité pour les développeurs : environnement identique au poste de développement
• Écosystème de paquets riche : apt (Debian/Ubuntu) donne accès à des milliers de bibliothèques
• Support long terme : Ubuntu LTS (5 ans standard, 10 ans étendu), RHEL (10 ans)
• Cycle de développement rapide : du concept au prototype fonctionnel en quelques jours

Limites en contexte embarqué :

• Empreinte mémoire importante : une installation minimale Debian dépasse 500 Mo
• Temps de démarrage : 5 à 30 secondes selon la configuration
• Surface d'attaque élargie : chaque service supplémentaire est un vecteur potentiel (voir notre guide sur la cybersécurité des systèmes embarqués)
• Complexité de mise à jour : gérer les dépendances apt sur un parc de dispositifs déployés
• Reproductibilité partielle : deux builds identiques ne produisent pas forcément la même image

Cas d'usage recommandés : passerelles IoT, edge servers, postes HMI, prototypage rapide, systèmes non contraints en ressources. Ubuntu 24.04 LTS, publié en 2024, offre 5 ans de support standard. Ubuntu Pro étend la fenêtre à 10 ans. Debian stable publie tous les 2 ans avec 3 ans de support freeze et 2 ans de LTS additionnelle.

Distributions Linux sans systemd : Alpine, Void, Devuan, Gentoo

Les distributions Linux sans systemd sont des systèmes qui reposent sur des init alternatifs comme OpenRC, runit, s6 ou SysVinit. Ces init privilégient, selon Alpine (alpinelinux.org), la simplicité et la modularité. Chaque composant fait une seule chose, le système reste lisible et auditable, et l'empreinte mémoire chute par rapport aux distributions généralistes. Alpine combine musl libc et BusyBox pour produire une base rootfs de 5 Mo.

Les alternatives à systemd :

• OpenRC (Alpine, Gentoo) : scripts shell avec gestion de dépendances, léger et éprouvé
• runit (Void Linux) : supervision de services minimaliste, redémarrage automatique
• s6 : supervision fine, conçu pour la fiabilité, utilisé dans des images Docker minimales
• SysVinit (Devuan) : l'init historique Unix, séquentiel mais simple à comprendre

Avantages pour l'embarqué :

• Empreinte réduite : une image Alpine fonctionnelle tient dans 50 Mo
• Démarrage rapide : 2 à 5 secondes sur du matériel modeste
• Surface d'attaque minimale : Alpine utilise musl libc et BusyBox, réduisant le code exposé
• Transparence : on comprend ce qui tourne, pas de « magie » cachée dans un PID 1 monolithique
• Adapté aux conteneurs : Alpine est la base image Docker la plus utilisée au monde

Limites :

• Écosystème de paquets plus restreint (Alpine apk vs Debian apt)
• Communauté plus petite : moins de documentation, moins de réponses sur les forums
• Compatibilité : certains logiciels supposent glibc et systemd (ex : certains agents de monitoring)
• Gestion manuelle des services : supervision à configurer soi-même (pas de socket activation, etc.)

Cas d'usage recommandés : conteneurs embarqués, appliances minimalistes, produits sensibles à la sécurité, systèmes à ressources limitées. Alpine Linux représente 50 % des images Docker publiées sur Docker Hub. Alpine 3.19 consomme 28 Mo en RAM minimale au boot.

Pourquoi construire sa propre distribution Linux avec Yocto ?

Le Yocto Project est un système de build Linux sur mesure, pas une distribution. Il permet, d'après le Yocto Project (yoctoproject.org), de créer des distributions Linux entièrement adaptées au matériel cible.

Yocto repose sur OpenEmbedded et le moteur BitBake pour générer des images reproductibles par cross-compilation. L'ingénieur garde un contrôle total sur chaque paquet, chaque bibliothèque, et chaque configuration présente dans l'image finale. Le projet, hébergé par la Linux Foundation, publie deux releases par an avec une LTS tous les deux ans (support 4 ans). La reproductibilité Yocto permet, comme le souligne Arm dans sa documentation Cortex-A, de figer un Board Support Package (BSP) sur une architecture donnée pendant toute la durée de vie produit. Un build Yocto LTS comme Kirkstone 4.0 reçoit, d'après Foundries et Timesys, des patches CVE pendant 4 à 6 ans.

Comment fonctionne Yocto :

• Layers (couches) : architecture modulaire, BSP layer (hardware), distro layer (politiques), application layer
• Recipes (recettes) : description déclarative de chaque composant logiciel (source, build, install)
• BSP intégré : support natif des processeurs NXP i.MX, TI Sitara, NVIDIA Jetson, Raspberry Pi, etc.
• Cross-compilation : build sur un serveur x86 puissant, déploiement sur ARM/MIPS/RISC-V, l'architecture RISC-V gagne du terrain en production industrielle et bénéficie d'un support croissant dans Yocto
• Choix du système d'init : systemd ou SysVinit, selon vos besoins

Avantages pour l'embarqué :

• Empreinte minimale : une image Yocto peut descendre sous les 10 Mo (core-image-minimal)
• Reproductibilité totale : même source = même image binaire, indispensable pour certification
• Maintenance long terme : vous maîtrisez le cycle de vie, pas de dépendance à l'éditeur d'une distribution
• Intégration BSP native : les couches hardware s'empilent proprement sur la base Poky
• Sécurité ciblée : pas de paquet superflu, surface d'attaque réduite au strict nécessaire
• systemd ou non : c'est votre choix, pas celui de la distribution

Limites :

• Courbe d'apprentissage : BitBake, les layers, les classes, il faut investir du temps
• Temps de build initial : plusieurs heures pour la première compilation complète
• Nécessite une expertise dédiée : maintenir un BSP Yocto demande des compétences spécifiques
• Pas de gestionnaire de paquets en production (dans la configuration typique) : les mises à jour passent par des images complètes ou un mécanisme OTA dédié

Yocto vs Buildroot : selon la Buildroot Association (buildroot.org), Buildroot est une alternative plus simple à Yocto : configuration via menuconfig, build plus rapide, mais moins flexible. Buildroot 2025.02 est la LTS actuelle, supportée jusqu'en mars 2028 selon buildroot.org, cycle rolling release GPLv2. Buildroot convient aux projets de petite taille avec peu de personnalisation. Yocto s'impose quand on a besoin de layers réutilisables, de builds reproductibles à l'échelle, et d'une maintenance sur plusieurs années. D'après Linaro, consortium Arm dédié au support Linux sur Cortex-A, Yocto reste le standard de facto pour les BSP industriels commerciaux.

Cas d'usage recommandés : produits embarqués de série, dispositifs certifiés (médical, automobile), hardware industriel avec BSP spécifique, systèmes à longue durée de vie. Kirkstone (4.0) est en fin de vie depuis avril 2026. Scarthgap (5.0) est LTS jusqu'en avril 2028, et Wrynose (6.0), publiée en avril 2026, est LTS jusqu'en avril 2030. Un build complet initial prend 2 à 6 heures sur un serveur x86 avec 16 cœurs et 64 Go de RAM.

Tableau comparatif : Ubuntu/Debian vs Alpine vs Yocto

Le tableau ci-dessous est une comparaison côte à côte d'Ubuntu/Debian, d'Alpine Linux et du Yocto Project sur les critères qui comptent pour un projet embarqué. Les lignes résument l'empreinte, le temps de boot, l'init, la fenêtre de support et l'intégration BSP pour positionner rapidement votre choix. Les valeurs correspondent à des ordres de grandeur représentatifs de configurations typiques rencontrées en contexte industriel.

Retour terrain : choisir le bon outil pour chaque projet

Le choix d'une distribution Linux embarquée est une décision liée à la phase du projet, qui dépend de la vitesse de prototypage, du volume de série et des contraintes du produit final. Notre approche repose sur un principe simple : il n'y a pas de solution universelle. Notre équipe accompagne des clients dans la conception de systèmes embarqués depuis plus de 10 ans. Au fil de ces projets, nous avons constaté que le bon choix change entre la phase de prototype et la production de série.

Pour le prototypage et les passerelles, nous déployons régulièrement des distributions standard (Ubuntu, Debian) qui permettent d'itérer rapidement avec un écosystème logiciel riche. L'objectif est de valider le concept avant d'investir dans une image sur mesure.

Pour les produits de série et les systèmes industriels, nous construisons des BSP custom avec le Yocto Project. Nous maîtrisons l'intégration de couches BSP pour processeurs NXP i.MX et NVIDIA Jetson, avec des images optimisées pour le hardware cible. Cette approche garantit la reproductibilité des builds, critère exigé par IEC 62304 sur les dispositifs médicaux. Yocto donne aussi un contrôle total sur les mises à jour et une empreinte adaptée aux contraintes de stockage et de démarrage.

Retour de terrain, BSP Yocto Jetson Orin NX (Q1 2026). Au Q1 2026, nous avons développé un BSP Yocto entièrement personnalisé pour un module Jetson Orin NX. Le travail a couvert des couches meta-aestechno dédiées, une configuration kernel adaptée (CONFIG_PREEMPT, drivers caméra, ajustements mémoire LPDDR5), un device tree étendu pour la carrier board custom, et l'intégration de la chaîne d'inférence TensorRT dans l'image de production. Un projet exigeant sur tous les fronts, alignement des versions L4T, patches kernel et reproductibilité des builds sur CI, qui illustre concrètement ce qu'apporte Yocto sur un produit de série.

Au-delà de Jetson, nous avons également livré un ordinateur industriel custom à base d'Intel Core i5 avec image Linux optimisée. Nous avons aussi intégré Linux embarqué aux côtés d'un RTOS (FreeRTOS ou Zephyr côté MCU, HAL commune) sur des plateformes hétérogènes. Notre comparatif de Zephyr, FreeRTOS et Linux embarqué détaille quand un RTOS l'emporte sur une pile Linux complète. Un spectre aussi complet nous permet d'arbitrer sans parti pris sur la distribution adaptée à chaque contexte. Le firmware MCU côté asymétrique reste piloté depuis le Linux de la MPU via IPC OpenAMP.

Notre bureau d'études gère l'ensemble de la chaîne : du choix du processeur à l'intégration du BSP, en passant par le bootloader, le device tree, les drivers kernel et l'applicatif embarqué. Nous travaillons en étroite collaboration avec nos ingénieurs hardware pour que le logiciel soit pensé en même temps que la carte électronique.

Écosystème Yocto : couches et outils à connaître

L'écosystème Yocto correspond à un assemblage de couches et d'outils à articuler, pas un monolithe. Cet écosystème couvre la distribution de référence Poky, les meta-layers OpenEmbedded, les couches BSP des fabricants et les outils de développement. Notre pratique industrielle repose sur les briques suivantes :

• Distribution de référence : Poky, la distribution de référence du projet Yocto, base de tout nouveau projet
• OpenEmbedded : l'ensemble des meta-layers open source qui alimentent Yocto, dont le moteur bitbake
• Layers essentielles : meta-virtualization (Docker, LXC, conteneurs), meta-security (AppArmor, SELinux, SCAP), meta-tegra (NVIDIA Jetson), meta-freescale / meta-imx (NXP i.MX), meta-ti
• Outils de développement : devtool pour le développement incrémental, kas ou Google's repo pour la gestion multi-layers, Toaster pour l'interface web
• Standards et politiques : Yocto Project Compatible (certification de layers), LTS kernel.org (environ 2 ans de support pour les versions actuelles), noyaux SLTS CIP (Civil Infrastructure Platform) pour du super-long-terme industriel (10 ans et plus)

Contrairement à l'idée qu'un BSP Yocto est un livrable ponctuel, un BSP industriel correspond à un cycle de maintenance LTS de 5 à 10 ans à intégrer dans l'organisation. Le cycle de maintenance couvre une veille sécurité sur les CVE kernel et userspace, des rebases réguliers et des tests de non-régression sur hardware cible. Automatiser ces rebuilds et ces tests est précisément l'apport d'une démarche DevOps et CI/CD embarquée. Dans notre pratique, nous budgétons la maintenance BSP comme une ligne à part entière du projet, et non comme une « finalisation » de la phase de développement.

Ordres de grandeur mesurés : rootfs, boot et latence

Quelques repères chiffrés pour calibrer votre arbitrage, issus des configurations que nous rencontrons régulièrement :

• Rootfs Alpine : 5 Mo base (BusyBox + musl), 50 Mo avec quelques paquets usuels ; BusyBox-only Yocto : 8 Mo ; Debian minimal : 300 Mo avec dpkg/apt.
• Temps de boot : Ubuntu 22.04 LTS 15-30 s, Alpine OpenRC 2-5 s, image Yocto optimisée 1-3 s (U-Boot + kernel compressé + initramfs minimal).
• Latence RT : kernel mainline 500 µs - 2 ms de jitter, kernel PREEMPT_RT 50-100 µs max observé sur ARM Cortex-A53.
• Fréquence kernel : HZ=100 par défaut, HZ=1000 pour une résolution 1 ms en contrôle-commande.
• Consommation : deep sleep d'un SoC sous Linux 100-500 µA selon drivers et quirks PMIC, vs 5-50 µA pour un RTOS pur.

Ces valeurs restent indicatives, elles dépendent du SoC, du bootloader (U-Boot, barebox, coreboot) et du kernel retenu (mainline, vendor fork, LTS). Le choix entre LTS et mainline relève d'un arbitrage classique. La mainline apporte les dernières corrections mais bouge tous les 9 semaines. La LTS stabilise 6 ans et minimise la dette de patches.

Quelle approche choisir pour votre projet ?

Un arbre de décision est un ensemble structuré de questions qui associe chaque contrainte du projet à une distribution ou une image sur mesure recommandée. Celui ci-dessous permet de trancher entre distribution standard et image sur mesure selon la certification, l'empreinte et le volume de série. Chaque situation est différente, mais ces grandes orientations couvrent la majorité des cas rencontrés en contexte industriel.

Prototype, passerelle, système non contraint en ressources :

• → Ubuntu ou Debian : développement rapide, écosystème riche, support LTS
• Exemples : gateway IoT, poste HMI, serveur edge

Conteneur, appliance minimale, produit sensible à la sécurité :

• → Alpine Linux : empreinte réduite, surface d'attaque minimale, boot rapide
• Exemples : micro-service embarqué, firewall applicatif, capteur avec interface web

Produit embarqué de série, hardware custom :

• → Yocto Project : image sur mesure, BSP intégré, builds reproductibles
• Exemples : automate industriel, dispositif médical, terminal de paiement, système embarqué NXP ou Jetson

Produit nécessitant une certification (médical, automobile, ferroviaire) :

• → Yocto Project : la reproductibilité des builds est un prérequis réglementaire
• La traçabilité complète des composants logiciels (SBOM) est indispensable pour IEC 62304, ISO 26262, etc.

Nous utilisons aussi des approches hybrides : prototype sur Ubuntu pour valider le concept, puis migration vers une image Yocto optimisée pour la production. Cette stratégie permet de réduire le time-to-market sans sacrifier la qualité du produit final.

En résumé : distribution Linux embarqué, quoi retenir

Ce récapitulatif est une synthèse condensée des six repères opérationnels pour arbitrer entre une distribution Linux embarqué généraliste et une image sur mesure. Chaque point ci-dessous associe une famille de distributions à son cas d'usage type et à sa contrainte principale.

• Ubuntu / Debian LTS : prototypage, passerelles, edge servers. Image ≥500 Mo, support 5-10 ans, écosystème apt complet. Pas adapté aux contraintes série strictes.
• Alpine Linux : appliances minimales, conteneurs, produits sensibles à la sécurité. Base ~5 Mo (musl libc + BusyBox), boot 2-5 s, surface d'attaque minimale. Audit de compatibilité glibc requis avant portage.
• Yocto Project : produits de série, hardware custom, certification (IEC 62304, ISO 26262, EN 50155). Image 10-50 Mo, builds reproductibles, BSP intégré, cycle LTS maîtrisé sur 5-10 ans.
• Kernel : privilégier une LTS kernel.org pour la maintenance long terme ; activer PREEMPT_RT si le produit demande une latence bornée (temps réel ferme ou souple) ; les boucles dures sous 10 µs relèvent d'un cœur MCU.
• Maintenance : un BSP industriel demande 2-6 semaines/an de veille CVE, rebases et tests de non-régression, à budgéter dès le kickoff.
• Cyber Resilience Act : quelle que soit la distribution, le fabricant porte les mises à jour de sécurité sur la période de support ; voir notre guide CRA pour Linux embarqué.

FAQ : distributions Linux pour l'embarqué

Cette FAQ est un ensemble de réponses directes aux questions que nous entendons le plus souvent quand un client choisit une distribution Linux embarquée pour un produit industriel. Les réponses ci-dessous couvrent le choix de la distribution, l'arbitrage Yocto contre Buildroot, le rôle de systemd et la sécurité.

Quelle distribution Linux pour un produit embarqué ?
Le choix dépend du contexte : pour un prototype ou une passerelle, Ubuntu ou Debian offrent un écosystème riche et un développement rapide. Pour un produit de série avec des contraintes de taille, de boot et de reproductibilité, le Yocto Project permet de construire une image sur mesure. Alpine Linux est un bon choix intermédiaire pour les appliances légères et les conteneurs.

Yocto ou Buildroot : comment choisir ?
Buildroot est plus simple à prendre en main et compile plus vite : il convient aux projets simples avec peu de personnalisation. Yocto est plus puissant grâce à son architecture en couches (layers) qui facilite la réutilisation, la maintenance long terme et les builds reproductibles. Pour un produit industriel de série maintenu sur plusieurs années, nous recommandons Yocto.

Peut-on utiliser Ubuntu en production embarquée ?
Oui, pour certains cas d'usage : passerelles, edge servers, postes HMI ou systèmes non contraints en ressources. Ubuntu offre un excellent support à long terme (LTS). Cependant, pour des produits de série avec des contraintes de taille mémoire, de temps de démarrage ou de certification, une image Yocto sur mesure est préférable.

Quel est le coût de développement d'un BSP Yocto ?
Le coût varie fortement selon la complexité du hardware, le nombre de périphériques à intégrer et le niveau de personnalisation requis. Un BSP basique sur une plateforme NXP i.MX bien supportée demande moins d'effort qu'une intégration sur un SoC peu documenté. Nous dimensionnons chaque projet lors de l'audit initial pour donner une estimation réaliste.

systemd est-il nécessaire pour l'embarqué ?
Non. systemd apporte des fonctionnalités avancées (supervision de services, journalisation structurée, gestion réseau) qui sont utiles sur des systèmes complexes. Mais pour un produit embarqué minimal, un init plus léger (OpenRC, SysVinit, BusyBox init) suffit souvent. Avec Yocto, vous choisissez votre système d'init selon vos besoins réels.

Comment sécuriser une distribution Linux embarquée ?
La sécurité commence par la réduction de la surface d'attaque : moins de paquets installés, moins de services actifs. Yocto excelle ici car l'image ne contient que le strict nécessaire. Ensuite, il faut mettre en place secure boot, chiffrement du filesystem, mises à jour OTA signées et monitoring des vulnérabilités (CVE). Consultez notre guide cybersécurité embarquée et notre méthode pour concevoir et déployer un produit IoT sécurisé pour approfondir.

Articles connexes

• Logiciel embarqué industriel : guide complet pour décideurs
• Processeurs Jetson de NVIDIA pour l'embarqué
• Bureau d'études électronique AESTECHNO
• Cybersécurité des systèmes embarqués
• L'IA embarquée avec NVIDIA Jetson
• Conception de produits électroniques