Le tissu multi-cloud du pauvre : réduire la facture d’égress avec Mesh Tunneling en 2026

Les fournisseurs cloud ont transformé l’égress des données en l’un des mécanismes de verrouillage les plus efficaces de l’histoire des logiciels d’entreprise. Les coûts sont délibérément punissants : en 2026, AWS facture 0,09 $ par GB pour l’égress Internet standard, Azure 0,087 $ par GB, et GCP 0,12 $ par GB pour le premier téraoctet — GCP doublant ses tarifs CDN Interconnect et peering en Amérique du Nord à partir du 1er mai 2026. Une analyse CloudZero de 2025 a révélé que le transfert de données représente 6 à 12 % des factures cloud typiques, mais la plupart des équipes d’ingénierie ne peuvent pas identifier où leur dépense d’égress est concentrée jusqu’à ce qu’une crise survienne. Avec 100 To sur AWS, déplacer simplement ces données ailleurs coûte 8 700 $ en egress avant que votre nouveau fournisseur ne gagne un dollar.

Il existe une solution. En construisant un réseau mesh crypté peer-to-peer entre clouds, les équipes d’ingénierie peuvent router le trafic inter-cloud via des tunnels overlay définis par logiciel qui contournent ou minimisent considérablement la surface de mesure des passerelles Internet standard. Ce n’est pas une astuce théorique — c’est l’architecture qui alimente les startups lean multi-cloud qui n’ont pas l’intention de payer des prix d’interconnexion d’entreprise.

---

Pourquoi les VPN traditionnels sont la mauvaise solution

Dans une architecture VPN site-à-site conventionnelle, chaque paquet entre deux réseaux doit passer par une passerelle centralisée de chaque côté. Si une charge de travail sur AWS EC2 doit atteindre une base de données sur GCP Compute Engine, ce paquet voyage jusqu’à la VPN Gateway AWS, traverse Internet public pour atteindre la VPN Gateway GCP, puis est routé vers la cible. Cette topologie hub-and-spoke crée un point de congestion qui introduit de la latence, concentre le risque de défaillance, et — surtout — fait passer chaque octet par le moteur de mesure de l’hyperscaler.

Un réseau mesh peer-to-peer élimine complètement le hub. Lorsqu’un daemon de tunneling léger fonctionne directement sur des machines virtuelles ou des hôtes de conteneurs dans différents clouds, les nœuds négocient des tunnels directs cryptés point-à-point entre eux. Le résultat est un sous-réseau privé virtuel unique et plat — généralement le bloc NAT Carrier-Grade 100.64.0.0/10 réservé par l’IANA — qui couvre tous les environnements connectés. Du point de vue d’une application tournant sur AWS, un cluster de bases de données dans GCP semble être sur le même switch local, accessible via une IP privée standard.

[ VPC AWS ]                         [ VPC GCP ]
+--------------------+               +--------------------+
|  +--------------+  |               |  +--------------+  |
|  | EC2 Node A   |==|===============|==| GCE Node B   |  |
|  | 100.64.1.1   |  |  WireGuard    |  | 100.64.2.1   |  |
|  +--------------+  |  P2P Tunnel   |  +--------------+  |
+---------||----------+               +---------||----------+
          ||                                    ||
          ||         +------------------+       ||
          \==========| On-Prem / Bare   |=======/
                     | Metal Node C     |
                     | 100.64.3.1       |
                     +------------------+
                       [ Rack Physique ]

---

Les protocoles derrière le Mesh

WireGuard : le moteur cryptographique

Pratiquement toutes les solutions modernes de tunneling mesh utilisent WireGuard comme protocole de data-plane. WireGuard a remplacé les protocoles legacy comme IPsec et OpenVPN en opérant entièrement dans l’espace noyau Linux — ou via des implémentations hautement optimisées en espace utilisateur — en utilisant une cryptographie moderne : ChaCha20 pour le chiffrement symétrique, Poly1305 pour l’authentification, et Curve25519 pour l’échange de clés. Son architecture sans connexion UDP signifie qu’il ne maintient pas une poignée de main bavarde lorsqu’il est inactif, ce qui réduit la consommation mémoire et la surcharge CPU.

