Vous venez de configurer votre superbe projet Laravel 12 sur Hostinger. Dans le panneau de configuration, tout est au vert : PHP 8.4 est activé. Votre site charge à la vitesse de l'éclair. C'est parfait.

Puis, vous ouvrez votre terminal SSH pour lancer une migration ou mettre à jour Filament v4, et là... c'est le drame.

Vous tapez php -v et le terminal vous répond fièrement : PHP 8.1 (ou 8.2).

Frustrant, n'est-ce pas ? C'est un peu comme avoir un moteur de Ferrari sous le capot, mais un tableau de bord de Twingo à l'intérieur. Pas de panique ! C'est un classique des environnements CloudLinux partagés (comme chez Hostinger).

Dans cet article, je vais vous montrer comment forcer l'utilisation de PHP 8.4 en ligne de commande pour que vos commandes artisan et composer tournent comme une horloge.

Sommaire

1. Le Problème : Pourquoi deux versions différentes ?

2. La Solution : Créer un alias permanent (Le hack ultime)

3. Mise en pratique : Composer, Filament v4 et Laravel 12

4. FAQ : Vos questions, mes réponses

1. Le Problème : Pourquoi deux versions différentes ?

Imaginez votre serveur comme un immeuble.

• Le Web (Apache/Nginx/LiteSpeed) est votre appartement privé. Vous le décorez comme vous voulez (PHP 8.4).

