Numérique et sciences informatiques (spécialité) · TerminaleBac
Mise au point des programmes : quiz 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ébogage) consiste à mettre en évidence un bug et à le reproduire avant de le corriger.2
- Un programme qui ne plante pas n'est pas forcément correct : le bug peut dépendre de la donnée d'entrée.2
- Chaque test vérifie un seul point précis du programme, sous la forme d'une assertion unique.1
- Un programme respectant certaines bonnes pratiques d'écriture est plus facile à mettre au point.2
Avant de commencer
Ce quiz porte sur la mise au point des programmes, un thème du programme de Terminale en numérique et sciences informatiques, rattaché à la gestion des bugs.3 Il te fait travailler quatre idées : ce qu'est la mise au point, comment on met un bug en évidence, comment on écrit un test utile, et ce qui rend un programme facile à corriger.
Tu y trouveras des questions de définition, des mises en situation sur de petits morceaux de code, un calcul simple et un détour historique par le langage BASIC, dont la simplicité a joué sur la façon de mettre au point les programmes.4
Quiz
13 questions · correction immédiate · ton score reste sur ton appareil.
-
La mise au point (ou débogage) passe d'abord par la mise en évidence du bug et sa reproduction.2 Rendre un programme plus rapide est de l'optimisation, une tout autre activité : la tentation vient du fait qu'on « retouche » le code dans les deux cas. Traduire ou commenter le code ne corrige aucun bug.
-
Il faut savoir mettre en évidence le bug et le reproduire.2 Sans cas reproductible, on ne peut pas savoir si une modification a réglé le problème. Modifier au hasard est tentant mais dangereux : on peut masquer le bug ou en créer un nouveau.
-
Faux. Selon la donnée d'entrée, un programme ne plante pas toujours, alors même qu'il contient un bug.2 Un résultat faux sans message d'erreur est même plus difficile à repérer qu'un plantage. L'absence de plantage prouve seulement que les cas essayés n'ont pas déclenché d'erreur visible.
-
La consigne d'Éduscol est de limiter chaque assertion à un seul aspect bien délimité du programme.1 Une assertion qui vérifie tout à la fois est tentante parce qu'elle semble économiser du travail, mais si elle échoue on ne sait pas quelle partie est fautive.
-
Avec
x = 5, la fonction renvoie5 + 2 = 7, pas10. L'assertion échoue et révèle le bug : la fonction ajoute 2 au lieu de multiplier par 2. Attention au piège dex = 2:2 + 2et2 * 2donnent tous les deux 4, ce test-là n'aurait rien détecté. Choisir la valeur testée compte. -
Chaque point précis a sa propre assertion.1 Pour 5 points, on écrit donc 5 assertions. Regrouper plusieurs points dans une seule assertion ferait perdre l'information sur l'origine d'un échec.
-
Selon la donnée d'entrée, le programme ne plante pas toujours.2 Un bug caché peut donc échapper à un test unique. Le programme ne change pas de comportement « tout seul » : à données identiques, il refait la même chose, ce qui est précisément ce qui permet de reproduire un bug.
-
Plus un programme suit de bonnes pratiques d'écriture, moins sa correction demande d'efforts.2 La brièveté seule ne suffit pas : un code court mais obscur reste difficile à corriger. Écrire en un seul bloc empêche de tester chaque morceau séparément, ce qui va à l'encontre de la logique du test ciblé.
-
BASIC date de 1963 : il a été pensé comme une version simplifiée de FORTRAN, à but éducatif, pour les débutants.4
-
Les constructions très limitées de BASIC ont favorisé des programmes mal organisés, donc pénibles à faire évoluer ; une critique publiée par Edsger Dijkstra a ensuite fait reculer son image dans l'enseignement, et Pascal l'a remplacé.4 Le piège de la première réponse est de croire l'inverse : BASIC était justement très simple.
-
Vrai. Les ressources du programme de numérique et sciences informatiques pour la voie générale citent explicitement la mise au point des programmes et la gestion des bugs.3 Ce n'est donc pas un simple conseil de méthode : c'est une notion à maîtriser.
Les questions qu'on se pose
Quelle est la différence entre un programme qui plante et un programme faux ?
Un programme qui plante s'arrête avec un message d'erreur. Un programme faux s'exécute jusqu'au bout mais renvoie un mauvais résultat. Un programme peut aussi planter seulement pour certaines données d'entrée.2 C'est pourquoi on ne se contente pas de vérifier que « ça tourne » : on compare le résultat obtenu à un résultat attendu.
Pourquoi une assertion ne doit-elle vérifier qu'un seul point ?
Parce qu'un test précis localise la panne. Les ressources d'accompagnement recommandent de limiter chaque assertion à un seul point du programme.1 Si une assertion mêle plusieurs vérifications et échoue, tu ne sais pas laquelle est en cause, et tu perds du temps à chercher.
Sources
- Mise au point de programmes, gestion des bugs, Éduscol. Consulté le 7 novembre 2026.
- Gestion des bugs NSI - Ressources d'accompagnement, Éduscol. Consulté le 7 novembre 2026.
- Programmes et ressources en numérique et sciences informatiques, Éduscol. Consulté le 7 novembre 2026.
- 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.