Internet-Box ou Raspberry Pi : lequel est vraiment plus rapide comme serveur WireGuard à domicile ? Cherchez d’abord le goulot d’étranglement

Le Raspberry Pi était déjà dans mon panier.

Il ne me restait qu’à payer.

À la maison, j’avais activé le serveur WireGuard directement sur ma Freebox. La configuration avait été presque décevante de simplicité : créer l’appareil, récupérer le fichier, l’importer sur mon portable.

Puis j’avais testé le tunnel depuis l’extérieur. Connexion immédiate. Mon NAS apparaissait. Mon adresse IP redevenait celle de la maison.

Tout fonctionnait. Le problème est arrivé quand j’ai lancé un gros transfert.

Le compteur est monté, puis s’est installé beaucoup plus bas que ce que ma fibre m’avait habitué à voir.

Ma conclusion a été immédiate : la box faisait probablement ce qu’elle pouvait avec son processeur, alors qu’un Raspberry Pi dédié n’aurait qu’une seule mission.

Quelques minutes plus tard, je comparais Pi 4, Pi 5, boîtiers et alimentations.

Je pensais chercher le serveur WireGuard le plus rapide.

En réalité, je n’avais pas encore identifié ce qui limitait ma vitesse.

Avec la fibre actuelle, la machine peut enfin devenir le maillon lent

Il y a quelques années, avec une connexion domestique montant à 10 ou 20 Mbit/s, débattre des performances WireGuard d’un routeur et d’un Raspberry Pi avait quelque chose d’académique.

La ligne gagnait presque toujours la course au goulot d’étranglement.

Ce n’est plus forcément elle qui gagne.

Fin mars 2026, la France comptait 27,7 millions d’abonnements fibre, soit 84 % des abonnements Internet fixes.

Chez Free, une Freebox Pop peut aujourd’hui annoncer jusqu’à 900 Mbit/s en débit montant, tandis que l’Ultra monte théoriquement jusqu’à 8 Gbit/s symétriques.

À ces vitesses, le matériel qui chiffre et fait transiter WireGuard peut réellement commencer à se voir.

Et puisque Free permet directement d’activer un serveur WireGuard sur ses Freebox, la question devient très tentante : pourquoi ajouter un ordinateur derrière une box qui sait déjà faire le travail ?

Ma première réponse aurait été :

parce que le Raspberry Pi peut être plus rapide.

C’était possible.

Mais il fallait encore que ce soit la vitesse dont j’avais réellement besoin.

J’avais trois plafonds, et je n’en regardais qu’un

J’imaginais mon serveur WireGuard comme un moteur. Freebox : moteur A. Raspberry Pi : moteur B. Le moteur le plus puissant gagne.

Mon transfert, lui, voyait les choses autrement.

Il devait franchir plusieurs portes : la connexion depuis laquelle j’utilisais le portable, le serveur WireGuard à la maison, puis la capacité de ma connexion domestique à renvoyer les données vers l’extérieur.

La vitesse finale ne pouvait pas dépasser la porte la plus étroite.

C’est comme remplacer un péage capable de faire passer cent voitures par minute par un modèle qui en accepte mille, alors que la route juste devant n’en apporte que quatre-vingts.

Le nouveau péage est réellement plus rapide.

Je n’arriverai pourtant pas plus tôt.

Cette image m’a obligé à regarder mon test autrement.

Si le Wi-Fi de l’hôtel plafonne à 100 Mbit/s, un Raspberry Pi capable de chiffrer plusieurs centaines de mégabits ne me donnera pas magiquement davantage.

Même chose si mon débit montant domestique constitue déjà la limite.

Le Raspberry Pi devient intéressant lorsque les autres portes sont suffisamment larges pour que la box elle-même soit enfin celle qui bloque le passage.

Et oui, un Raspberry Pi peut déplacer beaucoup de trafic WireGuard

Sur ce point, mon intuition initiale n’était pas mauvaise.

Un benchmark publié sur LaFibre.info avec un Raspberry Pi 4, OpenWRT et WireGuard a mesuré jusqu’à environ 800 Mbit/s en réception et 460 Mbit/s en émission à travers le tunnel, sur une fibre 1 Gbit/s descendant et 500 Mbit/s montant.

Ce n’était pas une promesse universelle pour tous les Raspberry Pi.

Mais c’était largement suffisant pour répondre à la question qui m’intéressait : un petit ordinateur de ce type peut-il devenir un serveur ou routeur WireGuard sérieusement rapide ?

Oui. Et il possède un autre avantage évident. Je contrôle la machine. Le système.

