$course$/QCM de NSI/Première/Invariants et terminaison Preuve de correction et de terminaison d'une boucle :
invariant de boucle (propriété conservée à chaque
itération) et variant de boucle (quantité entière qui
décroît strictement). Application aux algorithmes
classiques (recherche, tri).

]]> Invariants et terminaison — Q01 : Invariant de boucle Qu'est-ce qu'un invariant de boucle ?

]]> L'invariant sert à prouver que la boucle calcule
bien ce qu'elle doit. À la sortie, l'invariant
combiné à la condition d'arrêt donne la
correction de l'algorithme.

]]> 1.0 0.0 0 true true abc Une exception levée pendant l'exécution de la boucle

]]> Une exception est une
erreur d'exécution. Un
invariant est, lui, une
propriété logique
maintenue tout au long
de la boucle.

]]> Une variable dont la valeur ne change pas dans la boucle

]]> Trop restrictif : un invariant peut concerner
plusieurs variables ou des relations entre
elles.

]]> Une propriété vraie au début et conservée à chaque itération de la boucle

]]> Bonne réponse : c'est une propriété
mathématique qu'on prouve vraie avant la
boucle, puis qu'on prouve conservée à chaque
tour. Elle reste vraie à la sortie.

]]> Une boucle qui ne se termine pas

]]> Erreur : une boucle infinie est un bug, pas
un invariant.

]]> Invariants et terminaison — Q02 : Terminaison Qu'appelle-t-on terminaison d'un algorithme ?

]]> Distinction essentielle : un algorithme peut être
correct (donner le bon résultat s'il
termine) sans terminer (boucle infinie).
On veut prouver les deux propriétés.

]]> 1.0 0.0 0 true true abc Une variable globale nommée fin

]]> La terminaison est une
propriété mathématique
de l'algorithme, et non
le nom d'une variable
dans le code.

]]> Le moment où l'utilisateur appuie sur Ctrl+C

]]> Plaisanterie : c'est une interruption
extérieure, pas la terminaison de
l'algorithme.

]]> Le nom donné à la dernière instruction

]]> Erreur : la terminaison est une propriété
globale, pas une instruction particulière.

]]> La garantie que l'algorithme s'arrête après un nombre fini d'étapes, quelle que soit l'entrée

]]> Bonne réponse : prouver la terminaison, c'est
montrer qu'aucune entrée valide ne fera
boucler indéfiniment l'algorithme.

]]> Invariants et terminaison — Q03 : Variant de boucle Pour prouver la terminaison d'une boucle while,
on cherche un variant. Quelle propriété
doit-il avoir ?

]]> Variant typique : pour la dichotomie, c'est la
taille de l'intervalle d - g qui décroît
strictement. Pour while x > 0: x -= 1, c'est
x lui-même.

]]> 1.0 0.0 0 true true abc Croître à chaque itération

]]> Erreur : un variant croissant ne prouve pas
la terminaison (la suite peut être
non-bornée).

]]> Être un entier (ou une quantité minorée) qui décroît strictement à chaque itération

]]> Bonne réponse : si une quantité entière
décroît strictement et est minorée
(par exemple, par 0), elle ne peut décroître
qu'un nombre fini de fois.

]]> Rester constant

]]> Erreur : un invariant, oui ; un variant,
non.

]]> Être une chaîne de caractères qui change

]]> Erreur : un variant est une quantité
entière (ou minorée), pas une chaîne.

]]> Invariants et terminaison — Q04 : Exemple : recherche linéaire Dans une recherche linéaire avec for i in
range(len(liste)), quel est l'invariant à
l'entrée du tour i ?

]]> Combiner invariant + condition de sortie : à la
sortie (i = n et pas de return), invariant + (i
= n) ⇒ « cible absente ». L'invariant est l'âme
de la preuve.

]]> 1.0 0.0 0 true true abc La cible est plus grande que tous les éléments testés

]]> Erreur : aucune relation d'ordre n'intervient
dans une recherche linéaire générale.

]]> La cible n'est dans aucune position de la liste

]]> Trop fort : on ne sait pas encore si la
cible est plus loin.

]]> La liste est triée

]]> Erreur : la recherche linéaire n'a pas besoin
du tri.

]]> La cible n'a pas été trouvée dans liste[0..i-1] (notation algorithmique pour les éléments déjà parcourus ; en Python : liste[:i])

]]> Bonne réponse : à l'entrée de l'itération
i, on a déjà testé les indices 0 à i-1 et
aucun n'a satisfait le critère. Si on en
avait trouvé un, on aurait fait un return.

]]> Invariants et terminaison — Q05 : Variant for vs while Pour une boucle for i in range(n):, est-il
nécessaire de prouver la terminaison ?

]]> Astuce : si possible, écrire for plutôt que
while pour éviter de devoir prouver la
terminaison. C'est aussi plus lisible.

]]> 1.0 0.0 0 true true abc Oui, mais seulement lorsque $n$ est pair

]]> La parité de $n$ n'a
aucun rapport avec la
terminaison de la
boucle.

]]> Non, mais il faut prouver l'invariant

]]> Pertinent pour la correction mais hors
sujet ici (la question portait sur la
terminaison).

]]> Non, une boucle for sur un itérateur fini termine automatiquement

]]> Bonne réponse : Python garantit la
terminaison d'un for sur un range fini
ou une liste finie. Pas besoin de variant.

]]> Oui, comme pour toute boucle

]]> Trop strict : la terminaison est
automatique pour une boucle for sur un
itérateur fini.

]]> Invariants et terminaison — Q06 : Distinction Invariant et variant : quelle est la différence
essentielle ?

]]> Mnémonique : « in » comme « invariable » →
reste vrai (correction) ; « variant » comme
« ça change vers le bas » → décroît strictement
(terminaison).

]]> 1.0 0.0 0 true true abc Aucune, ce sont synonymes

]]> Erreur : ce sont deux notions distinctes.

]]> Les deux servent à compter les opérations

]]> Erreur : le compteur d'opérations est lié à la
complexité, pas à ces notions.

]]> L'invariant prouve la correction, le variant prouve la terminaison

]]> Bonne réponse : invariant → résultat juste à
la sortie ; variant → la sortie est
atteinte.

]]> L'invariant est de nature mathématique, le variant est de nature physique

]]> Cette distinction est
inexacte : ces deux
notions sont, l'une et
l'autre, des propriétés
mathématiques de la
boucle.

]]> Invariants et terminaison — Q07 : Invariant : somme 
somme = 0
for x in liste:
    somme += x

