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. PHP, Laravel, WordPress, JavaScript, et au-delà.

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.

  1. Accès et sauvegarde

    Avant toute modification : une sauvegarde, ou mieux une copie de travail, pour ne rien casser de plus.

  2. 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.

  3. Correction à la source

    Le correctif porte sur la cause, pas sur le symptôme. Il est testé sur la copie, puis appliqué chez vous.

  4. Compte rendu

    Ce qui s’est passé, ce qui a été modifié, et comment éviter que ça se reproduise.

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.

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.