Les chiffres de performance sont significatifs. Des benchmarks indépendants sur du matériel AMD EPYC 9654, publiés par Phoronix, ont montré que WireGuard en mode noyau atteignait environ 7,5 à 8,0 Gbps de débit TCP en flux unique avec environ 15 % de CPU en moins que les alternatives en espace utilisateur. OpenVPN plafonne à environ 1,1 Gbps sur le même matériel. IPsec via strongSwan atteignait 6,8 Gbps mais consommait environ 30 % de CPU en plus que WireGuard à pleine capacité.

WireGuard n’a pas de faiblesse cryptographique connue à la mi-2026. Une revue de Quarkslab en 2018 et des analyses académiques ultérieures n’ont trouvé aucune vulnérabilité dans le protocole. Le choix entre WireGuard et les couches de gestion qui s’y appuient est opérationnel, pas basé sur la sécurité.

Tailscale : couche de coordination zéro-config

Tailscale construit une couche de contrôle gérée au-dessus de WireGuard, automatisant l’échange de clés, la découverte de pairs, et la traversée NAT que WireGuard laisse volontairement à l’opérateur. Chaque connexion Tailscale est un tunnel WireGuard standard au niveau transport — les caractéristiques de chiffrement et de data-plane sont identiques. Ce que Tailscale ajoute, c’est un serveur de coordination qui distribue les clés publiques et les métadonnées d’endpoint à tous les nœuds du tailnet.

Fonctionnalités clés pour les déploiements multi-cloud :

Traversée NAT via STUN/ICE. Les VPC cloud cachent les machines virtuelles derrière des NAT multi-couches. Tailscale utilise STUN (Session Traversal Utilities for NAT) pour découvrir les ports publics de chaque nœud, permettant des connexions P2P directes même à travers des pare-feux d’entreprise restrictifs. Les connexions peer-to-peer directes ajoutent environ 1 ms de latence par rapport à une baseline non cryptée.

Relais DERP en mode fallback. En cas de blocage complet des UDP directs par les pare-feux, Tailscale bascule sur son réseau mondial de serveurs Relais Cryptés pour Paquets (DERP), garantissant la connectivité pendant que le système tente de rétablir un chemin direct. Les connexions relayées DERP ajoutent 10 à 50 ms selon la proximité du serveur relais.

Routeurs de sous-réseaux. Plutôt que d’installer l’agent Tailscale sur chaque conteneur ou serveur, les ingénieurs désignent une petite VM dans chaque VPC comme un Routeur de Sous-Réseau. Ce nœud annonce le bloc CIDR interne de son VPC hôte (par exemple, 10.100.0.0/16) au reste du mesh tailnet, permettant aux ressources non gérées de communiquer à travers la fabric sans agents supplémentaires.

Verrouillage du Tailnet. Depuis début 2026, la version Entreprise de Tailscale supporte le Lock du Tailnet, qui nécessite une autorisation multi-parties avant qu’un nouveau device ne soit admis dans le mesh — atténuant le risque d’un serveur de coordination compromis. Trail of Bits a audité Tailscale en 2024 et Doyensec en 2025 ; tous deux n’ont trouvé aucune vulnérabilité critique.

Les benchmarks de débit sur du matériel Linux identique montrent Tailscale atteindre environ 6,8 Gbps pour des connexions point-à-point directes avec WireGuard en espace utilisateur, dépassant 10 Gbps avec des optimisations kernel via segmentation UDP. Pour des charges microservices et bases de données, la différence de débit par rapport à WireGuard brut est négligeable une fois la fenêtre TCP activée.

Les prix Tailscale en 2026 sont de 6 $ par utilisateur actif par mois en plan Starter, jusqu’à 18 $ pour le plan Premium avec SSO avancé et ACL. La version gratuite couvre jusqu’à 3 utilisateurs et 100 appareils, suffisante pour la plupart des déploiements homelab et startups à deux.

Alternative auto-hébergée : Headscale. Pour les équipes avec des exigences strictes de souveraineté des données, Headscale est une alternative open-source à Headscale, un serveur de coordination Tailscale. Les appareils utilisent toujours le client officiel Tailscale mais pointent vers une instance Headscale sur votre infrastructure. La distribution des clés, la découverte de pairs, et l’application des ACL se font entièrement sur du matériel contrôlé par vous. La dernière version, début 2026, est la v0.26.1.

Nebula : Mesh d’entreprise décentralisé