Quel est l'invariant après k itérations ?

]]> C'est l'invariant le plus simple à formuler :
« la variable accumule progressivement ce
qu'elle doit ». Ce schéma apparaît dans tous
les calculs incrémentaux.

]]> 1.0 0.0 0 true true abc somme = 0

]]> Erreur : la somme augmente.

]]> somme > 0

]]> Erreur : la liste peut contenir des nombres
négatifs.

]]> somme = liste[0]

]]> Erreur : seulement après la première
itération, et pas un invariant général.

]]> somme = somme des k premiers éléments de liste

]]> Bonne réponse : à l'entrée de l'itération
k+1, somme contient la somme des k
éléments déjà parcourus. À la sortie
(k = n), c'est la somme totale.

]]> Invariants et terminaison — Q08 : Variant simple 
n = 10
while n > 0:
    n -= 1

Quel est un variant valide ?

]]> Variant typique : la quantité contrôlée par la
condition d'arrêt, qui converge vers la
condition finale.

]]> 1.0 0.0 0 true true abc n lui-même

]]> Bonne réponse : n est un entier ≥ 0 qui
décroît strictement (n -= 1 à chaque
tour). Quand n atteint 0, on sort.

]]> La constante 10

]]> Erreur : une constante ne décroît pas.

]]> La chaîne "hello"

]]> Erreur : un variant doit être une quantité
entière (ou minorée) qui décroît.

]]> Le booléen n > 0

]]> Erreur : un booléen ne décroît pas (au sens
numérique).

]]> Invariants et terminaison — Q09 : Boucle infinie 
i = 0
while i < 10:
    print(i)

