Five Mesh VPN Solutions for SMBs: Comparison and Practical Guide

Introduction 

Avec la généralisation du télétravail et l’externalisation croissante des services, les PME font face à de nouveaux défis en matière de cybersécurité et de gestion des accès. Les employés doivent pouvoir se connecter aux ressources de l’entreprise depuis n’importe où, tout en garantissant la sécurité des systèmes critiques. Or, multiplier les accès directs ou les VPN traditionnels de façon désorganisée peut créer une access fragmentation : each service has its own portal, its own credentials, or even its own VPN, making management complex and increasing the risk of security gaps. It is therefore crucial to streamline these connections within a unified and secure framework.

A virtual private network of the mesh type, also called an overlay network, répond à ces défis en connectant entre eux tous les appareils autorisés de l’entreprise au sein d’un réseau chiffré et privé, par-dessus Internet. Contrairement aux VPN classiques en hub-and-spoke VPNs (with a central server to which all clients connect), a mesh VPN enables direct peer-to-peer entre postes. Concrètement, cela signifie que les ordinateurs, serveurs et appareils distants de l’entreprise peuvent communiquer entre eux comme s’ils étaient sur le même réseau local, où qu’ils se trouvent physiquement. Résultat : un accès plus fluide aux outils internes, moins de dépendance à un point central (meilleures performances, pas de bottleneck unique) et une administration centralisée des règles de sécurité.

Moreover, these private networks facilitate the implementation of the principle of least privilege et d’une approche « Zero Trust » adaptée aux PME. On ne fait plus aveuglément confiance à tout appareil présent sur le réseau : chaque connexion à une ressource sensible peut être restreinte via des ACLs (Access Control Lists ou listes de contrôle d’accès) et des segments de réseau isolés. Même à l’intérieur du VPN, on segmente qui peut accéder à quoi. Cela empêche, par exemple, qu’un employé ou un appareil compromis puisse atteindre des données qui ne le concernent pas. Separating access et définir finement les permissions réduit les risques de mouvement latéral d’un attaquant dans le système d’information.

In this context, it becomes imperative to restreindre l’accès aux services critiques de l’entreprise uniquement via ces connexions privées sécurisées. Plutôt que d’exposer un gestionnaire de mots de passe, une base de données ou un serveur intranet directement sur Internet (même derrière un mot de passe fort), on y accède uniquement quand on est connecté au réseau privé de l’entreprise. Ainsi, un pirate ne pourra même pas atteindre la page de connexion de ces services sans avoir d’abord percé les défenses VPN – ce qui ajoute une couche de protection considérable.

Finally, the Quebec context brings a few additional considerations. The new Bill 25 requires businesses to better protect personal information and to assess risks when data leaves Quebec or Canada.

De plus en plus de PME s’intéressent donc à la digital sovereignty, c’est-à-dire la maîtrise de leurs données et infrastructures. Opter pour des solutions de VPN maillé, notamment des outils open source auto-hébergés, peut aider à garder un meilleur contrôle (par exemple en hébergeant le serveur de coordination du VPN au Canada ou au sein de l’entreprise). À l’inverse, faire appel à un service VPN cloud commercial géré à l’étranger peut soulever des questions de conformité et de confiance. Il s’agit de trouver le bon équilibre entre la simplicity d’utilisation, la security, data control , and cost, based on each SMB's specific circumstances.

Dans cet article, nous allons comparer cinq solutions de réseaux overlay (VPN mesh) adaptées aux PME, en mettant l’accent sur le télétravail sécurisé et la protection des systèmes critiques. Trois de ces solutions sont des outils libres (open source) qu’on peut héberger soi-même : WireGuard, Nebula and ZeroTier (en mode auto-hébergé). Les deux autres sont des solutions commerciales cloud où l’infrastructure est gérée par le fournisseur : Tailscale and ZeroTier Central (service cloud officiel de ZeroTier). Nous expliquerons d’abord de façon accessible l’utilité des VPN maillés et les concepts de sécurité (ACL, segmentation, etc.), puis nous présenterons chaque solution avec ses caractéristiques de fonctionnement, sa facilité de déploiement, le contrôle offert, les coûts et la maturité. Des cas d’usage concrets will illustrate how an SMB can leverage these technologies in everyday operations. Finally, a Recommendations section will help you choose the most suitable solution based on your organization's size, sector, and needs.

Why a mesh VPN for SMBs?

Pour une PME, déployer un VPN maillé présente plusieurs avantages concrets, notamment dans un contexte de télétravail ou de multi-sites :

• Unified and transparent access to internal resources : Avec un réseau overlay, tous les employés et dispositifs autorisés sont reliés comme s’ils étaient sur le même LAN (réseau local). Par exemple, en télétravail, un employé peut accéder au serveur de fichiers au bureau, à l’intranet ou à l’application de gestion interne sans configurations complexes – il se connecte au VPN et voit ces ressources directement, sans passer par des tunnels distincts pour chaque service. Cela simplifie l’expérience utilisateur et accroît la productivité, car on évite les manipulations techniques à chaque utilisation d’un outil de l’entreprise.
• Better performance through peer-to-peer : In a traditional hub-and-spoke, un serveur central gère tout le trafic – ce qui peut créer un goulet d’étranglement, surtout si de nombreux employés se connectent simultanément ou si le serveur a une bande passante limitée. À l’inverse, un VPN maillé permet aux appareils de communiquer directly entre eux dès que possible. Par exemple, si deux collègues en télétravail doivent échanger un gros fichier, leur trafic peut passer directement de l’un à l’autre plutôt que de transiter par le siège de l’entreprise. Le réseau mesh utilise généralement des techniques avancées de NAT traversal (traversée de NAT) pour établir ces connexions directes à travers Internet, même si les appareils sont derrière des routeurs ou pare-feux stricts. Résultat : des débits améliorés et moins de latence, ce qui est appréciable pour des usages comme la vidéoconférence, la téléphonie IP, ou simplement pour accéder plus rapidement aux bases de données et aux applications internes.
• No single point of failure : Si le serveur VPN central tombe dans un schéma classique, plus personne ne peut rien faire à distance. Dans un réseau overlay pair-à-pair, l’indisponibilité d’un nœud ou même d’un serveur de coordination n’empêche pas nécessairement les autres nœuds de communiquer (selon l’architecture). Cela améliore la resilience de l’accès au système d’information. Chaque appareil agit en quelque sorte comme une partie du réseau global, sans dépendre en permanence d’un concentrateur unique.
• Enhanced security through compartmentalization : A mesh VPN provides fertile ground for applying micro-segmentation principles within the network. Since all communication passes through the encrypted private network, it becomes easier to control and log who accesses what. It also prevents critical services from being reachable from the Internet. Instead, they are hidden behind the VPN. Par exemple, une interface d’administration sensible ou un dépôt Git interne ne seraient accessibles qu’aux machines membres du VPN autorisées, et invisibles pour le reste du monde. En outre, les solutions de VPN overlay modernes permettent souvent de définir des règles d’accès granulaires (par utilisateur, par appareil, par groupe, etc.) au sein même du réseau privé, ce qui ajoute une couche de contrôle comparé au simple VPN « tout ou rien » d’antan.
• Ease of connection for users : Pour l’employé non technicien, ces solutions peuvent être très simples à utiliser. Beaucoup de solutions overlay offrent des applications clientes faciles à installer sur PC ou smartphone, avec une authentification unique (par exemple via le compte d’entreprise) puis tout fonctionne en arrière-plan. Fini les configurations manuelles d’OpenVPN ou les partages de clés complexes : l’utilisateur se connecte en quelques clics et peut faire son travail normalement, ce qui réduit les freins au respect des politiques de sécurité. Une solution bien choisie peut même permettre à un nouvel employé de s’intégrer rapidement (on l’ajoute dans le système et son accès aux ressources nécessaires est automatiquement prêt via le VPN mesh).

In summary, a mesh VPN can be seen as an invisible backbone reliant tous les acteurs et équipements de l’entreprise de manière sûre. C’est particulièrement utile pour les PME en hybrid remote work (une partie du personnel au bureau, l’autre à distance), pour celles qui ont plusieurs sites géographiques, ou encore pour celles qui font régulièrement appel à des prestataires externes devant accéder à certaines applications internes. Plutôt que de jongler avec X solutions ponctuelles de connexion, le réseau overlay agit comme un single foundation on which all use cases are built.

Contrôle d’accès interne et sécurité : ACL, segmentation et services critiques

Mettre en place un réseau privé virtuel maillé n’est pas qu’une question de connectivité pratique – c’est aussi l’occasion de raise internal security standards de l’entreprise. Voici quelques notions clés à comprendre, présentées simplement 

