La comparaison revient sans cesse et elle est subtilement mal posée, ce qui explique pourquoi les réponses trouvées laissent sur sa faim. WireGuard est un protocole : un moyen de transporter des paquets chiffrés entre deux machines qui se connaissent déjà. Nebula est un réseau : identité, découverte, politique et transport livrés ensemble. Demander lequel est le meilleur, c'est presque demander si un rail vaut mieux qu'un chemin de fer.
La question utile est celle qui se cache dessous : voulez-vous maintenir la configuration des pairs à la main à mesure que le parc grandit, ou déléguer ce travail à un système ?
Dans les deux cas, une machine a besoin d'une IP publique joignable par chaque nœud : le lighthouse Nebula ou le hub WireGuard. Un Contabo Cloud VPS 4 à 5,50 €/mois (lien affilié) tient ce rôle avec sa propre IPv4, et notre générateur de configuration WireGuard gratuit écrit les configurations du hub et des pairs si vous restez sur WireGuard seul. Si vous préférez un hébergeur américain avec une garantie de remboursement de 30 jours, Ultahost VPS Basic coûte 5,52 $ par mois sur un engagement de 24 mois (1 Go de RAM, IPv4 dédiée, relevé le 21 octobre 2026), assez pour un serveur WireGuard pour quelques appareils. Le générateur est gratuit jusqu'à 10 appareils ; au-delà, WireGuard Pro (notre propre produit, 9 EUR une fois, sans abonnement) porte la limite à 250 et ajoute un ZIP contenant chaque .conf client et son QR code en PNG, pratique pour équiper tout un bureau ou toute une famille d'un coup.
Ce que chacun vous apporte réellement
WireGuard vous donne un tunnel et s'arrête là. Vous générez une paire de clés par machine, vous listez la clé publique de chaque pair et ses AllowedIPs, et c'est tout le modèle. Pas de découverte, pas de notion de groupe, pas de langage de politique. Ce minimalisme est délibéré et c'est ce qui rend WireGuard auditable : environ 4 000 lignes de code noyau et une suite cryptographique moderne fixe, sans négociation à rater.
Nebula vous donne une autorité de certification que vous gérez vous-même. Chaque hôte détient un certificat portant son identité et ses groupes, laptop, db, ci, signé par votre CA. Des nœuds lighthouse savent qui se trouve où, pour que les pairs puissent se trouver. Et chaque hôte embarque un pare-feu dans sa propre configuration, écrit en termes de ces groupes plutôt que d'adresses IP.
La courbe qui tranche
C'est la partie à bien assimiler, car c'est la vraie raison des migrations, et elle n'a rien à voir avec la vitesse.
Un maillage WireGuard complet exige une entrée de pair sur chaque machine pour chacune des autres. La configuration croît donc avec le carré du parc :
| Machines | Paires de pairs à maintenir |
|---|---|
| 3 | 3 |
| 5 | 10 |
| 10 | 45 |
| 20 | 190 |
Ajouter une machine à un maillage de 20 nœuds oblige à modifier vingt configurations existantes. Rien de techniquement difficile ; c'est simplement le genre de travail que les humains finissent par mal faire au bout d'un moment. Nebula, Tailscale et Headscale existent tous pour supprimer cette matrice, ils diffèrent dans le comment, pas dans le pourquoi.
Si vous utilisez plutôt une topologie en hub, où tout le monde se connecte à un seul serveur, WireGuard seul reste gérable indéfiniment. Le carré ne mord que sur un maillage complet.
Quand WireGuard seul est la bonne réponse
- Peu de machines, composition stable. Trois portables et un VPS, c'est un travail pour WireGuard, et sortir un overlay serait une surcharge sans contrepartie.
- Vous voulez la plus petite surface d'attaque possible. Rien d'autre dans ce domaine ne tient en 4 000 lignes.
- La vitesse noyau compte et vos hôtes sont sous Linux. Les transports en espace utilisateur paient un changement de contexte par paquet ; sur un lien 10 Gb saturé, cela se voit.
- Des liaisons site à site qui ne changent jamais. Deux routeurs, un tunnel, aucun problème de découverte à résoudre.
Quand Nebula justifie ses pièces en plus
- La composition change souvent. Les machines arrivent et partent sans que personne ne modifie les pairs.
- Vous avez besoin de politique, pas seulement de connectivité. « Seuls les hôtes de
cipeuvent joindre le port 5432 des hôtes dedb» tient en une ligne de configuration Nebula, et demande une brique d'infrastructure séparée avec WireGuard seul. - Vous voulez que l'application des règles survive à un plan de contrôle compromis. Le pare-feu de Nebula vit sur chaque hôte, donc rien de central ne peut ouvrir un port en silence.
- Des réseaux hétérogènes et capricieux. Les lighthouses gèrent la traversée de NAT que vous auriez sinon à résoudre liaison par liaison.
Un VPN change votre IP. Il ne change pas votre navigateur.
Un tunnel remplace l'adresse que voit un service. Il ne change rien à ce que votre navigateur annonce de lui-même (polices, écran, fuseau horaire, pile graphique), et cette combinaison est souvent assez stable pour vous reconnaître d'une session à l'autre, avec ou sans tunnel.
Mesurez l'empreinte de votre navigateur : passif, sans questions, sans compte, sans e-mail.
Le résumé honnête
WireGuard seul n'est pas un Nebula au rabais ; c'est un outil plus petit qui en fait moins volontairement, et le fait très bien. Choisissez-le tant que votre parc est petit ou que votre topologie est un hub. Choisissez Nebula quand la matrice des pairs devient une corvée, ou quand vous avez besoin d'identité et de politique plutôt que de simples tunnels, et acceptez en échange de gérer désormais une autorité de certification.
Si vous voulez le maillage sans avoir à exploiter une CA, la troisième voie est un maillage basé sur WireGuard avec un serveur de coordination : c'est ce que Headscale fait avec le problème de Nebula et le plan de données de WireGuard.
★ 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→