Pourquoi cette boucle ne termine-t-elle pas ?

]]> Bug très classique chez les débutants : oublier
de modifier la variable de boucle. Toujours
vérifier qu'un variant décroît à chaque tour.

]]> 1.0 0.0 0 true true abc Parce que print est interdit

]]> Erreur : print est valide.

]]> Parce que i n'est jamais modifié : il n'y a pas de variant qui décroît

]]> Bonne réponse : la condition i < 10 reste
toujours vraie. Pas de progression vers la
terminaison. Solution : ajouter i += 1
dans la boucle.

]]> Parce que 10 n'est pas un entier

]]> Erreur : 10 est bien un entier.

]]> Parce que Python est lent

]]> Erreur : aucune relation avec la performance.

]]> Invariants et terminaison — Q10 : Pourquoi prouver ? Pourquoi prouver la correction d'un algorithme
au lieu de simplement le tester ?

]]> Citation célèbre de Dijkstra : « Tester ne peut
jamais prouver l'absence de bugs ; au mieux,
cela peut prouver leur présence. »

]]> 1.0 0.0 0 true true abc Parce que les preuves sont plus rapides à écrire

]]> En pratique, c'est souvent l'inverse !

]]> Parce qu'aucun nombre fini de tests ne couvre tous les cas possibles ; une preuve garantit la correction sur toutes les entrées valides

]]> Bonne réponse : les tests valident sur les
cas testés ; la preuve garantit l'absence
de bugs sur toutes les entrées. Pour des
systèmes critiques (avions, médical),
c'est essentiel.

]]> Parce que c'est obligatoire en cours

]]> Argument scolaire, pas scientifique.

]]> Parce que les tests sont chers

]]> Erreur : les tests automatisés sont peu
coûteux.

]]> Invariants et terminaison — Q11 : Trois étapes de preuve Une preuve d'invariant comporte combien
d'étapes ?

]]> C'est la même structure qu'une preuve par
récurrence : initialisation, hérédité,
conclusion. L'invariant de boucle est en fait
une récurrence sur le numéro de l'itération.

]]> 1.0 0.0 0 true true abc Aucune, une preuve d'invariant est implicite

]]> Erreur : il faut bien la justifier.

]]> Trois : initialisation, hérédité (préservation), terminaison

]]> Bonne réponse : (1) Initialisation :
l'invariant est vrai avant la première
itération ; (2) Hérédité : s'il est
vrai à l'entrée d'un tour, il l'est à la
sortie ; (3) Terminaison : à la sortie
de la boucle, l'invariant + la condition
d'arrêt donnent le résultat voulu.

]]> Une seule

]]> Une étape unique ne
permet pas d'établir
la correction d'une
boucle. Il faut au
minimum vérifier
l'initialisation, la
conservation et l'effet
obtenu en sortie.

]]> Cinq

]]> Erreur : trois suffisent.

]]> Invariants et terminaison — Q12 : Invariant : minimum 
m = liste[0]
for x in liste[1:]:
    if x < m:
        m = x

Quel est l'invariant après l'itération sur les
k premiers éléments ?

]]> Schéma « accumulateur » : la variable m
agrège progressivement la propriété (ici, le
min) sur les éléments parcourus.

]]> 1.0 0.0 0 true true abc m == liste[0]

]]> Erreur : m peut être mis à jour.

]]> m == len(liste)

]]> Erreur : pas de relation avec la taille.

]]> m est le minimum des k premiers éléments parcourus

]]> Bonne réponse : à chaque tour, on met à
jour m si l'élément courant est plus
petit. À la fin, c'est le min de toute la
liste.

]]> m == 0

]]> Erreur : pas de raison d'être nul.

]]> Invariants et terminaison — Q13 : Variant dichotomie Pour la recherche dichotomique itérative,
quel est le variant le plus naturel ?

]]> Le variant est ce qui « pousse » l'algorithme
vers sa fin. Pour la dichotomie, c'est
l'intervalle de recherche qui rétrécit.

]]> 1.0 0.0 0 true true abc Le compteur d'itérations

]]> Possible, mais on préfère exprimer le
variant par les variables de l'algorithme.

]]> La longueur de la liste

]]> Erreur : la longueur de la liste est
constante.

]]> La taille de l'intervalle de recherche : d - g + 1

]]> Bonne réponse : à chaque itération,
l'intervalle est divisé par 2 (donc
décroît strictement). Quand il atteint 0
(ou devient négatif), on sort.

]]> La cible

]]> Erreur : la cible est constante.

]]> Invariants et terminaison — Q14 : Bug par variant 
def f(n):
    while n != 1:
        if n % 2 == 0:
            n = n // 2
        else:
            n = 3 * n + 1

