LiteSpeed Hosting et gestion des versions PHP : un guide technique complet pour les utilisateurs d’AlexHost

Choisir la bonne version PHP pour votre environnement d’hébergement est l’une des décisions les plus importantes lors du déploiement d’une application web. Une mauvaise version peut dégrader silencieusement les performances, introduire des vulnérabilités de sécurité ou rompre entièrement la compatibilité avec les frameworks. L’hébergement mutualisé LiteSpeed d’AlexHost prend en charge PHP 7.3, 7.4, 8.0 et 8.1 simultanément, vous permettant d’attribuer différentes versions PHP par domaine via le MultiPHP Manager de cPanel — sans toucher aux fichiers de configuration du serveur ni ouvrir un ticket de support.

Ce guide explique ce que chaque version PHP apporte réellement au niveau du moteur, comment changer correctement de version sur l’infrastructure AlexHost, et comment éviter les pièges courants qui causent des défaillances d’application après un changement de version.

Pourquoi le choix de la version PHP est plus important que la plupart des développeurs ne le réalisent

PHP n’est pas un runtime monolithique. Chaque version majeure et mineure modifie le comportement du Zend Engine, déprécie des fonctions, altère les règles de coercition de type et modifie la façon dont l’OPcache et le compilateur JIT interagissent avec votre code. Exécuter du code PHP 7.3 sur PHP 8.1 sans tests n’est pas une mise à niveau sûre — c’est un pari avec votre environnement de production.

LiteSpeed Web Server gère l’exécution PHP via LSAPI (LiteSpeed Server Application Programming Interface), qui est architecturalement distinct du mod_php ou FastCGI d’Apache. LSAPI maintient des processus worker PHP persistants, éliminant la surcharge de création de processus par requête qui pèse sur les configurations traditionnelles. Le résultat est un temps jusqu’au premier octet (TTFB) mesurément plus faible et des cycles CPU significativement réduits par requête — particulièrement important pour les applications PHP intensives comme WordPress, Magento ou Laravel.

Lorsque vous combinez LSAPI de LiteSpeed avec le MultiPHP Manager de cPanel, vous obtenez une isolation de version PHP par domaine au niveau du processus, pas seulement au niveau de la configuration. C’est une distinction critique pour les agences ou les développeurs hébergeant plusieurs sites clients sur un seul compte d’Hébergement Web Mutualisé.

Comparaison des versions PHP : matrice des fonctionnalités et de la sécurité

Conclusion clé de ce tableau : PHP 7.3 et 7.4 ont dépassé leurs dates officielles de fin de vie. Ils ne doivent être utilisés que lorsqu’une application legacy a des dépendances strictes qui ne peuvent pas être résolues — pas comme choix par défaut pour les nouveaux déploiements.

PHP 7.3 : stabilité legacy avec des limitations connues

PHP 7.3 était une version axée sur la maintenance qui a introduit array_key_first(), array_key_last(), la syntaxe heredoc/nowdoc flexible et la fonction is_countable(). Il représentait une plateforme stable pour les applications fonctionnant sur PHP 5.x et nécessitant un chemin de migration sans refactorisation agressive.

Réalité opérationnelle critique : PHP 7.3 a atteint sa fin de vie en décembre 2021. Il ne reçoit aucun correctif de sécurité du projet PHP. L’utiliser en production signifie que toute vulnérabilité nouvellement découverte dans le Zend Engine ou les extensions principales restera non corrigée. La seule raison légitime d’utiliser PHP 7.3 sur AlexHost aujourd’hui est de maintenir une application legacy pendant qu’une migration vers PHP 8.x est activement en cours.

Cas d’utilisation courant : Anciennes installations Joomla 3.x, applications legacy CodeIgniter 3, ou bases de code personnalisées de l’ère PHP 5.6 qui n’ont pas été mises à jour pour utiliser les déclarations de type modernes.

PHP 7.4 : le dernier de la branche 7.x — utile pour les déploiements transitionnels

