Quand j’ai décidé de monter un démonstrateur IoT pour un entretien technique, je m’étais fixé une contrainte volontaire : 6 semaines, budget raisonnable et un matériel facilement trouvable. L’idée n’était pas de faire quelque chose d’ultra-complexe, mais d’avoir un prototype robuste, visuel et racontable — un projet dont je pourrais expliquer chaque choix pendant un entretien. Voici le processus que j’ai suivi (et que je recommande) pour construire un démonstrateur convaincant autour d’un ESP32.
Pourquoi l’ESP32 ?
J’ai choisi l’ESP32 pour plusieurs raisons simples : prix bas, Wi‑Fi et Bluetooth intégrés, puissance suffisante pour du traitement local, et une vaste communauté (Arduino, PlatformIO, ESP-IDF). En entretien, pouvoir dire que le démonstrateur tourne sur un composant industriel populaire rassure le recruteur : cela montre que je sais choisir des technologies pragmatiques, pas seulement des prototypes exotiques.
Objectifs du démonstrateur
- Montrer une chaîne complète : capteur → traitement → cloud → interface utilisateur.
- Être fiable et réplicable en 30–60 minutes lors d’une démo en live.
- Raconter des compromis techniques et économiques (choix de capteurs, protocole, sécurité).
- Préparer un dépôt Git clair et une documentation courte pour partager le projet.
Idée que j’ai retenue
J’ai opté pour un démonstrateur de qualité d’air et de confort (température, humidité, CO2 approximatif via capteur de TVOC), avec affichage local (OLED), collecte de données vers un backend léger (InfluxDB/ThingsBoard ou Firebase), notifications et dashboard web simple. Ce cas d’usage est parlant pour des recruteurs en R&D, systèmes embarqués ou IoT industriel : capteurs, UI, communication, stockage et sécurité.
Matériel utilisé (budget raisonnable)
- ESP32 DevKit v1 (10–12 €)
- Capteur de température/humidité BME280 (5–8 €)
- Capteur de qualité d’air (SGP30 ou CCS811 pour TVOC/eCO2, 6–15 €)
- Écran OLED 0.96" I2C (2–6 €)
- Plaque d’essai, câbles, alimentation 5V (5–10 €)
- Boîtier imprimé en 3D ou petite boîte plexi pour la présentation (optionnel)
Plan en 6 semaines
| Semaine | Objectifs |
|---|---|
| S1 | Prototypage matériel : câblage, lecture capteurs, affichage local. |
| S2 | Développement firmware : structure, gestion Wi‑Fi, abstractions capteurs. |
| S3 | Transmission données : choix du protocole (MQTT/HTTP), serveur minimal. |
| S4 | Dashboard web et stockage : mise en place d’un backend et visualisation. |
| S5 | Sécurité & robustness : reconnection, gestion d’erreurs, mise à jour OTA. |
| S6 | Finition et préparation démo : boîtier, README, script de lancement, tests. |
Choix software et architecture
Mon architecture a été volontairement simple : l’ESP32 lit les capteurs toutes les 10–60 s, affiche l’essentiel sur l’OLED, et publie via MQTT sur un broker (Mosquitto) hébergé sur un Raspberry Pi ou un service cloud. Un petit back‑end (Node‑RED + InfluxDB + Grafana ou un simple Firebase) stocke et affiche les séries temporelles.
J’ai codé le firmware en PlatformIO avec l’ESP-IDF/Arduino comme base — PlatformIO m’offre gestion des bibliothèques et facilité de CI si je veux ensuite automatiser des builds. J’ai structuré le code en modules : Wi‑Fi manager, capteur manager, comms (MQTT), UI et watchdog.
Fonctionnalités auxquelles accorder de l’importance
- Robustesse : gestion des coupures Wi‑Fi, file d’attente des messages en cas de déconnexion.
- Sécurité : MQTT sur TLS si possible, ou au minimum token d’authentification. Montrer que vous avez pensé à la sécurité est un plus pour un recruteur.
- Mesures fiables : filtrage basique des valeurs aberrantes et moyennes glissantes pour éviter un affichage qui “saute”.
- OTA (Over The Air) : même une implémentation basique d’OTA impressionne parce qu’elle montre que vous pensez à la maintenance.
- Observabilité : logs, métriques (uptime, dernière connexion), et un dashboard propre.
Préparer la démonstration en entretien
Voici la checklist que j’utilise avant une démo :
- Brancher tout sur une prise ; emporter un câble USB et une batterie externe.
- Avoir une copie locale du dashboard (ou une version accessible hors réseau) pour éviter les mauvaises connexions.
- Préparer un script de démo de 3–5 minutes : problème, solution technique, live boot, envoi d’une mesure, visualisation et explication des choix.
- Anticiper 2–3 questions techniques (ex. “Pourquoi MQTT ?”, “Comment gérez‑vous la montée en charge ?”, “Quelles concessions faites‑vous pour la sécurité ?”).
Exemples de phrases claires à dire en entretien
- “J’ai choisi MQTT plutôt que HTTP pour son faible overhead et la gestion native de la QoS.”
- “La partie firmware est découpée en modules pour faciliter les tests unitaires et les évolutions.”
- “Pour garantir la fiabilité, le dispositif stocke localement jusqu’à 100 messages en cas de perte réseau et les retransmet.”
Ce que j’ai appris en pratique
En suivant ce plan j’ai réalisé que la simplicité paie : un démonstrateur stable et bien raconté vaut mieux qu’un prototype complexe mais fragile. J’ai aussi constaté l’importance du storytelling technique : expliquez vos compromis (coût vs précision, consommation vs fréquence d’échantillonnage) — les recruteurs aiment comprendre votre raisonnement.
Autre retour : documentez tout. Un README clair, des schémas de câblage et des captures d’écran du dashboard montrent que vous savez livrer un projet, pas seulement coder.
Ressources et bibliothèques utiles
- PlatformIO — gestion du projet et des dépendances.
- PubSubClient ou AsyncMqttClient pour MQTT sur ESP32.
- Adafruit_BME280, Adafruit_SGP30 (ou Sensirion) pour les capteurs.
- Node‑RED + InfluxDB + Grafana pour un backend rapide à déployer.
- ESP OTA examples (ArduinoOTA ou esp_https_ota) pour la mise à jour.
Si vous voulez, je peux vous fournir un squelette de projet PlatformIO, un schéma de câblage et un template de README pour que vous puissiez démarrer en une après‑midi. Dites-moi si vous préférez un backend MQTT+Grafana ou une solution Firebase pour la partie cloud et je vous fournis les commandes et snippets nécessaires.