Cette boucle termine-t-elle pour tout n entier ≥ 1 ?

]]> Cas instructif : trouver un variant peut être
très difficile. Pour la suite de Syracuse,
personne n'a encore réussi.

]]> 1.0 0.0 0 true true abc Non, car n = 5 fait boucler

]]> Erreur : pour n = 5, la suite atteint 1
rapidement. Aucun contre-exemple connu.

]]> Oui, car n décroît à chaque tour

]]> Erreur : n = 3n + 1 augmente n. Pas de
variant évident qui décroît à chaque tour.

]]> Oui, parce que Python le détecterait

]]> Erreur : Python n'a aucun mécanisme de
détection de boucle infinie.

]]> La terminaison n'est pas connue : c'est la fameuse conjecture de Syracuse (Collatz), non démontrée

]]> Bonne réponse : c'est l'un des plus
célèbres problèmes ouverts en mathématiques.
On a vérifié pour n très grand mais aucune
preuve générale.

]]> Invariants et terminaison — Q15 : Pré et post-conditions Que sont les préconditions et
postconditions d'une fonction ?

]]> L'invariant relie pré et postcondition à
l'intérieur d'une boucle. Ces notions
structurent la programmation par contrat.

]]> 1.0 0.0 0 true true abc La précondition est ce que la fonction suppose sur ses arguments ; la postcondition est ce qu'elle garantit sur le résultat

]]> Bonne réponse : « si X (précondition) est
vraie en entrée, alors Y (postcondition)
est vraie en sortie ». C'est un contrat.

]]> Des décorateurs Python

]]> Possible avec des bibliothèques (par
exemple icontract), mais ce n'est pas la
définition.

]]> Le code situé avant et après l'appel à la fonction

]]> Cette interprétation
littérale du nom est
inexacte. Les pré- et
postconditions sont des
propriétés logiques sur
les arguments et le
résultat, et non des
fragments de code.

]]> Des commentaires inutiles

]]> Erreur : ce sont des éléments de
spécification rigoureuse.

]]> Invariants et terminaison — Q16 : Décroissance stricte Pourquoi le variant doit-il décroître
strictement (et pas seulement « ne pas
augmenter ») ?

]]> Mathématiquement, une suite d'entiers
strictement décroissante et minorée par 0 est
finie (par bonne fondation de ℕ). Cette
propriété fonde la preuve de terminaison.

]]> 1.0 0.0 0 true true abc Parce que la preuve serait plus longue à rédiger sinon

]]> La longueur de la preuve
n'est pas le motif. La
décroissance stricte est
requise pour des raisons
mathématiques de fond,
comme expliqué dans la
bonne réponse.

]]> Parce qu'une suite d'entiers minorée et qui ne décroît pas strictement peut stagner indéfiniment

]]> Bonne réponse : la stagnation = boucle
infinie. La décroissance stricte garantit
que l'on s'approche du seuil de sortie à
chaque tour.

]]> Pour rendre la démonstration plus élégante visuellement

]]> La décroissance stricte
répond à un besoin
mathématique précis :
assurer que la boucle
ne stagne pas et finit
par s'arrêter.

]]> Parce que Python l'exige

]]> Erreur : Python n'a pas cette contrainte.

]]> Invariants et terminaison — Q17 : Invariant : tri par sélection Dans le tri par sélection, après la k-ème
itération de la boucle externe, quel est
l'invariant ?

]]> Cet invariant rend la correction du tri par
sélection évidente : à la fin (k = n), les n
premiers (= toute la liste) sont triés.

]]> 1.0 0.0 0 true true abc Les k premiers éléments sont triés et plus petits que tous les autres

]]> Bonne réponse : c'est l'invariant clé du
tri par sélection. À l'itération k, on a
fixé les positions 0..k-1 avec les k plus
petits éléments dans l'ordre.

]]> La liste est entièrement triée

]]> Trop fort : seules les k premières
positions sont triées.

]]> Les k premiers éléments sont les plus grands

]]> Erreur : le tri par sélection met les plus
petits en début (tri croissant).

]]> La liste est inchangée

]]> Erreur : on a fait des échanges.

]]> Invariants et terminaison — Q18 : Variant multivarié Pour la dichotomie itérative, peut-on choisir
g (l'indice de gauche) seul comme variant ?

]]> Astuce : si une variable augmente, prendre son
complément (par exemple n - i) comme variant.
Le choix du variant est souvent affaire de
reformulation.

]]> 1.0 0.0 0 true true abc Oui, parfait

]]> Erreur : g peut rester constant si c'est
d qui change.

]]> Non, parce que g n'est pas un entier

]]> Erreur : g est bien un entier.

]]> Non, parce que g ne décroît pas (il augmente ou reste constant)

]]> Bonne réponse : on cherche une quantité
qui décroît. Avec g qui augmente, il
faut prendre par exemple n - g ou bien
la taille de l'intervalle d - g.

]]> Oui, mais seulement si la liste est triée

]]> Erreur : la précondition de tri n'a aucun
rôle dans la terminaison.

]]> Invariants et terminaison — Q19 : Bonne formulation Pour qu'un invariant soit utile à la preuve,
il faut qu'il soit :

]]> Trop faible : ne dit rien d'utile. Trop fort :
faux. Le bon niveau est celui qui, combiné à la
condition d'arrêt, donne exactement la
postcondition.

]]> 1.0 0.0 0 true true abc Long et compliqué

]]> Au contraire, on cherche le plus simple
possible.

]]> Toujours faux

]]> Absurde : un invariant doit être vrai.

]]> Codé dans Python

]]> Sans rapport : un invariant est une
propriété mathématique.

]]> Vrai à l'initialisation et suffisamment fort pour impliquer la postcondition au moment de la sortie

]]> Bonne réponse : un invariant trop faible
ne donne rien à la sortie ; un invariant
trop fort peut être faux. Trouver le bon
niveau est tout l'art.

]]> Invariants et terminaison — Q20 : Outils Quel outil aide à détecter un bug dans un
invariant ?

]]> Les assert sont une excellente pratique :
ils transforment des invariants implicites en
vérifications explicites, attrapant les bugs
au plus tôt.

]]> 1.0 0.0 0 true true abc Un débogueur visuel

]]> Possible mais vague. Quelque chose de plus
précis est demandé.

]]> Un commentaire # TODO

]]> Erreur : un commentaire ne vérifie rien.

]]> Un assert placé dans la boucle pour vérifier l'invariant à l'exécution

]]> Bonne réponse : par exemple
assert m == min(liste[:i+1]). Si
l'invariant échoue à un tour, Python lève
AssertionError et indique le bug.

]]> La fonction print()

]]> Possible mais moins systématique qu'un
assert.

]]> Invariants et terminaison — Q21 : Invariant insuffisant Pour le tri par sélection, l'invariant
« les k premiers éléments sont triés » est-il
suffisant ?

]]> Bon invariant pour la sélection :
liste[0..k-1] (en Python : liste[:k]) est
trié et ne contient que des éléments
plus petits que tout ceux de liste[k..n-1]
(en Python : liste[k:]). Les deux
conditions sont nécessaires.

]]> 1.0 0.0 0 true true abc Oui, à condition d'utiliser un tri stable

]]> Erreur : la stabilité n'a aucun rôle ici.

]]> Oui, à condition que la liste soit triée à l'avance

]]> Erreur : on n'a pas cette précondition.

]]> Oui, c'est suffisant

]]> Insuffisant : « les k premiers triés » ne
dit pas qu'ils sont les plus petits. Si le
maximum se retrouvait en liste[0] et le
minimum en liste[1], ce serait « trié »
(ordre 1 puis 2 éléments), mais incorrect.

]]> Non, il manque la condition que ces éléments soient plus petits que ceux de liste[k..n-1] (en Python : liste[k:])

]]> Bonne réponse : sans cette condition
supplémentaire, l'algorithme pourrait
terminer avec liste[0..k-1] (en Python :
liste[:k]) triés mais contenant des
« gros » éléments, et le résultat final
serait faux.

]]> Invariants et terminaison — Q22 : Trouver le variant 
while a > b:
    a = a - b

