Lien d'affiliation - Cet article contient un lien d'affiliation Contabo. Si vous commandez un VPS via ce lien, nous touchons une commission sans surcoût pour vous. Les faits sur Headscale et WireGuard ci-dessous ont été lus dans la documentation officielle de chaque projet le 8 octobre 2026.
Réponse rapide : « Headscale ou WireGuard » n'est pas un choix entre deux protocoles VPN. WireGuard est le tunnel. Headscale est un serveur de contrôle qui indique aux clients Tailscale quelles clés WireGuard, quelles adresses et quelles routes utiliser, pour que vous n'ayez pas à les écrire à la main. Prenez WireGuard seul si vous avez un serveur et une poignée d'appareils qui doivent seulement joindre ce serveur. Prenez Headscale si vous voulez que de nombreux appareils se joignent entre eux, à travers le NAT, avec des noms, des règles d'accès et aucun fichier de configuration à modifier sur chaque machine.
Deux couches, pas deux rivaux
Le projet WireGuard résume son rôle en une phrase : il encapsule de façon sûre des paquets IP dans de l'UDP. Vous ajoutez une interface, vous lui donnez votre clé privée et les clés publiques de vos pairs, et les paquets circulent. La même page est tout aussi nette sur ce qu'elle laisse de côté : toutes les questions de distribution des clés et de configuration poussée sont hors du périmètre de WireGuard ("out of scope", dans le texte).
Cette couche manquante est précisément ce que fournit Headscale. Son README le définit comme une implémentation open source et auto-hébergée du serveur de contrôle de Tailscale, et décrit ce serveur comme le point d'échange des clés publiques WireGuard entre les nœuds du réseau : il attribue les adresses IP des clients et expose les routes qu'ils annoncent.
La vraie comparaison est donc celle-ci :
- WireGuard seul : le plan de contrôle, c'est vous. Vous générez les clés, choisissez les adresses, écrivez chaque bloc
[Peer]et le recopiez aux deux extrémités. - Headscale : le plan de contrôle est un service que vous hébergez. Les appareils font tourner le client Tailscale, se connectent à votre serveur et reçoivent leurs pairs automatiquement.
Dans les deux cas, le trafic entre vos machines est chiffré avec le protocole WireGuard.
Ce que WireGuard seul vous demande
Un réseau WireGuard se définit par des fichiers de configuration. Chaque pair est une clé publique associée aux adresses de tunnel qu'il a le droit d'utiliser, ce que le projet appelle le Cryptokey Routing :
[Interface]
PrivateKey = <server-private-key>
Address = 10.8.0.1/24
ListenPort = 51820
[Peer]
PublicKey = <laptop-public-key>
AllowedIPs = 10.8.0.2/32
Pour un serveur central et quelques clients, c'est court et lisible, et rien d'autre ne tourne que l'interface elle-même. Notre guide WireGuard sur Contabo décrit cette installation de bout en bout, et wg-easy y ajoute une interface web sans changer le modèle.
Le coût apparaît quand le réseau grandit dans une direction précise :
- Chaque appareil ajouté oblige à modifier au moins deux fichiers. Le nouveau pair doit connaître le serveur, le serveur doit connaître le nouveau pair.
- Un maillage complet multiplie ce travail. Si 10 appareils doivent chacun joindre directement les 9 autres, cela fait 45 paires à décrire, des deux côtés.
- Quelqu'un doit être joignable. Un tunnel s'établit vers un point de terminaison, une adresse IP et un port UDP. Deux appareils placés tous les deux derrière un NAT n'ont pas ce point de terminaison l'un pour l'autre : c'est la situation décrite dans notre guide WireGuard derrière un CGNAT. La réponse habituelle consiste à tout faire passer par le serveur.
- Les noms et les règles d'accès restent à construire. WireGuard vous donne des adresses. Le DNS et le filtrage entre pairs sont un travail à part.
Rien de tout cela n'est un défaut. C'est le périmètre que le projet a choisi, et pour un serveur unique c'est un avantage : moins de pièces mobiles, un seul port UDP.
Ce que Headscale ajoute
Avec Headscale, le travail par appareil se réduit à une commande. Sur le serveur, vous créez un utilisateur et une clé pré-authentifiée :
headscale users create <USER>
headscale preauthkeys create --user <USER_ID>
puis, sur chaque appareil où le client Tailscale est installé :
tailscale up --login-server <YOUR_HEADSCALE_URL> --authkey <YOUR_AUTH_KEY>
L'appareil reçoit alors son adresse et ses pairs depuis votre serveur. La liste des fonctionnalités de la documentation de Headscale comprend notamment :
- MagicDNS et le split DNS, pour que les machines aient des noms plutôt que des adresses.
- Des ACL dans un fichier de politique central, au lieu de règles de pare-feu sur chaque hôte.
- Les routeurs de sous-réseau et les nœuds de sortie, pour atteindre un LAN entier ou faire sortir tout le trafic par un nœud.
- Un serveur DERP embarqué. La documentation décrit DERP comme un relais utilisé surtout quand une connexion directe entre deux nœuds ne peut pas être établie. Il est désactivé par défaut.
- L'enregistrement par OpenID Connect, en plus des clés pré-authentifiées.
Ce que la documentation de Headscale dit qu'il n'est pas
C'est la partie que les comparatifs passent souvent sous silence, et le projet l'écrit lui-même sans détour.
- Périmètre. Le README indique que Headscale couvre un périmètre étroit : un seul réseau Tailscale (tailnet), adapté à un usage personnel ou à une petite organisation open source.
- Échelle. La FAQ précise que Headscale n'est pas un logiciel d'entreprise ("not enterprise software") et que la performance n'est pas une priorité. Elle estime que le serveur peut vraisemblablement gérer des centaines d'appareils quand le réseau change peu.
- Fonctions absentes. Funnel, Serve et les journaux de flux réseau ne sont pas cochés dans la liste des fonctionnalités.
- Déploiement. Le README indique que les mainteneurs ne prennent pas en charge et n'encouragent pas l'usage de reverse proxies ni de conteneurs pour faire tourner Headscale. Le support officiel porte sur les binaires et les paquets DEB. Des images de conteneur sont construites par commodité.
- Clients. Les appareils utilisent le client Tailscale. Le projet vise la compatibilité avec ses 10 dernières versions, sous Linux, OpenBSD, FreeBSD, Windows, Android, macOS, iOS et tvOS.
- Base de données. SQLite est recommandé. PostgreSQL reste pris en charge mais décrit comme étant en "maintenance mode".
Headscale est publié sous licence BSD-3-Clause. La dernière version sur GitHub à la date de rédaction de cette page est la v0.29.4, publiée le 23 septembre 2026.
Ce que chacun exige côté serveur
| WireGuard seul | Headscale | |
|---|---|---|
| Rôle | Tunnel entre des pairs que vous configurez | Serveur de contrôle pour clients Tailscale |
| Processus serveur | Une interface réseau, pas de démon | Un service avec une base de données (SQLite recommandé) |
| Ports publics | Un port UDP de votre choix | TCP 443 (HTTPS) ; UDP 3478 si le DERP embarqué est activé ; TCP 80 seulement si le client Let's Encrypt intégré utilise le défi HTTP-01 |
| Domaine et TLS | Inutiles | HTTPS sur le port 443 fortement recommandé par la documentation |
| Logiciel client | WireGuard sur chaque appareil | Client Tailscale sur chaque appareil |
| Ajouter un appareil | Modifier la configuration aux deux extrémités | Une commande tailscale up |
| D'appareil à appareil à travers le NAT | Par votre serveur, sauf si l'un des deux a un point de terminaison joignable | En direct quand c'est possible, relayé par DERP sinon |
| Noms et règles d'accès | À construire à part | MagicDNS et ACL inclus |
Sources : wireguard.com, le README de Headscale et la documentation de Headscale (prérequis, fonctionnalités, FAQ, DERP), lus le 8 octobre 2026.
Les deux reposent sur la même base : une petite machine Linux avec une adresse IP publique, qui reste en ligne. Aucun des deux projets ne publie de minimum de RAM ou de CPU sur les pages citées ici, et un VPS d'entrée de gamme est l'hébergement habituel de l'un comme de l'autre.
Voir les offres Contabo Cloud VPS actuelles
Lequel faire tourner ?
| Votre situation | Choix |
|---|---|
| Un VPS, quelques appareils, tout le trafic passe par le serveur | WireGuard |
| Vous voulez le moins de pièces mobiles possible et un seul port UDP | WireGuard |
| Un routeur ou un boîtier qui ne propose qu'un client WireGuard | WireGuard |
| Des portables, téléphones et serveurs qui doivent se joindre directement | Headscale |
| Plusieurs appareils derrière un NAT ou un CGNAT des deux côtés | Headscale |
| Vous ajoutez et retirez souvent des appareils | Headscale |
| Vous voulez des noms et des règles d'accès centralisées | Headscale |
| Des centaines d'appareils qui changent souvent, ou un besoin de support éditeur | Ni l'un ni l'autre : regardez le service Tailscale hébergé |
Si la dernière ligne ressemble à votre cas, Tailscale ou Headscale compare le service hébergé et le serveur auto-hébergé, et Tailscale ou WireGuard auto-hébergé traite la même question du côté de WireGuard.
Peut-on faire tourner les deux ?
Oui, et c'est un montage raisonnable. Une interface WireGuard classique sur son propre port UDP et un service Headscale sur le port TCP 443 ne se disputent pas le même port. Une répartition courante : un tunnel WireGuard pour un lien fixe, comme la liaison site à site entre deux réseaux, et Headscale pour les appareils personnels qui se déplacent. Le prix à payer, ce sont deux systèmes à tenir à jour : ne le faites que si chacun résout un problème que l'autre ne résout pas.
En résumé
WireGuard est un protocole et vous laisse la distribution des clés. Headscale est une façon d'assurer vous-même cette distribution, avec le client Tailscale, sur un serveur que vous contrôlez. Commencez par WireGuard seul quand un serveur central suffit. Passez à Headscale quand les fichiers de configuration deviennent l'essentiel de ce que vous entretenez, et lisez d'abord sa documentation : elle dit clairement qu'il est conçu pour des réseaux personnels et de petits groupes. L'installation pas à pas se trouve dans notre guide du plan de contrôle Headscale.
★ Datacenter Nuremberg GDPR · ✓ IPv4 dédiée incluse · port 200 Mbit/s
Héberge ton VPN sur ton propre VPS → ContaboAccès root complet · IPv4 publique · choisis ta région→
