WireGuard vs Tailscale vs Headscale vs NetBird : le choix de votre VPN mesh auto-hébergé

La réponse d'abord : ce n'est pas « WireGuard vs Tailscale »

WireGuard est un protocole, l'élément qui chiffre et déplace réellement vos paquets. Tailscale, Headscale et NetBird sont des control planes construits par-dessus ce protocole : ils gèrent la distribution des clés, la découverte des peers, le NAT traversal et la politique d'accès, pour que vous n'ayez pas à éditer des fichiers de configuration à la main. La requête populaire « WireGuard vs Tailscale » compare donc un protocole à un produit. La vraie décision, c'est qui gère votre control plane. Voici la version courte :

• Tailscale : vous voulez un VPN mesh qui fonctionne tout simplement, géré par quelqu'un d'autre, avec la meilleure expérience client et aucune gestion de control plane. Le prix à payer : un serveur de coordination fermé et hébergé, et une tarification par utilisateur.
• Headscale : vous voulez exactement l'expérience client de Tailscale, mais avec le serveur de coordination auto-hébergé. Open source, géré par la communauté, limité à un seul tailnet.
• NetBird : vous voulez une stack entièrement ouverte, entièrement auto-hébergeable (client et control plane), avec identity/SSO intégrés et une politique d'accès basée sur des groupes, et vous êtes prêt à faire tourner davantage de composants.
• WireGuard brut : votre topologie est petite et statique, vous voulez un contrôle maximal et le chemin de données le plus dépouillé possible, et vous gérez vous-même les clés et la configuration.

Le reste de cet article, c'est la carte, le tableau de décision, la réalité des performances (avec un mécanisme réel, pas des approximations vagues), et un verdict du point de vue d'un opérateur.

La carte : protocole, control plane, relais

Presque toutes les comparaisons dans les résultats de recherche passent à côté du seul schéma qui rend tout ce domaine limpide. Le voici sous forme de modèle en couches ; chaque produit fait des choix différents à chaque couche :

Deux conséquences découlent immédiatement de ce modèle :

• Comme chaque option utilise la même data plane WireGuard, le chiffrement et le chemin brut des paquets sont pour l'essentiel identiques. Les différences de débit viennent de la façon dont WireGuard est implémenté (noyau vs userspace) et du fait que le trafic passe en direct ou via un relais, pas du protocole.
• « Auto-hébergé » ne signifie pas la même chose selon le produit. Avec Headscale, vous auto-hébergez le serveur de coordination, mais vous utilisez toujours les clients officiels de Tailscale. Avec NetBird, vous pouvez tout auto-héberger. Avec Tailscale, vous n'auto-hébergez rien (même si vous pouvez faire tourner votre propre relais DERP). Cette distinction, c'est toute la décision, et le tableau ci-dessous la transforme en critères.

Le tableau de décision

Voici les critères sur lesquels les gens tranchent réellement. Les prix proviennent des pages des éditeurs en juillet 2026 et évoluent souvent ; vérifiez-les de nouveau avant de vous engager.

Quelques cellules méritent d'être développées, car c'est là que les gens ont des surprises.

L'ouverture des clients n'est pas l'ouverture du control plane. Les clients de Tailscale sont open source ; son serveur de coordination ne l'est pas. C'est exactement là que Headscale répond au besoin ; c'est une réimplémentation open source de ce serveur, que vous faites tourner vous-même, associée aux clients officiels de Tailscale. NetBird est open source de bout en bout (avec les composants management, signal et relais sous AGPLv3, et le reste sous BSD-3-Clause).

L'implémentation de WireGuard diffère, et c'est mesurable. Le client de Tailscale utilise un WireGuard userspace (wireguard-go) ; NetBird utilise le module WireGuard noyau sous Linux quand il est disponible, et ne bascule en userspace que lorsque ce n'est pas le cas. Ce seul fait explique la plupart des différences de débit entre les deux, développées plus loin.

Performance : d'où viennent réellement les différences

Tout le monde répète : « ils utilisent tous WireGuard, donc le débit est identique. » C'est vrai pour le protocole et faux en pratique, pour deux raisons concrètes : noyau vs userspace, et direct vs relayé.

Noyau vs userspace, pour WireGuard

