Rechercher dans la communauté

IT-Connect Publié le 6 avril 2026 Par Florian BURNEL it-connect.fr Environ 24 minutes de lecture Ce guide technique explique comment installer et configurer la solution open source AdGuard Home pour bloquer les publicités et les sites malveillants à l'échelle d'un réseau. La question suivante sera aussi abordée : comment bénéficier du blocage des publicités depuis n'importe où ? Grâce à la mise en place de la solution AdGuard Home, vous reprenez le contrôle sur votre navigation. Je dirais même que, d'une façon générale, vous allez avoir plus de contrôle sur les connexions effectuées par les appareils connectés à votre réseau. En effet, au-delà de bloquer les publicités, une solution comme celle-ci peut aussi bloquer les solutions de tracking et de suivi, ainsi que des sites indésirables ou malveillants. AdGuard Home est capable de nettoyer les flux réseau sur l'ensemble des appareils : de votre ordinateur à votre smartphone, en passant par votre TV connectée à Internet. Se pose alors une première question : comment fonctionne ce mécanisme de blocage ? Avant de parler de la solution AdGuard Home et du choix de cette solution, prenons un instant pour évoquer le mécanisme de blocage. Tout va jouer au niveau du DNS. Pour rappel, le système de noms de domaine (DNS) agit comme l'annuaire d'Internet. Lorsque vous tapez l'adresse d'un site web dans votre navigateur, votre ordinateur interroge un serveur DNS pour traduire ce nom de domaine en une adresse IP compréhensible par les machines. Sans cela, on serait obligé de connaître les adresses IP des sites par cœur : c'est tout simplement impossible. Ainsi, quand vous accédez à un site web comme www.domaine.fr, votre machine interroge le serveur DNS configuré dans les paramètres réseau de votre ordinateur pour obtenir l'adresse IP correspondante. Le blocage au niveau DNS, souvent appelé "DNS sinkholing" (que l'on appelle aussi trou noir DNS, ou DNS menteur), intervient exactement à cette étape. Lorsqu'une page web tente de charger une publicité ou un script de suivi, elle effectue une requête vers un domaine spécifique (par exemple, ads.serveur-publicite.com). Si vous utilisez AdGuard Home comme serveur DNS, celui-ci compare chaque requête à une liste de filtres (blocklists). Si le domaine demandé figure dans ces listes, AdGuard Home refuse de résoudre l'adresse IP réelle et renvoie une réponse invalide (comme 0.0.0.0). Le résultat est direct : l'appareil ne peut pas contacter le serveur publicitaire, et la publicité ne s'affiche pas. Cette méthode est légère, rapide et s'applique à tous les appareils utilisant ce serveur DNS. Le site web visité, quant à lui, continuera de fonctionner correctement. En effet, si vous accédez à IT-Connect via www.it-connect.fr et que vous bloquez les publicités chargées depuis www.domaine-pub.fr, il n'y a que les contenus relatifs à la publicité qui sont bloqués. Pour certains sites mondiaux, c'est parfois difficile, car les publicités et le site web sont chargés depuis le même domaine : dans ce cas, le blocage des publicités par DNS ne peut pas fonctionner. Les fonctionnalités principales d'AdGuard Home AdGuard Home est une solution open source, gratuite et éprouvée. Elle est développée et maintenue depuis plusieurs années. Sa principale alternative est elle aussi open source et s'appelle Pi-Hole. Il en existe d'autres, comme Blocky. AdGuard Home se distingue par une interface moderne et des fonctionnalités complètes, on peut citer : Filtrage des requêtes DNS : blocage des publicités, des traqueurs et des domaines malveillants en s'appuyant sur des listes maintenues par la communauté. Sur le papier, vous pouvez bloquer n'importe quel site web grâce aux règles personnalisées. Contrôle parental : possibilité d'activer la recherche sécurisée (Safe Search) sur les principaux moteurs de recherche (Google, Bing, DuckDuckGo) pour filtrer les contenus inappropriés. Blocage de services : une section dédiée permet de bloquer rapidement des applications ou des services populaires (comme TikTok, YouTube, WhatsApp, etc.) sans avoir à chercher manuellement les domaines associés. Du blocage en 1-clic. Gestion par client (appareil) : vous pouvez appliquer des règles de filtrage spécifiques en fonction de l'adresse IP, de l'adresse MAC ou du nom de l'appareil. Cette gestion par appareil offre beaucoup de souplesse. Chiffrement DNS : par défaut, les flux du DNS ne sont pas protégés (pas de chiffrement). AdGuard Home offre l'avantage de supporter nativement des protocoles sécurisés comme DNS-over-HTTPS (DoH) et DNS-over-TLS (DoT). Cela est vrai pour échanger avec les clients et les serveurs DNS upstreams (résolveurs). Où peut-on installer AdGuard Home ? AdGuard Home est conçu pour être léger et peu gourmand en ressources, ce qui permet de le déployer sur une grande variété d'équipements. Il existe des images Docker et des programmes d'installation pour différents OS. On peut donc imaginer les scénarios d'installation suivants : Sur un NAS : Docker est pris en charge par toutes les marques (Synology, QNAP, ASUSTOR, UGREEN, etc.). Sur un nano-ordinateur : un Raspberry Pi est parfaitement adapté (via cette commande : curl -s -S -L https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v) Sur un serveur Linux ou un VPS : que ce soit sous Debian, Ubuntu ou Alpine Linux (via cette commande : curl -s -S -L https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v) Directement sur Windows ou macOS : bien que ce soit moins courant pour un usage en réseau, des exécutables sont disponibles. Ce qui est important, c'est que l'appareil soit disponible 24/7 sur votre réseau, car AdGuard Home va devenir indispensable pour assurer le bon fonctionnement de votre connexion Internet. Un NAS ou un Raspberry Pi, c'est l'idéal. Dans le cadre de ce tutoriel, nous nous concentrerons sur une installation conteneurisée via Docker. L'avantage étant de pouvoir reproduire cette configuration sur différents types d'équipements à partir du moment où Docker est présent. Tutoriel - Installer AdGuard Home sur un NAS Synology AdGuard Home : ce qu'il peut bloquer & ce qu'il ne peut pas bloquer Entre les services en ligne et les bloqueurs de publicités, c'est un peu le jeu du chat et de la souris. Chacun essaie de prendre le dessus sur l'autre. Résultat, AdGuard Home ne peut pas bloquer toutes les publicités. Ce n'est pas qu'il est mauvais, c'est qu'il est limité par son mode de fonctionnement basé sur le DNS et aussi parce qu'en face, il y a beaucoup de services qui utilisent des techniques difficiles à contourner. Voici un état des lieux : Type de contenu AdGuard Home Explication technique Bannières classiques et pop-ups ✅ Bloqué La publicité provient d'un serveur tiers. AdGuard Home bloque la résolution DNS du domaine externe. Selon la façon dont est implémentée la publicité, cela peut laisser un espace blanc sur le site web. Télémétrie et traqueurs ✅ Bloqué Excellente efficacité contre les outils d'analyse (Google Analytics), le pistage Windows, IoT ou Smart TV qui communiquent avec des serveurs dédiés. Pubs "In-App" (smartphones/jeux) ✅ Bloqué Les applications mobiles gratuites font généralement appel à des régies publicitaires externes (domaines tiers) facilement identifiables et neutralisables. Publicités vidéo (YouTube, Twitch) ❌ Non bloqué La publicité et la vidéo légitime sont diffusées par le même domaine de streaming. Bloquer la pub revient à bloquer le site, ce qui empêche son fonctionnement. Posts sponsorisés sur les réseaux sociaux ❌ Non bloqué Sur Facebook, Instagram ou X (Twitter), les annonces sponsorisées sont injectées directement dans le flux d'actualité depuis les serveurs de la plateforme. AdGuard Home ne peut rien y faire. Installation d'AdGuard Home avec Docker Pour ce déploiement, je vous propose d'utiliser un mode réseau bien spécifique au niveau de Docker : le macvlan. Ce mode permet d'attribuer une adresse IP distincte de celle du serveur Docker directement au conteneur AdGuard Home. Ainsi, il aura sa propre adresse IP pour communiquer avec les appareils du réseau. Vous pourriez tout à fait utiliser le mode habituel (bridge) pour ce conteneur, mais AdGuard Home partagerait l'adresse IP du serveur Docker. Dans ce cas, et à cause du mécanisme de NAT interne à Docker, vous ne pourriez pas voir l'adresse IP source des clients. Donc, au niveau d'AdGuard Home, toutes les requêtes seront associées à un seul client, ce qui veut dire que vous n'aurez pas de statistiques par client (ni la possibilité de faire des règles par client) dans AdGuard Home. Si ce n'est pas important pour vous, alors l'utilisation d'un réseau macvlan est facultative. Personnellement, je trouve cela contraignant. Avant de commencer, je vous rappelle que le conteneur AdGuard Home doit être joignable sur le port 53 (standard pour le DNS). D'autres ports seront utilisés en fonction des services activés (serveur DHCP géré par AdGuard Home, par exemple). Création du réseau MacVlan en ligne de commande Il est préférable de créer le réseau MacVlan manuellement en amont. La raison est simple : vous ne pouvez avoir qu'un seul réseau MacVlan rattaché à une interface physique. Peut-être même que vous en avez déjà un, selon les services déjà déployés sur votre serveur Docker. Si ce n'est pas le cas, l'idée c'est de le créer puis d'y connecter ensuite le conteneur AdGuard Home. Par la suite, vous pourriez tout à fait connecter d'autres conteneurs à ce réseau. Pour cela, ouvrez un Terminal sur votre serveur ou lancez une connexion SSH. ssh <nom utilisateur>@<IP du serveur Docker> Une fois connecté en SSH, exécutez la commande docker network indiquée ci-dessous. Attention : veillez à adapter l'interface parent (eth0), le sous-réseau (subnet), la passerelle de votre routeur (gateway) et la plage d'IP souhaitée (ip-range) à votre propre réseau local. Si vous avez connecté l'interface 1 de votre serveur Docker au réseau, cela devrait être eth0. Vous pouvez le vérifier en saisissant la commande ip a et en regardant quel est le nom de l'interface où est configurée l'adresse IP de votre serveur. Voici la commande à exécuter pour créer le réseau MacVlan : docker network create -d macvlan \ -o parent=eth0 \ --subnet=192.168.10.0/24 \ --gateway=192.168.10.254 \ --ip-range=192.168.10.144/28 \ macvlan_net Dans l'exemple ci-dessous, un masque /28 est utilisé. Ainsi, avec la plage 192.168.10.144/28, cela mettra à disposition de Docker les adresses allant de 192.168.10.144 à 192.168.10.159. De quoi vous permettre de connecter jusqu'à 14 conteneurs via ce réseau MacVlan. Ensuite, vous pouvez vérifier l'existence de ce réseau et afficher sa configuration via ces deux commandes : docker network ls docker network inspect macvlan_net Note : l'idéal, c'est que cette plage d'adresses IP (de .144 à .159) soit exclue de la plage de distribution de votre serveur DHCP (votre box Internet ou votre routeur). Cela assure qu'il n'y aura pas de conflits. Déploiement AdGuard Home avec Docker Compose Maintenant que le réseau macvlan_net existe, nous pouvons créer notre fichier docker-compose.yml. Mais avant cela, créons l'arborescence de dossiers pour la persistance des données d'AdGuard Home. sudo mkdir -p /opt/docker-compose/adguard-home/{workdir,confdir} Note : le dossier confdir contiendra le fichier de configuration AdGuardHome.yaml. Ce fichier contient l'ensemble de la configuration d'AdGuard Home. Créez un fichier docker-compose.yml : sudo touch /opt/docker-compose/adguard-home/docker-compose.yml Insérez la configuration suivante dans ce fichier : services: adguardhome: image: adguard/adguardhome:latest container_name: adguard restart: unless-stopped volumes: - ./workdir:/opt/adguardhome/work - ./confdir:/opt/adguardhome/conf networks: macvlan_net: ipv4_address: 192.168.10.151 # L'IP accessible par tous les appareils du réseau local adguard_bridge: ipv4_address: 10.10.10.2 # L'IP interne accessible par le NAS/serveur hôte networks: macvlan_net: external: true adguard_bridge: driver: bridge ipam: config: - subnet: 10.10.10.0/24 gateway: 10.10.10.1 Lancez ensuite la création du conteneur en vous plaçant dans le dossier contenant le fichier, puis exécutez : docker compose up -d L'application va s'initialiser et si vous consultez les journaux (docker compose logs), vous devriez voir ceci : adguard | [info] webapi: AdGuard Home is available at the following addresses: adguard | [info] go to http://127.0.0.1:3000 adguard | [info] go to http://[::1]:3000 adguard | [info] go to http://10.10.10.2:3000 adguard | [info] go to http://192.168.10.151:3000 adguard | [info] starting plain server server=plain addr=0.0.0.0:3000 Premiers pas avec AdGuard Home Une fois le conteneur démarré, ouvrez votre navigateur web et rendez-vous sur l'adresse IP que nous avons définie, suivie du port d'installation par défaut : http://192.168.10.151:3000. Si cela ne fonctionne pas, et que votre machine Docker est une machine virtuelle, le commutateur virtuel (vSwitch) de votre hyperviseur bloque très probablement la connexion. Pourquoi ? En réalité, le réseau Macvlan génère une nouvelle adresse MAC virtuelle pour le conteneur. Par sécurité, les hyperviseurs bloquent le trafic destiné à une adresse MAC qu'ils n'ont pas explicitement attribuée à la VM. La solution consiste à modifier les paramètres de la machine virtuelle pour autoriser ce phénomène. Ce sera une configuration à effectuer sur plusieurs plateformes (Hyper-V, VMware, Proxmox...). Dans le cas d'Hyper-V, utilisé pour cet exemple, voici l'option à activer. Configuration initiale Un assistant de configuration va vous accueillir. Cinq étapes rapides à compléter nous attendent. Cliquez sur le bouton pour commencer. Vous devez indiquer sur quelle interface réseau (et quel port) sera joignable l'interface d'administration. La même chose est demandée pour le serveur DNS (port 53). Laissez par défaut (important pour le DNS si le serveur Docker doit aussi utiliser AdGuard Home comme DNS) ou sélectionnez l'interface correspondant à votre IP 192.168.10.151. Créer un compte administrateur : choisissez un nom d'utilisateur et un mot de passe robuste. AdGuard Home vous explique rapidement comment configurer vos appareils. En effet, la mise en œuvre d'une telle solution implique une modification de la configuration des appareils de votre réseau. Il ne sera pas nécessaire de configurer manuellement chaque appareil, comme nous le verrons ensuite. Une fois ces étapes validées, le tableau de bord principal sera accessible sur http://192.168.10.151 (sans le port 3000). Voilà, la configuration initiale est terminée ! Le tableau de bord affiche des statistiques d'utilisation (requêtes DNS totales, requêtes bloquées, etc.). Le menu présent en haut permet d'accéder aux différentes sections de la configuration. Actuellement, AdGuard Home est opérationnel. Sa configuration en sortie de boîte permet de filtrer les publicités. Néanmoins, il est préférable d'ajuster sa configuration pour en profiter pleinement, c'est ce que nous allons voir. Configuration des DNS upstreams (serveurs en amont) AdGuard Home ne connaît pas toutes les adresses IP des sites web. Lorsqu'il reçoit une requête DNS légitime, il doit la transmettre à un serveur DNS externe capable de la résoudre. C'est un tiers de confiance et vous avez le choix du serveur, ou je dirais même, des serveurs, que vous souhaitez solliciter. Allez dans Paramètres > Paramètres DNS. Dans la section "Serveurs DNS en amont", vous pouvez renseigner les serveurs DNS de votre choix. Certains sont réputés pour être plus respectueux de la vie privée que d'autres, certains feront eux aussi du filtrage, etc... Il y a le choix. Surtout, AdGuard Home peut interroger ces serveurs DNS via le protocole DNS traditionnel (flux en clair) ou via DoH ou DoT, ce qui permet de chiffrer les flux. Il est donc préférable d'utiliser des serveurs DNS upstreams compatibles DoH ou DoT. Par exemple les serveurs de Quad9 et Cloudflare via DNS-over-HTTPS : https://dns10.quad9.net/dns-query https://dns.cloudflare.com/dns-query Vous pouvez visiter cette page pour avoir une liste complète de serveurs que vous pouvez solliciter en tant que résolveur DNS. Par défaut, le mode "Équilibrage de charge" est sélectionné, ce qui signifie que tous les serveurs présents dans votre liste de serveurs upstreams seront sollicités. Par exemple, AdGuard pourra solliciter un serveur DNS pour répondre à un client, et à la prochaine sollicitation, il contactera l'autre serveur DNS. Même si en réalité, AdGuard priorisera celui qui offre les meilleures performances (vous le verrez dans les statistiques). Vous pouvez aussi choisir le mode "Requêtes en parallèle" pour qu'AdGuard sollicite plusieurs serveurs en même temps. Un peu plus bas dans la page, vous allez tomber sur une section nommée "Serveurs DNS d'amorçage". Il s'agit de serveurs DNS qu'AdGuard sollicitera pour résoudre les adresses des serveurs DoH. En effet, quand on indique à AdGuard d'utiliser https://dns10.quad9.net/dns-query comme serveur upstream, il doit forcément résoudre ce nom au moins une fois (dns10.quad9.net). D'autres paramètres sont disponibles pour vous permettre de gérer le comportement du cache, de définir des résolveurs privés (notamment pour les zones de recherche inversées) et le type de blocage. Ce dernier point fait écho à mes propos précédents. En effet, vous indiquez à AdGuard Home comment il doit bloquer les sites correspondant à de la publicité ou autre... Le mode par défaut indique bien "Répondre avec adresse IP zéro", ce qui veut bien dire qu'AdGuard Home va mentir au client DNS en lui indiquant que l'IP de la ressource est 0.0.0.0. Pensez à enregistrer les paramètres modifiés au niveau de chaque section de cette même page. Gestion des listes de filtrage Par défaut, AdGuard Home utilise sa propre liste de blocage. Pour aller plus loin et améliorer la sécurité de votre réseau, je vous recommande d'ajouter des listes supplémentaires. La gestion de ces listes s'effectue ici : Filtres > Listes de blocage DNS. Cliquez sur le bouton "Ajouter liste de blocage". Vous pouvez sélectionner des listes communautaires depuis une liste préconfigurée dans AdGuard Home ou ajouter vos propres listes. L'objectif étant d'utiliser des listes qui offrent un bon ratio de blocage avec très peu de faux positifs (sites légitimes bloqués par erreur). Sinon, cela va devenir un enfer à gérer. Je vous recommande ces listes : Steven Black (reconnue mondialement) : https://adguardteam.github.io/HostlistsRegistry/assets/filter_33.txt Phishing URL Blocklist (PhishTank and OpenPhish) : https://adguardteam.github.io/HostlistsRegistry/assets/filter_30.txt Nicolas Pawlak (Red Flag Domains) pour bloquer les domaines malveillants (tentative d'usurpation de marques) : https://dl.red.flag.domains/adguard/red.flag.domains.txt Ajoutez ces listes une par une. Comme le montre l'image ci-dessous, ces listes contiennent plusieurs dizaines de milliers de règles. Si vous piochez directement dans la liste des listes proposées par AdGuard Home, vous verrez qu'elles sont organisées par catégorie. Je vous invite à cliquer sur le bouton en forme de maison pour accéder au site de la liste afin d'en savoir plus avant de l'activer. Par ailleurs, dans le menu "Filtres", il y a une entrée nommée "Règles de filtrage personnalisées". Cela vous permet de déterminer des règles de blocage ou d'autorisation personnalisées. Quand vous allez créer des exclusions via le "Journal des requêtes", cela viendra alimenter cette section. AdGuard Home intègre son propre moteur de gestion de règles, ce qui vous permet de créer du sur-mesure. Une règle || sert à bloquer, tandis qu'une règle @@|| sert à autoriser (débloquer). L'exemple ci-dessous permet de débloquer la plateforme d'affiliation awin.com, que j'utilise pour IT-Connect. C'est un système très flexible. En effet, vous pouvez gérer des clients dans AdGuard Home (c'est-à-dire vos appareils) et chaque appareil peut avoir un type (PC, NAS, mobile, etc...). Ainsi, vous avez la possibilité de créer des règles qui s'appliqueront uniquement à certains clients nommés ou certains types de clients. L'exemple ci-dessous sert à bloquer le domaine exemple.fr pour tous les clients, sauf ceux qui ont le tag device_phone. ||exemple.fr^$ctag=~device_phone La syntaxe des règles de blocage est expliquée sur cette page. Blocage des services L'une des forces de l'outil AdGuard Home, c'est sa capacité à bloquer des services populaires : ChatGPT, Tinder, Xbox Live, Dropbox, Microsoft Teams, Proton, Amazon, eBay, etc.... Une liste prédéfinie est disponible ici : Filtres > Services bloqués. Si vous souhaitez empêcher l'accès aux réseaux sociaux (ou à un autre service) sur une plage horaire ou de manière permanente, il suffit de cocher le nom du service et de sauvegarder. AdGuard Home s'occupe alors de bloquer tous les domaines liés à ce service ! En bas de page, vous pouvez aussi créer des règles selon une plage horaire. Gestion des clients Pour appliquer des règles de filtrage ou d'exclusion spécifiques, AdGuard Home doit pouvoir identifier l'origine des requêtes DNS. La solution propose quatre méthodes pour effectuer une identification des clients : Adresse IP (192.168.1.98) : la méthode la plus directe est d'identifier le client à partir de son adresse IP. Mais, attention, l'équipement doit disposer d'une IP fixe (ou d'une réservation DHCP) pour garantir que l'identification reste fiable dans le temps. S'il change d'adresse IP, cela va perturber forcément le bon fonctionnement. Plage CIDR (192.168.1.0/24) : permet d'appliquer une stratégie à un sous-réseau entier. Idéal pour traiter par lots un réseau invité ou un VLAN dédié aux objets connectés (IoT). Vous fonctionnez par sous-réseau plutôt que par client. Adresse MAC (AA:BB:CC:DD:EE:FF) : fiable car cette méthode est liée à l'interface matérielle de l'appareil. Néanmoins, cette fonctionnalité requiert que le service DHCP soit géré par AdGuard Home lui-même, et non par votre box ou routeur. ClientID (DNS chiffré) : une approche avancée réservée lors de l'utilisation des protocoles sécurisés (DoH, DoT ou DoQ). Le client s'identifie au travers d'une URL personnalisée (par exemple : https://dns.domaine.fr/dns-query/mon-client). La gestion des clients permet d'avoir une idée précise de "qui a accédé à quoi" au niveau du réseau, bien que ce soit tout de même restreint à tout accès qui implique une requête DNS en amont. Mais, c'est aussi une façon de ne pas appliquer les mêmes règles à tous les appareils. Pour gérer les clients, accédez à : Paramètres > Paramètres du client. Vous pouvez identifier une machine par son adresse IP ou son adresse MAC et lui attribuer une politique spécifique : par exemple, désactiver le blocage de certains services pour votre ordinateur de travail, mais l'activer pour les tablettes des enfants. Vous pouvez visualiser vos clients existants et en ajouter des nouveaux. Quand vous ajoutez un client, vous devez le nommer, lui associer des mots-clés (c'est-à-dire un ou plusieurs tags), et surtout un identifiant (selon l'une des méthodes évoquées ci-dessus). Vous avez la possibilité de lui associer des règles spécifiques, comme l'activation du contrôle parentale, la recherche sécurisée, etc. Les journaux d'accès La section "Journal des requêtes" accessible depuis le menu principal, permet de visualiser, en temps réel, quelles sont les requêtes DNS traitées par AdGuard Home. Vous verrez les requêtes autorisées et celles bloquées. Quand c'est bloqué, vous saurez de quelle liste provient le blocage (AdGuard DNS Filter, sur l'exemple ci-dessous). Pour chaque ligne, vous avez plusieurs informations : la date et l'heure, le nom de domaine cible, l'action, et le client à l'origine de la demande. Sur chaque ligne, vous avez aussi trois points verticaux permettant d'accéder à un menu. Quatre actions sont proposées : Débloquer : pour créer une règle permettant d'autoriser le domaine en question (de quoi gérer les faux positifs), Débloquer uniquement pour ce client : comme l'action précédente, mais en autorisant le flux uniquement pour ce client, Interdire ce client : pour bloquer totalement cet appareil. Ajouter comme client persistant : pour ajouter cet appareil comme nouveau client persistant dans votre base (ce qui va alimenter Paramètres > Paramètres du client). Vous pouvez aussi rechercher un domaine, un client, ou filtrer par type de journaux. Ci-dessous, le filtre est positionné sur "Services bloqués", ce qui permet d'afficher les requêtes pour les services bloqués via la section suivante : Filtres > Services bloqués. AdGuard Home bloque un site, que faire ? N'allez pas croire qu'AdGuard Home est une solution miracle qui ne nécessite pas de maintenance. Au début, vous aurez forcément besoin de faire des ajustements dans la configuration, notamment pour débloquer les faux positifs ou les services que vous utilisez et qui ont été bloqués. Par exemple, si vous utilisez le service de streaming TF1+ pour regarder des programmes en ligne, vous serez confronté à une erreur comme celle-ci : La raison est simple : TF1+ dispose de capacités de détection lui permettant de voir que vous essayez de bloquer les publicités. Par conséquent, il vous empêche de lire la vidéo. Face à cette situation que vous allez très certainement rencontrer, que faire ? Voici trois options pour contourner ce blocage : La liste blanche (ciblée) : ajoutez manuellement les adresses des serveurs publicitaires de TF1 dans vos règles de filtrage personnalisées AdGuard. L'analyse en direct (sur-mesure) : lancez la vidéo, consultez le journal des requêtes d'AdGuard et débloquez à la volée les lignes rouges qui s'affichent au moment du blocage. L'exclusion de l'appareil (déconseillé) : enregistrez l'adresse IP de votre TV ou Box dans les paramètres clients d'AdGuard pour désactiver totalement le filtrage antipub sur cet écran précis. Vous devez donc passer par le "Journal des requêtes" pour identifier les flux bloqués et faire le nécessaire. Pour TF1+, à l'heure actuelle, vous pouvez ajouter ces règles dans le filtrage personnalisé (pour débloquer ces domaines) : @@||pub.tf1.fr^ @@||s.tf1.fr^ @@||adproxy.tf1.fr^ @@||ads.stickyadstv.com^ @@||tf1-fram.adswizz.com^ La configuration des clients pour AdGuard Home Votre serveur AdGuard Home est activé, il est configuré, mais pour autant, il ne bloque pas encore les publicités sur vos appareils. C'est normal. Vous devez l'utiliser en tant que serveur DNS. Sur un réseau domestique, la Box est utilisée par défaut en tant que DNS. Mais, là, vous devez solliciter votre serveur AdGuard Home. Plusieurs options sont possibles pour effectuer la configuration des clients : Modifier la configuration du DHCP sur votre box (ou routeur) pour diffuser l'adresse IP de votre serveur AdGuard Home comme DNS. Au niveau des options, cela dépend si vous utilisez une Box Orange, Free, Bouygues, etc. Utiliser AdGuard Home comme DHCP, et donc diffuser son IP comme serveur DNS. Veillez à désactiver le DHCP de la Box si vous partez sur cette méthode. Éditez manuellement la configuration IP d'un appareil pour spécifier l'adresse IP du serveur AdGuard Home comme serveur DNS. Méthode nécessaire sur les appareils avec une adresse IP fixe, et dans un premier temps pour faire un test de bon fonctionnement. Sur Windows, cela revient à spécifier l'adresse IP du serveur AdGuard Home de cette façon : À partir du moment où la configuration sera effective, vous verrez de premières lignes arriver dans le journal des accès d'AdGuard Home. Bloquer les publicités depuis n'importe où Si vous désirez profiter du blocage des publicités depuis n'importe où, c'est-à-dire y compris lorsque vous n'êtes pas connecté à votre réseau local, sachez que c'est possible. Vous devez utiliser une connexion VPN vers votre réseau local, afin d'appliquer le même principe : utiliser le serveur AdGuard Home comme serveur DNS. Pour mettre en place cette connexion à distance, plusieurs solutions sont envisageables : Utiliser un VPN de type OpenVPN ou WireGuard, ce second étant recommandé pour de meilleures performances, Utiliser une solution comme Tailscale ou Twingate pour mettre en place un réseau maillé sécurisé entre vos appareils (approche ZTNA). Il existe tout de même une autre solution qui n'implique même pas l'utilisation d'un VPN : DNS-over-HTTPS. Vous pouvez exposer votre serveur AdGuard Home sur Internet sous la forme d'un serveur DNS compatible DNS-over-HTTPS (DoH). Ainsi, vous n'exposez pas directement l'interface d'administration de la solution, mais bien le point d'entrée sécurisé en HTTPS. Pour cela, vous devez : Activer l'option "Activer le chiffrement (HTTPS, DNS-over-HTTPS et DNS-over-TLS)" dans les paramètres de chiffrement d'AdGuard Home. Ce qui implique également d'importer un certificat TLS pour chiffrer les connexions. Publier AdGuard Home via un reverse proxy ou Cloudflare, de façon à publier de façon sécurisée votre instance comme vous pourriez le faire avec une autre solution. Note : sans cette configuration, AdGuard Home peut tout de même contacter les résolveurs DNS externes (upstreams) via DoH ou DoT. Conclusion Le déploiement d'AdGuard Home sur un réseau local est une démarche efficace pour assainir sa navigation web. En centralisant le filtrage au niveau du protocole DNS, vous protégez d'un seul coup l'ensemble des équipements de votre réseau, y compris les objets connectés ou les TV connectées sur lesquels l'installation d'un bloqueur de publicités n'est pas toujours possible. Je publierai très prochainement des articles complémentaires pour vous expliquer comment utiliser AdGuard Home en tant que DoH, mais pas seulement. Qu'est-ce qu'AdGuard Home ? C'est un logiciel open source agissant comme un serveur DNS pour filtrer les requêtes réseau, bloquant ainsi les publicités et le suivi à l'échelle de tout un réseau. Quelle est la différence entre AdGuard Home et Pi-hole ? Pi-hole est l'outil historique, très populaire. AdGuard Home, écrit en Go, est plus récent et propose nativement des fonctionnalités comme le chiffrement DNS (DoH/DoT) et le blocage d'applications spécifiques, sans nécessiter de configurations additionnelles. Les deux applications répondent aux mêmes besoins : le blocage des publicités. AdGuard Home bloque-t-il les publicités sur YouTube ? Le blocage des publicités YouTube via DNS est complexe car Google sert ses vidéos et ses publicités depuis les mêmes noms de domaine. AdGuard Home ne peut pas bloquer ces publicités de manière fiable sans risquer de bloquer la vidéo elle-même. Est-ce qu'AdGuard Home ralentit ma connexion Internet ? Non, je dirais même qu'il aura a tendance à l'accélérer ! En bloquant les publicités et les scripts lourds avant même qu'ils ne soient téléchargés, les pages web se chargent plus rapidement et la bande passante est économisée. Puis-je utiliser AdGuard Home en dehors de mon réseau local ? C'est possible si vous le couplez avec un serveur VPN personnel (comme WireGuard ou OpenVPN) ou des solutions de réseau maillé comme Tailscale ou Twingate. Vos appareils mobiles profiteront ainsi du filtrage même en 4G/5G. Qu'est-ce qu'un serveur DNS "upstream" ou en amont ? C'est le serveur DNS public (comme ceux de Cloudflare, Google, ou Quad9) vers lequel AdGuard Home transfère vos requêtes si le domaine demandé n'est pas bloqué par vos listes. C'est ce qui vous permet d'avoir accès à Internet. Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture. Afficher l’article complet

