Bac NSI 2025 Asie remplacement jour 1 : corrigé du sujet 25-NSIPE4

Le nom Benard apparaît pour deux personnes distinctes, Elsa et Emma. Une clé primaire doit identifier une ligne sans ambiguïté et ses valeurs doivent être uniques et non nulles. Le nom ne satisfait donc pas l’unicité ; l’identifiant id distingue ici les lignes 4 et 5. Une clé primaire doit respecter cette règle pour toute la base, pas seulement pour un extrait qui semblerait ne contenir aucun doublon.

SELECT nom, prenom FROM joueurs WHERE genre = 2;

Le filtre retient le code 2, puis la projection conserve uniquement les deux colonnes demandées. Sur l’extrait, les résultats sont Panais Lise, Benard Elsa et Benard Emma. Sans ORDER BY, SQL ne garantit pas l’ordre de ces lignes ; il n’est pas demandé ici.

INSERT INTO joueurs (id, nom, prenom, genre) VALUES (6, 'Gervais', 'Nathan', 1);

L’identifiant 6 n’apparaît pas dans l’extrait. Les noms de colonnes rendent explicite l’ordre des valeurs, en particulier nom avant prénom. Comme le tableau est présenté comme un extrait, il faudrait vérifier dans la base complète que 6 est réellement libre ; le choix est cohérent avec les données visibles.

UPDATE competitions SET nom = 'Open de Tours' WHERE id = 3;

Le WHERE cible la clé primaire de la seule ligne erronée. Sans cette clause, toutes les éditions seraient renommées. L’identifiant est préférable au libellé fautif pour désigner précisément la ligne.

SELECT nom, annee FROM competitions ORDER BY annee ASC;

ASC demande l’ordre croissant et pourrait être omis, car c’est le sens par défaut. Les éditions de 2023 peuvent apparaître dans n’importe quel ordre relatif. Un second critère de tri serait possible, mais n’est pas requis. On ne supprime pas les éditions ayant le même nom : leurs années les distinguent.

SELECT joueurs.nom, joueurs.prenom
FROM joueurs JOIN participe ON joueurs.id = participe.id_joueur
WHERE participe.nb_gagnant > participe.nb_fautes;

La jointure relie chaque ligne de statistiques à son joueur grâce à id_joueur. Le test compare deux colonnes de cette même participation. On n’utilise pas DISTINCT, car l’énoncé souhaite conserver les répétitions liées à plusieurs performances. Sur l’extrait : Enzo Durand, Lise Panais, Elsa Benard et Emma Benard remplissent chacun le critère une fois. Le nombre d’aces n’intervient pas dans cette condition.

SELECT joueurs.nom, joueurs.prenom, competitions.nom
FROM joueurs
JOIN participe ON joueurs.id = participe.id_joueur
JOIN competitions ON competitions.id = participe.id_compet
WHERE joueurs.genre = 2 AND competitions.annee = 2023;

Les trois tables sont nécessaires : le genre et l’identité proviennent de joueurs, l’année et le tournoi de competitions, et le lien de participe. Deux filtres sont combinés par AND. Lise apparaît pour Blois et Nantes ; Elsa et Emma apparaissent pour Nantes. Préfixer les colonnes nom évite une ambiguïté entre le nom de famille et le nom du tournoi.

La participation (id_joueur=5, id_compet=4) référence encore Emma. Il faut traiter cette ligne dépendante avant de supprimer la ligne parent, sinon une contrainte de clé étrangère peut refuser l’opération. Pour une suppression complète de ses participations :

DELETE FROM participe WHERE id_joueur = 5;
DELETE FROM joueurs WHERE id = 5;

Une politique de suppression en cascade pourrait automatiser ce traitement si elle était déclarée, mais le sujet ne l’indique pas. Dans une application qui conserve l’historique sportif, on préférerait souvent marquer une personne comme inactive ; ce serait un autre choix de modèle.

L’intention est de créer d’abord la joueuse et le tournoi, puis leur participation. Mais l’extrait contient déjà la compétition d’id 5, Open de Nantes 2021. Les contraintes données sont incompatibles avec une simple insertion utilisant à nouveau 5 : elle violerait l’unicité de la clé primaire. Il faut signaler cette incohérence, sans écraser l’édition existante.

Si l’identifiant de compétition 5 était libre comme la question semble le supposer, les requêtes attendues seraient :

INSERT INTO joueurs (id,nom,prenom,genre) VALUES (7,'Turion','Agathe',2);
INSERT INTO competitions (id,nom,annee) VALUES (5,'Tournoi de Blois',2024);
INSERT INTO participe (id_joueur,id_compet,nb_fautes,nb_gagnant,aces) VALUES (7,5,14,15,2);

