FPGA, SoC, microcontrôleurs et logiciel embarqué : audit, conseil, formation et assistance technique pour le génie électrique

Cadre réglementaire et normatif du logiciel embarqué

Le Cyber Resilience Act et le firmware

Le règlement (UE) 2024/2847, dit Cyber Resilience Act (CRA), s'applique aux produits comportant des éléments numériques commercialisés dans l'Union, c'est-à-dire, pour un équipement électronique connecté, à son firmware comme à son matériel. Il est entré en vigueur le 10 décembre 2024. Selon la synthèse publiée par la Commission européenne, les organismes d'évaluation de la conformité sont notifiés depuis le 11 juin 2026, les obligations de notification s'appliquent depuis le 11 septembre 2026 et le règlement sera pleinement applicable le 11 décembre 2027.

Les obligations de notification portent sur les vulnérabilités activement exploitées et sur les incidents graves affectant la sécurité du produit : alerte précoce sous 24 heures, notification sous 72 heures, rapport final ensuite, par la plateforme unique de notification gérée par l'ENISA. Le texte attend aussi du fabricant une sécurité pensée dès la conception, une gestion documentée des vulnérabilités tout au long de la durée de support et des mises à jour de sécurité. Ces exigences se traduisent très concrètement dans le firmware : démarrage maîtrisé, authentification des mises à jour, journalisation, inventaire des composants logiciels.

Le texte lui-même est consultable sur EUR-Lex. Certains produits dont la fonction principale relève des annexes III et IV sont soumis à des procédures d'évaluation renforcées, précisées par un règlement d'exécution. Le classement d'un microcontrôleur, d'un système sur puce ou d'un FPGA dans ces annexes fait l'objet d'interprétations divergentes selon les sources : nous ne l'affirmons pas, et chaque fabricant doit l'établir pour son propre produit.

Les autres textes qui touchent le produit

Un équipement électronique reste d'abord soumis aux textes qui régissent son marquage CE (conformité européenne) : directive 2014/35/UE pour le matériel basse tension, directive 2014/30/UE pour la compatibilité électromagnétique, et directive 2014/53/UE pour les équipements radioélectriques, dont les exigences de cybersécurité, applicables depuis août 2025 par le règlement délégué (UE) 2022/30, seront remplacées à compter du 11 décembre 2027 par le cadre du CRA (abrogation par le règlement délégué (UE) 2026/339). Lorsque le produit est une machine, le règlement (UE) 2023/1230 s'applique à compter du 20 janvier 2027 et ajoute des exigences touchant les logiciels et systèmes de commande de sécurité. Les pages de la Commission sur la directive radio et sur les machines en donnent l'état à jour.

Deux points juridiques complètent le tableau. La directive (UE) 2024/2853 range le logiciel parmi les produits pour la responsabilité du fait des produits défectueux, avec une transposition attendue fin 2026 : un défaut de firmware peut donc engager le fabricant comme un défaut de matériel. Par ailleurs, un firmware qui intègre du chiffrement peut relever de la réglementation sur les biens à double usage, ce qui se vérifie avant d'exporter.

MISRA C, IEC 61508-3 et les référentiels de code

MISRA C est un ensemble de lignes directrices de programmation en langage C pour les systèmes sûrs, publié par The MISRA Consortium Limited. Sa dernière édition, MISRA C:2025, a été annoncée en mars 2025. Il s'agit d'un référentiel de bonnes pratiques d'une association, non d'une réglementation. Il n'existe pas de certification MISRA délivrée à une personne ou à un code : la conformité à ces lignes directrices se déclare par le développeur, en s'appuyant sur un outil d'analyse statique et sur un processus, avec la liste des écarts justifiés.

