Lire les erreurs et les logs — où regarder et quoi transmettre pour corriger

Cet article traite de la lecture des messages d'erreur et des logs.

Le texte qui apparaît quand l'exécution s'arrête et les enregistrements laissés pendant que le programme tourne sont deux choses différentes.

À partir d'un seul événement, « une erreur est apparue », l'endroit où tu regardes se divise en trois.

Les deux du haut sont du texte qui apparaît quand l'exécution s'arrête ; celui du bas est un enregistrement laissé pendant que le programme tourne.

Quand l'exécution s'arrête, un message d'erreur et une trace d'appels apparaissent

Quand une erreur (error : l'exécution qui s'arrête parce que les instructions ne peuvent plus continuer) se produit, l'environnement d'exécution écrit sous forme de texte ce qui s'est passé.

Ce texte se divise en deux parties aux rôles différents.

Quand tu lances app.js de l'application de réservation my-app avec node app.js, ce texte apparaît au moment où l'exécution s'arrête.

/Users/you/my-app/app.js:5
  return items.price * items.count;
               ^

TypeError: Cannot read properties of undefined (reading 'price')
    at keisan (/Users/you/my-app/app.js:5:16)
    at goukei (/Users/you/my-app/app.js:9:10)
    at Object.<anonymous> (/Users/you/my-app/app.js:13:13)
    at Module._compile (node:internal/modules/cjs/loader:1356:14)

La ligne qui commence par TypeError est le message d'erreur, et les quatre lignes en dessous qui commencent par at sont la trace d'appels.

Cette seule ligne de message d'erreur se divise elle aussi en trois : le type, la description et la cible.

La partie la plus intérieure, le type d'erreur (error type : le nom, prévu par l'environnement d'exécution, qui indique la catégorie du problème), détermine l'endroit où tu regardes en premier : il change selon le nom.

Le texte dit ce qui s'est passé et où

Le texte rouge affiché à l'écran se compose de deux choses : un message d'erreur qui indique brièvement ce qui s'est passé, et une trace d'appels qui liste où l'exécution s'est arrêtée.

Lis le message d'erreur en trois parties — type, description et cible — et une fois le nom du type connu, tu sais à peu près où ouvrir ensuite.

La trace d'appels est la suite des endroits traversés avant l'arrêt

Un programme est divisé en unités de traitement, et une unité en appelle une autre au fil de l'exécution.

Chaque ligne listée est une unité de traitement encore en cours au moment de l'arrêt.

Plus une ligne est haute, plus le traitement est intérieur ; plus elle est basse, plus il est extérieur.

La ligne keisan est l'endroit où l'exécution s'est arrêtée, mais on n'y trouve qu'une expression qui utilise la valeur reçue.

En remontant la valeur transmise, tu arrives à la ligne 13, la plus extérieure.

Ce qui a été transmis là ne contient pas price, donc l'exécution s'est arrêtée quand keisan a essayé de le lire.

Les lignes listées affichent aussi des noms de fichiers autres que ton propre app.js.

Commence par ouvrir la ligne d'un fichier que tu as écrit toi-même.

L'ordre et les mots changent selon l'environnement d'exécution.

Python écrit File au lieu de at, et appelle l'ensemble de la liste un traceback (traceback : un autre nom pour la trace d'appels).

Les lignes listées sont des appels de l'intérieur vers l'extérieur

La trace d'appels est la liste de l'endroit où l'exécution s'est arrêtée et des endroits traversés pour y arriver.

Une ligne correspond à un traitement et, plus elle est haute, plus elle est intérieure ; l'écriture et l'ordre changent selon l'environnement d'exécution, mais dans tous les cas tu commences à lire à la ligne qui porte un nom de fichier que tu as écrit.

Le log est l'enregistrement, avec l'heure, de ce qui se passe pendant l'exécution

Tu ne peux lire à l'écran le texte vu jusqu'ici que lorsque tu exécutes le programme sur ton ordinateur.

Sur un serveur public, il n'apparaît pas sur l'écran de l'utilisateur, car le montrer donne une piste aux attaquants.

Ce qui apparaît dans la colonne de droite est le log (log : l'enregistrement de ce qui se passe pendant que le programme tourne, écrit avec l'heure).

Pas seulement les erreurs : les requêtes reçues et les traitements réussis sont eux aussi listés ligne par ligne, dans l'ordre où ils se produisent.

Après un signalement indiquant qu'une réservation ne peut pas être enregistrée, tu ouvres le log de my-app.

Autour de cette heure-là, ces trois lignes étaient présentes.

2026-09-03 10:12:04  INFO   demande de réservation reçue id=182
2026-09-03 10:12:05  ERROR  échec de l'enregistrement de la réservation id=182
2026-09-03 10:12:05  ERROR  délai dépassé pour la connexion à la base de données

À l'intérieur d'une ligne aussi, les éléments sont rangés dans un ordre fixe : l'heure, le niveau de log et le contenu.

Le niveau de log au milieu (log level : la catégorie qui indique la gravité de l'événement noté sur cette ligne) te permet d'extraire et de lire uniquement les lignes graves.

Les noms et le nombre de catégories changent selon la bibliothèque, mais un point est commun : elles sont classées du plus léger au plus grave, et un réglage décide à partir de quel niveau les lignes sont gardées.

Les logs du serveur sont écrits dans un fichier, ou envoyés à un service de collecte de logs pour être conservés.

Lire seulement la fin d'un fichier est traité dans Afficher le contenu — cat / head / tail / wc.

L'endroit où regarder dépend du côté qui s'est arrêté.

Si l'arrêt a lieu dans le cadre de gauche, regarde la console du navigateur ; s'il a lieu dans le cadre de droite, regarde le log du serveur.

Après la mise en ligne, ce que tu lis, c'est le log

Le texte qui apparaît à l'écran sur ton ordinateur est conservé dans le log du serveur après la mise en ligne.

Une ligne de log suit toujours le même ordre — heure, niveau de log, contenu — : une fois la ligne ERROR trouvée, lis les lignes autour pour voir ce qui se passait.

Ce que tu transmets, ce sont 4 éléments : le texte complet, les étapes de reproduction, l'environnement et l'heure

Si tu dis seulement « une erreur est apparue », la personne qui répond doit commencer par te reposer des questions.

Elle ne peut pas voir ton ordinateur : tout se joue sur sa capacité à recréer le même état chez elle.

Le deuxième élément, les étapes de reproduction (steps to reproduce : la suite d'actions qui recrée le même état), est la première chose que demande la personne qui répond.

Énumère dans l'ordre sur quel écran tu étais, ce que tu as saisi et sur quoi tu as appuyé, et précise aussi si cela se produit à chaque fois.

Colle les 4 éléments en un seul bloc, sans les envoyer séparément.

Avant de coller, vérifie qu'aucun nom d'hôte de connexion ni clé API ne s'y est glissé.

Il arrive que le programme ne se comporte pas comme prévu sans qu'aucun texte d'erreur n'apparaisse.

L'écran reste blanc et rien ne se passe, ou un résultat sort mais la valeur est fausse.

Dans ce cas, cherche à quel endroit du log les enregistrements s'interrompent.

Avec les 4, l'autre personne peut recréer le même état

Tu transmets quatre choses : le texte complet affiché, les étapes de reproduction, l'endroit où tu l'as lancé et l'heure de l'incident.

Chacune sert à la personne qui répond pour recréer le même état : colle le texte tel quel sans le couper, et avant de coller, vérifie seulement qu'aucune valeur secrète ne s'y est glissée.