Notes de version

Résumé accessible des principales versions de WSA.

Cette page résume les principales versions de WSA en termes accessibles. Pour le détail technique complet de chaque release (changements de code, correctifs précis, migrations internes), consultez le RELEASE.md du dépôt source.

Version 2.3.10 — 22 juillet 2026

🛡️ Correctif de fiabilité (côté cPanel). La page Website Accelerator visible par le client ne perd plus de réglages de cache dans les cas limites où cela pouvait arriver en silence, et l'éditeur avancé ne perd plus d'entrées et ne se fige plus.

Ce qui change

Vos réglages sont préservés. Un fichier de configuration comportant un seul champ périmé n'est plus supprimé — il est conservé et complété depuis les valeurs par défaut. Seul un fichier réellement illisible est mis de côté (copie .bad) pour que le support puisse l'examiner. Un fichier corrompu n'est plus non plus remplacé par un gabarit vide qui effaçait tous les réglages.
Un seul mauvais fichier ne casse plus toute la page. Auparavant, un unique fichier par-domaine illisible pouvait vider toute la page de mise en cache ; désormais seul ce fichier est concerné.
Les règles de contournement WooCommerce / paiement tiennent. Les règles livrées contenant = (comme add-to-cart=, wc-api=) ne sont plus supprimées en silence à l'enregistrement — ce qui avait laissé le cache servir des URL de panier et de rappel de paiement.
L'éditeur est plus stable. La fenêtre d'édition ne s'ouvre qu'une fois ses données réellement chargées (un chargement lent ou échoué ne peut plus enregistrer dans le mauvais domaine), les listes de contournement CSS/JS et Images/Polices peuvent maintenant être vidées, et le bouton Enregistrer ne reste plus bloqué sur « Enregistrement… » après un incident réseau — il affiche une erreur claire.

Qui est concerné

Les utilisateurs cPanel qui modifient leurs réglages de cache — chaque cas ci-dessus est plus sûr. Aucun changement visible sur une configuration saine ; la différence n'apparaît que lorsqu'un fichier était corrompu ou qu'une requête a échoué.

Mise à jour

Les serveurs avec Auto Update activé reçoivent la mise à jour sous 24 h. Pour appliquer maintenant :

/etc/wsa/wsa --update --verbose

Version 2.3.9 — 22 juillet 2026

🔧 Correctif d'affichage. Dans WHM → Module Configuration, le contrôle Release Tier affiche maintenant la vraie version disponible de chaque canal.

Ce qui change

Release Tier affiche la vraie version de chaque canal. Les numéros de version à côté de Stable / Current / Edge / Dev étaient faux — un serveur avait tendance à afficher sa propre version installée pour tous les canaux. Le module lit désormais la version de chaque canal depuis son manifeste de version signé et affiche les quatre ; un canal qu'il ne peut pas vérifier n'affiche aucun numéro plutôt qu'un mauvais.

Qui est concerné

Tous les serveurs : le contrôle Release Tier de WHM est maintenant exact. Les numéros se rafraîchissent à la cadence normale de vérification de licence du module (aucune action requise).

Mise à jour

Les serveurs avec Auto Update activé reçoivent la mise à jour sous 24 h. Pour appliquer maintenant :

/etc/wsa/wsa --update --verbose

Version 2.3.8 — 22 juillet 2026

🛡️ Release de stabilité. L'ensemble des findings prioritaires d'un audit de code interne : les rebuilds sont désormais complètement sérialisés, la file de commandes est sans perte, un rebuild raté restaure une configuration fonctionnelle, les renouvellements SSL sont doux pour nginx, les rebuilds HTTP/3 par compte sont sûrs, le planificateur ne peut plus être figé par un crash, et une mauvaise lecture de la config Apache ne peut plus effacer vos sites.

Ce qui change