• ACL (Listes de Contrôle d’Accès) : Think of ACLs as rule sets that determine qui a le droit d’accéder à quoi. Dans le contexte d’un VPN overlay, une ACL peut par exemple stipuler que certain users or devices on the private network have the right to connect to a particular resource or service, éventuellement selon certains conditions (heure, lieu, etc.). En pratique, cela pourrait signifier : « Seuls les ordinateurs du service Comptabilité peuvent accéder au serveur de paie » ou « Interdire à tout le monde sauf à l’administrateur réseau d’accéder à l’interface d’administration du routeur ». Les ACL permettent donc de peaufiner la security policy au sein même du VPN, au-delà de la simple connexion ou non. C’est un peu le même principe qu’un contrôle d’accès physique : tout le monde peut entrer dans le bâtiment avec un badge général (connexion au VPN), mais certaines portes à l’intérieur ne s’ouvrent qupour les personnes autorisées (ACL internes).
• Internal network segmentation : Segmentation (or "access separation") involves dividing the network into multiple zones or isolated segments les uns des autres, afin de limiter l’étendue d’une intrusion éventuelle. Au lieu d’un réseau d’entreprise plat où une fois connecté on peut théoriquement joindre n’importe quelle machine, on crée des sous-réseaux ou des groupes. Par exemple, on peut isoler le réseau des serveurs de production, le réseau des équipements IoT, et le réseau des postes client. Avec un VPN maillé moderne, cette segmentation peut être logical – basée sur l’identité de l’appareil ou de l’utilisateur – plutôt que seulement physique ou par IP. Cela rejoint le principe des ACL : on ne donne accès qu’au segment nécessaire. En cas de compromission d’un poste, l’attaquant ne pourra pas rebondir facilement sur toute l’infrastructure, car les « portes » entre segments sont fermées par défaut. La segmentation interne est fondamentale pour protéger les critical systems.
• VPN-only access to critical services : De nombreuses PME disposent de services hautement sensibles : par exemple un coffre-fort de mots de passe d’entreprise, un serveur de gestion (ERP/CRM), une base de données client, un système de contrôle industriel, etc. Ces services ne devraient idéalement never be directly accessible from the Internet, même derrière un login. En les plaçant derrière le VPN privé, on ajoute une barrière. Seuls les utilisateurs connectés au VPN et dûment authentifiés peuvent tenter d’y accéder. On réduit drastiquement la surface d’attaque : plus de risque qu’un robot sur Internet découvre par hasard l’existence de votre page de login et tente des millions de mots de passe, ou qu’une vulnérabilité non corrigée dans votre application soit exploitée à distance. L’accès devient un privilège, pas un droit acquis par quiconque a Internet. C’est un peu comme garder les bijoux de famille dans un coffre-fort auquel on accède depuis une pièce sécurisée, plutôt que de les laisser dans l’entrée de la maison.
• Logging and audits : Un avantage souvent sous-estimé des VPN overlay est qu’ils peuvent centraliser la access logging. Because connections pass through this controlled network, it is possible to know which user accessed which resource and when. Some solutions offer detailed logs ou peuvent être intégrées à des outils d’audit et de supervision. Pour une PME qui souhaite se conformer à des normes de sécurité ou à la Loi 25, pouvoir tracer les accès aux données sensibles est un atout. Par exemple, si un audit de sécurité demande de prouver que seules les personnes autorisées consultent la base de données contenant des renseignements personnels, une infrastructure où tout passe via le VPN maillé (et donc est potentiellement enregistré) facilite ce genre de vérification.

En somme, mettre en place un VPN maillé ne sert pas qu’à rendre le télétravail plus commode : c’est aussi un levier pour instaurer une stronger internal security culture plus robuste. On passe d’un modèle ancien où le fait d’être « sur le réseau de l’entreprise » suffisait pour avoir confiance, à un modèle moderne où chaque accès est contrôlé, chaque ressource critique est isolée derrière plusieurs couches, et où l’on considère que la menace peut aussi venir de l’intérieur ou d’appareils compromis. Pour une PME, ces principes peuvent sembler techniques, mais les outils que nous présentons plus loin les rendent accessibles dans la pratique, souvent via des interfaces simples de définition de règles ou par la configuration initiale du réseau privé.

Cas d’usage concrets pour les PME

To illustrate what these technologies bring in concrete terms, here are a few cas d’usage typiques où une PME peut tirer parti d’un réseau overlay sécurisé :

• Secure access to an intranet or internal applications : Imaginons une PME qui dispose d’un intranet (par exemple un site web interne pour les employés, contenant l’annuaire du personnel, des procédures, des documents RH, etc.) ou même d’un partage de fichiers réseau. En déployant un VPN maillé, la PME peut rendre cet intranet accessible en tout lieu only aux employés connectés via le réseau privé. Un employé en déplacement ou en télétravail lance son client VPN mesh et peut consulter l’intranet exactement comme s’il était au bureau. L’entreprise n’a pas besoin d’exposer l’intranet sur Internet public, ce qui évite toute tentative de piratage externe. De plus, grâce aux ACL, on pourrait limiter certaines sections sensibles de l’intranet à des groupes d’utilisateurs spécifiques (par exemple, le dossier « Comptabilité » accessible seulement aux comptables même au sein du VPN).
• Centralized access to a password manager : Les gestionnaires de mots de passe d’entreprise (par ex. Bitwarden self-hosté, Keepass partagé, ou une solution maison) contiennent les « clés du royaume ». Il est dangereux de les rendre accessibles depuis n’importe quelle connexion Internet, même protégés par un mot de passe maître. Grâce à un VPN overlay, la PME peut héberger son coffre-fort de mots de passe sur un serveur interne et exiger que pour y accéder, l’utilisateur soit connecté au VPN sécurisé. Ainsi, un employé qui doit récupérer un mot de passe le fait depuis l’environnement protégé du réseau privé, réduisant les risques d’interception. On peut journaliser ces accès et les limiter (ex : seuls les membres de l’équipe IT peuvent accéder au coffre-fort des comptes admin, etc.). Cela donne une double barrier : il faudrait qu’un attaquant compromette le VPN and the password manager to reach this critical data.
• Simplified hybrid remote work : Dans beaucoup de PME, le télétravail n’est pas absolu – on parle plutôt d’hybride (quelques jours à la maison, quelques jours au bureau). Avec une solution de VPN maillé, la transition est transparente. Au bureau, la machine peut accéder aux ressources directement (ou même via le VPN, ce n’est pas un problème), et à la maison l’employé active son client VPN et retrouve exactement le même environnement réseau. Par exemple, un développeur qui travaille sur un serveur de test interne n’a pas besoin de changer la configuration de son outil selon qu’il est au bureau ou chez lui : l’adresse IP privée du serveur reste joignable dans les deux cas via le VPN. Cela réduit les risques d’erreur de configuration ou de laisser des ports ouverts « pour tester depuis la maison » (mauvaises pratiques courantes sans VPN unifié).
• Audit and technical support access : Une PME peut avoir des prestataires externes ou des auditeurs qui doivent temporairement accéder à certaines machines ou logs. Plutôt que de leur ouvrir un accès VPN classique à tout le réseau (ce qui pose un souci de confiance) ou de leur demander de venir physiquement, on peut les ajouter au réseau overlay avec un profil restreint. Par exemple, un expert sécurité mandaté pour un audit pourrait être invité sur le VPN maillé de l’entreprise, mais on configure des ACL de sorte qu’il ne puisse interroger que les serveurs cibles de l’audit, et rien d’autre. On peut limiter la durée de son accès (en le supprimant du VPN après la mission). De cette façon, l’auditeur peut travailler depuis chez lui en se connectant aux machines de la PME de manière sécurisée, sans exposer publiquement ces machines ni lui donner une clé VPN trop large. De même, pour du support technique externalisé, on peut accorder aux techniciens un accès VPN juste sur les systèmes concernés (par ex., le serveur de messagerie uniquement, et pas le reste).
• Geographic site interconnection : If an SMB has two or more offices (for example, a head office in Montreal and a branch in Quebec City), a mesh VPN can replace or supplement expensive inter-site connections. Each site connects its router or a few key machines to the overlay network, creating a shared encrypted network par Internet. Les employés des deux sites pourront accéder aux ressources partagées sans distinction, et les deux réseaux locaux peuvent être reliés comme un seul réseau virtuel. Cela se fait souvent sans avoir à configurer manuellement des tunnels site-à-site compliqués : les solutions mesh prennent en charge la découverte et la connexion automatique des nœuds correspondants. En bonus, si un des sites héberge un serveur de sauvegarde, il peut recevoir les données de l’autre site via le VPN sécurisé, évitant de transiter en clair sur Internet.

These examples show how, in very concrete terms, an overlay VPN can simplifier l’architecture informatique tout en renforçant la sécurité. Que ce soit pour faciliter le travail au quotidien (accès aux outils internes depuis n’importe où) ou pour protéger des actifs numériques vitaux, ce type de réseau privé donne aux PME une flexibilité autrefois réservée aux grandes entreprises disposant de réseaux MPLS et d’appliances coûteuses. Passons maintenant en revue cinq solutions représentatives permettant de mettre en place un tel réseau, chacune ayant ses atouts et inconvénients.

Overview of compared mesh VPN solutions

Il existe aujourd’hui plusieurs outils pour bâtir un VPN maillé. Nous avons sélectionné cinq solutions couramment évoquées, dont trois sont des logiciels libres auto-hébergeables et deux sont des offres commerciales cloud.

For each solution, we describe its operating model (peer-to-peer architecture, need for a central server, etc.), its ease of deployment et d’utilisation, le level of control offert (possibilité d’héberger soi-même, réglages de sécurité, intégrations SSO/LDAP), le cost (logiciel libre vs licence, besoin d’infrastructure) et sa maturity/stability along with its supporting community.

WireGuard (open source, self-hosted)

General overview: WireGuard est à l’origine un protocole VPN ultra-léger et sécurisé, publié en open source. Plus qu’un service complet « prêt à l’emploi », c’est un low-level tool (intégré au noyau Linux depuis 2020) qui permet de créer des tunnels VPN site-à-site ou point-à-point avec une grande performance. WireGuard vise la simplicité du code et de la configuration : il utilise des algorithmes cryptographiques modernes (basés sur le framework Noise) et se compose de seulement quelques milliers de lignes de code, ce qui le rend facilement auditable et très stable. En contexte de réseau maillé, WireGuard peut être utilisé comme brique de base pour interconnecter plusieurs nœuds en pair-à-pair, mais n’offre pas en soi de mécanisme de découverte ou de coordination centralisée – tout repose sur la configuration manuelle (ou l’ajout d’outils externes).

How it works: Chaque pair (machine) WireGuard est identifié par une clé publique et chaque tunnel VPN est défini en configurant les clés et adresses IP autorisées de part et d’autre. En pratique, pour construire un réseau mesh complet avec WireGuard pur, il faudrait configurer chaque machine avec la liste des autres pairs ou du moins avoir une topologie en étoile avec un nœud central relayant le trafic. WireGuard ne fait que chiffrer et transporter les paquets IP, il ne gère pas les droits d’accès par utilisateur ni l’inscription dynamique de nouveaux nœuds. C’est du pure peer-to-peer, sans serveur obligataire : les paquets sont envoyés directement entre clients (après un échange de clés initial). Pour traverser les NAT, WireGuard peut utiliser le protocole UDP et supporte du basic NAT traversal (via la technique du “hole punching”), mais souvent cela nécessite que chaque point connaisse l’adresse IP publique de l’autre ou passe par un relais si aucun contact direct n’est possible. En somme, WireGuard offre l’équivalent d’un câble réseau virtuel chiffré entre machines, mais c’est à l’administrateur de créer l’architecture logique voulue.