Initialement développé par Slack et publié en open-source, Nebula est conçu spécifiquement pour des déploiements d’infrastructure massifs sans dépendre d’un plan de contrôle géré par un fournisseur. À la place, il utilise des orchestrateurs auto-hébergés appelés Lighthouses.

Découverte décentralisée. Les nœuds Nebula enregistrent leurs adresses IP internes et externes auprès d’un Lighthouse — une VM bon marché avec une IP publique statique. Lorsqu’un nœud A veut se connecter à un nœud B, il demande au Lighthouse les coordonnées actuelles de B, établit un tunnel crypté direct, puis communique entièrement indépendamment du Lighthouse. Ce dernier sert uniquement de bootstrap de coordination, pas de relai de trafic.

Identité basée sur certificat. Nebula utilise un modèle PKI strict. Chaque nœud doit recevoir un certificat cryptographique signé par une Autorité de Certification interne privée. Les certificats dictent non seulement l’IP du nœud dans la mesh, mais aussi ses groupes de sécurité, tags d’environnement, et règles de pare-feu. Nebula utilise AES-256-GCM pour le chiffrement symétrique (comparé à ChaCha20 dans les solutions WireGuard) et le Noise Protocol Framework pour l’échange de clés.

Politiques de pare-feu natives. Nebula gère ses règles de pare-feu dans son daemon en espace utilisateur, permettant aux opérateurs de définir des politiques d’entrée et de sortie granulaires basées sur les propriétés des nœuds — par exemple, autoriser uniquement les nœuds tagués gcp-ai-worker à atteindre ceux tagués aws-rds-replica.

Pour une note de sécurité pratique : Nebula ne supporte pas encore SSO ni gestion utilisateur native. L’accès aux nœuds est entièrement géré via l’émission de certificats. Les groupes servent à segmenter les machines plutôt qu’à gérer des identités utilisateur. Les équipes nécessitant une intégration SAML ou OIDC devraient privilégier Tailscale ou NetBird.

NetBird et Netmaker : plans de contrôle open-source

Pour les équipes souhaitant la convivialité de Tailscale avec une souveraineté totale des données auto-hébergée, NetBird et Netmaker ont gagné en popularité. Ils offrent des consoles de gestion open-source avec UI web, une intégration avec des fournisseurs d’identité via OAuth2 et OIDC, et supportent des configurations WireGuard natives au noyau. NetBird exploite également eBPF pour un routage de paquets à la vitesse du line-rate. En 2026, NetBird utilise Go 1.23, ce qui améliore d’environ 18 % le débit dans des scénarios à forte concurrence grâce à des améliorations dans la planification des goroutines et la gestion mémoire.

---

Plan architectural : construire un mesh privé multi-cloud

Pour déployer un tissu résilient, rentable, entre AWS, GCP, et infrastructure on-premise, suivez ce modèle.

              +------------------------------------------------+
              |        PLAN DE CONTRÔLE / LIGHTHOUSE          |
              |     (Distribution de clés & découverte)       |
              +-------------------+----------------------------+
                                  |
         +------------------------+------------------------+
         |                        |                        |
+--------v--------+    +----------v------+    +------------v----+
|   VPC AWS      |    |   VPC GCP      |    | RACK ON-PREMISES |
|   10.100.0/16  |    |   10.200.0/16  |    |   192.168.1/24  |
|                |    |                |    |                |
| [Routeur de  |<--->| [Routeur de  |<--->| [Bare-Metal]   |
| sous-réseau] |    | sous-réseau] |    |                |
| IP overlay : |    | IP overlay : |    | IP overlay : |
|  100.64.1.1  |    |  100.64.2.1  |    |  100.64.3.1  |
+--------------+    +--------------+    +--------------+
    Tunnels P2P WireGuard UDP cryptés, NAT-traversés

Étape 1 : Isolation CIDR — Faites-le bien dès le départ

Avant de déployer un agent mesh, assurez-vous qu’aucun environnement n’a de chevauchement d’espace IP privé. Les sous-réseaux en chevauchement causent une corruption des tables de routage que aucun logiciel mesh ne peut corriger.

Environnement	CIDR recommandé
VPC AWS	10.100.0.0/16
VPC GCP	10.200.0.0/16
On-Prem / Bureau	192.168.1.0/24
Mesh overlay (tailnet)	100.64.0.0/10