PHP 7.4 était la version finale de la branche PHP 7 et a introduit plusieurs fonctionnalités qui ont rendu le code significativement plus maintenable et performant sans nécessiter les changements cassants venus avec PHP 8.0.

Les propriétés de classe typées vous permettent d’imposer des contraintes de type au niveau de la classe :

class User {
    public int $id;
    public string $email;
    public ?DateTime $lastLogin;
}

Cela élimine toute une catégorie d’erreurs d’exécution qui ne se manifestaient auparavant que sous des chemins d’exécution spécifiques.

Les fonctions fléchées réduisent la verbosité des courtes closures, particulièrement utiles dans les opérations sur les tableaux :

$multiplied = array_map(fn($n) => $n * 2, $numbers);

Le préchargement OPcache (introduit en 7.4) est architecturalement significatif : il permet à PHP de charger et compiler un ensemble de fichiers en mémoire partagée au démarrage du serveur, rendant ces fichiers disponibles à tous les processus worker sans compilation répétée. Sur LiteSpeed avec LSAPI, cela amplifie le bénéfice de performance car les workers persistants évitent déjà la surcharge de création de processus.

PHP 7.4 a atteint sa fin de vie en novembre 2022. Il convient aux installations WordPress exécutant des plugins plus anciens avec des incompatibilités PHP 8.x connues, ou pour les déploiements Drupal 7 en attente de migration.

PHP 8.0 : le point d’inflexion architectural

PHP 8.0 n’était pas une version incrémentale. Il a introduit des changements qui ont fondamentalement modifié la façon dont le code PHP est écrit, exécuté et raisonné. Plusieurs comportements de longue date ont été modifiés ou supprimés, en faisant une mise à niveau cassante pour les bases de code qui reposaient sur la coercition de type souple ou les fonctions dépréciées.

Compilation Just-In-Time

Le compilateur JIT de PHP 8.0 compile les chemins de code fréquents en code machine natif à l’exécution, contournant l’interprétation répétée. Dans les charges de travail liées au CPU — calculs mathématiques, traitement d’images, pipelines de transformation de données — le JIT peut apporter des accélérations substantielles. Cependant, pour les applications web typiques liées aux I/O (requêtes de base de données, lectures de fichiers, appels API), le bénéfice du JIT est souvent marginal car le goulot d’étranglement n’est pas l’exécution CPU mais l’attente de ressources externes.

Comprendre cette distinction évite l’erreur courante d’attendre que le JIT accélère automatiquement un site WordPress. Ce ne sera pas le cas — à moins que ce site n’effectue des calculs significatifs en cours de processus.

Types union et arguments nommés

Les types union permettent à un paramètre de fonction ou une valeur de retour d’accepter explicitement plusieurs types :

function processInput(int|string $input): int|false {
    // ...
}

Les arguments nommés découplent l’ordre des arguments des signatures de fonction, améliorant considérablement la lisibilité dans les fonctions avec plusieurs paramètres optionnels :

array_slice(array: $data, offset: 2, length: 5, preserve_keys: true);

L’expression match

L’expression match remplace switch avec une comparaison de type stricte, sans comportement de fall-through et des retours basés sur des expressions :

$status = match($code) {
    200, 201 => 'success',
    404 => 'not found',
    500 => 'server error',
    default => 'unknown',
};

Contrairement à switch, match lève une UnhandledMatchError si aucun bras ne correspond et qu’aucune valeur par défaut n’est fournie — rendant les échecs silencieux impossibles.

Attributs (métadonnées structurées)

Les Attributs PHP 8.0 remplacent les annotations docblock utilisées par des frameworks comme Doctrine et Symfony. Ils sont analysés par le moteur lui-même, pas par des expressions régulières en espace utilisateur :

#[Route('/api/users', methods: ['GET'])]
public function listUsers(): Response { ... }

Cela a des implications significatives pour les performances des frameworks et la précision des outils IDE.

PHP 8.1 : PHP moderne de qualité production

