6.2Problèmes récurrents (playbook)
L'essentiel en 30 secondes
- Réflexe : un symptôme = des causes probables = une action ciblée — on diagnostique avant de toucher au code.
- Lire : la traceback se lit par le bas : la dernière ligne nomme, le dessus localise.
- Isoler : tout écart entre local et CI se traite par venv, requirements figé et versions alignées.
Fil Nabil — le playbook scotché à côté de l'écran
Nabil garde ce playbook à côté de son écran. Verdict après un an : trois lignes l'ont le plus servi — le venv non activé derrière ModuleNotFoundError, le mélange tabulations + espaces, et la CI rouge alors que tout était vert en local. Pour chacune, il a fini par appliquer la séquence (lire la traceback, vérifier la cause, corriger) au lieu de modifier au hasard.
Symptôme observé, causes vérifiées, actions dans l'ordre : le réflexe tient en trois temps.
Diagnostiquer avant de relancer
La plupart des blocages Python sont des grands classiques : chaque symptôme a des causes typiques et une action ciblée. Le tableau ci-dessous regroupe les situations les plus fréquentes, de l'import au déploiement.
| Symptôme | Causes probables | Actions |
|---|---|---|
| ModuleNotFoundError | mauvais interpréteur, venv non activé, fichier au mauvais endroit | sélectionner le bon interpréteur, activer le venv, vérifier le chemin |
| IndentationError / TabError | tabulations + espaces mélangées | convertir en 4 espaces, black pour normaliser |
| NameError | faute de frappe, variable hors portée, import oublié | relire la dernière ligne, vérifier portée et imports |
| KeyError sur dict | clé absente, accès direct | .get() avec défaut + valider les données d'entrée |
| Ça marchait hier (dépendances) | global mélangé, versions dérivées | venv + requirements figés, rebuild pour prouver |
| Tests rouges après refactor | comportement changé sans le vouloir | lire LE test fautif, corriger le code (pas le test), relancer |
| API injoignable en conteneur | host localhost au lieu de 0.0.0.0 | CMD avec --host 0.0.0.0, -p pour publier |
| CI rouge, local vert | versions différentes, test manquant, secret absent | aligner versions (requirements), reproduire en local, vérifier secrets |
| Script lent sur gros volume | boucles Python au lieu de vectorisé/générateur | profiler, vectoriser (pandas/NumPy) ou yield |
Script prêt à dire — diagnostiquer sans toucher au hasard (30 s)
« Mon symptôme : [ModuleNotFoundError / KeyError / CI rouge / lenteur]. Je lis la traceback par le bas, j'identifie la cause probable du playbook, j'applique l'action ciblée et je vérifie. »
Modèle copier-coller — accès sûr + erreur précise
def taux_ville(ligne: dict) -> float:
ville = ligne.get("ville", "inconnue")
if ville == "inconnue":
raise ValueError("clé 'ville' absente de la ligne")
return float(ligne.get("taux", 0.0))TPE / petit budget
Pas de tableau formel : un symptôme, la cause probable du playbook, l'action et le responsable noté.
PME Alger
Intégrer les réalités locales dans le diagnostic : versions installées, postes partagés, pics du lundi connus.
Remote / hybride
Ajouter les logs écrits immédiats aux actions : à distance, un symptôme non consigné ressemble à un système qui marche.
Interculturel
Expliciter les constats par écrit : ce qui semble évident (quel venv, quelle version) ne l'est pas pour tous.
Défi 48h — appliquez demain
Repérez 1 symptôme actuel (import, KeyError, CI rouge), appliquez la ligne du playbook (traceback lue + cause vérifiée + action ciblée).
- Je sais relier un symptôme à ses causes probables.
- Je lis la traceback par le bas avant de corriger.
- Je sais verrouiller avec venv, hints et tests.
Le script de Nabil lève KeyError sur un dict de ventes. Quel réflexe applique le playbook ?
Une même galère qui revient sans cesse n'est pas dix incidents : c'est une méthode à corriger (venv, tests, hints).