Deployment and usage: Pour des informaticiens expérimentés, déployer WireGuard est assez simple : on installe le module/logiciel sur chaque machine (disponible pour Linux, Windows, macOS, Android, iOS, etc.), on génère des paires de clés, puis on édite un fichier de configuration listant les pairs autorisés et leurs clés. Cependant, pour une PME sans expertise réseau poussée, la mise en place d’un mesh complet peut vite devenir tedious si le nombre de nœuds augmente. Il faut penser que chaque nouveau poste doit être configuré sur tous les autres (ou sur un nœud central) manuellement. Il existe heureusement des solutions pour faciliter la gestion de WireGuard : par exemple des outils open source comme Netmaker, NetBird or Innernet which provide a controller Tailscale-like overlay while remaining self-hosted, or simple interfaces like wg-easy or PiVPN pour certains cas d’usage (souvent plus orientés VPN classique). Néanmoins, ces outils supplémentaires ne sont pas « officiels » de WireGuard et peuvent nécessiter du temps d’apprentissage.

Control and security: En utilisant WireGuard “brut”, le contrôle des accès se fait principalement via la topologie réseau et les règles IP. Il n’y a pas de notion intégrée d’utilisateur ou d’identité autre que les clés des appareils. Donc, si une machine est connectée, elle voit tout ce que le réseau IP lui permet de voir. Pour appliquer des restrictions, il faut utiliser des pare-feux (iptables par exemple) ou bien définir plusieurs réseaux WireGuard séparés pour différents groupes. Il n’y a pas d’centralized ACLs prêtes à l’emploi dans WireGuard – c’est à vous de mettre en place les filtrages. De même, l’intégration avec un annuaire d’entreprise (LDAP/Active Directory, SAML SSO) n’est pas fournie en natif : il faudrait développer un système pour créer/supprimer les configs WireGuard en fonction des utilisateurs de votre AD, par exemple. C’est donc très puissant et entirely under your control, mais ça demande du travail si on veut un résultat équivalent aux solutions clés en main. L’avantage, c’est que le chiffrement est à l’état de l’art et minimaliste, donc très peu de surface d’attaque. WireGuard a fait l’objet d’audits de sécurité approfondis et est réputé very safe and reliable.

Costs: WireGuard est gratuit et open source (licence GPLv2). Il n’y a aucun coût de licence logiciel, ni de limitation sur le nombre de connexions. Le principal coût pourrait être en temps humain (configuration, maintenance) et éventuellement en serveurs si vous choisissez d’avoir un nœud central ou des relais. Par exemple, une PME pourrait déployer un petit serveur VPS à 5€/mois pour faire office de nœud central/relai si besoin, mais ce n’est pas obligatoire. Il faut aussi considérer que sans interface de gestion, la maintenance (ajouter un utilisateur, révoquer une clé) demande de l’édition de config et du déploiement sur les machines concernées – donc du temps technique.

Maturity and community: WireGuard est l’une des technologies VPN les plus mature aujourd’hui, malgré son jeune âge (développé dans les années 2010 et intégré mainstream vers 2019). Il est directement intégré aux noyaux Linux récents, ce qui témoigne de la confiance de la communauté. De grandes entreprises et projets l’utilisent (par exemple, le service Cloudflare WARP s’appuie sur WireGuard, tout comme Tailscale à la base). La communauté autour de WireGuard est très large, avec d’innombrables tutoriels, scripts et outils tiers. Cependant, la communauté ne fournit pas un support officiel centralisé puisque ce n’est pas un produit “packagé” – ce sont les utilisateurs et contributeurs qui s’entraident via des forums, GitHub, etc. Pour une PME, adopter WireGuard signifie soit avoir en interne les compétences pour l’exploiter au mieux, soit s’appuyer sur un prestataire/consultant qui peut le faire. La stability du logiciel en lui-même est excellente : c’est léger, ça plante rarement, et les performances sont au rendez-vous (on atteint facilement des débits de plusieurs Gbps sur du matériel courant, ce qui surpasse souvent OpenVPN ou IPsec).

WireGuard summary: In short, WireGuard is ideal if you want a VPN solution that is highly streamlined, performant, and 100% under your control, mais il faut être prêt à gérer la configuration manuelle ou à investir dans un orchestrateur additionnel pour obtenir un véritable réseau maillé convivial. Pour une micro-entreprise ou un scénario simple (quelques sites fixes à interconnecter, ou donner accès à 2-3 employés nomades), WireGuard peut être mis en place relativement facilement et offre une fiabilité exemplaire. Pour un usage plus large avec des dizaines d’utilisateurs mobiles, d’autres solutions présentées ci-dessous pourraient apporter une simplified management layer that WireGuard alone lacks.

Nebula (open source, self-hosted)

