Pourquoi les projets matériels ont besoin d'une architecture microservices

L'instinct sur la plupart des projets embarqués est d'écrire un grand firmware qui gère tout : l'analyse des protocoles, la logique métier, la récupération d'erreurs, la journalisation. Ça livre. Ça fonctionne. Jusqu'à ce que le matériel change, qu'un nouveau protocole s'ajoute, ou qu'une chasse aux régressions prenne trois jours au lieu de trois heures.

Le problème multi-protocoles

Chez Volthium, le défi était réel : une flotte de 300+ batteries lithium-ion, chacune nécessitant des tests de production — incluant des tests destructifs — sur CAN, UART, Ethernet et Bluetooth simultanément. Un service monolithique aurait signifié un état partagé entre quatre patterns de communication fondamentalement différents, une logique de test emmêlée avec des adaptateurs de protocoles, et des sessions de débogage mesurées en jours.

La découpe microservices

L'architecture que nous avons construite a séparé les responsabilités proprement :

• •Adaptateurs de protocoles (un par interface : CAN, UART, Ethernet, Bluetooth) — chacun possède son transport et expose un bus de messages normalisé.
• •Service émulateur — rejoue un trafic connu pour les tests de régression sans matériel physique.
• •Orchestrateur de tests — séquence les tests, collecte les résultats, décide réussite/échec.
• •Moteur de régression — compare les résultats à une base de référence et signale automatiquement les écarts.

Chaque service communique via un bus de messages local. Ajouter un nouveau protocole signifie écrire un nouvel adaptateur sans toucher à l'orchestration. Une régression dans la pile CAN n'affecte que le service adaptateur CAN — le reste du système continue à fonctionner.

Le firmware embarqué SmartBridge

Côté embarqué, le firmware STM32 SmartBridge joue le rôle de passerelle matérielle : il agrège les données de toutes les interfaces physiques et expose un flux normalisé unique aux services logiciels. Le pattern bridge a maintenu le code embarqué focalisé sur la fiabilité matérielle — garanties temps réel, récupération d'erreurs, minuteries watchdog — tandis que les services PC géraient la logique de test.

Le gain inattendu : le puce propriétaire

Au milieu du projet, nous avons rencontré un problème de reprogrammation avec une puce chinoise propriétaire dans le système de gestion de batterie. Parce que l'adaptateur CAN était isolé, nous pouvions instrumenter et reproduire le bogue sans toucher aucune autre partie du système — quelque chose d'impossible dans une conception monolithique. L'isolation s'est rentabilisée sur une seule session de débogage.

Quand cette architecture s'applique

• •Votre produit parle plusieurs protocoles simultanément.
• •Vous avez besoin de tests de régression reproductibles à mesure que le matériel évolue.
• •Votre équipe embarquée et votre équipe logicielle travaillent en parallèle.
• •Vous devez simuler le matériel dans un pipeline CI.

L'investissement dans l'architecture microservices se rembourse doublement à la première révision matérielle majeure. Si ça décrit votre projet, contactez-nous.