Les routes. Les règles réseau. Les mises à jour. Les autres services qui tournent dessus.

Pour quelqu’un qui construit déjà un homelab, veut gérer précisément son routage ou compte utiliser la machine pour plusieurs services, le Raspberry Pi peut donc être bien plus qu’un moyen de gagner quelques mégabits.

À ce moment-là, mon panier recommençait à me sembler raisonnable.

Puis j’ai cherché le chiffre qui devait rendre l’achat évident.

Je voulais un duel Freebox contre Raspberry Pi que les chiffres ne permettaient pas vraiment

Dans ma tête, il suffisait de trouver : Freebox = X Mbit/s. Raspberry Pi = Y Mbit/s. Si Y était plus grand, achat validé.

Les retours publics m’ont empêché de faire ce raccourci.

Début 2025, un utilisateur expliquait par exemple obtenir environ 300 Mbit/s avec WireGuard sur deux Freebox Pop, contre environ 40 Mbit/s sur une Mini 4K dans son installation.

L’écart était énorme.

Mais il montrait surtout pourquoi « une Freebox » n’est pas une unité de mesure.

Modèle différent. Matériel différent. Connexion différente. Conditions différentes.

Face à cela, le benchmark Raspberry Pi montrait qu’un Pi 4 correctement configuré pouvait atteindre plusieurs centaines de mégabits avec WireGuard.

Je pouvais donc raisonnablement penser qu’un appareil dédié offrirait davantage de marge si ma box devenait le plafond.

Je ne pouvais toujours pas en déduire que mon transfert actuel deviendrait plus rapide.

Et c’est cette petite différence qui m’a empêché de cliquer sur « Commander ».

Le Pi m’offrait plus de contrôle — donc plus de choses à contrôler

Il restait pourtant un argument très séduisant.

Avec un ordinateur monocarte derrière la Freebox, je pourrais faire exactement ce que je voulais.

Puis je suis tombé sur une discussion de juin 2026 qui montrait assez bien l’autre moitié de cette liberté.

Un abonné Free fibre avait installé un Odroid — un ordinateur monocarte comparable dans son rôle à un Raspberry Pi — derrière une Freebox Pop pour servir de serveur WireGuard.

Le tunnel fonctionnait.

Les clients atteignaient Internet.

Ils atteignaient le serveur.

Puis l’utilisateur a voulu faire communiquer proprement ses clients VPN avec certaines machines du LAN en IPv6.

À partir de là, la discussion est partie vers les routes IPv6, le forwarding, les redirects ICMPv6 et la manière d’annoncer correctement le sous-réseau.

Ce n’était pas la preuve qu’un serveur dédié était une mauvaise idée.

C’était presque l’inverse.

On pouvait faire beaucoup plus.

Mais plus de contrôle signifie aussi que le problème devient le mien lorsqu’une route ne fait pas exactement ce que j’attends.

J’ai regardé mon panier une nouvelle fois.

Puis je l’ai laissé ouvert et je suis revenu à ma vraie question :

qu’est-ce que j’essayais réellement d’accélérer ?

Pour mon NAS, la réponse restait WireGuard à la maison

Une partie de mon besoin ne prêtait pas à discussion.

Mes fichiers étaient chez moi.

Pour atteindre mon NAS depuis l’extérieur, mon tunnel devait revenir sur mon réseau domestique.

Sur ce point, une application VPN commerciale ne remplace ni la Freebox ni le Raspberry Pi.

J’ai donc gardé WireGuard sur la box.

Pour récupérer des documents, administrer le NAS ou atteindre ponctuellement une machine du réseau, ses performances me suffisaient déjà.

Si j’avais constaté que la Freebox plafonnait à 200 ou 300 Mbit/s alors que ma fibre montante, ma connexion distante et mon usage demandaient réellement davantage, le Raspberry Pi aurait été mon essai suivant.

Là, son potentiel de plusieurs centaines de mégabits aurait eu un sens concret.

Mais quelque chose d’autre me gênait.

Une fois mon fichier récupéré, je laissais WireGuard actif.

Et tout le reste continuait à rentrer chez moi.

Je faisais faire un détour par mon salon à tout Internet

Messagerie. Navigateur. Cloud. Vidéo.

Une fois le tunnel domestique activé, mon trafic public repartait vers mon appartement avant de ressortir sur Internet.

Pour accéder au NAS, c’était exactement ce que je voulais.

Après le téléchargement du fichier, beaucoup moins.

Mon portable pouvait se trouver à plusieurs centaines de kilomètres et je continuais à lui imposer un aller-retour par la connexion de mon domicile simplement parce que le tunnel était déjà ouvert.