Les rebuilds ne s'exécutent plus les uns par-dessus les autres. Chaque source pouvant déclencher un rebuild — sauvegardes du panneau de contrôle, renouvellements SSL, tâches planifiées, boutons WHM — passe désormais par une porte atomique unique. Deux rebuilds ne peuvent plus s'entrelacer et corrompre la configuration nginx générée, et un long rebuild ne se fait plus « voler » son verrou en plein travail.
Les commandes de cache et de purge ne peuvent plus être perdues en silence. Une commande envoyée pendant qu'une autre opération se terminait pouvait auparavant être jetée sans jamais s'exécuter (l'interface affichait pourtant un succès). La file de commandes garantit maintenant que chaque commande acceptée est exécutée, exactement une fois.
Les renouvellements SSL ne redémarrent plus nginx à chaque certificat. Le balayage AutoSSL nocturne redémarrait nginx durement pour chaque certificat renouvelé, coupant les connexions actives. Les renouvellements utilisent désormais un rechargement gracieux (zéro connexion coupée), et un balayage complet est fusionné en un seul rebuild.
Les actions WHM sont plus robustes. Fermer l'onglet du navigateur ne tue plus un build ou une mise à niveau en cours, et double-cliquer un bouton (ou une seconde session WHM) ne peut plus lancer deux fois la même opération destructive — une bannière claire « opération déjà en cours » s'affiche à la place.
Les fichiers nginx générés sont écrits de façon atomique. Un crash ou un disque plein en pleine écriture ne peut plus laisser un fichier de configuration tronqué sur le disque, et une entrée malformée dans une liste de bots ne peut plus casser le test de configuration nginx sur tout le serveur.
Serveurs HTTP/3 : reconstruire un seul compte ne peut plus casser tout le serveur. Sur les serveurs avec le build HTTP/3 et des IP partagées, régénérer la configuration d'un seul compte pouvait produire une option de socket bas niveau en double qui faisait échouer le test de configuration nginx pour tous les sites. L'option vit désormais dans un unique fichier géré par le serveur et maintenu à jour à chaque rebuild — les rebuilds par compte sont toujours sûrs.
Un rebuild raté restaure maintenant une configuration fonctionnelle. Quand une régénération de configuration produit quelque chose que nginx rejette, WSA ramène désormais les fichiers touchés à leur dernière version connue-bonne au lieu de laisser des fichiers cassés sur le disque — ceux-ci pouvaient auparavant faire tomber tous les sites au prochain redémarrage du serveur ou à la rotation des logs. Si la configuration d'un seul compte est en cause, seul ce compte est isolé (et clairement rapporté avec la commande de réparation) ; les mises à jour des autres s'appliquent quand même. La réparation SSL automatique fonctionne aussi désormais pour tous les noms de domaine (elle sautait auparavant tout domaine contenant un chiffre ou un tiret).
Une mauvaise lecture de la configuration Apache ne peut plus faire tomber tous les sites. Si la configuration Apache du serveur était momentanément absente ou saisie en pleine réécriture, WSA pouvait l'interpréter comme « tous les comptes ont été supprimés » et effacer la configuration de tous les sites. Il refuse désormais d'agir sur une lecture incomplète, et un vrai changement de grande ampleur (ex. suppression de comptes en masse) n'est appliqué qu'après confirmation qu'il est stable — une lecture transitoirement mauvaise se répare d'elle-même au lieu de provoquer une panne.
Un crash ne peut plus désactiver définitivement les tâches planifiées de WSA. Le planificateur interne (celui qui ranime un Apache mort, vérifie les mises à jour de sécurité nginx et rafraîchit les statistiques de bots) utilisait un fichier de verrou qu'un crash en plein travail pouvait laisser derrière pour toujours, stoppant silencieusement toutes les tâches planifiées jusqu'à suppression manuelle du fichier. Le verrou est désormais géré par le noyau et toujours libéré à la fin du processus, quelle qu'en soit la cause — et un serveur déjà coincé de la sorte se répare de lui-même au premier passage après la mise à jour.

Qui est concerné

Tous les serveurs en bénéficient ; les serveurs multi-tenants occupés avec des renouvellements AutoSSL fréquents — et les serveurs avec le build HTTP/3 — en profitent le plus. Aucune action requise au-delà de la mise à jour.

Mise à jour

Les serveurs avec Auto Update activé reçoivent la mise à jour sous 24 h. Pour appliquer maintenant :

/etc/wsa/wsa --update --verbose

Version 2.3.7 — 20 juillet 2026

🔧 Correctif de fiabilité. La mise à jour d'nginx gérée par WSA réussit maintenant sur les serveurs avec Brotli activé, et le sélecteur Release Tier affiche le bon canal.

Ce qui change

La mise à jour d'nginx n'échoue plus sur les serveurs Brotli. Sur un serveur avec la compression Brotli activée, le flux « Upgrade nginx » (celui qui reconstruit Brotli de façon atomique) échouait à son test de sécurité et s'arrêtait — nginx n'était jamais redémarré, donc aucune interruption, mais la mise à jour de sécurité ne pouvait pas aboutir par ce chemin. Il reconstruit désormais le module Brotli contre le nouveau nginx avant le test de sécurité, si bien que la mise à jour passe. À associer à la mise à jour de sécurité nginx 1.30.4 de la 2.3.6.
Release Tier affiche maintenant le canal de votre build. Dans WHM → Module Configuration, le sélecteur Release Tier affichait Stable par défaut même sur un build Edge/Current/Dev (et sauvegarder la page pouvait basculer le serveur sur les mises à jour Stable). Il reflète maintenant le canal réellement suivi par le build ; un choix explicite que vous avez fait est préservé.

Qui est concerné

Serveurs nginx stock + Brotli : la mise à jour d'nginx gérée par WSA vers 1.30.4 aboutit maintenant au lieu d'avorter.
Serveurs Edge / Current / Dev : le Release Tier est affiché correctement et ne risque plus d'être remis à Stable à la sauvegarde.

Mise à jour

Les serveurs avec Auto Update activé reçoivent la mise à jour sous 24 h. Pour appliquer maintenant :

/etc/wsa/wsa --update --verbose

Version 2.3.6 — 20 juillet 2026

🔒 Release de sécurité. Met à jour la version épinglée d'nginx HTTP/3 vers 1.30.4, corrigeant trois vulnérabilités mémoire.

Ce qui change

nginx 1.30.4 (CVE-2026-42533, CVE-2026-60005, CVE-2026-56434) — la version d'nginx HTTP/3 épinglée passe à 1.30.4, corrigeant trois problèmes de sûreté mémoire dans un processus worker : un dépassement de tampon (heap overflow) via la directive map avec captures regex, un accès à de la mémoire non initialisée via la directive slice / la mise à jour de cache en arrière-plan, et un use-after-free dans le filtre SSI lors du traitement d'une réponse proxifiée forgée. La source téléchargée est vérifiée par signature PGP contre la clé officielle d'nginx avant d'être approuvée.
Rafraîchissement de la librairie d'activation — le SDK d'activation partagé livré avec WSA est resynchronisé vers sa version courante (ajout rétrocompatible de deux capacités utilisées par le pont d'activation multi-produits). Aucun changement visible du comportement de licence.

Qui est concerné

Tous les serveurs reçoivent la mise à jour de sécurité — aucune action requise au-delà de la mise à jour.
Les serveurs avec build HTTP/3 (EL 9 / EL 10 avec QUIC) : le tableau de bord signale le build HTTP/3 comme Rebuild needed pour nginx 1.30.4.

Mise à jour

Les serveurs avec Auto Update activé reçoivent la mise à jour sous 24 h. Pour appliquer maintenant :

/etc/wsa/wsa --update --verbose
/etc/wsa/wsa --rebuild-forced --verbose
# Serveurs avec build HTTP/3, pour recompiler avec 1.30.4 :
/etc/wsa/wsa --http3-rebuild --verbose

Version 2.3.4 — 19 juin 2026

🔧 Correctif de fiabilité d'installation. Une installation fraîche en une commande s'active maintenant immédiatement, et un module Brotli laissé par une installation précédente ne peut plus faire échouer nginx.

Ce qui change

Le module s'active dès la fin d'une installation fraîche. Auparavant, une toute nouvelle installation en une commande pouvait rester désactivée même si la licence s'était activée correctement — wsa --enable indiquait « un autre processus est en cours », et le module ne s'activait que 2 à 3 minutes plus tard, à la première tâche planifiée. WSA réconcilie désormais l'état de sa licence immédiatement après l'activation, de sorte que l'installeur active le module sur-le-champ.
Un module Brotli résiduel ne peut plus faire échouer nginx lors d'une réinstallation. Si une installation WSA précédente avait laissé un module Brotli compilé pour une autre version d'nginx, une réinstallation pouvait faire échouer le test de configuration d'nginx (…version 1030002 instead of 1030003) et bloquer le démarrage. WSA (a) ne charge plus jamais un module Brotli qu'il ne peut pas vérifier, et (b) supprime tout module Brotli orphelin à la fois à l'installation et à la désinstallation.

Qui est concerné

Les nouvelles installations et les réinstallations — l'installeur en une commande s'active maintenant sans le délai de 2 à 3 minutes, et réinstaller par-dessus une version antérieure ne risque plus un échec d'nginx -t.
Les serveurs existants — rien à faire ; la mise à jour applique les deux correctifs.

Mise à jour

Relancer l'installeur en une commande (ou wsa --update) applique les deux correctifs. Les serveurs avec Auto Update activé le reçoivent sous 24 h. Pour appliquer maintenant :

/etc/wsa/wsa --update --verbose

Version 2.3.1 — 17 juin 2026

🔒 Release de sécurité et de fiabilité. nginx 1.30.3 (deux CVE), une chaîne d'installation/mise à jour durcie, et une installation plus rapide et plus sûre qui ne compile plus Brotli.

Ce qui change

nginx 1.30.3 (CVE-2026-42055, CVE-2026-48142) — la version d'nginx HTTP/3 épinglée passe à 1.30.3, corrigeant deux vulnérabilités mémoire : un dépassement de tampon (buffer overflow) lors du proxy d'une requête forgée vers un backend HTTP/2 ou gRPC, et une lecture hors limites (buffer overread) via la directive charset_map. La source téléchargée est maintenant vérifiée par signature PGP contre la clé officielle d'nginx au moment de l'épinglage.
Chaîne d'installation et de mise à jour durcie — à la suite d'un audit de sécurité complet du module, les chemins d'installation et de mise à jour ont été renforcés : le composant qui vérifie les signatures de mise à jour est désormais verrouillé en intégrité (il ne peut plus être substitué sur le réseau), un ancien chemin de mise à jour non vérifié a été retiré, et un cas d'élévation de privilèges locale a été corrigé. Transparent — rien à faire.
Installation plus rapide et plus sûre — Brotli n'est plus compilé pendant l'installation. Une installation fraîche se contente désormais de déployer et d'activer WSA. Brotli se construit à la demande ensuite, depuis WHM → Nginx Build & Modules (ou wsa --nginx-install=brotli). Cela retire l'étape la plus longue et la plus sujette aux échecs de l'installeur.
Un module Brotli incompatible ne peut plus faire tomber nginx. Si le module Brotli présent sur le disque a été compilé pour un nginx différent de celui en cours d'exécution (par ex. après une mise à jour d'nginx), WSA évite maintenant de le charger au lieu de laisser nginx -t échouer — vos sites restent en ligne jusqu'à ce que vous reconstruisiez Brotli.

Qui est concerné

Tous les serveurs reçoivent les améliorations de sécurité et de fiabilité à la mise à jour — aucune action requise.
Les serveurs avec build HTTP/3 (EL 9 / EL 10 avec QUIC) : le tableau de bord signalera le build HTTP/3 comme Rebuild needed pour nginx 1.30.3.
Les nouvelles installations ne demandent plus pour Brotli pendant l'installation ; construisez-le depuis WHM quand vous le souhaitez (les drapeaux d'installation --with-brotli / --skip-brotli ont disparu).

