Partie 17 — Erreurs & debug : comprendre et corriger PHP

Partie 17 — Erreurs & debug : comprendre et corriger PHP

Si tu apprends PHP, tu vas rencontrer des erreurs. Beaucoup. Et c’est normal : une erreur n’est pas un échec, c’est un signal. Le vrai problème, ce n’est pas “avoir une erreur”, c’est de ne pas savoir la lire, la comprendre et la corriger.

Dans un vrai projet, le debug est une compétence à part entière. Deux développeurs peuvent avoir le même bug : l’un passe 2 heures, l’autre 5 minutes, parce qu’il suit une méthode.

👉 Dans cette partie, tu vas apprendre une méthode claire : identifier le type d’erreur, localiser la cause, reproduire, corriger, et éviter que ça revienne. Avec des exemples concrets (et les pièges les plus fréquents).

1) Les grandes familles d’erreurs PHP (et ce qu’elles veulent dire)

PHP peut te remonter différents niveaux de problèmes. Le mot “error” est utilisé partout, mais il faut distinguer :

• Parse error : erreur de syntaxe (le code ne peut même pas démarrer)
• Fatal error : erreur bloquante (ex: appel de fonction inconnue)
• Warning : le script continue, mais quelque chose est incorrect/risqué
• Notice : info (souvent variable non définie), le script continue
• Exception : erreur “contrôlable” via try/catch

✅ Réflexe : quand tu vois une erreur, lis 3 choses : le type, le message, la ligne.

2) Parse error : la syntaxe est cassée (exemples fréquents)

Une parse error veut dire : PHP n’arrive pas à “lire” ton code. Souvent, c’est un problème de caractère manquant.

2.1 Oubli de point-virgule

<?php
echo "Hello"
echo "World";
?>
  

Ici, la vraie faute est le point-virgule manquant après "Hello", mais l’erreur peut être signalée sur la ligne suivante, ce qui perturbe les débutants.

2.2 Accolades / parenthèses non fermées

<?php
if (true) {
   echo "OK";
 // } oubliée
?>
  

Dans ce cas, PHP va souvent dire “unexpected end of file”. Traduction : “j’attends une accolade/parenthèse et je ne la trouve pas”.

2.3 Mauvais guillemets

<?php
echo "Bonjour;
?>
  

Un guillemet non fermé casse tout le fichier. Astuce : beaucoup d’éditeurs (VS Code) aident en colorant la chaîne.

3) Fatal error : le code démarre… puis bloque

Une fatal error est souvent liée à :

• fonction inconnue
• méthode inconnue
• classe introuvable
• fichier include/require introuvable
• type invalide (dans certains cas)

3.1 Fonction inconnue

<?php
helloWorld(); // n'existe pas
?>
  

Correction : soit tu as fait une faute de frappe, soit tu as oublié d’inclure le fichier qui définit la fonction.

3.2 include/require introuvable

<?php
require "config.php"; // fichier absent => fatal
echo "OK";
?>
  

Si require échoue, le script s’arrête. include provoque souvent un warning et continue, mais en pratique, si c’est un fichier important (config DB), mieux vaut require.

✅ Pro tip : utilise des chemins absolus : __DIR__ . "/config.php" pour éviter les bugs selon le “current working directory”.

4) Warning & Notice : le script continue, mais quelque chose est mauvais

4.1 Notice : variable non définie

<?php
echo $name; // Notice: Undefined variable
?>
  

Correction : initialiser ou utiliser l’opérateur null coalescing :

<?php
$name = $name ?? "Invité";
echo $name;
?>
  

4.2 Warning : division par zéro / fichier introuvable / type inattendu

<?php
echo 10 / 0; // Warning
?>
  

Correction : valider avant de calculer. Beaucoup de warnings sont des “problèmes de données”.

⚠️ En production, un warning affiché à l’écran peut exposer des chemins internes du serveur. Donc : en prod on log, mais on n’affiche pas.

5) Activer le bon mode debug (DEV vs PROD)

En local (DEV), tu veux voir les erreurs immédiatement. En production (PROD), tu veux les logguer sans les montrer aux utilisateurs.

5.1 Mode DEV : afficher les erreurs

<?php
ini_set("display_errors", "1");
ini_set("display_startup_errors", "1");
error_reporting(E_ALL);
?>
  

5.2 Mode PROD : ne pas afficher, mais logger

<?php
ini_set("display_errors", "0");
error_reporting(E_ALL);
ini_set("log_errors", "1");
ini_set("error_log", __DIR__ . "/logs/php-error.log");
?>
  

En production, tu affiches plutôt une page “Erreur serveur” propre, et tu consultes le fichier log pour comprendre.

6) Debug rapide : var_dump(), print_r(), die(), exit()

Quand tu cherches un bug, tu veux voir ce qu’il y a dans une variable. Les outils de base :

• var_dump() : très détaillé (types + valeurs)
• print_r() : plus lisible pour arrays/objets
• die()/exit() : stoppe le script (utile pour isoler)

6.1 Exemple : inspecter un tableau POST

<?php
echo "<pre>";
print_r($_POST);
echo "</pre>";
die("Stop ici pour debug");
?>
  

Méthode simple : tu places des “points de contrôle”. Tu vois si ton code arrive là ou non. Comme un radar.

7) Le “Stack Trace” : ton GPS pour retrouver l’origine d’un bug

