Votre application est lente parce que votre load balancer est mal configuré — pas parce qu’elle est lente

Septembre 2025, un SaaS français perd 40 % de son trafic en pleine campagne marketing. La cause n’est pas un bug applicatif, ni une panne cloud, ni une attaque DDoS. C’est un balance roundrobin dans une config HAProxy qui n’a pas été touchée depuis trois ans — quatre backends sur cinq encaissaient la charge pendant que le cinquième, le plus puissant, tournait à 12 % de CPU.

Juin 2026, HAProxy sort sa version 3.4.0 avec les backends dynamiques rechargeables sans interruption de service. Traefik est en v3.7.9 et découvre vos conteneurs Docker sans une ligne de config. Envoy publie sa v1.39.0, enrichit son protocole xDS et muscle son filtrage HTTP/2. Trois excellents load balancers, des centaines de milliers de déploiements — et une écrasante majorité de configurations sous-optimales.

Un load balancer mal réglé ne se contente pas de ne pas aider : il injecte de la latence, gaspille des ressources et masque les vrais goulots d’étranglement. Le corriger rapporte plus de performance que de passer au plan de serveur supérieur.

Ce qu’un load balancer fait vraiment — et ce qu’il ne fait pas

Un load balancer distribue le trafic entrant entre plusieurs serveurs backend. Mais cette définition de manuel omet trois fonctions critiques qui déterminent si votre infrastructure tient la charge ou s’effondre.

Les algorithmes de distribution. Le round-robin (tourniquet) est le plus répandu et le plus mal compris. Il distribue les requêtes séquentiellement sans tenir compte de la charge réelle des backends. Si votre backend A a deux fois plus de CPU que le backend B, le round-robin lui envoie autant de requêtes — et le backend B s’écroule pendant que le A s’ennuie. Les algorithmes comme least connections (HAProxy leastconn, Envoy LEAST_REQUEST) ou least loaded (Traefik, basé sur les métriques du circuit breaker) corrigent ce déséquilibre, mais ils ne sont actifs que si vous les activez.

Les health checks. Sans eux, le load balancer continue d’envoyer du trafic vers un backend mort. Le health check TCP (port ouvert) est insuffisant : un processus NGINX peut accepter des connexions TCP tout en retournant des HTTP 500. Le health check HTTP (GET /health avec vérification du code de statut et du corps de réponse) est le minimum viable. HAProxy et Envoy supportent aussi les health checks gRPC, MySQL et Redis — des protocoles pour lesquels un check TCP dit « tout va bien » alors que le pool de connexions est saturé.

La terminaison SSL. Déchiffrer le TLS au niveau du load balancer évite aux backends de consommer du CPU pour de la cryptographie — un gain mesurable de 15 à 30 % de capacité backend. Mais c’est un compromis : le trafic entre le load balancer et les backends circule en clair si vous ne réactivez pas le TLS entre les deux. La terminaison SSL sans rechiffrement est la configuration par défaut de 80 % des tutos Docker Compose — et la première chose qu’un auditeur de pénétration va pointer du doigt.

HAProxy : le moteur diesel qui démarre au quart de tour

HAProxy est écrit en C par Willy Tarreau et maintenu depuis 2001. Il ne fait qu’une chose — proxy TCP/HTTP — et il la fait avec une efficacité que les implémentations plus récentes approchent rarement. Un seul processus HAProxy sur un serveur moderne peut gérer 2 millions de connexions simultanées avec moins de 100 Mo de RAM. C’est le load balancer derrière Cloudflare, GitHub, Reddit, Twitter et une partie significative du web francophone.

La version 3.4.0, publiée le 3 juin 2026, introduit une fonctionnalité attendue depuis quinze ans : les backends dynamiques. Avant la 3.4, toute modification de la liste des serveurs backend exigeait un reload — une opération qui redémarre le processus HAProxy et brise les connexions établies. Le reload d’HAProxy est célèbre pour sa douceur (le processus parent passe le socket au nouveau processus sans perte de paquets), mais il reste une opération à risque en haute charge. Avec la 3.4, vous créez, peuplez, publiez et supprimez des backends via le socket CLI sans jamais reloader. La version 3.4 est une LTS supportée jusqu’au deuxième trimestre 2031.

Les forces d’HAProxy sont mécaniques : un fichier de configuration unique (haproxy.cfg), un langage de règles ACL expressif, une documentation exhaustive, et une stabilité qui frôle la légende — des bugs de corruption de données ? Zéro en vingt-cinq ans. Ses limites sont également mécaniques : pas d’auto-discovery natif (il faut script ou consul-template pour injecter les backends dynamiquement), pas de gestion TLS automatique (pas de Let’s Encrypt intégré, c’est à vous de gérer les certificats), et une courbe d’apprentissage qui récompense ceux qui lisent la documentation plutôt que ceux qui copient-collent un tutoriel.

Traefik : la config qui s’écrit toute seule

