Rédigé par Rédaction CyberSDF / 18 September 2026

Erreur PHP "Cannot redeclare class" sur cPanel : trouver le double chargement

Verdict. Cette erreur signifie que PHP voit deux fois la déclaration d’une même classe. Dans File Manager, partez du fichier et de la ligne cités, repérez les deux chargements, puis gardez une seule inclusion ou donnez un nom distinct aux classes réellement différentes. Faites une copie avant toute modification.

Le message apparaît souvent après un transfert vers l’hébergement, un changement de plugin ou l’ajout d’un autoloader. La ligne affichée indique l’endroit où PHP constate le conflit, pas toujours le premier fichier qui l’a provoqué.

Lire le message avant de toucher au fichier

Relevez le nom exact entre Cannot redeclare class et in, le chemin du fichier et le numéro de ligne. Une erreur comme Cannot redeclare class App\Client donne déjà le nom complet de la classe. Conservez aussi l’heure de l’erreur pour comparer les journaux après la correction.

Deux situations se ressemblent mais ne se corrigent pas de la même façon :

• un même fichier est chargé deux fois par require, include ou un appel manuel mélangé à Composer ;
• deux fichiers différents déclarent le même nom de classe dans le même espace de noms.

Une seule classe ne peut pas occuper deux fois le même nom complet pendant une exécution PHP. Le nom court Client peut en revanche exister dans deux espaces de noms différents, comme le décrit le manuel PHP sur les namespaces.

Retrouver le double chargement depuis cPanel

Avant d’éditer, téléchargez une copie du fichier cité et de tout fichier d’inclusion proche. La documentation de File Manager cPanel décrit l’ouverture, l’édition et l’enregistrement des fichiers du compte. Vérifiez l’encodage proposé par l’interface avant de sauvegarder.

1. Ouvrez le fichier et la ligne indiqués. Cherchez la déclaration class, son namespace éventuel et les lignes require ou include qui l’entourent.
2. Remontez vers le point d’entrée. Suivez les fichiers qui chargent cette classe. Un fichier de configuration, un bootstrap et un autoloader peuvent tous participer au même chemin.
3. Recherchez le nom dans le compte. Avec un terminal SSH disponible, utilisez la commande suivante depuis la racine du projet :

grep -RniE '^[[:space:]]*(abstract[[:space:]]+|final[[:space:]]+)?class[[:space:]]+Client([[:space:]]|\{)' .

Dans File Manager, utilisez la recherche de nom ou ouvrez les fichiers correspondant au nom de la classe. Ne modifiez pas tout résultat qui contient le mot Client : une chaîne de caractères, un commentaire et une classe peuvent porter le même texte sans jouer le même rôle.

La recherche des inclusions complète celle des déclarations :

grep -RniE '(require|include|autoload|spl_autoload_register)' .

Notez pour chaque résultat le chemin réel, le fichier qui l’appelle et la branche de code concernée. Un chemin relatif peut viser un fichier différent selon le dossier courant ; __DIR__ rend souvent l’intention plus lisible.

Une mesure simple pour confirmer l’hypothèse

Le 18 septembre 2026, une fixture de deux fichiers contenant chacun class Client a produit deux déclarations avec la recherche précédente. La sortie utile était :

fixture-duplicate/app/Client.php:2:class Client {}
fixture-duplicate/legacy/Client.php:2:class Client {}

Cette mesure ne prouve pas quel fichier votre application doit conserver ; elle montre seulement le signal à chercher : deux définitions portant le même nom dans le même espace de noms. Une fois la cause identifiée, choisissez une correction qui conserve une seule source de vérité.

Choisir la correction qui correspond à la cause

Le même fichier est inclus plusieurs fois

Si deux chemins chargent le même fichier, remplacez l’inclusion répétable par require_once :

require_once __DIR__ . '/src/Client.php';

La fonction require_once est documentée par PHP : elle vérifie qu’un fichier n’a pas déjà été inclus pendant l’exécution. Le suffixe _once ne doit pas servir à masquer deux fichiers différents qui déclarent le même nom complet.

Vérifiez aussi les variantes d’un chemin. Un chemin relatif, un chemin absolu et un lien symbolique peuvent faire référence au même fichier physique tout en donnant à un vieux bootstrap des instructions différentes. Centralisez l’inclusion dans un seul point d’entrée plutôt que d’ajouter plusieurs garde-fous.

Deux fichiers déclarent réellement la même classe

