Bac NSI 2026 Métropole jour 1

Adresse IP : 10101100.00010000.00100000.00001111
Masque     : 11111111.11111111.11110000.00000000

Chaque octet doit garder huit chiffres : 172 = 128 + 32 + 8 + 4 ; 16 = 16 ; 32 = 32 ; 15 = 8 + 4 + 2 + 1. Le masque contient vingt bits à 1 consécutifs, donc le préfixe est /20.

Pour vérifier un octet, additionnez uniquement les poids correspondant aux bits à 1 dans la ligne 128, 64, 32, 16, 8, 4, 2, 1. La séparation par des points facilite cette vérification et évite de perdre les zéros initiaux. Le masque binaire n’est pas une adresse de machine : il indique quels bits de l’adresse sont conservés dans la partie réseau.

Il reste 32 - 20 = 12 bits pour les hôtes. On obtient 2¹² - 2 = 4 094 adresses utilisables, de 172.16.32.1 à 172.16.47.254. 172.16.32.0 désigne le réseau et 172.16.47.255 la diffusion. La passerelle consomme elle-même une de ces 4 094 adresses si l’on compte les autres équipements à installer.

Dans le troisième octet, les quatre bits de poids fort sont fixes : 0010. Ses quatre bits de poids faible vont de 0000 à 1111, ce qui donne les valeurs 32 à 47. Le dernier octet varie de 0 à 255. Le premier hôte est donc obtenu après l’adresse tout à zéro côté machine, et le dernier avant l’adresse tout à un. Cette méthode fonctionne aussi lorsqu’un masque ne s’arrête pas sur une frontière d’octet.

La passerelle configurée 172.16.48.254 appartient au site4, hors du sous-réseau de l’hôte. Remplacer par gateway 172.16.47.254. Une communication locale n’utilise pas la passerelle ; cela explique pourquoi imprimantes et serveurs restent joignables. Le test confirme que l’interface attendue de R2 est accessible.

Par exemple R2 : 192.168.0.9 et R4 : 192.168.0.10, ou l’inverse. Les quatre adresses vont de .8 à .11 ; .8 est le réseau et .11 la diffusion.

R2 → R3 → R4 → R5, coût 3 : trois liens entre routeurs. L’hôte et le routeur Internet apparaissent dans la trace, mais ne font pas partie du trajet demandé de R2 à R5.

Le trajet R2 → R4 → R5 coûte seulement 2 en RIP. Si toutes les liaisons indiquées sont opérationnelles et les tables convergées, la route observée de coût 3 n’est donc pas optimale. Une panne ou mauvaise configuration de R2-R4, une route non annoncée ou une convergence RIP encore inachevée peut l’expliquer. La trace seule ne permet pas d’identifier laquelle.

On souhaite maximiser le débit et minimiser le coût. Avec la formule donnée coût = 10⁸ / débit, augmenter le débit réduit le coût. Il faut exprimer le débit en bits par seconde, pas directement en Mbit/s.

Les coûts sont 10 en Ethernet, 1 en Fast Ethernet et 0,025 pour la fibre (10⁸/(4 × 10⁹)). Du site4, on rejoint R2, puis R2 → R1 → R3 → R4 → R5 → Internet. Le coût inter-routeurs vaut 1 + 0,025 + 0,025 + 0,025 = 1,075. R2-R4-R5 coûterait 10,025 et R2-R1-R4-R5 coûterait 2,025. Les coûts des liaisons site4-R2 et R5-Internet ne sont pas fournis : on ne les invente pas. On applique ici la métrique théorique du sujet, sans arrondi entier propre à certains équipements réels.

Pour établir un échange alors qu’aucun secret préalable n’est indiqué, ils utilisent un mécanisme asymétrique avec authentification des clés : chacun peut publier sa clé publique sans dévoiler sa clé privée. Envoyer une clé symétrique en clair sur le réseau compromis ne la garderait pas secrète. Une fois un secret établi de façon sûre, un chiffrement symétrique convient parfaitement aux données et est employé en pratique. L’asymétrique seul ne suffit pas contre un pirate actif qui substituerait des clés : certificats ou autre vérification fiable de l’identité sont nécessaires. Si Alice et Bob disposaient déjà d’une clé symétrique partagée secrètement, elle pourrait aussi protéger leur conversation.