IT-Connect Publié le 12 mars 2026 Par Florian BURNEL it-connect.fr Environ 7 minutes de lecture Exécuter des conteneurs Docker sur un environnement Proxmox VE, c'est une action que beaucoup d'entre vous cherchent à réaliser. Quelles sont les options possibles pour utiliser Docker sur Proxmox VE ? Quels sont les avantages et les inconvénients de ces méthodes ? Voici l'essentiel à savoir à ce sujet. Pour approfondir le sujet des conteneurs sur un environnement Proxmox VE, je vous invite à lire mes deux précédents articles à propos des conteneurs LXC : Proxmox VE : bien débuter avec les conteneurs LXC Proxmox VE : exécuter des images OCI (Docker) nativement dans LXC L'option à éviter : Docker sur l'hôte Proxmox VE Commençons par ce qu'il est préférable d'éviter : l'installation de Docker directement sur l'hôte Proxmox VE en lui-même ! Cela revient à positionner Docker au même niveau que Proxmox VE, à savoir directement sur le système d'exploitation de l'hôte (Debian). Je vous déconseille d'adopter cette méthode, je trouve que ce n'est pas propre. Docker doit venir se positionner sur une couche supérieure vis-à-vis de l'hyperviseur. De plus, Proxmox VE modifie Debian pour en faire un hyperviseur, ce qui pourrait donc créer des conflits avec Docker. Par exemple, Docker modifie la configuration réseau de la machine sur laquelle il est installé. Cela pourrait donc interférer avec la gestion du réseau opérée par Proxmox VE. Option n°1 : installer Docker dans une machine virtuelle Exécuter Docker au sein même d'une machine virtuelle Proxmox VE, c'est l'option la plus robuste et qui assure une compatibilité complète avec l'ensemble des fonctionnalités de Docker. L'idée est la suivante : vous installez une machine virtuelle, sous Debian ou Ubuntu, par exemple, et vous installez les paquets Docker (et Docker Compose). La machine virtuelle est isolée vis-à-vis de l'hôte Proxmox VE et chaque partie dispose de son propre noyau Linux. Sur cette machine virtuelle, vous pouvez installer tous les conteneurs dont vous avez besoin. L'inconvénient de cette méthode, c'est qu'elle implique une augmentation de la consommation des ressources : plus de RAM, plus de processeur, car au-delà des conteneurs, il faut des ressources pour exécuter l'OS invité. C'est une différence notable vis-à-vis des conteneurs LXC réputés pour leur légèreté. Vous devez aussi assurer la maintenance du système d'exploitation invité (celui de la VM), comme pour n'importe quelle machine virtuelle. Pour la production, c'est l'approche que je préfère, et elle ressemble aussi à ce que l'on peut faire avec toutes les plateformes de virtualisation. Cette machine virtuelle avec Docker peut être facilement sauvegardée, restaurée, voire même migrée vers un autre nœud Proxmox VE. Lors de la création de cette machine virtuelle, veillez à : Activer l'agent QEMU, tout en sachant qu'il sera installé par défaut si vous utilisez une image Debian 13 Choisissez un adaptateur réseau de type VirtIO Bien que ce soit facultatif, vous pouvez ajouter un second disque qui sera dédié au stockage des données des conteneurs Docker. Vous pouvez le monter dans /opt, ce qui permet ensuite de stocker vos données de projets sous /opt/docker-compose/. Une fois la machine créée et le système d'exploitation installé, effectuez l'installation de Docker. Vous pouvez utiliser la méthode "manuelle" via les dépôts officiels ou exécuter le script d'installation. Pour la première méthode, consultez mon tutoriel d'installation de Docker sur Debian. Pour la méthode basée sur le script, exécutez simplement ceci : apt update && install curl curl -fsSL https://get.docker.com -o get-docker.sh sh get-docker.sh Voilà, vous n'avez plus qu'à créer vos premiers conteneurs (mais lisez la suite de cet article avant cela). Option n°2 : exécuter Docker dans un conteneur LXC Déployer Docker à l'intérieur d'un conteneur LXC sur Proxmox VE (via le mécanisme d'imbrication ou nesting) est une seconde option. C'est une pratique courante associée à un avantage majeur : elle consomme beaucoup moins de ressources qu'une machine virtuelle (VM). Le problème, c'est que certaines applications conteneurisées exécutées via Docker ne fonctionneront pas si ce dernier est exécuté sur un conteneur LXC. L'explication est la suivante : contrairement à une VM, un conteneur LXC utilise le noyau Linux de l'hôte Proxmox. Les conteneurs Docker à l'intérieur du LXC partagent donc ce même noyau, et les restrictions sur les conteneurs LXC peuvent ne pas plaire à toutes les applications... Pour les applications légères et ce qui s'apparente à des applications Web, cela fonctionnera bien. Je vous donne quelques exemples : Dozzle, Vaultwarden, IT-Tools, Traefik, ou encore Homer. À l'inverse, il y a des chances d'avoir des problèmes et des limitations (ou besoin de tuning spécifique) avec les applications qui ont besoin de faire un lien avec le matériel, au niveau réseau via WireGuard, par exemple. On peut citer aussi Home Assistant. Pour contourner certaines limitations, vous pourriez être amené à configurer un conteneur LXC en mode privilégié. Néanmoins, il vaut mieux éviter, car cela signifie que l'utilisateur root dans le conteneur a des permissions qui s'étendent au niveau de l'hôte Proxmox VE. Pas top niveau sécurité. En cas de difficultés, privilégiez l'utilisation d'une machine virtuelle au sein de laquelle vous installez Docker. Si vous optez pour un conteneur LXC avec Docker, la méthode propre est de rester en Unprivileged et d'activer les fonctionnalités Nesting et Keyctl. Dans un précédent article, je vous ai expliqué comment créer un conteneur LXC en ligne de commande via la commande pct. Nous pouvons utiliser cette technique pour créer un conteneur LXC correctement configuré pour Docker. Il est important d'activer les options keyctl=1 et nesting=1 (comme précisé ci-dessus). CTID=306 CTTEMPLATE="local:vztmpl/debian-13-standard_13.1-2_amd64.tar.zst" CTHOSTNAME="lxc-docker" pct create $CTID $CTTEMPLATE \ --hostname $CTHOSTNAME \ --unprivileged 1 \ --cores 2 --memory 1024 --swap 512 \ --net0 name=eth0,bridge=vmbr0,firewall=1,ip=dhcp,tag=10,type=veth \ --rootfs local-lvm:8 \ --features keyctl=1,nesting=1 \ --password VotrePassword Cette commande crée un conteneur avec 2 cœurs de CPU, 1 Go de RAM et un disque de 8 Go. C'est largement suffisant pour faire tourner certaines applications conteneurisées. Vous pourrez alors créer d'autres conteneurs LXC sur le même principe, ou avec un peu plus de ressources, selon les besoins. Une fois le conteneur déployé, installez Docker à l'intérieur, sur le même principe que pour la machine virtuelle. La gestion au quotidien avec Dockhand (ou Portainer) Proxmox VE n'intègre pas d'outils natifs pour gérer les conteneurs Docker. C'est normal, ce n'est pas son rôle. De ce fait, vous pouvez déployer une solution comme Dockhand ou Portainer pour administrer vos conteneurs au quotidien. Ayant une préférence pour le premier cité, voyons comment l'installer rapidement. Ce qui suit doit être effectué sur la machine virtuelle Docker ou le conteneur LXC Docker. Commencez par créer un dossier nommé dockhand sous /opt/docker-compose, afin de stocker les données de ce projet. Au sein de ce répertoire dédié au projet Dockhand, il conviendra de créer également un sous-dossier nommé data. Il servira à stocker les données de l'application de façon persistante (dont la base de données SQLite). sudo mkdir -p /opt/docker-compose/dockhand/data Dans le dossier /opt/docker-compose/dockhand/, créez le fichier docker-compose.yml. Ci-dessous, le code à insérer dans votre fichier Docker Compose. Par défaut, Dockhand s'appuie sur une base SQLite. Si vous avez besoin de meilleures performances, vous pouvez configurer le conteneur pour utiliser une base PostgreSQL. services: dockhand: image: fnsys/dockhand:latest container_name: dockhand restart: unless-stopped ports: - "3000:3000" volumes: - /var/run/docker.sock:/var/run/docker.sock - ./data:/app/data Lancez la construction du projet : docker compose up -d Vous pourrez alors vous connecter à votre instance Dockhand via l'adresse IP de la VM/du conteneur où Docker est installé. Précisez le port 3000 puisque Dockhand est accessible sur ce port par défaut. L'interface de Dockhand se présente à vous, vous n'aurez qu'à ajouter l'environnement Docker local pour commencer à l'administrer. Pour apprendre à utiliser Dockhand, découvrez mon guide complet : Tutoriel - Prise en main de Dockhand pour l'administration de Docker Ainsi, vous disposez de l'interface de Proxmox VE pour administrer vos machines virtuelles, les conteneurs LXC et la plateforme virtualisée en elle-même, puis de Dockhand pour l'administration des environnements Docker. Une seule instance Dockhand peut se connecter à X moteurs Docker. Docker sur Proxmox VE : quelle méthode choisir ? Si vous avez les ressources (RAM/CPU), privilégiez la VM. C'est la méthode "zéro souci", mais elle ne permet pas d'optimiser l'utilisation des ressources. Sinon, vous pouvez mixer entre une machine virtuelle et des conteneurs LXC avec Docker pour vous adapter aux besoins des applications à déployer. Autrement dit, vous pouvez utiliser des conteneurs LXC (plus légers, plus rapides) autant que possible, tout en ayant une machine virtuelle pour certains projets plus exigeants et incompatibles avec cette approche. On peut aussi voir la situation de cette façon : Machine virtuelle à privilégier en entreprise pour la stabilité et la sécurité (isolation plus forte), Conteneur LXC à privilégier pour un Homelab ou s'il y a énormément de conteneurs, pour optimiser l'utilisation des ressources, en particulier sur du matériel modeste. Conclusion Vous pouvez utiliser l'une de ces deux méthodes ou mixer les deux pour exécuter des conteneurs Docker sur Proxmox VE. Vous pouvez aussi regarder du côté des images OCI (utilisées aussi par Docker), même si cette approche manque encore de maturité à l'heure actuelle (Proxmox VE 9.1) et n'a pas encore la même souplesse que de passer directement par Docker. Si vous avez l'habitude d'exécuter des applications conteneurisées via Docker sur Proxmox VE, n'hésitez pas à partager votre retour d'expérience en commentaire. Cela sera enrichissant pour les autres lecteurs de cet article. Documentation - Proxmox VE Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture. Afficher l’article complet

