Quelle distribution Linux embarqué ? Ubuntu, Alpine ou Yocto

Une distribution Linux embarquée est un assemblage de kernel Linux, d'une libc (glibc ou musl), d'un init et d'un Board Support Package (BSP) adapté au SoC cible. Trois approches dominent : Ubuntu de Canonical et Debian (500 Mo+ de rootfs, 5-10 ans de Long-Term Support), Alpine Linux (50 Mo, musl libc) et le Yocto Project, hébergé par la Linux Foundation (image sur mesure 10-50 Mo, 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 : 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, nous concevons 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.

Distributions Linux avec systemd : Ubuntu, Debian, Fedora, RHEL

Une distribution Linux avec systemd utilise un système d'initialisation complet qui remplace SysVinit par un PID 1 monolithique gérant services, sockets, devices et cgroups. systemd gère, selon Debian et selon Canonical pour Ubuntu, le démarrage des services, la journalisation (journald), la gestion des périphériques (udev) et la configuration réseau.

Cette intégration 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 LTS 22.04 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 sans systemd utilisent des systèmes d'init alternatifs : 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. Un init OpenRC permet un démarrage mesuré à 2,5 s sur un i.MX 8M à 1,6 GHz.

Yocto Project : construire sa propre distribution Linux

Le Yocto Project est un système de build Linux sur mesure, pas une distribution. Il permet, d'après Yocto (yoctoproject.org) et selon Linaro, 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 d'après 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 Buildroot Association (buildroot.org), Buildroot est une alternative plus simple à Yocto : configuration via menuconfig, build plus rapide, mais moins flexible. Buildroot 2024.02 est une LTS supportée 12 mois, 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. La release Yocto LTS Kirkstone (4.0) est supportée jusqu'en avril 2028. La release Scarthgap (5.0) est LTS jusqu'en 2028. 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

Ce tableau comparatif synthétise les caractéristiques clés de chaque approche pour positionner rapidement votre choix en fonction des contraintes de votre projet embarqué. Les valeurs correspondent à des ordres de grandeur représentatifs de configurations typiques rencontrées en contexte industriel.

Critère	Ubuntu / Debian	Alpine Linux	Yocto Project
Empreinte disque	500 Mo+	~50 Mo	10-50 Mo (sur mesure)
Temps de boot	5-30 s	2-5 s	<1-3 s
Système d'init	systemd	OpenRC	Au choix (systemd / SysVinit)
Gestionnaire de paquets	apt	apk	opkg / rpm / aucun
Support long terme	5-10 ans (LTS)	~2 ans	Vous le maîtrisez
Intégration BSP	Manuelle	Manuelle	Native (layers)
Reproductibilité	Partielle	Partielle	Totale
Courbe d'apprentissage	Faible	Faible	Élevée
Cas d'usage principal	Dev / gateway / edge	Conteneur / appliance minimale	Production embarquée série

Retour terrain : choisir le bon outil pour chaque projet

Notre approche repose sur un principe simple : il n'y a pas de solution universelle. Nous accompagnons nos clients dans la conception de systèmes embarqués depuis plus de 10 ans, et nous avons constaté que le choix de la distribution Linux dépend de la phase du projet et des contraintes du produit final.

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 ISO/IEC 62304 sur les dispositifs médicaux, 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 : couches meta-aestechno dédiées, configuration kernel adaptée (CONFIG_PREEMPT, drivers caméra, ajustements LPDDR4x), device tree étendu pour la carrier board custom, et intégration de la chaîne d'inférence TensorRT dans l'image de production. Un projet exigeant, alignement des versions L4T, patches kernel, 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, et intégré Linux embarqué + RTOS (FreeRTOS ou Zephyr côté MCU, HAL commune) sur des plateformes hétérogènes. Ce spectre 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.

Cas concrets rencontrés en lab

Trois situations rencontrées sur des projets récents illustrent pourquoi le choix de la distribution Linux se joue sur des détails invisibles au niveau « Ubuntu vs Yocto ».

• Cas 1 : BSP Yocto Jetson Orin NX (Q1 2026). Nous avons développé un BSP Yocto personnalisé pour un module NVIDIA Jetson Orin NX. Couche meta-aestechno dédiée empilée sur meta-tegra. Configuration kernel ajustée (CONFIG_PREEMPT, drivers caméra CSI, tuning LPDDR5x). Device tree étendu pour la carrier board custom, intégration TensorRT dans l'image de production. Contrairement à l'idée qu'un BSP Yocto est « juste un fichier de configuration », un BSP industriel correspond à une chaîne complète à maintenir, alignement L4T, patches kernel, reproductibilité CI. Nous préconisons de figer les révisions de layers dans un manifest (repo tool ou kas) dès le premier build.
• Cas 2 : Alpine en conteneur embarqué. Sur un projet de passerelle industrielle à ressources contraintes, nous avons migré un service Docker depuis Debian vers Alpine Linux (musl libc). Dans notre lab, nous avons mesuré l'image finale à 28 Mo, contre 180 Mo avant migration. Nous avons testé la compilation statique d'un agent de monitoring qui supposait glibc. Contrairement au marketing « Alpine partout », la migration musl impose une revue de chaque dépendance binaire. Nous recommandons Alpine pour le greenfield, et un audit préalable pour le portage.
• Cas 3 : Ubuntu LTS pour prototypage rapide. Sur un projet de POC edge AI, nous avons observé qu'Ubuntu 22.04 LTS permettait de valider l'architecture logicielle en 5 jours avant de lancer le chantier Yocto. Contrairement à une approche « Yocto d'emblée », le prototype sur distribution généraliste évite plusieurs semaines d'intégration BSP pour une idée encore mouvante.

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

L'écosystème Yocto correspond à un assemblage de couches et d'outils à articuler, pas un monolithe. 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), politique LTS du kernel Linux (support 2 à 6 ans selon la version), CIP (Civil Infrastructure Platform) pour du super-long-terme industriel (jusqu'à 20 ans)

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 : veille sécurité (CVE kernel, CVE userspace), rebases réguliers, tests de non-régression sur hardware cible. 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.

Arbre de décision : quelle approche pour votre projet

L'arbre de décision ci-dessous permet de trancher entre distribution standard et image sur mesure selon les contraintes réelles du projet. 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

Pour arbitrer entre distribution Linux embarqué généraliste et image sur mesure, cinq repères opérationnels :

• 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 du temps réel dur.
• 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.

FAQ : distributions Linux pour l'embarqué

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 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