HTTPS transporte HTTP dans TLS. Il fournit le chiffrement des données en transit, le contrôle de leur intégrité et l’authentification du serveur par un certificat validé. HTTP seul laisse les messages lisibles sur le trajet et ne fournit pas ces garanties. Cela ne protège pas un terminal lui-même compromis et ne signifie pas automatiquement que le serveur ne peut pas lire la conversation : le chiffrement de bout en bout serait une propriété supplémentaire.

Les neuf jetons ont chacun deux états, indépendamment des autres. Le principe multiplicatif donne 2 × 2 × … × 2, avec neuf facteurs, soit 2⁹ = 512 configurations. Ce décompte concerne tous les plateaux, pas uniquement ceux atteignables depuis un plateau donné.

Non. Les configurations successives sont les suivantes :

La configuration finale est 292 ; seuls les trois jetons de la première colonne sont noirs. La victoire serait 111/111/111, soit 511.

On lit les cases ligne par ligne, de gauche à droite et de haut en bas : 001001110. La valeur est 2⁶ + 2³ + 2² + 2¹ = 64 + 8 + 4 + 2 = 78. Le premier jeton correspond à 2⁸ et le dernier à 2⁰.

def representant(bits):
    valeur = 0
    for bit in bits:
        valeur = 2 * valeur + bit
    return valeur

Après chaque itération, valeur représente le préfixe déjà lu. Ajouter un bit à droite double la valeur précédente puis ajoute ce bit. On évite ainsi les erreurs sur les exposants et les conversions implicites de chaîne.

Cette trace sur [1,0,1] montre l’invariant du préfixe. Une liste de zéros garde la valeur 0 ; une liste vide donne également 0 selon ce code, même si un plateau du jeu contient toujours neuf bits. Ajouter le bit à la fin plutôt qu’au début est essentiel pour respecter le poids fort placé à gauche.

def xor_etendu(l_x, l_y):
    resultat = []
    for i in range(len(l_x)):
        resultat.append(xor(l_x[i], l_y[i]))
    return resultat

Les deux listes sont parcourues au même indice. La précondition garantit leurs longueurs égales. Une nouvelle liste est construite : les configurations d’origine ne sont pas modifiées. Pour [1, 1] et [0, 1], on obtient [1, 0].

Le XOR de deux bits est symétrique, mais il faut conserver les positions des cases. Une addition ordinaire ne convient pas : 1+1 vaut2 alors que 1 XOR1 vaut0. On peut tester la réversibilité du résultat : appliquer deux fois xor_etendu avec le même masque doit rendre exactement la liste initiale. Le résultat doit aussi conserver la longueur de l’entrée et ne contenir que0 ou1.

def configurations_suivantes(config):
    config_bin = binaire(config)
    voisins = []
    for coup in coups_possibles:
        masque = coups_possibles[coup]
        suivante = xor_etendu(config_bin, masque)
        voisins.append(representant(suivante))
    return voisins

Un bit de masque à 1 retourne la case ; un bit à 0 la préserve. Les huit coups sont appliqués chacun au même plateau de départ, et non successivement au plateau obtenu précédemment. Pour 67, la diagonale 1 donne 338, conformément au résultat binaire et au dictionnaire du sujet.

La conversion vers neuf bits se fait une seule fois avant la boucle. Chaque masque produit une nouvelle liste, ensuite convertie en entier. Les huit résultats forment les voisins du sommet config dans le graphe. Une erreur fréquente serait de remplacer config_bin par suivante à chaque tour : cela décrirait une suite de huit coups, alors que la question demande huit alternatives de premier coup.

Si le coup de masque m fait passer de x à y, alors y = x ⊕ m. Jouer à nouveau le même coup donne (x ⊕ m) ⊕ m = x : chaque jeton concerné est retourné deux fois. Le coup inverse est donc autorisé et l’arête retour existe.

