Firmware embarqué documenté, maintenable, et conçu pour vivre dix ans.
Un firmware industriel n'est pas un script qui marche le jour de la livraison. C'est un système complexe, sous Zephyr, FreeRTOS ou Linux, qui doit fonctionner après dix ans de production série, se mettre à jour à distance en toute sécurité, remonter des statistiques de télémétrie sur son fonctionnement, et résister à un environnement réglementaire qui évolue (CRA, IEC 62443).
Expertise pilotée par Hugues Orgitello, ingénieur en conception électronique et fondateur d'AESTECHNO Montpellier (10+ ans d'expérience, formateur agréé CAP'TRONIC).
- IEC 62304
- IEC 62443
- ETSI EN 303 645
- Cyber Resilience Act (CRA)
- MCUboot
- RAUC
Le firmware industriel doit survivre à son équipe
Un produit industriel reste en série 5 à 15 ans. Pendant cette période, l'équipe qui l'a conçu peut changer trois fois. Un firmware qui ne peut pas être maintenu par quelqu'un d'autre que son auteur est une dette technique masquée, qui se révèle au pire moment, quand un client critique demande un correctif urgent.
Chez AESTECHNO, avec plus de 10 ans d'expérience en conception embarquée, nous écrivons du firmware documenté en intention : pourquoi ce choix d'architecture, pourquoi ce timing, pourquoi cette priorité d'interruption. Le code lui-même reste conventionnel et lisible. Une équipe successeur peut prendre le relais en quelques semaines, pas en six mois. Voir notre guide complet : Logiciel embarqué industriel.
OTA sécurisé : pas une option, une exigence
Le Cyber Resilience Act (CRA) impose à partir de 2027 que tout produit connecté supporte des mises à jour de sécurité pour la durée de vie attendue du produit. Sans OTA sécurisé, aucun produit IoT industriel ne sera commercialisable en Europe.
Nous intégrons systématiquement : secure boot ancré dans le hardware (chaîne de confiance vérifiée à chaque démarrage), signature ECDSA sur chaque image OTA (MCUboot pour MCU, RAUC pour Linux), stockage chiffré des secrets, TLS 1.3 pour toute communication réseau, alignement IEC 62443 pour les produits industriels.
La gestion des CVE issues du SBOM demande une couche de priorisation opérationnelle, un point validé par Thierry Durand d'Embedded Expertise, notre pair indépendant en cybersécurité embarquée : scanner avec Grype ou Trivy ne représente que la première étape, le vrai travail d'ingénierie est la priorisation et le pilotage de la remédiation dans le contexte opérationnel du produit. Voir notre article sur la cybersécurité IoT industrielle.
Mise à jour à distance et télémétrie : garder la main sur la flotte
Un produit connecté ne s'arrête pas à la livraison : il faut pouvoir le corriger, le faire évoluer et savoir comment il se comporte sur le terrain. Chez AESTECHNO, nous développons la mise à jour à distance (OTA) et la remontée de statistiques de télémétrie dans le firmware lui-même, sous Zephyr comme sous FreeRTOS. Une mise à jour à distance doit pouvoir échouer sans laisser l'équipement inutilisable : image signée, vérifiée avant installation, et retour possible à la version précédente si le nouveau firmware ne démarre pas correctement.
La télémétrie répond à une autre question : que se passe-t-il réellement sur la flotte ? Selon le produit, le firmware peut remonter des statistiques de fonctionnement comme les causes de redémarrage, la version installée, l'état de la batterie ou la qualité de la liaison radio. Ces données servent à décider quand déployer un correctif, à vérifier qu'une mise à jour s'est bien passée, et à repérer un problème avant qu'il n'arrive chez le client. Voir aussi notre article sur le DevOps embarqué et la CI/CD.
Choix RTOS : Zephyr, FreeRTOS, NuttX, Linux
Le choix du RTOS ou du système d'exploitation embarqué n'est pas idéologique, il découle des contraintes du produit : empreinte mémoire, certification cible, écosystème de drivers, contraintes temps réel.
Sur MCU contraint (Cortex-M0/M4 avec 64-256 KB de RAM), Zephyr offre l'écosystème le plus moderne et la meilleure maintenabilité long terme. FreeRTOS, plus léger et très répandu, porte lui aussi des firmwares complexes : nous développons sur les deux, et nos produits en production tournent sur les deux. Le choix entre eux dépend des drivers disponibles pour le MCU, du code existant et de la certification visée, pas de la complexité du projet. Pour Linux embarqué (Cortex-A, MPSoC), Yocto avec un BSP propre et un SBOM (CycloneDX, SPDX) est notre choix par défaut sur tout produit destiné à passer la conformité CRA. Au Q1 2026, nous avons livré un projet Jetson Orin NX avec un BSP entièrement personnalisé, développé sous Yocto pour un client industriel. Voir notre article : Comparatif des distributions Linux embarquées.
Conformité IEC 62304, pour le médical
Quand le firmware embarque un dispositif médical, IEC 62304 ajoute une discipline documentaire stricte : classification logicielle (A, B, C selon impact patient), traçabilité exigences ↔ code, gestion des SOUP (logiciels d'origine inconnue, c'est-à-dire bibliothèques tierces), processus de mise à jour validé.
Notre approche : structurer le firmware en composants à criticité claire, isoler les fonctions Class C dans un module dédié (qualifié sous IEC 62304), traiter le reste en Class A/B avec une rigueur ISO 13485. Cela limite l'effort de qualification au strict minimum réglementaire. Nous avons développé des pipelines CI/CD pour plusieurs projets, avec un auto-déploiement conditionné à la validation complète des tests : sur serveurs ou sur le Play Store selon le produit. Voir : DevOps embarqué et CI/CD.
FAQ
- Linux embarqué ou RTOS ? Comment décidez-vous ?
La règle simple : si le produit a besoin d'un stack réseau complet (TCP/IP, TLS, multitâche), d'une UI graphique riche, ou d'un système de fichiers, Linux. Si le produit est temps-réel dur (latence < 1 ms), basse consommation (sub-mA en moyenne), ou sécurité fonctionnelle critique, RTOS. Beaucoup de projets industriels combinent les deux : un MPSoC avec Linux côté applicatif et un MCU compagnon (Zephyr ou FreeRTOS) pour les fonctions temps-réel. Voir Zephyr, FreeRTOS ou Linux pour l'embarqué temps-réel.
- Développez-vous du firmware complexe sous FreeRTOS ou Zephyr ?
Oui. Nous développons du firmware complexe sous FreeRTOS comme sous Zephyr, et nos produits en production tournent sur les deux. La complexité du projet ne départage pas les deux RTOS : FreeRTOS est léger et très répandu, Zephyr intègre un modèle de drivers et une pile réseau. Nous choisissons selon les drivers disponibles pour le MCU, le code existant du client et la certification visée. Voir Zephyr, FreeRTOS ou Linux pour l'embarqué temps-réel.
- Proposez-vous la mise à jour à distance et la télémétrie ?
Oui. Nous développons la mise à jour à distance (OTA) et la remontée de statistiques de télémétrie dans le firmware. La mise à jour est signée et vérifiée avant installation ; la télémétrie remonte, selon le produit, des indicateurs comme les causes de redémarrage, la version installée ou l'état de la batterie, pour piloter les correctifs sur la flotte déployée.
- Comment gérez-vous les CVE qui apparaissent post-déploiement ?
Génération automatique du SBOM (CycloneDX) à chaque build, scan continu (Grype, Trivy), et, c'est le travail clé, priorisation par contexte opérationnel : quelle est la surface d'attaque réelle de cette CVE sur ce produit déployé chez ce client ? La majorité des CVE remontées par un scan brut ne sont pas exploitables dans le contexte produit, mais elles encombrent les rapports. Nous travaillons avec Thierry Durand (Embedded Expertise) sur cette discipline de priorisation.
- Pouvez-vous reprendre un firmware existant à corriger ?
Oui. Reprendre un projet électronique en échec ou en dérive est un de nos cas typiques. Nous commençons par un diagnostic technique structuré (architecture, qualité du code, dette technique, modes de défaillance observés), puis proposons un plan de stabilisation chiffré avant tout engagement long terme. Voir notre article : Reprendre un projet électronique en échec.
Très bonne collaboration avec AESTECHNO ! Une équipe à la fois sympathique, efficace, flexible et réactive. Leur expertise, aussi bien en conception électronique, qu'en développement logiciel et mise au point système, a été un véritable atout pour la réussite du projet. Je recommande sans réserve.
Médical
Concevoir un dispositif médical, ce n'est pas adapter une carte industrielle après coup. C'est intégrer la sécurité patient, la traçabilité du logiciel et la gestion du risque dans chaque décision d'architecture, du cahier des charges au dossier technique MDR. Chez AESTECHNO, avec une équipe forte de plus de 10 ans d'expérience en conception et 65 projets livrés depuis 2022, nous avons développé un éclairage spécialisé de classe médicale et conçu de nombreux produits conformes aux normes CE et internationales.
Hardware
Un PCB livré chez nous est un PCB qu'on peut fabriquer en série, certifier dès la première campagne d'essais, et poser en usine sans surprise. La CEM, les standards IPC et la DFM sont intégrés au schéma, pas ajoutés après que le prototype ait fumé.
Industrialisation
Le piège classique : un design fonctionnel en proto, qui demande six mois et un re-spin pour tenir en production série. Chez AESTECHNO, notre signature technique, c'est l'inverse : la DFM, les standards IPC et la testabilité sont intégrés au schéma initial. Le proto est déjà une carte fabricable. Nous livrons un prototype fonctionnel et optimisé pour la pré-série, dès le premier essai ; 100% de réussite aux certifications CE/FCC au premier essai, sur des dizaines de campagnes menées en plus de 10 ans de pratique.