Qu'est-ce que WSA ?

Présentation du module Accélérateur de site Web — fonctionnement, avantages, intégration cPanel.

WSA (Web Site Accelerator, Accélérateur de site Web) est un module pour serveurs cPanel/WHM qui place nginx comme cache inversé devant Apache. Le résultat : les pages, scripts, styles, images et autres ressources de vos sites sont mis en cache au niveau du serveur et servis à pleine vitesse aux visiteurs suivants — sans appeler Apache, sans exécuter PHP, sans toucher à la base de données.

WSA est développé et maintenu par Astral Internet depuis 2019.

1. Le problème que WSA résout

Sur un serveur cPanel classique, chaque requête HTTP doit traverser toute la pile d'exécution :

   Navigateur → Apache → PHP-FPM → MySQL → ... → réponse

Pour une page WordPress typique, cette chaîne représente entre 100 et 500 ms de travail serveur, plusieurs requêtes SQL, et de la mémoire allouée pour chaque visite — même si le contenu n'a pas changé depuis la requête précédente.

Sur un site à fort trafic ou un serveur hébergeant beaucoup de comptes, cette répétition génère :

des temps de réponse lents pour les visiteurs ;
une charge CPU et mémoire constante ;
des pics de latence quand la base de données est sollicitée ;
une expérience visiteur dégradée lors des pics de trafic.

2. La solution apportée par WSA

WSA insère nginx comme couche de cache entre le visiteur et Apache :

                                  ┌─ Cache HIT  → réponse instantanée
   Navigateur → nginx (WSA) ─┤
                                  └─ Cache MISS → Apache → ... → réponse
                                                      ↓
                                                   stockage cache

Quand un visiteur demande une page, nginx vérifie d'abord s'il en a une copie récente :

Cache HIT — la copie est servie directement par nginx en quelques millisecondes, sans solliciter Apache, PHP ou la base de données.
Cache MISS — Apache génère la réponse normalement ; nginx la stocke pour les prochaines requêtes identiques avant de la transmettre au visiteur.

Comment nginx sait quand servir depuis la cache

WSA gère intelligemment plusieurs cas :

