Bienvenue dans cette seconde partie du test consacré au GL.iNet Flint 4, dédiée cette fois aux performances réseau. Si vous l’avez manqué, le premier volet est disponible ici : GL.iNet Flint 4 (GL-BE14000) – Test, 1ère partie : Prise en main.
Ce volet se veut plus technique : nous allons analyser en détail les différents benchmarks réalisés pour vérifier si ce Flint 4 tient réellement ses promesses.
Protocole de test et architecture réseau
Afin de mesurer précisément ce que le Flint 4 a dans le ventre sans être bridé par l’emplacement au sous-sol (dalle béton, distance…), j’ai découpé les mesures en deux phases distinctes :
- Phase 1 : Dans mon bureau
- Phase 2 : Au sous-sol L’objectif est d’abord de tester les débits du Wi-Fi à portée immédiate et de profiter de l’occasion pour tester le port 10 GbE en filaire, avant de basculer le routeur en conditions réelles d’exploitation au cœur de mon réseau.
Équipements mobilisés pour les tests de débits
Pour pousser le routeur dans ses retranchements, et comme je n’ai pas de machine équipée en 10 GbE natif, j’ai dû mobiliser plusieurs machines plafonnant à 2,5 GbE afin de cumuler les flux et maximiser le débit transitant par le Flint 4, pour tenter de m’approcher de ses limites. Voici les équipements utilisés lors des différents tests de débit :
- Accès Internet : ligne Fibre Bouygues Telecom (Bbox 2 Gb/s descendant / 900 Mb/s montant) ;
- Serveurs & NAS (en 2,5 GbE) : deux mini PC Geekom (IT13 et XT12 Pro) sous Proxmox VE, et mes NAS (Synology DS920+, OMV sur base Asustor, QNAP sous OMV) ;
- Clients filaires : mon MacBook Air M2 (en 2,5 GbE via un adaptateur USB-C), et un mini PC Geekom A7 (Windows 11) avec port 2,5 GbE natif ;
- Clients sans-fil : iPhone 16 Pro (compatible Wi-Fi 7 / canaux larges), iPhone 15 Plus, Samsung Galaxy S22 ;
- Outils de mesure : instance serveur
iPerf3sur le Flint 4 et clients sur les machines listées ci-dessus, complétés par des tests Speedtest pour la phase 1. J’ai également conçu des scripts (avec ChatGPT et Gemini) pour lancer des sessions iPerf3 simultanées, agréger les mesures récoltées et générer automatiquement les graphiques (scripts que je peux mettre à disposition sur simple demande).
| Routeur | Antennes et radios | Débits Wi-Fi théoriques annoncés |
|---|---|---|
| Flint 4 | 6 antennes externes, Wi-Fi 7 sur 2,4, 5 et 6 GHz | 688 Mbit/s en 2,4 GHz, 4 323 Mbit/s en 5 GHz et 8 646 Mbit/s en 6 GHz |
| Flint 2 | 4 antennes externes bibandes, Wi-Fi 6 en 4×4 | 1 148 Mbit/s en 2,4 GHz et 4 804 Mbit/s en 5 GHz |
| Appareil | Wi-Fi et bandes disponibles | Limite théorique utile pour ces tests |
|---|---|---|
| iPhone 16 Pro | Wi-Fi 7, 2×2 MIMO, 2,4 / 5 / 6 GHz | 2,4 Gbit/s en 5 ou 6 GHz sur un canal de 160 MHz |
| iPhone 15 Plus | Wi-Fi 6, 2×2 MIMO, 2,4 / 5 GHz | 1,2 Gbit/s en 5 GHz sur 80 MHz |
| MacBook Air M2 | Wi-Fi 6, 2×2 MIMO, 2,4 / 5 GHz | 1,2 Gbit/s en 5 GHz sur 80 MHz |
| iMac M1 | Wi-Fi 6, 2,4 / 5 GHz | Environ 1,2 Gbit/s en 5 GHz |
| Samsung Galaxy S22 | Wi-Fi 6, 2,4 / 5 GHz | Samsung ne publie pas de débit PHY maximal détaillé |
| Geekom A7 | MediaTek MT7922, Wi-Fi 6E 2×2 MIMO, 2,4 / 5 / 6 GHz | 2,4 Gbit/s en 5 ou 6 GHz sur un canal de 160 MHz |
Sources des données techniques : GL.iNet Flint 4, GL.iNet Flint 2, spécifications Wi-Fi des appareils Apple, Samsung Galaxy S22, GEEKOM A7 et MediaTek MT7922 / Filogic 330.
Récupération des données et création des graphiques
Pour mener à bien ces bancs d’essai, je me suis appuyé sur deux LLM (ChatGPT puis Gemini) afin de concevoir l’ensemble des scripts d’automatisation en Zsh et PowerShell, avec export systématique des données au format JSON. Ils m’ont d’abord permis de synchroniser des flux iPerf3 simultanés sur plusieurs machines pour chercher la saturation du lien 10 GbE. Dans un second temps, ils ont servi à orchestrer des vagues de tests individuels et répétés sur chaque machine (iPerf3 et Speedtest) afin de comparer précisément les débits selon les scénarios : avec ou sans VPN, et avec ou sans inspection DPI. Enfin, ces deux modèles m’ont aidé à écrire deux scripts Python dédiés au traitement de ces JSON et à la génération des graphiques comparatifs. Si ces scripts ou ces jeux de données vous intéressent pour vos propres bancs d’essai, je peux volontiers les mettre à disposition sur un dépôt GitHub sur simple demande.
Phase 1 : Le banc d’essai sur mon bureau
Pour cette première série de mesures, le Flint 4 a d’abord été installé temporairement sur mon bureau, à portée de main et juste à côté de mon ordinateur. Cette proximité immédiate facilite les branchements à répétition et offre les conditions idéales pour évaluer les capacités brutes du Wi-Fi à courte portée.
Mesures Wi-Fi
Les relevés sans fil ont été effectués à différentes distances afin de varier les conditions environnementales (vue directe sans obstacle, cloisons, étages). Côté outillage, j’ai utilisé le client iPerf3 en ligne de commande pour les ordinateurs et serveurs, et l’application mobile iPerf3 dédiée pour les smartphones (sous iOS et Android).
Débits WAN 10 GbE
Le Flint 4 a continué de faire office de serveur iPerf3. J’ai simulé une liaison WAN très haut débit sur son port RJ45 10G en lui envoyant simultanément les flux de plusieurs machines négociant en 2,5 GbE. L’objectif était d’évaluer sa capacité réelle de routage / NAT et d’observer le comportement du processeur face à cette charge intensive.
Petite anecdote révélatrice au sujet de l’écran tactile : Lors de ces premiers essais sur mon bureau, j’avais affecté le port SFP+ en WAN et le port Ethernet 10G en LAN. En descendant ensuite le Flint 4 au sous-sol pour l’installer à sa place définitive derrière la Bbox, j’ai bêtement oublié de réadapter l’attribution des interfaces… Privé d’accès réseau et n’ayant pas encore le réflexe d’utiliser l’écran tactile en façade, j’ai tout redébranché pour remonter le routeur au bureau et y brancher mon Mac, uniquement pour corriger ce paramètre dans la WebUI ! Ce n’est que plus tard, face à une manipulation similaire, que la présence de l’écran m’est revenue à l’esprit : l’opération se faisait directement dessus en quelques secondes sans aucun PC sous la main, ce qui m’aurait épargné un aller-retour et une bonne dizaine de minutes.
Phase 2 : Intégration en tête de réseau (sous-sol)
Une fois les tests unitaires validés, le Flint 4 a pris son emplacement définitif au sous-sol, venant remplacer le GL.iNet Brume 3 qui assurait jusqu’ici le rôle de passerelle principale :
- Configuration des liaisons lourdes : bascule conjointe du port SFP+ 10G et du port Ethernet RJ45 10G en mode LAN.
- Tests d’interconnexion 10G à 10G : mesures de débit LAN et transferts massifs entre le switch du sous-sol (via câble DAC SFP+) et le switch du bureau (via RJ45 10G), simulant les charges simultanées du homelab, des sauvegardes et des postes clients.
Tests Wi-Fi : Toutes les fréquences sur le gril
Tous les résultats Wi-Fi présentés ici ont été obtenus avec le Flint 4 installé dans mon bureau. Le routeur bénéficiait donc de conditions optimales, en particulier pour les mesures à 1 m et pour les appareils situés au même étage. Je conserve cette série de tests, car elle illustre parfaitement ce que le Flint 4 a dans le ventre lorsque la distance et les obstacles ne viennent pas trop le brider.
Afin d’établir un point de comparaison direct, j’ai réalisé les mêmes mesures avec le Flint 2, posé lui aussi sur mon bureau juste derrière le Flint 4 (sans réaliser sur le coup que leur proximité immédiate pouvait créer de légères interférences mutuelles…).
Passons maintenant aux bancs d’essai par bande de fréquence.
Bande 2,4 GHz : un avantage conservé par le Flint 2
Il s’agit de la bande Wi-Fi « historique » (normes 802.11b/g/n/ax) : elle privilégie la longue portée et la traversée des cloisons au détriment du débit brut.
Sur la bande des 2,4 GHz testée à 10 m derrière deux cloisons, le constat est sans appel : le Flint 2 conserve une longueur d’avance sur tous les appareils. Qu’il s’agisse de l’iPhone 15 Plus, du 16 Pro ou du Galaxy S22, le Flint 2 délivre systématiquement entre 15 et 35 Mb/s de plus, oscillant autour des 100 à 120 Mb/s là où le Flint 4 plafonne plutôt entre 65 et 90 Mb/s en download. Cette différence pourrait paraître modeste en valeur absolue, mais elle représente tout de même un écart de l’ordre de 30 %, ce qui n’est pas si négligeable.
Ce résultat n’est en réalité pas une surprise lorsqu’on se penche sur la fiche technique officielle :
- Flint 2 : jusqu’à 1 148 Mb/s théoriques sur la bande 2,4 GHz ;
- Flint 4 : plafonne à 688 Mb/s théoriques sur cette même bande.
[!info] L’explication est purement matérielle : le Flint 2 embarque une architecture radio en 4×4 MIMO sur le 2,4 GHz, lui offrant davantage de flux et une meilleure sensibilité de réception. À l’inverse, sur le Flint 4 (qui est un routeur tri-bande Wi-Fi 7), GL.iNet a choisi de passer le 2,4 GHz en 2×2 MIMO pour concentrer le gros des flux radio sur les bandes 5 GHz (4 323 Mb/s) et 6 GHz (8 646 Mb/s).
Rien d’alarmant ni de bloquant en pratique : cette bande de fréquences sert aujourd’hui quasi exclusivement aux objets connectés (IoT) ou aux connexions à longue portée, où ces débits restent largement suffisants. Mais c’est un point à souligner : le saut générationnel s’est fait sur la vitesse de pointe en 5 et 6 GHz, pas sur les 2,4 GHz.
Bande 5 GHz : le Flint 4 déploie son artillerie lourde
C’est la bande de référence pour le haut débit (normes 802.11ac/ax/be) : capable d’encaisser de gros volumes de données grâce à des canaux plus larges, mais avec une portée plus restreinte et une sensibilité importante aux obstacles. 
Dès que l’on bascule sur le 5 GHz, la dynamique change nettement en faveur du Flint 4, tout particulièrement en téléchargement (download) :
- À 1 mètre (même pièce) : le Flint 4 domine en download. Le résultat est particulièrement frappant sur l’iPhone 16 Pro où il atteint 1 429 Mb/s (contre 1 104 Mb/s pour le Flint 2). Sur les iPhone 15 Plus et Galaxy S22, on tourne autour de 770–780 Mb/s. Seule ombre au tableau : en envoi (upload), le Flint 2 garde curieusement l’avantage à courte portée, pointant à 1 627 Mb/s sur l’iPhone 16 Pro contre 1 146 Mb/s pour le Flint 4.
- À 10 mètres (deux cloisons) : à travers les obstacles, le Flint 4 montre toute son efficacité en réception. Il parvient à maintenir plus d’un gigabit réel (1 040 Mb/s) sur l’iPhone 16 Pro, là où le Flint 2 rétrograde à 877 Mb/s. Sur les autres terminaux, il reste systématiquement au-dessus de la barre des 530 Mb/s en download. Les débits en upload se tassent logiquement davantage avec la distance pour les deux routeurs, restant au coude-à-coude.
Comment expliquer ces chiffres ?
Ces écarts s’expliquent très bien dès que l’on croise la fiche technique des routeurs avec les capacités radio de chaque smartphone :
- Le cas de l’iPhone 16 Pro (la vitrine Wi-Fi 7) : c’est le seul smartphone de ce comparatif à tirer parti des avancées du Wi-Fi 7 (802.11be). Grâce au support des canaux larges de 160 MHz combiné à la modulation 4096-QAM gérée par le Flint 4, la bande passante théorique est doublée par rapport aux générations précédentes. Cela permet d’exploser le plafond du gigabit réel en téléchargement (1 429 Mb/s à 1 m et encore 1 040 Mb/s derrière deux cloisons).
- Le plafond des iPhone 15 Plus et Galaxy S22 : ces deux appareils restent cantonnés au Wi-Fi 6 conventionnel avec des canaux limités à 80 MHz (en 2×2 MIMO), ce qui bride leur liaison physique théorique à 1 201 Mb/s. Qu’ils soient connectés au Flint 2 ou au Flint 4, ils plafonnent donc naturellement autour des 770–780 Mb/s réels, ce qui correspond déjà au maximum exploitable pour cette configuration.
- La curiosité de l’upload en faveur du Flint 2 : si le Flint 4 survole le download, le Flint 2 reprend l’avantage en envoi à courte distance. Cela s’explique par sa configuration d’antennes en 4×4 MIMO sur le 5 GHz : avec quatre antennes dédiées à l’écoute, le Flint 2 capte mieux le signal émis par les puces radio des téléphones (qui émettent avec une puissance bien plus faible qu’un routeur), offrant une meilleure réception des flux montants à proximité immédiate.
Bande 6 GHz : le sommet de la chaîne Wi-Fi
C’est la toute nouvelle bande de fréquence dédiée au très haut débit (normes 802.11ax-6E et 802.11be) : à l’abri de l’encombrement spectral des bandes 2,4 et 5 GHz et capable d’exploiter des canaux ultra-larges pour des vitesses maximales, au prix d’une atténuation encore plus rapide dès que l’on s’éloigne ou traverse des murs.
À ce jour, je ne dispose toutefois que d’un seul appareil client compatible avec cette bande pour réaliser mes relevés. Les chiffres présentés ci-dessous n’ont donc pas vocation à établir une comparaison directe entre plusieurs périphériques ou avec l’ancienne génération, mais simplement à donner un aperçu concret de ce que le Flint 4 est capable de délivrer dans cette plage de fréquences. 
À 1 mètre sans obstacle, le débit en téléchargement franchit un nouveau palier pour atteindre 1 563 Mb/s (contre 1 429 Mb/s en 5 GHz, soit près de 10 % de gain). Même à 10 mètres à travers deux cloisons, le routeur maintient un niveau exceptionnel avec 1 106 Mb/s réels, conservant une courte tête sur le 5 GHz (1 040 Mb/s).
Ces excellents chiffres s’expliquent simplement :
- Un spectre avec très peu d’interférences (pour le moment) : contrairement au 5 GHz encombré par les réseaux voisins et bridé par les canaux DFS, le 6 GHz profite d’un environnement radio quasi désert. Un avantage certains aujourd’hui, qui s’érodera sans doute au fil des années à mesure que le parc de routeurs Wi-Fi 6E/7 s’installera dans le quartier.
- La limitation à 160 MHz de l’iPhone : si le Flint 4 gère des canaux géants de 320 MHz en 6 GHz, Apple bride sa puce à des canaux de 160 MHz. Le gain observé provient donc purement de la propreté du signal et non d’un doublement de la largeur de bande.
- Un upload calé sur la puissance du smartphone : en émission, les débits sont quasi superposables à ceux relevés en 5 GHz (~1 090 Mb/s à 1 m et ~590 Mb/s à 10 m). C’est ici l’amplificateur d’émission du téléphone et les contraintes physiques d’atténuation qui dictent la limite.
Le MLO (Multi-Link Operation) en pratique
J’ai fait quelques essais, mais tous sont restés sous les débits obtenus avec les réseaux 5 GHz ou 6 GHz dédiés. Je ne vais donc pas multiplier les mesures ni lui consacrer un graphique. Ce constat reste lié aux appareils utilisés et ne signifie pas que le MLO est inutile dans tous les usages.
Résultats des tests de débits : Filaire et lien 10G
Tests de débit sur la prise Ethernet 10 GbE configurée en port WAN
Lors de la phase 1, j’ai testé la prise Ethernet 10 GbE configurée en port WAN sur le Flint 4. Cette interface était raccordée à mon switch de bureau via un adaptateur SFP+ 10G. Ne disposant pas d’un hôte 10 GbE natif unique, j’ai cherché à cumuler des flux en 2,5 GbE. Toutefois, la configuration physique du banc d’essai imposait une contrainte : je n’avais que deux machines clientes présentes dans le bureau (le Geekom A7 et mon MacBook Air M2), et la liaison montante reliant mon bureau au switch du sous-sol plafonne à 2,5 GbE. Une seule machine distante du sous-sol (ici une VM Debian hébergée sur mon Geekom IT13) pouvait donc émettre sans saturer cette liaison intermédiaire.
J’ai ainsi cumulé trois flux 2,5 GbE simultanés vers le serveur iPerf3 lancé sur le routeur afin de pousser son port WAN dans ses retranchements.
Les relevés au pic de charge (calculés sur une fenêtre de 1 000 ms) démontrent une excellente tenue du Flint 4 :
- En download WAN (réception) : les trois flux cumulés atteignent un pic de 5,725 Gb/s. Le Geekom A7 (2,072 Gb/s) et le MacBook Air M2 (2,097 Gb/s) saturent quasiment leur lien 2,5 GbE respectif, complétés par la VM Debian distante (1,557 Gb/s).
- En upload WAN (émission) : les débits montent encore d’un cran pour atteindre un total cumulé de 6,719 Gb/s. Cette fois, les trois machines exploitent presque à 100 % leur liaison avec 2,361 Gb/s (Geekom A7), 2,404 Gb/s (VM Debian) et 1,954 Gb/s (MacBook Air).
Même si cette contrainte de câblage bride le test à 7,5 Gb/s théoriques (3 × 2,5 GbE), le résultat valide sans ambiguïté la capacité de routage et le comportement du processeur : encaisser plus de 6,7 Gb/s réels en trafic simultané se fait sans le moindre effondrement de paquets ni latence perceptible.
Tests de débit sur la prise SFP+ 10 GbE configurée en port LAN
Lors de la phase 2, le Flint 4 a rejoint son emplacement définitif au sous-sol : installé directement derrière la box opérateur et relié à celle-ci via un port Ethernet 2,5 GbE configuré en WAN. Ce n’est pas cette liaison montante que j’ai testée lors de cette série de mesures, mais le port SFP+ 10 GbE configuré en LAN, raccordé à mon switch principal par un câble DAC 10 Gb/s.
Tous mes serveurs et NAS étant brassés sur ce même switch en 2,5 GbE, j’ai mobilisé simultanément quatre machines pour générer quatre flux distincts à destination du serveur iPerf3 du routeur, avec pour objectif d’approcher le plafond théorique de la liaison 10G (4 × 2,5 GbE = 10 GbE).
Les quatre machines clientes mobilisées pour ce banc d’essai :
- OMV — Qnap TS-470-Pro (CPU Intel Core i7-3770) ;
- PVE — Geekom XT12Pro (CPU Intel Core i9-12900H) ;
- PVE — Geekom mini-IT13 (CPU Intel Core i9-13900H) ;
- OMV — Asustor AS6704T (CPU Intel Celeron N5105).
Les relevés au pic de charge (calculés sur une fenêtre de 1 000 ms) démontrent la tenue du lien SFP+ :
- Réception routeur (Download – flux LAN vers Routeur) : le cumul des quatre flux atteint un total de 5,720 Gb/s. Le trafic se répartit de manière homogène entre les nœuds : 1,368 Gb/s pour le NAS Qnap, 1,542 Gb/s pour le Geekom XT12Pro, 1,288 Gb/s pour le Geekom IT13 et 1,522 Gb/s pour le NAS Asustor.
- Émission routeur (Upload – flux Routeur vers LAN) : le résultat est impressionnant avec un débit cumulé qui culmine à 9,395 Gb/s. Les quatre interfaces 2,5 GbE sont saturées à leur maximum technique absolu, chacune oscillant autour de 2,35 Gb/s réels (2,350 Gb/s sur le Qnap, 2,349 Gb/s sur le XT12Pro, 2,348 Gb/s sur l’IT13 et 2,349 Gb/s sur l’Asustor).
Ce test en émission valide le comportement de la cage SFP+ et du bus interne du Flint 4 : en délivrant près de 9,4 Gb/s réels, le routeur exploite l’intégralité de la bande passante utile offerte par une liaison physique 10 GbE (une fois déduite la surcharge protocolaire TCP/IP), sans fléchir face à quatre flux concurrents.
[!cite] Explication par Gemini (LLM Google)
Pourquoi un tel écart entre l’envoi et la réception ?
Cette différence s’explique simplement par la manière dont un routeur gère les données :
- En émission (9,4 Gb/s) : le routeur a la maîtrise du flux. Il découpe et envoie les paquets de façon ordonnée vers les machines clientes en déchargeant ce travail sur sa puce réseau, ce qui lui demande très peu d’efforts de calcul.
- En réception (5,7 Gb/s) : le routeur subit une avalanche de millions de paquets arrivant en même temps de quatre sources différentes. Il doit alors trier, vérifier et remettre dans l’ordre tous ces morceaux en mémoire avant de les traiter dans l’application
iPerf3. Cet effort monopolise fortement son processeur, qui finit par atteindre sa limite de calcul pour cette tâche.Il ne s’agit donc pas d’un bridage du câble ou de la prise 10G, mais du temps nécessaire au processeur du routeur pour « digérer » simultanément quatre gros flux de données qui lui sont directement destinés.
Tests des débits unitaires par machine avec ou sans VPN (WireGuard)
J’ai réalisé ces tests lors de la phase 1, routeur dans mon bureau. J’ai voulu vérifier, dans cette dernière série de tests, les capacités du serveur VPN (WireGuard, je n’ai pas testé OpenVPN par manque de temps) depuis une prise WAN. J’ai donc connecté les machines (une par une) au serveur VPN WireGuard du Flint 4 en mode accès extérieur via la prise WAN (Ethernet 10G) car si je passais par la connexion internet, je n’aurais jamais eu de connexion adéquate pour tester correctement les débits. Ainsi je simule une connexion internet de 2,5 Gb/s via des périphériques communiquant vraiment en 2,5 Gb/s (à peu près).
Pour comparer finement les performances, j’ai réalisé des mesures iPerf3 et Speedtest sous quatre scénarios distincts. À noter que l’activation du DPI désactive obligatoirement l’accélération matérielle du réseau (hardware flow offloading) :
- Sans VPN ni DPI (accélération matérielle active) ;
- Sans VPN, avec DPI ;
- Avec VPN sans obfuscation (DPI actif) ;
- Avec VPN et obfuscation (DPI actif).
Résultats des tests iPerf3
Sur ces mesures purement locales via iPerf3, plusieurs constats sautent aux yeux :
- L’impact imperceptible du DPI : que l’inspection approfondie des paquets soit activée ou non, le débit brut reste strictement identique sur toutes les machines testées. Le NUC Geekom A7 et la VM Debian saturent intégralement le lien 2,5 GbE à environ 2 370–2 378 Mb/s en download comme en upload. Sur macOS (iMac M1 et MacBook Air M2), le débit sans VPN plafonne naturellement autour de 1 930–1 950 Mb/s en download et 2 347–2 355 Mb/s en upload, que le DPI soit enclenché ou non. Cela confirme le comportement habituel de la pile réseau d’Apple sur ces adaptateurs et démontre que le DPI n’induit aucune pénalité mesurable.
- Les performances en WireGuard : – L’anomalie de la VM Debian : la VM Debian affiche un débit de 2 358 Mb/s avec VPN, rigoureusement identique au débit hors tunnel. Face à une telle égalité au mégabit près, il est plus que probable que le tunnel WireGuard n’ait pas routé ce flux spécifique ou qu’un contournement direct ait eu lieu. N’ayant pas constaté cette anomalie à temps et n’ayant pas la possibilité matérielle de refaire la mesure, je préfère, par rigueur, écarter ce résultat qui ne reflète manifestement pas le comportement réel sous VPN. – Le NUC Geekom A7 sert donc de véritable référence matérielle x86 pour ce banc d’essai : il encaisse très bien la charge avec 1 249 Mb/s en download (sans obfuscation) et 971 Mb/s (avec obfuscation). – Les Mac (M1 et M2) montrent quant à eux une limite propre à leur implémentation client, plafonnant entre 569 et 604 Mb/s en download, et entre 288 et 356 Mb/s en upload.
- L’impact de l’obfuscation : l’ajout de la surcouche d’obfuscation entraîne un surcoût CPU non négligeable sur le Geekom A7 (perte d’environ 20 % en download comme en upload), mais cela reste imperceptible sur les Mac qui plafonnaient déjà sur leur implémentation logicielle client.
Résultats des tests Speedtest (CLI)
Ce second jeu de mesures, réalisé cette fois via l’outil officiel Speedtest en ligne de commande, vient confronter le routeur aux limites réelles d’une offre fibre grand public (ici symbolisée par un plafond théorique de 2 000 Mb/s en download et 900 Mb/s en upload) :
- En direct (sans VPN) : ce test a été réalisé lors de la phase 2, avec le Flint 4 installé au sous-sol. – En téléchargement, toutes les machines saturent le profil 2 Gb/s de la ligne, oscillant entre 1 811 Mb/s et 1 940 Mb/s. L’activation du DPI ne rogne quasiment rien : les Mac s’alignent immédiatement autour des 1 880–1 920 Mb/s, et la perte reste anecdotique sur le Geekom A7 ou la VM Debian. – En envoi, le plafond opérateur de 900 Mb/s est atteint au mégabit près sur l’ensemble du parc (940 à 950 Mb/s réels, avec ou sans DPI).
- Avec WireGuard : ce test a été réalisé lors de la phase 1, le Flint 4 étant installé sur mon bureau. – La VM Debian démontre une nouvelle fois une efficacité remarquable : en upload, elle sature le lien opérateur à 937–941 Mb/s même à travers le tunnel VPN. En download, elle assure entre 1 243 et 1 423 Mb/s, absorbant sans broncher l’essentiel de la bande passante internet. – Le Geekom A7 maintient lui aussi un excellent niveau avec plus de 1 100 Mb/s en download et 759 Mb/s en upload (tassé à 616 Mb/s avec obfuscation). – Les Mac confirment le plafond observé sous iPerf3, restant très stables autour des 560–625 Mb/s en download et 280–360 Mb/s en upload.
Que retenir de ces chiffres ?
En écartant l’anomalie de la VM Debian, le comportement du NUC Geekom A7 valide les capacités du routeur : le processeur du Flint 4 propulse sans difficulté un tunnel WireGuard à plus de 1,2 Gb/s réels. Pour un accès distant à son réseau local depuis l’extérieur, le débit offert dépassera très largement les besoins courants, même sur des transferts massifs de fichiers.
Intégration Homelab & Usage au quotidien
Après plusieurs semaines de mise en production au cœur de mon réseau, juste derrière la box opérateur, ce Flint 4 est d’une stabilité incroyable. Les seuls redémarrages que j’ai eus à faire sont survenus lors du passage d’une version bêta du firmware à la version actuelle (4.9.1) et lors de son déplacement physique de mon bureau vers le sous-sol. Les performances sont véritablement au rendez-vous, tout particulièrement sur la partie VPN. Je ne dispose pas encore d’équipement en 10G natif pour saturer de tels débits sur une seule machine, mais mes NAS et serveurs ne subissent plus aucun goulot d’étranglement lorsqu’ils communiquent simultanément : sauvegardes vers Internet, réplications entre NAS ou transferts lourds vers le Mac s’effectuent sans la moindre baisse de débit. Enfin, sa généreuse dotation en ports Ethernet et la présence de la cage SFP+ m’ont considérablement simplifié le câblage, tout en me laissant de la marge pour raccorder deux chambres supplémentaires en 2,5G dès que le besoin s’en fera sentir.
Que peut-on encore demander de plus à ce Flint 4 ?
Vous vous rappelez ce que j’ai évoqué lorsque j’ai parlé de l’interface web made in GL.iNet ? Le firmware est basé sur une vieille version d’OpenWrt. Les dépendances critiques sont bien maintenues par GL.iNet, mais beaucoup d’autres ne le sont plus. Ainsi, installer une application récente n’est pas forcément possible si le paquet n’a pas été porté pour OpenWrt 21… Et même si l’application (ou le binaire) peut tourner sur l’architecture matérielle, il arrive qu’une dépendance ne soit plus assez à jour. Bref, on peut vite se retrouver limité sur ce plan avec OpenWrt 21.
Une version OpenWrt 25 serait donc une excellente nouvelle. D’après mes échanges avec certains membres du Discord GL.iNet (a priori des employés/développeurs), une mouture basée sur OpenWrt 25 arrive très bientôt ! J’en suis ravi !
Cerise sur le gâteau : avec cette version OpenWrt 25 arrive une fonctionnalité que j’attends avec impatience depuis que j’ai su que je faisais partie du programme Créateur : le GL.iNet Mesh !
Traduction (par Ms Edge)
GL.iNet Mesh GL.iNet Mesh est la solution Wi-Fi de référence pour offrir un Wi-Fi rapide, stable et sécurisé dans chaque pièce de votre maison. Avec les routeurs puissants de GL.iNet, Mesh couvre les zones mortes et maintient des vitesses maximales sans nécessiter une configuration compliquée. Wi-Fi flexible et évolutif Le Mesh GL.iNet relie plusieurs routeurs GL.iNet pour créer un réseau Wi-Fi qui couvre toute votre maison. Vous pouvez combiner différents modèles GL.iNet pour répondre à vos besoins, et ajouter de nouveaux routeurs pour débloquer plus de fonctionnalités.
Il sera possible d’associer différents routeurs de la marque, à condition qu’ils bénéficient d’un firmware compatible (malheureusement, toute la gamme ne pourra pas en profiter…). Ce GL.iNet Mesh prendra en charge jusqu’à huit nœuds. Le backhaul Ethernet sera également de la partie : les bornes secondaires pourront ainsi être reliées au routeur principal (ou à un switch) à l’aide d’un câble réseau RJ45. C’est précisément la configuration en place chez moi avec mon Flint 2 ! Étant donné qu’un tel firmware est programmé pour le Flint 2, je vais pouvoir adopter cette solution à la maison et ne conserver qu’un unique réseau Wi-Fi unifié (avec un SSID par bande).
Voilà pour les évolutions attendues à court terme. Devant publier cet article avant la sortie officielle de ces firmwares, je proposerai un nouvel article dédié dès que j’aurai installé ces mises à jour et configuré le Wi-Fi Mesh !
Et combien coûte cette belle bête ?
Nous touchons ici la corde sensible qu’est le porte-monnaie ! ou la carte bancaire, au choix. Car le positionnement tarifaire va de pair avec les caractéristiques techniques du Flint 4.
Pour rappel, le Flint 2 est encore commercialisé au tarif de 165,37 € directement chez GL.iNet (j’avais payé le mien 142,58 € mi-2024 chez le marchand au sourire, petite inflation depuis…).
Aujourd’hui, le Flint 4 est commercialisé au tarif de 386,22 € (via la boutique GL.iNet) et à peine moins cher chez le vendeur au sourire. Ce n’est pas du tout la même gamme de prix, c’est sûr. Mais ce n’est pas non plus le même calibre technique. Le saut générationnel est tout sauf anecdotique : un port SFP+ 10G, un port Ethernet 10G, quatre ports 2,5G et autant en 1G. Ajoutez à cela le Wi-Fi 7 avec une solide bande passante sur le 6 GHz, les 64 Go de stockage eMMC et les 2 Go de RAM DDR4.
Avec l’envolée des coûts observée ces derniers mois sur les composants de stockage et de mémoire vive, il n’est guère surprenant que l’addition finale grimpe en conséquence pour un équipement aussi lourdement doté.
Ce Flint 4 change donc de catégorie et entre dans la cour des ténors du secteur. Il se retrouve en concurrence frontale avec des gammes premium comme les Asus ROG Rapture, les Netgear Nighthawk (entre le RS500 et le RS600) ou encore le TP-Link Archer BE800. L’acheteur potentiel hésitera forcément avec ces références, souvent encore un cran plus onéreuses.
Que pensez de ce tarif, me direz-vous ? Telle est la question que chacun devra se poser.
Si je n’avais pas été sélectionné pour ce Creator Program, aurais-je acheté ce routeur ? Ayant déjà un Flint 2 parfaitement fonctionnel, un seul périphérique compatible Wi-Fi 7 et pas encore de serveurs ou de switch en 10G, probablement pas dans l’immédiat. En revanche, si je n’avais pas eu un routeur aussi performant sous la main ou si ce dernier venait à lâcher, la question mériterait très sérieusement d’être posée.
Mon précédent routeur était un Synology RT2600ac, qui ne me convenait plus en raison de ses limitations logicielles : ne pas proposer de serveur WireGuard en 2024 était selon moi une aberration. Cela dit, plusieurs constructeurs concurrents cités plus haut ne l’intègrent toujours pas sur l’ensemble de leurs modèles grand public, alors que c’est devenu pour moi une exigence absolue.
Enfin, un argument de poids peut faire pencher la balance en faveur du Flint 4 : son système d’exploitation repose sur OpenWrt. Mine de rien, c’est un gage exceptionnel d’évolutivité et de pérennité logicielle. J’ai beau déplorer le choix initial d’une ancienne mouture (fortement revue, patchée et personnalisée par les équipes de développement), GL.iNet assure un suivi sérieux et déploie désormais, pour plusieurs appareils récents de son catalogue, des versions basées sur OpenWrt 24.x, voire 25.x. Mon propre Flint 2 tourne d’ailleurs depuis cet été sous le firmware GL.iNet 4.9.1-OP25, bien que cette branche reçoive des ajustements moins fréquents que celle restée sous OpenWrt 21.
OpenWrt s’appuie sur une communauté particulièrement dynamique et le support matériel du matériel récent finit toujours par mûrir. On peut donc raisonnablement espérer que d’ici quelques mois à un an, ce Flint 4 puisse accueillir une version Vanilla (pure) d’OpenWrt. D’ailleurs, une information similaire circulait récemment au sujet du Brume 3, pressenti pour recevoir lui aussi une prise en charge OpenWrt officielle très prochainement.
Annexe : Méthodologie de test & Outillage
Afin de garantir des mesures fiables et répétables, les benchmarks de cet article ont été réalisés à l’aide de scripts d’automatisation pour éviter les biais liés aux interfaces web ou aux fluctuations ponctuelles de ligne.
Mesures LAN (iPerf3)
Les débits locaux entre le sous-sol et le bureau ont été mesurés via iperf3 en mode multi-flux (-P 4) avec export JSON automatique.
- Serveur iPerf3 : Hébergé sur le Flint 4.
- Extraction : Les scripts
analyse_iperf_multi.pyetanalyse_iperf_serveurs.pyextraient les débits moyens et les pics cumulés depuis les données brutes.
Mesures WAN (Speedtest CLI)
Pour tester la saturation de la ligne Fibre sans l’interférence d’un navigateur web :
- Automatisation : Exécution de séries de 5 tests consécutifs espacés de 5 secondes via un script Shell (
run_speedtest.sh) exploitant le binaire officiel Ooklaspeedtest. - Analyse statistique : Traitement automatique via
analyse_speedtest_multi.pypermettant d’isoler les débits Minimum, Maximum et la Moyenne réelle (en Mbps) pour le Download, l’Upload et le Ping.
Mesures Wi-Fi (iPerf3)
Pour les smartphones, j’ai utilisé une application iPerf3 avec quatre connexions parallèles. Chaque valeur saisie dans le CSV est la moyenne affichée par l’application pour une session de 10 secondes ou, selon le moment de la campagne, de 30 secondes. Je n’ai donc pas les mesures brutes de chaque flux. Pour les ordinateurs, les transferts durent 20 à 30 secondes selon la campagne, avec plus de répétitions et des journaux JSON récupérés automatiquement. Le nombre de valeurs et la durée des sessions ne sont donc pas toujours identiques d’un appareil à l’autre. Je n’ai pas cherché à uniformiser artificiellement les séries : le script moyenne les sessions disponibles et affiche aussi leur plage min-max.
💡 Note : L’ensemble des scripts d’analyse et de collecte utilisés pour ce test sont documentés et disponibles sur demande.
