Présentation de la réalisation

Cette cinquième réalisation, la plus récente de mon alternance chez Alcante, constitue le prolongement direct de Modlink : une plateforme de pilotage d’éclairage professionnel au protocole DMX512, bâtie dans le même écosystème et sur les mêmes briques logicielles. Là où la première réalisation Modlink portait sur un appareil à deux entrées et deux sorties, ce nouvel appareil est un module « mère » doté de deux entrées 220 V, qui joue le rôle de central de commande d’un parc d’appareils « esclaves » répartis dans le lieu.

Le principe est le suivant : l’appareil mère ne produit lui-même aucun signal DMX. Il reçoit les consignes de l’utilisateur depuis l’interface web Modlink, les traduit en commandes et les diffuse sans fil aux esclaves via le protocole ESP-NOW que j’avais mis en place lors de Modlink ; chaque esclave génère alors localement son propre univers DMX de 512 canaux et le restitue sur une sortie XLR 3 broches vers les projecteurs qui lui sont raccordés. Les esclaves remontent en retour leur état à l’appareil mère, qui centralise ainsi la supervision de l’installation.

Introduction et objectifs

Le DMX512 est aujourd’hui réservé, dans les faits, aux installations d’envergure : il suppose un câblage complet du lieu et une console physique de pilotage, ce qui le rend difficilement accessible aux petites structures. L’objectif de cette réalisation est d’en proposer une déclinaison légère et sans fil, pilotable depuis un simple navigateur, y compris à distance grâce au tunnel SSH déjà exploité par Modlink. Les objectifs principaux peuvent se résumer ainsi :

• Suppression du câblage de commande : remplacer le bus DMX filaire entre la console et les projecteurs par une liaison radio ESP-NOW entre l’appareil mère et les esclaves, seule la liaison finale esclave-projecteur restant câblée ;
• Sobriété du réseau : ne transmettre par radio que des commandes de haut niveau, et non la trame DMX elle-même, afin de ne pas saturer la bande 2,4 GHz d’un lieu déjà chargé en Wi-Fi ;
• Pilotage à distance sans matériel dédié : rendre l’installation configurable et exploitable depuis l’interface web Modlink, sans console physique ni application propriétaire ;
• Intégration à l’écosystème existant : ajouter les commandes DMX à la liste de commandes Modlink pour les rendre utilisables dans les scénarios, au même titre que les autres actionneurs ;
• Supervision de la consommation : exploiter les deux entrées 220 V de l’appareil mère pour mesurer la consommation électrique de l’installation d’éclairage.

Contexte humain

Comme pour mes réalisations précédentes, ce projet m’a été confié dans le cadre de mon alternance au sein de l’entreprise Alcante, dont je suis le seul développeur : j’en assure la conception et le développement de bout en bout. L’idée initiale vient de mon tuteur, qui a identifié ce besoin auprès de sa clientèle. L’entreprise est composée de deux personnes :

• Jorge Beja, mon tuteur, dirigeant et technicien de l’entreprise, à l’origine de l’idée 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 commandes clients et assure en partie la comptabilité de l’entreprise.

Contexte technique

L’architecture repose entièrement sur des cartes ESP32, comme le reste de l’écosystème Modlink, et se décompose en deux rôles distincts. L’appareil mère assure la relation avec l’utilisateur et la coordination du parc : il héberge l’interface web Svelte et l’API REST embarquées héritées de Modlink, expose l’installation à distance par le tunnel SSH inverse déjà en place, et pilote les esclaves par radio. Il dispose de deux entrées 220 V, non pas pour commuter des circuits comme l’appareil Modlink classique, mais pour mesurer la consommation de l’installation à l’aide d’un capteur de courant à transformateur dimensionné jusqu’à 50 A.

Les appareils esclaves portent la partie DMX. Chacun embarque un module DMX prêt à l’emploi relié à une sortie XLR 3 broches, ce qui évite tout câblage de transceiver à réaliser soi-même, et génère localement une trame DMX512 complète de 512 canaux grâce à la bibliothèque LXESP32DMX. Six esclaves au maximum sont pris en charge dans l’état actuel du projet. Ce découpage est un choix d’architecture volontaire : le signal DMX, qui doit être rafraîchi plusieurs dizaines de fois par seconde, n’est jamais transporté par radio ; seules les commandes de haut niveau circulent entre le mère et les esclaves, chaque esclave se chargeant de maintenir sa propre trame en local. Le réseau radio reste ainsi très peu chargé, condition indispensable dans un bar ou une salle où la bande 2,4 GHz est déjà encombrée.