Mise à jour

Les serveurs avec Auto Update activé reçoivent la mise à jour sous 24 h. Pour appliquer maintenant :

/etc/wsa/wsa --update --verbose
/etc/wsa/wsa --rebuild-forced --verbose
# Serveurs avec build HTTP/3, pour recompiler avec 1.30.3 :
/etc/wsa/wsa --http3-rebuild --verbose

Version 2.2.15 — 15 juin 2026

🖼️ Correctif : images d'infolettre bloquées dans Gmail. Une nouvelle liste blanche de proxys de confiance exempte le proxy d'images de Gmail — et tout autre proxy de première partie que vous approuvez — de la Bot Protection.

Ce qui change

Le proxy d'images de Gmail est autorisé par défaut — Quand un destinataire ouvre une infolettre HTML dans Gmail, Google charge chaque image via son proxy d'images (GoogleImageProxy), qui présente un ancien User-Agent « Windows XP / Firefox 11 ». Ce User-Agent correspondait à la règle de blocage User-Agents falsifiés, donc les images étaient rejetées avec un 444 et ne s'affichaient pas dans les boîtes Gmail. WSA livre maintenant une liste blanche de proxys de confiance qui exempte GoogleImageProxy de toutes les catégories de Bot Protection, pour que les images d'infolettre se chargent de nouveau.
Éditable dans WHM — Une nouvelle Liste blanche de proxys de confiance apparaît dans l'onglet Configuration Nginx → Bot Protection : un interrupteur maître On/Off plus une liste de jetons éditable, pré-remplie avec GoogleImageProxy. Ajoutez d'autres proxys ou récupérateurs légitimes au besoin (ex. FeedFetcher-Google).
Sûr par conception — Les jetons correspondent comme des sous-chaînes littérales insensibles à la casse ; la liste blanche contourne uniquement la Bot Protection, jamais les contrôles de volume du rate-limit (un User-Agent est trivialement falsifiable). Pour désactiver entièrement la liste blanche, utilisez son interrupteur maître — vider la liste seule revient au défaut livré GoogleImageProxy.