General overview: Nebula est un outil de réseau overlay open source initialement développé par l’équipe de sécurité de Slack. Il a été conçu pour connecter entre eux des tens of thousands of servers and workstations around the world de manière sécurisée et performante. Slack l’a rendu public en 2019, et depuis une communauté s’est formée autour (notamment avec la société Defined Networking founded by Nebula's creators, which continues to support it). Nebula describes itself as a "global virtual packet exchange" : il permet à n’importe quelles machines autorisées de communiquer comme si elles étaient sur le même réseau, de façon chiffrée, en se basant sur des identités cryptographiques. Ce qui distingue Nebula, c’est l’intégration native de concepts de security groups and certificates concepts for identifying hosts, which facilitates access control at the network level.

How it works: L’architecture de Nebula est peer-to-peer with lightweight coordination. Each node (device) that joins the Nebula network is assigned a certificate signed by a certificate authority (CA) propre au réseau de l’entreprise. Ce certificat contient l’identité du nœud, sous forme d’attributs (par exemple : rôle = webserver, environnement = production, localisation = eu-west, etc. – c’est personnalisable). Nebula utilise ces identités pour décider si deux nœuds peuvent communiquer. La connexion entre nœuds est directe (p2p) dès que possible, et chiffrée (Nebula utilise par défaut le protocole Noise, avec un chiffrement symétrique AES-256-GCM). Pour que les nœuds se découvrent et s’établissent un canal, Nebula introduit un ou plusieurs serveurs de découverte appelés lighthouses (phares). Un lighthouse est un simple service (qu’on peut héberger sur n’importe quel serveur) auquel chaque nœud annonce sa présence et son adresse actuelle. Quand un nœud veut joindre un autre, il consulte le lighthouse pour obtenir sa dernière adresse connue et tente d’ouvrir une connexion UDP directe. À partir de là, le trafic passe en direct entre les deux hôtes (avec des techniques de hole punching pour traverser les NAT, similaire à ce que fait Tailscale ou ZeroTier). Les lighthouses do not carry user traffic (ils ne font que l’introduction), ce qui signifie que le réseau ne dépend pas d’eux pour la bande passante – en cas d’indisponibilité, de nouveaux pairs ne se trouveront plus aussi facilement, mais ceux déjà connectés pourraient continuer à échanger si leur adresse ne change pas. Nebula n’est pas basé sur WireGuard ; en réalité il s’inspire d’un autre VPN peer-to-peer nommé Tinc, mais revu à la sauce Slack pour plus de performance et de sécurité.

Deployment and usage: Déployer Nebula nécessite quelques étapes supplémentaires comparé à WireGuard, mais cela reste abordable pour une PME avec un minimum de compétences système. Il faut tout d’abord créer une certificate authority Nebula (générer une clé CA Nebula) puis, pour chaque machine, générer un certificat signé par cette CA. L’outil Nebula fourni en ligne de commande permet de le faire assez simplement (il y a des scripts d’exemples pour créer certificats et clés). Ensuite, il faut choisir un ou deux serveurs à mettre en rôle lighthouse (idéalement sur le cloud ou dans un endroit accessible par tous, avec IP fixe). Chaque client aura une configuration où l’on indique l’adresse du ou des lighthouses, sa propre identité (certificat + clé) et les règles de pare-feu Nebula (nous y reviendrons). Une fois cela fait, on lance le service Nebula sur chaque machine (c’est un binaire unique à exécuter, disponible pour Linux, Windows, macOS – et même Android/iOS via des apps mobiles développées plus tard). Nebula va alors automatiquement se connecter au(x) lighthouse(s), obtenir la liste des pairs du réseau et établir les liens nécessaires. Par rapport à WireGuard, le travail manuel d’inscription de chaque pair sur tous les autres n’est pas nécessaire : lighthouses et certificats gèrent la découverte et l’authentification. L’usage au quotidien est transparent : Nebula crée une interface réseau virtuelle sur chaque machine avec une adresse IP (généralement on choisit une plage type 10.***). Les machines peuvent s’adresser via ces IP Nebula. L’entreprise doit cependant maintenir la CA et émettre/révoquer les certificats quand un nouveau nœud arrive ou qu’un appareil est compromis. C’est un processus un peu semblable à gérer des certificats VPN ou des clés SSH, mais Nebula fournit des outils pour le faire en ligne de commande. Des interfaces graphiques tierces existent (par exemple, Nebula cert manager en open source, ou des scripts d’automatisation), mais la solution en elle-même n’a pas (à ce jour) de console d’administration web toute faite – c’est le revers de l’auto-hébergé pur.

Control and security: C’est l’un des points forts de Nebula. Grâce à son système d’identités par certificats, Nebula intègre un distributed firewall où chaque nœud applique des règles en fonction des attributs de l’identité des pairs. Par exemple, vous pouvez définir dans la configuration Nebula : « autoriser le trafic sur le port 3306 (MySQL) uniquement si l’émetteur a l’attribut rôle=db-client et le récepteur a rôle=db-server ». Ou encore : « interdire tout trafic RDP vers les machines de production ». Ces règles sont distribuées dans la config de chaque client et évaluées localement, ce qui signifie que la sécurité ne dépend pas d’un point central : même si quelqu’un arrivait à entrer dans le réseau Nebula, chaque hôte continue d’appliquer les configured restrictions. C’est une approche zero-trust de l’intérieur : l’identité (vérifiée par certificat) prime sur l’adresse IP réelle. Par rapport aux autres solutions, Nebula n’a pas de notion d’utilisateur humain ou d’intégration SSO – l’analogie serait plutôt que chaque appareil est comme un « entité » approuvée via son certificat. Donc si un employé utilise deux appareils, on gérera deux certificats. Révoquer l’accès d’un employé implique de révoquer ses certificats (Nebula ne gère pas une CRL complexe, souvent on retire le certificat de la configuration du réseau ou on change de CA pour forcer un renouvellement). Il n’y a pas d’LDAP/SAML integration prête à l’emploi : Nebula vise surtout le niveau réseau/transport, pas la gestion des identités utilisateurs. Cependant, on peut tout à fait coupler Nebula avec des outils existants : par exemple, un script pourrait utiliser une liste d’appareils autorisés issue de votre Active Directory pour générer les certificats. En matière de sécurité du protocole, Nebula est solid : utilisé en production chez Slack à grande échelle, il a prouvé pouvoir encaisser des milliers de nœuds et un trafic soutenu. Il utilise AES-GCM (rapide sur les CPU modernes avec AES-NI) et Noise protocol pour l’échange de clés, ce qui est tout à fait robuste. On notera que Nebula fonctionne en routed mode (Layer 3 IP) uniquement, pas en Ethernet ponté, ce qui est suffisant pour la quasi-totalité des usages (c’est pareil pour WireGuard et Tailscale, alors que ZeroTier peut faire du Layer 2). Ce choix évite par exemple les problématiques de broadcast orageux sur le réseau virtuel.

Costs: Since Nebula is fully open source (MIT license) and free, the main cost lies in the time and server resources to run it. The lighthouses consomment peu (ce sont de petits services d’annuaire, une petite VM à 1 vCPU/512Mo RAM peut suffire pour des dizaines ou centaines de clients). On en installe souvent au moins deux pour la redondance. Si vous avez déjà des serveurs chez un hébergeur local ou en data center, vous pouvez les utiliser. La gestion des certificats peut aussi prendre un peu de temps (surtout au début lors de l’inscription de tout le monde). Mais une fois en place, Nebula ne nécessite pas de coûts additionnels, pas de licence par nœud, etc. Il n’y a pas non plus de version entreprise payante (Defined Networking propose des services d’accompagnement éventuellement, mais le logiciel est unique). C’est donc attractif pour un budget serré, à condition d’avoir une appétence technique pour le maintenir.

Maturity and community: Nebula has achieved a solid level of maturity dans le sens où Slack l’utilise depuis des années en production. Cependant, en dehors de Slack et de certaines entreprises tech, il est moins connu du grand public que WireGuard ou ZeroTier. La communauté existe, principalement via GitHub, Slack (ironique, un Slack communautaire pour Nebula), et quelques blogs. On trouve de la documentation sur le site de Defined Networking, un guide officiel, etc., mais ce n’est pas une énorme communauté. Cela dit, Nebula répond à un besoin précis et ceux qui l’utilisent en sont généralement satisfaits pour sa stabilité. Des mises à jour continuent d’arriver (par ex., le support officiel des clients mobile a été ajouté, avec une app Nebula pour iOS et Android publiée en 2022, ce qui est crucial pour un usage en télétravail). Nebula est aussi utilisé dans certains projets open source annexes (par exemple pour créer des labos de sécurité ou des mini VPN). En termes de stabilité : c’est un service en Go, tournant en espace utilisateur, il peut consommer un peu de CPU sur des liens très rapides (chiffrement AES en userland) mais rien de dramatique pour des débits classiques (<1 Gbps). Slack a communiqué sur le fait qu’ils connectent des milliers de machines multi-cloud avec Nebula sans souci. Donc pour une PME, la trust à avoir en Nebula est tout à fait raisonnable, à condition d’être à l’aise avec l’absence de support commercial structuré (vous êtes votre propre support, ou via la communauté).

Nebula summary: Nebula is an excellent choice if your SMB wants a self-hosted mesh VPN with a high level of control over internal security. Il se distingue par sa capacité intégrée à gérer des politiques d’accès basées sur l’identité des machines, ce qui en fait un outil puissant pour segmenter votre réseau. En contrepartie, sa mise en place demande un peu d’investissement initial (certificats, config des lighthouses) et il n’a pas de portail web convivial pour inviter un nouvel utilisateur en un clic – c’est plus orienté « admin système ». Pour une entreprise technologique ou avec un bon service informatique, Nebula offrira une liberté totale et une absence de dépendance à un fournisseur externe, tout en assurant une sécurité robuste. Pour une PME très petite sans compétences IT, Nebula pourrait s’avérer complexe, auquel cas des solutions comme Tailscale ou ZeroTier (cloud) seraient plus appropriées.

ZeroTier in self-hosted mode (open source)

General overview: ZeroTier est une solution de réseau virtuel qui existe depuis 2014 et qui a gagné en popularité grâce à sa grande facilité d’utilisation et ses fonctionnalités avancées de virtualisation de réseau. Techniquement, ZeroTier se présente comme un commutateur Ethernet virtuel planétaire : il crée un réseau virtuel extended LAN (Layer 2) sur Internet, où chaque nœud se voit attribuer une adresse virtuelle et peut communiquer en broadcast, multicast, etc., comme sur un vrai réseau local. Le client ZeroTier est open source (code disponible), ce qui permet théoriquement de s’auto-héberger entièrement la solution. Cependant, par défaut la plupart des utilisateurs utilisent l’infrastructure cloud de ZeroTier, nous y reviendrons dans la section suivante. Ici, nous décrivons le cas de figure où une PME souhaite manage its own ZeroTier network, sans dépendre du cloud public ZeroTier.

How it works: ZeroTier, côté client, fonctionne de manière assez similaire aux autres VPN mesh : chaque nœud crée des liens pair-à-pair avec les autres pour échanger du trafic, en essayant la connexion directe et sinon en passant par des relais. La grosse différence est que ZeroTier opère au niveau Ethernet (Layer 2), ce qui lui permet de transporter tout type de trafic (IPv4, IPv6, ARP, etc.) et même de faire du bridging avec un réseau physique. Concrètement, les nœuds ZeroTier rejoignent un virtual network identified by an ID (un peu comme un SSID Wi-Fi). Un composant clé est le controller de réseau : c’est lui qui gère les autorisations (qui est membre de tel réseau, quelles adresses virtuelles ils ont, quelles règles de flux s’appliquent). Dans l’offre cloud, ce rôle est assuré par le service ZeroTier Central. En auto-hébergé, vous devez déployer votre own controller. Heureusement, le logiciel ZeroTier intègre un mode contrôleur que l’on peut activer via l’API ou la CLI, bien que non documenté de façon très didactique pour les novices. De plus, ZeroTier utilise des root servers (appelés planètes et lunes dans leur jargon) pour permettre aux clients de se trouver sur Internet. L’entreprise ZeroTier opère un ensemble de serveurs racine publics par défaut. En auto-hébergement complet, on peut choisir de ne pas utiliser ceux-là et de mettre en place ses propres serveurs racine (par ex., déployer des “moons”). C’est une configuration avancée, destinée surtout aux environnements isolés ou exigeants en souveraineté. En résumé, en mode auto-hébergé, vous pourriez : 1) déployer un contrôleur ZeroTier privé qui gère votre réseau virtuel (et donc vous avez votre propre interface/API pour autoriser des membres, configurer le réseau), 2) éventuellement déployer des serveurs racine ZeroTier (ou moons) pour que vos clients n’aient pas besoin de contacter l’infrastructure officielle. Les clients ZeroTier peuvent être configurés pour utiliser votre planète de serveurs plutôt que celle de ZeroTier Inc, réalisant ainsi un fully autonomous mesh VPN. Le fonctionnement pair-à-pair pour les données reste identique, et ZeroTier excelle dans la NAT traversal (c’est un de ses points forts, il utilise divers algorithmes pour établir les connexions directes ou recourir à des relais si nécessaire).

Deployment and usage: Autant le cas d’utilisation cloud de ZeroTier est plug-and-play, autant la voie de l’auto-hébergement demande un effort technique. Le contrôleur ZeroTier est disponible via une API JSON REST dans le démon ZeroTier lui-même. Cela signifie que pour créer un réseau, ajouter un membre, etc., vous devrez soit appeler ces API via des scripts, soit utiliser un outil tierce. La communauté a produit par exemple ZTNCUI (ZeroTier Network Controller UI), une interface web non officielle pour contrôler un serveur ZeroTier privé. ZeroTier Inc a documenté le minimum pour mettre en place un contrôleur et des root servers

, mais recommande cela uniquement pour les cas d’usage spécifiques (et réserve la condition que tout usage commercial de leur techno auto-hébergée doit respecter leur licence – gratuitement jusqu’à un certain point, mais probablement payant à très grande échelle). Pour une PME toutefois, ces limitations de licence ne devraient pas poser problème, on parle de milliers de nœuds avant d’atteindre des cas payants. En pratique, vous installeriez le service ZeroTier sur une machine Linux que vous dédiez comme contrôleur (celui-ci n’a pas besoin d’être puissant du tout). Vous créeriez un réseau via l’API, puis vous configureriez vos clients ZeroTier pour “joindre” ce réseau. Au moment où un client tente de joindre, il contactera votre contrôleur (il faut lui indiquer l’adresse de votre contrôleur au lieu de celui par défaut) pour l’autorisation. Vous verrez le nouvel équipement en attente et pourrez l’approuver (via un appel API ou une UI tierce). Après cela, l’appareil reçoit sa configuration réseau (une adresse virtuelle ZeroTier) et peut communiquer avec les autres. C’est très similaire à l’expérience cloud, sauf que everything is done manually via API à moins d’utiliser un outil auxiliaire. Autre option : ZeroTier propose aux clients entreprise un pack de contrôleur on-premises plus user-friendly, mais cela sort du cadre open source (c’est payant). Niveau usage quotidien, une fois configuré, ça marche comme en cloud : l’utilisateur lance ZeroTier, rentre l’ID de réseau et c’est tout. Donc l’auto-hébergement n’impacte pas l’utilisateur final, seulement l’administration en coulisse.