PHP 8.1 est la version que la plupart des nouveaux projets devraient cibler au moment de la rédaction de cet article. Il s’appuie sur les fondations de PHP 8.0 et ajoute des fonctionnalités qui comblent des lacunes de longue date dans le système de types et le modèle de concurrence du langage.

Énumérations

Les Enums résolvent le problème des « constantes magiques » qui a affecté les bases de code PHP pendant des décennies :

enum Status: string {
    case Active = 'active';
    case Inactive = 'inactive';
    case Pending = 'pending';
}

Les enums soutenus peuvent être stockés dans des bases de données et sérialisés proprement. Les enums purs fournissent une représentation d’état type-safe sans la fragilité des constantes de classe ou des drapeaux entiers.

Fibres : multitâche coopératif

Les Fibres introduisent une primitive de concurrence de bas niveau en PHP. Contrairement aux threads, les Fibres sont coopératives — elles cèdent le contrôle explicitement. C’est la fondation que les frameworks PHP asynchrones (comme ReactPHP et Amp) utilisent pour implémenter des I/O non bloquantes sans nécessiter d’extensions comme Swoole :

$fiber = new Fiber(function(): void {
    $value = Fiber::suspend('first suspension');
    echo "Resumed with: " . $value;
});

$value = $fiber->start();
$fiber->resume('hello');

Pour les applications fonctionnant sur un Hébergement VPS avec un contrôle total sur le runtime PHP, les Fibres ouvrent la porte à la création d’applications basées sur une boucle d’événements en PHP pur.

Propriétés readonly

Les propriétés readonly imposent l’immuabilité après initialisation, ce qui est essentiel pour les objets valeur et les entités de domaine dans les architectures DDD (Domain-Driven Design) :

class OrderId {
    public function __construct(
        public readonly string $value
    ) {}
}

Une fois définie dans le constructeur, $value ne peut pas être modifiée. Toute tentative lève une Error. Cela élimine toute une classe de code défensif répétitif.

Types intersection

Là où les types union disent « ceci OU cela », les types intersection disent « ceci ET cela » — exigeant qu’une valeur implémente plusieurs interfaces simultanément :

function processEntity(Serializable&Countable $entity): void { ... }

Cela est particulièrement précieux dans les architectures de conteneurs de services et de pipelines middleware.

Comment changer les versions PHP sur l’hébergement LiteSpeed d’AlexHost via cPanel

Les environnements d’VPS avec cPanel et d’hébergement mutualisé d’AlexHost exposent la gestion des versions PHP via le MultiPHP Manager de cPanel. Voici la procédure exacte :

Étape 1 : accéder à votre tableau de bord cPanel

Connectez-vous à votre compte AlexHost et naviguez vers la section Détails de connexion pour récupérer vos identifiants cPanel. Ouvrez cPanel directement via l’URL fournie (généralement yourdomain.com:2083 ou l’IP directe avec le port).

Étape 2 : naviguer vers MultiPHP Manager

Dans cPanel, localisez la section Logiciels. Cliquez sur MultiPHP Manager. Cette interface liste tous les domaines et sous-domaines associés à votre compte, chacun avec sa version PHP actuellement assignée affichée.

Étape 3 : sélectionner le domaine cible et la version PHP

Cochez la case à côté du domaine ou sous-domaine que vous souhaitez modifier. Utilisez le menu déroulant Version PHP pour sélectionner parmi les versions disponibles — PHP 7.3, 7.4, 8.0 ou 8.1 selon la configuration de votre plan d’hébergement. Cliquez sur Appliquer.

Étape 4 : vérifier le changement

Après application, le changement prend effet immédiatement pour les nouvelles requêtes. Vérifiez en créant un fichier temporaire phpinfo.php dans le répertoire racine du domaine :

<?php phpinfo(); ?>

Confirmez la version PHP dans la sortie, puis supprimez ce fichier immédiatement — laisser phpinfo() exposé en production est une vulnérabilité de sécurité qui révèle la configuration de votre serveur aux attaquants.

