Comment AptarGroup a fait monter un ingénieur embarqué sur Zephyr RTOS en quatre jours

Fondé en 1992 et coté au NYSE, AptarGroup conçoit et fabrique des solutions de distribution de doses pour la pharmacie, la beauté, la santé grand public et l'agroalimentaire. Si vous avez un jour utilisé un spray nasal, un auto-injecteur d'insuline ou une pompe doseuse de parfum, vous avez très probablement tenu un dispositif Aptar dans la main.

Le groupe est devenu en trente ans l'un des leaders mondiaux du dispositif médical de précision. Ses produits doivent répondre à des contraintes extrêmes : précision micrométrique de la dose délivrée, stérilité, conformité IEC 62304 pour les logiciels de dispositifs médicaux, fiabilité sur des millions d'unités produites.

Sa division Aptar Digital Health pousse aujourd'hui une génération de devices connectés : auto-injecteurs avec adhérence au traitement remontée par BLE, inhalateurs intelligents qui mesurent la qualité de l'inhalation, capteurs ingérables. Cette feuille de route impose un OS temps réel moderne, sécurisé et certifiable — Zephyr s'est imposé comme la référence.

Les équipes firmware d'Aptar ont historiquement développé en C bare-metal sur Cortex-M, avec des bibliothèques HAL constructeur. Cette approche a fonctionné tant que les devices étaient déconnectés et mono-tâche. Pour la nouvelle génération connectée — BLE, OTA, plusieurs threads concurrentiels, gestion fine de la consommation — elle atteint ses limites.

Le choix s'est porté sur Zephyr : RTOS open-source soutenu par la Linux Foundation, supporté par les grands fondeurs (Nordic, NXP, ST), avec un écosystème BLE mature et une compatibilité native MCUboot pour la mise à jour firmware sécurisée. Zephyr permet aussi d'aller chercher la conformité IEC 62304 sans repartir de zéro.

Pour amorcer cette migration, Aptar avait besoin d'un référent technique en interne capable de cadrer l'architecture, de produire les premiers builds et d'accompagner la diffusion progressive vers le reste de l'équipe. C'est ce profil-clé qui a été confié à Learni — avec une exigence : qu'à la sortie, il puisse livrer du code en repo dès la semaine suivante.

Learni a conçu un parcours individuel de quatre jours, livré en présentiel sur le site Learni de Lyon, et calé sur les cibles matérielles réelles d'Aptar (cartes nRF52 pour la radio BLE, STM32 pour le contrôle moteur). L'apprenant est reparti avec un kit de développement, un projet Zephyr forké du repo officiel, et un prototype fonctionnel — pas une démo de slide.

Le formateur, ingénieur embarqué senior actif sur le projet upstream Zephyr et contributeur à la base de code Nordic Connect SDK, a structuré la formation autour d'un fil rouge : construire un device de mesure connecté minimal, du bring-up jusqu'à l'OTA sécurisée. Tous les concepts ont été abordés au moment où ils servaient.

À la fin de la quatrième journée, l'apprenant disposait : d'un projet Zephyr buildé sur trois cibles, d'une stack BLE GATT custom, d'un schéma devicetree maîtrisé, d'un MCUboot opérationnel avec rollback automatique, et d'un plan de migration de leur premier device de production — chiffré, séquencé, prêt à être présenté en review d'architecture.

À l'issue des quatre jours, l'apprenant repart avec un projet Zephyr buildé sur trois cibles, un MCUboot opérationnel et un plan de migration concret pour le premier device de production visé. La satisfaction à chaud est de 100 %.

Au-delà des chiffres, la valeur du format un-pour-un se mesure à la profondeur de l'accompagnement : on ne se contente pas de couvrir un syllabus, on tranche aussi les choix d'architecture (BLE custom vs Nordic SoftDevice, gestion du devicetree multi-cibles, stratégie OTA) qui auraient nécessité plusieurs semaines de prototypage en autonomie.