Le bloc 100.64.0.0/10 est la plage NAT Carrier-Grade de l’IANA, réservée à cette utilisation privée overlay. Il évite les conflits avec les blocs RFC 1918 utilisés par la plupart des VPC cloud.

Étape 2 : Déployer des nœuds de passerelle mesh redondants

Plutôt que de faire fonctionner un daemon de tunneling sur chaque conteneur — ce qui complexifie la configuration et consomme de la mémoire — déployez des instances de passerelle dédiées dans chaque environnement.

1. Lancez deux instances optimisées pour le calcul dans le sous-réseau public de chaque cloud. Un c6i.large AWS et un c3-standard-2 GCP conviennent comme points d’entrée. Faites-en deux dans chaque environnement pour la haute disponibilité.
2. Activez le transfert IP au niveau de l’infrastructure. Sur AWS, désactivez explicitement l’attribut Source/Destination Check sur l’interface réseau Elastic Network Interface (ENI). Sur GCP, cochez la case can_ip_forward lors de la création de l’instance.
3. Installez votre daemon mesh choisi sur ces instances de passerelle.

Étape 3 : Configurer les annonces de routage

Une fois les daemons authentifiés et connectés à l’overlay, configurez chaque passerelle pour annoncer le CIDR de son cloud au reste du mesh.

Sur le nœud de passerelle AWS :

tailscale up --advertise-routes=10.100.0.0/16 --accept-routes

Sur le nœud de passerelle GCP :

tailscale up --advertise-routes=10.200.0.0/16 --accept-routes

Le plan de contrôle synchronise ces annonces entre tous les nœuds connectés. Chaque pair sait maintenant que les paquets destinés à 10.200.0.0/16 doivent être encapsulés et tunnélés vers l’IP overlay de la passerelle GCP.

Étape 4 : Mettre à jour les tables de routage VPC cloud

L’étape finale connecte la couche réseau native du cloud au tissu overlay. Les instances classiques — ignorantes du mesh — doivent savoir où envoyer le trafic inter-cloud.

Table de routage AWS : Ajoutez une route statique avec Destination 10.200.0.0/16 (sous-réseau GCP) et Target sur l’ID ENI de la passerelle mesh AWS locale.

Routes VPC GCP : Ajoutez une route avec Destination 10.100.0.0/16 (sous-réseau AWS) et Next Hop sur la VM passerelle GCP.

Une fois appliqué, un paquet d’un conteneur AWS destiné à une API GCP traverse la tableau de routage AWS, est encapsulé dans un paquet UDP WireGuard, traverse Internet, est décapsulé à la passerelle GCP, et arrive à l’instance cible — entièrement sur un espace IP privé.

---

L’économie : d’où viennent les économies

Le cas financier dépend de la façon dont les hyperscalers mesurent le trafic entre interfaces.

Egress Internet standard (AWS 0,09 $/GB, GCP 0,12 $/GB) n’a pas de coûts fixes ni de frais de port, mais facture par octet sortant vers Internet.

Interconnexions dédiées comme AWS Direct Connect réduisent l’eGress par GB à environ 0,02 $, mais ont un coût fixe de 0,03 $/heure pour une connexion 1 Gbps, ce qui ne devient rentable qu’au-delà d’environ 5 To de sortie mensuelle — où les économies par GB dépassent les frais fixes. Une startup transférant moins paie plus via Direct Connect que via l’eGress Internet standard, une fois les frais de port inclus.

L’approche overlay envoie le trafic via UDP standard Internet tout en offrant plusieurs avantages :

• Compression au niveau de la passerelle. La compression Zstandard appliquée avant l’encapsulation WireGuard réduit la taille des données brutes avant qu’elles n’atteignent le moteur de mesure de l’hyperscaler. Les économies réelles dépendent de la compressibilité des données, mais les logs froids et les payloads JSON se compressent souvent 4:1 ou mieux.
• Intermédiaires zéro-eGress. Cloudflare R2 facture 0 $ pour l’eGress. Les opérateurs peuvent positionner des proxies de routage ou des caches d’objets dans des environnements zéro-eGress. Le mesh route automatiquement le trafic via ces middleboxes, abstrait la complexité du routage de la logique applicative.
• Planification hors-heure de pointe. Les transferts de données en masse — sauvegardes de bases, checkpoints de modèles, archives de logs — peuvent être routés via des nœuds on-premise avec une bande passante symétrique ou bon marché pendant les heures creuses. Un nœud de rebond dans un rack physique avec une bande passante montante généreuse évite totalement le coût d’eGress cloud pour ce trafic.
• Augmentation des tarifs GCP en mai 2026. Google Cloud a doublé ses tarifs CDN Interconnect et Peering Direct en Amérique du Nord au 1er mai 2026. Les équipes utilisant déjà des fabrics overlay sont protégées contre cette hausse ; celles utilisant le routage via CDN eGress voient leur facture passer de 2 800 $ à 4 000 $ par mois pour des workloads de 50 To. L’architecture mesh offre une stabilité des coûts d’eGress que les ajustements tarifaires des hyperscalers ne peuvent pas remettre en cause unilatéralement.

