Application qui ne répond plus : trouver la cause

Si votre application cesse de fonctionner, déterminez d’abord si le problème vient de l’application elle-même ou du backend web qui se trouve derrière. Notez ce qui a changé en dernier et vérifiez si tous les utilisateurs sont touchés ou seulement quelques-uns. Lisez les journaux du serveur et revenez à une version livrée récemment si elle en est la cause. Nous pouvons réparer à distance une application web ou une API qui renvoie des erreurs.

Que veut dire « mon application plante » ?

Cette phrase recouvre des problèmes très différents. Une application web affiche peut-être un écran blanc ou une erreur. Une application mobile se ferme au démarrage, se fige ou annonce « Une erreur est survenue » dès qu’elle doit charger des données.

La question décisive est de savoir si le problème se trouve dans le code sur l’appareil ou sur le serveur avec lequel l’application communique. La plupart des applications, de la boutique en ligne à l’outil de réservation, dépendent d’un backend avec une API et une base de données. S’il tombe en panne, l’application semble cassée alors que son propre code est en ordre.

Que faire dans les dix premières minutes ?

Suivez ces étapes dans l’ordre. Chacune est rapide et fournit des indices avant que vous ne changiez quoi que ce soit.

1. Délimiter le périmètre. Tous les utilisateurs sont-ils touchés ou seulement quelques-uns ? Une fonction ou toute l’application ? Web, iOS, Android ou tout à la fois ?
2. Reproduire le problème. Ouvrez l’application ou le site sur votre propre appareil et sur un autre réseau. Notez le texte exact de l’erreur.
3. Nommer la dernière modification. Une nouvelle version, une mise à jour du serveur, une configuration modifiée, un renouvellement de certificat ou une mise à jour d’extension.
4. Vérifier les bases. Le serveur fonctionne-t-il ? L’espace disque est-il plein ? Le certificat SSL est-il valide ? La base de données est-elle joignable ?
5. Lire les journaux. Commencez par le journal d’erreurs de l’application et celui du serveur web, autour du moment où les pannes ont commencé.
6. Décider : revenir en arrière ou réparer. Si une nouvelle version a déclenché le problème et qu’il existe une sauvegarde ou une version précédente, le retour arrière est en général la voie la plus sereine.

L’application elle-même est-elle en cause, ou le backend ?

Le tableau donne une première estimation. C’est un repère, pas un verdict.

Un test rapide : si l’adresse de votre API renvoie un statut HTTP 5xx dans le navigateur ou avec un outil comme curl, le backend est en panne, et l’application n’est que le messager de la mauvaise nouvelle.

Un exemple concret

Lundi matin : des clients signalent que l’application de réservation « plante ». Personne n’a rien changé à l’application. Mais pendant le week-end, l’hébergeur a mis PHP à jour, et l’API de réservation renvoie désormais une erreur à chaque requête. L’application affiche un écran vide, car elle reçoit une erreur au lieu de données. Une fois le backend réparé, l’« application » fonctionnait de nouveau aussi.

Que révèlent les journaux ?

Les journaux sont la boîte noire de votre logiciel. Pour un backend web, consultez le journal de l’application et le journal d’erreurs du serveur web. Dans un projet Laravel, le journal de l’application est un fichier que vous pouvez ouvrir et parcourir à la recherche des entrées « ERROR » ou « Exception » les plus récentes.

[2026-10-22 08:14:03] production.ERROR: SQLSTATE[HY000] [2002] Connection refused

Une ligne comme celle-ci signifie que l’application n’a pas pu joindre sa base de données. C’est un problème tout autre qu’une erreur de programmation et il demande une autre solution. Lisez la première erreur d’une série, pas la dernière, car les erreurs suivantes sont souvent de simples conséquences.

Quand revenir à la dernière version qui fonctionnait ?

Si les pannes ont commencé juste après une nouvelle version ou une mise à jour, revenez à la dernière version qui fonctionnait. Cela supprime rapidement le symptôme et vous laisse le temps de chercher tranquillement la vraie cause.

Quels problèmes de backend font le plus souvent tomber les applications ?

• Une erreur de code après un déploiement
• La base de données refuse les connexions ou est pleine
• Un certificat SSL expiré
• L’espace disque ou la mémoire du serveur sont épuisés
• Un service tiers ou une API utilisés par votre backend est en panne
• L’hébergeur a changé la version de PHP ou d’un logiciel

Un certificat expiré mérite une mention particulière. Les applications mobiles sont souvent strictes sur ce point : l’application peut tomber complètement en panne, alors que votre site s’ouvre encore après un avertissement du navigateur. Nous traitons en détail deux causes fréquentes sur nos pages erreur de connexion à la base de données et Laravel : erreur 500 après déploiement.

Quand faut-il demander de l’aide ?

Demandez de l’aide si les journaux pointent vers quelque chose que vous ne savez pas interpréter, si le retour à la version précédente est impossible ou ne change rien, ou si des utilisateurs perdent de l’argent ou des données pendant que vous cherchez. Arrêtez-vous aussi avant de toucher à la base de données. Demander de l’aide tôt coûte moins cher qu’une mauvaise réparation sur des données en production.

Comment rendre la prochaine panne moins probable ?

Vous ne pouvez pas exclure toute panne, mais vous pouvez la garder plus petite et plus courte.

• Sauvegardez chaque jour le code et la base de données en dehors du serveur.
• Livrez par petites étapes, pour qu’une version défectueuse soit facile à repérer et à annuler.
• Mettez en place des contrôles de disponibilité qui vous alertent avant que vos utilisateurs ne se manifestent.
• Faites-vous avertir avant l’expiration du certificat SSL et du nom de domaine.
• Conservez les journaux assez longtemps pour retracer le début d’un problème.

Comment pouvons-nous vous aider en cas de panne d’application ?

Nous réparons à distance les sites web, les applications web et les backends web, dont WordPress, Laravel/PHP et les boutiques en ligne. Nous pouvons réparer la partie API, serveur et base de données d’une application mobile. Nous ne réparons ni l’interface ni le code des applications natives iOS ou Android, et nous vous le disons à temps si le problème se situe là.

Le diagnostic est gratuit. Nous vous annonçons le prix fixe avant le début des travaux (à partir de 295 € hors TVA), nous sauvegardons vos données avant toute modification, et vous payez à l’avance, après le diagnostic. Pour une erreur 500 dans le backend web, la page sur l’erreur 500 Internal Server Error peut vous aider, ou décrivez-nous votre cas. Pour que les pannes se fassent plus rares, un forfait de maintenance apporte des sauvegardes quotidiennes, des alertes de panne et des mises à jour avec retour arrière.