Lire une erreur sans paniquer : anatomie d'une stack trace (Python et JavaScript)

Ton code plante, un mur de texte rouge s’affiche, et le réflexe naturel est de tout fermer et de recommencer ailleurs. Mauvaise idée : ce mur de texte, appelé stack trace (ou traceback en Python), te dit presque toujours exactement où chercher. Apprendre à le lire, c’est la compétence qui te fait gagner le plus de temps en programmation, tous langages confondus.

Une erreur n’est pas une catastrophe

La documentation officielle de Python fait une distinction utile : il y a les erreurs de syntaxe (ton code n’est même pas valide, Python ne peut pas l’exécuter du tout) et les exceptions (ton code est valide, mais quelque chose se passe mal pendant l’exécution). Les secondes « ne sont pas inconditionnellement fatales » : elles interrompent le programme sur le coup, mais elles existent justement pour être repérées et corrigées, pas pour te punir.

Anatomie d’une stack trace en Python

Voici un exemple, tiré tel quel de la documentation officielle :

>>> 10 * (1/0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
    10 * (1/0)
          ~^~
ZeroDivisionError: division by zero

Lis-le du bas vers le haut. La toute dernière ligne est la plus importante : elle donne le type d’exception (ZeroDivisionError) et un message précis (« division by zero »). Au-dessus, la documentation officielle appelle ça un « stack traceback » : la liste des lignes de code traversées pour arriver jusqu’à l’erreur, dans l’ordre où elles ont été appelées. Dans un vrai script avec plusieurs fonctions qui s’appellent entre elles, tu verras plusieurs blocs File "...", line X, in nom_de_fonction empilés : le premier correspond à l’endroit où le programme a démarré, le dernier (juste avant le message d’erreur) à l’endroit exact où ça a cassé.

Anatomie d’une stack trace en JavaScript

En JavaScript, l’objet Error a une propriété stack qui fait sensiblement la même chose, mais dans l’ordre inverse. D’après MDN, elle « offre une trace des fonctions appelées, dans quel ordre, depuis quelle ligne et quel fichier », en partant « des appels les plus récents vers les plus anciens ». Exemple officiel, pour trois fonctions qui s’appellent en cascade (foo appelle bar, qui appelle baz) :

Error
    at baz (filename.js:10:15)
    at bar (filename.js:6:3)
    at foo (filename.js:2:3)
    at filename.js:13:1

Cette fois, lis du haut vers le bas : la première ligne (baz) est la fonction où l’erreur s’est réellement produite, et chaque ligne suivante remonte vers qui a appelé qui, jusqu’à l’appel initial. Retiens surtout ceci, qui vient du guide MDN pour débutants : le numéro de ligne indiqué te dit où l’erreur s’est manifestée, pas forcément où se trouve la vraie cause du problème — parfois le bug est une ligne plus haut, dans une valeur mal construite bien avant qu’elle ne fasse planter le programme.

Les erreurs de débutant les plus fréquentes

Côté Python, quelques classiques, avec leur définition officielle exacte :

• NameError : « levée quand un nom local ou global n’est pas trouvé » — le cas typique est une faute de frappe dans un nom de variable, ou une variable utilisée avant d’être définie.
• TypeError : « levée quand une opération ou une fonction est appliquée à un objet d’un type inapproprié » — additionner une chaîne de caractères et un nombre, par exemple.
• IndexError : « levée quand un indice de séquence est hors limites » — tu demandes le dixième élément d’une liste qui n’en a que trois.
• KeyError : « levée quand une clé de dictionnaire n’est pas trouvée parmi les clés existantes ».
• AttributeError : « levée quand une référence à un attribut… échoue » — souvent une faute de frappe dans le nom d’une méthode, ou un objet qui n’est pas du type que tu crois.
• ModuleNotFoundError : une sous-catégorie d’ImportError, « levée par import quand un module n’a pas pu être localisé » — le paquet n’est pas installé, ou son nom est mal orthographié.

Côté JavaScript, la référence officielle MDN classe les erreurs par famille. Les plus courantes au quotidien : TypeError (une valeur n’est pas du type attendu — messages typiques : « x is not a function », ou une tentative de lire une propriété sur null/undefined), ReferenceError (« x is not defined », une variable qui n’existe pas ou pas encore dans la portée actuelle), et SyntaxError (le code ne peut même pas être interprété, souvent un caractère ou une parenthèse manquante).

La méthode : reproduire, isoler, formuler une hypothèse, tester, corriger

Face à une erreur, procède dans l’ordre plutôt que de changer du code au hasard :

1. Reproduire : relance exactement la même action. Si l’erreur revient à l’identique, tu as une base stable pour travailler.
2. Isoler : réduis ton code au minimum qui déclenche encore l’erreur (commente des blocs, simplifie les données d’entrée) jusqu’à ce qu’il ne reste que l’essentiel.
3. Formuler une hypothèse : le type d’exception et la dernière ligne de la trace te donnent une piste concrète (« cette variable est sans doute None à cet endroit », par exemple).
4. Tester l’hypothèse : ajoute une vérification ou un print temporaire pour confirmer ce que tu penses, avant de corriger.
5. Corriger, puis revérifier : une fois le correctif en place, relance le programme en entier, pas seulement la partie isolée, pour t’assurer que rien d’autre ne s’est cassé.

Demander de l’aide : l’exemple minimal reproductible

Que ce soit à une IA ou sur un forum, la qualité de la réponse dépend directement de ce que tu fournis. Le guide officiel de Stack Overflow définit ce qu’on appelle un exemple minimal reproductible (aussi appelé reprex, MWE ou SSCCE selon les communautés) comme « un ensemble de code source et de données permettant de démontrer et reproduire un problème », qui doit être « aussi petit et simple que possible » pour démontrer le problème « sans complexité ni dépendances additionnelles ».

Concrètement, avant de poser ta question, prépare quatre choses : le message d’erreur complet copié tel quel (jamais reformulé de mémoire), le plus petit bout de code qui reproduit encore le problème, ce que tu attendais comme résultat, et ce que tu as déjà essayé. Un exemple minimal ressemble à ça :

# Reproduit systématiquement : TypeError
prix = "10"
total = prix + 5

Cinq lignes suffisent ici à montrer le problème : pas besoin de coller tout ton programme de deux cents lignes. Une question accompagnée d’un exemple de ce genre obtient une réponse plus vite, et souvent une meilleure réponse, qu’une question qui se contente de dire « ça marche pas ».

Si tu utilises une IA ou l’aide d’un forum pour un travail noté, vérifie d’abord les règles d’usage de l’IA de ton établissement : elles varient d’un cours à l’autre, et mieux vaut le savoir avant de rendre le devoir qu’après.

À retenir

• Une stack trace n’est pas une punition : elle te dit où regarder.
• En Python, lis le traceback de bas en haut ; la dernière ligne donne le type d’erreur et le message.
• En JavaScript, la propriété stack se lit de haut en bas, de l’appel le plus récent au plus ancien.
• Le numéro de ligne indique où l’erreur s’est manifestée, pas toujours où se cache la vraie cause.
• Méthode de dépannage : reproduire, isoler, formuler une hypothèse, tester, corriger, puis revérifier l’ensemble.
• Pour demander de l’aide : message d’erreur complet, code minimal qui reproduit le bug, résultat attendu, ce que tu as déjà essayé.