Aller au contenu
FR

Numérique et sciences informatiques (spécialité) · TerminaleBac

Mise au point des programmes : cours de Terminale NSI

Publié le 7 novembre 2026 · Mis à jour le 7 novembre 2026 · Signaler une erreur

L'essentiel

  • La mise au point (ou débuggage) consiste à faire apparaître un bug, à le rejouer à volonté, à le localiser puis à le corriger.2
  • Un bug ne fait pas toujours planter le programme : un résultat faux sans message d'erreur est le cas le plus piégeux.2
  • Une assertion vérifie un seul point précis du programme ; on en écrit une par vérification.1
  • Démarche type : constater, reproduire sur le plus petit exemple, localiser, corriger, puis relancer tous les tests.
  • Un programme écrit en petites fonctions, chacune testable seule, est plus facile à mettre au point.2

Pourquoi apprendre à mettre au point un programme

Un programme de quelques dizaines de lignes qui fonctionne dès la première exécution est rare. Même en programmation professionnelle, une grande partie du temps passe à chercher pourquoi un programme ne fait pas ce qu'on attendait. Savoir mener cette recherche avec méthode, au lieu de modifier le code au hasard en espérant que ça marche, fait gagner un temps considérable.

Le programme de numérique et sciences informatiques de terminale de la voie générale est accompagné de ressources publiées par Éduscol. L'une d'elles porte précisément sur la mise au point des programmes et la gestion des bugs.3 C'est donc une compétence attendue, que tu retrouveras dans tes projets et dans tes exercices de programmation, pas un simple « truc » de débrouillard.

Ce cours vient après la calculabilité, la récursivité, la modularité et les paradigmes de programmation. Tu vas t'appuyer sur ce que tu sais déjà : écrire des fonctions, les appeler, les découper en modules. La mise au point réutilise ces notions : plus ton programme est découpé proprement, plus il est facile à vérifier morceau par morceau.

Bug et mise au point : le vocabulaire

Un bug ne se manifeste pas toujours de la même façon. Dans certains cas, le programme s'arrête avec un message d'erreur : on dit qu'il « plante ». Mais tout dépend des données fournies : un même programme peut planter avec certaines entrées et pas avec d'autres.2 Il peut très bien se terminer normalement en affichant un résultat faux. C'est le cas le plus dangereux : personne ne te signale rien, et tu peux rendre un programme faux en croyant qu'il est juste.

On distingue donc deux situations :

  • le programme plante : le message d'erreur indique le type d'erreur et la ligne où elle s'est produite, ce qui donne une première piste ;
  • le programme se termine mais donne un mauvais résultat : aucun message, il faut détecter l'erreur en comparant le résultat obtenu au résultat attendu.

Reproduire le bug : le premier geste

Avant de chercher la cause d'un bug, il faut pouvoir le provoquer quand on veut. Éduscol range ce geste parmi les compétences de la mise au point : être capable de mettre le bug en évidence, puis de le rejouer.2 Un bug qu'on ne sait pas reproduire ne peut pas être corrigé de façon fiable, puisqu'on ne pourra jamais vérifier qu'il a disparu.

Les assertions : tester un point précis

Une fois le bug reproduit, on veut le fixer dans un test qui échoue tant que le bug existe et qui réussit quand il est corrigé. En Python, l'outil naturel est l'assertion, introduite par le mot-clé assert, suivi d'une condition qui doit être vraie. Si la condition est fausse, le programme s'arrête en signalant une erreur d'assertion ; si elle est vraie, il continue sans rien dire.

« Il ne faut tester qu'un point précis du programme sous forme d'une assertion unique. »1

Recommandation d'Éduscol

Cette recommandation a une raison pratique. Si tu regroupes plusieurs vérifications dans une seule assertion (par exemple en les reliant par and), un échec te dit seulement que quelque chose ne va pas, sans dire quoi. Avec une assertion par point précis, la ligne qui échoue désigne directement le cas fautif.1

Observer l'exécution pour localiser la cause