Qui est concerné

Les serveurs avec la Bot Protection activée (la catégorie User-Agents falsifiés est active par défaut) qui hébergent des infolettres courriel HTML : le correctif d'affichage Gmail s'applique dès que la nouvelle configuration est générée. Aucune action requise — GoogleImageProxy est autorisé d'emblée.
Les opérateurs qui veulent autoriser d'autres proxys de première partie peuvent éditer la liste dans WHM → Configuration Nginx → Bot Protection.

Mise à jour

Les serveurs avec Auto Update activé reçoivent la mise à jour sous 24 h, après quoi un rebuild de configuration applique la liste blanche. Pour appliquer maintenant :

/etc/wsa/wsa --update --verbose
/etc/wsa/wsa --rebuild-forced --verbose

Version 2.2.3 — 22 mai 2026

🔒 Release de sécurité. Met à jour la version épinglée d'nginx HTTP/3 vers 1.30.2.

Ce qui change

nginx 1.30.2 (CVE-2026-9256) — corrige un dépassement de tampon mémoire (heap buffer overflow) dans un processus worker, déclenchable par une configuration utilisant des captures qui se chevauchent dans ngx_http_rewrite_module. La vulnérabilité pouvait potentiellement permettre l'exécution de code arbitraire. Découverte et rapportée par Mufeed VH (Winfunc Research).

