Corrigé bac NSI 2026 Métropole jour 1 — Exercice 3 : Plateforme de débats : arbre des arguments en POO et base de données SQL

Partie A : structure arborescente des arguments

1. Le point de départ du débat est la racine de l'arbre : l'unique nœud sans parent, dont tous les autres nœuds descendent. Sur la figure 1, c'est le parallélogramme « La Science est une activité humaine objective. » ; les arguments sans réponse (par exemple « Les géants pétroliers… ») en sont les feuilles.

2. Un arbre binaire est un arbre dont chaque nœud possède au plus deux enfants (un sous-arbre gauche et un sous-arbre droit). Ce n'est pas le cas d'un arbre de débat : une affirmation peut recevoir autant d'arguments qu'on veut. Sur la figure 1, la racine a quatre enfants (deux arguments pour et deux arguments contre) et l'affirmation « La recherche financée par des organismes commerciaux peut tordre les faits. » en a trois. Un arbre de débat est donc un arbre général (dit « quelconque »), et non un arbre binaire. Dans la classe Affirmation, cela se traduit par l'attribut arguments, une liste d'enfants de longueur quelconque, là où un arbre binaire aurait deux attributs gauche et droit.

3. Les attributs sont ceux créés dans le constructeur __init__ :

4. La documentation impose de vérifier que l'argument n'a encore jamais été utilisé : avant tout ajout, son attribut sorte vaut la chaîne vide (ligne 8 du constructeur). On l'ajoute ensuite à la liste des arguments de self, puis on le marque comme argument pour :

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

Testé : après s.soutenir(a), a figure dans s.arguments et a.sorte vaut "pour" ; un second s.soutenir(a) lève une AssertionError, conformément à la précondition.

Ce que le correcteur attend : c'est self.arguments qui reçoit l'argument (et non argument.arguments), et c'est argument.sorte qui change (pas self.sorte, qui reste ce qu'il était).

5. On parcourt les arguments directement rattachés (la liste arguments, sans descendre plus bas dans l'arbre) et l'on compte ceux dont la sorte est "contre" :

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

Sur l'arbre de la figure 1 (reconstruit et exécuté) : la racine renvoie 2, « La Science se base sur les faits… » renvoie 1, et une feuille renvoie 0.

6. La méthode mystere renvoie le plus grand nombre d'arguments contre directement rattachés à une même affirmation, parmi l'affirmation self et toutes celles de son sous-arbre (ses arguments, les arguments de ses arguments, etc.) : c'est le « maximum de contre-attaques directes » subies par une affirmation du débat.

En effet, m part de self.nb_contre(), puis, pour chaque argument, l'appel récursif arg.mystere() fournit le maximum sur le sous-arbre de cet argument, et m ne conserve que le plus grand de tous ces candidats. La récursion s'arrête d'elle-même sur les feuilles, dont la boucle ne fait aucun tour. Sur la figure 1, mystere appelée sur la racine renvoie 2 (la racine subit deux arguments contre, aucune autre affirmation n'en subit plus d'un).

7. L'évaluation vaut (likes $-$ dislikes) de l'affirmation, plus l'évaluation de chaque argument pour, moins l'évaluation de chaque argument contre ; c'est une définition récursive, l'appel arg.evaluation() descendant dans le sous-arbre :

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

Le else est légitime car un argument rattaché ne peut être que "pour" ou "contre" ; on peut aussi remplacer else: par if arg.sorte == "contre":. Les autres lignes proposées sont à écarter : def evaluation(): n'a pas le paramètre self ; nb_likes + nb_dislikes et le produit ne suivent pas la formule ; arguments_pour et arguments_contre ne sont pas des attributs de la classe ; if arg.sorte == "sujet" ne peut jamais être vrai pour un argument ; total = arg.evaluation() écraserait le total au lieu de l'accumuler ; et return 1 + total ajouterait 1 à chaque nœud.

Vérification par exécution sur l'extrait de table de la partie B, qui décrit un petit arbre (0 est le sujet, 1 et 2 ses arguments pour, 3 et 4 ses arguments contre, 7 un argument contre de 1) : $\mathtt{evaluation}(7)=15-16=-1$ ; $\mathtt{evaluation}(1)=(20-20)-(-1)=1$ ; $\mathtt{evaluation}(2)=30$ ; $\mathtt{evaluation}(3)=1$ ; $\mathtt{evaluation}(4)=12$ ; d'où $\mathtt{evaluation}(0)=(42-17)+1+30-1-12=43>0$ : le pour l'emporte.

Partie B : base de données des utilisateurs et de leurs contributions

8. Les rôles d'un SGBD sont a), c) et d).

• a) Oui : le SGBD gère les droits d'accès (qui peut lire, modifier, supprimer quelles tables) et authentifie les utilisateurs de la base.
• b) Non : l'alimentation électrique relève de l'infrastructure matérielle (onduleurs, salle serveurs), pas d'un logiciel.
• c) Oui : la persistance est le cœur du SGBD ; il écrit les données sur disque et garantit, grâce à ses journaux et ses transactions, qu'une panne en cours d'opération ne laisse pas la base dans un état incohérent.
• d) Oui : le SGBD gère les accès concurrents de plusieurs utilisateurs (ou programmes) sans corrompre les données.
• e) Non : HTTPS est un protocole de la couche application du web, assuré par le serveur web ; le SGBD n'y intervient pas.

