Problèmes applicatifs

Quand le code fait planter votre serveur

Plugins défaillants, modules en conflit, erreurs PHP : trouvez le coupable.

Les symptômes révélateurs

Vous êtes probablement face à un problème applicatif si :

  • La 503 est apparue après une mise à jour (CMS, plugin, module, thème)
  • Le serveur n’est pas surchargé (CPU/RAM OK)
  • Les fichiers statiques chargent (images, CSS) mais pas les pages PHP
  • Le problème touche une partie du site seulement (admin, checkout, une page)
  • Vous voyez des erreurs PHP dans les logs

Bonne nouvelle : les problèmes applicatifs sont généralement les plus faciles à résoudre une fois identifiés. Il suffit souvent de désactiver le composant fautif.

Diagnostic : Les logs sont vos amis

Où trouver les logs d’erreur

EnvironnementChemin typique
PHP général/var/log/php8.2-fpm.log
Apache/var/log/apache2/error.log
Nginx/var/log/nginx/error.log
WordPress/wp-content/debug.log (si WP_DEBUG activé)
PrestaShop/var/logs/*.log
Laravel/storage/logs/laravel.log

Commandes de diagnostic

# Erreurs PHP récentes
$ tail -100 /var/log/php8.2-fpm.log | grep -i error

# Erreurs fatales uniquement
$ grep -i "fatal" /var/log/php8.2-fpm.log | tail -20

# Erreurs avec timestamp (dernière heure)
$ awk -v d="$(date -d '1 hour ago' '+%d-%b-%Y %H')" '$0 ~ d' /var/log/php8.2-fpm.log

# Erreurs Nginx liées à PHP
$ grep "upstream" /var/log/nginx/error.log | tail -20

Erreurs courantes et leur signification

Exemples d

# Mémoire insuffisante
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted
→ Un script consomme trop de RAM (limite 128 Mo atteinte)

# Timeout
PHP Fatal error: Maximum execution time of 30 seconds exceeded
→ Un script tourne trop longtemps

# Classe non trouvée
PHP Fatal error: Class 'MonModule\\MaClasse' not found
→ Fichier manquant ou autoload cassé (souvent après mise à jour)

# Erreur de syntaxe
PHP Parse error: syntax error, unexpected '}' in /var/www/module.php on line 234
→ Bug dans le code (mise à jour ratée, fichier corrompu)

# Connexion BDD
PHP Fatal error: Uncaught PDOException: SQLSTATE[HY000] [2002] Connection refused
→ MySQL down ou mal configuré

Problème 1 : Limite mémoire PHP atteinte

Erreur : Allowed memory size of X bytes exhausted

Diagnostic

# Voir la limite actuelle
$ php -i | grep memory_limit
memory_limit => 128M => 128M

# Identifier le script gourmand
$ grep "memory" /var/log/php8.2-fpm.log | tail -10
```

Solutions

Solution rapide : Augmenter la limite

/etc/php/8.2/fpm/php.ini

; Augmenter la mémoire (256M ou 512M pour les gros sites)
memory_limit = 256M
$ systemctl restart php8.2-fpm

Pour WordPress :

wp-config.php

define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M'); // Pour l'admin

Pour PrestaShop :

config/defines.inc.php

// Ajouter en haut du fichier
@ini_set('memory_limit', '512M');

Augmenter la mémoire est un pansement. Si un plugin consomme 500 Mo, c’est qu’il est mal codé ou mal configuré. Identifiez-le et corrigez la cause.

Problème 2 : Timeout / Script trop long

Erreur : Maximum execution time of 30 seconds exceeded

Diagnostic

# Voir la limite actuelle
$ php -i | grep max_execution_time
max_execution_time => 30 => 30

# Identifier les scripts lents
$ tail -50 /var/log/php-fpm/slow.log
[26-Dec-2024 14:30:01] [pool www] pid 12345
script_filename = /var/www/monsite/index.php
[0x00007f...] mysqli_query() /var/www/monsite/modules/monmodule/classes/MonModule.php:156

Solutions

Solution rapide : Augmenter le timeout

/etc/php/8.2/fpm/php.ini

max_execution_time = 120

/etc/php/8.2/fpm/pool.d/www.conf

request_terminate_timeout = 120s

Identifier le coupable :

Le slow log PHP-FPM (si configuré) montre exactement quel script et quelle fonction bloque :

/etc/php/8.2/fpm/pool.d/www.conf

; Activer le slow log
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/slow.log

Causes fréquentes :

  • Requête SQL non optimisée (manque d’index)
  • Appel API externe qui ne répond pas
  • Import/export de gros fichiers
  • Génération de PDF/images à la volée

Problème 3 : Plugin/Module défaillant

C’est la cause n°1 des 503 applicatives. Un composant tiers plante tout le site.

Identifier le coupable

Méthode 1 : Regarder les logs

$ grep -i "fatal\\|error" /var/log/php8.2-fpm.log | tail -30

# Chercher le chemin du fichier fautif
# Exemple : /var/www/monsite/wp-content/plugins/mon-plugin/includes/class.php
```

Méthode 2 : Désactivation par élimination

# Lister les plugins actifs
$ wp plugin list --status=active

# Désactiver tous les plugins d'un coup
$ wp plugin deactivate --all

# Le site remarche ? → Un plugin est fautif
# Réactiver un par un pour trouver lequel
$ wp plugin activate akismet
$ wp plugin activate woocommerce
# ... jusqu'à ce que ça replante

Si pas d’accès SSH, renommez le dossier :

$ mv wp-content/plugins wp-content/plugins_backup
# Testez le site
# Puis renommez pour restaurer
$ mv wp-content/plugins_backup wp-content/plugins

PrestaShop : Désactivation de modules

# Désactiver un module via base de données
$ mysql -u user -p prestashop_db
mysql> UPDATE ps_module SET active = 0 WHERE name = 'monmodule';
mysql> DELETE FROM ps_hook_module WHERE id_module = (SELECT id_module FROM ps_module WHERE name = 'monmodule');

# Vider le cache
$ rm -rf var/cache/prod/* var/cache/dev/*

Ou renommez le dossier du module :

$ mv modules/monmodule modules/monmodule_disabled
$ rm -rf var/cache/prod/*

Plugins WordPress problématiques connus

PluginProblème fréquentSolution
ElementorMemory exhausted sur grosses pagesAugmenter memory_limit, optimiser les pages
WooCommerceTimeout sur checkout, gros cataloguesCache objet, optimiser requêtes
WPMLConflits, lenteurDésactiver puis réactiver proprement
Yoast SEOCalcul SEO sur gros sitesDésactiver l’analyse en temps réel
JetpackConnexion WordPress.com timeoutDésactiver modules non utilisés

Modules PrestaShop problématiques connus

ModuleProblème fréquentSolution
Modules de paiementTimeout API externeAugmenter timeout, vérifier credentials
Import/Export CSVMemory exhaustedImporter par lots plus petits
Modules SEOBoucles de redirectionVérifier règles htaccess
Modules de cacheCache corrompuVider et désactiver temporairement

Pour une intervention rapide sur WordPress, WPHelp247 est disponible 24/7. Pour PrestaShop, IllicoPresta propose un support spécialisé.

Problème 4 : Erreur après mise à jour

WordPress : Mise à jour qui a cassé le site

# Vérifier la version actuelle
$ wp core version
6.4.2

# Revenir à une version précédente (si vous avez un backup)
$ wp core update --version=6.4.1 --force

# Ou restaurer depuis backup
$ mysql -u user -p db_name < backup_avant_maj.sql
$ tar -xzf files_backup.tar.gz -C /var/www/

Activer le mode debug pour voir les erreurs :

wp-config.php

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
// Les erreurs seront dans wp-content/debug.log

PrestaShop : Mise à jour qui a cassé le site

# Le cache est souvent le coupable après MAJ
$ rm -rf var/cache/prod/* var/cache/dev/*

# Recompiler les classes
$ php bin/console cache:clear --env=prod

# Si toujours KO : désactiver le mode maintenance forcé
$ mysql -u user -p prestashop_db
mysql> UPDATE ps_configuration SET value = 0 WHERE name = 'PS_SHOP_ENABLE';

Vérifier les overrides :

# Les overrides peuvent être incompatibles après MAJ
$ ls -la override/classes/
$ ls -la override/controllers/

# Désactiver temporairement les overrides
$ mv override override_backup
$ rm -rf var/cache/prod/*

Problème 5 : Boucle infinie / Récursion

Symptôme : CPU à 100% sur un seul processus PHP, timeout, puis 503.

Diagnostic

# Processus PHP qui tourne depuis longtemps
$ ps aux | grep php | awk '$10 > "01:00" {print}'

# Trace d'exécution (si xdebug installé)
# Sinon, chercher dans les logs
$ grep -i "recursion\\|loop\\|stack" /var/log/php8.2-fpm.log
```

Causes fréquentes

  1. Hooks qui s’appellent mutuellement (WordPress/PrestaShop)
  2. Redirections en boucle (htaccess mal configuré)
  3. Fonction récursive sans condition d’arrêt
  4. Cache qui se régénère indéfiniment

Vérifier les redirections

# Suivre les redirections
$ curl -ILs https://monsite.com | grep -E "HTTP|Location"

HTTP/1.1 301 Moved Permanently
Location: https://www.monsite.com/
HTTP/1.1 301 Moved Permanently
Location: https://monsite.com/          # ← Boucle !
HTTP/1.1 301 Moved Permanently
Location: https://www.monsite.com/
# ... infini
```

Solution : Vérifier .htaccess et la config serveur pour les règles de redirection conflictuelles.

Debugging avancé

Activer Xdebug (environnement dev)

/etc/php/8.2/fpm/conf.d/20-xdebug.ini

zend_extension=xdebug.so
xdebug.mode=debug,trace
xdebug.start_with_request=trigger
xdebug.log=/var/log/xdebug.log

Profiling avec Blackfire ou Tideways

Pour les problèmes de performance complexes, ces outils montrent exactement où le temps est passé :

# Exemple avec Blackfire
$ blackfire curl https://monsite.com/page-lente
```

Logger manuellement

debug.php

<?php
// Ajoutez dans le code suspect
function debug_log($message) {
    $timestamp = date('Y-m-d H:i:s');
    $trace = debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 2);
    $caller = $trace[1]['function'] ?? 'unknown';
    file_put_contents(
        '/tmp/debug.log', 
        "[$timestamp] [$caller] $message\
", 
        FILE_APPEND
    );
}

// Utilisation
debug_log("Entrée dans la fonction X avec paramètre: " . json_encode($param));

Besoin d’aide pour débugger ?

Les experts peuvent identifier la cause en quelques minutes.

Questions fréquentes

Comment savoir si c’est un plugin ou le core qui pose problème ?

Désactivez tous les plugins et passez sur un thème par défaut (Twenty Twenty-Four pour WP, thème Classic pour PrestaShop). Si le site fonctionne, c’est un plugin/module ou le thème. Réactivez-les un par un pour identifier le coupable.

Le site plante uniquement sur certaines pages, pourquoi ?

Certaines pages exécutent du code spécifique : shortcodes, widgets, modules de page builder, produits avec options complexes. Identifiez ce qui est unique à ces pages et testez en supprimant les éléments un par un.

Après une mise à jour, je ne peux plus accéder à l’admin, que faire ?

Accédez via FTP/SSH : renommez le dossier du plugin/module mis à jour (ou tous les plugins), videz le cache manuellement, puis accédez à l’admin. Vous pourrez alors investiguer depuis l’interface.

Comment éviter ces problèmes à l’avenir ?

Testez toujours les mises à jour sur un environnement de staging d’abord. Gardez des backups récents. Utilisez un monitoring qui alerte sur les erreurs PHP, pas seulement sur la disponibilité du site.