Déboguer et fiabiliser un programme complexe

Fixer le contrat avant la correction

Supposons une fonction qui compte les valeurs supérieures ou égales à un seuil. Elle reçoit une liste de nombres, accepte la liste vide et renvoie un entier. Elle ne doit pas modifier la liste. Ces précisions définissent la référence qui permet de reconnaître un défaut.

Sans contrat, remplacer ≥ par > pourrait sembler une correction alors que cela change le besoin. Commencez par écrire une entrée, le résultat attendu et une justification indépendante du programme. Le résultat attendu ne doit pas être calculé par une copie du code que l’on cherche justement à vérifier.

Une fiche de bug peut contenir quatre éléments : entrée minimale, attendu calculé à la main, observation et hypothèse de cause. Ajoutez la version du programme si plusieurs corrections sont essayées. Cette trace courte permet de revenir sur une modification et d’expliquer pourquoi le nouveau test est nécessaire.

Choisir des frontières révélatrices

Pour le seuil dix, les valeurs neuf, dix et onze explorent les trois positions utiles. Une liste vide vérifie l’initialisation ; une liste d’un seul élément révèle certains défauts de bornes ; une valeur située uniquement en dernière position détecte un parcours incomplet.

def compter(valeurs, seuil):
    total = 0
    for valeur in valeurs:
        if valeur >= seuil:
            total += 1
    return total

Un jeu de tests raisonné couvre des situations différentes. Répéter dix listes où tous les nombres dépassent largement le seuil apporte moins d’information que tester précisément la valeur égale au seuil.

Localiser la première divergence

Une trace compare l’état attendu à l’état observé après chaque étape. Si le total est correct avant la dernière valeur puis incorrect après, on examine la condition ou l’itération correspondante. Cette méthode évite de modifier plusieurs parties au hasard et de créer des défauts supplémentaires.

Les causes typiques comprennent des types incompatibles, des indices hors limites, des conditions non exhaustives, des inégalités mal choisies, des effets de bord et des noms trompeurs. Les flottants demandent aussi de la prudence : une approximation binaire peut rendre une égalité exacte inadaptée. La solution dépend toujours du problème et de sa précision attendue.

Vérifier que la correction tient

Après correction, rejouez le test qui révélait le défaut, puis les autres cas du contrat. Le premier protège contre le retour de l’erreur ; les autres vérifient que la réparation n’a pas cassé des comportements auparavant corrects. Une assertion exprime une propriété que l’on souhaite surveiller, mais elle ne prouve pas toutes les propriétés du programme.

La lisibilité contribue à la fiabilité : noms précis, fonctions courtes avec responsabilités claires et absence de dépendances cachées facilitent les vérifications. Un test réussi constitue une observation, pas une preuve universelle. Pour certaines propriétés, un invariant ou un raisonnement sur tous les cas complète les essais.

Exemple suivi : isoler deux défauts différents

Prenons la liste [0,10,11] et le seuil 10. L’attendu vaut deux. Une condition stricte oublie 10 et renvoie un ; un parcours qui oublie la dernière case oublie 11 et renvoie également un. Le même résultat incorrect ne suffit donc pas à identifier la cause. Le tableau des décisions par indice sépare les versions : la première diverge à l’indice 1, la seconde à l’indice 2.

Pour isoler la condition, utilisez [10,0] : la version stricte renvoie zéro tandis que l’oubli du dernier élément conserve le compte attendu de un. Pour isoler la borne, utilisez [0,11] : la condition stricte compte bien 11, mais le parcours incomplet l’oublie. Ces deux petits tests discriminants apportent davantage qu’une liste longue reproduisant le même total faux. Une correction doit être reliée à cette cause, puis vérifiée sur le contre-exemple initial.

Exemple suivi : passer du test à un invariant

Après le traitement des k premières valeurs, écrivons la propriété : total est le nombre de valeurs supérieures ou égales au seuil parmi ces k valeurs. Avant toute itération, k=0 et total=0 : aucune valeur n’a été traitée. À l’itération suivante, on ajoute un exactement si la nouvelle valeur satisfait la condition. La propriété est ainsi conservée sur le préfixe agrandi.

Quand k atteint la longueur de la liste, ce préfixe est la liste entière : la propriété fournit le résultat demandé. Le parcours borné garantit la terminaison et accepte naturellement la liste vide. Ce raisonnement explique pourquoi initialiser total à -1 serait incorrect même si une correction locale compensait ce décalage sur certains tests. Les essais révèlent des erreurs ; l’invariant relie toutes les itérations à une signification précise de l’accumulateur.

De la compréhension à l’autonomie

À vous de résoudre

Cherchez d’abord par vous-même. Vérifiez les résultats demandés, utilisez les indices si nécessaire, puis comparez votre méthode à la correction.

Les erreurs qui méritent un détour

Modifier plusieurs lignes au hasard.

Isolez d’abord un contre-exemple et la première divergence.

Utiliser le programme testé pour produire ses résultats attendus.

Cela peut reproduire la même erreur dans le test.

Cette notion au bac

Retrouvez ces idées dans un sujet complet, avec des indices, une correction expliquée et des ateliers.

• Bac 2026 · Métropole · Jour 2 : Taquin : corriger le programme et conserver la résolubilité
• Bac 2026 · Asie · Jour 1 : Perceptron : de la somme pondérée à l’apprentissage supervisé
• Bac 2026 · Asie · Jour 2 : Robots : interpréter des commandes et relayer des messages
• Bac 2026 · Polynésie · Jour 2 : Taquin et recherche de texte : deux parcours à ne pas interrompre trop tôt

Le prochain pas

• Comment résoudre un exercice de NSI
• Concevoir et mener un projet de NSI

Retrouver le catalogue de Terminale

Ce chapitre s’appuie sur le programme officiel de Terminale (PDF, nouvel onglet). Les explications et exercices sont proposés pour l’apprentissage.