La matrice comporte 512² = 2¹⁸ entrées. Les listes du dictionnaire contiennent 512 × 8 = 2¹² voisins. En comptant aussi les 512 clés entières, cela fait 2¹² + 2⁹ = 4 608 entiers, contre 262 144 entrées. On ignore ici le surcoût propre aux objets Python, puisque la question demande un nombre d’entiers. Le graphe est peu dense : conserver uniquement les huit voisins par sommet évite les très nombreux zéros de la matrice.

def parcours_profondeur(graphe, configuration, vus):
    vus.append(configuration)
    for s in graphe[configuration]:
        if s not in vus:
            parcours_profondeur(graphe, s, vus)

On marque le sommet avant ses appels récursifs. Tous les appels partagent la même liste vus, ce qui empêche de tourner indéfiniment sur les cycles. Le parcours modifie la liste et n’a pas besoin de renvoyer une valeur.

Par exemple, sur un triangle A-B-C-A, le premier appel marque A ; quand la récursion atteint C et retrouve A parmi ses voisins, le test d’appartenance le bloque. Si le marquage avait lieu après les appels aux voisins, A pourrait être rappelé avant d’être marqué et le cycle ne serait plus arrêté. La liste vus est un objet partagé, ce qui rend visibles les ajouts des appels profonds.

vus = []
parcours_profondeur(graphe, 4, vus)
print(511 not in vus)  # affiche True

Le parcours liste exactement la composante accessible depuis 4. La configuration entièrement noire vaut 2⁹ - 1 = 511. Son absence prouve qu’aucune suite de coups ne mène à la victoire. Tester seulement les huit voisins ne suffirait pas : il faut inclure les suites de plusieurs coups.

Le parcours en largeur explore d’abord les configurations à un coup, puis à deux coups, etc. Chaque arête représente un coup de même coût : la première découverte de 511 fournit donc une distance minimale. On peut mémoriser les prédécesseurs pour reconstruire la suite de coups. Le parcours en profondeur trouve un chemin éventuel, sans garantir qu’il soit le plus court.

C’est la racine de l’arbre : l’unique nœud qui n’a pas de parent.

Non. Dans un arbre binaire, chaque nœud a au plus deux enfants. Ici, le sujet possède quatre arguments directs ; un nombre quelconque d’arguments peut être ajouté. Deux catégories, pour et contre, ne signifient pas deux enfants.

phrase est un paramètre du constructeur ; ce n’est pas un attribut conservé sous ce nom. self désigne l’instance.

assert argument.sorte == ""
self.arguments.append(argument)
argument.sorte = "pour"

On vérifie que l’argument n’appartient pas encore à l’arbre, on l’ajoute à la liste des enfants de l’affirmation courante, puis on enregistre son rôle. Modifier self.sorte serait une erreur : c’est le nouvel argument qui soutient son parent.

def nb_contre(self):
    nombre = 0
    for arg in self.arguments:
        if arg.sorte == "contre":
            nombre += 1
    return nombre

On ne parcourt que les enfants directs. La consigne ne demande pas le nombre de contre-arguments dans tout le sous-arbre ; il ne faut donc pas ajouter d’appel récursif ici.

Une affirmation peut avoir un argument pour qui possède lui-même plusieurs arguments contre. Ceux-ci ne sont pas directement rattachés à l’affirmation de départ et ne doivent pas être comptés dans cette méthode. Ce décompte local est précisément la valeur que mystere comparera ensuite à celles des autres nœuds.

Elle renvoie le plus grand nombre d’arguments contre directs rattachés à une même affirmation dans le sous-arbre de l’affirmation courante, celle-ci comprise. Le maximum commence avec self.nb_contre(), puis est comparé au maximum de chacun des sous-arbres. Ce n’est ni un total de contre-arguments ni une hauteur.

def evaluation(self):
    total = self.nb_likes - self.nb_dislikes
    for arg in self.arguments:
        if arg.sorte == "pour":
            total = total + arg.evaluation()
        else:
            total = total - arg.evaluation()
    return total

Une feuille renvoie simplement likes - dislikes. Pour un nœud interne, chaque soutien ajoute son évaluation et chaque opposition la soustrait. Soustraire une opposition d’évaluation négative augmente le score du parent : un argument contre lui-même fortement contesté peut renforcer l’affirmation. Le else convient car un enfant inséré est pour ou contre, jamais sujet.

