Compression du trafic VPN : quand elle accélère et quand elle casse tout. Pratique 2026

Pourquoi compresser le trafic VPN et pourquoi ce sujet fait tant parler

La compression ressemble à un repas gratuit, mais est-ce vraiment le cas ?

On pourrait penser que c’est l’idée parfaite : on active la compression, les paquets sont allégés, la vitesse augmente, la facture mobile diminue. Génial, non ? Malheureusement, pas toujours. La compression dans un VPN est une lame à double tranchant : dans certains cas, elle fait des miracles, dans d’autres, elle pénalise la vitesse, la batterie du smartphone et même la sécurité. Comment savoir où elle est bénéfique et où elle pose problème ? Décryptons tout ça clairement, sans magie, avec des chiffres honnêtes.

L’idée clé : la compression VPN ne marche que sur des données encore non compressées et non chiffrées au niveau applicatif. En 2026, presque tout le web est en HTTPS et HTTP/3 (QUIC), le contenu média est encodé avec des codecs modernes, et les sauvegardes et logs sont souvent déjà compressés avec zstd. Autrement dit, l’espace pour compresser est limité. Mais il reste plusieurs niches — des protocoles textuels aux charges spécifiques en entreprise — où le VPN peut encore offrir un gain tangible.

Pourquoi le sujet est à nouveau chaud en 2026

La raison est simple : travail hybride, réseaux mobiles 5G/SA, adoption massive de QUIC et explosion de la télémétrie et des logs. Vous pouvez être en route vers la campagne, connecté à Starlink, partager internet depuis un téléphone et envoyer en direct des milliers d’événements JSON. Là, la compression sauve la bande passante ou alors surcharge le processeur. Et en plus, la menace des configurations sécurisées ressurgit à cause d’anciennes attaques toujours actives comme VORACLE. Bref, ce sujet n’est pas juste théorique : il est crucial et concret.

Dilemme fondamental : compresser avant ou après le chiffrement ?

Pour que la compression ait un sens, elle doit se faire avant le chiffrement. Sinon, l’entropie est trop élevée et rien ne se compresse. Le VPN propose justement une compression au niveau du tunnel, avant le chiffrement des paquets. Mais c’est justement cette étape qui ouvre la porte à des attaques comme CRIME, BREACH ou VORACLE — où la taille et le comportement du bloc compressé peuvent « chuchoter » des informations sensibles à un attaquant. La question n’est donc pas de savoir s’il faut activer la compression, mais COMMENT l’activer de manière sélective, sécurisée et consciente.

Comment fonctionne la compression dans les tunnels VPN

Place de la compression dans la pile et impact sur le MTU

La compression dans un VPN classique s’effectue côté client et serveur juste avant le chiffrement et l’encapsulation. Cela signifie que, dès la donnée brute, l’algorithme cherche à éliminer un maximum de redondance. Cependant, la compression modifie la taille des paquets, impactant le MTU réel et le risque de fragmentation. Résultat paradoxal : vous réduisez le volume de trafic, mais vous créez une latence supplémentaire à cause du recalcul MSS et cassez la découverte de MTU en réseau exotique. Conseil simple : si vous touchez à la compression, contrôlez aussi MTU/MSS, étape par étape, méthodiquement.

Algorithmes : LZO, LZ4, Zstd et leur usage

Historiquement, OpenVPN utilisait LZO. Rapide mais aujourd’hui dépassé et non sécurisé comme méthode de compression dans le tunnel. LZ4 est un compromis pour faible latence et haut débit, supportable sur processeurs modestes. Zstd (Zstandard) en 2026 est le « roi » de la compression universelle : il compresse bien à bas niveau, très efficace en niveaux moyens/élevés, avec une adaptation dynamique vitesse/qualité. Son inconvénient est son coût processeur, critique surtout sur les smartphones âgés de plus de 3-4 ans. Un cœur surchauffé signifie une instabilité. Dans la réalité, on active la compression avec modération et principalement si nécessaire.

Flux vs datagrammes : TCP, UDP et QUIC

