comment monter un mini-projet IoT avec ESP32 pour prouver des compétences hardware/firmware en entretien technique

Si vous cherchez un mini-projet IoT à présenter en entretien technique pour montrer vos compétences hardware et firmware, je vous propose une approche simple, rapide à réaliser et très parlante : un capteur de température/humidité connecté basé sur un ESP32, affichage OLED et envoi des données via MQTT. J’ai moi-même réalisé des versions de ce projet pendant mes stages et lors d’ateliers, et c’est un excellent compromis entre électronique, code embarqué et architecture réseau — trois sujets que les recruteurs aiment explorer.

Pourquoi choisir un projet ESP32 pour un entretien ?

Je privilégie l’ESP32 pour plusieurs raisons pratiques : c’est peu cher, il intègre Wi‑Fi et Bluetooth, il possède suffisamment de GPIOs et de puissance pour des démos fluides, et il existe une grosse communauté et des bibliothèques bien maintenues (Arduino, ESP-IDF, PlatformIO). En entretien, vous pouvez facilement expliquer vos choix techniques, montrer un prototype fonctionnel et ouvrir la discussion sur des extensions (sécurité, optimisation énergie, mise à jour OTA, etc.).

Objectifs du mini‑projet

• Mesurer température et humidité avec un capteur (DHT22 ou BME280).
• Afficher la valeur sur un écran OLED (SSD1306).
• Publier les données via MQTT vers un broker public ou local (par exemple Mosquitto ou Cloud MQTT).
• Ajouter une page web simple embarquée ou une API REST pour contrôler/consulter le module.
• Documenter le projet, expliquer l’architecture et fournir le code sur GitHub.

Matériel et bill of materials (BOM)

Choix logiciels et environnement de développement

Pour coder, j’aime utiliser PlatformIO avec VSCode pour la gestion de bibliothèques et la compilation, ou l’IDE Arduino pour une mise en route très rapide. Si vous voulez montrer une démarche plus « ingénieur », référez-vous à ESP-IDF pour expliquer la stack native de l’ESP32.

Bibliothèques utiles :

• Adafruit Unified Sensor + Adafruit BME280 ou DHT sensor library
• Adafruit SSD1306 ou U8g2 pour l’OLED
• PubSubClient ou AsyncMqttClient pour MQTT
• ESPAsyncWebServer si vous voulez héberger une petite page web embarquée

Architecture logicielle (en bref)

Voici l’architecture que je présente en entretien, simple à schématiser :

• Task de lecture capteur : périodique (ex. 10s), filtrage basique et gestion d’erreurs.
• Task d’affichage : mise à jour de l’OLED avec timestamp et indicateur de connexion.
• Module communication : gestion de la connexion Wi‑Fi, reconnexion automatique, client MQTT.
• Web server API : endpoint /status et /config pour lecture/écriture de paramètres (optionnel).
• Persistance minimale : configuration Wi‑Fi et broker stockés en SPIFFS ou preferences.

Étapes de réalisation (méthode pas à pas)

• Monter le circuit sur breadboard : ESP32, capteur et écran I2C. Vérifier les pins SDA/SCL (souvent GPIO21/22).
• Installer PlatformIO + créer un projet « ESP32 Dev Module » ou ouvrir l’IDE Arduino et sélectionner la carte ESP32.
• Faire un sketch minimal : lire le capteur et afficher dans le moniteur série. Objectif : capteur OK.
• Ajouter l’OLED et afficher la valeur localement (test avant réseau).
• Implémenter la connexion Wi‑Fi avec gestion de la reconnexion et test d’un client HTTP simple.
• Intégrer MQTT : publier les mesures sur un topic, souscrire éventuellement à un topic de contrôle (ex. intervalle de mesure).
• Ajouter une petite page web embarquée (optionnel) pour visualiser les données sans broker externe.
• Documenter les étapes et pousser le code sur GitHub en ajoutant un README et des captures.

Exemples de features à montrer en entretien

• Démonstration live : capteur qui publie et l’interface (MQTT Explorer ou Home Assistant) qui affiche les valeurs.
• Analyse d’un échec : par exemple, gestion d’un capteur qui ne répond pas et stratégie de retry/backoff.
• Sécurité : chiffrement TLS pour MQTT (si vous voulez monter en compétence) ou au minimum explication des risques.
• Mise à jour OTA : expliquer comment on pourrait déployer un nouveau firmware à distance.
• Optimisation énergie : mettre en avant l’utilisation du mode deep sleep pour augmenter l’autonomie et montrer un calcul simple d’estimation.

Qué montrer dans le dépôt GitHub / dossier du projet

Lors d’un entretien, j’apporte un lien GitHub organisé. Voici ce que j’y mets toujours :

• README complet : objectifs, schéma de branchement, screenshots et instructions pour reproduire.
• Commentaires clairs dans le code et séparation en modules (network.c/h, sensor.c/h, display.c/h).
• Fichier platformio.ini ou instructions d’installation des bibliothèques.
• Fichiers de configuration exemples (ex. config.example.json) pour ne pas exposer de secrets.
• Captures écran / vidéo courte de la démo (utile si vous ne pouvez pas faire de live demo en entretien).

Questions techniques probables et comment y répondre

• Pourquoi l’ESP32 et pas un autre MCU ? — Répondez sur la connectivité intégrée, les perfs et l’écosystème.
• Comment gérez‑vous la fiabilité réseau ? — Expliquez reconnexion, file d’attente des messages, QoS MQTT selon besoin.
• Comment sécurisez‑vous les communications ? — Montrez que vous connaissez TLS, certificats ou l’utilisation d’un broker sécurisé, et mentionnez le stockage sécurisé des credentials.
• Comment tester votre firmware ? — Tests unitaires si possible, logs structurés, et procédures de validation manuelle.

Pièges et conseils pratiques

• Sur breadboard, certains modules I2C ont des tensions 3.3V ou 5V : vérifiez pour éviter d’endommager l’ESP32.
• Testez la stabilité du capteur : le DHT22 est simple mais moins fiable que le BME280 ; choisissez selon votre temps et priorité.
• Préparez une démo de secours (vidéo/GIF) si le Wi‑Fi du lieu d’entretien est instable.
• Expliquez vos choix : les recruteurs apprécient quand vous justifiez trade-offs (coût vs fiabilité vs complexité).

Ce mini‑projet couvre l’essentiel que j’aime voir chez un candidat hardware/firmware : connaissance du hardware, capacité à structurer du firmware, attention aux cas d’erreur et compréhension des interactions réseau. Si vous voulez, je peux vous fournir un squelette de code en PlatformIO ou un README modèle que vous adapterez pour votre entretien.