Présentation de la réalisation

Modlink est un système domotique de type IoT, destiné à être commercialisé par l’entreprise. Son nom traduit son principe : des appareils modulables, connectés les uns aux autres et pilotés par des scénarios configurables. Le système permet aux utilisateurs, professionnels comme particuliers, de créer, modifier et exécuter des scénarios personnalisés à partir des données recueillies par différents capteurs (température, mouvement, lumière) et de déclencher des actions automatisées via des actionneurs (LED, moteurs, relais).

Chaque scénario peut inclure l’envoi de notifications par SMS ou courriel selon des conditions définies. Le système est compatible avec une large gamme de capteurs et d’actionneurs : grâce à une architecture modulaire, l’utilisateur peut ajouter de nouveaux éléments sans reconfigurer l’ensemble, et accéder à l’objet à distance, hors du réseau local.

Introduction et objectifs

Modlink a été développé pour offrir aux utilisateurs une solution domotique unifiée, capable de piloter une multitude d’appareils à partir d’une interface unique, sans dépendance à un service cloud externe. Plusieurs objectifs de qualité ont structuré le projet : la fiabilité et la stabilité des scénarios configurables, la sécurité des données et des équipements, et la compatibilité avec un large éventail de matériels IoT.

Le projet s’est également attaché au respect des normes en vigueur : la conformité CE (Conformité Européenne) pour la sécurité, la santé et la protection de l’environnement au niveau européen ; les exigences de compatibilité électromagnétique afin de prévenir toute interférence entre appareils ; et la norme NF C 15-100 pour la sécurité des installations électriques. Les objectifs principaux peuvent se résumer ainsi :

• Modularité : permettre à l’utilisateur d’ajouter ou de retirer des capteurs et actionneurs sans reconfigurer l’ensemble du système, grâce à une architecture extensible ;
• Accessibilité : rendre l’objet pilotable aussi bien localement qu’à distance, via une interface web simple et intuitive ne nécessitant aucune interaction avec le code ;
• Sécurité et conformité : garantir la confidentialité et l’intégrité des données et des actions par le chiffrement des communications et l’authentification des utilisateurs, dans le respect des normes applicables ;
• Autonomie : assurer un fonctionnement fiable même hors connexion, en privilégiant le traitement local des scénarios.

Contexte humain

Comme pour ma réalisation précédente, le projet m’a été confié dans le cadre de mon alternance au sein de l’entreprise Alcante, dont j’étais le seul développeur : j’ai conçu et déployé la solution de bout en bout. L’entreprise est composée de deux personnes :

• Jorge Beja, mon tuteur, dirigeant et technicien de l’entreprise, à l’origine de la commande et de la validation des orientations du projet, dans un rôle proche de celui d’un product owner ;
• Isabelle Saraiva, secrétaire, qui gère les répondeurs professionnels, les commandes clients et assure en partie la comptabilité de l’entreprise.

Contexte technique

Le cœur du système repose sur une carte ESP32, connectée au réseau en Wi-Fi ou en Ethernet. L’architecture logicielle est hybride : elle combine une architecture monolithique légère sur l’ESP32 pour le traitement local des scénarios et une architecture décentralisée pour l’accès distant, assuré par un reverse proxy et une liaison SSH. Ce choix garantit une exécution rapide des scénarios tout en offrant flexibilité et sécurité des accès distants. L’ensemble suit une approche MVC (Modèle-Vue-Contrôleur) adaptée à un système embarqué : le modèle correspond aux données des capteurs et aux scénarios, la vue à l’interface web, et le contrôleur au firmware de l’ESP32 qui orchestre l’exécution des scénarios et les communications réseau.

Backend — Le backend est assuré par l’ESP32 lui-même, qui gère les capteurs, les actionneurs et l’exécution des scénarios. Le code est écrit en C++, avec le framework ESP-IDF (SDK dédié aux microcontrôleurs Espressif, donnant un accès précis au Wi-Fi, au Bluetooth et aux GPIO) complété par Arduino pour réutiliser des bibliothèques courantes. Les données critiques comme les scénarios sont stockées localement au format JSON, ce qui permet une exécution rapide sans interroger constamment une base distante — un point essentiel pour la réactivité en temps réel.

Frontend — L’interface est développée en Svelte, un framework JavaScript moderne et léger, avec TypeScript pour bénéficier d’un typage statique. Contrairement à React ou Vue, Svelte déplace l’essentiel du travail à la compilation et manipule directement le DOM sans Virtual DOM, ce qui réduit la charge à l’exécution — un atout déterminant sur un ESP32 aux ressources limitées. Une première piste s’appuyait sur React avec Next.js, mais Svelte s’est révélé mieux adapté : une bibliothèque dédiée permet d’en compiler puis d’en compresser les ressources afin de les loger directement dans la mémoire de l’ESP32, où elle est servie par le serveur AsyncWebServer. Ainsi stockée sur l’objet, l’interface permet de configurer les scénarios, de gérer capteurs et actionneurs et de visualiser les données sans manipuler le code. La bibliothèque Svelte Flow est utilisée pour modéliser les scénarios sous forme de diagrammes interactifs (nodes et edges).