Étape 5 : tester la fonctionnalité de l’application

Ne supposez pas qu’un changement de version PHP est sûr sans tests. Vérifiez le journal d’erreurs de votre application (/home/username/logs/ ou via l’outil Erreurs de cPanel) pour les avis de dépréciation, les erreurs fatales ou les appels de fonctions non définies qui indiquent une incompatibilité.

Remplacement de version PHP par répertoire via .htaccess

Pour un contrôle granulaire — par exemple, exécuter un sous-répertoire legacy sur PHP 7.4 tandis que le site principal fonctionne sur PHP 8.1 — vous pouvez remplacer la version PHP au niveau du répertoire en utilisant .htaccess :

<FilesMatch ".php$">
    SetHandler application/x-httpd-ea-php81
</FilesMatch>

Le format du nom de gestionnaire est application/x-httpd-ea-phpXX où XX correspond au numéro de version sans le point décimal. Il s’agit d’une convention EasyApache 4 utilisée dans les environnements cPanel.

Matrice de décision pour la sélection de version PHP

Implications de sécurité de l’exécution de versions PHP en fin de vie

Ce point mérite une emphase explicite. Les versions PHP dépassant leur date de fin de vie ne reçoivent pas de correctifs de sécurité du projet PHP. Cela signifie :

• Les CVE découvertes après la fin de vie ne sont pas corrigées dans la branche de version affectée.
• Les environnements d’hébergement mutualisé sont particulièrement exposés car un processus PHP compromis peut potentiellement affecter les comptes voisins selon la configuration d’isolation.
• La conformité PCI DSS interdit explicitement l’exécution de logiciels dépassant leur date de fin de vie supportée par le fournisseur. Si vous traitez des paiements, l’utilisation de PHP 7.3 ou 7.4 constitue une violation de conformité.
• Les pare-feux d’applications web (WAF) peuvent atténuer certaines expositions, mais ils ne peuvent pas corriger les vulnérabilités au niveau du moteur.

Si vous avez besoin d’un contrôle total sur votre environnement PHP, la cadence de correction de sécurité et la capacité de compiler des extensions PHP personnalisées, un Serveur Dédié vous offre l’isolation et l’accès administratif que les environnements mutualisés ne peuvent pas fournir.

Considérations de performance PHP spécifiques à LiteSpeed

Plusieurs comportements de LiteSpeed interagissent avec la sélection de version PHP de manières qui ne sont pas évidentes :

LiteSpeed Cache (LSCache) : Le plugin LSCache pour WordPress fonctionne au niveau du serveur web, pas au niveau PHP. Cependant, les taux de succès OPcache améliorés de PHP 8.x signifient que les échecs de cache sont servis plus rapidement, réduisant la pénalité de performance des requêtes non mises en cache.

Persistance des workers LSAPI : LiteSpeed maintient les workers PHP actifs entre les requêtes. Cela signifie que le compilateur JIT de PHP 8.1 a plus d’opportunités de se réchauffer et d’optimiser les chemins de code fréquents par rapport à une configuration CGI traditionnelle où chaque requête démarre un processus à froid.

PHP-FPM vs. LSAPI : Sur les Panneaux de contrôle VPS où vous configurez la pile vous-même, vous pouvez choisir entre PHP-FPM et LSAPI. LSAPI surpasse systématiquement PHP-FPM dans les benchmarks pour les environnements LiteSpeed car il utilise un protocole de communication dédié plutôt que l’interface générique de FastCGI.

Limites mémoire et nombre de workers : PHP 8.x a une empreinte mémoire de base légèrement plus élevée que PHP 7.x en raison des structures d’exécution supplémentaires pour le JIT et le système de types. Si vous fonctionnez dans un environnement à mémoire limitée, surveillez les paramètres memory_limit après la mise à niveau.

Liste de contrôle pratique des points clés

Avant de changer ou de sélectionner une version PHP sur votre hébergement LiteSpeed AlexHost, parcourez cette liste de contrôle :