Qui est concerné

Les serveurs qui utilisent le build personnalisé WSA HTTP/3 (EL 9 / EL 10 avec QUIC activé) : mise à jour recommandée dès que possible.
Les serveurs utilisant le paquet RPM nginx standard : la mise à jour passe par votre gestionnaire de paquets — le bouton Upgrade nginx dans WHM (Nginx Build & Modules) détectera la nouvelle version automatiquement.

Mise à jour

Les serveurs avec Auto Update activé recevront le nouveau pin dans les 24 heures. Une fois le pin appliqué, le tableau de bord signalera le build HTTP/3 comme Rebuild needed — cliquer sur Rebuild dans la page Nginx Build & Modules (ou lancer wsa --http3-rebuild --verbose en ligne de commande) pour recompiler avec 1.30.2.

Pour forcer la mise à jour du module WSA immédiatement :

/etc/wsa/wsa --update --verbose
/etc/wsa/wsa --http3-rebuild --verbose

Version 2.2.0 — Mai 2026

🚀 Première release stable de la série 2.2. Refonte complète de l'interface WHM et de la couche de protection contre les robots.

Ce qui change pour les administrateurs

Nouveau tableau de bord WHM — Toutes les informations importantes (état de la cache, version nginx, modules installés, statistiques de blocage des robots, comptes problématiques) sont maintenant rassemblées sur une seule page d'accueil. Plus besoin de naviguer entre 5-6 menus pour diagnostiquer un problème.
Inventaire des comptes — Liste de tous les comptes cPanel avec leur profil de cache actuel, filtre et recherche intégrés. Application en masse de profils (Default/None/Custom) à des dizaines de comptes en un clic. Export CSV pour la facturation ou la documentation.
Page Nginx Build & Modules — Gestion centralisée du binaire nginx : choix entre le paquet RPM standard et le build WSA personnalisé (avec HTTP/3), reconstruction Brotli, vérification des versions épinglées vs versions installées.
Validation visuelle en direct — Tous les champs de configuration valident maintenant la saisie au fur et à mesure (bordure rouge, info-bulle d'aide) plutôt qu'au moment de la sauvegarde.
Restauration des valeurs par défaut — Chaque option affiche désormais sa valeur par défaut à côté du champ, avec un bouton ↺ pour revenir au défaut en un clic.

Ce qui change pour les clients cPanel

Catégories de robots élargies — La protection contre les robots passe de 4 à 8 catégories. Les IA sont maintenant séparées entre assistants de recherche (autorisés par défaut, ils aident vos visiteurs), outils utilisateurs (autorisés, déclenchés par un humain) et robots d'entraînement (bloqués, ils consomment des ressources sans bénéfice).
Édition par sous-domaine — Vous pouvez désormais personnaliser la cache pour chaque sous-domaine indépendamment, sans toucher au domaine principal.
Listes personnalisées de bots par domaine — Vous pouvez ajouter ou retirer des bots spécifiques de la liste de blocage, sur un seul de vos domaines, sans affecter les autres.
Avertissement liste vide — Si vous bloquez une catégorie de bots mais videz la liste, un message vous explique que la liste vide n'équivaut PAS à « ne rien bloquer » — utilisez Autorisé pour ça.

Corrections de bugs notables

Boutons d'action fonctionnels — Les boutons « Rebuild Nginx conf », « Restart Nginx », « Clear all caches » et « Disable WSA » du tableau de bord WHM ne « tombaient » plus silencieusement sans rien faire.
Suivi en direct de l'activation HTTP/3 — Quand un administrateur active l'émission QUIC, la sortie de la reconstruction des vhosts est désormais visible en temps réel (avant : page bloquée 60 secondes sans feedback).
Icône WSA dans cPanel — Sur les installations fraîches, l'icône WSA apparaît immédiatement dans la liste des applications cPanel (avant : pouvait nécessiter une intervention manuelle après l'installation).
Utilisation de la cache — Sur les serveurs multi-tenants avec cache par utilisateur, la tuile « Cache Utilisation » du tableau de bord affiche maintenant la vraie utilisation (avant : toujours 0 même avec 600+ sites en cache).
Sécurité renforcée — Validation regex côté serveur sur toutes les listes d'exclusion (URI, cookies, User-Agents). Aucune injection possible via la configuration.