La compression ne s’entend pas avec TCP-over-TCP. Si vous faites circuler une session TCP dans un tunnel TCP, vous vous exposez au piège de la « double gestion de flux », au blocage en tête de ligne douloureux et à des pics de latence bizarres. Les tunnels UDP, comme WireGuard ou OpenVPN UDP, supportent mieux la compression, à condition de bien régler paquets, jitter et buffers. QUIC (HTTP/3) sur UDP intègre déjà ses propres optimisations, compression d’en-têtes et reprise de pertes — la compression supplémentaire au niveau VPN n’apporte généralement pas grand-chose.

Quand la compression aide : scénarios et chiffres vérifiés

Protocoles textuels et événements : JSON, logs, télémétrie

Tout ce qui ressemble à JSON, CSV, XML, syslog, métriques Prometheus et dumps textuels non traités est parfait pour la compression. On observe typiquement un gain entre 40 et 80 % de volume. Dans une entreprise, nous avons activé un zstd « intra-site » sur un canal de logs entre une filiale et le siège : le trafic a fondu de 63 % avec seulement 3-5 ms de latence en plus. Le prix : une charge CPU modérée côté serveur (12-18 %) et une consommation acceptable côté clients légers (5-10 %).

Sauvegardes et migrations de données

Beaucoup de solutions de backup compressent déjà. Mais si, pour des raisons historiques, la compression est désactivée ou modérée, la compression VPN peut aider. Exemple pratique 2025-2026 : backups incrémentaux de configurations et rapports textuels entre sites via IPsec avec IPComp. Résultat : reduction de 28-35 % du trafic, graphique stable, économies sur la bande louée. Mais on insiste : si le source applique déjà zstd, ne cherchez pas à rattraper ça au niveau VPN, ce serait vain.

RDP/SSH et sessions « fines »

RDP et SSH économisent déjà du trafic, mais pas toujours agressivement, surtout sur des mises à jour d’écran en flux dans des apps non standards ou avec beaucoup de modifications textuelles. Sur liens lents, LZ4 en OpenVPN UDP a permis une économie de 10-20 % de volume avec une très légère amélioration du temps de réponse. Pas miraculeux, mais sur un 4G faiblard en périphérie, le curseur ne « colle » plus.

IoT et trafic industriel

Capteurs, machines, contrôleurs communiquent parfois via des protocoles textuels simples. Dans des réseaux fermés sans HTTPS, on peut comprimer jusqu’à 50 % du payload. Oui, c’est un retour en arrière, mais en réalité dans les ateliers : si le protocole date des années 2000 et n’a pas de compression intégrée, la compression VPN est une montée en gamme économique. Important : évaluez d’abord les risques sécuritaires (nous en reparlons avec VORACLE et menaces associées), puis activez-la uniquement sur les sous-réseaux concernés.

Quand la compression nuit : failles souvent ignorées

Les codecs modernes et le chiffrement grignotent le gain

Vidéo H.265/H.266, audio Opus/AAC, images WebP/AVIF, archives, et TLS 1.3 sur HTTP/3 — c’est soit déjà compressé, soit du bruit blanc pour le compresseur. Vous aurez quasi aucune économie et dépenserez du CPU. Bilan : vitesse maximale en baisse, latences en hausse, batterie qui fond sur téléphone. Parfois, on a même observé une chute de moitié de la vitesse utile avec LZO activé sur OpenVPN, uniquement parce que 95 % du trafic était de la vidéo et du TLS.

TCP-over-TCP et le « blocage » des fenêtres

Si votre VPN roule sur TCP et qu’à l’intérieur c’est aussi TCP, à chaque perte de paquet le TCP extérieur retransmet, le TCP intérieur attend et rassemble. Ajoutez la compression, et les queues côté VPN font concurrence aux fenêtres TCP. Résultat : vitesse saccadée, chutes non prévues dans les FPS en cloud gaming, plaintes d’utilisateurs « ça lag ». Dans ces scénarios, évitez à tout prix les tunnels TCP, alors la compression autant y renoncer.

MTU, MSS, fragmentation et douleurs cachées

La compression modifie la taille moyenne et la variabilité des paquets. Là où PMTUD fonctionnait avant, maintenant on peut avoir des fragments rares mais sévères. En 5G SA, peu perceptible, mais en LTE avec routeurs anciens, ça peut vraiment poser problème. Ajoutez des CGNAT imprévisibles et vulnérables, et vous aurez des coupures mystérieuses. Solution : ajuster avec précaution mssfix et tun-mtu dans OpenVPN, tester les scénarios ICMP blackhole et mesurer le taux de fragmentation sur le chemin.