Le module WireGuard noyau traite les paquets à l'intérieur du noyau. Une implémentation userspace comme wireguard-go doit faire passer chaque paquet à travers la frontière user/kernel, et cet overhead de syscall par paquet (pas le chiffrement lui-même) est le prix à payer. Il augmente avec le débit de paquets, donc il se voit surtout sur les charges de travail à haut débit et petits paquets.

Quelle est l'ampleur de cet écart ? Prenez les chiffres des personnes qui ont écrit l'implémentation userspace elles-mêmes. Le blog technique de Tailscale rapporte une base de référence de 2.66 Gbit/s pour WireGuard noyau contre 2.42 Gbit/s pour wireguard-go dans le même test, et après l'ajout d'optimisations de segmentation-offload et de batching, leur chemin userspace a atteint 5.36 Gbit/s, dépassant même la base de référence noyau non optimisée. Ils ont aussi montré que le seul fait de monter la MTU de 1500 à 9001 a fait passer wireguard-go de 2.42 à 7.88 Gbit/s. Interprétez cela honnêtement : sur une configuration à MTU par défaut et non optimisée, l'userspace paie une vraie pénalité ; avec des jumbo frames et des offloads modernes, le chemin userspace peut être très rapide. La règle empirique de la communauté, à savoir une pénalité de ~10–15 % pour l'userspace sur des configurations par défaut, est juste dans sa tendance mais dépend de la configuration.

Les enseignements pratiques :

• Si vous devez saturer une liaison rapide avec un seul flux et voulez le chemin le plus dépouillé, WireGuard noyau brut (ou le mode noyau de NetBird sous Linux) a l'avantage sur une configuration par défaut.
• La MTU compte plus que le choix du produit. Une MTU d'overlay mal configurée (la valeur par défaut de l'interface WireGuard est d'environ 1420, pour laisser de la place à l'encapsulation) vous coûte plus de débit que noyau-vs-userspace. Réglez d'abord la MTU correctement.
• Pour l'immense majorité du trafic réel (de nombreux petits flux, bien en dessous du gigabit), la différence est imperceptible, et vous devriez choisir en fonction de l'exploitation et des fonctionnalités, pas des benchmarks.

Des benchmarks indépendants confirment ces enseignements. Une étude de l'université d'Amsterdam sur une liaison à 1 Gbit/s a montré que WireGuard noyau et wireguard-go en userspace saturaient tous les deux la liaison (~900 Mbit/s), mais wireguard-go y brûlait 230 % d'un cœur de CPU pour y parvenir, contre largement moins d'un cœur pour le module noyau. Le coût de l'userspace se paie en CPU, et il ne devient un plafond de débit qu'une fois que le CPU devient le goulot d'étranglement (liaisons plus rapides, paquets plus petits). Sur du vrai matériel 10 GbE, Protectli a mesuré WireGuard noyau brut à 4.15–5.01 Gbit/s (iperf3, quatre flux) sur ses appliances milieu de gamme ; sur un desktop modeste datant de 2016 en gigabit, TechOverflow a mesuré Tailscale à 354/194 Mbit/s, soit environ la moitié de ce que la même liaison faisait sans lui, exactement le cas d'un CPU faible où le chemin userspace devient la limite.

La seule comparaison directe qui mérite d'être citée est celle de NetBird lui-même, et elle est d'une honnêteté rafraîchissante : en testant NetBird 0.68.3 face à Tailscale 1.96.4 sur des hôtes cloud, les deux ont atteint ~1.26–1.30 Gbit/s sur une liaison de datacenter au sein d'un même pays, et l'auteur (qui écrit sur le blog de NetBird) a conclu que les deux sont « fondamentalement identiques… aucun avantage cohérent et reproductible ». C'est le bilan honnête : sur du matériel performant, tous ces produits se valent ; l'écart noyau-vs-userspace n'apparaît que lorsque le CPU devient le goulot d'étranglement, et la MTU compte généralement plus que le produit choisi.

Direct vs relayé, et NAT traversal

