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
| Environnement | Chemin 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
| Plugin | Problème fréquent | Solution |
|---|---|---|
| Elementor | Memory exhausted sur grosses pages | Augmenter memory_limit, optimiser les pages |
| WooCommerce | Timeout sur checkout, gros catalogues | Cache objet, optimiser requêtes |
| WPML | Conflits, lenteur | Désactiver puis réactiver proprement |
| Yoast SEO | Calcul SEO sur gros sites | Désactiver l’analyse en temps réel |
| Jetpack | Connexion WordPress.com timeout | Désactiver modules non utilisés |
Modules PrestaShop problématiques connus
| Module | Problème fréquent | Solution |
|---|---|---|
| Modules de paiement | Timeout API externe | Augmenter timeout, vérifier credentials |
| Import/Export CSV | Memory exhausted | Importer par lots plus petits |
| Modules SEO | Boucles de redirection | Vérifier règles htaccess |
| Modules de cache | Cache corrompu | Vider 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
- Hooks qui s’appellent mutuellement (WordPress/PrestaShop)
- Redirections en boucle (htaccess mal configuré)
- Fonction récursive sans condition d’arrêt
- 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.