Cache TTL — Chaque réponse a une durée de validité (5 min, 1 h, 1 jour, etc.) configurable par catégorie de contenu.
Contournement par cookie — Les requêtes avec certains cookies (utilisateur connecté, panier d'achat, session) contournent automatiquement la cache.
Contournement par URI — Certaines URL (admin, checkout, preview) ne sont jamais mises en cache.
Variations par catégorie — Les pages dynamiques, les fichiers CSS/JS et les images peuvent avoir des durées de cache différentes.

3. Avantages mesurables

Vitesse

Une page WordPress non-cachée se charge typiquement entre 200 ms et 1 s. La même page servie depuis WSA répond en 5 à 20 ms. Pour le visiteur, c'est la différence entre « lent » et « instantané ».

Capacité serveur

Sur un serveur hébergeant 500+ comptes cPanel, l'introduction de WSA peut réduire la charge Apache et PHP-FPM de 60 à 90 % sur les sites populaires. Les ressources libérées permettent d'héberger plus de comptes sans dégradation de performance.

Résistance aux pics de trafic

Quand un site est partagé sur les réseaux sociaux ou apparaît dans l'actualité, WSA absorbe la vague — Apache continue à ne servir que les requêtes qui passent la cache, généralement les visiteurs uniques nouveaux.

Économies de ressources

Moins de cycles CPU, moins de requêtes SQL, moins de mémoire PHP utilisée. Sur un serveur dédié ou VPS, c'est de la marge opérationnelle ; sur un hébergement mutualisé, c'est davantage de clients possibles par serveur.

4. Compression — Gzip et Brotli

WSA active deux algorithmes de compression sur les fichiers texte (HTML, CSS, JavaScript, JSON, SVG, fonts…) :

Gzip

Standard depuis ~20 ans, supporté par tous les navigateurs. Compresse les fichiers texte à environ 70 % de leur taille originale.

Brotli

Algorithme moderne développé par Google, supporté par tous les navigateurs récents. 15 à 25 % plus efficace que Gzip sur les fichiers texte. Brotli est compilé comme module dynamique nginx par WSA lui-même, depuis le code source officiel — pas besoin de paquet RPM tiers.

Servir les deux automatiquement

WSA envoie automatiquement le bon format à chaque visiteur : Brotli aux navigateurs qui le supportent, Gzip aux autres. Le visiteur ne s'en aperçoit jamais ; le débit consommé baisse naturellement.

Cela se traduit aussi en temps de chargement pour les visiteurs sur connexion lente — un fichier CSS de 100 ko compressé en Brotli ne pèse plus que 25-30 ko sur le réseau.

5. HTTP/3 — la nouvelle génération du Web

Sur les distributions modernes (EL 9 et EL 10), WSA peut compiler nginx avec le support HTTP/3 (QUIC).

Qu'est-ce qu'HTTP/3 ?

HTTP/3 est le protocole de troisième génération du Web, successeur d'HTTP/2. Ses avantages principaux :

Connexion plus rapide — HTTP/3 utilise UDP et peut établir une connexion en un seul aller-retour réseau, contre 2 à 3 pour HTTP/2 sur TLS.
Pas de blocage de tête de file — Plusieurs requêtes parallèles ne se bloquent plus entre elles si un seul paquet est perdu.
Mobile-friendly — Les changements de réseau (WiFi → 4G, par exemple) n'interrompent plus la connexion.

Comment c'est activé dans WSA

L'administrateur du serveur clique sur Build HTTP/3 dans l'onglet Nginx Build & Modules du WHM. WSA :

Télécharge les sources officielles de nginx et QuicTLS.
Vérifie les sommes SHA256 pour garantir l'intégrité.
Compile un binaire nginx personnalisé avec --with-http_v3_module.
Remplace le binaire système, garde une copie de sauvegarde.
Ouvre le port UDP/443 dans le pare-feu (CSF ou firewalld).
Redémarre nginx.

Une fois installé, l'administrateur active ensuite l'émission QUIC par vhost (envoi de listen 443 quic; + en-tête Alt-Svc). Les visiteurs sur navigateurs modernes basculent automatiquement vers HTTP/3 ; les autres restent sur HTTP/2.

Sécurité du build

Le module surveille en arrière-plan les nouvelles versions de nginx (CVE-2026-42926, CVE-2026-40460, etc.) et propose une reconstruction automatique quand un correctif de sécurité est publié. L'administrateur garde le contrôle total : aucune recompilation ne se déclenche sans son accord.

6. Intégration complète sans casser les sites

C'est probablement la qualité la plus importante de WSA : l'installation n'affecte aucun site existant. Aucun client n'a besoin de modifier son code, son .htaccess, ses cookies, ses thèmes ou ses extensions.

Détection automatique

WSA détecte automatiquement les configurations sensibles :

Sites WordPress — Les utilisateurs connectés contournent la cache (cookies wordpress_logged_in_* détectés).
WooCommerce — Le panier, la caisse et le compte client contournent la cache (cookies woocommerce_cart_hash, URI /cart, /checkout, /my-account).
Sites e-commerce divers — Les patterns PrestaShop, Magento, OpenCart sont préconfigurés.
PHP générique — Les cookies PHPSESSID et équivalents sont reconnus.

Sécurité par défaut

Une page contenant des données personnelles d'un utilisateur n'est jamais mise en cache et servie à un autre :

Si un cookie de session est présent, la requête contourne la cache.
Si la réponse contient Set-Cookie, la réponse n'est pas stockée.
Si l'application envoie Cache-Control: no-cache ou Cache-Control: private, par défaut WSA respecte la directive.

Migration transparente

Sur un serveur existant avec 500+ sites en production, l'installation de WSA :

Ne modifie aucun fichier dans les comptes cPanel.
N'interrompt pas Apache — la transition se fait par basculement des ports (Apache passe de 80/443 à 8080/8443, nginx prend les ports publics).
Ne touche pas aux certificats SSL — WSA lit les certificats déjà installés par AutoSSL ou Let's Encrypt.
Préserve les en-têtes HTTP personnalisés émis par les applications.

Réversibilité

Si pour une raison quelconque WSA doit être désinstallé, l'opération restaure intégralement la configuration Apache d'origine. Les comptes cPanel ne s'en aperçoivent pas — leurs sites continuent de fonctionner comme avant.

7. Protection contre les robots indésirables

WSA inclut une couche de filtrage des User-Agents qui bloque, au niveau nginx, les requêtes des robots qui consomment des ressources sans bénéfice pour les sites :

Catégorie	Exemples	Bloqué par défaut
Robots d'entraînement IA	GPTBot, ClaudeBot, Bytespider, CCBot	✅
Scanners de vulnérabilités	Nikto, sqlmap, Wfuzz, ZAP	✅
User-Agents falsifiés	Chrome inexistant, Firefox impossible	✅
User-Agent vide	requêtes sans en-tête `User-Agent`	✅
IA assistants (recherche live)	ChatGPT lookup, Perplexity	❌ (autorisé)
IA tools utilisateur	extensions de navigateur IA	❌ (autorisé)
Spiders SEO	AhrefsBot, SemrushBot, MJ12bot	❌ (autorisé)

Chaque administrateur peut modifier ces listes globalement depuis le WHM ; chaque client cPanel peut outrepasser la politique du serveur sur ses propres domaines (autoriser un robot bloqué globalement, ou bloquer un robot autorisé globalement).

Économie de ressources mesurable

Sur un serveur avec 500+ sites WordPress, le filtrage des robots IA seuls représente typiquement 5 à 15 % de bande passante économisée et une charge serveur équivalente libérée — sans aucun impact négatif sur les vrais visiteurs ou le référencement des moteurs de recherche légitimes (Google, Bing, DuckDuckGo ne sont jamais bloqués).

8. Architecture en trois couches

WSA est volontairement modulaire :

   ┌─────────────────────────────────────────────────────────┐
   │  WHM (administrateur)                                   │
   │  /usr/local/cpanel/whostmgr/docroot/cgi/wsa/            │
   │  - Configuration globale du serveur                     │
   │  - Modules nginx (Brotli, HTTP/3)                       │
   │  - Inventaire des comptes + actions en masse            │
   └────────────────────────┬────────────────────────────────┘
                            │
                            ▼
   ┌─────────────────────────────────────────────────────────┐
   │  Coeur du module                                        │
   │  /etc/wsa/                                              │
   │  - Démon wsad (surveillance changements config)         │
   │  - Tâches cron internes                                 │
   │  - Génération des configurations nginx                  │
   │  - Base SQLite (paramètres, état)                       │
   └────────────────────────┬────────────────────────────────┘
                            │
                            ▼
   ┌─────────────────────────────────────────────────────────┐
   │  cPanel (client final)                                  │
   │  /usr/local/cpanel/base/frontend/jupiter/wsa/           │
   │  - Configuration par compte cPanel                      │
   │  - Mode simple ou avancé                                │
   │  - Personnalisation par domaine et sous-domaine         │
   └─────────────────────────────────────────────────────────┘

L'administrateur garde toujours le dernier mot sur la politique globale, mais chaque client peut personnaliser ses propres domaines dans les limites définies.

9. En résumé

Bénéfice	Pour qui ?
Sites plus rapides (5-20 ms en cache vs 200-1000 ms)	Visiteurs des sites
Moins de charge Apache/PHP/MySQL (60-90 % en moins)	Administrateur serveur
Compression Brotli et Gzip transparente	Visiteurs et serveur
HTTP/3 sur EL 9 et EL 10	Visiteurs (latence réduite, mobile)
Protection contre les robots indésirables	Tout le monde (moins de spam, moins de charge)
Configuration par domaine en cPanel	Clients du serveur
Aucune modification requise dans les sites	Clients du serveur
Installation et désinstallation sans casser les sites	Administrateur serveur

Pour aller plus loin

Installation et prérequis — Comment installer WSA sur votre serveur cPanel.
Configuration WHM — Le panneau administrateur.
Configuration cPanel — Le panneau client.
Optimisation — Tirer le maximum de WSA.