Base de données — L’ESP32 s’appuie sur une base de données relationnelle MySQL, gérée à distance via phpMyAdmin, pour les informations à conserver dans la durée : identifiants uniques des appareils pour la connexion distante, informations de connexion Wi-Fi, données utilisateur et historique des modifications. La conception a suivi les étapes classiques (MCD, MLD puis schéma physique en SQL), avec des contraintes de clés étrangères garantissant la cohérence des données. Le site central destiné aux professionnels, projet lié mais distinct, s’appuie quant à lui sur une base NoSQL MongoDB pour une gestion flexible et scalable des scénarios.

Communication et sécurité — Pour l’accès distant, un reverse proxy est mis en place entre le serveur web distant et l’ESP32 : il reçoit les requêtes des utilisateurs et les redirige vers l’objet, sans exposer directement celui-ci à Internet. Une connexion SSH, établie de l’ESP32 vers le serveur à l’aide de la bibliothèque LIBSSH2, assure les communications critiques et la maintenance à distance par la technique du reverse forward port. Les échanges sont sécurisés par HTTPS (certificats SSL/TLS) ou, à défaut, par un chiffrement symétrique AES-CBC 128 bits associé à un HMAC et encodé en Base64. Le protocole ESP-NOW, propre aux cartes Espressif, a par ailleurs été mis en place pour permettre une communication directe et à faible latence entre ESP32, sans passer par un réseau Wi-Fi traditionnel.

L’enjeu

L’enjeu principal était de concevoir une solution domotique réellement modulaire et autonome, là où la plupart des produits du marché imposent une application mobile propriétaire et une dépendance permanente à des services cloud. Modlink devait au contraire offrir une gestion centralisée et planifiée via une interface web, fonctionner aussi bien en ligne qu’hors ligne, et rester compatible avec une grande variété de capteurs et d’actionneurs sans reconfiguration lourde.

Cet objectif imposait un équilibre délicat entre le traitement local, nécessaire à la réactivité et à l’autonomie, et l’accès distant sécurisé. Il fallait de plus concilier cette richesse fonctionnelle avec les ressources restreintes de l’ESP32, tout en garantissant la conformité aux normes applicables (CE, compatibilité électromagnétique, NF C 15-100), condition indispensable à une commercialisation.

Les risques

Le principal risque était d’ordre sécuritaire, le système manipulant des données utilisateur et pilotant des équipements électriques à distance. J’ai donc mené une veille continue sur les vulnérabilités, en m’appuyant sur les bases CVE et NVD ainsi que sur le top 10 de l’OWASP, et en analysant les dépendances du projet avec des outils tels que npm audit et Snyk.

Plusieurs catégories de menaces ont été traitées : les injections SQL, contrées par des requêtes préparées, la validation des entrées et une restriction stricte des privilèges sur la base ; les attaques XSS, par l’échappement des données affichées, une Content Security Policy et l’assainissement des saisies ; les attaques de type Man-in-the-Middle, par le chiffrement des échanges (HTTPS et clé partagée entre ESP32) ; les attaques par rejeu, par l’usage de jetons uniques par requête ; et les failles de session, par la régénération des identifiants après authentification et la sécurisation des cookies (Secure, HttpOnly, SameSite).

Un second risque tenait aux ressources limitées de l’ESP32, qui devait gérer simultanément les scénarios, le serveur web, le SSH et le chiffrement. Ce risque a été maîtrisé par l’optimisation des données échangées (JSON compact), la compression gzip des pages web et un traitement prioritaire des commandes critiques.

Les étapes

Le projet s’est déroulé sur la durée de mon alternance, selon les grandes étapes suivantes :

• Conception : rédaction du cahier des charges, définition de l’architecture logicielle et matérielle, et prototypage de l’interface utilisateur ;
• Développement du backend : mise en place de la liste de commandes pilotant capteurs et actionneurs, conception d’une structure d’appareils fondée sur des classes C++ extensibles, et développement de l’algorithme d’exécution des scénarios ;
• Développement du serveur web et de l’API REST embarqués sur l’ESP32, puis mise en place du reverse SSH et du protocole ESP-NOW ;
• Développement du frontend en Svelte, avec modélisation des scénarios via Svelte Flow ;
• Sécurisation de l’ensemble et phase de tests (tests fonctionnels et test unitaire de la fonction critique de reconstruction graphique des scénarios).

Méthodologie de suivi

