#odx-page{font-family:’Inter’,system-ui,-apple-system,sans-serif;color:#334155;line-height:1.8;max-width:820px;margin:0 auto;padding:0 20px} #odx-page h1{font-size:2rem;font-weight:800;color:#0f172a;margin:0 0 1rem;line-height:1.3} #odx-page h2{font-size:1.45rem;font-weight:700;color:#1e293b;margin:2.5rem 0 1rem;padding-bottom:.5rem;border-bottom:2px solid #3c72fc30} #odx-page h3{font-size:1.15rem;font-weight:600;color:#1e293b;margin:1.8rem 0 .8rem} #odx-page p{margin:0 0 1.2rem;font-size:1rem;color:#475569} #odx-page ul,#odx-page ol{margin:0 0 1.5rem;padding-left:1.5rem} #odx-page li{margin-bottom:.5rem;color:#475569} #odx-page strong{color:#1e293b} #odx-page a{color:#3c72fc;text-decoration:none} #odx-page a:hover{text-decoration:underline} #odx-page .odx-hero-img{width:100%;height:auto;border-radius:12px;margin:1.5rem 0 2rem;box-shadow:0 4px 20px rgba(0,0,0,.08)} #odx-page .odx-toc{background:#f1f5f9;border-radius:10px;padding:1.5rem 2rem;margin:2rem 0} #odx-page .odx-toc h3{margin:0 0 .8rem;font-size:1.1rem;color:#0f172a;border:none;padding:0} #odx-page .odx-toc ol{margin:0;counter-reset:toc} #odx-page .odx-toc li{counter-increment:toc;margin-bottom:.4rem;color:#3c72fc;font-weight:500} #odx-page .odx-toc li a{color:#3c72fc} #odx-page .odx-highlight{background:linear-gradient(135deg,#eff6ff,#e0f2fe);border-left:4px solid #3c72fc;border-radius:0 10px 10px 0;padding:1.2rem 1.5rem;margin:1.5rem 0} #odx-page .odx-highlight p{margin:0;color:#1e3a5f;font-weight:500} #odx-page .odx-stat-grid{display:grid;grid-template-columns:repeat(auto-fit,minmax(200px,1fr));gap:1rem;margin:1.5rem 0} #odx-page .odx-stat{background:#f8fafc;border:1px solid #e2e8f0;border-radius:10px;padding:1.2rem;text-align:center} #odx-page .odx-stat .num{font-size:1.8rem;font-weight:800;color:#3c72fc;display:block} #odx-page .odx-stat .label{font-size:.85rem;color:#64748b;margin-top:.3rem;display:block} #odx-page table{width:100%;border-collapse:collapse;margin:1.5rem 0;font-size:.95rem} #odx-page th{background:#1e293b;color:#fff;padding:.8rem 1rem;text-align:left;font-weight:600} #odx-page td{padding:.7rem 1rem;border-bottom:1px solid #e2e8f0;color:#475569} #odx-page tr:nth-child(even) td{background:#f8fafc} #odx-page .ofaq{background:linear-gradient(135deg,#0a1628 0%,#1e3a5f 100%);border-radius:16px;padding:2.5rem;margin:3rem 0;position:relative;overflow:hidden} #odx-page .ofaq::before{content: »;position:absolute;top:-50%;right:-20%;width:300px;height:300px;background:radial-gradient(circle,rgba(60,114,252,.15),transparent 70%);border-radius:50%} #odx-page .ofaq-head{display:flex;align-items:center;gap:1rem;margin-bottom:1.5rem} #odx-page .ofaq-icon{width:48px;height:48px;background:linear-gradient(135deg,#3c72fc,#60a5fa);border-radius:12px;display:flex;align-items:center;justify-content:center;font-size:1.4rem;flex-shrink:0} #odx-page .ofaq-title{color:#fff;font-size:1.3rem;font-weight:700;margin:0} #odx-page .ofaq-count{color:#94a3b8;font-size:.85rem} #odx-page .ofaq-list{display:flex;flex-direction:column;gap:.8rem} #odx-page .ofaq-item{background:rgba(255,255,255,.05);border:1px solid rgba(255,255,255,.08);border-radius:12px;overflow:hidden;backdrop-filter:blur(10px)} #odx-page .ofaq-btn{width:100%;display:flex;align-items:center;gap:1rem;padding:1.1rem 1.3rem;cursor:pointer;border:none;background:none;text-align:left} #odx-page .ofaq-num{width:28px;height:28px;background:rgba(60,114,252,.15);border-radius:8px;display:flex;align-items:center;justify-content:center;color:#60a5fa;font-weight:700;font-size:.85rem;flex-shrink:0} #odx-page .ofaq-q{color:#e2e8f0;font-weight:600;font-size:.95rem;flex:1} #odx-page .ofaq-chevron{color:#64748b;transition:transform .3s cubic-bezier(.4,0,.2,1);font-size:.8rem;flex-shrink:0} #odx-page .ofaq-item.active .ofaq-chevron{transform:rotate(180deg)} #odx-page .ofaq-item.active .ofaq-num{background:linear-gradient(135deg,#3c72fc,#60a5fa);color:#fff} #odx-page .ofaq-panel{max-height:0;overflow:hidden;transition:max-height .4s cubic-bezier(.4,0,.2,1)} #odx-page .ofaq-item.active .ofaq-panel{max-height:500px} #odx-page .ofaq-ans{padding:0 1.3rem 1.2rem;color:#cbd5e1;line-height:1.7;font-size:.92rem} #odx-page .odx-cta{background:linear-gradient(135deg,#3c72fc,#1d4ed8);border-radius:14px;padding:2.5rem;text-align:center;margin:3rem 0;color:#fff} #odx-page .odx-cta h3{color:#fff;margin:0 0 .8rem;font-size:1.4rem;border:none} #odx-page .odx-cta p{color:rgba(255,255,255,.85);margin:0 0 1.5rem} #odx-page .odx-cta a.btn{display:inline-block;background:#fff;color:#1d4ed8;padding:.8rem 2rem;border-radius:8px;font-weight:700;text-decoration:none;transition:all .3s} #odx-page .odx-cta a.btn:hover{transform:translateY(-2px);box-shadow:0 8px 25px rgba(0,0,0,.2);text-decoration:none} @media(max-width:768px){#odx-page{padding:0 15px}#odx-page h1{font-size:1.5rem}#odx-page h2{font-size:1.25rem}#odx-page .ofaq{padding:1.5rem}#odx-page .odx-stat-grid{grid-template-columns:1fr 1fr}#odx-page .odx-cta{padding:1.5rem}}