• La Console (SSH) est le couloir de l'immeuble. C'est un espace commun géré par le propriétaire (l'hébergeur). Par défaut, il utilise une version standard (souvent plus ancienne) pour garantir la stabilité de tout l'immeuble.

C'est pour cela que lorsque vous lancez php artisan migrate, Laravel peut vous crier dessus car il a besoin des fonctionnalités de PHP 8.4, mais la console lui donne du 8.2.

Mais bonne nouvelle : nous avons les clés pour changer ça !

Diagnostic Initial

[u19000edhu36491@fr-int-webfr1044 public_html]$ php84 -v
-bash: php84: command not found

[u19000edhu36491@fr-int-webfr1044 public_html]$ scl enable alt-php84 bash
bash-4.4$ which php
/opt/cloudlinux/alt-php84/root/usr/bin/php

bash-4.4$ php84 -v
bash: /opt/alt/php84/bin/php: No such file or directory

Pourquoi Cette Différence Existe-t-elle ?

Comprendre CloudLinux et les Versions PHP

Sur CloudLinux, les versions PHP alternatives sont gérées via Software Collections (SCL). Voici ce qui se passe :

• Web (Apache/Nginx) : Utilise la version PHP définie dans le cPanel/Hostinger Panel (PHP 8.4)

• Console CLI : Utilise la version PHP système par défaut (souvent PHP 8.2 ou antérieure)

• SCL (Software Collections) : Crée des environnements isolés pour différentes versions PHP

Ces deux environnements sont complètement séparés et ne partagent pas la même configuration.

La Solution Ultime : Configuration Permanente

Étape 1 : Activer l'Environnement CloudLinux

scl enable alt-php84 bash

Cela vous place dans un sous-shell avec PHP 8.4 disponible.

Étape 2 : Vérifier le Chemin Correct de PHP 8.4

bash-4.4$ which php
/opt/cloudlinux/alt-php84/root/usr/bin/php

Important : Le chemin correct est /opt/cloudlinux/alt-php84/root/usr/bin/php (pas /opt/alt/php84/bin/php)

Étape 3 : Créer l'Alias Permanent

bash-4.4$ alias php84='/opt/cloudlinux/alt-php84/root/usr/bin/php'

bash-4.4$ php84 -v
PHP 8.4.14 (cli) (built: Oct 22 2025 15:58:59) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.4.14, Copyright (c) Zend Technologies
    with Zend OPcache v8.4.14, Copyright (c), by Zend Technologies

Étape 4 : Ajouter l'Alias à ~/.bashrc

bash-4.4$ nano ~/.bashrc

Ajoutez cette ligne à la fin du fichier :

alias php84='/opt/cloudlinux/alt-php84/root/usr/bin/php'

Puis sauvegardez avec Ctrl+O, Entrée, Ctrl+X.

Étape 5 : Nettoyer et Recharger la Configuration

bash-4.4$ sed -i '/alias php84/d' ~/.bashrc

bash-4.4$ echo "alias php84='/opt/cloudlinux/alt-php84/root/usr/bin/php'" >> ~/.bashrc

bash-4.4$ source ~/.bashrc

Utilisation Pratique : Commandes Essentielles

Mettre à Jour les Dépendances Composer

bash-4.4$ php84 /usr/local/bin/composer update

Loading composer repositories with package information
Updating dependencies
Lock file operations: 0 installs, 10 updates, 0 removals
  - Upgrading brianium/paratest (v7.16.0 => v7.16.1)
  - Upgrading laravel/framework (v12.44.0 => v12.47.0)
  - Upgrading laravel/prompts (v0.3.8 => v0.3.10)
  - Upgrading laravel/sail (v1.51.0 => v1.52.0)
  - Upgrading laravel/serializable-closure (v2.0.7 => v2.0.8)
  - Upgrading laravel/tinker (v2.10.2 => v2.11.0)
  - Upgrading phpoffice/phpspreadsheet (1.30.1 => v1.30.2)
  - Upgrading phpstan/phpdoc-parser (v2.3.0 => v2.3.1)
  - Upgrading rector/rector (v2.3.0 => v2.3.1)
  - Upgrading webmozart/assert (v2.0.0 => v2.1.2)

Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 0 installs, 10 updates, 0 removals

Installer les Dépendances

bash-4.4$ php84 /usr/local/bin/composer install

Installing dependencies from lock file (including require-dev)
Verifying lock file contents can be installed on current platform.
Nothing to install, update or remove

Generating optimized autoload files
> Illuminate\Foundation\ComposerScripts::postAutoloadDump
> @php artisan package:discover --ansi

   INFO  Discovering packages.

Vider les Caches Laravel

bash-4.4$ php84 artisan cache:clear
   INFO  Application cache cleared successfully.

bash-4.4$ php84 artisan config:clear
   INFO  Configuration cache cleared successfully.

bash-4.4$ php84 artisan route:clear
   INFO  Route cache cleared successfully.

Vérifier la Version de Laravel

bash-4.4$ php84 artisan --version
Laravel Framework 12.47.0

Résumé des Commandes Essentielles

Packages Découverts et Activés

Lors de l'exécution de Composer, les packages suivants ont été découverts et activés :

• ✅ barryvdh/laravel-debugbar

• ✅ barryvdh/laravel-dompdf

• ✅ intervention/image-laravel

• ✅ laravel/breeze

• ✅ laravel/pail

• ✅ laravel/sail

• ✅ laravel/tinker

• ✅ maatwebsite/excel

• ✅ nesbot/carbon

• ✅ nunomaduro/collision

• ✅ nunomaduro/termwind

• ✅ pestphp/pest-plugin-laravel

Total : 98 packages recherchent du financement

Voici une proposition d'article de blog optimisé, structuré et rédigé selon ton style et ta stack technique actuelle.

PHP 8.4 sur le Web mais 8.2 en Console ? La Solution Ultime pour Hostinger & CloudLinux V2

Vous venez de configurer votre superbe projet Laravel 12 sur Hostinger. Dans le panneau de configuration, tout est au vert : PHP 8.4 est activé. Votre site charge à la vitesse de l'éclair. C'est parfait.

Puis, vous ouvrez votre terminal SSH pour lancer une migration ou mettre à jour Filament v4, et là... c'est le drame.

Vous tapez php -v et le terminal vous répond fièrement : PHP 8.1 (ou 8.2).

Frustrant, n'est-ce pas ? C'est un peu comme avoir un moteur de Ferrari sous le capot, mais un tableau de bord de Twingo à l'intérieur. Pas de panique ! C'est un classique des environnements CloudLinux partagés (comme chez Hostinger).

Dans cet article, je vais vous montrer comment forcer l'utilisation de PHP 8.4 en ligne de commande pour que vos commandes artisan et composer tournent comme une horloge.

Sommaire

1. Le Problème : Pourquoi deux versions différentes ?

2. La Solution : Créer un alias permanent (Le hack ultime)

3. Mise en pratique : Composer, Filament v4 et Laravel 12

4. FAQ : Vos questions, mes réponses

1. Le Problème : Pourquoi deux versions différentes ?

Imaginez votre serveur comme un immeuble.

• Le Web (Apache/Nginx/LiteSpeed) est votre appartement privé. Vous le décorez comme vous voulez (PHP 8.4).

• La Console (SSH) est le couloir de l'immeuble. C'est un espace commun géré par le propriétaire (l'hébergeur). Par défaut, il utilise une version standard (souvent plus ancienne) pour garantir la stabilité de tout l'immeuble.

C'est pour cela que lorsque vous lancez php artisan migrate, Laravel peut vous crier dessus car il a besoin des fonctionnalités de PHP 8.4, mais la console lui donne du 8.2.

Mais bonne nouvelle : nous avons les clés pour changer ça !

2. La Solution : Créer un alias permanent

Nous n'allons pas changer la version du serveur (impossible en mutualisé), mais nous allons dire à notre terminal : "Hé, quand je t'appelle, utilise ce chemin précis vers PHP 8.4".

Voici la procédure exacte, testée et approuvée sur les serveurs Hostinger CloudLinux :

Étape 1 : Identifier le chemin (Path)

Sur les serveurs CloudLinux, les binaires PHP sont cachés dans /opt/cloudlinux/. Pour PHP 8.4, le chemin magique est : /opt/cloudlinux/alt-php84/root/usr/bin/php

Étape 2 : Créer l'alias

On va modifier votre fichier .bashrc (c'est le fichier de configuration qui se charge à chaque fois que vous vous connectez).

Ouvrez votre terminal et lancez cette commande pour éditer le fichier :

Bash

nano ~/.bashrc

Ajoutez cette ligne tout en bas du fichier :

Bash

alias php84='/opt/cloudlinux/alt-php84/root/usr/bin/php'

Astuce : Vous pouvez aussi nommer l'alias simplement php si vous voulez remplacer la commande par défaut, mais php84 est plus sûr pour éviter les conflits.

Sauvegardez (Ctrl+O, Entrée) et quittez (Ctrl+X).

Étape 3 : Recharger la configuration

Pour que cela fonctionne immédiatement sans se déconnecter, tapez :

Bash

source ~/.bashrc

Maintenant, le moment de vérité :

Bash

php84 -v

Si vous voyez PHP 8.4.13 (cli), félicitations ! Vous êtes le roi du pétrole.

3. Mise en pratique : Composer, Filament v4 et Laravel 12

Maintenant que nous avons notre commande php84, regardons comment cela débloque votre workflow de développement, en reprenant l'exemple d'une mise à jour réelle.

Lancer Composer avec la bonne version

Souvent, Composer refuse de s'installer si la version PHP CLI est trop vieille. Voici comment forcer la main à Composer en utilisant notre nouvel alias :

Bash

php84 /usr/local/bin/composer update

Résultat ? Les dépendances s'installent sans broncher. Vous pouvez voir dans vos logs que tout s'enchaîne parfaitement :

• livewire/livewire (v3)

• filament/filament (v4)

• laravel/framework (v12)

Mettre à jour Filament et la Base de Données

Avec un environnement technique aussi pointu (Laravel 12, Livewire 3, Tailwind v4), vous ne pouvez pas vous permettre d'erreurs de version.

Regardez comme c'est fluide pour mettre à jour les assets de Filament v4 :

Bash

php84 artisan filament:upgrade

Le terminal va publier tous les nouveaux assets JS et CSS nécessaires au bon fonctionnement de votre admin panel.

Et pour vos migrations ?

Bash

php84 artisan migrate

Boom ! 2026_01_17_000000_add_slug_to_users_table ....... DONE. Votre application est à jour, sécurisée et tourne sur la toute dernière version du framework.

4. FAQ (Foire Aux Questions)

Q : Est-ce que je dois refaire cette manip à chaque connexion ?

R : Non ! Grâce à l'ajout dans le fichier .bashrc, c'est mémorisé pour toujours (ou jusqu'à ce que vous le supprimiez).

Q : Puis-je utiliser cet alias pour mes tâches CRON ?

R : Pour les Cron Jobs dans le panneau Hostinger, il vaut mieux utiliser le chemin absolu complet (/opt/cloudlinux/alt-php84/root/usr/bin/php) plutôt que l'alias, pour être sûr à 100%.

Q : Pourquoi ne pas simplement utiliser php comme alias ?

R : Vous pouvez ! (alias php='...'). C'est plus pratique, mais garder php84 vous rappelle explicitement quelle version vous forcez. C'est une question de goût.

Conclusion

La clé pour résoudre ce problème est de comprendre que CloudLinux sépare l'environnement web et CLI. En suivant ces étapes simples :

✅ Activer l'environnement SCL avec scl enable alt-php84 bash
✅ Créer un alias permanent vers /opt/cloudlinux/alt-php84/root/usr/bin/php
✅ Ajouter cet alias à ~/.bashrc pour la persistance
✅ Recharger la configuration avec source ~/.bashrc

Vous garantissez que :

✅ PHP 8.4.14 reste accessible après chaque reconnexion
✅ Vos commandes Artisan fonctionnent correctement
✅ Composer peut mettre à jour vos dépendances sans problème
✅ Votre environnement CLI correspond à votre environnement web
✅ Laravel Framework 12.47.0 fonctionne parfaitement

Bonus : Cette solution fonctionne également pour d'autres versions PHP (8.3, 8.2, etc.) en remplaçant simplement alt-php84 par alt-php83 ou alt-php82 dans le chemin et l'alias.

Vous avez maintenant la solution ultime pour synchroniser PHP 8.4 entre votre web et votre console sur Hostinger ! 🚀