Pourquoi le « strictement sortant » bat le VPN site-à-site

Le VPN site-à-site est la réponse par défaut quand un fournisseur doit atteindre les services internes d’un client. C’est le défaut depuis la fin des années 1990. Il y a de bonnes raisons pour lesquelles c’est devenu le défaut, et il y a de bonnes raisons pour lesquelles c’est le mauvais défaut pour la connectivité opérateur-vers-client en 2026.

Cet essai est le plaidoyer architectural pour remplacer ce défaut par une connectivité strictement sortante. Pas « envisager de remplacer ». Remplacer.

Ce que fait réellement le VPN site-à-site

Un VPN site-à-site établit un tunnel authentifié et chiffré entre deux réseaux. Chaque côté exécute généralement un concentrateur VPN (un appareil matériel ou virtuel) qui termine le tunnel. Le trafic des deux côtés adressé au sous-réseau de l’autre réseau est routé à travers le tunnel et livré comme s’il provenait localement.

Le modèle a une belle symétrie. Les deux réseaux se voient comme s’ils étaient un sous-réseau différent du même réseau interne. La plupart des applications existantes fonctionnent sans modification parce qu’elles pensent parler à une IP locale.

Cette symétrie est aussi la source des problèmes.

Le problème entrant

Les deux extrémités d’un VPN site-à-site écoutent les connexions entrantes. La négociation IKE, les paquets IPSec ESP, le re-clavage — tout cela exige des écouteurs entrants sur les concentrateurs. Les concentrateurs sont exposés à l’internet public sur UDP/500 et UDP/4500.

Cela signifie que chaque déploiement de VPN site-à-site ajoute une surface d’attaque entrante aux deux réseaux. La surface d’attaque est petite, les protocoles sont bien testés, et en pratique les exploits contre les piles modernes IKE/IPSec sont rares. Mais l’exposition est réelle, et l’équipe de sécurité du client doit en tenir compte dans son registre des risques, son modèle de menaces et sa configuration de surveillance continue.

Quand le fournisseur dit « nous avons besoin d’un VPN site-à-site », l’équipe réseau du client entend « nous avons besoin d’ajouter une surface d’attaque à notre périmètre pour un fournisseur spécifique ». C’est ce qu’elle accepte. La décision est, à juste titre, lente et politique.

Le problème de mouvement latéral

Une fois qu’un VPN site-à-site est en place, le réseau du fournisseur est à une décision de routage IP du réseau du client. Les serveurs du fournisseur peuvent atteindre les serveurs du client. Par défaut, cette joignabilité est large — chaque IP du sous-réseau du fournisseur peut parler à chaque IP du sous-réseau du client. Les ACL réduisent ceci, mais les ACL sont de la configuration, et la configuration dérive.

En pratique, chaque déploiement de VPN site-à-site entre fournisseur et client est accompagné d’une longue discussion sur les ACL. Le résultat est généralement trop large à la première itération (parce que le coût opérationnel d’être trop étroit est concret et le coût sécurité d’être trop large est hypothétique). La dérive s’accumule avec le temps.

C’est ainsi que les fournisseurs se retrouvent dans les analyses post-incident des clients même quand le fournisseur n’est pas le vecteur d’incident original — parce qu’une fois que l’attaquant est sur le réseau du client, le tunnel S2S est un chemin vers les systèmes connexes.

Ce que change le strictement sortant

La connectivité strictement sortante inverse la topologie. Le côté client ouvre une connexion vers l’extérieur vers le côté fournisseur. Il n’y a pas d’écouteurs entrants côté client. Aucune surface d’attaque entrante n’est ajoutée au périmètre du client.

Le côté fournisseur a des écouteurs entrants — mais le fournisseur est l’opérateur et l’écouteur entrant concerne un service connu exécutant un code connu sous le contrôle opérationnel du fournisseur. Le registre des risques du client ne gagne pas d’entrée. Le modèle de menaces du client est inchangé.

Le mouvement latéral devient contraint par le protocole applicatif. La connexion sortante n’est pas un chemin réseau routé ; c’est un canal de couche applicative. Le fournisseur ne peut pas scanner le sous-réseau du client depuis l’autre extrémité de la connexion. Le fournisseur peut seulement faire ce que le protocole applicatif au-dessus de la connexion permet.

Ce que cela signifie en pratique

Si vous concevez la connectivité opérateur-vers-client pour un produit IA ou SaaS, ne commencez pas par « le client doit ouvrir un tunnel vers nous ». Commencez par « nous expédierons un composant Client qui s’exécute dans l’environnement du client et ouvre une connexion sortante ». Construisez tout le reste par-dessus.

L’argument architectural pour le strictement sortant est suffisamment fort pour qu’il soit devenu le défaut moderne pour les nouveaux déploiements à grande échelle (Cloudflare Tunnel, le routage de sous-réseau Tailscale dans certaines configurations, BeyondCorp, le modèle Hub-Client d’Ewii). La question restante n’est pas si faire le changement. C’est quel produit strictement sortant convient à votre forme opérationnelle spécifique — et c’est une question à laquelle les pages de comparaison et la revue d’architecture existent pour répondre.