(avec a, b entiers, b > 0). Quel est un
variant valide ?

]]> Cette boucle calcule a mod b (reste de la
division euclidienne). C'est un cas classique
illustrant variant et terminaison.

]]> 1.0 0.0 0 true true abc a (qui décroît strictement à chaque tour, et est minoré par b à la sortie)

]]> Bonne réponse : à chaque tour a -= b
avec b > 0 donc a décroît
strictement. La boucle se termine quand
a <= b.

]]> La constante 1

]]> Erreur : une constante ne décroît pas.

]]> b

]]> Erreur : b ne change pas dans la boucle.

]]> a - b

]]> Possible, mais à chaque tour a - b
change : à voir si décroissance stricte.
On peut faire mieux et plus simple.

]]> Invariants et terminaison — Q23 : Preuve par récurrence Pourquoi la preuve d'un invariant fait-elle
penser à une preuve par récurrence ?

]]> C'est le pont entre mathématiques et
informatique : la preuve algorithmique
utilise les outils du raisonnement
mathématique. L'invariant est une propriété
P(k) à prouver par récurrence sur k.

]]> 1.0 0.0 0 true true abc Parce que les deux utilisent des indices

]]> Vague et superficiel.

]]> Aucun rapport entre les deux

]]> Erreur : la similarité est profonde.

]]> Parce qu'on prouve l'invariant à la 1ʳᵉ itération (initialisation), puis qu'on prouve qu'il est conservé d'une itération à la suivante (hérédité), exactement comme une récurrence sur le numéro d'itération

]]> Bonne réponse : invariant de boucle =
récurrence sur le compteur d'itérations.
C'est la même structure logique.

]]> Parce que c'est imposé par les règles du langage

]]> Aucun langage de
programmation n'impose
de prouver les
invariants par
récurrence. C'est une
démarche
mathématique, qui
relève du raisonnement,
pas du langage.

]]> Invariants et terminaison — Q24 : Inventer l'invariant 
r = 0
n = N
while n > 0:
    n = n // 2
    r = r + 1

