$course$/QCM de NSI/Terminale/Mise au point et débogage Mise au point d'un programme : tests d'intégration,
profilage (en temps et en mémoire), gestion des
exceptions avec try et except, analyse des
journaux d'exécution, débogueur interactif et
méthodes systématiques de réduction au cas
minimal et d'explication à voix haute.

]]> Mise au point et débogage — Q01 : Notion d'exception Qu'est-ce qu'une exception en Python ?

]]> Les exceptions remontent la pile des appels
de fonctions jusqu'à un bloc try / except
qui les capture. En l'absence d'un tel
bloc, le programme s'arrête en affichant
la trace de l'erreur.

]]> 1.0 0.0 0 true true abc Un type de variable particulier

]]> Une exception est un événement de
l'exécution, pas un type de donnée que
l'on déclare comme on déclarerait un
entier ou une chaîne.

]]> Un simple avertissement qui n'interrompt pas le programme

]]> Cette description correspond à un
warning. Une exception non capturée,
au contraire, interrompt l'exécution du
programme.

]]> Une erreur signalée durant l'exécution, qui interrompt le flux normal du programme sauf si elle est capturée

]]> Quelques exemples classiques :
ValueError, TypeError, IndexError,
KeyError. C'est le mécanisme standard
pour signaler une condition inattendue
pendant l'exécution.

]]> Un commentaire spécial inséré dans le code

]]> Une exception n'a aucun rapport avec un
commentaire. Les commentaires en Python
commencent par le caractère # et n'ont
aucun effet sur l'exécution.

]]> Mise au point et débogage — Q02 : Le bloc try / except Comment gérer une exception sans que le
programme ne s'interrompe ?

]]> Variantes utiles :
except ValueError: pour capturer un type
d'exception spécifique ; else: pour le
cas où aucune exception n'a été levée ;
finally: pour du code toujours exécuté.
Bonne pratique : capturer un type
d'exception précis plutôt qu'utiliser un
except nu.

]]> 1.0 0.0 0 true true abc Aucun moyen ne permet d'éviter l'arrêt du programme

]]> Python fournit précisément le bloc
try / except pour intercepter une
exception et poursuivre l'exécution.

]]>

try:
    risque()
except Exception as e:
    print("Erreur :", e)

]]> Le bloc try tente l'exécution. En
cas d'exception, le bloc except
prend le relais et permet de gérer
proprement l'erreur.

]]> catch risque() {}]]> Cette syntaxe est utilisée en Java ou
en C++, mais pas en Python, qui
emploie try et except.

]]> if risque() == error: ...]]> Cette syntaxe n'est pas valide en
Python. La gestion des erreurs ne
repose pas sur une comparaison à une
valeur spéciale, mais sur le mécanisme
des exceptions.

]]> Mise au point et débogage — Q03 : Débogueur Python Quel module de la bibliothèque standard de
Python permet de déboguer interactivement ?

]]> Les environnements de développement
modernes (VS Code, PyCharm) intègrent des
débogueurs graphiques. Un simple clic
dans la marge pose un point d'arrêt, et
un panneau dédié affiche la valeur des
variables. C'est plus ergonomique que la
ligne de commande de pdb.

]]> 1.0 0.0 0 true true abc fix

]]> Aucun module nommé fix n'existe en
Python.

]]> error

]]> Aucun module standard nommé error
n'existe en Python.

]]> pdb

]]> On peut écrire

import pdb;

pdb.set_trace()

