Lire les logs d'une application Python

3 min de lecture07 novembre 2026

Sur l'hébergement d'applications, la console du panneau est votre principale fenêtre sur le processus Python. Savoir où partent les messages, comment les structurer et comment lire une trace d'erreur évite de diagnostiquer à l'aveugle.

1. Où vont les sorties

Le panneau démarre la commande de démarrage et capture deux flux distincts :

  • stdout : print(), sorties normales.
  • stderr : avertissements, erreurs et tracebacks non interceptés.

Les deux apparaissent dans la console, souvent entrelacés, et leur ordre n'est pas garanti. Autre piège : lorsque la sortie n'est pas un terminal, Python bufferise. Des messages peuvent donc arriver en retard, ou disparaître si le processus est tué brutalement. Définissez PYTHONUNBUFFERED=1 dans les variables d'environnement du panneau, ou passez flush=True à print().

2. Structurer avec logging

print() dépanne pour un test, pas pour un service. Le module logging ajoute un niveau, un horodatage, un nom de logger et une sortie configurable.

Python
import logging
import os
import sys

logging.basicConfig(
    level=os.environ.get("LOG_LEVEL", "INFO").upper(),
    format="%(asctime)s %(levelname)s %(name)s %(message)s",
    stream=sys.stdout,
    force=True,
)
log = logging.getLogger("app")
log.info("demarrage")

En production, restez en INFO. Activez DEBUG par variable d'environnement le temps d'une investigation, puis revenez en arrière : un niveau trop bavard remplit la console et peut exposer des données internes. N'écrivez jamais de jeton, de mot de passe ni de chaîne de connexion complète dans un log. Pour une exception, log.exception("contexte") conserve la trace complète.

3. Lire un traceback

Python affiche la pile d'appels du plus ancien au plus récent. La ligne décisive est la dernière : type d'exception et message. Les blocs During handling of the above exception ou The above exception was the direct cause signalent des exceptions enchaînées ; cherchez la cause la plus profonde.

Les lignes File "...", line N, in ... indiquent l'emplacement, y compris dans les dépendances. Quelques signatures courantes :

  • ModuleNotFoundError : dépendance absente de requirements.txt ou mal installée.
  • SyntaxError : code invalide, l'application ne démarre même pas.
  • Address already in use : port déjà occupé par un autre processus.
  • KeyError sur une variable d'environnement : secret non configuré dans le panneau.

4. Boucle de redémarrage

Si le processus se termine, le panneau peut le relancer. Une boucle courte répète la même erreur et repousse les premières lignes hors de vue. Lisez le début de la sortie après un redémarrage : c'est là que figure la cause initiale. Si la console tronque l'historique, reproduisez localement avec python main.py et les mêmes variables.

5. Vérifier et dépanner

  1. Redémarrez avec LOG_LEVEL=DEBUG, reproduisez le problème, puis remettez INFO.
  2. Vérifiez que chaque message attendu apparaît une seule fois.
  3. Contrôlez les dépendances avec pip install -r requirements.txt en local.
  4. Supprimez du code les print() de débogage avant de redéployer.

Une console lisible vaut mieux qu'un long fichier de logs que personne ne consulte.

Publicité

Cet article vous a-t-il aidé ?

À lire aussi