Control and security: ZeroTier permet de définir des flow rules associées à un réseau, qui agissent comme des ACL/firewall au sein du réseau virtuel. Par exemple, on peut écrire une règle pour bloquer tel type de trafic entre certaines machines. Ces règles, écrites dans un langage propre à ZeroTier, sont distribuées à tous les clients qui les appliqueront. Cela donne un bon contrôle sur qui peut parler à qui et comment, directement au niveau du réseau overlay. En auto-hébergé, vous bénéficiez bien sûr de toutes ces fonctionnalités sans restriction. L’intégration avec des systèmes d’identité (SSO, annuaires) n’est pas native dans la version open source. ZeroTier Inc a introduit un support SSO/OIDC pour sa console cloud entreprise【8†】, mais si vous gérez vous-même, il faudra reproduire cela manuellement (par exemple, en interfaçant l’API pour autoriser automatiquement les membres dont l’email apparaît dans un LDAP, etc.). En d’autres termes, ZeroTier self-hosted offre un full control over the data (rien ne transite par des serveurs tiers sauf ce que vous n’avez pas remplacé, comme les roots si vous gardez ceux par défaut) et sur la configuration du réseau, mais vous perdez la simplicité du SSO ou du “magique” qu’offrent les services gérés. Côté sécurité du protocole : ZeroTier utilise son propre protocole de chiffrement (pas WireGuard) mais il est open source et éprouvé depuis des années. Les communications sont chiffrées de bout en bout entre clients, et le contrôleur voit les meta-données (quel nœud est sur quel réseau, son adresse IP publique, etc.) mais pas le contenu des paquets. En self-host, ces meta-données restent chez vous. Notez que l’auto-hébergement complet (avec vos propres root servers) permet même d’avoir un réseau ZeroTier completely self-contained (par exemple pour des machines qui n’ont pas accès à Internet, on pourrait imaginer un ZeroTier sur un réseau LAN isolé pour faire de la segmentation interne). Peu de PME iront jusque-là, mais c’est possible.

Costs: Le logiciel ZeroTier est gratuit jusqu’à un certain seuil et open source. L’auto-héberger vous-même évite l’abonnement Premium de ZeroTier (qui s’applique normalement au-delà de 50 nœuds ou pour avoir plus de fonctionnalités sur leur cloud). Ici, vos seuls coûts sont l’hébergement du contrôleur et éventuellement des serveurs root. Un petit VPS (ou même un Raspberry Pi local) peut faire office de contrôleur. Si vous voulez des root servers privés répartis géographiquement, ça peut impliquer 2-3 petits serveurs dans le monde. Mais pour démarrer, ce n’est pas nécessaire, les clients peuvent très bien s’appuyer sur les root servers publics existants pour la mise en relation initiale, même si le contrôleur est à vous. Il faut juste savoir que si, par exemple, Internet coupait l’accès aux roots publics, vos clients ne se trouveraient plus. En termes d’effort humain, l’installation du contrôleur ZeroTier demande du temps de compréhension (l’API, la gestion via cURL ou via un outil custom). Ce n’est pas plug-and-play. Donc, le “prix” est surtout en complexité. On peut considérer qu’self-hosting ZeroTier is a niche choice pour les PME férues de technique ou ayant des besoins réglementaires forts.

Maturity and community: ZeroTier est très popular dans la communauté IT, et cela depuis plusieurs années. On recense des millions d’installations. La communauté d’utilisateurs est conséquente – mais la majorité utilise la version cloud. Néanmoins, de nombreux hobbyistes et experts ont expérimenté l’auto-hébergement et partagent des outils (on a cité ZTNCUI, il y a aussi des scripts Docker pour un contrôleur minimal, etc.). ZeroTier Inc fournit de la documentation sur l’auto-hébergement, ce qui est bon signe sur l’ouverture de la plateforme. Le logiciel en lui-même est stable et régulièrement mis à jour. Sur un plan performances, ZeroTier en mode routage userland est un peu moins rapide que WireGuard kernel dans certains tests, mais reste très correct (il peut atteindre plusieurs centaines de Mbit/s, largement suffisant pour la plupart des PME). Sa stability est reconnue : il n’est pas rare de voir un client ZeroTier tourner des mois sans interruption, permettant à des sites distants de rester connectés en permanence. Quant à la durabilité, ZeroTier Inc étant une entreprise (récemment acquise par Canonical fin 2023), la technologie a de bonnes chances d’évoluer et d’être supportée sur le long terme. La communauté peut aider via les forums officiels, Discord, Reddit, etc., en cas de souci, même en mode auto-hébergé (bien que moins courant, donc moins de monde a l’expertise précise).

Self-hosted ZeroTier summary: Cette option s’adresse aux PME qui veulent bénéficier de la power of ZeroTier (facilité d’ajout de nœuds, réseau flexible L2, règles fines) tout en gardant tout en interne pour des raisons de confidentialité ou de conformité. C’est un excellent compromis entre un WireGuard brut (où tout est manuel) et un service cloud (où tout est tiers) – à condition d’accepter la charge de l’admin. Pour une PME ayant un administrateur réseau compétent, ce peut être un projet intéressant, surtout si elle a des réticences à confier ses réseaux à un service externe. Pour d’autres, la complexité ne vaudra pas le gain, et elles préféreront soit du Nebula (autonome mais plus simple niveau contrôleur) soit directement un service cloud comme Tailscale ou ZeroTier Central qui offrent la même expérience sans effort.

Tailscale (commercial cloud offering)

General overview: Tailscale est une solution de VPN maillé relativement récente (lancée en 2019) qui a rapidement gagné en notoriété grâce à son extrême simplicité d’utilisation. Tailscale utilise le protocole WireGuard sous le capot pour le chiffrement, mais apporte par-dessus un cloud-managed control plane et une intégration aux identités d’entreprise. L’objectif avoué de Tailscale est de rendre le VPN aussi facile que possible, y compris pour des non-spécialistes : “installez, connectez-vous, et ça marche”. Il est particulièrement apprécié des développeurs, des PME et même des particuliers pour connecter des homelabs, parce qu’il élimine la plupart des tracas de configuration. Tailscale est un service commercial SaaS, bien qu’il propose une généreuse offre gratuite pour usage personnel ou petites équipes de 1 à 3 utilisateurs.

How it works: Tailscale adopte une architecture peer-to-peer with centralized coordination. Chaque client Tailscale que vous installez (sur PC, Mac, serveur Linux, smartphone…) va, au démarrage, s’authentifier auprès du Tailscale coordination server. Ce serveur central (géré par Tailscale Inc sur leurs infrastructures) enregistre la clé publique du client et lui fournit la liste des autres pairs de son réseau privé (appelé “tailnet” dans leur jargon). Il agit en quelque sorte comme un annuaire et un serveur d’authentification. Une fois cela fait, le client établit les connexions directes chiffrées WireGuard vers les autres clients quand il en a besoin. Tailscale utilise également un réseau de relay servers called DERP (relay servers distribués à travers le monde) pour faire transiter le trafic si un pair ne peut absolument pas avoir de connexion directe vers un autre (cas de NAT symétriques très restrictifs par exemple). Tout ce plan de contrôle est transparent pour l’utilisateur, si ce n’est qu’il nécessite Internet pour contacter le serveur de coordination. Tailscale n’a pas de mode “offline” auto-hébergé officiel (bien que la communauté ait créé “Headscale”, un clone open source du serveur – non couvert ici). Donc, en bref, Tailscale = clients WireGuard + serveur central dans le cloud pour orchestrer l’échange de clés et la découverte + éventuellement relais en cloud si nécessaire. Le modèle de confiance est tel que Tailscale (la société) cannot read your data (les tunnels WireGuard sont de bout en bout entre clients), mais elle a connaissance de la cartographie de votre réseau privé (quels appareils, quels IP virtuels, qui est connecté).

Deployment and usage: C’est le point fort de Tailscale : le déploiement est near-instantaneous. Pour une PME, cela se traduit par : on crée un compte Tailscale (souvent lié à son domaine d’entreprise Google Workspace, Microsoft 365 ou autre), on invite éventuellement des coéquipiers, puis chacun installe le petit client sur son appareil et se connecte avec son compte d’entreprise (SSO). Aussitôt, l’appareil apparaît dans le tableau de bord administrateur et est relié aux autres. Il n’y a pas de configuration de clés, de ports, de firewall complexe : Tailscale gère tout en arrière-plan. L’interface d’admin (via le web) permet de renommer les appareils, de les regrouper, de gérer des tags. L’administrateur peut définir des ACLs via un fichier de configuration (en JSON ou HCL, mais Tailscale propose aussi un éditeur visuel de règles simple pour les cas courants). Ces ACL permettent par exemple de dire : “les machines taggées serveur acceptent uniquement les connexions des utilisateurs du groupe Admin” ou “l’imprimante du bureau n’est pas accessible via Tailscale” etc. En termes d’effort, c’est très accessible : en quelques heures on peut équiper toute l’entreprise. Tailscale s’occupe aussi du name meshing : chaque machine a un nom du type hostname.tailnet-yourdomaine.ts.net, ce qui facilite la connexion sans connaître les IP. De plus, Tailscale propose des fonctionnalités annexes appréciables comme MagicDNS (intégration DNS interne), Split tunneling configurables, ou encore des “Exit nodes” (pour sortir sur Internet via un point particulier si on veut). Pour l’utilisateur final, l’application Tailscale affiche simplement qui est connecté dans votre réseau, avec un gros bouton on/off. Sur mobile, c’est aussi simple qu’une appli VPN standard. Cette approche en fait une solution parfaite pour les PME ne disposant pas de service IT dédié, ou pour des équipes où on ne veut pas perdre du temps en configuration technique.

Control and security: Bien que Tailscale soit géré dans le cloud, il offre de solides possibilités de contrôle. La première couche, c’est l’SSO/Identity integration : vous pouvez lier Tailscale à votre fournisseur d’identité (Google, Microsoft Azure AD, Okta, etc.). Ainsi, lorsque quelqu’un installe Tailscale, il doit se connecter via ce fournisseur – ce qui garantit qu’il s’agit bien d’un employé autorisé. Vous pouvez aussi paramétrer la validation automatique ou manuelle des nouveaux appareils. Ensuite, via les ACLs mentionnées, on peut imposer une politique zero-trust : par défaut Tailscale relie tout le monde, mais l’admin peut décider de restreindre fortement. Par exemple, isoler les environnements : dev, prod, etc., ou encore faire du RBAC (contrôle par rôle) sur l’accès à telle application. Les ACL de Tailscale sont définies dans la console et appliquées par le moteur central qui, en gros, décide quels pairs “voient” quels autres. Si une connexion n’est pas autorisée par les ACL, Tailscale empêchera les deux nœuds d’échanger (il filtre au niveau des paquets). C’est donc très facile à ajuster et à auditer. Sur le plan sécurité protocole, Tailscale héritant de WireGuard, c’est du chiffrement solide (ChaCha20-Poly1305 pour les données, Noise protocol pour l’établissement). Tailscale rajoute la rotation automatique des clés régulièrement pour plus de sécurité. Par ailleurs, toutes les connexions étant liées aux comptes utilisateurs, on peut révoquer l’accès d’une personne en un clic (suspendre son compte ou retirer son appareil). Tailscale fournit aussi des logs d’audit (surtout dans les plans payants) pour savoir qui s’est connecté quand, etc. Un petit plus : Tailscale a introduit récemment le concept de Firewall integration (devices that can act as subnet routers or funnels) et machine certificates – ce dernier permet à un appareil Tailscale d’obtenir un certificat x509 lié à son identité, ce qui peut servir à authentifier la machine sur d’autres services. Globalement, Tailscale est très complet en termes de sécurité pour un usage PME, sans nécessiter d’en comprendre tous les rouages.

