Auteur/autrice : La Rédaction et Daily Home Lab

  • Optimizing Multi-Layer Forest Garden Irrigation: Calculating VPD with ESP32 and Home Assistant

    The Challenge of Water Management in a Multi-Layer Ecosystem

    In a forest garden designed according to permaculture principles, vegetation is structured in several vertical layers: from the canopy to ground covers, including fruit shrubs. Automating the irrigation of this type of ecosystem with simple soil moisture sensors poses a major problem: microclimate disparity. The intermediate shrub layer undergoes a different water stress compared to the ground cover layer, which is often protected by thick mulch.

    To solve this problem with ultra-precision, we will abandon capacitive soil probes (which oxidize and drift over time) to focus on a much more reliable biophysical metric: Vapor Pressure Deficit (VPD). VPD precisely measures the atmospheric pull on the water contained in plant leaves, indicating their actual transpiration rate.

    The IoT Architecture: Environmental Sensors and ESP32 under ESPHome

    Our architecture is based on the deployment of ESP32 modules housed in 3D-printed waterproof enclosures (IP65), positioned at different heights corresponding to the forest garden strata:

    • Layer 1 (Ground cover): DHT22 sensor placed 10 cm above the ground, under the mulch.
    • Layer 2 (Shrubs): BME280 sensor placed 1.5 m high, in the heart of the berry bushes.

    These sensors measure ambient temperature and relative humidity. Data is transmitted via Wi-Fi using the MQTT protocol to our Home Assistant home automation server.

    Real-Time VPD Calculation in Home Assistant

    VPD is expressed in kiloPascals (kPa). To calculate it dynamically, we use template integration in Home Assistant. Here is the mathematical formula implemented to calculate the saturated vapor pressure (VPsat) and the actual vapor pressure (VPact) to get the VPD:

    template:
      - sensor:
          - name: "Shrub Layer VPD"
            unit_of_measurement: "kPa"
            state: >-
              {% set T = states('sensor.bme280_temperature') | float %}
              {% set RH = states('sensor.bme280_humidity') | float %}
              {% set VPsat = 0.61078 * e ** ((17.27 * T) / (T + 237.3)) %}
              {% set VPact = VPsat * (RH / 100.0) %}
              {{ (VPsat - VPact) | round(2) }}

    Smart and Resilient Irrigation Automation

    Using this VPD value, we program a localized, water-saving irrigation rule. If the VPD of the shrub layer exceeds 1.2 kPa (moderate water stress zone for young shrubs) while the soil is not saturated, a low-power Shelly Pro 1 solenoid valve triggers a targeted drip system for 15 minutes.

    This approach respects permaculture design by preventing water waste while keeping plants in their transpiration comfort zone, thus limiting the development of fungal diseases favored by stagnant ground moisture.

  • Optimiser l’irrigation d’un jardin-forêt par strate : Calcul du VPD avec ESP32 et Home Assistant

    Le défi de la gestion de l’eau dans un écosystème multi-strate

    Dans un jardin-forêt conçu selon les principes de la permaculture, la végétation est organisée en plusieurs strates verticalisées : de la canopée aux plantes couvre-sol, en passant par les arbustes fruitiers. Automatiser l’irrigation de ce type d’écosystème avec de simples sondes d’humidité au sol pose un problème majeur : la disparité des microclimats. La strate arbustive intermédiaire subit un stress hydrique différent de la strate rampante, souvent protégée par un paillage dense (mulch).

    Pour résoudre ce problème de manière ultra-précise, nous allons abandonner les sondes de sol capacitives (qui s’oxydent et dérivent avec le temps) pour nous concentrer sur une métrique biophysique bien plus fiable : le Déficit de Pression de Vapeur (VPD – Vapor Pressure Deficit). Le VPD permet de mesurer précisément la force d’attraction de l’atmosphère sur l’eau contenue dans les feuilles des plantes, indiquant ainsi leur taux de transpiration réel.

    L’architecture IoT : Sondes environnementales et ESP32 sous ESPHome

    Notre architecture repose sur le déploiement de modules ESP32 abrités dans des boîtiers étanches imprimés en 3D (IP65), positionnés à différentes hauteurs correspondant aux strates du jardin-forêt :

    • Strate 1 (Couvre-sol) : Capteur DHT22 placé à 10 cm du sol, sous le paillage.
    • Strate 2 (Arbustive) : Capteur BME280 placé à 1,5 m de hauteur, au cœur des buissons de baies.

    Ces capteurs mesurent la température et l’humidité relative de l’air. Les données sont transmises en Wi-Fi via le protocole MQTT à notre serveur domotique Home Assistant.

    Calcul du VPD en temps réel dans Home Assistant

    Le VPD s’exprime en kiloPascals (kPa). Pour le calculer de manière dynamique, nous utilisons l’intégration de templates dans Home Assistant. Voici la formule mathématique implémentée pour calculer la pression de vapeur saturante (VPsat) et la pression de vapeur réelle (VPact) afin d’obtenir le VPD :

    template:
      - sensor:
          - name: "VPD Strate Arbustive"
            unit_of_measurement: "kPa"
            state: >-
              {% set T = states('sensor.bme280_temperature') | float %}
              {% set RH = states('sensor.bme280_humidity') | float %}
              {% set VPsat = 0.61078 * e ** ((17.27 * T) / (T + 237.3)) %}
              {% set VPact = VPsat * (RH / 100.0) %}
              {{ (VPsat - VPact) | round(2) }}

    Automatisation intelligente et résiliente de l’irrigation

    Grâce à cette valeur de VPD, nous programmons une règle d’irrigation locale et économe. Si le VPD de la strate arbustive dépasse 1.2 kPa (zone de stress hydrique modéré pour les jeunes arbustes) alors que le sol n’est pas saturé, une électrovanne basse consommation Shelly Pro 1 déclenche un goutte-à-goutte ciblé pendant 15 minutes.

    Cette approche permet de respecter le design permacole en évitant le gaspillage d’eau tout en maintenant les plantes dans leur zone de confort de transpiration, limitant ainsi le développement des maladies cryptogamiques (champignons) favorisées par une humidité stagnante au sol.

  • IoT & Jardin-Forêt : Calibrer ESPHome pour réguler l’humidité multi-couches (Rhizosphère vs Herbacée)

    Le défi de l’irrigation stratifiée en permaculture

    Contrairement à un potager classique, un jardin-forêt (ou food forest) s’organise en plusieurs strates de végétation. Arroser uniformément est une hérésie écologique : la strate herbacée (racines superficielles) a besoin d’une humidité constante, tandis que les arbres fruitiers de la canopée nécessitent des cycles de stress hydrique modéré pour ancrer profondément leurs racines. Un excès d’eau en profondeur asphyxie la rhizosphère et détruit le réseau mycorhizien.

    L’architecture technique : Multi-capteurs capacitifs sous ESPHome

    Pour cartographier ce gradient d’humidité, nous déployons des sondes capacitives (type Corrosion-Resistant v1.2) connectées à un microcontrôleur ESP32 flashé sous ESPHome. Nous installons deux sondes par zone : une à 10 cm de profondeur (strate herbacée) et une à 40 cm (rhizosphère/strate arbustive).

    La clé réside dans la calibration logicielle pour contrer la dérive thermique et la nature spécifique du sol. Voici notre configuration YAML ESPHome optimisée pour lisser les valeurs et éviter les faux déclenchements :

    sensor:
      - platform: adc
        pin: GPIO32
        name: "Humidite Surface 10cm"
        update_interval: 15s
        filters:
          - calibrate_linear:
              - 3.12 -> 0.0
              - 1.45 -> 100.0
          - exponential_moving_average:
              alpha: 0.1
              send_every: 4

    Logique de gouvernance locale : L’automatisation Home Assistant

    Grâce à l’intégration Home Assistant, nous n’activons pas l’électrovanne (gérée par un relais Shelly) sur une simple valeur brute. Nous calculons le différentiel de tension hydrique. Si la surface est sèche (< 30%) mais que la rhizosphère est humide (> 60%), l’irrigation est bloquée pour forcer les plantes compagnes à puiser dans la strate inférieure, stimulant ainsi la résilience globale du système et préservant les ressources en eau de notre Home Lab de manière éco-responsable.

  • Sécuriser son Home Lab : Trunk VLAN 802.1Q entre Proxmox et OPNsense avec tunnel Cloudflare

    Le défi de la gouvernance réseau dans un Home Lab

    En tant que professionnel de la gouvernance des SI, la règle du moindre privilège doit s’appliquer même au sein d’une infrastructure domestique. Mélanger le trafic d’administration de votre hyperviseur Proxmox VE avec celui de vos objets connectés ou de vos machines virtuelles de production est une hérésie en matière de sécurité. L’objectif aujourd’hui est d’isoler hermétiquement ces flux via un Trunk VLAN 802.1Q géré par OPNsense, tout en exposant certains services via un Tunnel Cloudflare (cloudflared) pour éviter toute ouverture de port sur votre routeur externe.

    Étape 1 : Configuration du Trunk VLAN sur Proxmox VE

    Par défaut, Proxmox utilise un pont Linux standard (vmbr0). Pour acheminer plusieurs VLANs vers nos machines virtuelles à travers une seule interface physique, nous devons rendre ce pont « VLAN aware ». Dans l’interface de Proxmox, naviguez vers Système > Réseau, éditez le bridge principal vmbr0 et cochez la case VLAN Aware. Cela permet à Proxmox de taguer et de transmettre les trames 802.1Q directement à votre pare-feu virtuel OPNsense sans multiplier les interfaces réseau virtuelles.

    Étape 2 : Segmentation et routage sous OPNsense

    Sur votre VM OPNsense (qui possède une interface virtuelle connectée à vmbr0), nous allons créer nos interfaces virtuelles (VLANs). Allez dans Interfaces > Other Types > VLAN. Créez le VLAN 10 (Management / Administration) et le VLAN 20 (Zone DMZ / Services publics). Associez-les à l’interface parente physique d’OPNsense. Configurez ensuite les règles de pare-feu : le VLAN 10 peut initier des connexions vers le VLAN 20, mais l’inverse est strictement interdit. C’est la base d’une gouvernance de zone robuste.

    Étape 3 : Exposition sécurisée via Cloudflare Tunnel

    Pour accéder à vos applications du VLAN 20 depuis l’extérieur sans exposer l’IP publique de votre domicile ni ouvrir de ports (NAT/PAT), nous déployons un agent léger cloudflared dans une VM isolée au sein du VLAN 20. Cet agent établit une connexion sortante persistante et chiffrée vers les serveurs edge de Cloudflare. Seul le trafic légitime et pré-authentifié par vos politiques Cloudflare Zero Trust sera acheminé vers vos services du VLAN 20, bloquant ainsi d’office les scans de vulnérabilités opportunistes.

    Bénéfices de gouvernance opérationnelle

    En appliquant cette architecture, vous réduisez drastiquement la surface d’attaque de votre infrastructure. L’accès aux interfaces de gestion de Proxmox et d’OPNsense reste confiné au VLAN 10 (uniquement accessible via un VPN local de confiance), tandis que vos services web résident dans une DMZ étanche (VLAN 20), protégée en amont par le WAF et les règles de sécurité de Cloudflare.

  • Sécuriser les webhooks sur Proxmox VE : Routage OPNsense et Cloudflare Tunnels sans exposition IP

    Introduction : Le défi de l’exposition des API dans un Home Lab gouverné

    Dans le cadre d’une gouvernance rigoureuse des systèmes d’information (GSI), l’exposition de services d’administration ou de webhooks d’automatisation vers l’extérieur représente un risque majeur de sécurité. Comment permettre à des services tiers (comme GitHub ou des API SaaS) d’interagir avec notre hyperviseur Proxmox VE sans pour autant ouvrir de ports sur notre routeur principal ou exposer notre adresse IP publique ? La réponse réside dans la synergie entre la segmentation réseau stricte sur OPNsense et l’isolation des flux via un Cloudflare Tunnel (cloudflared).

    Architecture et Politique de Moindre Privilège

    Pour respecter les principes de gouvernance, nous mettons en œuvre une architecture segmentée en trois zones distinctes :

    • VLAN 10 (Management) : Contient l’interface d’administration de Proxmox VE (PVE). Strictement inaccessible depuis l’extérieur et depuis les autres VLANs, sauf rebond sécurisé.
    • VLAN 90 (DMZ – Webhooks) : Zone isolée contenant un conteneur LXC ‘Proxy-Webhook’ chargé de recevoir les requêtes externes et de les valider.
    • L’agent Cloudflare (Cloudflared) : Installé dans un conteneur LXC distinct sur le VLAN 90, il établit une connexion sortante sécurisée vers le réseau Cloudflare, éliminant le besoin d’ouvrir des ports entrants (NAT) sur OPNsense.

    Configuration d’OPNsense : Le pare-feu comme garant de la politique de sécurité

    Sur notre pare-feu OPNsense, nous créons des règles de filtrage strictes pour le VLAN 90. L’objectif est d’empêcher toute communication latérale initiée par la DMZ vers le réseau de management (VLAN 10), tout en autorisant uniquement les réponses aux requêtes légitimes.

    Une règle spécifique autorise le conteneur ‘Proxy-Webhook’ à interagir uniquement avec l’API de Proxmox VE sur le port 8006, en limitant l’accès à une adresse IP source unique et à des points de terminaison d’API spécifiques via un proxy inverse local agissant comme un point de contrôle applicatif.

    Mise en œuvre du Cloudflare Tunnel

    Grâce à la console Cloudflare Zero Trust, nous créons un tunnel pointant vers l’IP interne du proxy inverse sur le VLAN 90. Les requêtes externes arrivent sur un sous-domaine dédié, transitent de manière chiffrée par le tunnel, et sont délivrées localement sans aucune exposition de notre routeur OPNsense sur le WAN public. Les règles de pare-feu d’OPNsense bloquent le reste du trafic, garantissant l’intégrité de l’infrastructure.

  • Gouvernance Réseau : Segmentation VLAN Sécurisée avec OPNsense et Proxmox VE

    Introduction : La nécessité d’une gouvernance réseau au sein du Home Lab

    Dans un écosystème informatique domestique moderne, la frontière entre vie privée, télétravail et expérimentations techniques est de plus en plus poreuse. Adopter une approche de gouvernance des systèmes d’information, même à l’échelle d’un Home Lab, n’est plus un luxe mais une nécessité cyber-résiliente. Un réseau « plat » (Flat Network) représente un risque de propagation latérale majeur : la compromission d’un simple objet connecté (IoT) peut mener à la prise de contrôle de vos hyperviseurs ou de vos serveurs de stockage (NAS). Cet article détaille l’implémentation d’une segmentation réseau stricte par VLAN (802.1Q) en articulant deux piliers open-source incontournables : l’hyperviseur Proxmox VE et le pare-feu/routeur OPNsense.

    La cartographie et la politique de zones (Urbanisation du SI)

    Avant de configurer la technique, il convient de définir notre politique d’urbanisation réseau. Nous appliquerons le principe de moindre privilège en isolant nos flux dans quatre zones distinctes :

    • VLAN 10 – MGMT (Management) : Accès exclusif aux interfaces d’administration (Proxmox GUI, OPNsense GUI, IPMI, switches).
    • VLAN 20 – LAN (Trusted) : Périphériques de confiance (ordinateurs de travail, serveurs sécurisés).
    • VLAN 30 – IoT (Internet of Things) : Objets connectés, caméras IP (isolation stricte, pas d’accès WAN non contrôlé).
    • VLAN 40 – DMZ (Demilitarized Zone) : Services exposés à Internet (Reverse Proxy, serveurs web).

    Configuration de l’hyperviseur Proxmox VE

    Pour acheminer ces VLANs vers nos machines virtuelles (VM) et conteneurs (LXC), nous devons configurer le commutateur virtuel de Proxmox pour qu’il gère le marquage 802.1Q (VLAN-Aware).

    1. Connectez-vous à l’interface de Proxmox VE, allez dans System > Network.
    2. Sélectionnez votre pont réseau principal (généralement vmbr0) et cliquez sur Edit.
    3. Cochez la case VLAN Aware. Cette option essentielle permet au pont de propager les paquets étiquetés (tagged) sans nécessiter la création d’interfaces physiques virtuelles pour chaque VLAN au niveau de l’hôte.
    4. Appliquez la configuration (cliquez sur Apply Configuration ou redémarrez l’hôte).

    Déploiement et routage sous OPNsense

    OPNsense agira comme le cœur de routage inter-VLAN et la passerelle de sécurité. Dans notre architecture virtuelle, la VM OPNsense dispose d’une interface réseau virtuelle rattachée à vmbr0.

    1. Dans l’interface d’OPNsense, rendez-vous dans Interfaces > Other Types > VLAN.
    2. Créez vos interfaces VLAN en associant le tag 802.1Q approprié (ex: 10, 20, 30, 40) à l’interface parente LAN physique ou virtuelle (ex: vtnet1).
    3. Allez dans Interfaces > Assignments pour assigner ces nouvelles interfaces virtuelles et les activer. Activez le client DHCP ou configurez des IPs statiques pour chaque sous-réseau (ex: 10.10.10.1/24 pour le VLAN 10).

    Gouvernance des flux : Règles de Pare-feu et Filtrage Stateful

    Par défaut, OPNsense applique une politique de sécurité implicite de type « Default Deny ». Nous devons créer des règles de pare-feu précises pour orchestrer les flux légitimes :

    • Règle de cloisonnement IoT : Bloquez toutes les requêtes initiées par le VLAN 30 (IoT) vers les autres réseaux locaux (VLAN 10, 20, 40). N’autorisez que les flux sortants vers les serveurs NTP ou DNS spécifiques (idéalement hébergés localement et sécurisés).
    • Règle d’administration sécurisée : Seul le VLAN 10 (MGMT) est autorisé à initier des connexions SSH (port 22) ou HTTPS (port 443/8006) vers les interfaces d’administration de vos équipements.
    • Règle de DMZ : Les serveurs en DMZ (VLAN 40) ne doivent jamais pouvoir initier de connexion vers le LAN (VLAN 20) ou le Management (VLAN 10). Seules les réponses aux requêtes légitimes initiées depuis ces réseaux sont autorisées via l’inspection d’état (Stateful Packet Inspection).

    Conclusion et perspectives d’audit

    En structurant votre Home Lab selon ces principes rigoureux d’urbanisation et de filtrage, vous réduisez drastiquement la surface d’attaque globale. Cette approche professionnalisante démontre qu’une gouvernance cyber robuste est applicable dès l’infrastructure domestique. Pour aller plus loin, l’étape suivante consiste à centraliser les journaux de pare-feu d’OPNsense vers un outil d’analyse de logs (SIEM) afin de détecter les comportements anormaux sur votre réseau IoT.

  • Sécuriser son Home Lab : Segmentation réseau (VLAN) avec OPNsense et Proxmox

    Introduction : Pourquoi segmenter votre Home Lab ?

    À l’ère de la multiplication des objets connectés et des services auto-hébergés, la sécurité de nos réseaux domestiques ne peut plus être négligée. Appliquer les principes de gouvernance des systèmes d’information à la maison n’est plus un luxe, mais une nécessité. La segmentation réseau via des VLANs (Virtual Local Area Networks) constitue le socle de cette démarche de sécurisation.

    Le duo gagnant : OPNsense et Proxmox VE

    Pour structurer cette architecture, nous utilisons OPNsense comme pare-feu et routeur principal, combiné à l’hyperviseur Proxmox VE. Cette synergie permet d’isoler hermétiquement les flux de production, les objets connectés (IoT), et les services exposés sur internet.

    Méthodologie de déploiement des VLANs

    La mise en œuvre repose sur trois étapes clés : d’abord, la configuration des interfaces parentes et la création des VLANs (par exemple, VLAN 10 pour le Management, VLAN 20 pour les VMs publiques, VLAN 30 pour l’IoT) sur OPNsense. Ensuite, l’activation de l’option VLAN Aware sur le pont Linux (vmbr0) de Proxmox. Enfin, l’application de règles de pare-feu strictes empêchant par défaut les communications inter-VLANs, sauf autorisation explicite.

    Conclusion : Une gouvernance réseau robuste

    En cloisonnant vos environnements, vous limitez drastiquement la surface d’attaque. Si un conteneur Docker exposé est compromis, l’attaquant restera confiné dans son VLAN sans pouvoir atteindre vos données personnelles ou vos outils de gestion domotique.

  • Segmentation réseau (VLAN) sécurisée sous OPNsense et Proxmox : Guide de Gouvernance pour votre Home Lab

    Introduction : Pourquoi segmenter votre Home Lab ?

    Dans un contexte où les menaces cybernétiques ne cessent de croître, appliquer des principes de gouvernance d’entreprise à votre Home Lab n’est plus un luxe, mais une nécessité. La segmentation réseau via les VLANs (Virtual Local Area Networks) est la pierre angulaire d’une architecture de sécurité robuste. Elle permet d’isoler les flux critiques (administration, serveurs de production) des flux potentiellement vulnérables (objets connectés, accès invités).

    Le couple gagnant : OPNsense et Proxmox VE

    Pour mettre en œuvre cette stratégie, l’association d’un pare-feu dédié comme OPNsense et d’un hyperviseur comme Proxmox VE s’avère extrêmement puissante. OPNsense va orchestrer le routage et appliquer les règles de filtrage entre les zones, tandis que Proxmox va distribuer ces segments directement aux machines virtuelles et conteneurs de manière logicielle.

    Étape 1 : Configurer les VLANs sur OPNsense

    La première étape consiste à définir votre plan d’adressage et à créer les interfaces virtuelles sur OPNsense. Attribuez un ID de VLAN unique à chaque usage : par exemple, VLAN 10 pour l’administration, VLAN 20 pour la production, et VLAN 30 pour l’IoT. N’oubliez pas d’appliquer une politique de sécurité par défaut (Default Deny), interdisant tout trafic inter-VLAN non explicitement autorisé.

    Étape 2 : Configurer Proxmox VE pour la gestion des VLANs

    Côté Proxmox, la configuration est simplifiée grâce à l’option VLAN-aware sur le pont réseau principal (vmbr0). En activant cette case, vous transformez votre commutateur virtuel en un commutateur intelligent capable de véhiculer les tags VLAN (Trunk). Il vous suffira ensuite de spécifier l’ID du VLAN directement dans les paramètres réseau de chaque VM ou conteneur.

    Bonnes pratiques de gouvernance réseau

    Pour maintenir une infrastructure saine à long terme, suivez ces règles simples :

    • Documentez systématiquement votre plan de nommage et d’adressage IP.
    • Appliquez le principe du moindre privilège pour les règles de pare-feu.
    • Isolez totalement les équipements IoT qui n’ont pas besoin de communiquer avec vos serveurs internes.
  • Héberger un site web chez soi en sécurité (Zero Trust avec Proxmox, Docker et Cloudflare)

    Introduction

    Exposer un serveur web auto-hébergé sur Internet a toujours été un casse-tête pour les passionnés d’informatique. La méthode traditionnelle exige d’ouvrir les ports 80 et 443 sur son routeur, ce qui crée une brèche de sécurité majeure dans le pare-feu. Pour une infrastructure gérée sous OPNsense, c’est un risque inacceptable. Aujourd’hui, nous allons voir comment contourner ce problème grâce à l’architecture « Zero Trust », en déployant un tunnel chiffré depuis un conteneur Proxmox.

    L’architecture cible

    L’objectif est simple : le pare-feu OPNsense ne doit accepter aucune connexion entrante. Tout le trafic doit être initié de l’intérieur vers l’extérieur. Pour y parvenir, nous utilisons trois composants majeurs :

    • Un hyperviseur Proxmox hébergeant un conteneur LXC (Debian).
    • Le moteur Docker, qui fait tourner notre application web (WordPress) de manière isolée.
    • Un agent Cloudflared, qui établit un tunnel sécurisé direct entre le conteneur et le réseau mondial de Cloudflare.

    Étape 1 : Préparation de l’environnement local

    La première étape consiste à déployer une application web standard sans se soucier de son exposition. Dans un conteneur LXC vierge sous Proxmox, Docker permet de lancer l’application en quelques secondes via un fichier d’orchestration docker-compose.yml. L’application tourne paisiblement sur le port 80 de la machine locale, totalement invisible depuis Internet, et protégée par le réseau LAN.

    Étape 2 : Le concept du Tunnel Zero Trust

    Plutôt que de dire à Internet « Venez taper à la porte de mon adresse IP », nous allons dire à notre serveur « Va te connecter aux serveurs de Cloudflare ». Nous installons l’agent Cloudflare directement dans le conteneur Debian. Cet agent initie une connexion sortante (qui est autorisée par défaut par le pare-feu) et maintient ce lien ouvert et chiffré.

    Étape 3 : Le routage final

    Une fois le tunnel établi, la configuration s’effectue dans le tableau de bord Cloudflare. Il suffit de lier son nom de domaine au tunnel actif, et d’indiquer à l’agent local de rediriger le trafic entrant vers le port 80 de Docker.

    Conclusion

    Le résultat est une infrastructure robuste de niveau professionnel. Le certificat SSL est géré automatiquement par Cloudflare, l’adresse IP publique de la maison reste secrète, et le pare-feu matériel reste hermétiquement fermé de l’extérieur. L’auto-hébergement redevient sûr et accessible.