Avant-hier matin, mercredi 13 août, suite à une mise à jour vers Ubuntu 22 de mon serveur, j'ai eu la mauvaise surprise de ne pas le voir redémarrer...
Subissant en plus un rhume carabiné, je me suis un peu décomposé en voyant mes systèmes de supervision m'alerter lorsque la vingtaine …
Windows 10 arrive en fin de support dans moins de deux mois, est-ce qu'il faut cesser de l'utiliser dès le premier jour hors-support ? Dans le cas contraire, que peut-on faire pour en améliorer la sécurité si on souhaite le garder encore un moment ?
Quand on cherche à faire fabriquer ses propres circuits imprimés, on pense souvent en premier aux plateformes asiatiques, notamment chinoises. Pourtant, il existe des alternatives fiables et performantes en Europe… mais aussi au Canada. Bittele Electronics, dont le siège est basé à Toronto, propose une solution clé en main pour la fabrication et l’assemblage de […]
Un guide de sécurisation et de maximisation de la vie privée sur Android, tout en gardant un équilibre entre utilisabilité du système et protection trop contraignante à l'usage.
Réflexion issue d’une discussion sur le Discord de Cuistops concernant le fait que Talos pourrait ne pas être le meilleur point de départ pour s’attaquer à cette technologie d’infrastructure qui a balayé le monde de l’orchestration de containers en une petite dizaine d’années. Pour illustrer pourquoi il n’y a pas de réponse absolue à cette question, je me suis dit que vous décrire mon parcours concernant l’univers des containers et Kubernetes en particulier (aussi bien au niveau perso que pro) serait éclairant sur certains points.
Aux origines : Docker
Le moins qu’on puisse dire, c’est que mon entrée dans l’univers des containers, en particulier via docker, n’était pas brillante. Je conserve avec malice le premier billet que j’ai consacré à ce sujet en 2016 pour illustrer à quel point je me trompais sur la technologie, que je n’avais jusque là pas vraiment vu, encore moins au niveau professionnel. J’ai heureusement rattrapé cette erreur depuis, aussi bien à la faveur de formations au travail (merci Thomas Perelle ) qu’au niveau perso, où mes propres expérimentations m’ont conduit à partager ma découverte et mon utilisation de Docker Swarm. J’ai bien rattrapé le coup, hein ?
D’ailleurs, Swarm a été pour moi la découverte de la notion d’orchestration. Que j’ai pu creuser cette fois au niveau pro en 2018 après un premier tout petit pas vers l’univers Kubernetes par la porte OpenShift à la faveur d’un workshop de deux jours par un collègue qui sera réellement un mentor pour les années suivantes, Julien Francoz. Je n’ai malheureusement pas gardé grand chose de ce workshop, étant donné que je n’avais aucune plateforme de ce type dans mon pôle client, encore moins de Kubernetes. Tout juste on commençait à avoir des clients qui cherchaient à déployer leurs applis en mode container sur des serveurs classiques, avec Docker. Sans pratique, la théorie s’efface vite, d’autant qu’en 2018, les usages « domestiques » n’étaient pas légion, donc les articles de blog non plus, encore moins autour d’Openshift. C’est en 2019 que tout change.
2019 : La découverte de Kube, de la containerisation d’applications, d’Azure, de terraform (tout en même temps)
Je vous passe le contexte de comment j’en suis arrivé à cette situation intense qui aura duré 5 mois, mais oui, j’ai découvert Kubernetes d’une façon un peu particulière : service cloud managé, sur Azure, el famoso « AKS« , à devoir migrer des applications précédemment hébergées sur des serveurs virtuels Debian dépassés, avec un cluster déployé manuellement qu’on a tenté de « terraformer » après-coup, avec toute la « qualité » de l’API d’Azure d’alors. Et je remercie encore Julien d’avoir pris autant de temps à me soutenir dans cet apprentissage express (la notion de mentor n’était pas galvaudée, clairement).
Moi pendant la migration du client sur Kubernetes
Service cloud Managé veut dire qu’on ne gère pas certains aspects importants de la vie d’un cluster : tout le control plane est masqué, vous ne voyez que les nœuds, vous ne vous occupez pas trop de certains aspects comme la rotation des certificats, les mises à jour sont automatisées (vous indiquez une version cible, le service s’occupe de la montée de version du control plane, puis des nœuds un par un), et vous bénéficiez d’intégrations avec le reste de l’infra du fournisseur, au niveau du réseau, du stockage, des capacités comme l’autoscaling (vous augmentez et réduisez automatiquement le nombre de nœuds en fonction de la charge ou des réservations de ressources des pods à déployer). L’installation se fait en trois/quatre clics via l’interface web, une ligne de commande avec l’utilitaire maison, ou un peu plus de lignes de code si on le fait via un outil d’infrastructure as code.
Bref, c’est cool, ça permet de se concentrer sur les aspects opérationnels des applications déployées, mais même comme ça, je vous avoue que AKS tel que Microsoft le proposait n’était pas toujours une sinécure. Azure lui-même était pénible, avec des VMs qui mettaient plusieurs minutes à démarrer (quand les concurrents tournaient autour de la minute). Et comme on ne gère pas le control plane, on rate tout un pan de l’architecture et de la gestion de Kubernetes et de ses composants sous-jacents. En plus à l’époque, l’image de l’OS utilisé pour les nœuds était basée sur Ubuntu, pas le plus léger et le « gaspillage » de ressources était réel, au-delà de Kubernetes lui-même.
J’aurais l’occasion de passer encore quelques années, pratiquement trois, à déployer d’autres projets AKS pour d’autres clients, ce qui m’a permis de constater, il faut savoir aussi le reconnaitre, comment Microsoft a cravaché pour amener un niveau de qualité sur le service bien plus en phase avec ce qu’on attend d’un tel fournisseur. Rotation automatique des certificats via les mises à jour (c’était pas le cas, la commande de rotation était à lancer à la main), amélioration générale d’Azure sur les temps de démarrage des nœuds, efficacité des mises à jour, intégrations avancées au niveau réseau (Calico, Istio, etc)… Ce qui n’empêche pas certains pains avec entre autres une API qui accepte certaines valeurs pourtant non supportées et qui m’ont forcé à redéployer des clusters from scratch parce que la communication entre les nœuds étaient devenue impossible (réponse du support : « on va mettre à jour la doc pour indiquer les valeurs supportées »; bravo…). Par la suite, j’ai découvert et encore plus adoré exploiter et déployer du GKE, le service équivalent de Google Cloud; il m’aura permis au passage d’apprendre comment fonctionnait ce fournisseur et tout ce qu’il fait de mieux que Microsoft (et parfois d’AWS). Au point de passer la certification « Professional Architect » au bout de 4 mois seulement de pratiques.
Kube à la maison
Cette expérience en particulier avec Azure ne m’aura pas empêché pas de tomber amoureux de la technologie, au point de remiser Docker Swarm, et de migrer sur K3S. Là aussi un choix particulier, conçu pour les machines très légères, puisque ciblant les Raspberry Pi, j’ai malgré tout fait le déploiement du flemmard, même si j’ai privilégié un déploiement semi-automatisé avec un playbook/role Ansible, et un seul nœud comme control plane (qui était le seul mode de déploiement supporté alors).
Particularité de k3s, regrouper tous les composants « core » de Kubernetes dans un seul binaire, une petite prouesse à la base de son empreinte mémoire réduite, mais pas que : un des éléments les plus critiques d’un cluster, la base de données ETCD, la « mémoire » du cluster, est remplacée par SQlite, bien plus léger, mais évidemment limité à une seul nœud, et moins enclin aux problèmes des bases de données plus complexe. Bien que le mode « multi-master » ait été implémenté par la suite, au passage à mes Raspberry Pi 4, j’ai quand même conservé le même mode de fonctionnement. J’ai eu l’occasion de détailler pas mal de choses concernant K3S sur ce blog, je ne vais donc pas m’étendre beaucoup plus.
Reste qu’à l’occasion d’une volonté de refonte, accélérée par la mort successive des cartes SD des Raspi après 4 ans de bons et loyaux services, j’ai décidé de revenir à un Kubernetes un peu moins simplifié, en partant sur un autre choix particulier, Talos Linux, qui aura fini en machine virtuelle suite à une déconvenue de matériel et de limitations électriques, que je me suis pris en pleine poire en plein live Twitch. Talos propose un déploiement Kubernetes beaucoup plus standardisé dans ses composants de base, mais dont la gestion des nœuds est très particulière : pas d’OS à proprement parler, juste le noyau et une API qui permet de pratiquer toutes les opérations sur la gestion de ces nœuds : pas de SSH, pas de CLI directe, l’utilitaire talosctl est là pour configurer les nœuds à l’envi, permettant de les ajouter/retirer d’un cluster en un clin d’œil, un aspect très important dans une gestion d’infrastructure au sens large (comprendre, en entreprise). Toute la configuration de base se fait au travers de fichiers de configuration YAML, à l’instar de Kubernetes lui-même, permettant une approche « intégration continue » et un versionnement via git.
Actuellement, je me débats avec certains paramétrages par défaut orientés sécurité entre autres qui peuvent limiter/bloquer certains usages sans attention particulière. Il est vrai que par défaut, Kubernetes est une plateforme particulièrement ouverte avec peu de gardes-fous, et c’est à chacun d’adapter cet aspect en fonction de son propre contexte, ce qui amène à devoir exploiter nombre d’extensions et contrôleurs additionnels pour y parvenir. Et comme souvent, la sécurité à un prix…
Et la question de départ ?
On le voit, au final je n’ai que peu choisi comment j’ai découvert et abordé la technologie et son déploiement « dans le monde réel », et j’ai démarré par certaines abstractions qui font que si je m’étais retrouvé face à un cluster « vanilla » (kubeadm, kubespray), et un problème lié au control plane, j’aurais été plus en peine que quelqu’un ayant directement attaqué « the hard way » (z’avez la ref ?). Et d’un certain côté c’est certainement encore le cas encore aujourd’hui, ce qui me vaudrait d’être recalé au recrutement chez Lucca ou Enix. Le livre à venir teasé par Denis Germain (qui ne s’appellera pas 50 Nuances de Kubernetes, ce qui aurait été bien trop cool comme titre) montre bien la diversité d’approches qui ont chacune leurs spécificités, avec la plupart des services dit « managés » abstrayant une bonne partie des composants et concepts de bas-niveau pour vous concentrer sur vos applications ou celles de vos clients.
Est-ce que l’une d’elles est meilleure qu’une autre ? Je considère toujours que la théorie est importante, jusqu’à un certain point, dans la mesure où si on n’a pas de le contrôle sur les éléments, ne pas savoir comment ils fonctionnent de manière sous-jacente n’est pas toujours une grosse tare : ce n’est pas de notre ressort que d’y mettre les mains. Imaginez une corruption de base ETCD sur un service managé. Ma seule préoccupation sera d’être capable éventuellement de restaurer tout ce que j’y ai mis au départ – mes déploiements d’applications, mes secrets, mes CRDs, etc- , là où la préoccupation du provider, sera de réparer cette corruption; dans le pire des cas, s’il n’aura pas été capable de restaurer le service avec un minimum de pertes, il s’agira de restaurer tout ça sur un nouveau cluster.
Nous vivons également dans un monde connecté à la plus grande base de connaissances du monde : Le Web. Je n’ai pas besoin de connaitre l’intégralité des arcanes du moindre bout de logiciel, quelque soit son niveau dans l’environnement où j’évolue, pour être capable de l’exploiter au quotidien, voire de le réparer. Les connaissances déjà acquises sont évidemment importantes, parce qu’elles permettent de définir un état d’esprit, un mode de réflexion, qui est la plupart du temps applicable aux autres technologies que vous rencontrerez. Mais si je rencontre un problème que je n’ai pas déjà vu par le passé, une recherche sur le web m’amène généralement soit à la solution, soit à une piste à creuser pour déterminer la cause. Dès lors, il n’y a pas de réponses simples à apporter à la question « par où démarrer », parce qu’elle peut dépendre aussi de la « fin ».
Par où on attaque ?
Faire un cluster à la mano avec tous les composants en mode « the hard way » ne sert pratiquement à rien si après on évolue dans un contexte de service managé. À l’inverse, un service managé est intéressant en ce sens qu’il permet de gérer les interactions avec d’autres services du fournisseur, et donc le mode de fonctionnement de celui-ci. Sur Kube lui-même vous manquez des choses, mais vous avez quand même pas mal de concepts à intégrer. Est-ce moins pertinent ? Pas forcément si c’est ce que vous manipulez tous les jours. Dans le même esprit, « the hard way » est probablement la pire méthode pour gérer le quotidien sur de l’infra qu’on gère, même si pour le coup on a toutes les tripes du cluster sur la table. On privilégiera donc très vite d’autres outils plus automatisés pour la gestion habituelle. N’est-ce pas tout aussi pertinent de démarrer directement avec ces solutions pour intégrer plus rapidement leurs concepts ?
Par où commencer Kubernetes ? J’ai envie de dire, par la solution qui vous rendra curieux. C’est tout le sel de l’apprentissage, comme de la recherche scientifique, où chaque réponse qu’on trouve amène d’autres questions, tout aussi passionnantes. D’autant plus que quand on démarre, on est amené à faire, défaire, refaire, à comparer. Notre univers informatique au sens large bouge tout le temps, la « galaxie » Kubernetes n’est pas en reste, il y a toujours des dizaines d’angles d’attaque possible, et à de très rares exceptions près, il n’y en a pas nécessairement une qui est plus mauvaise qu’une autre. Et d’autres apparaitront régulièrement, ce qui représente de nouvelles réponses possibles à cette question. Il ne faut pas avoir peur de se faire plaisir de différentes manières
Gros fan et utilisateur du terminal Asbru-CM, j’ai de temps en temps besoin de pouvoir utiliser ça en mobilité. Je m’étais équipé d’une instance de SSHwifty. Cherchant un terminal, gratuit, à héberger et avec plus de fonctionnalités, mon choix s’est arrêté sur Nexterm qui ne manque pas d’options !
CAUTION Nexterm is currently in early development and subject to change. It is not recommended to use it in a production environment.
Identifiants user:pwd ou clés
2FA
Gestion d’utilisateurs
Gestionnaire de sessions et d’identifiants
SSH, sFTP, VNC, RDP, Proxmox (LXC et Qemu)
Gestion de « snippets », raccourcis de commandes à utiliser en terminal
Gestion de scripts avec raccourcis
Possibilité de déployer des Dockers
Intégration de l’IA, par exemple via un compte OpenAI pour avoir de l’aide dans un terminal
Options esthétiques…
Ok, tout n’est pas utile évidemment.
Pour l’installer, il faudra avant générer une clé de chiffrement via openssl rand -hex 32
Aussi disponible via template sous UNRAiD, attention, il manque la variable de clé de chiffrement… Je doute que ça se lance sans d’ailleurs. Il faut ajouter la variable ENCRYPTION_KEY et sa valeur
Une fois un compte créée, on peut paramétrer l’interface
Créer des identités qu’il faudra ensuite lier aux serveurs ajoutés. On peut donc utiliser soit un mot de passe soit une clé SSH.
Comme je l’écrivais, on peut ajouter de l’IA. J’ai testé rapidement, je vous montre ça ensuite.
La partie serveurs, qu’on peut organiser en dossiers, est simple et intuitive.
Choisir ou créer une identité liée
Si on active le monitoring, on l’a sur le panel homonyme avec des infos basiques mais suffisantes. A noter que ça ne me retourne jamais de version de l’OS. Je ne suis pas surpris pour UNRAiD ou Synology mais c’est plus étonnant pour Debian, Garuda (Arch) et Ubuntu. Comme indiqué sur le site, l’outil est encore à un stade de développement peu avancé.
On peut accéder à chaque serveur en même temps, dans un onglet séparé. En revanche attention si un travail est en cours, cliquer sur un autre menu dans le même onglet (du navigateur) ferme toutes les sessions.
Version sFTP, avec téléchargement, création de dossiers, édition/renommage.
On ne peut en revanche pas (encore ?) visualiser de photo ou vidéo. D’un autre côté c’est pas le but d’un FTP…
Après les clés SSH, l’une des options que je cherchais absolument était la possibilité de créer des raccourcis (alias) de commandes, qui soient globaux pour chaque terminal (et non ajouter des alias sur chaque machine). Par exemple taper « upgrade » ou cliquer un bouton (cette option avec Nextrem) qui envoie la commande sudo apt update && sudo apt upgrade -y On peut créer les snippets via le menu et ensuite les utiliser avec l’icône en haut à droite du terminal (qui se voit plus ou moins bien selon le thème…). J’ai pris des exemples basiques pour l’instant, j’ai plus testé qu’utilisé.
Cliquer sur l’icône des snippets et sur celui qu’on souhaite utiliser
Selon les configurations des users et sudoers, il faut évidemment taper le mot de passe
Si l’option d’intégration de l’IA est activée, on y accède depuis un terminal via Ctrl + k. Aucune commande n’est exécutée par l’IA, elles sont juste tapées dans le terminal et l’utilisateur doit l’exécuter.
Je ne suis ni fan ni, du coup, connaisseur, donc j’ai pas testé de demande très compliquée. Même en faisant des fautes dans la demande, elle s’en sort du du basique
Idem pour des installations basiques. Testé sur Arch aussi, c’était bon. Mais je reste sur du très simple.
Semble également fonctionner en français (vu que c’est ChatGPT dans mon test) et l’installation de Docker est correcte. Même si c’est pas optimisé (serveur Apache2n mysql de base etc)
Pour que ce soit « parfait », il faut lui indiquer quels dossiers monter etc. Bref, autant le faire à la main as usual! Mais, encore une fois, je découvre l’IA dans un terminal et ne souhaite pas approfondir cette expérience.
Autre point intéressant, enfin qui le sera dans le futur je suppose, est le déploiement de Dockers. Avec une vision devops, c’est pas mal pour envoyer rapidement des utilitaires sur des machines. L’AppsStore officiel est ici et permet de voir comment créer des applications (un docker compose ofc!). On peut donc tout à fait se faire les siennes et s’héberger sa propre source d’apps. Je ne me vois pas déployer Plex ou Nextcloud comme ça mais pour des utilitaires… Avec un Authelia en sus de tout ça…
Je devrais renommer « Streaming » en « Testing », pauvre machine… Le process est entièrement détaillé en temps réel
On peut visualiser les logs
Et j’y accède bien à la fin. Alors évidemment, aucune auth, aucune sécurité. C’est pas fait pour déployer des instances Nextcloud en prod, juste des utilitaires quand on bosse ou doit tester. Enfin à mon sens c’est le but.
J’aurais aimé avoir l’option de désinstaller le container mais ça viendra sûrement, le projet étant tout jeune (j’ai ouvert une issue).
Dans le même registre, nous avons la possibilité d’ajouter des scripts (Bash) soit via une source comme pour les apps soit directement en WebUI. Ils pourront alors être exécutés sur un serveur.
Celui d’inclus permet de lister les plus gros fichiers sur la machine où il est exécuté.
Pour l’instant on ne peut l’exécuter que sur une machine à la fois.
Pour l’instant je suis fan de l’outil ! Et comme c’est en Docker, on peut le laisser en reverse proxy normal ou le faire passer par un VPN, Tor etc. Très pratique.
Vous voulez améliorer nettement votre Wi-Fi à la maison, sans sacrifier votre vie privée ? Bonne nouvelle : on peut aujourd’hui obtenir d’excellentes perfs avec des routeurs et systèmes mesh récents qui tournent officiellement sous OpenWrt. Je vous propose une sélection 2025 claire, triée par RouteurOpenWrt et Système MeshOpenWrt, chacun en 3 niveaux de budget, avec un gros chapitre dédié OpenWrt & vie privée.
Ce qu’il faut savoir en 2 minutes
OpenWrt, c’est un système alternatif pour routeurs. Vous gagnez en contrôle, sécurité, mises à jour, et vous coupez la télémétrie superflue.
En 2025, le choix solide reste le Wi-Fi 6 (et 6E pour quelques cas). Le Wi-Fi 7 avance mais reste peu supporté proprement sous OpenWrt côté “tout-en-un”.
Si votre logement est grand ou à étages, partez sur un système mesh (deux ou trois nœuds), sinon un bon routeur suffit.
Si vous avez de la fibre ≥ 1 Gb/s, prenez un modèle avec au moins un port 2,5 GbE pour ne pas brider le débit.
La sélection des systèmes proposés dans cet article est conforme à la Table Of Hardware préconisé par OpenWrt
Pourquoi OpenWrt (et en quoi ça protège mieux votre vie privée)
OpenWrt remplace le logiciel d’origine du routeur par un système ouvert et maintenu.
Concrètement :
Mises à jour régulières et correctifs de sécurité rapides.
Aucune collecte commerciale par défaut.
DNS chiffré (DoH/DoT/DoQ) pour éviter que vos requêtes soient lisibles en clair.
Blocage des pubs et traqueurs au niveau du réseau (tous vos appareils en profitent).
VPN WireGuard directement sur le routeur (télétravail, déplacements).
Réseaux invités et VLAN pour isoler les objets connectés.
Mesh/roaming standardisés (802.11r/k/v et 802.11s) pour une vraie continuité entre nœuds.
Remarque simple : quand on parle “version stable” d’OpenWrt en 2025, on vise la branche 24.10.x. Installez la dernière révision disponible, point.
Comment choisir en routeur ou système Mesh en 30 secondes ?
Pour savoir si vous avez besoin d’un Routeur (appareil seul) ou d’un système Mesh (Plusieurs Routeurs Interconnectés) voici de quoi vous aider à choisir très simplement. Une fois que vous savez vers quoi vous orienter, rendez-vous dans la section qui vous correspond.
Surface < 100 m², peu d’obstacles → Routeur seul suffira.
De 100 à 180 m² / étage → Routeur puissant ou Mesh 2 nœuds.
> 180 m² ou murs épais → Mesh 3 nœuds, idéalement backhaul Ethernet entre les nœuds.
Beaucoup d’appareils (30+) → privilégiez Wi-Fi 6 en 4×4 et un CPU récent (MediaTek Filogic ou Qualcomm).
ROUTEURS OpenWrt — Les meilleurs choix 2025
J’ai déjà rédigé un article pour présenté les meilleurs solutions de WiFi Mesh Multiroom, et je vous invite à le consulter si vous rechercher des solutions natives grand publics. la sélection qui suit est focus sur les solutions compatibles OpenWrt, donc pour ceux qui recherchent une solution ou la transparence et le contrôle de sa vie privée est primordiale.
Routeur simple et efficace pour un petit budget. Le Wi-Fi 6 tient bien la charge pour 10 à 20 appareils, avec une portée correcte en appartement. Les ports Gigabit suffisent pour une fibre à 1 Gb/s, et OpenWrt s’installe sans prise de tête. Idéal pour activer DNS chiffré, ad-blocking et un réseau invité sans ralentir la connexion.
Format mini, perfs maxi pour sa taille. On apprécie le port 2,5 GbE et la facilité de configuration sous OpenWrt, y compris en mode voyage ou point d’accès d’appoint. Idéal pour une chambre, un bureau ou une résidence secondaire. Ça consomme peu, ça chauffe peu, et ça fait le job proprement.
Routeur discret qui passe partout, avec une radio Wi-Fi 6 très propre pour une maison standard. OpenWrt lui va bien : stabilité, bonnes vitesses et options utiles (réseau invité, contrôle parental basique). Si vous voulez un appareil qu’on installe et qu’on oublie, c’est typiquement celui-là. Excellent rapport simplicité/performances.
Haut de gamme (2,5 GbE, VPN rapide, maison > 150 m² en solo)
Un des meilleurs routeurs grand public récents compatibles OpenWrt. On a du 2,5 GbE pour le WAN et le LAN, un Wi-Fi 6 4×4 musclé et un CPU qui encaisse bien le VPN. Parfait pour un foyer très connecté ou pour lisser la latence avec du SQM. C’est puissant sans être compliqué à vivre au quotidien.
Routeur costaud, taillé pour les foyers qui veulent du 2,5 GbE partout et un VPN rapide. Le Wi-Fi 6 4×4 couvre large et reste stable, même avec beaucoup d’appareils. OpenWrt est natif dans l’ADN du produit, donc les fonctions avancées s’activent facilement. Un excellent choix “performance/praticité”.
Carte routeur pensée avec l’équipe OpenWrt pour être ouverte et durable. On y trouve du 2,5 GbE, du M.2 pour évoluer, et une base MediaTek moderne. Ce n’est pas le plus “plug-and-play” du lot, mais on contrôle tout et on apprend en chemin. Idéal si vous aimez comprendre votre réseau de A à Z.
Tableau — Routeurs (2025)
Modèle (année)
Wi-Fi
Ports RJ45
Pour qui ?
Pourquoi lui
Cudy WR3000 (2023–2025)
AX3000
1×WAN 1G + 3×LAN 1G
Budget < 100 m²
Simple, stable, parfait pour DoH + Adblock
GL-MT3000 (2023)
AX3000
1×2,5G + 1×1G
Nomade / annexe
Compact, facile à configurer
ASUS RT-AX59U (2024)
AX4200
4×1G
Maison standard
Radio propre, bonne portée
ASUS TUF-AX6000 (2024)
AX6000 4×4
WAN 2,5G + LAN 2,5G + 1G
Famille connectée
Débits élevés + faible latence
GL-MT6000 Flint 2 (2023)
AX6000 4×4
2×2,5G + 4×1G
Réseau 2,5 GbE
Très bon en VPN/WireGuard
OpenWrt One AP-24.XY (2024)
AX (2×2/3×3)
2,5G + 1G
Passionnés
Ultra-ouvert, évolutif (M.2)
SYSTÈMES MESH OpenWrt — couverture multi-pièces
Comment raisonner
Backhaul Ethernet (câble entre nœuds) : toujours mieux. Ça libère la radio pour vos appareils et évite les chutes de débit.
Backhaul radio : préférez un kit tri-bande si vous ne pouvez pas câbler.
Mesh OpenWrt : fonctionne en 802.11s (vrai maillage) et roaming 802.11r/k/v pour des bascules invisibles d’un nœud à l’autre.
Bon compromis prix/perfs pour 3 à 5 pièces. Le Wi-Fi 6 est efficace et OpenWrt offre les fonctions utiles (réseau invité, ad-blocking, DNS chiffré). Idéalement, reliez les deux boîtiers en backhaul Ethernet pour garder un Wi-Fi rapide sur tous les appareils. Vérifiez la révision matérielle compatible avant achat.
Un kit récent, discret, et facile à poser. Avec OpenWrt, on active rapidement les réglages de sécurité et le roaming, sans complexité. La couverture est homogène dans une maison de 120 à 180 m². En filaire ou en radio, le maillage reste stable pour le streaming, les visios et le jeu léger.
La valeur sûre pour les grandes surfaces sans câbles. La troisième bande sert de voie dédiée entre nœuds, donc le Wi-Fi reste fluide même en backhaul radio. OpenWrt est mature sur ce modèle, avec un roaming propre entre satellites. C’est le choix “sans surprise” pour une maison exigeante.
Astuce “Mesh DIY” : deux routeurs identiques (ex. 2× RT-AX59U ou 2× TUF-AX6000) reliés en Ethernet, avec 802.11r activé. Dans beaucoup de maisons, c’est plus stable et plus rapide qu’un mesh 100 % radio.
Tableau — Systèmes mesh (2025)
Modèle (packs)
Wi-Fi
Backhaul recommandé
Pour qui ?
Pourquoi lui
Cudy M3000
AX3000
Ethernet
Maison 3–5 pièces
Prix doux, simple à déployer
D-Link M30 Aquila
AX3000
Radio ou Ethernet
120–180 m²
Installation facile, débit stable
Linksys Velop MX4200
AX4200 tri-bande
Radio si pas de câble
Grandes maisons
Bon backhaul sans fil
Mise en route OpenWrt : le “kit privacy” en 7 étapes (5–15 min)
Changez le mot de passe admin dès la première connexion.
Mettez à jour vers la dernière révision 24.10.x disponible pour votre modèle.
Activez WPA2-AES ou WPA3 pour le Wi-Fi (évitez WPA/WEP).
DNS chiffré : installez un paquet DoH/DoT (ex. https-dns-proxy ou smartdns), choisissez un résolveur sérieux (Cloudflare, Quad9).
Bloquez pubs/trackers : installez adblock ou adblock-fast et chargez une liste légitime (par ex. oisd).
Créez un réseau invité séparé pour les objets connectés (SSID + mot de passe dédiés).
VPN (option) : si vous bossez à distance, configurez WireGuard en client vers votre fournisseur VPN, ou en serveur pour accéder chez vous.
Bonus performance : si votre box opérateur est obligatoire, mettez-la en mode bridge (ou DMZ vers le routeur OpenWrt), pour que le routeur OpenWrt gère vraiment le réseau.
Questions fréquentes
Qu’est-ce que Wi-Fi 6, 6E, 7 ?
Wi-Fi 6 = plus d’efficacité et de portée.
Wi-Fi 6E ajoute la bande 6 GHz (plus propre mais portée un peu plus courte).
Wi-Fi 7 va plus loin (agrégation de canaux, MLO), mais les routeurs “OpenWrt-friendly” sont encore rares en 2025.
Je veux juste que ça marche, sans prise de tête. Je choisis quoi ? Logement standard : ASUS RT-AX59U. Grand logement sans câble : Linksys Velop MX4200. Réseau domestique 2,5 GbE ou gros usage VPN : ASUS TUF-AX6000 ou GL-MT6000.
Et si j’ai déjà une box opérateur ? Gardez la box pour l’accès Internet, mais confiez le Wi-Fi et le routage à l’appareil OpenWrt. Idéalement, mettez la box en bridge ou en DMZ vers le routeur OpenWrt.
Wi-Fi 7 : j’achète maintenant ? Pas si vous voulez absolument OpenWrt “propre”. Préférez un bon Wi-Fi 6 maintenant. Vous ne perdrez pas grand-chose en usage réel, et vous gagnerez en stabilité.
Conseils d’achat rapides
Vérifiez la révision exacte du produit avant d’acheter (nom, version matérielle).
Prévoyez un switch 2,5 GbE si vous avez déjà un NAS/PC en 2,5 Gb/s.
Câblez ce que vous pouvez (surtout les nœuds mesh).
Un seul SSID par bande dans la plupart des cas : c’est plus simple, et le roaming fonctionne mieux.
Ça ne me sert à rien directement. Mais j'aime bien la philosophie (un peu désuet aujourd'hui) de cette méthode.
Cette page fournit (en CC-BY-NC-SA) un « petit vade-mecum à l’usage des correcteurs en herbe ».
En adoptant des systèmes électriques intelligents et des infrastructures numériques, les entreprises atteignent de nouveaux niveaux d’efficacité et de performance. Mais ce passage au numérique s’accompagne aussi d’une forte augmentation des cybermenaces. Des violations de données aux perturbations des systèmes, les risques sont bien réels et ne cessent de croître. C’est pourquoi l’intégration de services […]
La chanson, parue la même année sur l'album Urba https://fr.wikipedia.org/wiki/Urba_(album), avec ses paroles imagées très fortes, parfois poétiques et parfois franchement directes, prend déjà bien aux tripes, avec simplement des harmonies vocales et une sourdine lancinante en fond sonore.
Version album : https://www.youtube.com/watch?v=-hSvysIrsVY
Battu de vent, flottant bastion
Battus devant, flots, tourbillons
Battu, battant sang pavillon
Soleil levant, noir sans rayons
Noirs l'eau, le feu, la terre
Noirs de feu les deux airs
Le vent, la brume aussi
Mer est en brume, soleil déforme
Terre est en brume, vieille difforme
Doigts sont changeants en dix corneilles (ce que je comprends : quand on plonge les doigts dans la mer, ils ressortent couleur corneilles : noirs)
Poissons sanglants en dix orteils (et nos orteils sont remplacés par des poissons morts)
Pigeons de feu sur mer
Poison de gueux sous mer
Sept îles et fer en pluie
Morte saison sans floraison
Morte maison, sang, déraison
Saisons perdues en oraisons
Moissons perdues sans rébellion
Feuillaison en hiver
Fenaison en désert
Grésil de fer en pluie
Discours de feu, discours de veau (J'imagine bien les politiques entrer en scène ...)
Concours de peu, discours dévôts
Secours de peu, futiles travaux
Séjour de feu pour mille chevaux
Noire langue des vipères
Noire lande de colère
Les vents, les hommes aussi
Mil malloz ru*, chant de l'épée (*mille malédictions rouges, en Breton)
Mille noires statues, noirs policiers
Mille poings tendus, dix poings brisés
Mille printemps dus pour mille années
Cent mille hommes en colère
Mille hommes sans la mer (plus moyen pour les pêcheurs de sortir en mer)
Sang, larmes et fer en pluie
Mortes tribus sans héritiers
Portent tribut, sang à payer
Soleil fendu, bois condamnés
Sol est vendu, lois sont damnées
Au temps que meurt la mer
Autant se meurt la terre
Sous peur, sous fer en pluie
Jour de demain, courage ardent
Jour de Samain, coups, rage aux dents
Seront les veaux perdant sang blanc
Seront les loups perdant cent dents
Rouge fin, rouge avers
Rouges poings, rouge guerre
Rouges mains, rouges serres
Rouge festin, rouge chair
Rouge vin, rouge bière
Le feu, la mer aussi (Permalink)
The Grey Matters resource is a free online tool for finding health-related grey literature that is not published commercially and may be inaccessible via bibliographic databases.