Traefik a été conçu en Go pour un monde de conteneurs. Sa promesse est radicale : vous ne configurez pas Traefik, vous annotez vos services, et Traefik découvre le reste. Un conteneur Docker avec le label traefik.http.routers.monapp.rule=Host(\"app.example.com\") apparaît automatiquement dans la configuration de routage — pas de fichier YAML séparé, pas de reload, pas d’oubli.

La version v3.7.9 (juillet 2026) supporte les providers Docker, Kubernetes (Ingress, Gateway API, CRD), Consul, Etcd, Redis, ZooKeeper et Nomad. Le certificat TLS est géré automatiquement via Let’s Encrypt avec renouvellement sans intervention. Le middleware pipeline est extensible : rate limiting, circuit breaker, forward auth, compression, headers customization — le tout activable par annotation.

Ce modèle a un coût. Traefik est un binaire unique qui tourne avec 50 à 200 Mo de RAM selon la complexité du routage, et son moteur de découverte interroge activement chaque provider. Sur un cluster Docker Swarm de 50 nœuds avec 300 conteneurs, le polling de l’API Docker consomme des appels API non négligeables. Les utilisateurs avancés butent aussi sur la syntaxe de routage : ce qui est trivial avec le label Docker devient vite ésotérique en YAML statique, et le débogage d’une règle de routage qui ne matche pas est moins outillé que le haproxy -c -f qui vous dit exactement où est l’erreur.

Le verdict communautaire est clair : Traefik est imbattable pour le routage HTTP/HTTPS dans un environnement conteneurisé où le développeur contrôle les annotations. Dès que vous sortez du HTTP (TCP brut, base de données, broker de messages), HAProxy reprend l’avantage.

Envoy : le load balancer qui ne sait pas faire que du load balancing

Envoy est un projet CNCF graduated créé par Lyft en 2016. Contrairement à HAProxy et Traefik, Envoy n’a jamais été conçu pour être configuré à la main par un humain. Sa configuration se lit en YAML ou JSON (plusieurs centaines de lignes pour un reverse proxy simple), et son modèle de configuration dynamique — le protocole xDS — suppose qu’un plan de contrôle externe pousse les mises à jour en continu. C’est le data plane derrière Istio, le service mesh de Google Cloud, et une partie croissante des architectures Kubernetes en production.

La version v1.39.0 (juillet 2026) ajoute le parsing JSON streaming pour les protocoles MCP, A2A et OpenAI, des health checkers extensibles, l’affinité CPU par worker, un load balancer de connexion eBPF SO_REUSEPORT, et des modules dynamiques chargeables sans recompilation. Envoy supporte nativement HTTP/1.1, HTTP/2, HTTP/3 (QUIC), gRPC, MongoDB, MySQL, Redis, Kafka, Thrift, et à peu près tout protocole qui parle TCP.

Cette universalité a un poids. Un déploiement Envoy minimal consomme ~50 Mo de RAM par proxy, mais un proxy configuré avec filtrage HTTP complet, observabilité OpenTelemetry et health checking actif peut monter à 150-200 Mo. Le fichier de configuration statique est inhumain — 500 à 1000 lignes de YAML pour un reverse proxy avec TLS et rate limiting —, ce qui explique pourquoi presque personne n’utilise Envoy sans un plan de contrôle comme Istio, Contour ou Envoy Gateway.

La force d’Envoy n’est pas le load balancing de base. C’est l’observabilité : tracing distribué natif, métriques par percentile (P50, P95, P99), logs d’accès structurés, et la capacité à injecter des fautes (fault injection) ou à dupliquer du trafic (traffic mirroring) sans toucher au code applicatif. Si votre load balancer doit aussi servir de laboratoire de chaos engineering, Envoy est le seul à cocher cette case.

Les quatre configurations qui tuent vos performances

Avant de choisir entre HAProxy, Traefik et Envoy, corrigez les erreurs de configuration qui annulent leurs bénéfices. Ces quatre pièges sont universels — ils s’appliquent aux trois outils.

1. Le round-robin par défaut. Dans HAProxy, c’est balance roundrobin. Dans Traefik, c’est le comportement par défaut des services Docker Swarm. Dans Envoy, c’est ROUND_ROBIN. Aucun de ces modes ne tient compte de la capacité des backends. Résultat : le backend le plus lent dicte la latence globale. La correction est simple : balance leastconn (HAProxy), LEAST_REQUEST (Envoy), ou un weighted round-robin avec des poids proportionnels à la capacité réelle de chaque backend. Mais cette correction suppose que vous ayez mesuré la capacité de chaque backend — ce que 90 % des équipes ne font pas.

2. Le health check TCP sans vérification applicative. Un check port 8080 ne détecte pas un backend qui répond HTTP 503 sur toutes ses requêtes. Le coût est silencieux : le load balancer envoie du trafic vers un backend malade, qui le rejette, et le client voit une erreur alors qu’un backend sain attendait des requêtes. La solution est un health check HTTP actif (option httpchk GET /health dans HAProxy, healthcheck dans Traefik, un health_check filter dans Envoy) qui vérifie le code de statut et idéalement un champ dans le corps de la réponse.

3. La terminaison SSL sans rechiffrement. Le trafic entre le load balancer et les backends circule en clair sur le réseau interne. C’est rapide, c’est pratique, et c’est la configuration par défaut de la plupart des tutoriels. C’est aussi une violation de tout référentiel de sécurité réseau (ANSSI, NIST, PCI-DSS) qui exige le chiffrement de bout en bout. Le coût CPU du rechiffrement est réel — 5 à 15 % selon la charge — mais l’alternative est pire : un attaquant qui compromet un seul conteneur sur le réseau Docker bridge peut sniffer tout le trafic inter-services.

4. Le timeout mal dimensionné. Le timeout par défaut entre le load balancer et les backends est souvent laissé à sa valeur d’usine : 30 secondes dans HAProxy (timeout server 30s), 60 secondes dans Traefik, 15 secondes dans Envoy. Si votre backend traite des requêtes longues (upload de fichiers, génération de rapports, appels à une API externe), le timeout coupe la connexion avant la fin du traitement — et le client reçoit une erreur 504 Gateway Timeout. À l’inverse, un timeout trop long sur des requêtes rapides immobilise des connexions qui pourraient servir d’autres clients. La règle : mesurez le P99 de latence de vos backends, doublez-le, et utilisez cette valeur comme timeout. Re-mesurez tous les mois.

Le verdict : quel load balancer pour quel profil

Le load balancer parfait n’existe pas. Le bon load balancer est celui dont vous maîtrisez la configuration et dont le modèle de déploiement correspond à votre architecture — pas à celle du blog qui vous l’a recommandé.

Vous gérez un parc bare-metal ou des VMs avec des backends hétérogènes. Prenez HAProxy 3.4 LTS. Le fichier unique haproxy.cfg est versionnable, revuable, et compréhensible par un SRE qui n’a pas touché la config depuis six mois. Les backends dynamiques de la 3.4 éliminent le dernier gros irritant opérationnel. Le support jusqu’en 2031 vous donne cinq ans de tranquillité. Seul bémol : prévoyez une solution externe pour les certificats TLS (certbot + cron, ou un pipeline CI/CD qui pousse les certificats).

Vous déployez sur Docker ou Kubernetes avec une majorité de trafic HTTP/HTTPS. Prenez Traefik 3.7. L’auto-discovery par labels Docker ou annotations Kubernetes réduit la configuration au strict minimum, Let’s Encrypt gère vos certificats, et le middleware pipeline couvre 90 % des besoins de transformation de requêtes. Le coût du polling d’API devient sensible au-dessus de 200 conteneurs — si vous atteignez cette échelle, migrez le provider vers un fichier de configuration statique ou passez à un plan de contrôle Kubernetes (Ingress Controller ou Gateway API).

Vous opérez un service mesh Kubernetes avec des besoins d’observabilité avancée. Envoy 1.39 est le data plane de référence, mais ne le configurez pas à la main. Utilisez Istio (le plus complet, le plus lourd), Contour (le plus simple, basé sur les Gateway API), ou Envoy Gateway (le standard CNCF émergent, encore jeune). Le surcoût en RAM et en complexité est réel — ne déployez Envoy que si vous avez déjà une équipe qui maîtrise les CRD Kubernetes.

Vous avez moins de 5 backends et une charge modérée. Vous n’avez peut-être pas besoin d’un load balancer dédié. NGINX en reverse proxy avec un upstream block et least_conn fait le travail pour des déploiements simples. La différence avec HAProxy se joue à partir de 50 000 connexions simultanées ou de 10 backends — en dessous, la simplicité d’une config NGINX que toute l’équipe connaît pèse plus lourd que les 5 % de performance qu’HAProxy gagne sur du trafic HTTP.

Le load balancer est le premier maillon de la chaîne de traitement d’une requête. C’est aussi le plus négligé, parce qu’il « marche » avec les réglages d’usine — jusqu’au jour où il ne marche plus. Les trois minutes que vous passez à remplacer roundrobin par leastconn rapportent plus que les trois jours que vous passerez à debugger une application qui n’a jamais été le problème.

Références

• HAProxy 3.4.0 Release Announcement — 3 juin 2026, backends dynamiques
• HAProxy Documentation — LTS lifecycle — support 3.4 jusqu’à 2031-Q2
• Traefik v3.7.9 Release Notes — 24 juillet 2026
• Traefik Documentation — Providers — Docker, Kubernetes, Consul, etc.
• Envoy v1.39.0 Release Notes — 14 juillet 2026
• Envoy xDS Protocol Documentation — protocole de configuration dynamique
• Envoy Proxy — CNCF Graduated Project — historique et gouvernance
• NGINX Upstream Module — least_conn et health checks
• PCI-DSS v4.0 Requirement 4.2.1 — chiffrement des données en transit
• ANSSI — Recommandations de sécurité relatives à TLS — terminaison et rechiffrement