, ou plus simplement
breakpoint() depuis Python 3.7,
pour poser un point d'arrêt.
Quelques commandes utiles : n
(passer à la ligne suivante), s
(entrer dans la fonction), c
(continuer), p variable (afficher
une variable).

]]> debug

]]> Aucun module nommé debug n'existe
dans la bibliothèque standard.

]]> Mise au point et débogage — Q04 : Journalisation Pourquoi préfère-t-on le module logging à
print pour le débogage en production ?

]]> Bonne pratique : utiliser le niveau de
gravité approprié. Le niveau debug
sert pour les détails de développement,
info pour les événements normaux,
warning pour les anomalies non
bloquantes, error pour les erreurs
récupérables, et critical pour les
erreurs fatales.

]]> 1.0 0.0 0 true true abc Pour pouvoir activer ou désactiver les messages, choisir leur niveau de gravité (debug, info, warning, error, critical) et les rediriger vers un fichier

]]> Le module logging est conçu pour la
production. Il offre une
configuration centralisée, plusieurs
niveaux de gravité, un formatage
personnalisable et des destinataires
variés.

]]> Parce que la fonction print n'existe pas en Python

]]> La fonction print existe bel et
bien et reste utile, notamment pour
l'apprentissage. Elle est simplement
insuffisante pour gérer les
messages de débogage en production.

]]> Pour économiser de l'espace de stockage

]]> L'économie d'espace n'est pas
l'objectif principal. L'avantage du
module logging se situe ailleurs,
dans la flexibilité et la
configurabilité des messages.

]]> Aucun avantage particulier

]]> Le module logging apporte une
souplesse importante par rapport à
un simple print, comme détaillé
dans la bonne réponse.

]]> Mise au point et débogage — Q05 : Profilage Que désigne-t-on par le profilage d'un
programme ?

]]> Avec cProfile, la commande
python -m cProfile -s time script.py
affiche les fonctions triées par temps
cumulé d'exécution. Cela permet
d'identifier les $10\%$ du code qui
consomment $90\%$ du temps total.

]]> 1.0 0.0 0 true true abc Établir une description de son auteur

]]> Le profilage en informatique n'a
aucun rapport avec une description
biographique. Il s'agit d'une mesure
de performances.

]]> Mesurer où le programme passe son temps et consomme la mémoire, afin d'identifier les parties les plus coûteuses

]]> Avant d'optimiser, il faut mesurer.
Un adage célèbre rappelle que
« l'optimisation prématurée est la
racine de tous les maux ». Quelques
outils Python : cProfile,
line_profiler, memory_profiler.

]]> Compresser le code pour gagner de la place

]]> La compression du code n'a aucun
rapport avec le profilage, qui
mesure le temps d'exécution et la
consommation mémoire.

]]> Lancer le programme plusieurs fois pour vérifier sa stabilité

]]> Lancer un programme plusieurs fois
relève plutôt du test de robustesse.
Le profilage cherche à localiser les
parties coûteuses, et non à mesurer
la stabilité globale.

]]> Mise au point et débogage — Q06 : Test d'intégration Qu'est-ce qu'un test d'intégration ?

]]> La pyramide classique des tests comporte
beaucoup de tests unitaires (rapides à
exécuter), peu de tests d'intégration
(plus lents mais essentiels), et très
peu de tests de bout en bout (sur
l'ensemble du système). C'est une
stratégie pragmatique de couverture.

]]> 1.0 0.0 0 true true abc Un test gratuit, sans contrepartie

]]> Cette interprétation littérale du mot
« intégration » n'a pas de sens en
informatique.

]]> Un test qui vérifie l'intégrité de la pile d'exécution

]]> Cette description ne correspond à
aucun test classique. Un test
d'intégration porte sur les
interactions entre plusieurs modules.

]]> Un test qui ne déclenche jamais d'erreur

]]> Au contraire, un bon test
d'intégration peut très bien
détecter des erreurs ; c'est même
son but principal.

]]> Un test qui vérifie que plusieurs modules fonctionnent correctement ensemble, et pas seulement chacun isolément

]]> Ce type de test se distingue du test
unitaire, qui ne vérifie qu'un seul
module pris isolément. Le test
d'intégration permet de détecter les
bugs liés aux interactions, comme un
mauvais format de données échangées
entre deux modules.

]]> Mise au point et débogage — Q07 : Trace d'erreur Que représente la trace d'erreur
affichée par Python à la suite d'une
exception non capturée ?

]]> Pour lire une trace d'erreur, on
commence par la dernière ligne, qui
indique le type d'erreur, puis on
remonte pour localiser l'origine de
l'appel problématique. On ignore
généralement les blocs internes aux
bibliothèques pour se concentrer sur
son propre code.

]]> 1.0 0.0 0 true true abc Un fichier journal stocké sur le disque

]]> Une trace d'erreur n'est pas
stockée par défaut sur le disque ;
elle est simplement affichée dans
la sortie d'erreur du programme.

]]> Le code source complet du programme

]]> La trace ne contient pas tout le
code source, mais uniquement la
séquence d'appels qui a mené à
l'erreur, avec les numéros de
lignes correspondants.

]]> La suite des appels de fonctions au moment où l'exception a été levée, chaque ligne indiquant la fonction appelante

]]> Cette trace se lit du bas (lieu où
l'erreur s'est produite) vers le
haut (point d'entrée du programme).
Elle aide à comprendre le contexte
dans lequel l'erreur est apparue.

]]> Un type de mémoire interne au système

]]> Cette description évoque la pile
d'appels en mémoire, qui est une
notion proche mais distincte. Ici,
on parle de l'affichage textuel
obtenu à la sortie du programme.

]]> Mise au point et débogage — Q08 : Point d'arrêt À quoi sert un point d'arrêt dans un
débogueur ?

]]> En Python, on peut écrire breakpoint()
dans le code, ou cliquer dans la marge
d'un environnement de développement
pour poser un point d'arrêt graphique.
L'exécution s'arrête alors et l'on
peut explorer l'état du programme
interactivement.

]]> 1.0 0.0 0 true true abc À empêcher d'écrire du code dans une certaine zone

]]> Aucun point d'arrêt ne restreint
l'écriture du code. Il agit
uniquement à l'exécution.

]]> À supprimer définitivement le programme

]]> Un point d'arrêt n'a aucun effet
destructeur. Il ne fait que
suspendre temporairement
l'exécution.

]]> À suspendre l'exécution à une ligne précise pour inspecter les variables et progresser pas à pas

]]> C'est une technique essentielle
pour comprendre un programme
complexe. On peut placer plusieurs
points d'arrêt, voire des points
conditionnels (« suspendre
uniquement si $x > 100$ »).

]]> À enregistrer automatiquement le programme

]]> L'enregistrement du fichier source
n'a aucun rapport avec un point
d'arrêt.

]]> Mise au point et débogage — Q09 : Reproduction d'un bug Pourquoi est-il essentiel de pouvoir
reproduire un bug avant de le corriger ?

]]> L'adage classique en débogage est :
« si l'on ne peut pas reproduire le
bug, on ne peut pas le corriger ».
Une fois la reproduction obtenue, on
écrit un test qui échoue dans cette
situation, puis on corrige jusqu'à ce
que ce test passe avec succès.

]]> 1.0 0.0 0 true true abc Pour pouvoir le montrer à l'utilisateur final

]]> La présentation du bug à
l'utilisateur n'est pas la raison
pour laquelle on cherche à le
reproduire. L'objectif est de
pouvoir vérifier qu'il a été
corrigé.

]]> Parce qu'on ne peut pas vérifier qu'une correction est efficace si l'on n'arrive pas à redéclencher le bug

]]> Un bug intermittent est très
difficile à corriger. Trouver une
procédure fiable de reproduction
représente déjà la moitié du
travail de correction.

]]> Pour s'amuser à le voir se produire

]]> La reproduction d'un bug est un
travail technique sérieux, motivé
par la nécessité de pouvoir
contrôler la correction.

]]> Aucune raison particulière

]]> La reproduction est au contraire
l'étape fondatrice de tout
processus de correction sérieux.

]]> Mise au point et débogage — Q10 : Réduction au cas minimal Quelle est l'une des techniques
systématiques pour isoler la cause
d'un bug dans un programme ?

]]> Réduction au cas minimal et
explication verbale (du code à un
collègue, ou même à un objet) sont
les deux méthodes systématiques
utiles à connaître. Elles
complètent les outils techniques
(débogueur, journaux, profilage).

]]> 1.0 0.0 0 true true abc Réduire progressivement l'entrée problématique au cas le plus simple qui reproduit encore le bug, ce qui localise efficacement la zone fautive

]]> Cette technique du « cas de test
minimal » est très efficace : si
un programme plante sur une liste
de mille éléments, on essaie avec
dix, puis cinq, puis deux, en
gardant à chaque fois la
propriété qui déclenche le bug.
Cela localise la cause et fournit
gratuitement un test de
régression compact.

]]> Multiplier la taille de l'entrée jusqu'à observer un comportement régulier

]]> C'est l'inverse. Plus l'entrée est
grande, plus il est difficile
d'identifier précisément ce qui
déclenche le bug.

]]> Demander conseil à un collègue

]]> Cela peut aider à clarifier ses
idées (technique dite « du canard
en plastique »), mais n'est pas
une méthode systématique
d'isolation de la cause.

]]> Tout réécrire de zéro

]]> Cette démarche est risquée : elle
peut introduire de nouveaux bugs
et masquer l'origine du problème
initial.

]]> Mise au point et débogage — Q11 : Lever une exception explicitement Dans une fonction racine_carree(x), on
souhaite signaler une erreur lorsque
x est négatif. Quelle est la bonne
pratique ?

]]> Les instructions raise ValueError(...)
ou raise TypeError(...) sont les
moyens standard de signaler une
mauvaise utilisation d'une fonction.
Combinées à try / except, elles
offrent une gestion robuste des
erreurs sans imposer une convention
de retour fragile à l'appelant.

]]> 1.0 0.0 0 true true abc Lever explicitement une exception, par
exemple avec :