Avec la base réellement reproduite, une correction cohérente consiste à réserver un identifiant de compétition libre, par exemple 7, et à utiliser ce même identifiant dans participe. Les espaces d’identifiants de joueurs et competitions sont indépendants : chacun peut utiliser 7.

INSERT INTO joueurs (id,nom,prenom,genre) VALUES (7,'Turion','Agathe',2);
INSERT INTO competitions (id,nom,annee) VALUES (7,'Tournoi de Blois',2024);
INSERT INTO participe (id_joueur,id_compet,nb_fautes,nb_gagnant,aces) VALUES (7,7,14,15,2);

Ces deux variantes sont alternatives ; ne pas exécuter les deux séries. Dans une vraie base, les trois insertions forment une transaction afin de ne pas laisser une opération partiellement réalisée.

L’adresse 137.254.128.200 est déjà attribuée. Les 207 machines sont placées depuis les premières adresses utilisables ; 200 appartient à cette plage, contrairement à 210. La réservation éventuelle d’une adresse pour le routeur ne change pas la distinction entre ces deux propositions.

Non. Un /24 laisse 8 bits d’hôte, soit 256 adresses. En excluant l’adresse réseau et l’adresse de diffusion, on obtient 254 adresses d’hôtes, dont une pour le routeur. Les 207 machines occupent déjà la grande majorité de la capacité ; 207 + 132 = 339 dépasse même les 254 adresses utilisables. Le nombre exact d’adresses restantes dépend du comptage du routeur dans les 207, mais cette ambiguïté ne change pas l’impossibilité.

Le chemin imposé par les tables est R1 → R3 → R6 → R7. Navigation est reliée à R1 et Commerces à R7. À chaque étape, on lit la ligne de destination R7 dans la colonne du routeur courant : R1 conseille R3, R3 conseille R6, R6 conseille R7. Il faut suivre les tables données, même si un autre chemin est visible sur le graphe.

Le message part de R7 vers R4 pour atteindre R1. Mais R4 envoie vers R6 et R6 renvoie vers R4 : R7 → R4 → R6 → R4 → R6…. Il existe une boucle de routage et le message ne rejoint pas R1. Les liaisons physiques existent ; le défaut vient de l’incohérence des tables. Dans un réseau IP réel, une durée de vie peut limiter la circulation, mais elle ne répare pas les routes.

g = {
    'R1': ['R2', 'R3'],
    'R2': ['R1', 'R3', 'R5'],
    'R3': ['R1', 'R2'],
    'R5': ['R2']
}

Le triangle R1-R2-R3 est complété par la liaison R2-R5. Le graphe est non orienté : chaque liaison apparaît dans les listes des deux extrémités. L’ordre des voisins peut varier sans changer le graphe.

Une fonction récursive s’appelle elle-même sur un problème lié, généralement plus petit. Un cas de base fournit une réponse sans nouvel appel, et les appels doivent progresser vers ce cas pour terminer. Dans un parcours de graphe, l’ensemble des sommets encore admissibles peut diminuer ; sans contrôle des sommets déjà visités, un cycle pourrait provoquer des appels indéfinis.

def plus_court_chemin(graphe, r_depart, r_arrivee):
    chemins = liste_chemins(graphe, r_depart, r_arrivee)
    if not chemins:
        return None
    meilleur = chemins[0]
    for chemin in chemins[1:]:
        if len(chemin) < len(meilleur):
            meilleur = chemin
    return meilleur

Une liste de k routeurs décrit k−1 liaisons : minimiser sa longueur revient donc à minimiser le nombre de sauts. On initialise le meilleur avec un chemin réel puis on le remplace uniquement lorsqu’une liste plus courte apparaît. La garde sur la liste vide donne None lorsqu’aucun trajet n’existe. En cas d’égalité, la première solution est conservée.

Cette méthode suppose que liste_chemins fournit des chemins sans répétition inutile. Son principal défaut reste le nombre potentiellement très grand de chemins à construire ; la recherche du minimum ne compense pas ce coût.

def plus_court_chemin_largeur(graphe, r_depart, r_arrivee):
    if r_depart == r_arrivee:
        return [r_depart]
    dict_chemins = {r_depart: [r_depart]}
    L = [r_depart]
    sommets_marques = [r_depart]
    for r in L:
        for s_r in graphe[r]:
            if s_r not in sommets_marques:
                sommets_marques.append(s_r)
                dict_chemins[s_r] = dict_chemins[r] + [s_r]
                if s_r == r_arrivee:
                    return dict_chemins[s_r]
                L.append(s_r)
    return None