Mise à jour

La mise à jour vers 2.2.0 ne nécessite aucune intervention. Aucun site n'est affecté. Aucun paramètre n'est perdu — les configurations existantes sont automatiquement migrées vers le nouveau format de l'interface.

Les serveurs qui activaient Auto Update recevront la mise à jour automatiquement dans les 24 heures. Pour forcer maintenant :

/etc/wsa/wsa --update --verbose

Version 2.1 — Avril-Mai 2026

Série de releases incrémentales qui ont apporté :

Protection contre les robots v2 — Refonte complète de la gestion des User-Agents bloqués (édition par domaine, granularité fine par catégorie IA).
Recovery banner HTTP/3 — Détection automatique quand une mise à jour dnf remplace le binaire WSA HTTP/3 par le paquet standard, avec proposition de reconstruction.
Support EL 10 — Compatibilité avec AlmaLinux 10, Rocky Linux 10 et RHEL 10.
Détection ABI drift — Détection automatique des changements d'ABI nginx qui invalideraient le module Brotli, avec reconstruction proposée.

Version 2.0 — Mars 2026

Première release avec support HTTP/3 (QUIC) :

Construction d'un binaire nginx personnalisé avec --with-http_v3_module depuis les sources officielles + QuicTLS.
Vérification SHA256 des tarballs téléchargés (sécurité).
Activation et désactivation de QUIC par vhost via le WHM.
Ouverture automatique du port UDP/443 (CSF ou firewalld).

