Site ou application en panne : je trouve la cause et je la corrige
Erreur 500, page blanche, formulaire qui n’envoie plus rien, tâche qui ne tourne plus, bug apparu après une mise à jour : je remonte jusqu’à la cause dans le code et les journaux du serveur, puis je corrige à la source. Laravel, PHP sur mesure, JavaScript, Docker, et au-delà.
Votre site tourne sous WordPress ? Voir le dépannage WordPress
Vous reconnaissez votre situation ?
- Erreur 500, page blanche ou « service indisponible »
- Bug apparu après une mise à jour ou un changement d’hébergement
- Formulaire, paiement ou envoi de mails qui ne fonctionne plus
- Import, export ou tâche planifiée qui échoue sans prévenir
- Application que plus personne ne sait maintenir depuis le départ de son développeur
- Erreur JavaScript qui bloque un bouton ou une page entière
La méthode, étape par étape
Chaque étape laisse une trace écrite : vous savez ce qui a été fait, et pourquoi.
Accès et sauvegarde
Avant toute modification : une sauvegarde, ou mieux une copie de travail, pour ne rien casser de plus.
Lecture des journaux et du code
Journaux du serveur, de l’application et du navigateur : l’erreur réelle, avec le fichier et la ligne en cause.
Correction à la source
Le correctif porte sur la cause, pas sur le symptôme. Il est testé sur la copie, puis appliqué chez vous.
Compte rendu
Ce qui s’est passé, ce qui a été modifié, et comment éviter que ça se reproduise.
Un cas réel : une administration en erreur 500 sans changement de code
L’administration d’une application Laravel renvoyait des erreurs 500 en continu. Un premier correctif dans le code n’avait rien changé : l’application n’était pas en cause.
Les journaux ont montré que le conteneur Redis, qui sert de cache, était tué par le noyau pour dépassement mémoire : 1 102 redémarrages, avec une limite de 128 Mo trop basse pour la réécriture de son journal. À chaque redémarrage, le cache disparaissait et l’administration tombait.
J’ai fixé une limite mémoire et une politique d’éviction dans Redis, relevé la limite du conteneur, et ajouté au déploiement la recréation du service, qui ne se faisait pas. Après correction, le compteur de redémarrages est resté à zéro.
Questions fréquentes
Quelles technologies connaissez-vous ?
Au quotidien : PHP, Laravel, WordPress, JavaScript, MySQL, Nginx et Docker. Pour le reste (Symfony, PrestaShop, Node.js, Python…), je lis le code et la documentation, et je vous dis dès le diagnostic si je peux régler le problème. Si ce n’est pas le cas, vous êtes remboursé.
Faut-il me donner un accès au serveur ?
Le plus souvent, oui : un accès à l’hébergement (SSH ou FTP) et à l’administration de l’application. Sans les journaux, un diagnostic reste une supposition.
Le développeur d’origine a disparu et il n’y a aucune documentation. Est-ce un problème ?
C’est un cas fréquent. Je pars du code tel qu’il est, et le compte rendu que je vous remets devient le début de la documentation.
Pour aller plus loin
Des guides écrits à partir de cas réels, si vous préférez comprendre avant de confier.
Un problème à régler, un outil à créer ?
Décrivez-le en quelques lignes. Vous recevez sous 24 h ouvrées une réponse claire : oui ou non, la formule et le délai.