Le test qui échoue te dit **qu'**il y a un problème, pas où il se trouve dans le code. Localiser la cause demande d'observer ce que le programme fait réellement, étape par étape, et de comparer avec ce que tu pensais qu'il faisait.

La démarche de mise au pointCinq étapes successives : constater l'écart, reproduire sur un petit exemple, localiser la cause, corriger, vérifier avec tous les tests.1ConstaterComparer résultat obtenu et résultat attendu2ReproduireTrouver le plus petit exemple qui échoue3LocaliserObserver les variables, isoler la ligne fautive4CorrigerFaire une seule modification à la fois5VérifierRelancer toutes les assertions
  1. ConstaterComparer résultat obtenu et résultat attendu
  2. ReproduireTrouver le plus petit exemple qui échoue
  3. LocaliserObserver les variables, isoler la ligne fautive
  4. CorrigerFaire une seule modification à la fois
  5. VérifierRelancer toutes les assertions
La démarche de mise au point · Chaque étape prépare la suivante ; on revient à l'étape 3 si la correction échoue.

Les familles d'erreurs

Savoir classer l'erreur oriente la recherche. On rencontre en général trois familles.

Écrire des programmes faciles à mettre au point

On peut réduire le travail de débogage en amont. Les ressources d'Éduscol soulignent que la mise au point devient plus aisée quand le programme a été écrit en suivant quelques principes.2 Voici ceux qui t'aideront dans la pratique, en lien avec la modularité que tu as étudiée.

L'histoire des langages éclaire ce point. Le langage BASIC, créé en 1963 comme version simplifiée de FORTRAN pour les débutants, était interprété, ce qui facilitait beaucoup la mise au point des programmes.4 Cette facilité explique en partie sa popularité rapide. Mais la pauvreté de ses constructions favorisait des programmes non structurés, difficiles à maintenir.4 Un langage qui permet d'essayer vite ne dispense donc pas d'écrire du code bien organisé : les deux qualités se complètent.

Une mise au point complète, étape par étape

Déroulons toute la démarche sur un exemple. On veut une fonction maximum(liste) qui renvoie le plus grand élément d'une liste non vide de nombres.

Les pièges fréquents de la mise au point

Exercices corrigés

Exercice 1 Dérouler une fonction à la main

★☆☆Environ 8 min

On considère la fonction suivante, censée calculer la somme des entiers de 1 à n :

def somme(n):
    s = 0
    for i in range(n):
        s += i
    return s
  1. Dresse le tableau de suivi de s et de i pour l'appel somme(5).
  2. Quelle valeur renvoie somme(5) ?
  3. Quelle valeur était attendue ? Quel est le type de ce bug (syntaxe, exécution ou logique) ?
  4. Écris une assertion qui détecte le bug, puis propose une correction.
Indice 1

range(5) produit les entiers 0, 1, 2, 3, 4 : le 5 n'y figure pas.

Indice 2

Pour sommer de 1 à n, il faut que i prenne les valeurs de 1 à n inclus.

Voir la correction pas à pas

  1. Pour somme(5), i prend successivement les valeurs 0, 1, 2, 3 et 4. Le tableau de s après chaque tour est : 0, 1, 3, 6, 10.

  2. La fonction renvoie donc 10.

  3. La somme attendue de 1 à 5 est 15. Le programme s'est exécuté sans message : c'est une erreur de logique, due à la borne de range.

  4. Assertion : assert somme(5) == 15. Correction : remplacer la boucle par for i in range(1, n + 1):. Après correction, i vaut 1, 2, 3, 4, 5 et s vaut 15.

Le bug n'a déclenché aucune erreur : seule la comparaison avec le résultat attendu l'a révélé. Le tableau de suivi a localisé la cause (la borne de range) sans deviner.

Exercice 2 Tester et corriger une moyenne

★★☆Environ 15 min

Voici une fonction censée renvoyer la moyenne d'une liste de nombres :