if x < 0:
    raise ValueError("x doit être positif")

]]> L'instruction raise interrompt
immédiatement l'exécution et
signale un problème de manière
explicite. L'appelant peut
capturer cette exception avec
try / except s'il le souhaite,
et le message rend le bug facile à
comprendre.

]]> Renvoyer la valeur $-1$ pour signaler l'erreur

]]> Cette pratique est dangereuse :
l'appelant peut oublier de tester
la valeur de retour, et la valeur
$-1$ peut aussi être un résultat
légitime pour une autre fonction.

]]> Afficher un message avec print puis renvoyer la valeur $0$

]]> L'appel à print ne peut pas être
capturé par l'appelant, et la
valeur $0$ ne se distingue pas
d'un résultat valide. Cette
approche dissimule donc le
problème.

]]> Continuer le calcul comme si de rien n'était

]]> Cette pratique conduit à un
résultat numérique faux (le plus
souvent nan ou une autre valeur
aberrante), ce qui rend le bug
très difficile à diagnostiquer
ensuite.

]]> Mise au point et débogage — Q12 : L'instruction raise Dans quelles situations utilise-t-on
l'instruction raise en Python ?

]]> L'avantage par rapport à un simple
if qui renverrait None : l'erreur
ne peut pas être ignorée
silencieusement, puisque le
programme s'arrête sauf si l'on
capture l'exception explicitement
avec try / except.

]]> 1.0 0.0 0 true true abc Pour lever explicitement une exception et signaler une erreur

]]> On l'utilise par exemple pour
valider un paramètre :