Prenons un sujet de score local5, un soutien évalué3 et une opposition évaluée-2. L’évaluation du sujet vaut5+3-(-2)=10. Pour obtenir le3 ou le-2 des enfants, la même méthode évalue d’abord tous leurs descendants. Il s’agit donc d’un calcul ascendant : les feuilles fournissent leur différence likes/dislikes, puis chaque parent combine ces valeurs avec le signe du lien. La récursion se termine car l’arbre possède un nombre fini de niveaux.

Réponses attendues : a, c et d. Le SGBD gère les droits d’accès, la durabilité et la récupération via journaux/sauvegardes, ainsi que les accès concurrents. L’alimentation relève de l’infrastructure et HTTPS du service réseau/web. La durabilité n’est pas une garantie magique contre toute destruction physique : elle suppose les mécanismes de stockage, de sauvegarde et de reprise adaptés.

L’attribut email, à condition que la plateforme impose une adresse renseignée et unique par compte, peut identifier chaque utilisateur. C’est l’alternative usuelle visée. Le schéma seul ne déclare cependant pas cette contrainte : sans elle, son statut de clé candidate n’est pas démontré. Ni le nom ni le prénom ne garantissent l’unicité.

SELECT COUNT(*)
FROM affirmation
WHERE nb_likes >= 50;

WHERE filtre d’abord les affirmations ; COUNT(*) compte ensuite les lignes retenues. L’égalité doit être incluse. Le résultat est un nombre unique, pas une liste de likes.

SELECT a.contenu, a.nb_likes
FROM affirmation AS a
JOIN utilisateur AS u ON a.auteur = u.pseudo
WHERE a.sorte = 'sujet'
  AND u.prenom = 'Pierre'
  AND u.nom = 'Durand';

La jointure associe l’auteur à son compte par la clé, puis les trois conditions doivent être vraies simultanément. On ne suppose pas que le couple nom/prénom identifie une seule personne ; tous les sujets des homonymes correspondants sont retournés.

Pour relire la requête, imaginez les étapes logiques : la jointure produit les couples affirmation/auteur compatibles ; les trois filtres retiennent les sujets écrits par les personnes portant les deux noms demandés ; le SELECT ne conserve que contenu et nb_likes. Cette lecture distingue bien le rôle de chaque clause et permet de détecter un oubli du filtre sorte.

L’intention est d’obtenir le texte d’une affirmation et le texte d’une réponse contre cette affirmation, lorsque cette réponse possède au moins deux fois autant de likes que l’affirmation. Les deux alias distinguent le parent et sa réponse. Le SQL imprimé utilise toutefois deux noms absents du schéma : affirmation_repondue et id_affirmation. Pour l’exécuter avec les tables données, la jointure doit être rep.aff_repondue = aff.id_aff. Sans cette correction, la requête échoue ; ce n’est pas une difficulté de compréhension de votre part.

INSERT INTO reaction
VALUES (108, 'i<3descartes', 'like');

UPDATE affirmation
SET nb_likes = nb_likes + 1
WHERE id_aff = 108;

La première instruction mémorise la réaction dans l’ordre des attributs de la table. La seconde incrémente le compteur existant, sans le remplacer par 1, et ne concerne que l’affirmation 108. On suppose qu’aucune réaction de ce compte sur cette affirmation n’existait déjà, conformément à l’insertion demandée. En application réelle, ces deux opérations seraient regroupées dans une transaction.

Chaque réaction référence utilisateur.pseudo par une clé étrangère. Supprimer d’abord le compte laisserait des références sans ligne cible et violerait l’intégrité référentielle, en l’absence d’une suppression en cascade prévue. Les affirmations doivent de même avoir été anonymisées avant la suppression du compte.

UPDATE affirmation
SET auteur = NULL
WHERE auteur = 'i<3rgpd';

DELETE FROM reaction
WHERE utilisateur = 'i<3rgpd';

DELETE FROM utilisateur
WHERE pseudo = 'i<3rgpd';

Cet ordre préserve les clés étrangères. NULL s’écrit sans guillemets : ce n’est pas une chaîne contenant le mot NULL. Les likes et dislikes restent inchangés, car le sujet le demande explicitement. Les clauses WHERE évitent de toucher les autres utilisateurs.