Communication — Le lien entre l’appareil mère et les esclaves s’appuie sur ESP-NOW, protocole propriétaire des cartes Espressif permettant une communication directe et à faible latence sans passer par un réseau Wi-Fi. L’ESP-NOW brut se limitant à l’envoi de trames courtes entre adresses MAC, j’ai dû développer une couche protocolaire maison au-dessus, en m’inspirant de la bibliothèque EspNowBus. Cette couche prend en charge l’adressage logique des six esclaves, la liste et la procédure d’appairage, les accusés de réception des commandes, la remontée d’état des esclaves vers le mère, la détection de la perte d’un esclave, ainsi que le chiffrement des transmissions et de la clé partagée. Elle simplifie enfin l’émission des commandes du point de vue du reste du firmware, qui n’a plus à manipuler directement les trames radio.

Intégration logicielle — Les commandes DMX viennent enrichir la liste de commandes Modlink existante, ce qui les rend directement utilisables dans le moteur de scénarios : un éclairage peut ainsi être déclenché ou modulé par un scénario, au même titre qu’un relais ou un moteur, et se modéliser graphiquement dans l’interface Svelte Flow. Cette intégration est valable pour l’ensemble des appareils Modlink, et non seulement pour le contrôleur d’éclairage.

L’enjeu

L’enjeu principal est de rendre accessible aux petites structures — bars, salles associatives, particuliers — une technologie jusqu’ici réservée aux installations professionnelles lourdes. Le DMX512 impose habituellement de tirer un bus filaire jusqu’à chaque projecteur et de disposer d’une console de pilotage ; l’objectif est de conserver la richesse du protocole tout en supprimant le câblage de commande et la console physique, remplacés par une liaison radio et une interface web.

Cet objectif suppose de résoudre une tension technique de fond : le DMX est un protocole temps réel exigeant, alors que la radio est par nature moins fiable et partagée. C’est précisément ce qui justifie de déporter la génération de la trame chez les esclaves et de ne faire circuler que des commandes. Il faut de plus que cette nouvelle famille d’appareils s’insère naturellement dans l’écosystème Modlink, sans dupliquer les briques existantes — interface web, API REST, accès distant, moteur de scénarios — mais en les réutilisant.

Les risques

Le premier risque est d’ordre radio : la bande 2,4 GHz est fortement sollicitée dans les lieux visés, et une perte de commande se traduirait par un éclairage figé ou incohérent en plein événement. Ce risque est adressé par le choix d’architecture — la trame DMX étant maintenue localement par chaque esclave, une commande perdue ne coupe pas l’éclairage — et par les accusés de réception et la détection de perte d’esclave implémentés dans ma couche ESP-NOW.

Le second risque est électrique : l’appareil mère est raccordé au 220 V et le projet doit respecter les mêmes exigences que le reste de la gamme Modlink, à savoir la conformité CE, les règles de compatibilité électromagnétique et la norme NF C 15-100 pour la sécurité des installations électriques. Le projet étant à son tout début, ce volet reste à traiter mais est d’ores et déjà identifié comme un préalable à toute commercialisation.

Le troisième risque est sécuritaire, la plateforme étant pilotable à distance : il est traité par la réutilisation des mécanismes déjà éprouvés sur Modlink — accès distant par tunnel SSH inverse derrière un reverse proxy, chiffrement des échanges — complétés par le chiffrement des transmissions radio et de la clé partagée entre appareils.

Les étapes

Le projet, engagé en 2026, s’étend sur mon année d’alternance 2026-2027, la conception de l’appareil mère ayant été amorcée dès 2025 dans la continuité de Modlink. Il se déroule selon les grandes étapes suivantes :

• Conception : définition de l’architecture mère-esclaves, du découpage des rôles et du format des commandes échangées par radio ;
• Développement de la couche de communication ESP-NOW personnalisée : appairage, adressage, accusés de réception, remontée d’état, détection de perte et chiffrement ;
• Développement de la génération DMX sur les esclaves à l’aide de la bibliothèque LXESP32DMX, avec restitution sur sortie XLR 3 broches ;
• Intégration de la mesure de consommation sur les deux entrées 220 V de l’appareil mère ;
• Ajout des commandes DMX à la liste de commandes Modlink et à leur exploitation dans le moteur de scénarios (étape en cours) ;
• Réalisation d’un prototype matériel, puis tests fonctionnels sur une installation d’éclairage réelle (étape à venir).

Méthodologie de suivi