Costs: Tailscale propose un modèle Freemium. Pour usage personnel (jusqu’à 1 utilisateur / 20 appareils) c’est gratuit. Pour une équipe ou PME, le plan payant démarre autour de 5$ par utilisateur par mois (avec 5 à 10 appareils par utilisateur inclus). Il existe aussi un plan “business” un peu plus cher apportant des fonctionnalités avancées (SSO obligatoire, key rotation personnalisée, etc.). Pour une PME de, disons, 50 employés, on peut s’attendre à un coût aux alentours de 250 $ par mois si tous doivent être connectés (ce qui reste généralement inférieur au coût de maintenir sa propre solution si on compte le temps humain). À noter que le prix per user peut être plus ou moins intéressant selon l’usage : chez Tailscale un “utilisateur” correspond généralement à une personne réelle avec plusieurs appareils. Si votre usage c’est connecter 100 IoT ou serveurs qui n’ont pas d’humains derrière, la tarification n’est pas parfaitement adaptée (ZeroTier en cloud facture plutôt par appareil par paquets de 25). Tailscale inclut dans ses coûts l’infrastructure de relais, la coordination, le support technique (pour les plans entreprise). On peut estimer que pour une petite PME (<5 personnes), le plan gratuit ou “Teams Starter” peut suffire à coût zéro. Au-delà, il faudra budgéter un abonnement. Il n’y a pas de coûts cachés d’infrastructure car vous n’hébergez rien de votre côté (hormis éventuellement un petit serveur si vous utilisez un “subnet router” pour connecter un réseau local entier, mais ce n’est pas obligatoire). Et bien sûr, vous économisez du temps d’administration réseau.

Maturity and community: En quelques années, Tailscale a acquis une base d’utilisateurs fervents et une active community. Le produit est en développement constant (nouvelles fonctionnalités ajoutées tous les quelques mois) par une startup dynamique, soutenue par des investisseurs. C’est à la fois un avantage (innovation rapide, ajout de fonctions utiles) et un point à surveiller (la société est jeune, non profitable en l’état – toutefois sa croissance et son adoption laissent penser qu’elle s’inscrit pour durer, d’autant qu’elle se base sur un protocole standard). La communauté technique discute beaucoup de Tailscale sur les forums, Reddit, etc., pour des usages allant de “connecter mes machines perso” jusqu’à “remplacer notre VPN d’entreprise Cisco”. Les avis convergent sur sa stability : bien que ce soit du user-space WireGuard (donc un poil moins rapide qu’en kernel), pour la plupart des usages on parle de saturer une fibre classique sans souci. Il y a des cas connus d’utilisation professionnelle sans accrocs. Tailscale étant multiplateforme, il y a des clients pour Windows, Mac, Linux (y compris ARM, etc.), iOS, Android, Synology, et même des plugins Docker. Cette ubiquité en fait un choix sûr pour l’avenir proche. L’entreprise derrière Tailscale est basée au Canada, ce qui peut rassurer certaines organisations quant à la juridiction (même si les serveurs peuvent être globalement distribués).

Tailscale summary: Pour une PME cherchant la simplest possible solution pour déployer un VPN maillé, Tailscale est un candidat de choix. Il brille par sa facilité (autant pour l’installation que la gestion des accès via SSO et ACL), ce qui se traduit par un gain de temps et une réduction des erreurs de configuration. Sa dépendance à un service cloud peut poser des questions de trust (il faut être à l’aise avec le fait qu’un tiers gère le contrôle de votre réseau, même s’il ne voit pas les données chiffrées). La plupart des entreprises considèrent que c’est un compromis acceptable étant donné les bénéfices. Cependant, pour des secteurs très réglementés ou soucieux de souveraineté, le fait que les métadonnées de connexion passent par les serveurs de Tailscale (hébergés aux États-Unis ou ailleurs) pourrait être un frein. En somme, Tailscale convient parfaitement aux PME qui ont peu de ressources IT et veulent quelque chose qui “just works” pour connecter leurs équipes en télétravail et protéger leurs services internes, avec une approche moderne de sécurité. Il comblera un peu moins ceux qui voudraient tout personnaliser ou tout garder on-premises.

ZeroTier Central (commercial cloud service)

General overview: Pour terminer, considérons ZeroTier in managed cloud version, c’est-à-dire l’utilisation standard du service proposé par ZeroTier Inc via leur plateforme ZeroTier Central. C’est en quelque sorte l’équivalent de Tailscale mais avec les spécificités de ZeroTier. Ici, vous ne déployez pas votre propre contrôleur, vous utilisez celui de ZeroTier Inc. L’intérêt est bien sûr de bénéficier de la configuration simplicity sans se soucier de l’infrastructure. ZeroTier, comme évoqué, offre un réseau virtuel de niveau 2 très flexible. La solution cloud convient aux PME qui veulent utiliser ZeroTier sans héberger quoi que ce soit.

How it works: En mode cloud, les clients ZeroTier que vous installez sur vos machines vont par défaut communiquer avec les public root servers de ZeroTier pour rejoindre le réseau global (la “planète” ZeroTier). Vous créez un réseau virtuel sur le site my.zerotier.com (appelé ZeroTier Central). Ce réseau a un ID unique. Chaque client qui connaît cet ID peut demander à le rejoindre. Le contrôleur cloud (ZeroTier Central) maintient la liste des membres autorisés, leurs adresses virtuelles, etc. Lorsqu’un de vos appareils se connecte, il reçoit du contrôleur la configuration (par ex., “l’appareil A a l’IP virtuelle 10.10.10.5/24 sur le réseau”). Les clients essaieront de se connecter en pair-à-pair comme toujours, en utilisant l’infrastructure ZeroTier (roots, relais) pour s’entraider à se trouver si besoin. En mode cloud, c’est ZeroTier Inc qui maintient cette infra globale de découverte. Eux peuvent s’assurer qu’il y a toujours des relais disponibles, que les serveurs d’autorité répondent rapidement, etc. Pour vous, administrateur, l’interface web ZeroTier Central permet de see all your nodes, de les grouper, de activer/désactiver, configurer des routes ou des passerelles. ZeroTier étant L2, on peut même bridger un réseau local en cochant une option sur un nœud (ce qui permet à un nœud d’agir comme un switch vers un LAN physique). En un mot, le mode cloud vous offre turnkey ZeroTier.

Deployment and usage: Côté utilisation, ZeroTier cloud est très proche de Tailscale dans l’esprit, avec quelques différences pratiques. On commence par créer un compte sur le site ZeroTier (là aussi possibilité de lier Google ou Microsoft pour SSO utilisateur, mais ce n’est pas orienté “utilisateurs multiples” de la même façon que Tailscale ; généralement c’est un compte admin qui gère tout, puis on distribue un Network ID aux clients). Ensuite, vous installez le client sur chaque machine (le client ZeroTier est disponible pour Windows, Mac, Linux, Android, iOS...). Pour joindre le réseau, vous pouvez soit entrer l’ID réseau manuellement via la CLI ou l’UI du client, soit utiliser un lien d’invitation. Une fois qu’un appareil demande à joindre, il apparaît dans votre console Central comme “en attente d’autorisation”. L’admin doit alors l’autoriser (à moins de mettre le réseau en mode “auto-approve” public, ce qui est rare en contexte pro). Cette étape d’approbation manuelle est une légère friction comparée à Tailscale où l’authentification utilisateur suffit à auto-valider les équipements. Mais elle garantit que même si quelqu’un connaissait l’ID, il ne peut pas rentrer sans validation. Une fois autorisé, l’appareil obtient son adresse (que vous pouvez éventuellement fixer ou laisser en auto-attribution). Tout de suite, il peut communiquer avec les autres selon les règles définies. La console permet de définir des flow rules en langage ZeroTier pour implémenter des ACL. Par exemple, on peut y écrire qu’une certaine plage ou un certain tag ne peut pas communiquer avec tel autre. Ce langage est puissant mais un peu ésotérique pour un débutant – c’est moins convivial qu’une liste d’accès de Tailscale par exemple. Heureusement, pour de petits réseaux, on peut s’en sortir en n’autorisant que certaines machines et en gardant des règles par défaut. ZeroTier Central permet également de paramétrer la IP configuration du réseau (IPv4/IPv6, etc.), ce qui est assez flexible (on peut avoir plusieurs sous-réseaux virtuels, du multicast, etc.). Pour l’utilisateur final, ZeroTier se fait discret : sur PC il tourne en tâche de fond, sur mobile il se comporte comme un VPN classique à activer. La gestion peut être un peu plus technique que Tailscale car il faut parfois expliquer à l’utilisateur comment entrer l’ID et attendre l’approbation, mais c’est globalement assez simple.