Types de données et efficacité attendue de la compression

Facilement compressibles : texte et proche du texte

- JSON, CSV, XML, YAML : 40-80 % de gain - Logs, configs, scripts, dumps SQL (non archivés) : 50-85 % - Protocoles type MQTT sans compression intégrée : 30-60 % - RDP/SSH sur charges textuelles : 10-30 %

La répartition dépend de l’entropie : plus la répétition des structures et mots est élevée, plus le gain est fort. Zstd en niveau 3-5 offre souvent un bon compromis, surtout sur serveurs avec cœurs performants.

Difficilement compressibles : déjà compressés ou chiffrés

- HTTPS, HTTP/3, trafic TLS de tout type : 0-5 % - Vidéo, audio, images dans formats modernes : 0-3 % - Archives zip/7z, bases, blobs, backups chiffrés : 0-1 %

Le compresseur n’a rien à attraper ici : l’entropie est trop forte, aucune régularité à exploiter. Toute tentative ne fait que gaspiller du CPU.

Cas situationnels : SMB, protocoles anciens, télémétrie

SMB 3.1.1 sous Windows récents intègre sa propre compression (et zstd est courant). La compression VPN gêne donc souvent. Mais pour de vieux clients ou applis spécifiques sans compression, LZ4 au niveau VPN peut apporter 10-25 % d’économie. La télémétrie est souvent textuelle embauchée, parfois avec champs binaires ; regardez les pcap pour calculer les coefficients réels.

Risques de sécurité : VORACLE, attaques associées et comment les éviter

Qu’est-ce que VORACLE et pourquoi elle est encore d’actualité

VORACLE est une attaque où la compression avant chiffrement dans un VPN permet de fuir des secrets HTTP via l’analyse des tailles de blocs compressés. Scénario classique : un attaquant persuade sa victime de visiter une page avec une injection contrôlée, et en observant les longueurs des paquets compressés, devine petit à petit le contenu secret (cookies par exemple). Apparentée à CRIME et BREACH, avec les spécificités d’OpenVPN et LZO. En 2026, le mécanisme est toujours valide : si vous activez la compression telle quelle et que vous faites passer du texte sensible non compressé dedans, vous êtes en danger.

Quels protocoles sont vulnérables ou non

Si tout votre trafic est HTTPS correctement configuré, la probabilité de succès de VORACLE est minime, car le compresseur VPN ne voit plus qu’une soupe entropique issue du TLS. Mais s’il y a du HTTP (non sécurisé), des API non protégées, des consoles d’administration anciennes, des interfaces back-office, le risque est réel. Même les portails internes d’entreprise « entre collègues » sont vulnérables si passés par un VPN avec compression activée et sans mesures complémentaires.

Mesures pratiques de protection

- Désactivez par défaut la compression dans le VPN. Activez-la seulement sur des flux explicitement sûrs et non sensibles. - Sous OpenVPN, utilisez allow-compression no ou le mode asymétrique qui accepte la compression en réception seulement, pas en envoi. - Forcez le HTTPS, activez HSTS, sécurisez les cookies avec HttpOnly, Secure, SameSite=Strict. - Pour le web, désactivez la compression des réponses sur les pages contenant des secrets ou appliquez un padding aléatoire côté application. - Segmentez : tunnels séparés ou politiques différentes pour logs/télémétrie, et pour le trafic utilisateur web.

Configuration pratique : OpenVPN, WireGuard, IPsec, Shadowsocks

OpenVPN : vivre sans comp-lzo sans pleurer

La vieille option comp-lzo est aujourd’hui un drapeau « danger ». Dans les versions récentes, préférez allow-compression no, évitez compress sauf si vous connaissez parfaitement les risques. Si compression nécessaire : - créez un profil/tunnel séparé pour les flux textuels non sensibles ; - choisissez LZ4 au niveau minimum sur ces tunnels ; - ajustez mssfix (ex. 1400-1420 pour LTE) et modérez tun-mtu ; - contrôlez la charge CPU sur client (smartphone, client léger) et serveur ; - testez en A/B pendant au moins 24 h avec charge réelle.