Que calcule cette boucle, et quel invariant
rend ce calcul évident ?

]]> Cet algorithme calcule le logarithme entier.
C'est aussi la base de la complexité O(log n)
de la dichotomie : on divise par 2 jusqu'à
atteindre 0.

]]> 1.0 0.0 0 true true abc La boucle compte de 1 à N

]]> Erreur : n est divisé par 2, pas
décrémenté.

]]> r est toujours 0

]]> Erreur : r est incrémenté.

]]> r compte le nombre d'itérations ; à la fin, r ≈ ⌊log₂(N)⌋ + 1. Invariant : 2^r * n ≥ N (avant l'itération courante).

]]> Bonne réponse : on divise par 2 jusqu'à
atteindre 0, en comptant. C'est le calcul
du logarithme entier en base 2. Le
variant : n (qui décroît
strictement par division entière).

]]> La boucle ne termine pas

]]> Erreur : n // 2 ramène n à 0 en log₂(N)
étapes.

]]> Invariants et terminaison — Q25 : Synthèse Parmi les affirmations suivantes sur les
invariants et la terminaison, laquelle est
fausse ?

]]> Distinction terminologique : correction
partielle = « si termine, alors juste » ;
correction totale = correction partielle +
terminaison. C'est la correction totale qu'on
veut habituellement.

]]> 1.0 0.0 0 true true abc Un programme correct est nécessairement un programme qui termine

]]> Faux (donc bonne réponse) : la correction
est une propriété conditionnelle :
« si le programme termine, le résultat
est juste ». La terminaison est une
propriété distincte. Un programme
peut être correct mais ne pas terminer
(par exemple s'il calcule une fonction
partielle).

]]> Un variant doit être un entier (ou une quantité minorée) qui décroît strictement

]]> Vrai : sinon la décroissance peut être
infinie.

]]> Un invariant doit être vrai à chaque entrée d'itération

]]> Vrai : c'est sa définition.

]]> Toute boucle for i in range(n) se termine, sans qu'on ait besoin de prouver de variant

]]> Vrai : la boucle for sur un itérateur
fini termine automatiquement.

]]> Invariants et terminaison — Q26 : Invariant : tri par insertion Dans le tri par insertion, après l'itération
i de la boucle externe, quel invariant
caractérise correctement l'état de la liste ?

]]> Différence clé avec le tri par sélection :
l'invariant de l'insertion porte sur le tri
d'une partie initiale (sans hypothèse sur les
valeurs), alors que celui de la sélection
ajoute la condition « plus petits que les
autres ».

]]> 1.0 0.0 0 true true abc La sous-liste liste[0..i] (en Python : liste[:i+1]) contient les mêmes éléments qu'au début, mais elle est triée

]]> Bonne réponse : c'est l'invariant clé du
tri par insertion. Les i + 1 premiers
éléments restent les mêmes (à l'ensemble
près) qu'avant la boucle, mais maintenant
ordonnés. À la dernière itération
i = n - 1, toute la liste est triée.

]]> La liste est entièrement triée

]]> Erreur : trop fort. À l'itération i,
seuls les i + 1 premiers éléments sont
triés ; les éléments suivants n'ont pas
encore été traités.

]]> Les i premiers éléments sont les plus grands

]]> Erreur : ce serait un tri décroissant ou
un tri par sélection inversé. Le tri par
insertion classique est croissant et ne
place pas les plus grands en tête.

]]> Les i premiers éléments sont triés et plus petits que tous les autres

]]> Erreur : c'est l'invariant du tri par
sélection. Le tri par insertion ne
place pas les plus petits en tête à chaque
étape ; il insère le i-ème élément à sa
place dans la partie déjà traitée.

]]> Invariants et terminaison — Q27 : Terminaison de l'algorithme d'Euclide L'algorithme d'Euclide pour le PGCD s'écrit :
def pgcd(a, b):
    while b != 0:
        a, b = b, a % b
    return a