Quand tu as une erreur moderne (ou une exception), PHP peut donner une stack trace. C’est la liste des appels de fonctions qui a mené au problème.

Au lieu de lire 30 lignes au hasard, tu fais ça :

1. Regarde la première ligne importante (souvent celle où l’erreur se déclenche)
2. Remonte vers ton code (pas vers vendor/framework si possible)
3. Identifie la variable qui cause le bug

✅ Astuce : si tu utilises Laravel/Symfony, le message d’erreur et la stack trace sont souvent excellents en DEV. En PHP pur, tu peux améliorer tes exceptions (voir section suivante).

8) Exceptions : try/catch (contrôler les erreurs au lieu de subir)

Les exceptions sont des erreurs “gérables”. Tu peux les capturer et réagir proprement. Exemple : fichier introuvable, requête DB, API externe…

8.1 Exemple simple

<?php
try {
    if (!file_exists("data.json")) {
        throw new Exception("Fichier data.json introuvable");
    }

    $content = file_get_contents("data.json");
    echo $content;

} catch (Exception $e) {
    echo "Erreur : " . htmlspecialchars($e->getMessage());
}
?>
  

En production, au lieu d’afficher l’erreur exacte, tu peux afficher un message générique, et logger le vrai message :

<?php
catch (Exception $e) {
    error_log($e->getMessage());
    echo "Une erreur est survenue. Réessaie plus tard.";
}
?>
  

9) Créer un handler global : capturer erreurs & exceptions proprement

Dans un projet sérieux, tu veux centraliser la gestion : tout ce qui casse doit être loggué au même endroit, avec contexte.

9.1 Gestionnaire d’exceptions global

<?php
set_exception_handler(function (Throwable $e) {
    error_log("EXCEPTION: " . $e->getMessage() . " in " . $e->getFile() . ":" . $e->getLine());
    http_response_code(500);
    echo "Erreur serveur.";
});
?>
  

9.2 Gestionnaire d’erreurs (warnings/notices) en exceptions

Tu peux convertir certains warnings en exceptions pour forcer un code plus strict.

<?php
set_error_handler(function ($severity, $message, $file, $line) {
    // Tu peux filtrer les niveaux si besoin
    throw new ErrorException($message, 0, $severity, $file, $line);
});
?>
  

✅ En DEV, ça te force à corriger les warnings/notice au lieu de les ignorer.

10) Méthode de debug “pro” (en 7 étapes)

1. Reproduire le bug (toujours)
2. Lire le message + la ligne + le type
3. Isoler : commenter des blocs / mettre des die() pour voir où ça casse
4. Inspecter les variables : var_dump, print_r
5. Formuler une hypothèse (“variable vide”, “mauvais chemin”, “type string au lieu d’int”)
6. Tester la correction en petit
7. Ajouter une protection (validation, try/catch, test) pour éviter le retour du bug

✅ Ce process marche sur PHP, JS, Laravel, API… partout.

11) Debug avancé : Xdebug (le niveau supérieur)

Quand var_dump ne suffit plus, Xdebug te permet de :

• mettre des breakpoints
• exécuter ligne par ligne
• voir les variables en direct
• comprendre le flow exact

Sur un setup local (Windows/Mac/Linux), Xdebug + VS Code, c’est un vrai “super-pouvoir”. Tu peux débugger un login, une requête, un upload, sans deviner.

⚠️ Xdebug en production : généralement non (impact perf + risques). On l’utilise surtout en DEV.

12) Exemples réels de bugs (et comment les corriger vite)

Bug A : “Undefined array key” sur $_POST

Cause : le champ n’existe pas, ou la requête n’est pas POST. Fix : utiliser ?? et vérifier le method.

<?php
if ($_SERVER["REQUEST_METHOD"] !== "POST") {
    die("Méthode invalide");
}

$email = $_POST["email"] ?? "";
if ($email === "") {
    die("Email requis");
}
?>
  

Bug B : “Headers already sent”

Cause : tu as affiché du HTML/echo avant header() ou setcookie(). Fix : déplacer les headers avant tout output.

<?php
// PAS de echo avant
header("Location: /dashboard.php");
exit;
?>
  

Bug C : “Allowed memory size exhausted” sur images

Cause : image trop grande + traitement (GD/Imagick). Fix : limiter dimensions, refuser énormes images, resize avant.

Bug D : “Call to a member function on null”

Cause : tu attends un objet mais tu as null. Fix : vérifier la valeur avant d’appeler.

<?php
$user = $repo->find($id); // peut retourner null
if (!$user) {
    die("Utilisateur introuvable");
}
echo $user->name;
?>
  

13) Mini-exercices (pour entraîner ton cerveau au debug)

1. Crée un script avec 3 erreurs (notice, warning, fatal) et corrige-les.
2. Active le mode DEV (display_errors + E_ALL) et observe les messages.
3. Fais un handler global (exception + error handler) et teste-le.
4. Reproduis volontairement “headers already sent” puis corrige.

Conclusion

Savoir coder, c’est bien. Savoir débugger, c’est ce qui te rend autonome. Avec une méthode et les bons outils (logs, var_dump, stack trace, try/catch), tu peux corriger plus vite, éviter les bugs répétitifs, et construire des projets solides.

Dans la Partie 18, on peut enchaîner naturellement sur un sujet “niveau pro” : sécurité web en PHP (XSS, CSRF, SQLi) ou authentification complète.