def moyenne(liste):
    total = 0
    for x in liste:
        total += x
    return total / (len(liste) - 1)
  1. Quelle valeur renvoie moyenne([4, 8, 6]) ? Quelle valeur est attendue ?
  2. Écris deux assertions, chacune testant un seul point précis, qui échouent sur cette version.
  3. Corrige la fonction.
  4. Quel problème reste-t-il pour la liste vide ? Propose une précondition sous forme d'assertion dans la fonction.
Indice 1

Calcule d'abord total : 4 + 8 + 6, puis divise par len(liste) - 1.

Indice 2

Pour la liste vide, len(liste) vaut 0 : que devient la division ?

Voir la correction pas à pas

  1. total vaut 18 et len(liste) - 1 vaut 2, donc la version fautive renvoie 9. La moyenne attendue est 18 divisé par 3, soit 6.

  2. Deux assertions séparées : assert moyenne([4, 8, 6]) == 6 et assert moyenne([5]) == 5. La seconde échoue aussi : elle provoque une division par zéro, car len([5]) - 1 vaut 0. Chaque assertion cible un point précis.1

  3. Correction : diviser par len(liste) au lieu de len(liste) - 1.

  4. Avec une liste vide, la division se fait par zéro et le programme plante. On ajoute en tête : assert len(liste) > 0, 'liste vide interdite'. Le problème est alors signalé clairement, avec un message qui dit ce qui ne va pas.

Une seule modification d'une ligne a corrigé le cas ordinaire et le cas à un seul élément. Le cas de la liste vide a demandé une décision différente : une précondition explicite plutôt qu'un résultat inventé.

Exercice 3 Isoler un bug qui dépend de l'entrée

★★★Environ 20 min

La fonction nb_chiffres(n) doit renvoyer le nombre de chiffres de l'écriture décimale d'un entier positif ou nul n. Par convention, l'entier 0 s'écrit avec un chiffre.

def nb_chiffres(n):
    c = 0
    while n > 0:
        n = n // 10
        c += 1
    return c

Un camarade affirme : « ma fonction marche, je l'ai testée avec 405, 7045 et 12. »

  1. Vérifie ses trois exemples en déroulant la fonction.
  2. Trouve une entrée pour laquelle la fonction est fausse et explique pourquoi les tests du camarade ne l'ont pas détectée.
  3. Écris un jeu d'assertions couvrant les cas limites.
  4. Corrige la fonction sans casser les cas qui marchaient.
Indice 1

Qu'arrive-t-il à la condition n > 0 quand n vaut 0 dès le départ ?

Indice 2

Pour corriger, tu peux traiter le cas 0 séparément avant la boucle.

Voir la correction pas à pas

  1. Pour 405 : n passe à 40, puis 4, puis 0, soit 3 tours : le résultat est 3. Pour 7045 : 704, 70, 7, 0, soit 4 tours. Pour 12 : 1, puis 0, soit 2 tours. Les trois exemples sont corrects.

  2. Pour n = 0, la condition n > 0 est fausse dès le début, la boucle ne s'exécute pas et la fonction renvoie 0 au lieu de 1. Les exemples du camarade étaient tous strictement positifs : aucun ne visitait le cas limite 0.

  3. Assertions, une par point : assert nb_chiffres(0) == 1, assert nb_chiffres(5) == 1, assert nb_chiffres(10) == 2, assert nb_chiffres(405) == 3. Le cas 10 teste le passage d'un nombre de chiffres à l'autre.

  4. Correction : ajouter en début de fonction if n == 0: puis return 1. On relance toutes les assertions : les quatre passent, et les exemples 405, 7045 et 12 donnent toujours le résultat attendu.

Un jeu de tests ne vaut que par les familles de cas qu'il visite. Ici, le bug ne dépendait que d'une valeur d'entrée, le cas limite 0, que les exemples « ordinaires » ne rencontraient jamais.

Quiz