Les deux compléments demandés sont s_r dans append et dict_chemins[s_r] dans le return. La version ci-dessus ajoute les cas départ=arrivée et arrivée inaccessible. La liste L est étendue en fin de parcours et visitée dans son ordre : les sommets à une distance donnée sont traités avant ceux de distance supérieure. Le premier chemin atteignant l’arrivée est donc minimal en nombre de sauts.

Le voisin est marqué dès sa découverte, avant son ajout à la liste. Cela empêche que plusieurs routes le mettent plusieurs fois en attente. Le chemin du voisin reprend celui du sommet courant et ajoute seulement ce voisin ; il faut créer une nouvelle liste, et non modifier tous les chemins qui pourraient partager le même objet.

def table_routage(graphe, routeur):
    table = {}
    for destination in graphe:
        if destination != routeur:
            chemin = plus_court_chemin_largeur(graphe, routeur, destination)
            if chemin is not None:
                table[destination] = chemin[1]
    return table

Le chemin commence par le routeur source : la passerelle est donc son deuxième élément, d’indice 1. On omet l’entrée vers soi, qui n’a pas de prochain routeur ; on omet aussi les destinations inaccessibles. La garde destination!=routeur évite un accès à chemin[1] pour une liste d’un seul sommet. Dans ce réseau connecté, toutes les autres destinations sont accessibles.

Il faut convertir les mégabits en bits avant la division. Un débit plus grand donne un coût plus faible : OSPF additionne ensuite les coûts des liaisons et minimise ce total. La fibre ne vaut pas zéro, même si elle est la plus rapide.

Un chemin minimal est R1 → R3 → R2 → R5 → R6 → R4 → R7, de coût 2+2+10+2+2+2=20. Il comporte plus de sauts qu’un chemin direct par R3-R4, mais évite les liaisons Ethernet de coût 100. Le détour par R3 pour joindre R2 coûte 4 au lieu de 10 ; le détour par R4 pour joindre R7 depuis R6 coûte 4 au lieu de 10.

Il faut comparer des sommes de coûts, pas compter les routeurs ni choisir avidement une liaison rapide sans considérer la suite. Le calcul de plus court chemin sur tous les sommets confirme ici ce trajet.

Vers R4, le chemin R2-R5-R6-R4 coûte 10+2+2=14 ; vers R7, on le prolonge par R4-R7 et obtient 16. Ces deux destinations ont donc la même passerelle R5. Le coût 0 vers soi est une convention d’explication ; aucune passerelle n’est requise sur cette ligne. Une table stocke le prochain saut, pas la totalité du chemin.

[31, 45, 108, 127, 421]

Après 31 et 45, les valeurs 41,28 et 37 sont inférieures au dernier conservé 45.108 puis 127 sont acceptés.2 et 124 sont alors inférieurs à 127, donc rejetés.421 termine la liste. La comparaison porte toujours sur le dernier conservé, même si plusieurs valeurs intermédiaires ont été éliminées.

Un tri réordonne les éléments en conservant leurs occurrences : sa sortie est une permutation de l’entrée. Ici, des valeurs sont supprimées. L’entrée [2,3,1,8] contient 1, mais la sortie ne le contient plus. La liste obtenue est croissante au sens large, mais cela ne suffit pas à en faire le résultat d’un tri.

Ce test donne par hasard le résultat attendu. Pourtant le programme compare 9 à 2 et 12 à 6, c’est-à-dire aux éléments précédents de l’entrée, même s’ils ont été rejetés. Ce succès local ne valide donc pas sa logique générale.

Une liste vide ne possède aucun indice 0. L’erreur se produit dès l’initialisation, avant la boucle. Une garde au début de la fonction respecte le cas vide annoncé :

if not serie:
    return []

La garde doit précéder l’accès à serie[0]. Elle ne répare que ce défaut d’accès ; le problème de comparaison de la question 6 reste présent. L’entrée n’est pas modifiée, conformément au contrat de la partieA.

Un test examine une entrée particulière et peut révéler un contre-exemple. Un ensemble fini de tests ne couvre généralement pas toutes les entrées possibles, leurs tailles ou leurs combinaisons. Un programme peut donc réussir ces tests et échouer ailleurs, comme celui d’Edgar. Une preuve s’appuie sur les propriétés du programme pour couvrir une classe entière d’entrées ; tests et raisonnement sont complémentaires.

Le sujet illustre cette idée par une citation de Dijkstra sur le rôle des tests : ils sont efficaces pour montrer la présence d’erreurs, mais ne suffisent pas en général à démontrer leur absence. Un domaine fini entièrement testé constitue un cas particulier, pas la situation générale évoquée.