9. L'attribut email aurait aussi pu servir de clé primaire : une adresse électronique est propre à une personne, deux comptes ne peuvent pas partager la même, et elle est nécessairement renseignée à l'inscription ; elle identifie donc chaque n-uplet de façon unique et sans valeur NULL, ce qu'exige une clé primaire. Ni nom ni prenom ne conviennent : plusieurs utilisateurs peuvent s'appeler Pierre Durand.

10. On compte les lignes de affirmation dont le nombre de likes est au moins 50 :

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

Sur l'extrait donné, le résultat serait 0 (le maximum est 42) ; vérifiée sur une base d'essai, la requête renvoie bien le nombre de lignes à nb_likes $\ge 50$.

11. Le nom et le prénom sont dans utilisateur, le contenu et les likes dans affirmation : il faut une jointure sur la clé étrangère auteur, qui référence pseudo, puis filtrer les sujets et l'identité de l'auteur :

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

Ce que le correcteur attend : la condition sorte = 'sujet' (on veut les sujets, pas tous les messages de Pierre Durand), la jointure (le nom n'est pas dans affirmation) et les deux conditions liées par AND.

12. La table affirmation est jointe avec elle-même : aff désigne une affirmation et rep une réponse qui lui est rattachée (sa clé étrangère « affirmation répondue » vaut l'identifiant de aff). Les conditions gardent les réponses de sorte 'contre' dont le nombre de likes est au moins le double de celui de l'affirmation attaquée. La requête renvoie donc, pour chaque argument contre au moins deux fois plus liké que l'affirmation qu'il attaque, le contenu de cette affirmation et le contenu de l'argument contre : elle repère les contre-arguments nettement plus populaires que ce qu'ils contredisent.

Remarque : la requête imprimée nomme les attributs affirmation_repondue et id_affirmation, alors que le schéma de la figure 2 les appelle aff_repondue et id_aff ; avec les noms du schéma, la jointure s'écrit ON rep.aff_repondue = aff.id_aff. Sur l'extrait de table, aucune ligne ne ressort : l'argument 7 (15 likes) attaque l'affirmation 1 (20 likes), et 3 et 4 (13 et 18 likes) attaquent 0 (42 likes) ; aucun n'atteint le double.

13. On ajoute une réaction (les valeurs dans l'ordre des attributs de la table : aff_reagie, utilisateur, sorte) puis on incrémente le compteur de likes de l'affirmation 108 :

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

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

Testé sur une base d'essai : la ligne (108, 'i<3descartes', 'like') apparaît dans reaction et nb_likes de l'affirmation 108 passe de 60 à 61.

Ce que le correcteur attend : nb_likes = nb_likes + 1 (on ne connaît pas la valeur actuelle, on ne peut pas écrire un nombre), et la clause WHERE sur id_aff, sans laquelle toutes les affirmations gagneraient un like.

14. Dans la table reaction, l'attribut utilisateur est une clé étrangère qui référence utilisateur.pseudo. La contrainte d'intégrité référentielle impose que toute valeur d'une clé étrangère corresponde à une clé primaire existante. Si l'on supprimait d'abord l'utilisateur, ses réactions référenceraient un pseudo qui n'existe plus : le SGBD refuse cette suppression (erreur de contrainte de clé étrangère, ce que nous avons observé sur une base d'essai). Il faut donc d'abord faire disparaître toutes les références au pseudo (les réactions, et l'attribut auteur des affirmations, mis à NULL), puis seulement supprimer l'utilisateur.

15. Les trois requêtes, dans l'ordre de la procédure :

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

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

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

La première anonymise les affirmations sans les supprimer (leurs nb_likes et nb_dislikes sont intacts) ; la deuxième supprime les réactions sans toucher aux compteurs des affirmations, comme demandé ; la troisième supprime enfin le compte, ce que le SGBD accepte maintenant que plus rien ne le référence. Exécutées dans cet ordre sur une base d'essai, elles laissent les affirmations de 'i<3rgpd' avec un auteur NULL et leurs compteurs inchangés, et suppriment l'utilisateur.