$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 du tout le programme

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

]]> Une erreur signalée à l'exécution, qui interrompt le programme

]]> 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.

]]>

try {
    risque()
} catch (Exception e) {
    print("Erreur :", e)
}

]]> Cette syntaxe à accolades, avec
catch, est celle de Java ou de C++,
pas celle de Python, qui emploie try
et except suivis de deux-points et
d'un bloc indenté.

]]>

resultat = risque()
if resultat == error:
    print("Erreur :", resultat)

]]> Ce code ne gère rien : si risque()
lève une exception, le programme
s'arrête avant même d'atteindre le
if. 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 filtrer les messages selon leur niveau de gravité

]]> 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 du tout 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 — 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é complète 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 vérifiant que plusieurs modules marchent ensemble

]]> 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 menant à l'erreur

]]> 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 pour inspecter les variables

]]> 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 fichier du 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é.

]]> Sans reproduction, impossible de vérifier la correction

]]> 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 l'entrée au cas le plus simple qui reproduit encore le bug

]]> 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 avec raise

]]> Bonne réponse, par exemple :

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 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 par deux

]]> 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 Il capture toutes les exceptions, même les interruptions clavier

]]> 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 tout simplement 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 (nettoyage)

]]> 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 lorsqu'une erreur survient

]]> 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 qui empêche un bug corrigé de réapparaître plus tard

]]> 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 — 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 réellement exécutées

]]> 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 intégrale du code source du programme

]]> 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 toujours bien plus rapidement que les exceptions

]]> 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 signalent un bug, les exceptions gèrent des cas attendus

]]> 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 Inspecteur de variables, pas à pas et points d'arrêt

]]> 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 AZERTY ou 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 change dès qu'on tente de l'observer

]]> 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 absolument jamais à 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 — 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.

]]> Cibler la fenêtre temporelle de l'erreur, puis remonter à l'événement anormal

]]> 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 finisse par disparaître

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

]]> Reproduire, isoler, corriger, puis ajouter un test de régression

]]> 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 Il faut corriger le bug d'abord, 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, même en cas d'exception

]]> 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.

]]>