if x < 0: raise ValueError("x

doit être positif")

. C'est une
approche défensive de la
programmation.

]]> Pour multiplier la valeur d'une variable

]]> La multiplication d'une variable
s'écrit avec l'opérateur ,
comme dans x = x 2. Aucun
rapport avec l'instruction
raise.

]]> Pour incrémenter un compteur

]]> L'incrémentation d'un compteur
s'écrit c = c + 1 ou c += 1,
et n'a aucun rapport avec
l'instruction raise.

]]> Pour quitter un programme

]]> Pour quitter un programme, on
utilise plutôt sys.exit(). Une
exception non capturée arrête
aussi l'exécution, mais ce n'est
pas l'usage premier de raise.

]]> Mise au point et débogage — Q13 : Le bloc except sans type Pourquoi le bloc except: sans
précision de type est-il déconseillé ?

]]> Règle d'or : ne jamais ignorer
silencieusement une erreur. Au
minimum, il faut journaliser ce qui
s'est passé, même si l'on choisit
de poursuivre l'exécution.

]]> 1.0 0.0 0 true true abc Parce qu'il capture toutes les exceptions, y compris KeyboardInterrupt (interruption clavier) et SystemExit, ce qui peut masquer des bugs et empêcher l'arrêt propre du programme

]]> Capturer indistinctement toutes
les exceptions est une mauvaise
pratique. Mieux vaut écrire
except Exception: (qui
n'attrape pas les interruptions
clavier) ou, idéalement, capturer
un type d'exception spécifique.

]]> Parce qu'il est plus lent à l'exécution

]]> La performance n'est pas le
critère ici. Le problème est
d'ordre fonctionnel : un
except nu intercepte trop de
choses.

]]> Aucune raison ne justifie de l'éviter

]]> Au contraire, plusieurs raisons
justifient d'éviter le except
nu, comme expliqué dans la bonne
réponse.

]]> Parce que la syntaxe except: n'existe pas en Python

]]> La syntaxe existe et est
syntaxiquement valide. Le
problème est sémantique : elle
capture trop largement.

]]> Mise au point et débogage — Q14 : Le bloc finally À quoi sert le bloc finally dans une
structure try / except ?

]]> Le motif moderne consiste à utiliser
with open(f) as fichier:, qui
ferme automatiquement le fichier,
même en cas d'erreur. Cette syntaxe
est plus concise que la construction
try / finally.

]]> 1.0 0.0 0 true true abc À exécuter du code dans tous les cas, qu'il y ait eu une exception ou non. Il est utile pour les opérations de nettoyage (fermeture de fichiers, libération de ressources)

]]> Exemple typique :
try: f = open(...) suivi de
finally: f.close(). Cette
construction garantit la
fermeture du fichier, même en
cas d'erreur. La construction
plus moderne with (gestionnaire
de contexte) automatise ce type
de gestion.

]]> À ralentir intentionnellement l'exécution

]]> Le bloc finally n'a aucun
objectif de ralentissement. Son
rôle est purement fonctionnel.

]]> À empêcher la levée des exceptions

]]> Le bloc finally ne supprime pas
les exceptions. Il garantit
simplement l'exécution de
certaines instructions, quoi
qu'il advienne.

]]> À exécuter du code uniquement en cas d'erreur

]]> Cette description correspond au
bloc except. Le bloc finally
a un rôle différent : il
s'exécute dans tous les cas.

]]> Mise au point et débogage — Q15 : Mesurer le temps d'exécution Comment mesurer où un script Python
passe le plus de temps ?

]]> Pour mesurer la consommation
mémoire, on utilise memory_profiler.
Pour analyser ligne par ligne le
temps passé, on utilise
line_profiler. Ces deux
bibliothèques s'installent
séparément, par exemple avec
pip install.

]]> 1.0 0.0 0 true true abc Avec un chronomètre

]]> Cette mesure est trop manuelle
et ne permet pas d'identifier
finement les fonctions les plus
coûteuses dans le code.

]]> En le lançant plusieurs fois et en chronométrant

]]> Cette mesure globale du temps
total ne dit pas où, dans le
code, le programme passe son
temps. Or c'est précisément
l'information nécessaire pour
optimiser.

]]> Il est impossible de mesurer cela en Python

]]> Plusieurs outils existent en
Python pour mesurer la
performance d'un script,
notamment cProfile,
line_profiler ou timeit.

]]> Avec la commande python -m cProfile -s time script.py

]]> Cette commande standard affiche
les fonctions triées par temps
cumulé d'exécution, ce qui
permet d'identifier rapidement
les parties les plus coûteuses
du code.

]]> Mise au point et débogage — Q16 : Test de régression Qu'est-ce qu'un test de régression ?

]]> Un cycle classique de correction de
bug consiste à : écrire d'abord un
test qui reproduit le bug et échoue,
puis corriger le code jusqu'à ce
que ce test passe avec succès, puis
enfin nettoyer la structure du code.

]]> 1.0 0.0 0 true true abc Un test ajouté après avoir corrigé un bug, afin de vérifier que ce bug ne réapparaisse pas lors de modifications ultérieures du code

]]> Cette pratique est essentielle
pour éviter qu'un bug déjà
corrigé ne réapparaisse à
l'occasion de modifications
ultérieures. Une discipline
courante consiste à ajouter un
test pour chaque bug corrigé.

]]> Un test trop simple pour être utile

]]> La simplicité d'un test n'a rien
à voir avec sa qualité de test
de régression. Beaucoup de tests
de régression sont d'ailleurs
très simples par construction.

]]> Un test exécuté sur l'ancienne version du code

]]> Un test de régression s'exécute
sur la version courante du
code, et non sur une ancienne
version. Son rôle est de
vérifier qu'un bug ancien ne
réapparaît pas.

]]> Un test qui revient en arrière dans le code source

]]> Cette interprétation littérale du
mot « régression » est inexacte.
Le test de régression vise à
empêcher la réapparition d'un
bug, pas à revenir en arrière
dans le code.

]]> Mise au point et débogage — Q17 : Méthode du canard en plastique Que désigne la méthode dite du canard
en plastique en débogage ?

]]> Plusieurs variantes existent : on
peut expliquer son code à un
collègue, ou rédiger un message
détaillé qu'on n'envoie finalement
pas. De nombreux bugs se résolvent
d'ailleurs au cours de la rédaction
même de l'explication.

]]> 1.0 0.0 0 true true abc Une méthode de compression de code

]]> Aucun rapport avec la
compression. Il s'agit d'une
méthode psychologique de
débogage.

]]> Un type particulier de test automatique

]]> Cette méthode n'a rien à voir
avec un test automatique. Elle
repose sur l'explication
verbale du code, généralement
oralement.

]]> La technique consistant à expliquer son code à voix haute, à un objet ou à un interlocuteur, ce qui force à clarifier sa pensée et révèle souvent l'origine du bug

]]> Cette technique est réelle et
remarquablement efficace. Le fait
d'expliquer le code structure le
raisonnement et fait apparaître
les hypothèses cachées qui
peuvent être à l'origine du
bug.

]]> L'utilisation d'un canard en plastique magique pour résoudre les bugs

]]> Cette interprétation est
plaisante mais ne reflète qu'une
moitié de l'idée. Le sens réel
est plus profond et concerne le
processus mental d'explication.

]]> Mise au point et débogage — Q18 : Trace d'exécution Que produit une trace d'exécution d'un
programme ?

]]> Le module trace de Python permet
d'obtenir une trace très complète,
avec la commande
python -m trace --trace script.py.
Le résultat est verbeux mais utile
pour analyser des comportements
complexes.

]]> 1.0 0.0 0 true true abc Une optimisation du code

]]> La trace est un outil
d'observation du comportement,
et non une transformation du
code visant à le rendre plus
rapide.

]]> Un journal des étapes effectivement exécutées par le programme, incluant les entrées et sorties de fonctions et les valeurs des variables clés

]]> La trace d'exécution permet de
comprendre le déroulement réel
du programme, ce qui est
particulièrement utile pour des
bugs complexes ou intermittents.
Elle peut être réalisée avec
print, logging, ou des
décorateurs dédiés.

]]> Une erreur d'exécution

]]> La trace d'exécution n'est pas
un message d'erreur, mais le
journal complet du déroulement
du programme.

]]> Une simple copie du code source

]]> La trace d'exécution n'est pas
le code source du programme,
mais un journal de son
comportement effectif.

]]> Mise au point et débogage — Q19 : Assertion et exception Quelle est la différence entre une
assertion et la gestion d'exception ?

]]> Une assertion est désactivable avec
l'option python -O (typiquement
en production). Il faut donc éviter
d'utiliser assert pour des
vérifications critiques portant sur
des entrées utilisateur. Pour
celles-ci, il vaut mieux utiliser
raise.

]]> 1.0 0.0 0 true true abc Aucune différence

]]> Les deux mécanismes sont
distincts, à la fois par leur
fonction et par leur usage,
comme détaillé dans la bonne
réponse.

]]> Les assertions s'exécutent plus rapidement

]]> La performance n'est pas le
critère pertinent ici. Les deux
mécanismes ont des rôles
différents.

]]> Les exceptions n'existent pas en Python

]]> Les exceptions sont au contraire
un mécanisme central du langage
Python.

]]> Les assertions vérifient des invariants (des conditions qui ne devraient jamais être fausses) et signalent un bug. Les exceptions, elles, gèrent des conditions exceptionnelles attendues (entrée invalide, fichier manquant) et peuvent être capturées et traitées

]]> On peut résumer ainsi : assert
exprime « cela ne doit jamais
arriver », tandis que
raise combiné à try / except
exprime « cela peut arriver, et
voici comment je le gère ».

]]> Mise au point et débogage — Q20 : Outils d'environnement de développement Quels outils d'un environnement de
développement intégré facilitent le
débogage ?

]]> Un investissement utile consiste à
apprendre les raccourcis clavier
de son environnement de
développement. Les raccourcis
classiques sont F5 pour exécuter
ou déboguer, F10 pour passer à la
ligne suivante, F11 pour entrer
dans une fonction, et F9 pour
poser ou retirer un point d'arrêt.

]]> 1.0 0.0 0 true true abc L'inspecteur de variables, la navigation pas à pas, les points d'arrêt conditionnels, la console interactive et l'analyseur statique

]]> Les environnements modernes
comme VS Code, PyCharm ou
Jupyter offrent tous ces
outils. Un environnement bien
maîtrisé est un accélérateur
majeur du travail de débogage.

]]> Aucun outil particulier n'aide au débogage

]]> Au contraire, les environnements
modernes proposent une riche
palette d'outils dédiés au
débogage.

]]> Uniquement la coloration syntaxique

]]> La coloration syntaxique est
utile, mais loin d'être
suffisante. Les véritables
outils de débogage vont
beaucoup plus loin.

]]> Le simple choix d'un clavier en disposition QWERTY

]]> La disposition du clavier n'a
aucun rapport avec les outils de
débogage de l'environnement de
développement.

]]> Mise au point et débogage — Q21 : Bug fantôme Qu'appelle-t-on un bug fantôme ou
Heisenbug, en référence au principe
d'incertitude de Heisenberg ?

]]> Une stratégie utile consiste à
ajouter du logging systématique
plutôt que des modifications
ponctuelles. Si le bug disparaît
avec l'ajout du logging, c'est un
indice fort qu'il est lié à des
questions de synchronisation
temporelle.

]]> 1.0 0.0 0 true true abc Un bug provenant d'un programme allemand

]]> La référence à Heisenberg
concerne le physicien allemand
du XXe siècle, mais le bug
lui-même n'a aucune origine
géographique particulière.

]]> Un bug visible uniquement la nuit

]]> Cette interprétation est
fantaisiste. Le terme
« fantôme » fait référence à
l'évanescence du bug, pas à
un horaire d'apparition.

]]> Un bug qui disparaît ou change lorsqu'on tente de l'observer (par exemple, en ajoutant des print ou en lançant le programme dans un débogueur). L'origine est souvent liée à des problèmes de synchronisation ou de mémoire non initialisée

]]> Le nom fait référence au
principe d'incertitude
d'Heisenberg : observer le
phénomène le modifie. Ces bugs
sont particulièrement
difficiles à diagnostiquer.
Causes typiques : interactions
entre fils d'exécution
concurrents, mémoire partagée,
dépendances temporelles.

]]> Un bug que l'on ne parvient pas à reproduire

]]> Cette description est incomplète.
La caractéristique essentielle
est plus précise : le bug
disparaît ou change de
comportement quand on essaie de
l'observer.

]]> Mise au point et débogage — Q22 : Fuite de mémoire Qu'appelle-t-on une fuite de mémoire ?

]]> Plusieurs outils permettent de
détecter les fuites de mémoire en
Python : tracemalloc pour suivre
les allocations, ou objgraph
pour visualiser les graphes de
références. Ces outils sont
particulièrement utiles pour les
programmes qui s'exécutent sur de
longues durées, comme les
serveurs.

]]> 1.0 0.0 0 true true abc De l'eau qui s'infiltre dans l'ordinateur

]]> Cette interprétation littérale
est plaisante, mais sans rapport
avec le concept informatique.
Le terme « fuite de mémoire »
décrit un comportement
logiciel.

]]> Une optimisation du programme

]]> Une fuite de mémoire est au
contraire un défaut, qui dégrade
la performance et peut faire
planter le programme à terme.

]]> Une situation dans laquelle le programme conserve des références à des données dont il n'a plus besoin, accumulant ainsi la mémoire utilisée jusqu'à un éventuel arrêt brutal

]]> Ce phénomène est moins fréquent
en Python, qui dispose d'un
ramasse-miettes, qu'en C ou en
C++. Il peut néanmoins se
produire, par exemple via des
caches non bornés ou des
références cycliques associées
à des méthodes spéciales comme
__del__.

]]> La perte d'un fichier sur le disque

]]> Une fuite de mémoire concerne
la mémoire vive utilisée par
un programme, et non un fichier
sur le disque.

]]> Mise au point et débogage — Q23 : Analyse d'un journal d'exécution Face à un programme qui écrit
régulièrement dans un journal
d'exécution, quelle stratégie
d'analyse est la plus efficace
lorsqu'un bug est signalé en
production ?

]]> Bonne pratique : structurer ses
journaux avec des niveaux
(debug, info, warning,
error, critical) et des
horodatages. En cas d'incident,
filtrer le journal par niveau
et par fenêtre temporelle
permet de reconstituer
rapidement la chaîne d'événements
qui a mené au bug.

]]> 1.0 0.0 0 true true abc Lire l'intégralité du journal depuis le début, ligne par ligne

]]> Démarche peu efficace : un
journal de production peut
contenir des millions de lignes.
Il faut cibler la zone
temporelle proche du moment
où le bug s'est produit.

]]> Effacer le journal et redémarrer le programme

]]> Démarche désastreuse : on
perd la principale source
d'information sur le bug. Au
contraire, il faut conserver
précieusement les journaux
des incidents pour pouvoir
les analyser à froid.

]]> Désactiver le journal et compter sur les utilisateurs pour signaler les erreurs

]]> Démarche contre-productive : un
journal détaillé est l'outil
principal de diagnostic en
production. Sans lui, on est
aveugle quand un bug
survient.

]]> Localiser dans le journal la fenêtre temporelle proche de l'erreur, puis remonter à rebours en cherchant le premier événement anormal qui a précédé l'erreur observée

]]> C'est la démarche standard.
On part de la trace d'erreur
(qui donne l'horodatage et le
contexte), on filtre les
lignes voisines (avec grep,
tail, ou un outil dédié),
puis on remonte la chaîne
de causalité. Le journal
révèle alors ce qui a
précédé le plantage : appel
inattendu, état incohérent,
ressource manquante, etc.

]]> Mise au point et débogage — Q24 : Méthodologie face à un bug Quelle est la bonne méthodologie
générale lorsqu'on est confronté à un
bug ?

]]> La discipline est essentielle. Il
faut s'imposer de ne jamais
corriger un bug sans avoir réussi
à le reproduire, et de ne jamais
corriger sans ajouter ensuite un
test. Sinon, le bug finira par
réapparaître, et le temps gagné
au départ sera perdu plus tard.

]]> 1.0 0.0 0 true true abc Réécrire l'intégralité du programme

]]> Réécrire l'ensemble du
programme est rarement la
bonne réponse. Cela demande un
effort considérable et risque
d'introduire d'autres bugs.

]]> Demander la solution à un collègue

]]> Solliciter un collègue peut
être utile dans le diagnostic,
mais ne constitue pas une
méthodologie complète face à un
bug.

]]> Modifier le code au hasard jusqu'à ce que le bug disparaisse

]]> Cette démarche est dangereuse :
elle risque d'introduire de
nouveaux bugs et masque
l'origine réelle du problème.

]]> Reproduire le bug, isoler la cause
(par réduction au cas minimal ou
avec un débogueur), corriger le
code, ajouter un test de
régression, puis documenter si
pertinent

]]> Cette méthodologie est éprouvée.
Sauter une étape, en particulier
l'ajout du test de régression,
garantit que le bug finira par
réapparaître.

]]> Mise au point et débogage — Q25 : Synthèse Parmi les affirmations suivantes sur la
mise au point des programmes, laquelle
est fausse ?

]]> L'adage classique en débogage est :
« si l'on ne peut pas reproduire le
bug, on ne peut pas le corriger ».
La reproduction est l'étape
première, celle qui permet de
mesurer la qualité de la
correction.

]]> 1.0 0.0 0 true true abc La règle d'or consiste à corriger d'abord le bug, puis à essayer de le reproduire

]]> C'est l'inverse qui est vrai
(donc cette affirmation est
bien la fausse). Il faut
d'abord reproduire le bug,
afin de pouvoir vérifier
ensuite que la correction est
effective, puis seulement
corriger.

]]> La construction try / except permet de capturer des exceptions

]]> Cette affirmation est correcte.
C'est précisément le rôle du
mécanisme try / except.

]]> Le profilage indique où, dans le code, le programme passe son temps

]]> Cette affirmation est correcte.
C'est l'un des principaux
objectifs du profilage.

]]> Une assertion qui échoue signale typiquement un bug dans le programme

]]> Cette affirmation est correcte.
Une assertion représente une
vérification d'invariant : si
elle échoue, c'est qu'une
hypothèse fondamentale du
programme est violée.

]]> Mise au point et débogage — Q26 : Le mot-clé with Quel est l'avantage d'écrire