Je poursuis sur ce projet la méthodologie adoptée pour mes réalisations précédentes, inspirée de l’agilité dans une version simplifiée du modèle Scrum. Le développement avance de manière itérative et incrémentale : chaque cycle débute par un échange avec mon tuteur sur la fonctionnalité à développer, que je conçois, implémente puis teste avant de la soumettre à sa validation. Une fonctionnalité conforme est intégrée définitivement ; dans le cas contraire, des ajustements sont effectués avant une nouvelle validation. Ce fonctionnement, déjà éprouvé sur Modlink, permet d’avancer par petits pas vérifiables sur un projet dont le périmètre reste ouvert.

Gestion du code source et traçabilité

Comme pour Modlink, dont ce projet réutilise une large partie du code, le développement est versionné sur le dépôt Git hébergé sur le serveur Alcante. Cette organisation me garantit une copie sécurisée à distance et le suivi des versions, avec des branches dédiées pour développer la couche ESP-NOW et la partie DMX sans affecter le code principal de Modlink, et des commits documentés à chaque étape.

Les acteurs

Trois types d’acteurs interviennent sur ce projet :

• Moi-même, en tant que concepteur et développeur unique, de l’architecture jusqu’aux tests ;
• Jorge Beja, mon tuteur, à l’origine de l’idée et de la validation des orientations du projet ;
• Les utilisateurs finaux — bars, salles et particuliers souhaitant une installation d’éclairage DMX légère et sans câblage de commande.

Les résultats

Le projet étant en cours de développement, il n’existe pas encore de prototype matériel : sa réalisation est en cours de lancement. Les fondations logicielles sont en revanche posées. La couche de communication ESP-NOW personnalisée est en place, avec l’appairage et l’adressage des esclaves, les accusés de réception, la remontée d’état, la détection de la perte d’un esclave et le chiffrement des transmissions. La génération d’un univers DMX de 512 canaux côté esclave, à partir de la bibliothèque LXESP32DMX et d’un module DMX relié à une sortie XLR 3 broches, est également fonctionnelle, de même que la réutilisation de l’interface web Svelte et de l’accès distant hérités de Modlink.

Deux chantiers restent ouverts : la liste complète des commandes DMX, dont l’écriture s’est révélée plus complexe que prévu, et l’implémentation de ces commandes dans le moteur de scénarios afin de pouvoir piloter l’éclairage depuis un scénario. La mesure de consommation sur les deux entrées 220 V de l’appareil mère est au stade de l’intégration.

Les lendemains du projet

Ce projet se poursuivra sur l’ensemble de mon année d’alternance 2026-2027. Les prochaines étapes sont la finalisation de la liste de commandes, leur intégration complète au moteur de scénarios, puis la réalisation d’un prototype matériel et sa mise à l’épreuve sur une installation d’éclairage réelle. Le volet normatif — conformité CE, compatibilité électromagnétique et NF C 15-100 — devra être traité avant toute mise sur le marché. À terme, ce contrôleur a vocation à devenir une famille d’appareils à part entière au sein de la gamme Modlink, commercialisée par l’entreprise et administrable depuis le site central multi-appareils.

Mon regard critique

Bien que le projet soit encore jeune, il m’a déjà confronté à une difficulté d’un genre nouveau : concevoir moi-même une couche protocolaire au-dessus d’ESP-NOW. Jusqu’ici j’avais surtout consommé des protocoles existants ; il s’agissait cette fois d’en définir un, avec ses adresses, ses accusés de réception, sa gestion des pertes et son chiffrement. Cet exercice m’a fait comprendre de l’intérieur ce que suppose la fiabilité d’une communication, et constitue de loin l’apport le plus formateur de cette réalisation à ce stade. La définition de la liste des commandes s’est elle aussi révélée plus délicate que je ne l’avais anticipé, car elle doit rester assez générique pour s’intégrer au moteur de scénarios de tous les appareils Modlink.

Avec le recul, la décision de ne pas transporter le DMX par radio mais seulement des commandes est le choix d’architecture dont je suis le plus satisfait : il résout d’un même geste la saturation du réseau et la robustesse de l’éclairage en cas de perte de liaison. Si c’était à refaire, je stabiliserais en revanche le format des commandes plus tôt, avant d’attaquer leur intégration aux scénarios, afin d’éviter les reprises. Ce projet confirme surtout la valeur de l’écosystème construit avec Modlink : pouvoir bâtir une nouvelle famille de produits en réutilisant l’interface web, l’API, l’accès distant et le moteur de scénarios existants est la meilleure validation des choix d’architecture faits précédemment.