Plateforme IoT de monitoring énergétique

Le contexte

Le défi business

Lancer un nouveau produit sur le marché de l'énergie pour permettre aux producteurs d'éviter la production à perte. Le client partait d'une page blanche avec une ambition forte : déployer rapidement une solution robuste, capable d'évoluer (V1, V2...) sans dette technique initiale.

Ma mission

Convertir cette vision stratégique en une réalité technique opérationnelle. Concevoir l'architecture complète (Hardware + Software) pour qu'elle soit immédiatement fiable et prête pour les futures fonctionnalités déjà planifiées.

Dans un marché de l'énergie volatil, les producteurs solaires risquent parfois de produire à perte. Mon client a identifié un besoin critique : offrir aux producteurs un outil de pilotage précis pour optimiser leur rentabilité. Et à ses clients de pouvoir suivre la consommation en temps réel.

Le cahier des charges

• Lire les données directement depuis le compteur Linky (protocole Teleinfo)
• Afficher la production/consommation en temps réel sur une interface web
• Intégrer les données officielles Enedis pour le suivi facturation
• Gérer des groupes d'autoconsommation collective (ACC)
• Mettre à jour le matériel à distance (OTA)
• Le tout avec une stack 100 % commercialisable (pas de licences restrictives)

La solution livrée

J'ai conçu et développé l'ensemble de la plateforme, du firmware embarqué jusqu'à l'interface utilisateur, en passant par l'API backend. Trois briques techniques qui communiquent entre elles en temps réel.

Architecture globale

Les défis techniques

1. Deux protocoles Teleinfo incompatibles

Les compteurs Linky en France existent en deux modes : Historique (1200 bauds) et Standard (9600 bauds), avec des formats de trames complètement différents.

Ce que j'ai mis en place :

• Auto-détection du mode au démarrage (analyse des trames sur 5 secondes par mode)
• Validation de chaque trame par checksum avant exploitation
• Détection « souple » des trames pour les compteurs dont le signal est dégradé (bits corrompus sur les caractères de contrôle)
• Compteurs de diagnostic accessibles à distance pour le support technique

Résultat : le boîtier s'adapte automatiquement à n'importe quel compteur Linky, sans intervention de l'installateur.

2. Temps réel sur une architecture distribuée

Le défi : afficher les données de consommation avec une latence inférieure à 10 secondes, tout en stockant l'historique pour la facturation.

Ce que j'ai mis en place :

• Double canal de données : le frontend reçoit les données MQTT directement depuis le boîtier (pas de détour par le backend), pendant que le backend les archive en parallèle
• SSE (Server-Sent Events) en fallback pour les navigateurs sans WebSocket
• Synchronisation nocturne avec l'API Enedis pour les données officielles (J-1)

Résultat : les utilisateurs voient leur consommation bouger en direct, et retrouvent les données officielles Enedis le lendemain matin.

3. Intégration Enedis (OAuth 2.0 + RGPD)

L'accès aux données Enedis passe par deux API distinctes avec authentification OAuth 2.0, gestion du consentement RGPD, et des limites de débit strictes (1000 appels/heure).

Ce que j'ai mis en place :

• Workflow de consentement RGPD intégré dans l'interface
• File d'attente avec throttling pour respecter les quotas Enedis
• Support de l'API ACC (données collectives) et Data Connect (données individuelles)
• Job planifié à 1 h du matin pour la synchronisation quotidienne

Résultat : chaque matin, les données officielles Enedis de la veille sont disponibles dans l'interface, sans jamais dépasser les quotas.

4. Mise à jour du firmware à distance (OTA)

Avec des boîtiers déployés chez des particuliers, il fallait pouvoir les mettre à jour sans déplacement.

Ce que j'ai mis en place :

• Vérification automatique toutes les 10 minutes via comparaison de version semver
• Déclenchement possible à distance via commande MQTT
• Adaptation réseau : HTTPS sur WiFi, HTTP sur Ethernet (contrainte hardware)
• Feedback visuel par LEDs pendant la mise à jour
• Plus de 20 versions déployées en OTA sans intervention physique

5. Licensing commercial

Le client vend le boîtier à ses propres clients. Toute la stack devait être exempte de licences copyleft (GPL, LGPL).

Ce que j'ai fait :

• Audit complet des dépendances firmware (migration v2 vers v3 pour éliminer les librairies LGPL)
• Remplacement des librairies critiques par des équivalents Apache 2.0
• Fichier NOTICES.txt maintenu à jour pour la conformité

Stack technique

Infrastructure : PostgreSQL, MQTT Broker (WebSocket), serveur OTA, API Enedis (OAuth 2.0)

Ce que ce projet illustre

Ce type de projet est représentatif de ce que je fais au quotidien : prendre un besoin métier complexe et livrer une plateforme complète, de bout en bout.

• Full-stack au vrai sens du terme : du C++ embarqué au Vue.js, en passant par l'API et la base de données
• Protocoles industriels : Teleinfo, MQTT, OTA, Serial, pas juste du CRUD
• Intégrations API complexes : OAuth 2.0, consentement RGPD, rate limiting, synchronisation de données
• Pensée produit : auto-détection, diagnostic à distance, mise à jour OTA. Le matériel est déployé chez des particuliers, il doit fonctionner sans support
• Rigueur commerciale : audit de licences, conformité, documentation technique

Créer une V1 est « facile ». Créer une V1 qui permet de sortir la V2 et la V3 sans tout réécrire est un autre métier.