Le 3 est accepté parce qu’il est supérieur à 2, pourtant 2 a été éliminé : il fallait comparer 3 au dernier conservé 8. De même,5 est accepté à tort en étant comparé à 3. Le bon critère utilise la dernière case de la liste résultat.

def tri_dictatorial(serie):
    if not serie:
        return []
    serie_triee = [serie[0]]
    for valeur in serie[1:]:
        if valeur >= serie_triee[-1]:
            serie_triee.append(valeur)
    return serie_triee

Après chaque étape, la sortie contient exactement les éléments déjà lus que la règle autorise, dans leur ordre initial. Ajouter une valeur seulement si elle est au moins égale à la dernière préserve la croissance. La garde traite le vide, et le parcours lit l’entrée sans la modifier. Les égalités sont conservées : [2,2,1,3] devient [2,2,3].

m8 = Maillon(8, None)
m0 = Maillon(0, m8)
m1 = Maillon(1, m0)
ma_liste = Liste(m1)

Construire depuis la fin permet de disposer de chaque successeur au moment de créer le maillon précédent. L’attribut tete référence m1 ; il ne contient pas directement l’entier 1. Chaque suivant contient une référence à un autre Maillon ou la valeur None.

Chaque accès à suivant traverse une liaison. Il faut distinguer le maillon, sa valeur et l’absence de maillon. Les expressions de cette question se lisent avant la modification de la question 9.

ma_liste.tete.suivant = ma_liste.tete.suivant.suivant

La flèche issue de m1 pointe maintenant vers m8. L’objet m0 existe toujours si une variable le référence, et son propre suivant reste m8 ; il n’est simplement plus dans la chaîne accessible depuis tete. Aucun déplacement de données n’est nécessaire.

def tri_dictatorial_chaine(chaine):
    maillon = chaine.tete
    if maillon is None:
        return
    while maillon.suivant is not None:
        if maillon.valeur <= maillon.suivant.valeur:
            maillon = maillon.suivant
        else:
            maillon.suivant = maillon.suivant.suivant

Si le prochain maillon est admissible, il devient le dernier conservé et on avance. Sinon, on le contourne en reliant le maillon courant au successeur du prochain ; on reste sur le même dernier conservé pour examiner le nouveau voisin. Avancer après une suppression ferait sauter une comparaison, notamment avec plusieurs petites valeurs consécutives.

La garde ajoutée traite une chaîne vide, absente du squelette fourni mais autorisée par le principe général. Chaque tour avance ou supprime un maillon, donc réduit le travail restant sur une chaîne finie. La liste est modifiée en place et la fonction renvoie implicitement None.

Une pile suit LIFO : le dernier élément empilé est le premier dépilé. L’ajout et le retrait se font au sommet. On ne retire pas directement un élément au milieu de la pile. Ici, l’ordre de la série à traiter est donc l’ordre dans lequel les éléments sont dépilés.

si p n'est pas vide :
    créer une pile intermédiaire p2 vide
    dépiler p dans dernier_conservé, puis empiler cette valeur dans p2
    tant que p n'est pas vide :
        dépiler p dans candidat
        si candidat >= dernier_conservé :
            affecter candidat à dernier_conservé et l'empiler dans p2
    tant que p2 n'est pas vide :
        dépiler p2 et empiler la valeur dans p

Le premier dépilement initialise toujours un élément conservé. La première boucle filtre les suivants dans l’ordre de lecture. La seconde boucle est placée après la première, et non dedans : elle restitue la pile initiale une fois tout le filtrage terminé. Le passage par p 2 inverse l’ordre, puis le retour vers p l’inverse une seconde fois. La pile finale se dépile donc dans l’ordre croissant des valeurs retenues.

def tri_dictatorial_pile(p):
    if not p.est_vide():
        p2 = Pile()
        dernier_conserve = p.depiler()
        p2.empiler(dernier_conserve)
        while not p.est_vide():
            candidat = p.depiler()
            if candidat >= dernier_conserve:
                dernier_conserve = candidat
                p2.empiler(candidat)
        while not p2.est_vide():
            p.empiler(p2.depiler())

On utilise seulement l’interface annoncée de Pile. Aucun accès à une liste interne supposée n’est nécessaire. La garde empêche de dépiler une pile vide. Le candidat est retiré de p dans tous les cas ; il n’est ajouté à p 2 que s’il satisfait le critère. Après restitution, les éléments rejetés ont disparu, et les conservés ont retrouvé leur ordre de lecture.

Par exemple, si p se dépile initialement en 2,3,1,8, p 2 se dépile après filtrage en 8,3,2. Le transfert final donne une pile p se dépilant en 2,3,8. L’expression « triée » doit être accompagnée de cette convention de lecture, car un dessin de pile peut être lu dans l’autre sens.