WireGuard : pas de compression et c’est voulu

WireGuard n’intègre volontairement aucune compression. C’est une bonne décision : moins d’attaques du type « compression avant chiffrement = fuite ». Pour économiser : compressez côté applicatif : - archivez les backups avec zstd avant envoi ; - activez compression dans les clients de télémétrie ; - optimisez les formats d’envoi (protobuf avec varint, déduplication à la source). Ce n’est pas excitant mais sûr et prévisible côté ressources.

IPsec et IPComp : la classique prudente

IPComp (RFC 3173) est une option de compression de la charge utile IPsec. Ça marche, mais n’apporte un bénéfice que sur des flux textuels. En 2026, c’est un usage de niche : activez selon l’adresse, pour des sous-réseaux ciblés, et mesurez. Attention au matériel : certains équipements implémentent IPComp de façon médiocre avec bugs sporadiques et fragmentation inattendue.

Shadowsocks / pile proxy : compression en plugin

Dans certains environnements, on utilise des plugins d’obfuscation parfois combinés à la compression. Important : le gain n’est réel que sur du contenu non compressé, et les risques sécuritaires sont similaires — la compression avant chiffrement augmente la surface d’attaque par analyse de longueur. Mieux vaut garder la compression côté application et ne pas mélanger avec l’obfuscation de transport sauf nécessité.

Monitoring, tests et métriques : sans chiffres, la compression c’est du devin

Comment tester correctement : A/B sur trafic réel

Lancez deux branches parallèles, avec et sans compression. Soumettez-les aux mêmes charges pendant un ou deux jours. Mesurez : - volume d’octets entrant/sortant du tunnel ; - latences p95/p99 ; - CPU et RAM sur points d’extrémité ; - taux de pertes et retransmissions. Testez en « heure de pointe » et pendant les pics de fond (tâches de réserve, mailing, mises à jour massives).

Outils et méthodes en 2026

Utilisez iperf3 pour baseline, tc pour émuler la latence/jitter, des exportateurs systèmes (node-exporter par ex.). Analysez les pcap filtrés sur interfaces tunnel, calculez le taux de compression, inspectez MTU/MSS et fragmentation. Visualisez les écarts dans Grafana — pas de magie, que des courbes pratiques.

Critères de succès et condition d’arrêt

Gardez la compression si : - économie de trafic stable et supérieure à 15-20 % ; - latence augmentée de moins de 5-10 ms sur tâches interactives ; - CPU ne dépasse pas 70-75 % sur longues durées ; - pas de pics de fragmentation ni erreurs PMTUD. Sinon, désactivez la ou déplacez-la côté application.

Cas concrets 2024-2026 : où ça a marché et où non

Ventes mobiles et CRM sur le terrain

Smartphones des commerciaux envoient paquet de requêtes textuelles et mini-rapports. OpenVPN UDP avec LZ4 sur serveur dist: économie de 22-35 %, latence augmentée de 3-4 ms. Batterie un peu plus sollicitée (+4-7 %), mais utilisateurs contents : les formulaires s’ouvrent plus vite, même en LTE instable.

Canal satellite et télémétrie d’une ferme agri

VSAT avec latence 600+ ms. Télémétrie = lots de petits messages JSON. Compression activée côté serveur avec zstd dans l’application, plus pas dans VPN ni IPsec. Gain 58 %, moins de fluctuations CPU, envoi plus régulier. Conclusion : compression en application apporte plus de contrôle et prévisibilité.

Vidéo-surveillance et accès distant

Essaye de compresser les flux H.265 via OpenVPN. Résultat quasi nul, voire latences 10-15 % plus élevées à cause du CPU. Solution : désactiver compression, optimiser bitrate caméras et GOP. Dans VPN : trafic pur sans interventions inutiles.

Backups d’entreprise entre datacenters

Backups déjà zstd, flux parallèles. IPsec avec IPComp donne 1-3 % d’économie mais pics CPU aux gateways. IPComp désactivé, parallélisme backup ajusté, canal stable et sans interruptions.

Parc IoT sur vieux protocole