• Vérifiez la matrice de compatibilité PHP officielle de votre application — ne devinez pas. Laravel, WordPress, Magento et Drupal publient tous les versions PHP minimales et maximales supportées.
• Auditez les plugins et extensions installés — le code tiers est la source la plus courante d’incompatibilité PHP 8.x. Exécutez composer check-platform-reqs si vous utilisez Composer.
• Effectuez d’abord le changement en environnement de staging — utilisez un sous-domaine ou un environnement de staging pour tester le changement de version PHP avant de l’appliquer en production.
• Examinez les journaux d’erreurs immédiatement après le changement — recherchez les entrées E_DEPRECATED, E_NOTICE et E_FATAL qui indiquent une compatibilité rompue.
• Supprimez tous les fichiers phpinfo() créés lors de la vérification.
• N’exécutez pas de versions PHP en fin de vie en production sauf si vous disposez d’un plan de migration documenté et limité dans le temps ainsi que de contrôles de sécurité compensatoires.
• Utilisez MultiPHP INI Editor (également dans la section Logiciels de cPanel) pour ajuster les directives PHP par domaine comme memory_limit, upload_max_filesize et max_execution_time après un changement de version — les valeurs par défaut diffèrent entre les versions.
• Si votre application nécessite PHP 8.2 ou 8.3, envisagez de passer à un plan VPS où vous contrôlez la pile logicielle complète et pouvez installer n’importe quelle version PHP via des dépôts comme Remi ou ondrej/php.

Questions fréquemment posées

Puis-je exécuter différentes versions PHP sur différents domaines au sein du même compte d’hébergement mutualisé AlexHost ?

Oui. Le MultiPHP Manager de cPanel applique les paramètres de version PHP au niveau par domaine. Chaque domaine ou sous-domaine de votre compte peut exécuter une version PHP différente de manière indépendante, géré via la même interface sans affecter les autres domaines.

Le changement de version PHP dans MultiPHP Manager nécessite-t-il un redémarrage du serveur ou cause-t-il une interruption de service ?

Non. Le changement s’applique immédiatement aux nouvelles requêtes entrantes. Les processus PHP de longue durée existants peuvent continuer sur l’ancienne version jusqu’à leur achèvement, mais pour les requêtes web typiques cette transition est transparente et ne cause aucune interruption mesurable.

Le compilateur JIT de PHP 8.1 accélérera-t-il automatiquement mon site WordPress ?

Pas de manière significative pour les déploiements WordPress standard. Le JIT bénéficie aux charges de travail liées au CPU. Les performances de WordPress sont principalement contraintes par le temps de requête de base de données et les opérations I/O, que le JIT n’accélère pas. Les améliorations PHP 8.x les plus impactantes pour WordPress sont une meilleure efficacité OPcache et une surcharge réduite des appels de fonctions.

Quelle est la différence entre MultiPHP Manager et MultiPHP INI Editor dans cPanel ?

MultiPHP Manager contrôle quelle version PHP est assignée à chaque domaine. MultiPHP INI Editor contrôle les directives de configuration PHP (paramètres php.ini) pour chaque combinaison de domaine et de version PHP. Les deux outils sont nécessaires pour une gestion complète de l’environnement PHP — la sélection de version seule ne configure pas les limites mémoire, les délais d’exécution ou le chargement des extensions.

Que dois-je faire si mon application se casse après la mise à niveau vers PHP 8.x ?

Tout d’abord, revenez à la version PHP précédente dans MultiPHP Manager pour restaurer le service. Ensuite, examinez les journaux d’erreurs pour des messages d’erreur spécifiques. Les problèmes courants incluent les fonctions supprimées (each(), create_function()), le comportement modifié de coercition de type et les méthodes de classe de style constructeur dépréciées. Résolvez chaque problème dans un environnement de staging avant de tenter à nouveau la mise à niveau. Si l’application est un CMS ou un framework, vérifiez si une version mise à jour existe qui supporte officiellement PHP 8.x.