IT-Connect Publié le 9 mars 2026 Par Florian BURNEL it-connect.fr Environ 9 minutes de lecture Proxmox VE 9.1 a introduit une nouveauté attendue pour les conteneurs LXC : la possibilité de lancer des images de conteneurs applicatifs (provenant de Docker Hub ou GitHub), sans passer par une machine virtuelle intermédiaire ni installer Docker. La raison : la prise en charge des images OCI. Dans notre tutoriel sur la prise en main des conteneurs LXC, nous avons vu comment déployer des "conteneurs systèmes" (une Debian ou une Ubuntu complète). Aujourd'hui, nous allons apprendre à exploiter l'intégration native des images OCI (Open Container Initiative). Cette fonctionnalité permet, par exemple, de déployer une solution de monitoring comme Uptime Kuma ou un serveur web Nginx très rapidement, en piochant dans la bibliothèque d'images existantes, tout en bénéficiant de la légèreté de LXC. Vous pouvez aussi lire mes précédents tutoriels dédiés à Proxmox VE : Bien débuter avec Proxmox VE : le guide complet Proxmox VE : comment créer une machine virtuelle Windows 11 ? Proxmox VE : la gestion des snapshots La configuration du réseau avec Proxmox VE : le guide pour bien débuter OCI sur LXC : ce que ça change Pour bien saisir ce que change cette nouveauté (encore considérée comme étant en préversion), il faut s'intéresser à la différence entre un conteneur système et un conteneur applicatif. Jusqu'ici, pour faire tourner une application "dockerisée" sur Proxmox VE, l'administrateur devait effectuer les actions suivantes : Créer une machine virtuelle ou un conteneur LXC standard (Debian). Installer le moteur Docker au sein de la VM ou du conteneur. Lancer le conteneur via docker run ou Docker Compose. Avec la prise en charge native des images OCI, Proxmox supprime l'intermédiaire, c'est-à-dire ce besoin de créer un conteneur LXC ou une machine virtuelle. L'hyperviseur est capable de télécharger l'image et de l'exécuter directement avec le moteur LXC. Pour autant, il est important de comprendre que Proxmox VE n'a pas de moteur Docker ! Vous exécutez l'image nginx:alpine ou uptime-kuma directement sur le noyau de Proxmox via un conteneur LXC. Pas de Daemon Docker, pas de VM, juste les couches de l'image OCI. Zoom sur les images OCI : au-delà de Docker Avant de manipuler ces images en pratique sur Proxmox VE, il me semble important de démystifier le terme images OCI. Une image OCI n'est pas - obligatoirement - une image Docker. OCI signifie Open Container Initiative Il s'agit d'une norme commune adoptée par les géants de la tech (Docker, Google, Red Hat, IBM) pour les images de conteneurs. Ce standard est important pour éviter une guerre entre les standards des uns et des autres qui aurait fragmenté le marché. Pour faire une analogie simple : imaginez que l'image OCI soit au conteneur ce que le format MP3 est à la musique. Peu importe que vous utilisiez VLC, Windows Media Player ou iTunes (le Runtime) pour écouter la musique, tant que le fichier est au format MP3 (le Standard), il sera lu correctement. Docker sait lire des images OCI, tout comme Proxmox VE. Chacun à sa façon, mais le résultat est là. De quoi est composée une image OCI ? Concrètement, quand vous téléchargez une image Docker (qui est en fait une image OCI), vous récupérez une archive structurée contenant trois éléments clés : Le manifeste (Manifest) : il liste les fichiers à télécharger et l'architecture CPU cible (amd64, arm64). Les couches (Layers) : c'est le système de fichiers, sous la forme d'un millefeuille de couches empilées permettant de former, ensemble, l'image. Par exemple, une couche pour l'OS de base (Alpine), une couche pour les binaires Python, une couche pour votre application. La configuration : un fichier JSON qui dit "Au démarrage, lance la commande /app/start.sh" . C'est grâce à cette standardisation que Proxmox VE est capable de faire opérer la magie de "lire" les images OCI. On peut imaginer que Proxmox VE effectue les étapes suivantes : Télécharger les couches depuis le Docker Hub. Les décompresser et les assembler. Les "donner à manger" à son propre moteur LXC, sans avoir besoin d'installer le moteur Docker. LXC reste donc le composant clé et Docker inexistant dans ce processus. Création d'un conteneur LXC avec une image OCI Dans le cadre de cette démonstration, nous allons prendre pour exemple l'outil de surveillance Uptime Kuma. Il est léger, moderne et parfait pour ce contexte d'utilisation. Télécharger une image applicative La première étape consiste à télécharger l'image OCI. Il n'est pas nécessaire de déclarer le Docker Hub comme dépôt, car il est déjà déclaré dans Proxmox VE. Depuis l'interface Web de Proxmox VE, suivez ces étapes : Allez dans votre stockage (par exemple : local). Cliquez sur la section "CT Templates", comme pour les templates LXC classiques. Cliquez sur le bouton "Pull from OCI Registry" situé à côté des autres boutons (si vous ne le voyez pas, c'est que vous devez mettre à jour PVE). Vous devez ensuite compléter le formulaire pour spécifier l'image OCI à télécharger. Dans le champ "Reference", saisissez le nom de l'image de façon explicite. Utilisez la syntaxe proprietaire/image ou repository/proprietaire/image. Ici, cela donnerait louislam/uptime-kuma ou alors de façon plus précise : Pour Docker Hub : docker.io/louislam/uptime-kuma Pour GitHub (GHCR) : ghcr.io/louislam/uptime-kuma Vous devez ensuite cliquer sur "Query tags", et si l'image a été trouvée, la liste des tags (et versions) sera affichée. Ici, je sélectionne le tag 2 pour récupérer la dernière version de la V2 d'Uptime Kuma. Lancez le téléchargement et patientez un instant. L'image OCI apparaît dans la bibliothèque aux côtés des autres modèles déjà téléchargés. Création et configuration du conteneur La création du conteneur est très similaire à celle d'un LXC classique. Une fois l'image téléchargée, cliquez sur le bouton "Créer CT". Onglet Général Donnez un ID, par exemple 303, et un nom comme lxc-oci-uptime-kuma. Décochez "Unprivileged container" si vous rencontrez des soucis de droits, bien que dans notre cas, Uptime Kuma fonctionnera bien dans un conteneur non-privilégié. Onglet Template Sélectionnez l'image louislam/uptime-kuma que vous venez de télécharger, même si elle apparaît avec le nom de l'archive. Onglets Disques/CPU/Mémoire Allouez les ressources. Ici, il convient d'adapter en fonction des besoins de l'application. Uptime Kuma avec peu de sondes n'a pas besoin de beaucoup de ressources. Le fait d'associer un disque au conteneur implique que son stockage sera persistant. Onglet réseau La mise en réseau du conteneur est différente selon si l'image OCI est exécutée via LXC ou Docker. En effet, avec Docker, vous feriez un mappage de port (-p 3001:3001), tandis qu'avec LXC, le conteneur a sa propre adresse IP sur votre réseau (via le pont vmbr0 ou une autre interface sélectionnée). Vous avez le choix entre le DHCP ou la configuration d'une adresse IP statique. Configurez le DNS si nécessaire. Confirmez pour lancer la création du conteneur. Patientez le temps que la magie opère côté Proxmox. Personnaliser les variables d'environnement Avant d'exécuter un conteneur, vous pouvez personnaliser sa configuration en ajustant les variables d'environnement. En effet, dans le cas de l'utilisation d'une image OCI sur Proxmox VE en mode natif, il n'est pas possible de jouer sur les arguments de la commande docker run ou d'utiliser les directives d'un Docker Compose. De ce fait, c'est via cette méthode que l'on peut tenter de personnaliser la configuration d'une application. Dans la section "Options" du conteneur, double-cliquez sur "Environment". Une fenêtre avec les variables d'environnement définies dans l'image OCI va s'afficher. Vous pouvez en configurer d'autres, en fonction de ce qui est pris en charge par l'application déployée (consultez la documentation de la solution en question). Dans le cas d'Uptime Kuma, il existe de nombreuses variables d'environnement. Par exemple, la variable UPTIME_KUMA_PORT sert à personnaliser le port pour accéder à l'interface Web. Cela pourrait permettre de préciser 3002 à la place de 3001 (port par défaut). Une fois vos modifications effectuées, validez. C'est éditable à tout moment, mais la prise en charge des nouvelles valeurs implique un redémarrage du conteneur. Premier démarrage du conteneur Effectuez un clic droit sur le conteneur pour le démarrer via le bouton "Start". Cliquez sur l'onglet "Network" pour afficher l'adresse IP du conteneur. Ce sera utile pour récupérer l'adresse IP dans le cas où la carte réseau est configurée en DHCP. De plus, sur ce type de conteneurs applicatifs, vous n'avez pas toujours un shell interactif complet, donc l'onglet "Console" ne sera pas d'une grande utilité (cela varie d'une image à l'autre). Ouvrez un navigateur et spécifiez l'adresse IP du conteneur suivie du port 3001 (ou 3002 si la variable avec le port personnalisé a été appliquée). Voilà, l'interface de l'application apparaît à l'écran. Il ne reste plus qu'à faire la configuration initiale et profiter de cette application conteneurisée ! Pour le reste, c'est propre à l'application Uptime Kuma en elle-même, notamment pour la création de sondes. Conclusion L'intégration des images OCI dans Proxmox VE 9.1 marque une étape importante en matière de maturité pour les conteneurs LXC avec cet hyperviseur open source. Elle offre une méthode alternative, située à mi-chemin entre Docker et LXC, bien que ce dernier soit utilisé directement, pour exécuter des conteneurs applicatifs. Cette fonctionnalité est idéale pour des applications comme Uptime Kuma, Home Assistant, Pi-hole, etc.... puisque cela évite d'utiliser un conteneur avec un système complet ou même une machine virtuelle. Néanmoins, ce n'est pas encore adapté pour les projets avec plusieurs conteneurs (comme une stack Docker Compose basée sur un ensemble de microservices). La mise à jour des conteneurs LXC basés sur une image OCI semble être également une opération délicate, que j'aborderai dans un prochain article. Ai-je besoin d'installer Docker sur mon Proxmox pour utiliser les images OCI ? Non, absolument pas. C'est tout l'intérêt. Proxmox utilise LXC pour exécuter le contenu de l'image OCI. Le moteur Docker n'est pas présent. Puis-je utiliser des fichiers docker-compose.yml ? Non. Cette fonctionnalité ne gère que des conteneurs unitaires. Vous ne pouvez pas orchestrer plusieurs conteneurs avec un fichier YAML comme avec Docker Compose. À voir si une future version de Proxmox VE apporte des améliorations à ce sujet. Est-ce que Portainer peut gérer ces conteneurs LXC ? Non. Portainer parle à l'API Docker. Ici, il n'y a pas d'API Docker. Vous devez gérer ces conteneurs via l'interface web de Proxmox ou la commande pct. Les images "Alpine" fonctionnent-elles bien ? Oui, très bien. Elles sont extrêmement légères et démarrent quasi instantanément dans un conteneur LXC. Elles sont plus légères qu'une image Debian, Ubuntu ou autre. Quelle est la différence de consommation RAM par rapport à une VM Docker ? Elle est significative. Une VM Linux consomme minimum 512 Mo à 1 Go juste pour le système d'exploitation et le moteur Docker. Un conteneur OCI sur LXC ne consomme que la RAM du processus applicatif (parfois quelques méga-octets seulement). C'est un gain énorme. Le réseau fonctionne-t-il comme le "Bridge" de Docker ? Non. Par défaut, le conteneur est relié au pont de Proxmox (vmbr0, par exemple). Il se comporte comme une machine connectée sur votre réseau local (il demande une adresse IP à votre routeur/DHCP ou utilise une IP statique). Puisque docker logs n'existe pas, vous devez consulter la console du conteneur dans Proxmox, ou regarder directement les fichiers de logs dans /var/log (si l'application écrit dedans). Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture. Afficher l’article complet

Cachem Publié le 4 février 2026 Par Fx cachem.fr Environ 1 minute de lecture LanguageTool est un outil gratuit de correction d’orthographe et de grammaire. Il dépanne au quotidien pour rédiger un e-mail, un commentaire ou un document plus long. Mais une question revient souvent : où partent les données ? Quel est le niveau de confidentialité ? Que se passe-t-il si je n’ai plus de connexion Internet ? J’ai une bonne nouvelle pour vous, il est possible d’installer LanguageTool sur un NAS. Vous allez voir, c’est assez simple 🙂 LanguageTool sur son NAS LanguageTool peut fonctionner en mode serveur via une API HTTP. Cette configuration permet aux extensions de navigateur par exemple de s’y connecter sans jamais envoyer de données vers Internet. Si vous souhaitez l’installer sur votre NAS, il faut que ce dernier soit capable d’executer des conteneurs Docker. Aussi, LanguageTool est relativement gourmand… il consomme rapidement environ 765 Mo de RAM. Si votre NAS ne dispose que de 1 Go de RAM, ce n’est clairement pas recommandé. Installer sur un NAS Synology Pour cette installation, j’ai choisi l’image Docker erikvl87/languagetool, qui est recommandée par l’éditeur de LanguageTool. Préparation des dossiers Ouvrez File Station Allez dans le dossier docker Créez un sous-dossier nommé languagetool À l’intérieur de celui-ci, créez un dossier nommé ngrams Ce dossier ngrams servira à stocker vos modèles linguistiques personnalisés. Création du conteneur Docker Ouvrez Container Manager Allez dans Projet → Créer Renseignez les informations suivantes : Nom du projet : languagetool Chemin : docker/languagetool Source : Créer un fichier docker-compose.yml Collez ensuite le contenu suivant : services: languagetool: image: erikvl87/languagetool container_name: languagetool restart: unless-stopped volumes: - ./ngrams:/ngrams environment: - Java_Xms=512m - Java_Xmx=1g - langtool_languageModel=/ngrams ports: - 8010:8010 Voici ce que vous devriez avoir : Le port 8010 exposera l’API LanguageTool sur le NAS et langtool_languageModel=/ngrams indique l’emplacement des données linguistiques. Cliquez sur Suivant, puis sur Effectué… et patientez quelques minutes le temps que le conteneur démarre. Configuration de LanguageTool dans le navigateur Côté navigateur : Installez l’extension LanguageTool Cliquez sur l’icône de l’extension Ouvrez les paramètres via la roue crantée Descendez jusqu’à « Paramètres avancés (uniquement pour les professionnels) » Dans Serveur LanguageTool, sélectionnez : Autre serveur — le serveur LanguageTool doit fonctionner ici Saisissez l’adresse suivante : http://AdresseIPduNAS:8010/v2/ C’est terminé ! En synthèse Vous utilisez désormais LanguageTool en local, sans aucune connexion à Internet. Toutes les analyses restent strictement sur votre NAS : vos données restent chez vous… vraiment. Afficher l’article complet