Load balancing : répartir la charge pour garantir la disponibilité

Un site web qui tombe en panne à cause d’un pic de trafic, c’est du chiffre d’affaires perdu et de la crédibilité envolée. Le load balancing (répartition de charge) est la solution technique qui distribue les requêtes entre plusieurs serveurs pour garantir performance et disponibilité. Selon AWS, une interruption de service coûte en moyenne 300 000 dollars par heure aux entreprises. Même à l’échelle d’une PME, les conséquences d’une indisponibilité sont significatives.

Les principes du load balancing

Le load balancing consiste à répartir le trafic entrant entre plusieurs serveurs (appelés backends ou upstream) pour éviter la surcharge d’un seul serveur. Le load balancer est le point d’entrée unique qui reçoit toutes les requêtes et les distribue intelligemment.

Pourquoi répartir la charge

• Performance : chaque serveur traite une fraction du trafic, les temps de réponse restent bas
• Disponibilité : si un serveur tombe, le trafic est automatiquement redirigé vers les autres
• Scalabilité : ajouter un serveur augmente la capacité sans modifier l’architecture
• Maintenance : un serveur peut être mis à jour sans interruption de service

Les algorithmes de répartition

L’algorithme de répartition détermine comment le load balancer choisit le serveur qui traitera chaque requête. Le choix de l’algorithme impacte directement les performances et l’équité de la répartition.

Les principaux algorithmes