Control and security: En mode cloud, c’est ZeroTier Inc qui détient le contrôle plane. Donc, vos nœuds contactent leurs serveurs pour tout ce qui est coordination. La confidentialité du trafic reste assurée (chiffrement de bout en bout), mais les métadonnées (qui est sur quel réseau, quand une machine se connecte) sont potentiellement visibles par eux. Ils ont cependant une politique de ne pas espionner, et proposent même du SSO pour l’accès à la console admin (pour entreprises via SAML/OIDC). Comparé à Tailscale, ZeroTier n’a pas une notion forte de “utilisateurs avec comptes individuels” au niveau de son service – c’est plus orienté “vous gérez un réseau et vous y ajoutez des nœuds”. Ceci dit, ils ont introduit la possibilité d’associer des comptes et déléguer l’admin à d’autres sur un réseau, etc. Concernant la sécurité interne du réseau, on a évoqué les Flow Rules qui permettent d’écrire des ACL très fines si nécessaire. ZeroTier permet aussi de déclarer des local network routers : par exemple, un nœud peut annoncer qu’il route le sous-réseau 192.168.1.0/24 vers le VPN – et grâce à ça, on peut accéder à tout un LAN distant via un seul client (c’est équivalent à la fonction de subnet router de Tailscale). La sécurité de ZeroTier a été éprouvée sur le plan cryptographique, et la flexibilité L2 fait que certaines choses sont possibles (ex : on pourrait faire tourner un protocole custom ou de la découverte réseau à distance, ce que Tailscale ne permet pas car limité à IP). Pour une PME, il faut juste être conscient que ZeroTier cloud implique de faire confiance à l’entreprise sur la gestion des accès. On peut tout de même minimiser les risques en utilisant des two-factor authentication sur le compte admin, en segmentant les réseaux (plusieurs réseaux ZeroTier pour différents usages) et en appliquant des règles strictes dès le début pour limiter la portée de chaque nœud.

Costs: ZeroTier Central est gratuit jusqu’à 50 nœuds (appareils) ce qui, pour pas mal de petites PME, pourrait déjà suffire. Au-delà, ils fonctionnent sur un modèle de packs de nœuds : il faut acheter 25 nœuds supplémentaires à chaque fois, pour environ 29$/mois par pack de 25. Donc si vous avez 100 appareils, cela tourne autour de 58$/mois (2 packs en plus des 50 gratuits). Ce mode de tarification peut être plus predictable que le par utilisateur de Tailscale, notamment si une personne a plusieurs appareils ça compte plusieurs nœuds. ZeroTier propose aussi une formule Enterprise avec un tarif personnalisé et plus de services (support, on-prem controller packagé, etc.). Mais pour une PME standard, on sera sur l’utilisation de la formule Basic (gratuite/petits packs). Niveau coûts indirects, utiliser ZeroTier cloud c’est épargner du temps d’administration comparé à la solution auto-hébergée. Tout est compris dans le service. Donc financièrement, c’est assez intéressant, d’autant que la barre des 50 nœuds gratuits est haute pour beaucoup de structures (par ex., 20 employés avec chacun PC + mobile + peut-être un serveur ou deux, on atteint à peine ~50). Il faut juste garder en tête qu’en cas de croissance, on passe sur un palier payant, mais modulaire.

Maturity and community: Comme déjà souligné, ZeroTier est une solution mûre avec une communauté vaste. En mode cloud, vous bénéficiez automatiquement des mises à jour d’infrastructure sans le voir. La société a fait ses preuves en termes de fiabilité du service. Par exemple, il est rare d’entendre que “ZeroTier est en panne globale” – leur réseau est distribué, redondant. Évidemment, une dépendance existe : si demain l’entreprise arrête, vos réseaux disparaissent (vous pourriez alors passer en self-hosting, mais ce serait une transition à gérer). Cependant, la tendance actuelle (rachat par Canonical, intégration dans divers routeurs et appliances) donne confiance dans la pérennité. La communauté utilisateur pourra vous aider sur les forums en cas de question, et ZeroTier Inc fournit documentation et support (le support direct et SLA étant surtout pour les clients Enterprise). Techniquement, la solution étant stable, vous n’aurez probablement pas besoin de beaucoup d’assistance après la phase initiale. Un point annexe : ZeroTier étant open source, il y a un certain gage de transparence sur le fonctionnement, même si en mode cloud le backend précis est propriétaire (ils ne publient pas leur serveur Central complet).

ZeroTier cloud summary: C’est une solution very well-balanced pour les PME qui veulent un VPN overlay flexible avec un minimum de maintenance. Par rapport à Tailscale, ZeroTier cloud offre plus d’options réseau (L2, choix d’adresses, bridging…) mais un tout petit peu moins d’intégration “enterprise” (pas de gestion fine par utilisateurs natifs, pas d’identités multiples – bien que vous puissiez toujours coupler avec d’autres outils). La facilité d’utilisation est excellente même si l’interface web est un peu plus technique. Si votre PME a, par exemple, des besoins spécifiques comme connecter non seulement des PC mais aussi des équipements réseau ou du matériel qui a besoin d’être dans le même sous-réseau virtuel, ZeroTier est idéal. Si vous cherchez avant tout la simplicité pour des utilisateurs nomades, Tailscale est un poil plus user-friendly, mais ZeroTier se défend très bien et reste compréhensible pour peu qu’on prenne une heure pour lire la doc de base. In terms of sovereignty, ZeroTier cloud pose la même question que Tailscale : données de contrôle hors de votre contrôle. Cependant, l’option de migrer vers un self-host plus tard existe, ce qui peut rassurer (on pourrait démarrer en cloud, puis si un jour on veut rapatrier, c’est faisable avec un peu d’effort).

Summary comparison of the five solutions

Maintenant que nous avons passé en revue chaque solution, résumons les points clés de comparaison selon des critères importants pour une PME :

• Architecture and operating model : WireGuard est purement pair-à-pair sans infrastructure à part ce que vous créez vous-même (topologie manuelle). Nebula et ZeroTier sont pair-à-pair avec une coordination : Nebula nécessite de déployer un ou des lighthouses (serveurs de découverte) auto-hébergés, ZeroTier peut s’appuyer soit sur vos propres contrôleurs/roots soit sur ceux du cloud. Tailscale et ZeroTier (cloud) reposent sur une coordination centralisée gérée par le fournisseur (serveurs SaaS) pour orchestrer les pairs, tout en gardant les échanges de données en direct chiffrés entre clients. Une différence notable : ZeroTier opère en mode réseau virtuel Ethernet (L2) tandis que les autres sont orientés IP (L3), mais pour un usage PME classique (accès IP aux services) cela ne change pas grand-chose, sauf si vous avez besoin de fonctionnalités réseau avancées.
• Ease of deployment : Du plus simple au plus technique, on peut classer ainsi :
  • Tailscale : le plus simple, installation en quelques minutes, interface conviviale, pratiquement aucune config réseau à connaître.
  • ZeroTier (cloud) : également très simple, un peu plus “tech” dans l’interface que Tailscale, mais largement abordable. L’approbation manuelle des nœuds peut demander une petite coordination interne.
  • Nebula : intermédiaire – demande de générer des certificats et de configurer des fichiers, mais avec un bon tutoriel on s’en sort. Une fois installé, ça tourne tout seul.
  • WireGuard : technique – configuration manuelle de chaque tunnel, peut convenir pour quelques machines mais devient complexe à grande échelle sans outils additionnels.
  • ZeroTier (auto-hébergé) : technique également – déployer un contrôleur et manipuler l’API n’est pas trivial, c’est une étape de plus par rapport à Nebula. On pourrait dire que c’est le plus exigeant en administration initiale (sauf à souscrire la version Enterprise qui facilite).
• Control and security features :
  • WireGuard offre un contrôle total car vous gérez tout, mais n’a pas de fonctionnalités de sécurité intégrées (pas d’ACL prêtes, pas d’identités utilisateurs). Vous devrez compléter avec d’autres mesures (firewall, etc.). C’est très sûr en chiffrement, mais pas “sécurisé par politique” par défaut.
  • Nebula intègre un pare-feu par identité très puissant. Vous pouvez segmenter finement votre réseau selon des groupes de machines. En revanche, pas d’intégration utilisateur/annuaire directe – c’est plutôt machine-centric.
  • ZeroTier propose des flow rules qui permettent de mettre en place une micro-segmentation similaire (exemple : tel groupe d’IP ne peut pas parler à tel autre). En mode cloud, vous bénéficiez aussi potentiellement du SSO pour accéder à la console admin. En auto-hébergé, c’est vous qui définissez tout. ZeroTier peut s’intégrer à des systèmes existants via son API pour automatiser le contrôle d’accès.
  • Tailscale apporte une gestion par utilisateurs et appareils très fine. On peut utiliser l’SSO pour l’authentification, définir des ACL par utilisateurs/groupes, voir les logs d’accès. C’est probablement celui qui offre le plus de contrôles “haut niveau” tout en étant clé en main, incarnant bien le concept Zero Trust pour PME (minimum de privilèges accordés, revocation facile, etc.).
• Integration and customization :
  • WireGuard peut s’intégrer à peu près n’importe quoi (puisque c’est vous qui le faites) mais n’a pas de fonctionnalités spécifiques d’annuaire ou autres.
  • Nebula and ZeroTier self-hosted nécessitent un peu d’ingénierie si on veut les lier à une gestion d’entreprise (par exemple, écrire un script qui génère un cert Nebula quand un nouvel employé arrive, ou qui appelle l’API ZeroTier quand on met à jour un annuaire). Ils offrent beaucoup de liberté pour personnaliser (open source oblige), mais il faut mettre les mains dedans.
  • Tailscale and ZeroTier cloud fournissent déjà beaucoup : Tailscale a des intégrations prêtes (par ex, on peut connecter Tailscale à Okta ou ActiveDirectory en quelques clics pour importer les groupes utilisateurs). ZeroTier cloud a une API également si vous voulez automatiser l’ajout d’appareils, et on peut lier le compte admin à un SSO pour la gestion.
  • Si besoin d’intégration LDAP/SAML pour la connexion des utilisateurs au VPN : c’est direct avec Tailscale, indirect avec ZeroTier (on peut utiliser SSO pour la console ou une authentification sur l’app client via un script, mais ce n’est pas natif pour la session VPN elle-même, puisqu’il n’y a pas de concept d’utilisateur). Nebula/WireGuard n’ont pas ça du tout en natif.
• Costs and business model :
  • WireGuard, Nebula, ZeroTier (self) : pas de coûts de licence, uniquement des coûts d’hébergement (minimes) et de maintenance humaine. Ce sont des solutions idéales si le budget est très serré mais que le temps/compétences sont disponibles.
  • Tailscale, ZeroTier (cloud) : modèle abonnement. Tailscale par utilisateur (~5$/utilisateur/mois standard), ZeroTier par appareil au-delà de 50 gratuits (~1$ par appareil/mois dans les packs). Pour une PME de 20 personnes par exemple, Tailscale couterait ~100 $/mois, ZeroTier probablement gratuit ou ~30 $/mois selon le nombre d’appareils. Ces coûts incluent le support et l’infrastructure, il faut les voir aussi comme l’économie de ne pas gérer de serveurs VPN ni de temps passé. À noter : pour un usage très faible (quelques utilisateurs), Tailscale peut revenir un peu plus cher que ZeroTier, mais pour plus d’utilisateurs avec plusieurs devices chacun, ça s’équilibre ou avantage Tailscale. En tout cas, les deux sont bien moins onéreux que des solutions VPN d’entreprise traditionnelles ou des SD-WAN propriétaires.