Lorsque le produit remplit une fonction de sécurité, la norme IEC 61508-3, qui traite des exigences relatives au logiciel, entre en jeu avec le reste de la série IEC 61508. Elle fixe un cycle de développement, des techniques et des mesures selon le niveau d'intégrité visé et des exigences sur les outils. Le niveau d'intégrité de sécurité (SIL) est attribué à une fonction de sécurité, jamais à une société ni à une prestation, et une évaluation indépendante par un organisme tiers peut être exigée. Les références d'édition sont à relire sur le site de l'IEC. Les référentiels de logiciel critique propres à d'autres secteurs d'activité sortent du périmètre de ce site et ne sont pas traités ici.

Enjeux pour un fabricant ou un sous-traitant de développement

Rôles et responsabilités

Le fabricant est celui qui met le produit sur le marché sous son nom. Il porte la responsabilité du marquage CE, du dossier technique, de la gestion des vulnérabilités et des mises à jour. Il lui revient aussi de veiller à ce que les composants tiers, propriétaires ou libres, qu'il intègre ne compromettent pas la sécurité du produit. Un sous-traitant de développement, une société d'ingénierie ou un prestataire comme Optédif intervient au titre d'un contrat et sur un périmètre défini, mais ne devient pas fabricant par son conseil. Dès qu'un produit serait livré sous le nom du prestataire, le fabricant, le dossier technique et la répartition des responsabilités doivent être fixés par écrit.

Dans une équipe, les rôles se partagent en général entre le responsable de bureau d'études ou le directeur technique, qui arbitre l'architecture et les délais, les ingénieurs en logiciel embarqué et en électronique, qui réalisent, les ingénieurs test et validation, qui vérifient, et le responsable qualité, qui porte les procédures. La question de la sécurité du produit, longtemps reléguée à la fin du projet, s'invite désormais à chacune de ces fonctions.

Cycle de vie du firmware et nomenclature logicielle

Un firmware vit longtemps après la livraison : corrections, évolutions, correctifs de sécurité pendant la durée de support annoncée. Cela suppose une chaîne de génération reproductible, un dépôt de sources tenu avec rigueur, des tests automatisés dont on suit la couverture, et un inventaire à jour de ce que contient chaque version. La nomenclature logicielle, souvent désignée par l'acronyme SBOM, répond à ce dernier besoin et sert à repérer rapidement les produits touchés lorsqu'une faille est publiée sur une bibliothèque.

Les licences méritent la même attention. Un composant sous licence copyleft, intégré à un firmware commercialisé, peut imposer de publier tout ou partie des sources ; une bibliothèque non maintenue devient un risque de sécurité. Ces sujets se traitent au moment du choix de composant, pas la veille de la livraison. Du côté de la propriété intellectuelle, la cession des livrables développés par un prestataire doit être écrite, de même que l'usage des outils de chacun et la confidentialité du code, protégé comme secret des affaires.

Outils, chaînes de développement et marques

Les environnements de développement et de simulation sont des produits d'éditeurs. Quartus, ModelSim, Vivado, Keil, Code Composer Studio, Simulink ou les outils de Synopsys sont des marques de leurs éditeurs respectifs, et leurs offres évoluent : la documentation de l'éditeur de Quartus indique par exemple que ModelSim a été remplacé par Questa dans sa gamme, à partir des versions 21.1 (Standard) et 21.3 (Pro). Nous ne présentons aucun outil comme qualifié, et nous adaptons nos prestations à ceux que votre équipe utilise déjà.

La même prudence vaut pour les langages et les plates-formes. Rust apporte des protections de sûreté mémoire intéressantes pour le code embarqué, mais son usage ne vaut pas qualification d'une chaîne d'outils. Arduino et ses cartes conviennent bien au prototypage et à l'expérimentation, et leur passage en produit de série demande les mêmes exigences de conception, de test et de documentation que n'importe quelle autre cible.

Ce que nous faisons, et ce que nous ne faisons pas

Ce que nous faisons

