Le Lab

🎯 Pourquoi cette page existe

Entre l'écriture d'un article sur l'effacement diffus et la conception d'une infrastructure client, il y a un point commun : j'ai besoin de mesurer pour comprendre. Cette page recense mon installation d'instrumentation perso — énergie, réseau, compute — et explique ce qui s'y passe, pourquoi, et ce que ça produit comme contenu ou comme service.

Le lab sert trois choses :

• Crédibilité éditoriale — quand je dis "j'ai mesuré que…" dans un article du blog énergie, cette page montre avec quoi.
• Pont perso → pro — certaines briques d'ici ont pris assez d'ampleur pour migrer en asset de RDEM Systems. Le NTP Stratum 1, par exemple, a démarré sur une étagère avant de devenir un service public.
• Dogfooding honnête — je suis client de ma propre entreprise pour sauvegarder ce lab. C'est le meilleur test qu'un produit existe.

⚡ A — Instrumentation énergétique

C'est la section phare du lab : installation photovoltaïque, stockage batterie, et deux systèmes de mesure fine qui tournent en parallèle — Shelly Pro 3 EM côté injection/conso, Emporia Vue sur 16 voies CT pour voir chaque circuit de la maison individuellement.

Installation photovoltaïque

Installation résidentielle de 3 kWc en monophasé, sans revente totale : l'objectif est l'autoconsommation, avec stockage pour lisser l'injection et revendre seulement les surplus aux moments où le réseau en a besoin (typiquement après 16 h).

Double exposition volontaire. Les panneaux du toit sont orientés Ouest / Sud-Ouest, ceux posés au fond du jardin Est / Sud-Est. Ça étale la courbe de production sur la journée plutôt que de concentrer toute la puissance sur le pic de midi solaire — exactement la logique "grid-friendly" que la batterie Zendure permet d'amplifier en plus.

Concrètement, les créneaux de production s'enchaînent sur la journée :

• Panneaux jardin (Est / Sud-Est) : commencent à produire dès 8h30 au printemps, 9h-9h30 en hiver — ils captent la première lumière du matin que les panneaux du toit, côté Ouest, ne voient pas encore.
• Panneaux toit (Ouest / Sud-Ouest) : démarrent vers 10h-11h en été, 13h en hiver — et continuent bien après le pic solaire de midi, jusqu'en fin d'après-midi.

Les deux panneaux du jardin — les plus éloignés — sont raccordés en entrée directe sur les Hyper 2000 Zendure, un par stack. C'est un montage inhabituel que j'assume : pas de micro-onduleur sur ces deux-là, l'énergie part directement dans la batterie puis ressort côté AC au moment choisi. Les autres panneaux passent par les micro-onduleurs Enphase et remontent dans l'installation AC classique.

Bilan annuel 2025 — portail Enphase

Quelques chiffres qui parlent :

• Production 2025 : 3,2 MWh pour 3 kWc installés — soit environ 1 067 kWh/kWc/an, cohérent pour une installation française bien exposée.
• Consommation totale du foyer : 9,2 MWh — maison familiale avec deux PAC, conso hiver significative.
• 213 kWh exportés seulement sur les 3,2 MWh produits. Autrement dit, 93 % de ce que produit le PV est consommé sur place. C'est l'effet combiné Zendure + PAC + décalage d'injection : on garde tout ce qu'on peut, on n'envoie au réseau que les vrais surplus.
• Couverture PV réelle : ~33 % de la conso totale du foyer couverte par le solaire (3 MWh autoconsommés / 9,2 MWh consommés).

Stockage — Zendure Hyper 2000

Deux stacks Hyper 2000, chacun équipé de deux batteries AB2000S et d'un panneau solaire raccordé en entrée directe. Le reste de la puissance PV passe par l'installation onduleur classique côté AC. Cette architecture mixte est volontaire : elle me permet de tester à la fois l'autoconsommation "classique" et le décalage d'injection piloté par la batterie.

La stratégie : décaler l'injection réseau du pic de midi (13 h) vers la fin d'après-midi (16 h-18 h), au moment où le réseau en a réellement besoin. Soyons clair sur l'intention : en tant que particulier résidentiel, je ne paye pas directement quand le prix spot devient négatif — ce sont les producteurs sur les marchés de gros qui encaissent le choc, pas moi. Ma motivation est donc éthique et systémique, pas économique : je ne veux pas amplifier un problème que je contribuerais autrement à alimenter passivement, à savoir l'injection massive et synchronisée de dizaines de milliers de toits résidentiels au pic de midi solaire.

Ce comportement synchronisé à l'échelle de millions de sites n'est pas un problème théorique. L'incident ibérique d'avril 2025 a montré ce qui se passe quand un réseau devient trop dépendant de sources de production non-pilotables qui se comportent toutes en même temps : quand ça chute, ça chute ensemble, et la stabilité du système entier bascule en quelques secondes. Décaler ma petite injection de 3 kWc ne sauve pas le réseau européen, évidemment. Mais c'est cohérent avec l'idée qu'un système électrique sain repose sur des contributeurs désynchronisés, pas sur l'exact opposé. J'ai détaillé toute la démarche — courbes RTE 2024 croisées avec mes mesures Shelly 2025 — dans un article dédié : Pourquoi je décale mon injection PV de 13 h à 16 h (mesures réelles).

