Pour préparer les questions d'entretien d'un développeur firmware IoT, partez du produit. Un capteur sur pile qui envoie une mesure toutes les dix minutes en LoRaWAN, un objet BLE piloté par une application mobile et un traceur LTE-M ne demandent pas la même expérience radio. Le socle reste commun : du C sur un nRF, un ESP32 ou un STM32, un RTOS comme Zephyr ou FreeRTOS, et un bootloader qui n'accepte que des images signées.
Le CV ne suffit pas à trier. Beaucoup de développeurs embarqués ont monté un démonstrateur BLE sur kit sans jamais suivre un parc d'objets. Demandez des valeurs mesurées : un courant de veille, une autonomie calculée puis vérifiée, un taux d'échec de mise à jour. Une personne qui a vécu la production parle de piles qui décrochent au froid, de resets par le watchdog et de déploiements arrêtés à mi-parc.
Depuis août 2025, les équipements radio connectés à internet vendus dans l'Union doivent respecter les exigences de cybersécurité de la directive RED, et le Cyber Resilience Act impose de signaler les vulnérabilités exploitées à partir de septembre 2026. Vérifiez que la personne sait provisionner une clé par appareil et verrouiller le port de debug. Le PDF ajoute un cas de 20 minutes sur un capteur d'occupation de salles.
Radios, RTOS et outils du développeur firmware IoT
Microcontrôleurs radio (nRF, ESP32, STM32)
La plupart des objets reposent sur une puce qui intègre le cœur ARM ou RISC-V et la radio : les nRF52, nRF53 et nRF54 de Nordic pour le BLE, les ESP32 d'Espressif pour le Wi-Fi et le BLE, les STM32WL ou STM32WB de ST pour LoRa et BLE. Demandez sur quelle puce la personne a livré un produit, et pas seulement monté un prototype.
Zephyr, nRF Connect SDK et FreeRTOS
Le RTOS organise le firmware en tâches avec leurs priorités. Zephyr gagne du terrain, notamment parce que Nordic a construit dessus le nRF Connect SDK et a placé l'ancien nRF5 SDK en maintenance. FreeRTOS reste très répandu et sert de base à l'ESP-IDF d'Espressif. Un profil venu de FreeRTOS a besoin de quelques semaines pour prendre en main le device tree et Kconfig de Zephyr.
Bluetooth Low Energy
La radio courte portée des objets pilotés par smartphone. Le développeur définit les services GATT, règle l'advertising et l'intervalle de connexion, et gère l'appairage avec LE Secure Connections. Les problèmes de déconnexion et de débit se diagnostiquent avec un sniffer BLE, ce qui distingue vite les profils qui ont dépanné un vrai produit.
LoRaWAN
Le réseau longue portée et bas débit des capteurs sur pile, via des passerelles et un serveur de réseau (The Things Network, ChirpStack, un opérateur). En Europe, la bande EU868 limite le temps d'émission, souvent à 1 %. Un bon profil calcule le temps d'antenne d'un message et sait pourquoi on préfère OTAA à ABP.
LTE-M et NB-IoT
Les réseaux cellulaires pour objets, utilisés quand il n'y a ni passerelle ni smartphone à proximité. Le firmware pilote un modem par commandes AT ou par une bibliothèque du fabricant, et vit grâce aux modes PSM et eDRX, sans lesquels la pile se vide en quelques semaines.
MQTT, CoAP et plateformes cloud
Les protocoles qui portent les données jusqu'au serveur : MQTT sur TCP et TLS vers un broker comme AWS IoT Core ou Azure IoT Hub, CoAP sur UDP et DTLS quand chaque octet compte. Le choix pèse sur la batterie à cause du coût des connexions chiffrées.
MCUboot et mise à jour OTA
Le bootloader qui vérifie la signature d'une nouvelle image, l'installe dans un second emplacement et revient à l'ancienne si elle ne se confirme pas. MCUboot est le standard sous Zephyr. C'est la partie du poste où une erreur coûte le plus cher, puisqu'un objet bloqué sur le terrain ne se répare pas à distance.
Sécurité de l'objet
Démarrage sécurisé, clé ou certificat propre à chaque appareil, élément sécurisé ou TrustZone, port de debug verrouillé en production. La directive RED, avec ses normes EN 18031, et le Cyber Resilience Act rendent ces sujets obligatoires pour les produits vendus en Europe.
Mesure de consommation et débogage
Une sonde SWD (J-Link ou équivalent) avec gdb, un analyseur logique pour les bus, et un analyseur de courant comme le Power Profiler Kit II de Nordic ou un Otii. Sans mesure de courant, une autonomie annoncée reste une hypothèse.
Les intitulés varient : développeur firmware, ingénieur logiciel embarqué IoT, référent firmware. Selon l'équipe, la personne écrit aussi les pilotes des capteurs, participe au choix de la puce radio avec l'électronicien ou maintient le logiciel de la passerelle. Un profil confirmé a déjà mené un produit jusqu'à la série : clés provisionnées en usine, cartes verrouillées, versions suivies sur le parc. Un junior sort souvent d'un projet sur kit de développement. Demandez-lui de justifier un mode de veille ou un réglage radio qu'il a choisi lui-même.
Les compétences firmware IoT à vérifier en entretien
- Architecture firmware sur RTOS
- Piles radio BLE et LoRaWAN
- Cellulaire basse consommation et MQTT
- Budget énergie et modes de veille
- Bootloader et mise à jour OTA
- Sécurité de l'objet et des échanges
Cinq questions posées à un développeur firmware IoT
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Un capteur prévu pour tenir deux ans sur pile est à plat en trois mois. Par où commencez-vous ?
Une bonne réponsePar une mesure, avant de toucher au code : un profil de courant sur la carte réelle avec un Power Profiler Kit ou un Otii, sur un cycle complet. On lit le courant de veille, puis la durée et la fréquence des réveils. Les causes habituelles : un périphérique resté alimenté (UART de debug, capteur jamais mis en veille), une broche flottante ou une résistance de tirage qui consomme, un tick du RTOS qui réveille le cœur, une radio qui retente ses envois, un advertising BLE trop rapide, un modem cellulaire qui n'entre jamais en PSM. Ensuite un bilan : courant moyen par état multiplié par sa durée, comparé à la capacité réelle de la pile à la température d'usage.
Signal d'alertePrendre une pile plus grosse ou baisser la fréquence du processeur sans avoir mesuré. Un bilan fait avec les seules valeurs typiques de la datasheet, ou une mesure au multimètre, qui ne voit ni les pics ni leur durée.
Question 2 · confirmé
Une mise à jour OTA part vers 5 000 objets sur le terrain. Qu'est-ce qui empêche qu'une coupure en plein transfert en transforme une partie en briques ?
Une bonne réponseDeux emplacements en flash : la nouvelle image est écrite à côté de celle qui tourne, jamais par-dessus. Le bootloader, MCUboot par exemple, vérifie l'intégrité et la signature avant de basculer, et son mécanisme d'échange reprend là où il s'était arrêté après une coupure. La nouvelle version démarre en test : elle se confirme après un autotest (connexion au réseau réussie, capteurs lus), sinon le bootloader revient à l'ancienne au reset suivant. Côté parc, un déploiement par lots avec suivi des versions remontées, et pas d'installation quand la batterie est trop basse.
Signal d'alerte« On télécharge et on écrase la flash. » Une image contrôlée par un simple CRC, aucun retour arrière possible, ou tout le parc mis à jour le même jour.
Question 3 · confirmé
Un objet BLE perd régulièrement la connexion avec l'application mobile. Quels paramètres regardez-vous ?
Une bonne réponseL'intervalle de connexion, la latence accordée au périphérique et le délai de supervision : avec un délai trop court par rapport aux deux autres, quelques paquets perdus suffisent à couper le lien. Puis le motif de déconnexion remonté par la pile (supervision timeout, déconnexion demandée par le téléphone). Une trace avec un sniffer BLE, nRF Sniffer et Wireshark par exemple, montre les paquets manqués. Viennent ensuite l'antenne et la puissance d'émission, une tâche de priorité haute qui retarde la pile radio, et le téléphone lui-même : Android et iOS imposent leurs propres plages d'intervalle.
Signal d'alerte« C'est le téléphone », sans trace radio. Ou monter la puissance d'émission au maximum comme seule réponse.
Question 4 · confirmé
Des capteurs LoRaWAN installés en Europe envoient 50 octets toutes les deux minutes, et des messages se perdent. Que vérifiez-vous ?
Une bonne réponseLe temps d'antenne. En EU868, la plupart des sous-bandes limitent l'émission à 1 % du temps, et un facteur d'étalement élevé allonge beaucoup chaque trame : à SF12, 50 octets occupent l'antenne environ deux secondes, ce qui impose plusieurs minutes de silence avant l'envoi suivant. Il vérifie aussi les règles d'usage du réseau utilisé, l'ADR qui fait baisser le facteur d'étalement des objets proches d'une passerelle, et la qualité radio (RSSI, SNR) dans la console du serveur de réseau. Pistes : un encodage binaire compact, des envois plus espacés ou regroupés.
Signal d'alerteDes messages en JSON, un uplink confirmé pour chaque mesure, ou l'ignorance d'une limite d'émission réglementaire.
Question 5 · confirmé
Tous les objets d'une série partagent la même clé de chiffrement, écrite dans le firmware. Qu'en pensez-vous, et que proposez-vous ?
Une bonne réponseUne seule carte lue (dump de la flash, port SWD resté ouvert) compromet tout le parc. Il faut une identité par appareil : clé ou certificat propre, provisionné en production, stocké dans une zone protégée (élément sécurisé, TrustZone, stockage protégé de la puce). Le port de debug est verrouillé en sortie d'usine et le démarrage sécurisé n'exécute que du code signé. Côté réseau, TLS ou DTLS avec authentification mutuelle, ou des clés LoRaWAN propres à chaque objet. Il cite les exigences européennes : l'acte délégué cybersécurité de la directive RED (normes EN 18031), applicable depuis août 2025, et le Cyber Resilience Act.
Signal d'alerte« Le firmware est compilé, personne ne lira la clé. » La sécurité par l'obscurité, ou aucune idée du verrouillage du port de debug.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Recrutement d'un développeur firmware IoT : questions fréquentes
Quelle différence entre un développeur firmware IoT et un développeur firmware microcontrôleur ?
Les deux écrivent du C sur microcontrôleur avec un RTOS. Le profil IoT ajoute la radio (BLE, LoRaWAN, LTE-M ou Wi-Fi), le protocole vers le cloud et la vie du produit à distance : autonomie sur pile, mise à jour OTA, identité de chaque objet. Un profil microcontrôleur peut exceller sur les pilotes et le temps réel sans avoir jamais réglé un intervalle de connexion BLE. Précisez dans l'annonce la radio de votre produit.
Zephyr, FreeRTOS ou ESP-IDF : faut-il exiger le RTOS de votre projet ?
Rarement. Tâches, priorités, files et gestion de la veille se transposent d'un RTOS à l'autre. L'effort porte surtout sur l'outillage : Zephyr, base du nRF Connect SDK de Nordic, demande de maîtriser le device tree et Kconfig, ce qui prend quelques semaines à un profil venu de FreeRTOS. ESP-IDF repose sur FreeRTOS. Exigez le RTOS exact seulement si personne dans l'équipe ne peut accompagner l'arrivée.
Faut-il un test technique pour un développeur firmware IoT ?
Un exercice court pendant l'entretien donne plus d'informations qu'un projet à rendre. Montrez cinquante lignes de C avec une interruption trop longue, une variable partagée sans volatile et une mise en veille oubliée, et demandez ce qui pose problème. Une courbe de consommation à commenter marche aussi. La personne raisonne à voix haute, et vous voyez vite si elle a déjà mesuré un objet réel.
Quel matériel de mesure un développeur firmware IoT manie-t-il au quotidien ?
Une sonde de débogage SWD avec gdb, un analyseur logique pour les bus I2C et SPI, un analyseur de courant comme le Power Profiler Kit de Nordic ou un Otii, un sniffer BLE avec Wireshark. Côté réseau, la console du serveur LoRaWAN ou du broker MQTT pour lire ce que l'objet envoie. Demandez dans quelle situation la personne a sorti chacun de ces outils. Une réponse vague indique une pratique limitée au kit de développement.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.