with open("fichier.txt") as f:
    contenu = f.read()

par rapport à

f = open("fichier.txt")
contenu = f.read()
f.close()

]]> Le motif with est en réalité un
gestionnaire de contexte (context
manager). Tout objet implémentant
les méthodes __enter__ et __exit__
peut servir de contexte. C'est utile
pour les fichiers, les connexions
réseau, les verrous, les
transactions de base de données.

]]> 1.0 0.0 0 true true abc La construction with permet
d'écrire dans le fichier sans
ouvrir un mode d'écriture

]]> Erreur : with n'a aucun effet
sur le mode d'ouverture. Pour
écrire dans un fichier, il faut
toujours préciser mode='w' ou
'a', que l'on utilise with ou
non.

]]> La construction with est
obligatoire en Python depuis la
version 3

]]> Erreur : la construction with
n'est pas obligatoire ; elle est
fortement recommandée. La
version manuelle avec open et
close reste valide
syntaxiquement, mais elle est
fragile face aux exceptions.

]]> La construction with est plus
rapide à l'exécution

]]> Erreur : la performance est
identique. L'avantage est dans la
robustesse face aux exceptions, pas
dans la vitesse.

]]> La construction with ferme
automatiquement le fichier à
la sortie du bloc, même si une
exception est levée pendant la
lecture, ce qui évite les fuites
de descripteurs de fichier

]]> Bonne réponse : c'est la principale
raison d'utiliser un gestionnaire
de contexte. Si une exception est
levée pendant le read() dans la
version sans with, l'instruction
f.close() ne sera jamais
exécutée, et le descripteur de
fichier reste ouvert. La construction
with garantit la fermeture, qu'il
y ait erreur ou non. Équivaut à un
try / finally propre.

]]> Mise au point et débogage — Q27 : Optimisation prématurée Donald Knuth a écrit en 1974 :
« L'optimisation prématurée est la
racine de tous les maux ». Quelle est
la signification pratique de cette
maxime pour le développement logiciel ?

]]> Schéma à appliquer : (1) écrire un
programme correct, lisible et
modulaire ; (2) le tester ; (3) si
les performances sont insuffisantes,
le profiler pour identifier les
véritables goulots ; (4) optimiser
ces goulots en mesurant l'impact ;
(5) revérifier que tous les tests
passent. Toute optimisation qui ne
suit pas ce schéma est suspecte.

]]> 1.0 0.0 0 true true abc Il faut optimiser dès la première
ligne de code écrite

]]> Erreur : c'est exactement ce que
Knuth dénonce. Optimiser avant
d'avoir un programme correct
conduit souvent à du code complexe,
buggé, et qui n'apporte pas
forcément le gain attendu.

]]> Cette maxime ne s'applique qu'aux
programmes anciens, pas aux
programmes modernes

]]> Erreur : la maxime reste plus que
jamais d'actualité. Avec la
montée en complexité des
programmes modernes, l'enjeu de
ne pas s'égarer dans des
optimisations inutiles est encore
plus important.

]]> Il ne faut jamais optimiser un
programme

]]> Erreur : Knuth ne dit pas
d'abandonner toute optimisation,
mais d'éviter celle qui n'est pas
nécessaire ou qui se fait sans
mesure. Optimiser les vrais
goulots d'étranglement est
parfaitement légitime.

]]> Il faut d'abord écrire un code
correct et lisible, puis,
seulement si nécessaire et
après mesure, optimiser les
parties effectivement coûteuses
identifiées par le profilage

]]> Bonne réponse : Knuth ajoutait
ensuite que « 97 % du temps, les
micro-optimisations sont à
oublier ». Sans mesure, on
optimise souvent les mauvaises
parties, on dégrade la lisibilité
et on introduit des bugs. Il faut
mesurer avant d'agir : on parle
de « pas d'optimisation aveugle ».

]]>