Anciens contrôleurs envoyant paquets semi-textuels sans TLS. Tunnel OpenVPN dédié avec LZ4 juste pour ce sous-réseau : gain 45-55 % en trafic et baisse coûts opérateur. L’équipe a assumé le risque, pas de données sensibles, gros bénéfice. Monitorage et limitation MTU ajoutés pour éviter fragmentation.

Checklists et recommandations pour 2026

Quand activer la compression

- Trafic principalement textuel, peu entropique - Charge stable, avec mesure et surveillance possibles - Tunnel/politique séparé pour sous-réseaux ciblés - Tolérance à une légère augmentation de latence pour économiser de la bande

Quand éviter absolument

- Flux vidéo, audio, jeux ou tout ce sensible à la latence - Trafic massif HTTPS/HTTP3, archives, backups déjà compressés - Tunnels TCP-over-TCP - Réseaux inconnus avec MTU/PMTUD problématiques

Sécurité avant tout

- Désactiver compression dans VPN par défaut - Trafic web secret en HTTPS avec bonnes pratiques cookies - Séparation des tunnels : logs/télémétrie vs IT utilisateur - Envisager padding côté application si compression des réponses

Performance et exploitation

- Surveiller CPU aux extrémités, prévoir une marge de cores - Être particulièrement économe sur mobiles face au risque batterie - Gérer MTU/MSS et monitorer fragmentation - Faire des tests A/B d’au moins 24 h, comparer p95/p99

Erreurs fréquentes et anti-patterns

Activer « au cas où » et oublier

Voilà comment on casse les connexions. La compression est une hypothèse, pas un bouton magique. Sans mesure, comptez que ça fonctionne pire avant.

Compresser sur du déjà compressé

Compresser du H.265 ou zip, c’est comme repasser des glaçons : ça grésille, CPU gaspillé, zéro gain. Faites la compression là où il y a répétition.

Ignorer la sécurité

VORACLE est toujours là. Si vous avez encore du HTTP sans S avec compression VPN — le risque est réel. Bouchez les failles ou segmentez le trafic.

TCP sur TCP

Double gestion de flux plus compression = recette à lags bizarres. Pour du predictable, évitez cette architecture.

FAQ : bref, clair et sans bla-bla

Sécurité et risques

La compression dans OpenVPN est-elle dangereuse en 2026 ?

Par défaut, oui, déconseillée. Le risque VORACLE et fuites associées est toujours là. En cas de nécessité, activez uniquement sur sous-réseaux non sensibles, avec LZ4 séparé.

La compression aide-t-elle contre le DPI et la censure ?

Non. Compression agit sur la taille et la répétition, pas sur l’obfuscation. Pour contrer le DPI, préférez obfuscation, plugins transport ou autres protocoles, mais c’est un autre sujet avec d’autres risques.

tls-crypt protège-t-il contre VORACLE ?

Non. tls-crypt chiffre et authentifie le canal de contrôle, mais si vous compressez la charge utile avant chiffrement, les attaques basées sur la taille restent possibles.

Performance et gains

Peut-on vraiment accélérer internet par la compression ?

Sur du trafic texte non compressé en amont, oui, gains de volume de 20 à 60 % et accélération visible du chargement. Pour vidéo, HTTPS ou archives, aucun bénéfice voire dégradation.

La compression épuise-t-elle la batterie du smartphone ?

Cela dépend de l’algorithme et de l’appareil. En moyenne, LZ4 consomme 3-7 % de batterie supplémentaire par jour, zstd plus encore. Les vieux téléphones chauffent vite.

Pratique et configuration

IPComp a-t-il un intérêt pour IPsec ?

Oui, si les flux sont compressibles (logs, télémétrie). Mais vérifiez votre matériel, des bugs de fragmentation sont possibles. Sur trafic chiffré ou média, IPComp est inutile.

Comment savoir si la compression aide ou pénalise ?

Faites un test A/B de 24-48 heures. Contrôlez l’économie en octets, latence p95, charge CPU, fragmentation. Si économie <15 % ou latence augmente >10 ms, coupez la compression.

Pourquoi WireGuard n’a-t-il pas intégré la compression ?

Pour éviter les vulnérabilités et complexités. La compression est un facteur de risques et de charge CPU, avec des gains douteux sur le trafic moderne. Mieux vaut compresser côté application où c’est pertinent.