Activité batterie — 2025 vs 2026

Le Zendure a été mis en service fin 2025, d'où l'activité très partielle sur la première capture. La seconde capture montre l'activité sur les 4 premiers mois de 2026, qui valide un point important que je sous-estimais au début : même en plein hiver, la batterie travaille tous les jours. Le solaire de janvier-février est faible en volume, mais il existe des créneaux quotidiens où ma production instantanée dépasse ma consommation instantanée — et ces créneaux-là, la batterie les capture et les redistribue plus tard dans la journée. Le décalage d'injection ne se joue pas à l'échelle d'une saison, il se joue à l'échelle d'une journée.

Mesure fine — Shelly Pro 3 EM

Le Shelly Pro 3 EM est un module triphasé, mais mon installation est monophasée : seule une des trois voies est câblée. C'est un choix volontaire — le Pro 3 EM est plus propre à installer et plus précis que le Pro 1 EM, et rien n'empêche de ne l'utiliser qu'en monophasé. Le sur-équipement au cas où une évolution en triphasé serait envisagée un jour.

Mesure circuit par circuit — Emporia Vue

Là où le Shelly mesure le flux global au tableau, l'Emporia Vue prend chaque circuit individuellement : 16 pinces CT branchées sur les disjoncteurs qui comptent le plus — les deux pompes à chaleur en priorité, plus une sélection des circuits les plus représentatifs de la conso du logement. C'est ce qui permet de dire, mesures à l'appui, quelle part de la consommation vient de quoi, et d'identifier les postes à optimiser.

Stack de traitement des données

Aujourd'hui, les données vivent principalement dans les clouds Shelly et Emporia. C'est fonctionnel pour la consultation au quotidien, mais limité pour l'analyse historique, les corrélations croisées et l'export automatisé vers un dashboard unifié.

Chantier en cours : migration de Jeedom vers Home Assistant. L'objectif est de rapatrier toutes les mesures (Shelly, Emporia, Zendure) dans une stack auto-hébergée avec de l'historique propre et des dashboards qui permettent vraiment de raconter une journée type. C'est un chantier que je n'ai pas encore fini — et c'est une des raisons pour lesquelles cette page existe en version "vivante" plutôt qu'en version définitive.

💻 B — Homelab informatique

La partie compute et réseau du lab : un rack Ubiquiti qui porte la connectivité maison, un hôte Proxmox sous forme de tour, et quelques VMs — dont une qui héberge un serveur Minecraft pour mon fils.

Rack & réseau Ubiquiti

Le cœur du réseau maison tourne sur une stack Ubiquiti complète, montée en rack :

Cohérence matérielle et gestion unifiée via un seul contrôleur — c'est la même logique qu'en production chez les clients : une seule interface pour firewall, switching, Wi-Fi et CCTV. Pour un lab perso qui sert aussi à tester des configs réseau avant de les déployer ailleurs, c'est le bon niveau de professionnalisation sans basculer dans le sur-investissement.

Hôte Proxmox

Une tour intégrée dans le rack à côté des équipements Ubiquiti. Pas un serveur 1U dédié — pour un lab qui doit aussi pouvoir accueillir une carte GPU le jour où le projet IA démarre, une tour bien remplie reste le meilleur compromis coût / évolutivité / niveau sonore.

Architecture volontairement sobre mais bien dimensionnée : la combinaison SSD + HDD permet de faire tourner les VMs actives sur du stockage rapide tout en gardant beaucoup d'espace pour les snapshots, les ISO, les données longue durée et les cas d'usage qui ne demandent pas de performance. 128 Go de RAM, c'est largement suffisant pour les VMs actuelles plus la marge qu'il faut pour héberger un modèle LLM de taille moyenne en mémoire quand le projet IA démarrera.

Pourquoi Proxmox ? Parce que c'est la techno que RDEM Systems infogère au quotidien, et qu'il serait incohérent de faire tourner mon lab sur autre chose. Le lab sert aussi de terrain de test pour valider des scénarios avant de les proposer en prod : migrations, snapshots, restauration PBS, etc. C'est du dogfooding au sens strict.

Un serveur Minecraft pour mon fils

Une VM dédiée héberge un serveur Minecraft accessible depuis le réseau maison — le genre de service qui dure 3 ans ou 3 mois selon les phases, mais qui bénéficie énormément de vivre sur une infra propre : sauvegardes automatiques, snapshots avant les changements de version, accessibilité garantie, zéro perte de monde quand on passe d'une version de serveur à la suivante. C'est aussi une excellente occasion de lui faire comprendre qu'un "serveur", ce n'est pas juste une boîte magique qu'on allume.

Projet Lab IA (planifié)