À ce moment-là, le duel Freebox contre Raspberry Pi a cessé d’être la bonne question.

Pour atteindre mon NAS, je voulais un serveur chez moi.

Pour continuer à travailler ensuite, je voulais surtout que ma connexion n’ait plus besoin de repasser chez moi.

Et changer la Freebox pour un Raspberry Pi plus rapide n’aurait pas supprimé ce détour.

Cela aurait seulement construit un détour plus rapide.

J’ai coupé WireGuard après le dernier fichier

Le téléchargement terminé, j’ai désactivé le tunnel domestique.

Puis j’ai ouvert la petite application prévue pour la seconde partie du test.

Pas de serveur supplémentaire à installer dans l’appartement. Pas de nouvelle règle sur la Freebox. Pas de Raspberry Pi à administrer. Surtout, plus de débit montant domestique au milieu du trajet.

J’ai lancé la connexion adaptée au réseau que j’utilisais et repris mon travail.

Messagerie. Documents cloud. Navigateur. Visioconférence.

Tout fonctionnait sans que chaque requête fasse d’abord le voyage jusqu’à mon salon.

C’est ce résultat qui a finalement changé mon comparatif.

Je n’avais pas trouvé une application « plus rapide qu’un Raspberry Pi ».

J’avais retiré de mon trajet une machine dont je n’avais plus besoin.

Le changement de réseau m’a donné une deuxième raison de garder cette séparation

Un peu plus tard, j’ai fermé le portable et quitté le Wi-Fi.

Sur le téléphone, le réseau mobile a repris.

Je m’attendais au petit rituel habituel : vérifier le VPN, attendre la reconnexion, éventuellement relancer ce qui s’était figé.

La connexion a repris sans que j’aie à reconstruire manuellement le tunnel.

Ce comportement correspond au transport basé sur HTTP/3 utilisé par le service. HTTP/3 repose sur QUIC, dont la conception prévoit notamment la possibilité pour une connexion de s’adapter à un changement de chemin réseau.

Je n’avais pas besoin d’aller beaucoup plus loin dans la théorie. WireGuard maison répondait à une question géographique très précise : comment rentrer dans mon réseau domestique ?

La petite application répondait à une autre : comment continuer à utiliser Internet sur l’appareil qui voyage ?

Une fois ces deux tâches séparées, je n’avais plus besoin de demander à un seul tunnel de tout faire.

Le Raspberry Pi reste celui que je testerais si la Freebox devenait vraiment le plafond

Je n’ai donc pas conclu que la Freebox était plus rapide.

Je n’ai pas conclu non plus que le Raspberry Pi était inutile.

Si je transférais régulièrement de très gros volumes vers mon domicile et qu’un test montrait que le processeur ou le serveur WireGuard intégré de la box était réellement la partie la plus lente du trajet, je regarderais sérieusement un Raspberry Pi relié en Ethernet.

Les mesures publiques montrent qu’un Pi 4 peut déjà déplacer plusieurs centaines de mégabits à travers WireGuard dans une configuration adaptée.

Mais si ma Freebox atteint déjà le débit que le reste de mon trajet permet d’utiliser, elle possède un avantage difficile à battre :

elle est déjà allumée. Déjà connectée. Déjà chez moi. Et Free génère directement les configurations WireGuard nécessaires.

Ajouter un Pi dans ce scénario pourrait augmenter mon plafond sans accélérer une seule seconde de mon usage réel.

Mon panier est finalement resté vide

Pas parce que le Raspberry Pi était moins rapide.

Au contraire : si je veux davantage de marge et de contrôle pour un serveur WireGuard domestique, c’est probablement la première machine dédiée que je testerais.

Mais je ne l’achèterais plus avant d’avoir identifié la porte la plus étroite.

Pour rejoindre mon NAS, je garde le serveur domestique le plus simple qui atteint déjà le débit dont j’ai besoin.

Une fois sorti de mon réseau domestique, je préfère que ma navigation, mes appels et mes services Internet n’aient plus à traverser l’appartement. La petite application me permet justement de retirer ce détour, avec une limite crédible : elle dispose de moins de localisations et de moins de recul public que les grands fournisseurs installés depuis longtemps.

J’étais parti avec une question de puissance : Freebox ou Raspberry Pi, lequel fait passer WireGuard le plus vite ?

Je termine avec une question beaucoup plus utile : si la Freebox est réellement mon goulot d’étranglement, le Raspberry Pi peut valoir le détour ; si je n’ai plus besoin de rentrer chez moi, le serveur WireGuard domestique le plus rapide reste celui que je peux simplement couper.