8 questions · correction immédiate · ton score reste sur ton appareil.

  1. D'après les ressources d'Éduscol sur la gestion des bugs, comment appelle-t-on aussi la mise au point d'un programme ?

  2. Selon la recommandation d'Éduscol, que doit tester une assertion ?

  3. Un programme qui se termine sans afficher de message d'erreur est forcément correct.

  4. On reprend la fonction somme(n) de l'exercice 1 (boucle for i in range(n) avec s += i). Quelle valeur renvoie somme(4) ?

  5. Un utilisateur signale que ta fonction donne un résultat faux. Quelle est la première chose à faire ?

  6. Parmi ces pratiques, lesquelles facilitent la mise au point d'un programme ? (plusieurs réponses)

    Plusieurs réponses possibles.

  7. Le langage BASIC, créé en 1963, était interprété, ce qui facilitait la mise au point des programmes.

  8. La fonction maximum initialise m = 0 puis parcourt la liste. Pourquoi renvoie-t-elle 0 pour [-3, -8, -5] ?

Les questions qu'on se pose

Quelle différence entre une assertion et une instruction if ?

Un if choisit entre plusieurs chemins d'exécution : le programme continue dans les deux cas. Une assertion affirme qu'une condition est vraie à cet endroit ; si elle est fausse, le programme s'arrête avec une erreur, car quelque chose ne s'est pas passé comme prévu. On utilise if pour gérer des situations normales du programme, et assert pour vérifier des hypothèses (un test, une précondition).

Comment savoir si un bug vient de ma fonction ou de la fonction que j'appelle ?

Teste chacune séparément. Si la fonction appelée réussit ses assertions seule, regarde comment ta fonction lui passe les données (ordre des paramètres, valeurs transmises). Afficher avec print les valeurs reçues et renvoyées de part et d'autre de l'appel montre à quel endroit l'écart apparaît. C'est un argument de plus pour écrire des fonctions courtes et testables seules.

Est-ce que plus d'assertions garantit que mon programme est correct ?

Non. Des assertions prouvent que les cas testés fonctionnent, pas que tous les cas fonctionnent. En revanche, des assertions bien choisies (cas ordinaires, cas limites, cas particuliers, cas des bugs déjà rencontrés) rendent les erreurs bien moins probables. Mieux vaut peu d'assertions bien ciblées, chacune sur un point précis,1 qu'un grand nombre de tests identiques.

Mon programme plante seulement avec certaines données : est-ce normal ?

Oui, c'est courant : un programme ne plante pas systématiquement, cela dépend de ce qu'on lui fournit.2 Une division par zéro n'apparaît que si le diviseur vaut zéro, un indice hors liste que si la liste est trop courte. C'est pourquoi la première étape est de noter l'entrée exacte qui provoque le problème et de la rejouer.

Faut-il savoir mettre au point un programme au bac ?

La mise au point des programmes et la gestion des bugs figurent dans les ressources associées au programme de NSI de terminale.3 Dans les épreuves, cela se traduit par la capacité à lire un code, repérer ce qui est faux, prévoir ce qu'il renvoie sur une entrée donnée et proposer des tests ou une correction. Entraîne-toi à dérouler des fonctions à la main : c'est la compétence la plus directement utile.

Sources

  1. Mise au point de programmes, gestion des bugs, Éduscol. Consulté le 7 novembre 2026.
  2. Gestion des bugs NSI - Ressources d'accompagnement, Éduscol. Consulté le 7 novembre 2026.
  3. Programmes et ressources en numérique et sciences informatiques, Éduscol. Consulté le 7 novembre 2026.
  4. Programmation impérative, Wikipédia. Consulté le 7 novembre 2026.

Les numéros dans le texte renvoient à ces sources. Une source qui ne dit pas ce qu'on lui fait dire ? Signale-le.

Signaler une erreur sur cette page

Je suis en…

Primaire

  • CP Bientôt
  • CE1 Bientôt
  • CE2 Bientôt
  • CM1 Bientôt
  • CM2 Bientôt

Collège

Lycée

Supérieur

  • BTS Bientôt
  • BUT Bientôt
  • Licence Bientôt
  • Prépas Bientôt

Sur cette page