Pour un ingénieur logiciel embarqué qui travaille sur microcontrôleur, les questions d'entretien dépendent de la cible. Sur un STM32, un NXP, un Nordic ou un ESP32, la mémoire se compte en kilo-octets, le code accède aux registres des périphériques, et une erreur se termine souvent par un reset sans message. Les offres parlent d'ingénieur logiciel embarqué, de développeur C embarqué ou de développeur firmware pour ce même travail, souvent avec une partie Bluetooth Low Energy, CAN ou capteurs.
Un CV « C embarqué, FreeRTOS, STM32 » peut venir d'un projet d'école sur carte d'évaluation. L'expérience produit se repère à des sujets que l'on ne croise qu'en série : une pile de tâche dimensionnée par mesure, un HardFault analysé à partir des registres sauvegardés, une consommation en veille réduite à l'ampèremètre, un bootloader qui revient à l'ancienne image après une mise à jour ratée.
Prévoyez une carte de développement ou au moins un extrait de code réel. Lire une routine d'interruption trop longue et dire ce qui ne va pas prend dix minutes et en dit beaucoup. Le PDF contient 30 questions et un cas de 20 minutes sur un capteur sur pile.
Microcontrôleurs, RTOS et outils du développeur firmware
Microcontrôleurs ARM Cortex-M et ESP32
La plupart des postes tournent sur des Cortex-M de ST (STM32), NXP, Nordic (nRF52, nRF54) ou Microchip, ou sur les ESP32 d'Espressif pour le Wi-Fi et le Bluetooth. Le développeur lit le manuel de référence et les errata du composant. Demandez sur quelles références il a travaillé et ce qu'il a programmé lui-même.
C embarqué et MISRA C
Le C reste le langage du poste. On attend une maîtrise des pointeurs, de volatile, de l'alignement et des comportements indéfinis. MISRA C est un ensemble de règles de codage, vérifié par un analyseur statique et fréquent dès qu'un produit touche à la sécurité.
FreeRTOS
Le noyau temps réel le plus répandu, sous licence MIT et maintenu par AWS. Il gère des tâches à priorité, des files, des mutex et des sémaphores. La version 11 ajoute le multicœur symétrique. ESP-IDF, le kit de développement d'Espressif, repose dessus.
Zephyr
Un RTOS de la Linux Foundation, plus complet que FreeRTOS : pilotes, piles réseau et Bluetooth, configuration par devicetree et Kconfig. Il sort une version tous les six mois et une LTS maintenue plusieurs années (3.7 aujourd'hui). Le kit nRF Connect SDK de Nordic est construit dessus.
HAL et SDK des fabricants
STM32Cube HAL et LL, MCUXpresso SDK, nrfx ou ESP-IDF fournissent les pilotes de base. Ils accélèrent le démarrage d'un projet mais cachent parfois un comportement ou coûtent en flash. Un profil confirmé sait quand descendre au registre.
Bus et périphériques
UART, SPI, I2C, CAN, ADC, timers, PWM, DMA. Le développeur écrit ou adapte leurs pilotes à partir de la fiche technique du composant. Les pannes se diagnostiquent souvent à l'analyseur logique ou à l'oscilloscope.
Bootloader et mise à jour (MCUboot)
Le bootloader vérifie et lance l'application, et gère la mise à jour sur le terrain par câble ou à distance (OTA). MCUboot, utilisé avec Zephyr et d'autres environnements, gère deux emplacements d'image, la signature et le retour en arrière.
Sondes de debug et outils de mesure
J-Link ou ST-LINK sur le port SWD pour flasher et déboguer pas à pas, analyseur logique pour les bus, oscilloscope pour les temps, analyseur de consommation pour la veille. Un candidat qui a travaillé sur du matériel réel cite ces outils sans qu'on les lui demande.
Le poste se publie sous plusieurs intitulés : ingénieur logiciel embarqué, développeur C embarqué, développeur firmware, ingénieur logiciel temps réel. Les offres demandent le C, souvent le C++, un ou deux RTOS (FreeRTOS, Zephyr, parfois ThreadX ou un noyau maison), une famille de microcontrôleurs et des bus de communication. Selon le produit s'ajoutent la radio (Bluetooth Low Energy, LoRa, Wi-Fi), la basse consommation, la sécurité (secure boot, TLS, gestion des certificats) et la mise à jour à distance. Le travail se fait avec les électroniciens : lecture de schémas, mise en route de nouvelles cartes, recherche de pannes entre matériel et logiciel. Aucune certification ne fait référence, le niveau se vérifie sur du code et des cas de débogage.
Les points à contrôler chez un développeur firmware
- C embarqué et gestion de la mémoire
- Interruptions, DMA et pilotes
- RTOS : FreeRTOS et Zephyr
- Bootloader, OTA et sécurité
- Basse consommation et temps réel
- Débogage sur cible et tests
Cinq questions de terrain sur le firmware
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 · junior à confirmé
Une variable modifiée dans une interruption et lue dans la boucle principale semble ne jamais changer, ou change au mauvais moment. Que vérifiez-vous ?
Une bonne réponseD'abord volatile : sans lui, le compilateur peut garder la valeur dans un registre et ne plus relire la mémoire en optimisation. Ensuite l'atomicité : volatile ne protège pas un accès en plusieurs instructions, comme une variable 64 bits sur un Cortex-M 32 bits ou un compteur++ (lecture, modification, écriture). Il faut alors masquer l'interruption le temps de l'accès, ou utiliser les instructions exclusives LDREX et STREX, ou les atomiques C11 quand la cible les supporte.
Signal d'alerte« J'ajoute volatile et c'est réglé », ou une confusion entre volatile et protection contre les accès concurrents.
Question 2 · confirmé
Sous FreeRTOS, une tâche de haute priorité attend une ressource tenue par une tâche de basse priorité et rate ses échéances. Que se passe-t-il, et comment corrigez-vous ?
Une bonne réponseUne inversion de priorité : une tâche de priorité moyenne prend le processeur à la tâche basse qui tient la ressource, et la tâche haute attend sans borne. La correction passe par un mutex FreeRTOS, qui applique l'héritage de priorité, à la place d'un sémaphore binaire qui ne le fait pas. Il ajoute qu'il faut garder la section protégée courte et ne jamais y faire d'attente bloquante, et qu'un mutex ne se prend pas dans une interruption.
Signal d'alerteMonter la priorité de toutes les tâches, ou ne pas connaître la différence entre mutex et sémaphore binaire dans FreeRTOS.
Question 3 · confirmé
Un flux UART à 921 600 bauds perd des octets quand le firmware est chargé. Comment le fiabilisez-vous ?
Une bonne réponseRéception par DMA en mode circulaire dans un tampon, avec l'interruption de ligne inactive (IDLE) ou de demi-tampon pour traiter les données au fil de l'eau, plutôt qu'une interruption par octet. L'interruption reste courte et signale une tâche. Il vérifie le drapeau d'overrun, la priorité de l'interruption face aux autres, la précision de l'horloge pour ce débit et un contrôle de flux matériel (RTS/CTS) si l'émetteur le permet.
Signal d'alerteUne interruption par octet qui traite la trame et fait un printf, ou « on baisse le débit ».
Question 4 · senior
Sur le terrain, un appareil redémarre en HardFault environ une fois par semaine. Comment trouvez-vous la cause ?
Une bonne réponseUn gestionnaire de faute qui sauvegarde les registres empilés (PC, LR, xPSR) et les registres de faute du Cortex-M (CFSR, HFSR, MMFAR, BFAR) dans une RAM non initialisée au reset, puis les remonte au redémarrage avec la cause du reset. Le PC se retrouve dans le fichier map ou avec addr2line sur l'ELF conservé pour chaque version. Il cherche ensuite les causes fréquentes : dépassement de pile, pointeur invalide, accès non aligné, division par zéro activée en faute.
Signal d'alerte« On ajoute des printf et on attend », ou aucune idée de ce que contient la pile au moment de la faute.
Question 5 · senior
Comment concevez-vous une mise à jour à distance qui ne rend jamais l'appareil inutilisable, même en cas de coupure d'alimentation ?
Une bonne réponseDeux emplacements en flash et un bootloader qui reste fixe, comme MCUboot. La nouvelle image est téléchargée dans l'emplacement secondaire, sa signature vérifiée, puis le bootloader l'échange ou la lance en mode test. L'application confirme l'image seulement après un autotest, sinon le bootloader revient à l'ancienne au reset suivant. Il prévoit un numéro de version contre le retour à une image vulnérable et un watchdog actif pendant la mise à jour.
Signal d'alerteÉcrire la nouvelle image par-dessus l'ancienne, ou un bootloader qui démarre une image sans vérifier sa signature.
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
Développeur firmware : les questions des recruteurs
Bare-metal ou RTOS : faut-il exiger les deux ?
Exigez ce que votre produit utilise, et vérifiez les bases de l'autre. Un développeur qui n'a connu que FreeRTOS doit quand même savoir écrire une interruption courte et gérer une variable partagée sans l'aide du noyau. À l'inverse, un profil bare-metal qui rejoint un projet sous RTOS doit apprendre les priorités, les mutex et le dimensionnement des piles. Ce passage se fait en quelques semaines si les bases du C embarqué sont solides.
Un ingénieur Linux embarqué peut-il prendre un poste firmware sur microcontrôleur ?
Le langage est le même, le quotidien diffère. Sous Linux, le noyau gère la mémoire, les pilotes et l'ordonnancement. Sur microcontrôleur, le développeur s'en occupe lui-même, avec quelques dizaines de kilo-octets de RAM et sans protection mémoire le plus souvent. Posez des questions sur les interruptions, la pile, la veille et le bootloader. Un profil Linux qui a déjà écrit des pilotes noyau s'adapte en général plus vite qu'un profil applicatif.
Quel exercice proposer à un développeur firmware ?
Un exercice de lecture vaut mieux qu'un algorithme. Donnez une routine d'interruption UART et une tâche qui consomme les données, avec trois ou quatre défauts : variable partagée sans protection, appel bloquant dans l'interruption, tampon circulaire faux, retour non vérifié. Trente minutes suffisent. Si vous avez une carte, un test technique sur cible, comme faire clignoter une LED par timer puis mesurer le temps d'une routine, montre l'aisance avec les outils.
Le C++ et le Rust ont-ils leur place sur un poste firmware ?
Le C++ est courant, souvent dans un sous-ensemble sans exceptions ni allocation dynamique, avec des templates et du RAII. Vérifiez que le candidat sait ce que coûte chaque fonctionnalité en flash et en RAM. Rust apparaît dans quelques projets, avec les crates embedded-hal ou le framework Embassy, mais la plupart des bases de code restent en C. Évaluez d'abord le C, puis le langage secondaire selon votre code existant.
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.