Version 1.5 — Fin 2025

Compilation Brotli intégrée — Brotli est désormais compilé comme module dynamique nginx par WSA directement, sans dépendre d'un paquet RPM tiers.
Surveillance dnf — Détection quotidienne des nouvelles versions nginx disponibles via dnf, avec proposition de mise à jour depuis le WHM.

Version 1.4 — Été 2025

Bot Protection v1 — Première version du filtrage User-Agent : 4 catégories (IA, scanners, SEO, no-agent), paramétrage global via WHM, log des requêtes bloquées.

Version 1.3 — Printemps 2025

Cache par utilisateur (induser_enable) — Chaque compte cPanel obtient sa propre zone de cache, isolée des autres. Améliore la fairness multi-tenant et le contournement par cookie.
Mode avancé refondu — Le panneau cPanel passe d'un monolithe à des onglets clairs (Basique, Bot Protection, Dynamique, JS/CSS, Images & Polices).

Versions plus anciennes

Pour le détail des versions 0.x à 1.2, voir le RELEASE.md historique du dépôt. Les éléments majeurs :

1.x — Stabilisation, support EL 8, intégration EasyApache 4.
0.x — Premières versions, support EL 7, intégration cPanel initiale, ports basés sur AutoSSL.

Politique de support

Version majeure	Support actif	Correctifs de sécurité
2.3.x	✅ développement actif	✅
2.2.x	✅ correctifs uniquement	✅
2.1.x	⚠️ correctifs critiques uniquement	✅
2.0.x	⚠️ correctifs critiques uniquement	✅
1.x	❌ fin de support	❌

Les serveurs en version 1.x doivent migrer vers la branche 2.x. La mise à jour est sans risque — toutes les configurations existantes sont préservées.

Pour aller plus loin

Procédure de mise à jour — Comment mettre à jour vers la dernière version.
Configuration du module — Choisir la branche de release (stable vs current vs edge).