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 qui doit fonctionner après dix ans de production série, supporter des mises à jour OTA sécurisées, 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.
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.
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.
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 reste pertinent pour les projets simples ou les équipes existantes. 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.
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.
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.
- 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.
Hardware
Un PCB livré chez nous est un PCB qu'on peut fabriquer en série, certifier sans reprise, 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. 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.