Prochain chantier majeur : monter un nœud compute dédié aux expérimentations LLM locaux. L'idée est d'acheter une machine d'occasion équipée d'une ou deux cartes graphiques, suffisante pour faire tourner les modèles ouverts courants en local — Llama 3, Mistral, DeepSeek, etc. — avec une stack auto-hébergée.

L'angle est clair : je ne veux pas raconter des histoires sur l'IA en conseil sans l'avoir manipulée sérieusement en local, sans passer par des API commerciales. Ce lab sera le banc d'essai avant toute proposition client sur le sujet.

Connectivité

Aujourd'hui : accès Internet Free classique — suffisant pour tout ce qui est décrit sur cette page.

À l'étude : un lien direct entre Equinix PA5 et la maison, pas pour annoncer l'AS depuis ici, mais pour deux raisons très concrètes — (1) disposer d'une IP pro issue de l'AS206014 à la maison (Free fournit déjà une IP publique fixe, ça fonctionne très bien, mais passer sur une IP annoncée par mon propre AS change la nature du raccordement), et (2) avoir une liaison directe et dédiée vers l'infrastructure de production de RDEM Systems, sans dépendre d'un chemin Internet public. C'est le genre de lien qui n'a de sens que si on exploite son propre AS et qu'on a un vrai besoin de symétrie entre le lab et la prod — ce qui est mon cas via RDEM Systems. À suivre — ça fera probablement l'objet d'une section dédiée le jour où c'est en place.

⏱️ B.1 — NTP Stratum 1 : l'exemple parfait du pont perso → pro

Le projet qui incarne le mieux pourquoi cette page existe. Un Raspberry Pi + un module GPS monté au départ comme curiosité technique, qui est devenu un serveur de temps public, puis un asset opéré par RDEM Systems avec documentation technique complète et clients payants.

Je ne duplique volontairement pas ici les détails techniques — hiérarchie NTP, signal PPS, algorithme de sélection des pairs, gestion des secondes intercalaires, configurations ntpd et gpsd, tout cela est déjà documenté proprement côté pro, et maintenir deux versions du même contenu serait une dette à perte.

La timeline en 3 dates

Je contribue au NTP Pool Project depuis 2005 — donc avant même d'avoir un Stratum 1 à moi. À cette époque, je faisais tourner des serveurs Stratum 2 synchronisés sur des sources publiques, parce que "donner un peu de temps au réseau" me paraissait être une contribution à ma mesure pour un protocole que j'utilisais tous les jours sans y penser. C'était un geste simple, et ça reste une des meilleures façons de comprendre comment fonctionne vraiment Internet : rendre un service, même modeste, plutôt que de seulement le consommer.

Autour de 2015-2016, j'ai monté mon premier Stratum 1 à la maison : un Raspberry Pi, un module GPS avec sortie PPS, une antenne, et suffisamment de patience pour lire la documentation de gpsd et de ntpd. Ce n'était plus du Stratum 2 "parasite" qui se synchronisait sur d'autres serveurs — c'était ma propre source de temps, alignée sur le signal GPS à la microseconde près. Le passage de Stratum 2 à Stratum 1 a été un moment charnière : la différence de précision était techniquement marginale pour la plupart des usages, mais le fait de posséder vraiment la source du temps changeait complètement la façon dont je comprenais le sujet.

Aujourd'hui, l'infrastructure est opérée par RDEM Systems, avec les détails techniques complets sur ntp.rdem-systems.com. C'est exactement le type de parcours que cette page est faite pour raconter : une curiosité technique qui dure 20 ans, qui se muscle petit à petit, et qui finit par devenir un service que d'autres utilisent. Rien de spectaculaire — juste la trajectoire normale d'un asset quand on s'en occupe longtemps et sérieusement.

💾 B.2 — Sauvegarde : dogfooding Nimbus Backup

Le lab est sauvegardé par Nimbus Backup, la solution Proxmox Backup Server de RDEM Systems. Je ne suis techniquement pas un client payant — c'est offert en usage interne — mais le fait que j'aie choisi de l'utiliser pour mon lab plutôt qu'une autre solution raconte l'essentiel : j'y crois suffisamment pour lui confier mes données.

Pourquoi ce choix

Il y a deux façons de construire un produit : en écouter d'autres en parler, ou l'utiliser soi-même tous les jours. Quand on démarre Nimbus Backup, la question "est-ce que je confierais mes propres données à ce service ?" est un test fondateur. Si la réponse est non, le produit n'est pas prêt. Si la réponse est oui et qu'on le fait vraiment, on découvre dix fois plus vite toutes les petites frictions qu'un client ne signalerait jamais.

🧭 Ce que cette page deviendra

Cette page est volontairement vivante. Chaque article instrumenté publié sur le blog y ajoute une preuve. Chaque brique qui migre en asset pro y laisse sa trace narrative. L'idée n'est pas de tout expliquer en détail ici, mais d'être un hub transparent : tu arrives, tu comprends avec quoi je travaille, et tu sais où chercher la suite — dans les articles du blog pour les analyses, sur les sites RDEM Systems pour les services pro.

Dernière mise à jour : 13 avril 2026.