Pendant longtemps, concevoir un objet connecté, c'était se concentrer sur l'électronique, le firmware, la radio, l'autonomie, le coût de série. Aujourd'hui, un nouveau sujet s'impose dans presque toutes nos réunions de projet : la cybersécurité. Et il ne s'agit plus d'une case à cocher en fin de parcours.
"Vous avez prévu le CRA ?" — le mot qui revient partout
Ces derniers mois, chez Codium, on entend des questions qu'on n'entendait pas il y a encore deux ans :
Ces questions ne sont plus l'apanage des grands comptes ou des projets défense. Elles viennent de PME, de startups industrielles, d'intégrateurs. Et elles arrivent de plus en plus tôt dans le projet.
Il y a aussi un catalyseur concret, moins médiatisé : depuis quelques mois, de nombreuses collectivités territoriales ont été auditées et sensibilisées par les équipes de l'ANSSI. Le constat a parfois été brutal — certaines ont réalisé qu'elles étaient particulièrement exposées sur leurs systèmes numériques. Et ça s'est traduit très vite dans les appels d'offre : les collectivités veulent désormais remettre à niveau l'ensemble de leurs systèmes, y compris les réseaux d'objets connectés désormais omniprésents dans les métropoles — compteurs de gaz, eau, électricité, régulation du trafic, feux intelligents, capteurs environnementaux. Ces objets, longtemps déployés sans réflexion de sécurité sérieuse, sont maintenant dans le viseur.
Pourquoi ça dépasse largement "un sujet de conformité"
La première tentation, quand on entend "cybersécurité réglementaire", c'est de ranger ça dans la pile des contraintes qualité. Un tampon de plus avant de mettre sur le marché.
Sauf que quand on creuse, on voit très vite que la cybersécurité d'un objet connecté n'est pas un vernis qu'on applique à la fin. C'est une série de vraies questions d'architecture :
Ces questions impactent directement l'architecture électronique, le firmware, la production et la maintenance. On est en plein dans le cœur du développement produit.
Chez Codium, l'un des associés est spécialiste en cybersécurité — et en 2026, ça tombe à pic
« Avoir un associé dont la thèse portait sur la sécurité des objets connectés, dans une période où toute l'industrie découvre soudain que ses produits vont devoir être pensés autrement… c'est objectivement un très bon timing. »
— L'équipe CodiumSoyons honnêtes : pendant longtemps, cette sensibilité à la sécurité a pu paraître un peu excessive. Le réflexe de challenger l'architecture d'authentification dès le premier proto, de poser des questions sur le stockage des clés alors qu'on n'a pas encore choisi le microcontrôleur, de refuser de laisser un JTAG actif en production "juste pour dépanner"… ça a parfois été accueilli avec un sourire en coin. Un peu trop parano pour certains projets. Un peu trop dans les détails pour des clients qui voulaient surtout avancer vite.
Sauf qu'en 2026, on est vraiment contents d'avoir ces réflexes dans l'équipe. Parce que ces questions qu'on posait "en avance" sont exactement celles que posent aujourd'hui les labos, les grands comptes, les collectivités et les donneurs d'ordre. Et les projets qui ont intégré cette réflexion tôt sont les mieux armés pour y répondre.
La cybersécurité n'est pas traitée comme une contrainte subie en fin de projet, mais intégrée dès les premières décisions : choix du microcontrôleur, stratégie de stockage des secrets, architecture de la mise à jour OTA, interfaces de maintenance. Pragmatique, calibrée au niveau de risque réel du produit et au marché visé.
Dans la vraie vie d'un développement électronique embarqué, ça change énormément de choses.
RED et CRA : deux textes, deux niveaux d'exigence
Pour beaucoup de fabricants, les acronymes s'accumulent et finissent par se mélanger. Voici ce qui distingue concrètement les deux textes principaux :
| Critère | Directive RED | Cyber Resilience Act (CRA) |
|---|---|---|
| Portée | Équipements radio (WiFi, BT, LTE-M, LoRa…) | Tout produit avec un composant numérique connecté |
| Objectif | Éviter qu'un produit radio menace les réseaux et les données | Sécurité conçue, maintenue et documentée sur toute la durée de vie |
| Obligations | Conformité avant mise sur le marché | Conception + mises à jour + gestion des vulnérabilités + documentation |
| Calendrier | Volet cyber déjà applicable | Entrée en vigueur progressive d'ici 2027 |
| Impact produit | Architecture sécurité à intégrer avant marquage CE | Cycle de vie complet : du proto jusqu'à la fin de commercialisation |
| Produits concernés | Tout équipement émettant/recevant (WiFi, BLE, LTE-M, Zigbee, GNSS…) | Pratiquement tous les objets connectés, équipements industriels inclus |
Les 4 piliers à intégrer dès la conception
C'est probablement le changement le plus profond. La cybersécurité ne peut plus être traitée après le proto. Voici les quatre sujets qu'on challenge maintenant dès les premières réunions de cadrage :
1. Identité du produit
Chaque équipement doit-il avoir une identité propre — clé unique, certificat individuel, méthode d'authentification robuste ? La réponse est presque toujours oui. Un parc entier d'objets qui partagent la même logique d'accès, c'est une attaque sur un seul dispositif qui compromet potentiellement tout le parc.
Ce choix impacte directement l'architecture électronique (Secure Element ? eFuse ? TrustZone ?), le firmware d'amorçage et le process de production (injection des clés en atelier).
2. Gestion des secrets et des clés
Où sont stockés les secrets ? Dans le microcontrôleur ? Une mémoire externe ? Un élément sécurisé ? Injectés à quel moment du process de fabrication ? Renouvelables comment en cas de compromission ?
Ces questions ne peuvent pas être repoussées en fin de projet — elles conditionnent le choix des composants, l'architecture firmware et parfois le coût BOM. Une mémoire flash externe non chiffrée qui stocke des clés de session, c'est une vulnérabilité gravée dans le silicium.
3. Mises à jour sécurisées (FOTA / OTA)
Un produit connecté sans vraie stratégie de mise à jour est déjà partiellement un problème. Si une vulnérabilité est découverte après commercialisation (et elle le sera), il faut pouvoir corriger le firmware en production, à distance, sans risque d'injection de code malveillant.
Ça implique : signature du firmware, validation d'intégrité avant flashage, mécanisme de rollback en cas d'échec, gestion de la compatibilité de versions, et une infrastructure de distribution sécurisée.
4. Modes maintenance et accès techniques
C'est souvent là que se cachent les futures failles. Les interfaces les plus dangereuses ne sont pas toujours celles exposées à l'utilisateur final — ce sont les ports de debug, les UART de développement, les interfaces JTAG, les backdoors de support laissées actives en production.
Chez Codium, c'est typiquement le genre de point qu'on préfère challenger très tôt, plutôt que le découvrir lors d'un audit ou d'une évaluation labo. Désactiver un JTAG en production, verrouiller un bootloader, conditionner un accès maintenance à une authentification forte — ce sont des décisions d'architecture, pas de configuration.
Le marché évolue : la cybersécurité devient un critère de sélection
Il y a un phénomène de marché qui s'ajoute à la pression réglementaire. Les clients, les intégrateurs, les grands comptes et même certains distributeurs commencent à poser des questions précises sur la sécurité des produits qu'ils intègrent.
Ce n'est plus seulement un sujet de risque technique. C'est un sujet commercial. Un fournisseur capable de documenter l'architecture de sécurité de son produit, de démontrer une stratégie de gestion des vulnérabilités et d'accompagner une démarche de certification — c'est un fournisseur qui remporte des marchés.
Pour les produits critiques : CSPN et IEC 62443
Dans certains contextes — industriels, critiques, ou chez des clients exigeants — la conformité réglementaire de base ne suffit pas. Il faut être capable de le démontrer sérieusement.
Certification de Sécurité de Premier Niveau
Portée par l'ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information), c'est le référentiel de certification produit de référence en France. Elle oblige à structurer rigoureusement le périmètre du produit, ses hypothèses de sécurité, sa documentation et ses mécanismes de protection.
Ce n'est pas un logo commercial. C'est la différence entre "on pense que le produit est sécurisé" et "on est capables de le démontrer sous évaluation indépendante."
Pertinent pour : marchés régaliens, défense, santé critique, smart metering, collectivités publiques.
Sécurité des systèmes industriels
Norme internationale (IEC = International Electrotechnical Commission), reconnue dans le monde entier pour les environnements industriels et OT. Dès qu'on parle d'automatisme, d'infrastructure critique ou d'équipements connectés en milieu industriel, elle s'impose comme le référentiel de fond.
Ce qui la distingue : l'IEC 62443 ne s'arrête pas au produit lui-même. Elle va jusqu'à évaluer les méthodes de développement — processus de conception, pratiques du bureau d'études, gestion des correctifs, traçabilité. En d'autres termes, c'est un audit du produit et de l'organisation qui le produit.
Elle oblige à raisonner sur l'architecture, la segmentation réseau, les niveaux de sécurité (SL 1 à 4) et le durcissement dans un système potentiellement critique.
Pertinent pour : automates, passerelles industrielles, IHM connectées, systèmes SCADA edge, marchés export.
Notre démarche chez Codium : intégrer tôt, pas subir tard
C'est notre conviction très claire, et elle guide notre façon d'aborder les projets depuis maintenant plusieurs années.
- ✓ Dès le cadrage : analyse de risques cyber et revue d'architecture sécurité avant les premiers choix de composants.
- ✓ Choix des composants : intégration de la disponibilité d'un Secure Element, d'un accélérateur crypto matériel ou d'une zone mémoire protégée dès la BOM.
- ✓ Architecture firmware : stratégie d'authentification, de gestion des clés et de mise à jour OTA définie en cohérence avec les contraintes matérielles.
- ✓ Interfaces techniques : revue systématique des accès de debug, maintenance et production — désactivation ou verrouillage avant série.
- ✓ Documentation : production d'une architecture de sécurité documentée, utile pour les clients, les labos et les futures démarches de certification.
- ✓ Maintenance dans le temps : réflexion sur la gestion des vulnérabilités post-commercialisation et la stratégie de mise à jour du parc terrain.
Les produits connectés qui survivront le mieux demain seront ceux dont la cybersécurité aura été pensée dès aujourd'hui — pas rattrapée en urgence avant certification.
Conclusion : en 2026, ce n'est plus une option
Entre la directive RED, le Cyber Resilience Act, les attentes croissantes du marché et les référentiels d'évaluation comme la CSPN ou l'IEC 62443, la cybersécurité des objets connectés est passée d'un sujet périphérique à un sujet central de développement produit.
Chez Codium, on ne prétend pas que ça rend les projets plus simples. Mais on est convaincus d'une chose : ce sujet, traité tôt, avec méthode et avec les bonnes compétences dans l'équipe, est parfaitement gérable. Traité tard, il peut coûter très cher — en reprises techniques, en délais et en crédibilité commerciale.
Et franchement, dans le contexte actuel, on est vraiment contents d'avoir ces compétences cyber dans l'équipe dès le début d'un projet — plutôt que de les regretter amèrement lors d'un audit douloureux à la fin.
Vous développez un objet connecté, un équipement radio ou un produit embarqué ? Parlons de votre projet et de votre stratégie cyber.