Responsable systèmes embarqués

Chez ID-1, j'ai été responsable de la conception et du développement d'un système embarqué industriel destiné à équiper des machines thermodynamiques, principalement des pompes à chaleur.

Ce rôle recouvrait l'intégralité de la chaîne de valeur : de la définition des besoins jusqu'au déploiement terrain, en passant par l'électronique, le firmware, l'industrialisation et l'exploitation à distance.

J'étais seul responsable de l'architecture système, de la conception des cartes électroniques, du développement du firmware, des tests, de la mise en production, du CI/CD, du sourcing des composants (capteurs, connecteurs, batteries, modules 4G, alimentations), ainsi que de l'intégration mécanique. Cette responsabilité complète m'a naturellement amené à raisonner en permanence en termes de produit, et non de simple assemblage technique.

Le produit est un système de mesure connecté, basé sur un cœur numérique ESP32-S3, capable de se connecter en Ethernet, Wi-Fi ou 4G. Il génère un point d'accès local avec portail captif permettant la configuration via une application web embarquée, tout en étant synchronisé avec un serveur distant pour la configuration, la collecte des mesures et les mises à jour logicielles.

Les mesures sont échantillonnées à intervalles réguliers, stockées localement, puis transmises vers une base de données temporelle. Le système est conçu pour pouvoir alerter rapidement en cas d'anomalie, ce qui impose un haut niveau de fiabilité et de robustesse.

L'architecture matérielle repose sur des cartes filles interchangeables, permettant d'interfacer différents types de capteurs (résistifs, tension, tout-ou-rien, bus de communication). Cette modularité permet d'adapter le produit à différents usages sans remettre en cause le cœur du système.

Un second boîtier, plus simple, a été développé sur une architecture proche. J'ai fait le choix de conserver un firmware unique pour les deux produits : le logiciel identifie dynamiquement la cible matérielle en analysant les périphériques disponibles. Ce choix réduit fortement la complexité de maintenance et limite les risques de divergence fonctionnelle.

Le système évolue dans un environnement industriel, avec des contraintes fortes de temps réel, de robustesse terrain et de coût BOM. L'échantillonnage des mesures devait rester régulier et fiable, indépendamment des tâches de communication réseau, parfois instables.

L'utilisation de FreeRTOS s'est imposée pour découpler proprement les responsabilités : acquisition, communication, stockage, supervision. Le firmware est développé en C++, avec une architecture modulaire inspirée des modules ESP-IDF, afin de garantir une séparation claire des rôles et une bonne testabilité. Cette organisation m'a permis d'écrire des tests unitaires complets et d'anticiper les évolutions futures.

Les mises à jour logicielles sont volontairement simples : elles sont distribuées via un serveur FTP sécurisé par mot de passe. Ce choix, peu sophistiqué en apparence, s'est révélé robuste et parfaitement adapté au contexte industriel du produit.

Être seul sur le firmware de deux produits, avec des boîtiers qui sortent de production et d'autres déjà installés chez des clients, impose un filet. Je l'ai construit sous la forme d'une chaîne d'intégration continue, mise en place via Bitbucket pour le firmware ESP32 comme pour les applications web du produit.

Côté embarqué, cette chaîne fait plus que compiler : elle exécute les tests, produit les binaires, et vérifie que la reprogrammation à distance fonctionne sur la nouvelle version. C'est le point le plus critique du produit : un boîtier installé chez un client qu'on ne peut plus mettre à jour, c'est un déplacement sur site — et la confiance du client en moins.

Elle fabrique enfin l'utilitaire de flashage des boîtiers neufs, conçu pour être lancé par mon responsable, qui n'est pas développeur. Mettre un boîtier sortant de production dans son état de livraison ne dépend donc plus de ma disponibilité. Ce réflexe d'outillage, présent sur tous mes postes, fait l'objet d'une fiche dédiée.

Tout au long du projet, j'ai dû arbitrer entre fonctionnalités idéales et réalités industrielles. Ces choix ne sont pas des compromis « par défaut », mais des décisions réfléchies, prises en tenant compte de l'usage réel et du modèle économique.

Le projet a également été très formateur sur le plan industriel.

Aujourd'hui, j'argumente beaucoup plus fermement sur ces aspects dès les premières phases de conception. Avec le recul, une phase de prototypage rapide à base de cartes d'évaluation aurait permis de confronter plus tôt les exigences initiales aux réalités du marché, notamment sur le prix cible.