• Maturity, stability, community :
  • WireGuard : très stable, standard de facto du VPN moderne, énorme communauté (mais pas de support officiel autre que la communauté).
  • Nebula : éprouvé chez Slack et quelques autres, communauté plus restreinte mais active dans son domaine. Logiciel stable mais qui nécessite un peu de compréhension.
  • ZeroTier : plus de 10 ans d’existence, large base d’utilisateurs, code robuste. Communauté large, et maintenant appui d’une plus grosse entreprise (Canonical) qui peut garantir la continuité. La dualité open source / service pro lui donne une bonne image de fiabilité.
  • Tailscale : plus jeune mais en très forte croissance, communauté enthousiaste (surtout dans le monde dev et startup), beaucoup de contributions (guide, outils open source compatibles). A montré sa fiabilité technique et est construit sur WireGuard qui est solide. Le principal point d’attention est sur la pérennité de l’entreprise (startup), mais elle semble sur la bonne voie avec l’adoption qu’elle connaît.

En fin de compte, chacune de ces solutions a ses strengths :

• WireGuard excelle en performance et minimalisme, parfait pour les administrateurs qui veulent du “fait maison” sans couche superflue.
• Nebula brille par son modèle de sécurité intégrée (certificats, filtrage par groupes) et son indépendance totale, idéal pour un usage sur mesure où l’on veut maîtriser chaque aspect.
• ZeroTier (auto-hébergé) offre une flexibilité quasi infinie (on peut vraiment façonner son réseau comme on l’entend) et garantir que rien ne sort de son infrastructure, ce qui est top pour la souveraineté, au prix d’efforts d’implémentation.
• Tailscale remporte la palme de la simplicité et de l’ergonomie, tout en fournissant les fonctionnalités attendues par une PME moderne (SSO, ACL, mobilité).
• ZeroTier (cloud) apporte un bon compromis entre facilité et richesse fonctionnelle réseau, avec une générosité sur le nombre d’appareils gratuits qui permet de tester largement avant d’engager des frais.

Recommendations

Pour aider à faire un choix, voici quelques recommandations basées sur les profils et besoins des PME :

• For very small businesses (VSBs) or SMBs without a dedicated IT department : Tailscale ressort souvent comme la solution la plus adaptée. Sa facilité d’installation et de gestion signifie que même un dirigeant ou un technophile “amateur” peut le mettre en place. Vous n’avez pas à gérer de serveur, l’interface est claire et l’authentification via Google/Microsoft compte existant simplifie l’onboarding. Par exemple, une startup de 10 employés en full télétravail pourra en une heure donner accès à tout le monde au réseau privé (pour atteindre un NAS, une base de données dans le cloud privé, etc.), sans se soucier des détails techniques. Le coût sera modeste (probablement gratuit ou le plan Team à une trentaine d’euros par mois). Si vous êtes allergique à toute configuration et que la confidentialité des meta-données n’est pas critique pour vous, Tailscale est un excellent choix “plug & play”.
• For SMBs with a small IT team that prefer to avoid foreign SaaS : ZeroTier in cloud mode peut convenir si la préoccupation est surtout financière ou technique plutôt que juridique. En effet, ZeroTier peut fonctionner quasi intégralement gratuitement jusqu’à un certain point, ce qui est intéressant pour une PME de 30-40 personnes max. C’est une solution simple à déployer également, bien qu’un peu plus technique que Tailscale (il faudra gérer les autorisations d’appareils et éventuellement écrire quelques règles de flux). Si la souveraineté des données de contrôle est un souci (par ex. secteur médical ou juridique craignant le CLOUD Act), alors ni Tailscale ni ZeroTier cloud ne seront pleinement satisfaisants – il faudrait considérer l’auto-hébergement. Mais pour une PME standard sans données hyper-sensibles, ZeroTier cloud permet de garder les avantages du mesh VPN sans coûts et avec la possibilité à moyen terme de migrer on-premises si requis. Pensez à ZeroTier cloud si vous avez des besoins réseau un peu spéciaux (ex : connecter deux réseaux locaux ensemble, ou utiliser des protocoles non-IP à travers le VPN) car son approche L2 le rend plus flexible pour ces cas-là.
• For SMBs concerned with sovereignty, in regulated sectors, or with sensitive data : Les solutions open source auto-hébergées prennent tout leur sens. Nebula pourrait être le meilleur compromis dans ce scénario : il a été conçu pour la sécurité et la performance, et vous gardez tout le contrôle (vos serveurs lighthouses sont chez vous ou dans un cloud de confiance local, les certificats sont gérés en interne). Nebula est approprié si vous disposez d’un administrateur système ou réseau capable de le mettre en œuvre. C’est très bien pour, par exemple, une PME en technologie industrielle ou en finance qui doit absolument cloisonner ses accès : Nebula vous donne la garantie qu’aucun fournisseur tiers ne peut ajouter un nœud “caché” ou voir vos machines (une préoccupation soulevée parfois pour les mesh VPN cloud【0†】). Alternativement, si votre équipe maîtrise déjà bien Linux et les réseaux, et que vous voulez bâtir quelque chose de sur-mesure, vous pourriez utiliser WireGuard comme base – soit via un orchestrateur (comme Netmaker ou Netbird) pour retrouver des fonctionnalités de coordination, soit via des scripts maison. WireGuard conviendrait pour un usage plus statique ou simple (par ex., relier 3 sites d’une entreprise de façon permanente). Mais pour un usage multi-utilisateurs nomades avec rotation fréquente, ce sera vite lourd à gérer manuellement.
• For mid-size businesses (50–200 employees) : On sort un peu du cadre PME classique, mais on peut imaginer un scénario où l’on cherche à équiper de nombreux collaborateurs. Dans ce cas, la question de l’échelle et de la gestion centralisée se pose encore plus. Tailscale peut toujours convenir (ses plans payants couvrent ce genre de taille et ils supportent les intégrations d’entreprise comme Okta, ce qui aide pour l’automatisation). ZeroTier cloud commencerait à engendrer un coût non négligeable si on dépasse largement 50 appareils, mais reste abordable comparé à des solutions MPLS ou SD-WAN classiques. Nebula pourrait soutenir 200+ nœuds sans problème technique, mais la gestion des certificats pourrait nécessiter d’automatiser (écrire un petit outil interne par exemple). Il n’existe pas encore de grosse suite commerciale autour de Nebula pour en faciliter l’administration (Defined.net propose peut-être des services sur mesure). L’intégration avec un annuaire sera sans doute cruciale à cette échelle : avantage Tailscale et ZeroTier (via SSO ou API), alors que Nebula/WireGuard demanderaient plus de travail. En somme, pour 100+ utilisateurs, il est probable qu’une solution gérée (Tailscale ou ZeroTier) soit la plus efficace en temps et en fonctionnalités.
• Selon les secteurs d’activité :
  • Dans le technology or software sector, les équipes sont souvent à l’aise avec open source, donc Nebula ou WireGuard peuvent être adoptés facilement, et l’aspect souveraineté/open source peut être un plus philosophique.
  • Dans le manufacturing or logistics sector, où il peut y avoir de l’IoT, des machines, etc., ZeroTier est intéressant car on peut l’embarquer dans divers environnements (par ex. il existe un client ZeroTier pour certaines solutions embarquées) et son côté L2 permet d’intégrer des systèmes peut-être un peu anciens qui ne supporteraient pas un NAT par exemple.
  • Dans le services, consulting, and general SMBs sector, Tailscale est attractif car il réduit la charge sur une éventuelle équipe IT réduite, tout en s’adaptant aux infrastructures cloud hybrides (on peut par exemple mettre un relais Tailscale dans un VPC AWS ou Azure pour y donner accès aux employés sans exposer les ports).
  • For the public or para-public sector in Quebec, la question des données hors Canada peut orienter vers Nebula ou ZeroTier self-host si la politique interne l’impose. Cependant, cela doit être mis en balance avec les moyens disponibles pour le maintenir.

En conclusion, les mesh/overlay VPNs sont en train de devenir un pilier de l’infrastructure des PME modernes, de la même manière que les VPN classiques l’étaient pour les grandes entreprises il y a 15 ans, mais avec la flexibilité et la sécurité adaptées à l’ère du cloud et du télétravail. Chaque solution présentée répond à ces besoins sous un angle différent : du pur open source à faire soi-même jusqu’au service prêt à l’emploi.

Pour faire votre choix, identifiez vos priorités : simplicity and speed of implementation, minimal budget, full control and sovereignty, integration with your existing tools, etc. Il n’y a pas de solution universellement “meilleure” : une petite agence web de 5 personnes n’aura pas la même réponse qu’une entreprise industrielle de 50 salariés manipulant de la propriété intellectuelle sensible. L’important est que vous preniez conscience des enjeux (ne pas laisser vos accès se fragmenter ou se bricoler sans vision d’ensemble) et que vous optiez pour une approche structurée avec l’un de ces outils. Avec un VPN maillé bien choisi, vos employés pourront travailler securely comme s’ils étaient tous au même endroit, et vos données critiques resteront bien à l’abri derrière des murs numériques contrôlés. C’est un investissement qui renforce à la fois la peace of mind de votre équipe informatique et la trust de vos clients/partenaires dans la robustesse de votre entreprise face aux menaces numériques.

Sources and bibliography: 

• Slack Engineering – Introducing Nebula, the open source global overlay network from Slack (2019)

Tailscale – Nebula vs. Tailscale: Which VPN Alternative is Better for You?

Netmaker Blog – Tailscale vs ZeroTier: Comparing Top Overlay VPN Networks (2023)

Opensource.com – How I manage my own virtual network with ZeroTier (2022)

• PME Conforme – Data sovereignty: Is Quebec ready to take back control? (on Bill 25 and the cloud)

Hacker News (discussion) – Be aware, when you use mesh VPN products such as ZeroTier, Nebula or Tailscale… (2021)

(considerations on trust and security of mesh VPNs)