• Round Robin : distribution séquentielle (serveur 1, serveur 2, serveur 3, serveur 1…). Simple et efficace quand les serveurs sont identiques.
• Weighted Round Robin : comme Round Robin mais avec des poids. Un serveur plus puissant reçoit plus de requêtes.
• Least Connections : la requête est envoyée au serveur qui a le moins de connexions actives. Idéal quand les requêtes ont des durées variables.
• IP Hash : l’IP du client détermine le serveur cible. Garantit qu’un même client est toujours dirigé vers le même serveur (affinité de session).
• Least Response Time : la requête est envoyée au serveur qui répond le plus vite. Le plus intelligent mais nécessite un monitoring temps réel.

Les types de load balancers

Les load balancers se classent en deux catégories : couche 4 (transport) et couche 7 (application). Le choix dépend du niveau de contrôle nécessaire sur le routage.

Load balancing couche 4 (L4)

Le load balancer L4 opère au niveau TCP/UDP. Il distribue les connexions sans inspecter le contenu des requêtes. C’est le plus rapide et le plus simple, adapté au trafic générique (mail, base de données, applications TCP).

Load balancing couche 7 (L7)

Le load balancer L7 opère au niveau HTTP/HTTPS. Il peut inspecter le contenu des requêtes et router en fonction de l’URL, des en-têtes, des cookies ou du domaine. C’est le plus flexible, indispensable pour les applications web modernes.

• Routage par URL : /api vers les serveurs API, /static vers les serveurs de contenu
• Routage par domaine : app.example.com vers un backend, api.example.com vers un autre
• Affinité de session par cookie : garantit la continuité de session utilisateur
• Terminaison SSL : centralise la gestion des certificats
• Compression et cache : optimise les réponses au niveau du load balancer

Mise en oeuvre pratique

La mise en oeuvre d’un load balancing dépend de l’infrastructure existante et du budget disponible.

Solutions logicielles

Les solutions logicielles de load balancing sont accessibles à toute PME :

• Nginx : excellent load balancer L7, déjà présent dans de nombreuses infrastructures
• HAProxy : référence en matière de load balancing, performances exceptionnelles en L4 et L7
• Traefik : auto-discovery des services Docker, idéal pour les architectures conteneurisées
• Envoy : proxy moderne utilisé par les service mesh (Istio), pour les architectures microservices

Solutions cloud

Les fournisseurs cloud proposent des load balancers managés qui simplifient l’administration :

• AWS ALB/NLB : load balancer managé, facturation à l’usage
• Cloudflare Load Balancing : répartition globale avec health checks
• OVHcloud Load Balancer : solution européenne intégrée à l’écosystème OVH

Gestion des sessions

La gestion des sessions utilisateur est le défi principal du load balancing. Si un utilisateur est connecté sur le serveur A et que sa requête suivante est envoyée au serveur B, sa session est perdue. Plusieurs solutions existent :

La meilleure approche est de stocker les sessions dans un stockage partagé (Redis, Memcached, base de données) accessible par tous les serveurs. L’application devient alors « stateless » et le load balancer peut distribuer les requêtes librement.

Haute disponibilité du load balancer

Le load balancer est un point de défaillance unique (SPOF). S’il tombe, toute l’infrastructure est inaccessible. La redondance du load balancer lui-même est donc essentielle pour une infrastructure véritablement hautement disponible.

Redondance active/passive

La configuration classique utilise deux load balancers en mode actif/passif avec une IP flottante (VIP) gérée par keepalived ou VRRP. Le load balancer actif traite le trafic. En cas de panne, le passif prend le relais automatiquement en quelques secondes.

Les health checks (vérifications de santé) permettent au load balancer de détecter automatiquement les serveurs backend défaillants et de les retirer de la rotation. Quand un serveur revient en ligne, il est automatiquement réintégré. Cette automatisation est la clé d’une infrastructure résiliente.

document.querySelectorAll(‘.ofaq-btn’).forEach(b=>b.addEventListener(‘click’,()=>{const i=b.closest(‘.ofaq-item’);document.querySelectorAll(‘.ofaq-item’).forEach(x=>{if(x!==i)x.classList.remove(‘active’)});i.classList.toggle(‘active’)}));