Quand deux peers peuvent ouvrir une connexion directe, WireGuard fonctionne en pair-à-pair et vous obtenez les chiffres ci-dessus. Quand ce n'est pas possible (CGNAT des deux côtés, firewalls stricts, UDP bloqué), le trafic bascule vers un relais, et un relais est un saut supplémentaire partagé et placé géographiquement, qui ajoute de la latence et peut plafonner le débit.

• Tailscale et Headscale utilisent DERP (Designated Encrypted Relay for Packets). DERP relaie des paquets WireGuard déjà chiffrés, donc il ne peut pas déchiffrer votre trafic ; c'est un dispositif de secours, pas un homme du milieu. Vous pouvez auto-héberger un nœud DERP pour contrôler où va le trafic relayé.
• NetBird utilise ICE (STUN pour découvrir les mappings publics, TURN pour relayer) et est en train de passer de Coturn à son propre relais basé sur WebSocket.

À quelle fréquence ce repli se produit-il réellement, et à quel coût ? Tailscale est le seul à publier des chiffres solides, et ils sont rassurants : l'entreprise indique un « NAT traversal direct largement au-dessus de 90 % » en conditions typiques, plus de neuf connexions sur dix finissent donc en direct plutôt que relayées, même si ce chiffre n'est pas détaillé pour les cas difficiles (CGNAT des deux côtés, NAT symétrique), où les chances diminuent. Quand une connexion passe effectivement par un relais, le coût en latence dépend de la distance à laquelle se trouve ce relais : dans une étude de cas de Tailscale sur une liaison Inde-États-Unis, le passage par un nœud DERP distant a donné 452 ms contre 298 ms pour une liaison plus proche et quasi directe, soit environ 150 ms de détour évitable. NetBird ne publie aucun chiffre équivalent de taux de réussite, donc pour NetBird (et pour votre propre réseau, quel que soit l'outil), le résultat direct-vs-relais et la pénalité de latence du relais sont des choses à mesurer plutôt qu'à supposer.

Les quatre options, honnêtement

WireGuard brut

Point fort : l'option la plus dépouillée, la plus rapide, la plus auditable : une toute petite base de code dans le noyau, sans control plane à faire confiance ou à exploiter. Pour une poignée de peers statiques (quelques serveurs, une liaison site à site), rien ne la bat en simplicité et en performance. Nous l'utilisons exactement ainsi dans notre guide sur un VPN site à site avec WireGuard sur VyOS.

Limite la plus nette : il n'a pas de control plane, et cela va très bien jusqu'au jour où cela ne va plus. Au-delà d'une dizaine de peers, gérer les clés, l'allocation d'IP et le maillage AllowedIPs à la main devient un vrai travail, et il n'y a pas de NAT traversal intégré ; les peers derrière un CGNAT ont besoin d'un relais que vous devez construire vous-même. Dès que vous voulez du SSO, des ACL ou de la découverte automatique des peers, vous reconstruisez ce que les trois autres sont déjà.

Tailscale

Point fort : la meilleure expérience de la catégorie. Les clients sont excellents sur toutes les plateformes, le NAT traversal « fonctionne tout simplement » via DERP, le SSO et les ACL sont de premier ordre, et il n'y a aucun control plane à exploiter. Si votre objectif est un mesh opérationnel dès cet après-midi et que vous ne voulez pas exploiter d'infrastructure, c'est le chemin le plus court.

Limite la plus nette : le serveur de coordination est à source fermée et hébergé par Tailscale, et la tarification se fait par utilisateur : une offre Personal gratuite (6 utilisateurs, appareils illimités en juillet 2026), puis Standard à $8/user/month et Premium à $18/user/month. Pour une équipe d'infrastructure, cela ne pose pas de problème ; pour une flotte importante ou sensible aux coûts, le modèle par siège et le control plane fermé sont les deux éléments qui poussent les gens vers Headscale ou NetBird.

Headscale

Point fort : l'expérience client de Tailscale avec un control plane qui vous appartient. Vous faites tourner un unique serveur open source (actuellement v0.29.x, en juillet 2026) et vous y pointez les clients officiels de Tailscale, de sorte que vous gardez les applications abouties pendant que la coordination, les clés et les ACL vivent sur votre propre matériel, sans facture par siège. La prise en charge des ACL (le moteur policy v2) et un relais DERP intégré sont disponibles.

Limite la plus nette : c'est un projet communautaire limité à un tailnet unique, délibérément pas le produit multi-tenant à console d'entreprise que vend Tailscale. Il n'y a pas de GUI d'administration officielle (les interfaces viennent de tiers), et le projet indique explicitement qu'il ne prend pas en charge l'exécution derrière des reverse proxys ou dans des conteneurs, même si des gens le font quand même. Il convient parfaitement à une équipe ou une organisation ; il n'essaie pas d'être une plateforme managée.

NetBird

Point fort : l'option auto-hébergée la plus ouverte et la plus complète en fonctionnalités. Le client et le control plane sont tous deux open source et entièrement auto-hébergeables, la solution embarque identity/SSO (un IdP intégré dans la stack auto-hébergée par défaut, plus OIDC vers Keycloak/Authentik/Entra/Okta), des politiques d'accès basées sur des groupes, et elle utilise WireGuard noyau sous Linux pour le chemin de données le plus rapide. Les versions récentes ont même ajouté un reverse proxy intégré pour exposer des services internes sans ouvrir de ports (bêta). Si l'objectif est « tout auto-héberger, avec l'identity intégrée », NetBird est la réponse la plus complète.

Limite la plus nette : c'est le plus jeune et le plus lourd à faire tourner : services management, signal et relais plus un IdP, contre un unique binaire pour Headscale. Le projet avance vite (v0.74.x en juillet 2026, avec des versions fréquentes et certaines fonctionnalités encore en bêta), ce qui est excellent pour les fonctionnalités mais signifie aussi que vous suivez une cible qui bouge plus vite. Prévoyez plus de temps pour la mise en place et les mises à jour qu'avec Tailscale ou Headscale.

L'angle opérateur que les résultats de recherche des éditeurs ignorent

La moitié des résultats de recherche sur ce sujet sont écrits par NetBird lui-même (leur propre knowledge hub) ou par un partenaire éditeur, et aucun d'entre eux ne couvre le cas qui compte pour un opérateur d'infrastructure : utiliser un mesh pour atteindre en toute sécurité les réseaux de management et hors bande.

Le modèle consiste en un mesh basé sur WireGuard avec routage de sous-réseau : un relais/nœud de sortie situé à l'intérieur d'un réseau protégé annonce des routes vers celui-ci, de sorte que les membres autorisés du mesh peuvent atteindre un VLAN IPMI/BMC, un segment de management OOB, ou un réseau de services internes, sans en exposer quoi que ce soit à l'internet public. Bien mis en œuvre, cela remplace le modèle du « serveur rebond sur IP publique » par un overlay dont l'accès est conditionné à l'identité : l'accès est lié au SSO et révoqué de façon centralisée, la management plane n'a jamais de listener public, et chaque saut est chiffré en WireGuard de bout en bout. Tailscale, Headscale et NetBird prennent tous en charge le routage de sous-réseau ; le choix entre eux relève de la même question de propriété du control plane que partout ailleurs, avec ce poids supplémentaire que, spécifiquement pour l'accès à l'infrastructure, de nombreux opérateurs veulent le serveur de coordination sur leur propre matériel (Headscale ou NetBird auto-hébergé) plutôt que sur celui d'un tiers.

Le conseil pratique pour ce cas d'usage : n'annoncez que le sous-réseau de management précis dont vous avez besoin plutôt qu'une route large, protégez-le derrière une ACL liée au plus petit groupe possible, et gardez le routeur de sous-réseau lui-même patché et surveillé ; il vient de devenir un pont vers votre réseau le plus sensible, et mérite donc la même vigilance qu'un serveur bastion.

Verdict, avec conditions

• Choisissez Tailscale si vous voulez la charge opérationnelle la plus faible et les meilleurs clients, qu'une control plane fermée et hébergée ne vous pose pas de problème, et que la tarification par utilisateur correspond à la taille de votre équipe. C'est le bon choix par défaut pour les équipes zero-ops.
• Choisissez Headscale si vous adorez l'expérience Tailscale mais avez besoin du serveur de coordination sur votre propre matériel : une équipe ou une organisation, un tailnet unique, aucune facture par siège. La réponse la plus nette pour « l'UX de Tailscale, avec un contrôle auto-hébergé ».
• Choisissez NetBird si vous voulez tout ouvert et auto-hébergé, avec identity/SSO et politique d'accès intégrés, et que vous pouvez faire tourner quelques services supplémentaires pour l'obtenir. Le meilleur choix pour un mesh zero-trust entièrement maîtrisé.
• Choisissez WireGuard brut si votre topologie est petite et statique, que vous voulez le chemin le plus dépouillé, le plus rapide et le plus auditable, et que gérer vous-même les clés et la configuration ne vous dérange pas.

Pour un opérateur d'infrastructure en particulier, le critère décisif est généralement la propriété du control plane pour l'accès au réseau de management : cela penche vers Headscale ou NetBird auto-hébergé plutôt que vers l'option SaaS, même quand Tailscale serait le choix le plus simple dès le premier jour.

Questions fréquentes

Tailscale est-il simplement du WireGuard ?

Non. Tailscale utilise le protocole WireGuard pour sa data plane, mais y ajoute tout un control plane : un serveur de coordination pour la distribution des clés et la découverte des peers, des relais DERP pour le NAT traversal, le SSO et les ACL. Et son client utilise une implémentation userspace de WireGuard (wireguard-go) plutôt que le module noyau. Tailscale, c'est donc WireGuard plus tout ce que WireGuard laisse volontairement de côté.

Headscale est-il prêt pour la production ?

Pour le périmètre auquel il est destiné, oui : un tailnet unique pour une équipe ou une organisation, géré par des personnes à l'aise avec l'exploitation d'un serveur open source. Il prend en charge les ACL et un relais DERP intégré, et fonctionne avec les clients Tailscale officiels. Ce qu'il n'est pas : une plateforme d'entreprise multi-tenant gérée par GUI ; c'est le produit payant de Tailscale. Réservez Headscale à un déploiement au sein d'une seule organisation et il tient parfaitement la route ; attendez-vous à le piloter en CLI/API et à fournir votre propre OIDC.

NetBird peut-il être entièrement auto-hébergé ?

Oui. C'est sa caractéristique déterminante. Les clients comme le control plane (les services management, signal et relais) sont open source et auto-hébergeables, et la stack d'auto-hébergement par défaut inclut un fournisseur d'identité intégré, si bien que vous pouvez faire tourner tout le mesh (SSO compris) sur votre propre infrastructure, sans dépendre du cloud d'un éditeur.

Lequel est le plus rapide ?

Sur une configuration par défaut, WireGuard noyau brut (et le mode noyau de NetBird sous Linux) a un léger avantage sur les implémentations userspace comme celle de Tailscale, car il évite les passages user/kernel à chaque paquet ; les propres benchmarks de Tailscale situent WireGuard noyau à 2.66 Gbit/s contre 2.42 pour wireguard-go non optimisé. Mais la MTU et le fait qu'une connexion soit directe ou relayée font bien plus varier le débit que le choix du produit, et pour un trafic typique sous le gigabit, la différence est imperceptible. Choisissez en fonction de l'exploitation et des fonctionnalités, pas d'un benchmark, sauf si vous saturez des liaisons rapides.

Où faire tourner le control plane, le relais ou le nœud de sortie

Chaque option ici, à l'exception du Tailscale SaaS pur, a besoin d'un hôte : le serveur de coordination de Headscale, la stack management/signal/relais de NetBird, un nœud DERP auto-hébergé, ou un exit/subnet-router WireGuard veulent tous une petite machine always-on à faible latence avec une IP publique stable. C'est un choix naturel pour un VPS sur notre cloud, suffisant pour un control plane et un relais, sur le même réseau ASN 55285 avec une mitigation DDoS permanente devant le listener public. Si vous routez vers une infrastructure plus lourde ou faites tourner des nœuds de sortie à pleine vitesse de ligne, un serveur dédié vous donne la bande passante non partagée et le contrôle au niveau noyau dont WireGuard tire parti.

Vous construisez déjà directement avec WireGuard ? Nos guides sur un VPN site à site avec WireGuard sur VyOS et sur une dorsale routeur et VPN flexible sur VyOS couvrent l'extrémité protocole-brut de ce spectre, et notre guide des distributions Linux couvre l'OS à faire tourner en dessous, quel que soit votre choix.