Comme pour mes autres réalisations, j’ai adopté une méthodologie inspirée de l’agilité, dans une version simplifiée du modèle Scrum. Le développement s’est déroulé de manière itérative et incrémentale : chaque cycle débutait par un échange avec mon tuteur sur une nouvelle fonctionnalité à développer. Je la concevais, l’implémentais puis la testais, avant de la soumettre à sa validation — il jouait un rôle proche de celui d’un product owner. Une fonctionnalité conforme était intégrée définitivement ; dans le cas contraire, des ajustements étaient effectués avant une nouvelle validation. Ce fonctionnement a garanti un développement progressif et contrôlé, tout en permettant d’intégrer rapidement les retours.

Gestion du code source et traçabilité

En tant que développeur unique du projet, je n’avais pas besoin d’outils de collaboration entre développeurs, mais il était impératif d’assurer la sauvegarde et la traçabilité de mon travail. J’ai donc créé un dépôt Git sur le serveur Alcante, me permettant de conserver une copie sécurisée du projet à distance tout en suivant les versions du code. J’ai utilisé différentes branches pour développer plusieurs fonctionnalités en parallèle sans affecter le code principal, avec des commits et des pushs réguliers et documentés, facilitant la compréhension du code par de futurs développeurs.

Les acteurs

Trois types d’acteurs sont intervenus sur ce projet :

• Moi-même, en tant que concepteur et développeur unique : j’ai pris en charge l’intégralité de la réalisation, de l’architecture jusqu’aux tests ;
• Jorge Beja, mon tuteur, à l’origine de la commande et de la validation des orientations du projet ;
• Les utilisateurs finaux, professionnels et particuliers, visés par la commercialisation du produit.

Les résultats

Le projet a abouti à un prototype fonctionnel capable d’exécuter des scénarios personnalisés. Le cœur du système — la structure d’appareils extensible, l’algorithme d’exécution des scénarios, le serveur web et l’API REST embarqués, ainsi que l’interface Svelte de modélisation graphique des scénarios — est opérationnel. La liaison SSH sécurisée par la base de données, le chiffrement des échanges et les bases du protocole ESP-NOW ont également été mis en place.

Faute de temps, certaines fonctionnalités n’ont pas été entièrement finalisées : la totalité des commandes prévues, l’authentification complète du site web, l’intégration à Home Assistant et l’exploitation avancée d’ESP-NOW en sont restées au stade des fondations, prêtes pour une extension ultérieure. Les fonctionnalités essentielles étant en place, j’ai néanmoins pu mener des tests fonctionnels ainsi qu’un test unitaire sur la fonction critique de reconstruction graphique des scénarios.

Principaux éléments de preuve

• Architecture de données documentée : conception relationnelle MySQL selon les étapes MCD, MLD et MPD, complétée par une base MongoDB pour le site central.
• API REST embarquée sur l’ESP32 et échanges protégés par HTTPS ainsi que par un chiffrement AES-CBC 128 bits associé à un HMAC.
• Interface Svelte/TypeScript optimisée et compressée pour la mémoire flash de l’ESP32, précédée de wireframes validés.
• Fonctionnement validé par des requêtes de contrôle, un test unitaire Jest et une documentation du suivi et de l’architecture du projet.

Les lendemains du projet

Modlink étant mon projet le plus important, je l’ai poursuivi bien au-delà du rapport initial : le développement est aujourd’hui presque abouti. Les parties laissées en fondation — la liste complète des commandes, l’authentification du site, ESP-NOW et l’intégration à Home Assistant — ont vocation à être finalisées, et le produit est destiné à être commercialisé par l’entreprise. Le site central de gestion multi-ESP32, adossé à la base NoSQL, constitue un prolongement naturel du système.

Mon regard critique

Avec le recul, ce projet m’a confronté à une complexité bien supérieure à celle de mes réalisations précédentes, et c’est précisément ce qui l’a rendu si formateur. La principale difficulté a été de faire cohabiter, sur une carte aux ressources restreintes, un nombre important de responsabilités : exécution des scénarios, serveur web, API REST, SSH, chiffrement et communication inter-appareils. Cette contrainte m’a obligé à un vrai travail d’optimisation et à des choix techniques réfléchis, comme le recours à Svelte pour alléger le frontend ou à la compression des échanges.

Si c’était à refaire, j’anticiperais davantage certaines fonctionnalités transversales, comme l’authentification, plutôt que de les traiter en fin de parcours, afin de ne pas les laisser inachevées. Ce projet m’a néanmoins permis de monter en compétences sur l’ensemble de la chaîne IoT, du firmware embarqué à l’interface web, et de consolider ma capacité à mener un projet technique d’envergure de bout en bout. Il a confirmé mon intérêt pour l’Internet des objets et conforté mon choix de voie professionnelle.