---

Guide d’implémentation : Nebula sur Bare Metal

Pour une implémentation open-source, sans dépendance, Nebula fournit un mesh multi-cloud complet sans plan de contrôle vendor. Voici un plan de configuration pratique.

Générer l’Autorité de Certification

Sur une machine hors ligne sécurisée, initialisez le PKI :

nebula-cert ca -name "VotreOrg-MultiCloud-Mesh"

Cela génère ca.crt (distribué publiquement à tous les nœuds) et ca.key (strictement hors ligne et secret).

Signer les certificats des nœuds

Émettez des certificats pour chaque passerelle, en assignant des IP overlay statiques :

# Passerelle AWS
nebula-cert sign -name "aws-gateway" -ip "172.16.1.1/16" -groups "routers,aws"

# Passerelle GCP
nebula-cert sign -name "gcp-gateway" -ip "172.16.2.1/16" -groups "routers,gcp"

# Nœud on-prem
nebula-cert sign -name "onprem-node" -ip "172.16.3.1/16" -groups "routers,onprem"

Configuration de la passerelle AWS (/etc/nebula/config.yaml)

pki:
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/aws-gateway.crt
  key: /etc/nebula/aws-gateway.key

static_host_map:
  "172.16.0.1": ["<votre-ip-lighthouse-publique>:4242"]

lighthouse:
  am_lighthouse: false
  interval: 10
  hosts:
    - "172.16.0.1"

listen:
  host: 0.0.0.0
  port: 4242

tun:
  dev: nebula1
  drop_local_broadcast: true
  drop_multicast: false
  tx_queue_len: 500
  mtu: 1300    # Réduit pour accueillir les headers d’encapsulation

firewall:
  conntrust: true

  inbound:
    - port: any
      proto: any
      group: routers    # Autorise tous les routers mesh vérifiés

  outbound:
    - port: any
      proto: any

Une fois le service Nebula lancé via systemd (systemctl start nebula), les passerelles effectuent une poignée de main cryptographique P2P et établissent le tunnel inter-cloud sans dépendance continue au Lighthouse pour le data-plane.

---

Les compromis de performance à connaître

Débit noyau vs. espace utilisateur

Le débit de votre mesh dépend fortement de si le daemon de tunneling traite les paquets en espace noyau ou utilisateur. Le routage traditionnel avec iptables et l’analyse en espace utilisateur peuvent réduire le débit total de 60 à 70 % sous charge réseau élevée et concurrente.

Les implémentations eBPF éliminent cette surcharge. Le data path eBPF de Cilium — adopté en 2025 par AWS EKS comme CNI par défaut — offre 30 à 40 % de débit en plus que le routage iptables traditionnel en contournant la pile réseau standard et en traitant directement les paquets encapsulés au niveau du driver d’interface réseau. Les benchmarks Cilium montrent que les solutions eBPF surpassent même les mesures de référence node-to-node sur kernels modernes, car eBPF évite la couche iptables que le baseline traverse encore.

Pour WireGuard en mode noyau, le plafond pratique sur le matériel serveur actuel est d’environ 7,5 à 8,0 Gbps. Pour les implémentations en espace utilisateur (incluant la configuration par défaut de Tailscale), le débit est d’environ 6,8 Gbps en point-à-point, dépassant 10 Gbps avec des optimisations kernel et segmentation UDP activée sur Linux.

La limitation MTU n’est pas optionnelle

Ethernet standard a un MTU de 1500 octets. Les headers d’encapsulation WireGuard et Nebula consomment 40 à 80 octets, donc une trame payload de 1500 octets ne peut pas rentrer dans un paquet encapsulé. Sans ajustement MTU, la passerelle fragmentera chaque paquet volumineux, causant latence accrue, perte de paquets, et surcharge CPU.