(avec a, b entiers naturels, b > 0 à
l'entrée). Quel est un variant qui prouve la
terminaison ?

]]> Une remarque profonde : ici, l'invariant
est pgcd(a, b) = pgcd(a₀, b₀) (la valeur
initiale du PGCD est conservée), tandis que le
variant est b. À la sortie, l'invariant
donne pgcd(a, 0) = a₀ ∗, ce qui est bien le
PGCD recherché.

]]> 1.0 0.0 0 true true abc La valeur de b

]]> Bonne réponse : à chaque itération, b
devient a % b, qui est strictement
inférieur à l'ancien b. Comme b est un
entier naturel minoré par 0, la suite des
valeurs de b est strictement décroissante
et finie. La boucle se termine donc.

]]> Le PGCD lui-même

]]> Erreur : l'invariant de l'algorithme est
précisément que pgcd(a, b) reste
constant à chaque itération. Une quantité
constante ne peut servir de variant (qui
doit décroître strictement).

]]> La somme a + b

]]> Erreur : la somme peut augmenter ou
stagner selon les cas. Par exemple
pgcd(5, 12) : avant, a + b = 17 ;
après, a + b = 12 + 5 = 17. Donc pas de
décroissance stricte.

]]> La valeur de a

]]> Erreur : a ne décroît pas forcément à
chaque tour. Par exemple avec a = 5,
b = 12, après une itération on a
a = 12, b = 5, donc a a augmenté.

]]> Invariants et terminaison — Q28 : Assertion d'invariant en pratique On suspecte qu'une boucle calcule mal une
somme. Quel ajout permet de détecter
automatiquement une violation d'invariant
pendant l'exécution ?

]]> Bonne pratique : exprimer les invariants
critiques sous forme d'assertions pendant la
phase de développement. Cela transforme les
bugs silencieux en erreurs immédiates et
réduit considérablement le temps de
débogage.

]]> 1.0 0.0 0 true true abc Un commentaire # vérification de l'invariant

]]> Erreur : un commentaire est inerte. Il
n'est lu que par le programmeur, pas par
l'interpréteur Python. Aucun bug ne peut
être détecté ainsi.

]]> Une instruction assert exprimant l'invariant attendu, par exemple assert somme == sum(liste[:i+1])

]]> Bonne réponse : assert lève
immédiatement une AssertionError si la
condition est fausse, ce qui localise
précisément l'itération où l'invariant a
été rompu. C'est un outil de débogage très
efficace, à retirer ou à désactiver
(python -O) en production.

]]> Une exception try/except autour de la boucle

]]> Erreur : un try/except capture les
erreurs levées par Python, pas les
violations d'invariant logique. Si la
boucle calcule une mauvaise somme sans
erreur d'exécution, le try/except ne
détectera rien.

]]> Un appel à print affichant la valeur courante de la variable

]]> Possible mais limité : il faut alors
inspecter la sortie à l'œil nu et
identifier visuellement une anomalie. Pas
de détection automatique.

]]>