Site to site VPN WireGuard : relier deux agences d’une PME sans boîtie
Relier deux sites d'une PME en VPN permanent avec WireGuard : routage, matériel réel et supervision, sans boîtier propriétaire coûteux.
Deux agences, un seul réseau partagé : c’est la demande qui revient depuis que le télétravail a poussé les PME à ouvrir leurs accès à distance. Un VPN pour un salarié isolé, on sait faire. Relier en permanence deux bureaux entiers, c’est une autre affaire. On a déjà détaillé monter son propre VPN sur un petit serveur pour un poste nomade. Ici, on monte un cran : le site to site.
Pourquoi un site to site VPN change la donne face au VPN d’un seul salarié
Un VPN classique connecte un poste au réseau de l’entreprise. L’utilisateur lance un client, entre ses identifiants, et sa machine rejoint le réseau distant. Le trafic passe par un seul chemin, celui de son ordinateur.
Un site to site VPN fait autre chose : il relie deux réseaux entiers, en permanence, sans que personne n’ait à se connecter. Le routeur de l’agence de Lyon parle directement au routeur de l’agence de Nantes. Toutes les machines des deux côtés se voient comme si elles étaient sur le même réseau local.
La différence se joue au niveau de la responsabilité. Sur un VPN poste à poste, chaque salarié gère sa connexion. Sur un site to site, le tunnel tourne tout seul, jour et nuit, et personne ne doit y penser. C’est exactement ce qui en fait un outil pour une imprimante réseau partagée entre deux sites, un serveur de fichiers accédé des deux côtés, ou un logiciel de gestion commerciale qui doit voir la même base partout.
WireGuard entre deux routeurs : ce qu’il faut régler avant d’annoncer que ça marche
WireGuard simplifie beaucoup de choses par rapport à IPsec ou à OpenVPN. Sa configuration tient dans un fichier de quelques lignes, par interface. Mais un tunnel entre deux sites pose trois questions qu’un VPN poste à poste n’a pas.
D’abord, le routage. Chaque site doit savoir que le réseau de l’autre passe par le tunnel, et pas ailleurs. Une ligne de route mal écrite, et le trafic part dans le vide ou revient en boucle.
Ensuite, l’adressage. Si les deux agences utilisent le même plan d’adresses (192.168.1.0/24 des deux côtés, ce qui arrive plus souvent qu’on ne le croit avec des box grand public), le tunnel ne peut pas distinguer les machines. Il faut changer l’un des deux réseaux avant de brancher quoi que ce soit.
Enfin, la permanence. Un poste nomade se déconnecte le soir, personne ne s’en rend compte. Un lien site to site qui tombe à 9h un lundi matin, c’est toute une agence qui perd l’accès au serveur de fichiers de l’autre. Je vérifie toujours comment le tunnel se relance seul après une coupure internet avant de dire qu’un montage est prêt. Un fichier WireGuard qui ne redémarre pas automatiquement au boot, c’est un lien qui ne revient pas tout seul après une panne de courant chez le fournisseur.
Site to site VPN WireGuard : la demande en chiffres
10 recherches par mois
pour la requête « site to site vpn wireguard » : un montage encore peu documenté en français, alors que la demande des PME avec deux sites physiques est bien réelle.
Le matériel réel : deux boîtiers ou deux VPS, le temps que ça prend vraiment
Pas besoin de pare-feu propriétaire à 2 000 €. WireGuard tourne sur un Raspberry Pi, une petite carte réseau sous Linux, ou un VPS loué quelques euros par mois, un de chaque côté du tunnel si les deux agences n’ont pas d’IP fixe.
Le temps de réglage réel, pour quelqu’un qui connaît un minimum Linux : une demi-journée pour un premier montage entre deux sites, en comptant les tests de routage et la vérification que les deux réseaux se voient bien dans les deux sens. Pas deux heures, comme certains comparatifs le laissent croire. Le routage mal pensé est justement ce qui fait traîner un montage qui semblait simple sur le papier.

Pour qui gère déjà des services conteneurisés sur ses serveurs, la logique est la même qu’ailleurs : on ne branche rien sans pouvoir surveiller ce qui tourne derrière. Un tunnel VPN n’est qu’un service de plus à garder sous l’œil.
Sauvegardes et accès distants : ce que ce tunnel protège au quotidien
Le cas le plus courant chez une PME à deux sites : le serveur de sauvegarde est installé dans une seule agence, et l’autre doit pouvoir y envoyer ses fichiers chaque nuit, sans passer par internet en clair.
Le site to site VPN résout ça sans complexité ajoutée côté utilisateur. La sauvegarde part comme si le serveur était sur le réseau local, chiffrée de bout en bout par WireGuard. On a déjà détaillé comment sécuriser des sauvegardes envoyées à distance : le tunnel site to site en est une version pour deux locaux physiques plutôt que pour un cloud public.
Un abonnement VPN cloud à 15 € par mois ne remplace pas ce montage quand les deux sites échangent des volumes de données réguliers : la facture de bande passante chez un prestataire tiers grimpe vite, alors qu’un tunnel WireGuard entre deux VPS à 5 € par mois chacun ne coûte rien de plus au-delà du matériel initial.
Superviser le tunnel : ce qu’affiche un lien coupé et comment le voir avant les salariés
WireGuard ne prévient personne quand il tombe. La commande wg show affiche la dernière poignée de main (handshake) : si elle date de plus de deux minutes, le tunnel ne passe plus de trafic, même si l’interface semble active.
Un script cron qui vérifie ce handshake toutes les cinq minutes et envoie une alerte par mail coûte dix lignes de bash. Sans lui, c’est souvent un salarié qui prévient en premier que le serveur de l’autre agence ne répond plus, et c’est déjà trop tard dans la journée.
Le dernier conseil, celui qui compte vraiment : testez la coupure vous-même, un vendredi soir plutôt qu’un lundi matin. Débranchez un câble, regardez combien de temps le tunnel met à revenir seul. C’est ce test, et pas la configuration initiale, qui dit si le montage est prêt pour deux sites qui en dépendent chaque jour.
Faut-il un boîtier physique dédié à chaque site ?
Non. Un petit serveur Linux existant, ou un VPS loué, suffit pour faire tourner l’interface WireGuard. Le boîtier dédié n’apporte rien de plus pour deux sites, sauf si l’un des deux n’a aucune machine Linux disponible.
Que se passe-t-il si les deux sites ont la même plage d’adresses IP ?
Le tunnel ne peut pas router correctement le trafic : les deux réseaux se confondent. Il faut changer le plan d’adresses d’un des deux sites avant de monter le VPN, pas après.

Victor couvre les serveurs, la cybersécurité et l’automatisation. Il indique la version testée de chaque outil et ce qu’une installation demande vraiment en temps et en compétences.
Publié le 23/10/2026 mis à jour le 23/10/2026