Tailscale vs WireGuard est une question un peu mal posée, parce que Tailscale, c'est WireGuard. Même crypto, même data plane, même module noyau qui fait le chiffrement. Ce que Tailscale ajoute, c'est la partie que WireGuard a volontairement laissée de côté : un control plane qui distribue les clés, perce le NAT, fait tourner MagicDNS, applique les ACL et branche le tout sur ton SSO. Le vrai choix n'est donc pas WireGuard contre Tailscale, c'est veux-tu câbler le mesh toi-même ou laisser un service de coordination le faire, et un control plane hébergé qui voit tes métadonnées te convient-il ou héberges-tu cette partie aussi avec Headscale.
The short answer
Tailscale, c'est WireGuard plus un control plane. Tes paquets passent toujours par des tunnels WireGuard bruts, mais Tailscale distribue les clés, traverse le NAT via DERP, fait tourner MagicDNS et applique les ACL branchées sur ton SSO. Choisis donc WireGuard brut pour un petit ensemble statique de machines que tu possèdes, Tailscale pour les appareils nomades et les équipes, ou Headscale quand tu veux l'expérience Tailscale sans confier tes métadonnées de coordination à un SaaS.
J'utilise les deux. WireGuard tourne sur un VPS pour les machines que je veux relier à la main, et Tailscale s'occupe d'un fouillis de portables, téléphones et deux ou trois VM cloud qui bougent trop pour que je passe mon temps à éditer des configs. On me demande tout le temps lequel choisir, et franchement la question est un peu mal posée. Tailscale, c'est WireGuard. Même crypto, même data plane, même module noyau qui fait le chiffrement. Ce que Tailscale ajoute, c'est justement la partie que WireGuard a volontairement laissée de côté : un control plane qui distribue les clés, perce le NAT, fait tourner MagicDNS, applique les ACL et branche le tout sur ton SSO. Donc le vrai choix, ce n'est pas WireGuard contre Tailscale. C'est plutôt « est-ce que je veux câbler le mesh moi-même, ou laisser un service de coordination le faire à ma place », et juste derrière, « est-ce que je suis à l'aise avec un control plane hébergé qui voit mes métadonnées de coordination, ou est-ce que je veux héberger cette partie aussi avec Headscale ». Je te détaille comment ça se passe en vrai.
Ils ne sont pas vraiment concurrents
Commençons par là, parce que la plupart des débats « Tailscale vs WireGuard » sont des gens qui ne parlent pas de la même chose. WireGuard est un protocole de tunnel. Il chiffre les paquets entre deux peers qui connaissent déjà leurs clés publiques et leurs endpoints IP respectifs. C'est tout son boulot. Il ne dit pas aux peers comment se trouver, ne distribue pas de clés, ne gère pas le NAT. C'est voulu. L'auteur l'a gardé volontairement petit, environ 4 000 lignes de code noyau, et a poussé tout le reste vers l'espace utilisateur.
Tailscale a justement ramassé tout ce que WireGuard avait poussé dehors. Sous le capot, ton trafic passe toujours par des tunnels WireGuard bruts. Au-dessus, il y a un serveur de coordination qui sait quels appareils appartiennent à ton réseau, échange leurs clés publiques, les aide à se trouver à travers le NAT et applique tes règles d'accès. Voilà le partage. WireGuard, c'est le moteur. Tailscale, c'est le moteur plus la boîte de vitesses, le tableau de bord et le voiturier qui le gare à ta place. Les comparer frontalement, c'est comme comparer un moteur à une voiture. La question reste utile, parce que tu choisis bel et bien entre « je construis la voiture » et « j'en achète une ».
Le tableau comparatif honnête
Voici comment les deux se comparent sur ce que tu vas vraiment ressentir. Je mets Headscale dans sa propre colonne parce que pour pas mal de lecteurs, c'est la réponse qui l'emporte discrètement : l'expérience Tailscale, ton control plane.
| Ce qui compte pour toi | WireGuard brut | Tailscale (hébergé) | Headscale (auto-hébergé) |
|---|---|---|---|
| Effort de mise en place | Configs manuelles par peer | Installe, connecte-toi, fini | Fais tourner le serveur de contrôle, puis les clients Tailscale |
| Traversée NAT | Tu ouvres le port toi-même | Automatique via DERP | Automatique via DERP |
| Distribution des clés | À la main, comme des clés SSH | Le control plane s'en charge | Ton control plane s'en charge |
| Topologie | Hub-and-spoke (en général) | Full mesh, zéro config | Full mesh, zéro config |
| ACL et SSO | Règles de pare-feu à la main | Intégré, login Google ou GitHub | ACL oui, SSO selon l'install |
| Débit brut | WireGuard noyau, le plus rapide | Souvent en userspace, un peu plus lent | Pareil que les clients Tailscale |
| Qui voit les métadonnées | Personne à part toi | Tailscale voit les données de coordination | Personne à part toi |
| Coût | Juste le VPS | Offre gratuite plafonnée, puis par utilisateur | Gratuit, seulement ton hébergement |
| Idéal pour | Site à site statique que tu possèdes | Appareils nomades, équipes, zéro config | Puriste de l'auto-hébergement qui veut l'UX |
L'effort de mise en place
C'est l'écart qui surprend les gens la première fois. Avec WireGuard brut, tu génères une paire de clés par appareil, tu écris un bloc [Interface] et un bloc [Peer] pour chaque autre machine avec laquelle il parle, et tu dois mettre les bonnes lignes AllowedIPs des deux côtés. Pour trois appareils, c'est vingt minutes. Pour quinze appareils qui se baladent, c'est un mi-temps, et chaque nouveau portable veut dire éditer les configs sur chaque peer qu'il doit joindre. Je l'ai fait. C'est nickel jusqu'au moment où ça ne l'est plus.
Tailscale, c'est un seul binaire et un login. Tu installes le client, tu lances tailscale up, tu t'authentifies avec ton compte Google ou GitHub dans un onglet du navigateur, et la machine apparaît sur ton tailnet avec une adresse 100.x stable. Aucune clé à copier. Aucun port à ouvrir. L'appareil suivant que tu ajoutes peut le joindre tout de suite, parce que le control plane a déjà prévenu les deux côtés. Headscale t'offre la même expérience côté client, le hic étant que tu dois d'abord monter le serveur Headscale toi-même et pointer tes clients dessus plutôt que sur le service de coordination de Tailscale.
La traversée NAT, la fonctionnalité qui change tout
Si je devais nommer la seule chose qui pousse les gens à basculer, c'est celle-là. WireGuard brut a besoin qu'au moins un peer soit joignable à un endpoint fixe et routable. Ça veut souvent dire un VPS avec une IP publique, ou ouvrir un port UDP sur ta box maison en croisant les doigts pour que ton FAI ne te coince pas derrière du carrier-grade NAT. Quand les deux extrémités sont derrière du NAT, WireGuard brut ne peut tout simplement pas les connecter tout seul.
Tailscale fait quasiment disparaître ce problème. Son service de coordination aide les deux peers à découvrir leur adresse et leur port vus de l'extérieur, puis chaque côté envoie des paquets vers l'extérieur en même temps pour que le NAT de chacun voie une réponse qu'il attend. C'est ça le hole punch. Quand une connexion directe est vraiment impossible, le trafic retombe sur un relais DERP, le réseau de serveurs relais conscients de WireGuard chez Tailscale qui font suivre tes paquets déjà chiffrés. DERP ne voit que du chiffré, jamais ton trafic en clair, et dès qu'un chemin direct s'ouvre, ta connexion bascule dessus en silence. Résultat : deux portables sur deux réseaux de cafés hostiles qui se parlent en direct, sans rien ouvrir nulle part. WireGuard brut ne sait pas faire ça. Headscale, si, parce qu'il parle le même protocole et peut utiliser les relais DERP lui aussi.
Gestion des clés et forme du mesh
Avec WireGuard, les clés sont ton boulot. Tu les traites comme des clés SSH : tu génères une paire par peer, tu n'en réutilises jamais une sur deux machines (ça casse le handshake de façon déroutante), tu transmets la moitié publique par un canal de confiance. Pour une poignée de machines, c'est propre et auditable. J'aime bien ça pour une install statique, d'ailleurs. Il n'y a personne dans la boucle, et je sais exactement ce qui est où.
La forme compte aussi. Les configs WireGuard brutes finissent presque toujours en hub-and-spoke, parce qu'un vrai full mesh veut dire que chaque peer détient la clé de tous les autres et un bloc de config qui correspond. Le calcul devient vite moche, en gros n au carré blocs à maintenir. Tailscale et Headscale te donnent un full mesh gratuitement : chaque nœud peut joindre tous les autres en direct, et le control plane garde toutes les clés synchronisées au fil des appareils qui arrivent et repartent. Tu ajoutes un téléphone, il parle à tout, et tu n'as rien édité.
ACL, SSO et exit nodes
WireGuard brut n'a aucune notion d'identité au-delà d'une clé publique, et aucune règle d'accès au-delà de ce que tu construis avec AllowedIPs et le pare-feu de l'hôte. Tu veux « les prestataires peuvent joindre la machine de staging mais pas la prod » ? Tu vas écrire de l'iptables. Ça marche, c'est juste manuel, et ça dérive.
Tailscale livre une vraie politique de contrôle d'accès que tu édites comme un seul fichier, exprimée en termes d'utilisateurs et de tags, branchée sur ton SSO pour que l'identité vienne de Google Workspace, GitHub ou ce que tu fais déjà tourner. Les exit nodes sont un bonus sympa : marque un appareil comme exit node et les autres peuvent router tout leur trafic Internet à travers lui, ce qui est le classique du VPN full-tunnel, sauf que tu n'as rien configuré côté client à part le choisir dans un menu. Headscale gère les ACL dans le même format de politique et gère les exit nodes aussi. Le SSO sur Headscale tient plutôt du « ça dépend comment tu l'as câblé », vu que c'est toi qui fournis le backend d'identité.
Performances
WireGuard noyau brut est le champion du débit, et ce n'est même pas serré sur le papier. Le chemin de données vit dans le noyau, ChaCha20-Poly1305 coûte peu, et un seul cœur sature un lien gigabit sans transpirer. Tailscale utilise WireGuard aussi, mais historiquement son client faisait tourner la crypto en espace utilisateur (wireguard-go), ce qui te coûte un peu de débit et un peu plus de CPU par rapport au chemin in-kernel. Sur un lien rapide, tu peux mesurer la différence.
Est-ce que tu la ressens ? Pour la plupart des gens, franchement non. Si ton goulot d'étranglement est une montée à 200 Mbps chez toi, les deux la saturent. L'écart apparaît quand tu déplaces du gros trafic sur un chemin à 1 Gbps et plus et que tu comptes chaque pourcent. Et Tailscale a réduit l'écart, en s'appuyant sur WireGuard noyau là où la plateforme le permet. Donc : WireGuard brut gagne le benchmark, Tailscale gagne le « je n'ai pas eu à y penser », et sur une connexion normale tu ne remarqueras pas lequel tu utilises.
Vie privée, confiance et Headscale
C'est la partie qui mérite qu'on ralentisse. Ton trafic est chiffré de bout en bout dans tous les cas. Les serveurs de Tailscale ne voient pas ton trafic en clair, point, et les relais DERP ne touchent jamais que du chiffré. Mais le control plane hébergé voit bien des métadonnées de coordination : quels appareils sont dans ton tailnet, leurs clés publiques, leurs endpoints, à peu près quand ils se connectent. Pour la plupart des gens, c'est un compromis acceptable pour ne plus jamais penser au NAT. Pour certains, qu'un tiers détienne cette carte est exactement ce qu'ils cherchent à éviter.
C'est là que Headscale entre en jeu. C'est une implémentation open-source et auto-hébergée du serveur de contrôle Tailscale. Tu le fais tourner sur ta propre machine, tu pointes les clients Tailscale normaux dessus, et tu obtiens le mesh, la traversée NAT, le nommage type MagicDNS, les ACL, sans le SaaS Tailscale dans la boucle et sans aucune métadonnée de coordination qui sort de chez toi. Le prix à payer, c'est que tu exploites maintenant le control plane : un service de plus à garder en vie, patcher et sauvegarder. Pour le puriste de l'auto-hébergement qui veut l'expérience Tailscale sans la dépendance, c'est la réponse. Si tu héberges déjà des trucs comme un gestionnaire de mots de passe, tu es déjà dans cet état d'esprit, vois notre guide d'auto-hébergement de Vaultwarden pour le même compromis sous une autre forme.
Une réserve honnête sur Headscale. Il suit le protocole Tailscale mais c'est un projet à part, donc il peut prendre du retard sur les nouvelles fonctionnalités client, et quelques petits plus de Tailscale n'y sont pas ou marchent différemment. Lis sa doc avant d'y engager toute une flotte.
Quand chacun l'emporte
Voici où j'atterris après avoir fait tourner les deux un bon moment.
- WireGuard brut quand tu as un petit ensemble de machines statiques que tu contrôles, idéalement avec au moins une sur une IP publique, et que tu veux zéro tiers et un débit maximal. Du site à site entre deux bureaux que tu possèdes ? Un VPS plus trois machines maison ? C'est la réponse propre. Notre guide WireGuard auto-hébergé déroule tout le build.
- Tailscale quand tu as beaucoup d'appareils nomades, une équipe qui a besoin de SSO et d'ACL, ou quoi que ce soit derrière du CGNAT où l'ouverture de port n'est même pas envisageable. Le mesh zéro config et la traversée NAT automatique valent de l'argent réel en temps gagné. Si l'offre gratuite te couvre (et pour un solo ou une petite équipe, c'est souvent le cas), difficile de discuter.
- Headscale quand tu veux tout ce que Tailscale offre mais que tu refuses de confier tes métadonnées de coordination à un SaaS. Tu échanges un peu de travail d'exploitation contre la pleine propriété. Le choix du puriste, et un bon choix si tu as déjà l'habitude de l'auto-hébergement.
Je me trompe peut-être pour ton cas précis, mais la ligne de partage qui a tenu pour moi, c'est le nomadisme. Si les appareils bougent et se cachent derrière du NAT, tu veux un control plane, hébergé ou auto-hébergé. S'ils restent immobiles sur des IP que tu possèdes, WireGuard brut a moins de pièces à casser.
Sources et pour aller plus loin
- Tailscale, comment ça marche (architecture et control plane)
- Tailscale, relais DERP et traversée NAT
- WireGuard, site officiel
- Headscale, serveur de contrôle Tailscale open-source
Questions fréquentes
Tailscale, c'est juste WireGuard avec des étapes en plus ?
C'est WireGuard avec les étapes manquantes remplies, ce qui est l'inverse d'« en plus ». Tailscale fait tourner du WireGuard brut pour les vrais tunnels de données, puis ajoute les parties que WireGuard a laissées de côté exprès : distribution des clés, traversée NAT via DERP, MagicDNS, ACL et login SSO. Donc tu ne paies pas une taxe de performance pour un autre protocole. Tu paies un petit coût de débit (crypto userspace sur certaines plateformes) en échange de ne jamais câbler le mesh à la main.
Est-ce que Tailscale voit mon trafic ?
Non, pas le contenu. Ton trafic est chiffré de bout en bout avec WireGuard, et les serveurs de Tailscale ne détiennent jamais les clés pour le déchiffrer. Même les relais DERP ne font jamais que faire suivre du chiffré. Ce que le control plane hébergé voit, ce sont des métadonnées de coordination : quels appareils sont sur ton réseau, leurs clés publiques, leurs endpoints, quand ils se connectent. Si cette carte te dérange, auto-héberge le control plane avec Headscale et elle ne quitte jamais tes mains.
C'est quoi Headscale et pourquoi je l'utiliserais ?
Headscale est une version open-source et auto-hébergée du serveur de coordination de Tailscale. Tu le fais tourner toi-même, tu pointes les clients Tailscale standards dessus, et tu obtiens le même mesh, la même traversée NAT et les mêmes ACL sans le SaaS de Tailscale dans la boucle. Les gens l'utilisent pour garder leurs métadonnées de coordination totalement privées, ou juste pour éviter de dépendre d'un service hébergé. Le compromis, c'est que tu exploites maintenant ce control plane, une chose de plus à patcher et sauvegarder, et il peut prendre du retard sur les nouvelles fonctionnalités de Tailscale.
Lequel est le plus rapide, Tailscale ou WireGuard brut ?
WireGuard brut, sur le papier. Son chemin de données tourne dans le noyau, et un seul cœur remplit un lien gigabit. Tailscale fait souvent tourner la crypto en espace utilisateur, ce qui coûte du débit et du CPU sur un lien rapide. En pratique, sur une connexion maison ou bureau normale, les deux saturent ta montée et tu ne sentiras pas la différence. L'écart n'apparaît que quand tu pousses à 1 Gbps et plus et que tu comptes chaque pourcent.
Puis-je éviter l'ouverture de port avec WireGuard brut ?
Seulement en partie. Un client WireGuard derrière du NAT peut joindre un serveur qui a un endpoint public et routable, parce que le client ouvre la session en sortant. Le problème, c'est quand les deux extrémités sont derrière du NAT, surtout du carrier-grade NAT, où aucune ne peut être appelée directement. WireGuard brut n'a pas de hole-punching à lui, donc tu es coincé. C'est exactement ce cas où Tailscale ou Headscale gagnent leur croûte, puisque leur control plane traverse le NAT et retombe sur un relais quand il le faut.