Numérique et sciences informatiques (spécialité) · TerminaleBac
Modularité et API : quiz de Terminale NSI
Publié le 7 novembre 2026 · Mis à jour le 7 novembre 2026 · Signaler une erreur
L'essentiel
- Découper un programme en modules permet de travailler sur des parties séparées et bien délimitées.
- L'API d'un module, c'est ce qu'il offre à l'extérieur : des fonctions ou méthodes dont on connaît le nom, les paramètres et le rôle.
- Celui qui utilise un module s'appuie sur la spécification, jamais sur le code interne, qui peut changer sans casser les programmes appelants.
Avant de commencer
Ce quiz porte sur la modularité et sur la notion d'API au programme de la spécialité NSI en Terminale. Quand un projet devient gros, il faut séparer proprement ses différentes parties 3. Tu connais déjà cette démarche depuis la classe de Première ; en Terminale, on l'explicite plus en profondeur, car c'est une méthode essentielle de programmation 2.
Les questions te demandent de raisonner sur des situations concrètes : lire un petit morceau de code Python, décider ce qui relève de l'interface ou de l'implémentation, repérer qui est responsable d'une erreur. Prends le temps de lire chaque énoncé en entier avant de répondre.
Les repères à garder en tête
Quiz
12 questions · correction immédiate · ton score reste sur ton appareil.
-
Le découpage sert à séparer proprement les parties du projet 3 : on peut alors les écrire, les vérifier et les corriger l'une après l'autre. Croire que le découpage accélère l'exécution est tentant mais faux : l'objectif est l'organisation du travail, pas la vitesse. Quant aux spécifications, elles deviennent au contraire plus utiles, puisque les modules communiquent par elles.
-
L'API décrit ce qu'on peut demander au module et ce qu'on obtient en retour. Elle n'a pas pour but de montrer comment le travail est fait, ce qui élimine la deuxième réponse. Modifier les variables internes est même précisément ce que l'API cherche à éviter, car cela lierait ton programme à des détails fragiles.
-
C'est faux. La spécification (nom, paramètres, résultat, conditions d'emploi) suffit. Penser qu'il faut lire le code est une erreur courante : cela reviendrait à perdre tout l'intérêt de la modularité, puisque chaque utilisateur devrait comprendre tout le module avant de s'en servir.
-
L'interface est restée identique : les appelants n'ont donc aucune raison d'être modifiés. C'est le bénéfice principal de la séparation entre interface et implémentation. Les autres réponses supposent à tort que l'algorithme interne est visible des appelants.
-
La fonction multiplie ses deux paramètres : . Si tu as trouvé 10, tu as additionné au lieu de multiplier ; 20 ou 48 viennent d'une confusion avec le périmètre ou avec un facteur 2 inventé. Le programme appelant ne voit que le résultat renvoyé, jamais le contenu de
outils.py. -
Une docstring, des noms parlants et la mention des conditions d'emploi (par exemple « liste non vide ») forment une bonne spécification. Faire modifier les variables internes par l'utilisateur est une mauvaise idée : cela expose un détail d'implémentation, et le moindre changement interne casserait les programmes appelants.
-
En important tous les noms d'un coup, on peut sans le savoir remplacer une fonction ou une variable qui portait le même nom. Avec
import geometrie, chaque appel s'écritgeometrie.aire(...), ce qui évite ce mélange. Les autres réponses décrivent des effets que cette instruction n'a pas. -
C'est vrai : c'est une convention de nommage qui signale « ne pas utiliser depuis l'extérieur ». Python ne l'interdit pas techniquement, ce qui explique l'hésitation : c'est un engagement de bonne conduite entre programmeurs. L'utilisateur sérieux s'en tient aux fonctions sans tiret bas.
-
Un module isolé se vérifie avec des appels simples dont on connaît le résultat attendu, ce qui aide à situer l'origine d'un défaut. Cela ne garantit pas l'absence d'erreur : un test ne prouve que ce qu'il vérifie. Et sans spécification, on ne saurait même pas quoi tester.
-
Seul le code qui dépend du détail interne
_contenuest fragile, puisque ce détail a été remplacé. Les programmes qui passent parempileretdepilerrespectent l'API et restent valides. Dire qu'aucun programme n'est touché ignore que certains ont contourné l'interface. -
La spécification est un contrat : l'appelant s'engage à fournir une liste non vide, le module s'engage à renvoyer la moyenne. L'appel
moyenne([])rompt ce contrat. On pourrait penser que l'auteur doit tout prévoir, mais une condition documentée sert justement à répartir les responsabilités. -
Chaque module expose 2 fonctions, donc . Répondre 12 revient à compter aussi les fonctions internes, alors que l'API ne contient que ce qui est destiné aux utilisateurs du module. Répondre 2 oublie de multiplier par le nombre de modules.
Les questions qu'on se pose
Quelle différence y a-t-il entre un module et une API ?
Le module est le fichier ou l'ensemble de code qui regroupe des éléments liés. L'API est la partie de ce module offerte à l'extérieur, avec sa spécification. Un module peut contenir beaucoup de fonctions internes qui ne font pas partie de son API.
Comment réussir les questions de code sur la modularité ?
Pose-toi deux questions : qu'est-ce qui est promis par l'API, et qu'est-ce qui n'est qu'un détail interne ? Une réponse correcte s'appuie sur la spécification, jamais sur la manière dont le code est écrit à l'intérieur du module.
Sources
- Modularité et API — Spécialité NSI Terminale 2024-2025, Lycée La Martinière Diderot (ac-lyon.fr). Consulté le 7 novembre 2026.
- Introduction à la Modularité et API — NSI Terminale 2024-2025, Lycée La Martinière Diderot (ac-lyon.fr). Consulté le 7 novembre 2026.
- Modularité en programmation — NSI Terminale 2026-2027, Lycée La Martinière Diderot (ac-lyon.fr). 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.