Nous auditons du code embarqué, des descriptions FPGA et des chaînes de développement : lecture des sources, paramétrage d'un outil d'analyse statique, classement des écarts, plan d'actions. Nous conseillons sur l'architecture matérielle et logicielle : choix entre microcontrôleur, système sur puce et FPGA, bare-metal ou système d'exploitation temps réel, stratégie de test, prise en compte du CRA dès la conception. Nous concevons des firmwares, des blocs logiques et des bancs de simulation, livrés avec leurs sources, leurs tests et leur documentation. Nous confions à une équipe encadrée, en assistance technique, un lot défini de développement ou de vérification. Nous formons les équipes aux langages et aux méthodes, en intra-entreprise.

Sur le CRA, nous accompagnons le fabricant : analyse des écarts du firmware et du cycle de mise à jour, préparation des éléments du dossier technique, organisation de la veille et du traitement des vulnérabilités, nomenclature logicielle. Nos livrables sont traçables et argumentés, et peuvent être présentés à votre donneur d'ordre ou à un organisme tiers.

Ce que nous ne faisons pas

Optédif ne délivre aucune certification, qualification, licence, agrément ou habilitation, et n'emploie pas de personnel certifié à ce titre. Concrètement, nous ne disons jamais d'un code qu'il est certifié MISRA, car cette certification n'existe pas. Nous ne qualifions ni outil ni processus, et nous ne promettons l'absence d'aucune vulnérabilité. Nous n'attribuons pas de niveau SIL, nous ne remplaçons pas l'évaluation indépendante qu'un niveau élevé peut exiger et nous ne signons pas le dossier du fabricant.

Nous ne déclarons pas non plus la conformité d'un produit au CRA et nous n'apposons pas de marquage CE. Les certifications de sécurité d'un composant, comme la certification de sécurité de premier niveau (CSPN) ou les Critères Communs, relèvent de laboratoires d'évaluation et de l'ANSSI, et nous ne nous y substituons pas. Une revue de code ne remplace pas un essai accrédité, et un banc de simulation que nous développons n'est pas un moyen de mesure accrédité.

Assistance technique : une mission, un lot, une recette

Une mission d'assistance technique est une mission au forfait, définie par un lot : un bloc fonctionnel à décrire et à vérifier, un module de test à écrire, un lot de firmware à développer ou à corriger. Un cahier de mission fixe les livrables, l'échéance et les critères de recette. La charge s'exprime en jours par lot, ou au plus en jours par mois lorsque les lots se succèdent. Les travaux sont réalisés sous la responsabilité et l'encadrement d'Optédif, et la mission se termine par une recette et une passation documentée.

Nous ne plaçons pas de personnel sous votre autorité hiérarchique : vous commandez des livrables, pas des heures de présence, et un responsable de mission reste votre interlocuteur. La confidentialité du code et des données de conception, l'accès aux sources strictement nécessaires au lot et la propriété intellectuelle des livrables sont fixés par contrat avant le démarrage.

Les exemples de cas que nous présentons sur le site sont des exemples construits : ils décrivent ce qui a été produit et décidé, sans résultat chiffré présenté comme réel et sans promesse d'issue. Nous répondons sous 48 heures ouvrées à une première demande, le devis suit l'échange, et une formation peut démarrer au plus tôt sept jours après l'accord.

Références officielles à consulter

Sources européennes

Pour le CRA, la synthèse de la Commission européenne et sa page sur les obligations de notification donnent les échéances et le fonctionnement de la plateforme unique. Le texte du règlement figure sur EUR-Lex, où il convient aussi de chercher le règlement d'exécution qui décrit les catégories de produits importants et critiques.

Sources nationales et normatives

L'ANSSI publie les informations sur la CSPN, avec la liste des centres d'évaluation. L'IEC tient la fiche de la norme IEC 61508-3, et l'association MISRA présente ses lignes directrices et leur usage. Les normes elles-mêmes sont payantes : nous n'en reproduisons ni les exigences ni les critères, et nous renvoyons à leur lecture dans l'édition en vigueur.

Le droit et les échéances évoluent : une relecture de ces références avant toute décision reste indispensable. Notre équipe peut vous aider à replacer ces textes dans le contexte de votre produit et à préparer, sur le thème qui vous occupe, un échange avec votre donneur d'ordre ou avec un organisme tiers.