Si app/Client.php et legacy/Client.php contiennent chacun la classe Client, décidez laquelle représente le modèle courant. Archivez l’ancienne version ou renommez la classe et ses usages. Ne supprimez pas un fichier depuis File Manager sans avoir recherché ses appels.

Si les deux classes doivent coexister, donnez-leur des espaces de noms :

<?php
namespace App;

class Client
{
    public function endpoint(): string
    {
        return '/api/clients';
    }
}

<?php
namespace Legacy;

class Client
{
    public function endpoint(): string
    {
        return '/legacy/clients';
    }
}

Le code appelant peut alors distinguer les deux types avec des alias :

use App\Client as ApiClient;
use Legacy\Client as LegacyClient;

$api = new ApiClient();
$old = new LegacyClient();

Un namespace doit être appliqué à tous les fichiers concernés et à leurs références. Ajouter une seule ligne namespace sans adapter les imports transforme parfois une erreur fatale en classe introuvable.

Composer et les inclusions manuelles se doublent

Dans un projet Composer, chargez l’autoloader au point d’entrée puis laissez-le résoudre les classes :

require_once __DIR__ . '/vendor/autoload.php';

$client = new App\Client();

Le manuel PHP sur l’autoloading explique spl_autoload_register() et le fichier vendor/autoload.php généré par Composer. Retirez l’inclusion manuelle du même fichier de classe si Composer le connaît déjà. Ne modifiez pas un fichier dans vendor pour corriger une classe de votre application : la prochaine installation le remplacera.

Cette règle est particulièrement importante dans une application Laravel ou dans un projet qui mélange une bibliothèque historique et un autoloader moderne. Pour replacer le problème dans une application PHP complète, consultez la page sur la création d’une API REST Laravel avec Sanctum. Pour les choix d’outils et de dépendances PHP, la page sur le développement web open source avec PHP, MySQL et Laravel donne un contexte plus large.

Contrôler le fichier avant le retour en ligne

Après la modification, relisez le fichier entier et contrôlez les lignes qui l’appellent. Sur un accès SSH ou un terminal cPanel, lancez le vérificateur de syntaxe avec la version PHP utilisée par le compte :

php -l /home/COMPTE/public_html/chemin/vers/Client.php

Le résultat attendu est No syntax errors detected. La commande vérifie la syntaxe du fichier, pas le chemin d’exécution complet ; chargez ensuite le point d’entrée réel dans un environnement de test ou une URL protégée.

Rechargez l’application et comparez l’heure du journal d’erreurs. Si le message cite encore l’ancien contenu après une sauvegarde confirmée, vérifiez le fichier réellement servi, la version PHP du domaine et l’opcache proposé par l’hébergement. N’effacez pas les journaux avant d’avoir conservé la ligne d’erreur et l’heure du nouveau chargement.

La correction doit supprimer le double nom complet sans supprimer la classe dont le reste de l’application dépend. Une sauvegarde téléchargeable et un fichier de retour arrière rendent ce choix réversible.

Quand require_once ne suffit pas

Si l’erreur revient malgré require_once, cherchez une seconde définition dans un autre fichier. Les causes fréquentes sont un ancien dossier copié dans le nouveau projet, un plugin chargé deux fois, un autoloader déclaré deux fois ou une classe renommée dans un seul fichier.

• Deux fichiers pour le même rôle : gardez la version appelée par le code courant et retirez l’appel vers l’ancienne.
• Deux rôles différents avec le même nom : utilisez des namespaces et des alias explicites.
• Autoloader et inclusion manuelle : gardez l’autoloader au point d’entrée et retirez l’inclusion redondante.
• Erreur apparue après une mise à jour : comparez la liste des fichiers déployés avec la version précédente avant de modifier la dépendance.

Pour vérifier un script de shell utilisé pendant cette recherche, vous pouvez reprendre les bases de l’écriture d’un script Bash et, si l’accès passe par SSH, les repères de la connexion SSH par clé.

Checklist avant de remettre le domaine en ligne

1. Copie du fichier et des fichiers d’inclusion conservée.
2. Nom complet de la classe relevé dans le message.
3. Déclarations et chargements recherchés dans tout le projet.
4. Correction choisie selon la cause, sans modification de vendor au hasard.
5. Syntaxe contrôlée avec la version PHP du compte.
6. URL ou point d’entrée rechargé, puis journal relu avec son heure.
7. Retour arrière préparé si le site affiche une nouvelle erreur.

Une classe chargée une seule fois, avec un nom complet cohérent et un chemin d’inclusion lisible, fait disparaître la cause au lieu de cacher le message.