La solution est MTU clamping à la passerelle : forcer TCP à négocier une taille MSS maximale laissant de la place pour les headers d’encapsulation. La plage sûre est généralement de 1280 à 1420 octets. Dans Nebula, définissez mtu: 1300 dans la section tun comme montré ci-dessus. Sur Tailscale, cela est géré automatiquement.

La latence et le jitter

Un tunnel mesh sur Internet public ne garantit pas la latence d’un circuit fibre dédié. Les paquets traversent le backbone ISP global, ce qui signifie que les temps de ping de base sont légèrement plus élevés et que le jitter (variabilité de la latence) est plus important qu’un lien Direct Connect ou Cloud Interconnect.

Pour des charges synchrones à très faible latence — trading haute fréquence, moteurs de cache distribués en temps réel — l’underlay Internet public peut être insuffisant. Pour les API microservices, queues de messages, réplicas de bases de données asynchrones, transferts de données ML, et pipelines de logs, la différence de latence est négligeable pour l’expérience utilisateur. L’overhead de 1 ms d’un tunnel WireGuard peer-to-peer est insignifiant par rapport au temps de traitement d’une application typique.

Considérations sur le modèle de confiance

L’utilisation de solutions mesh gérées modifie la frontière de confiance. Avec WireGuard brut, vous faites confiance au noyau Linux et à votre propre distribution de clés. Avec Tailscale, vous faites aussi confiance au serveur de coordination fermé de Tailscale. Tailscale atténue cela avec le Lock du Tailnet (exige une autorisation multi-parties) et des mécanismes de transparence des clés publiques. Les équipes avec des exigences strictes de zero-trust ou conformité devraient évaluer Headscale, Nebula, ou NetBird, où l’infrastructure de coordination fonctionne entièrement sur du matériel contrôlé par l’opérateur.

---

Choisir le bon outil : un cadre de décision

Exigence	Outil recommandé
Mise en place rapide, plan de contrôle géré acceptable	Tailscale
UX gérée + plan de contrôle auto-hébergé complet	Headscale (client Tailscale + serveur auto-hébergé)
Open-source, pas de dépendance fournisseur, PKI-native	Nebula
Open-source avec UI web + SSO	NetBird
Kubernetes-native, performance eBPF	Cilium avec chiffrement WireGuard
Entreprise, WireGuard noyau + gestion avancée	Netmaker

---

Conclusion

La combinaison des coûts d’eGress cloud — 0,09 $/GB sur AWS, 0,12 $/GB sur GCP avec des hausses en cours — et la maturité des protocoles mesh open-source a fait du tissu multi-cloud défini par logiciel le choix architectural évident pour les équipes lean en 2026. Le plafond de débit en mode noyau de WireGuard (7,5 à 8,0 Gbps), l’automatisation NAT de Tailscale, le modèle d’identité basé sur certificats de Nebula, et la capacité d’eBPF à contourner la surcharge iptables donnent aux petites équipes des primitives réseau qui nécessitaient auparavant du matériel d’entreprise dédié et des contrats d’interconnexion à six chiffres.

L’effort d’implémentation est réel : la planification CIDR doit être faite avant le déploiement, le MTU doit être ajusté, et les équipes doivent faire des choix délibérés sur leur modèle de confiance. Mais aucun de ces éléments ne requiert des ressources réseau spécialisées. Une équipe d’infrastructure de deux personnes peut déployer un mesh multi-cloud de niveau production en une après-midi et commencer à router du trafic entre AWS, GCP, et bare metal on-premise via des tunnels P2P cryptés — en ne payant que pour le calcul des nœuds de passerelle.

Dans l’environnement actuel de coûts d’eGress, cela ne représente pas seulement une optimisation de coûts. C’est une souveraineté d’infrastructure.

---

Tous les chiffres de coûts d’eGress ont été vérifiés contre la documentation officielle d’AWS, GCP, Azure et des sources indépendantes en mai 2026. Les benchmarks de débit WireGuard proviennent de l’évaluation Linux VPN de Phoronix sur du matériel AMD EPYC 9654. Les audits Tailscale de Trail of Bits (2024) et Doyensec (2025) sont issus de rapports publiés.