Données structurées

a) Les descripteurs sont les titres des colonnes : Nom, Prénom, Classe, Option.

b) Chaque ligne sous l'en-tête décrit un élève : il y a 4 objets. Chaque objet a une valeur par descripteur, donc la table contient 4 × 4 = 16 valeurs.

c) On se place sur la ligne de Hugo Nguyen et dans la colonne Option : la valeur est « Aucune ». Même « aucune option » est une valeur : la case n'est pas vide.

d) « Classe » est le titre d'une colonne, commun à tous les élèves : c'est un descripteur. « Latin » est le contenu d'une case (descripteur Option, pour Inès Martin ou Lucas Petit) : c'est une valeur. « Diallo » est la valeur du descripteur Nom pour la troisième élève : c'est aussi une valeur.

a) Les valeurs sont séparées par un point-virgule. La colonne population_millions contient des nombres décimaux écrits avec une virgule (10,6) : avec « , » comme séparateur, « 10,6 » serait coupé en deux champs « 10 » et « 6 », et chaque ligne aurait un champ de trop.

b) La première ligne est l'en-tête : elle ne décrit aucun pays, elle donne les noms des descripteurs, dans l'ordre des colonnes.

c) L'en-tête contient 4 noms : 4 descripteurs (pays, capitale, population_millions, continent). Les trois lignes suivantes décrivent chacune un pays : 3 objets.

d) On respecte l'ordre de l'en-tête et le séparateur :

Japon;Tokyo;124,5;Asie

La ligne compte bien 4 champs, comme l'en-tête.

a) Ces informations ne sont pas l'image elle-même : elles décrivent le fichier (nom, taille, dimensions) et les conditions de la prise de vue (date, appareil, lieu). Ce sont des données sur une donnée, donc des métadonnées (ici au format EXIF).

b) Nombre de pixels : 4 032 × 3 024 = 12 192 768 pixels. Comme 1 mégapixel = 1 000 000 de pixels, la photo compte environ 12,2 mégapixels.

c) Les coordonnées GPS situent la prise de vue à un endroit précis (ici à Marseille, près du Vieux-Port), et la date indique que le photographe s'y trouvait le 14 juillet 2025 vers 22 h 47. On peut donc savoir où et quand il était, et même, si la photo est prise chez lui, où il habite.

d) Première solution : désactiver la localisation dans l'application appareil photo, pour que les coordonnées ne soient plus enregistrées. Seconde solution : supprimer les métadonnées avant l'envoi (option de partage « sans position », ou outil qui efface les données EXIF). Beaucoup de réseaux sociaux les retirent aussi, mais on ne doit pas compter dessus.

a) Chaque descripteur de l'en-tête devient une clé, associée à la valeur de la ligne A12 :

{"id": "A12", "espece": "girafe", "poids_kg": 830, "soigneur": "Nadia"}

b) Une collection d'objets s'écrit comme une liste, entre crochets, les objets étant séparés par une virgule :

[{"id": "A12", "espece": "girafe", "poids_kg": 830, "soigneur": "Nadia"}, {"id": "B07", "espece": "zèbre", "poids_kg": 312, "soigneur": "Karim"}]

c) Le poids est un nombre : on l'écrit sans guillemets pour pouvoir calculer avec. L'identifiant A12 contient des lettres : c'est un texte (chaîne de caractères), qui doit être entre guillemets doubles. Même un identifiant uniquement formé de chiffres resterait un texte, car on ne fait pas de calcul dessus.

d) Erreur de syntaxe : la valeur lion est un texte écrit sans guillemets ; un programme ne sait pas la lire et refuse tout le fichier. Il faut écrire "lion". Maladresse : "190" est valide, mais c'est un texte et non un nombre ; un programme qui additionne ou compare les poids le traiterait mal. Il faut écrire 190 sans guillemets, comme pour les autres animaux.

a) Il y a 24 relevés par jour, donc en un an : 24 × 365 = 8 760 lignes.

b) Taille = nombre de lignes × taille d'une ligne = 8 760 × 39 = 341 640 octets. Comme 1 ko = 1 000 octets, cela fait 341,64 ko, soit environ 342 ko, ce qu'il fallait montrer.

c) On multiplie par le nombre de stations et par le nombre d'années : 341 640 × 12 × 10 = 40 996 800 octets. Comme 1 Mo = 1 000 000 d'octets, la taille est d'environ 41,0 Mo.

d) Toutes les 10 minutes, il y a 60 ÷ 10 = 6 relevés par heure au lieu de 1 : le nombre de lignes est multiplié par 6, et la taille aussi (chaque ligne garde 39 octets). On obtient 40 996 800 × 6 = 245 980 800 octets, soit environ 246 Mo. Cela reste faible pour un disque actuel, mais montre que la fréquence de mesure pèse directement sur le volume stocké.

a) Une proposition possible : Nom (texte), Prénom (texte), Date de naissance (date), Catégorie (texte, par exemple « moins de 15 ans »), Certificat médical fourni (booléen : oui ou non). D'autres choix sont acceptables (numéro de maillot : nombre entier ; taille en mètres : nombre décimal) s'ils décrivent bien chaque licencié et ont un type précis.

b) L'âge change chaque année : une table qui le stocke devient fausse dès le premier anniversaire et doit être corrigée sans cesse. La date de naissance, elle, ne change jamais, et l'âge s'en déduit à tout moment par un calcul. C'est donc elle qu'il faut stocker.

c) Une valeur doit contenir une seule information. Avec « Nom complet », on ne sait pas toujours où s'arrête le prénom (« Jean Pierre Martin » : prénom composé ou nom composé ?) et on ne peut pas rechercher facilement tous les membres d'une même famille. Séparer Nom et Prénom rend chaque valeur simple et sans ambiguïté.

d) Il faut un identifiant unique, par exemple le numéro de licence délivré par la fédération : deux licenciés ne peuvent pas avoir le même. Sans lui, les deux Léo Garcia ne se distinguent que si leurs autres valeurs diffèrent, ce qui n'est pas garanti.

a) 2 340 × 3,2 = 7 488 Mo, soit 7,488 Go (environ 7,5 Go).

b) Vidéos : 9 × 850 = 7 650 Mo. Total : 7 488 + 7 650 = 15 138 Mo = 15,138 Go. Or 15,138 Go > 15 Go : l'ensemble ne tient pas, il manque 138 Mo. Léa doit supprimer ou compresser quelques fichiers (ou payer plus d'espace).

c) La tablette a déjà envoyé sa version au nuage. À la reconnexion, l'ordinateur envoie la sienne : les deux versions ont été modifiées indépendamment à partir du même fichier, c'est un conflit de synchronisation. Le service ne peut pas choisir seul ; en général il garde les deux, en créant une copie « en conflit », et Léa doit fusionner les modifications à la main pour ne rien perdre.

d) Pour le professeur : un partage en lecture seule, qui lui permet de lire sans risquer de modifier le travail. Pour le binôme : un partage en modification, nécessaire pour compléter l'exposé. On partage ainsi avec chacun le minimum de droits utile.

1. Le PUE est le quotient de l'énergie totale par l'énergie des équipements informatiques.

2021 : PUE = 52 800 ÷ 32 000 = 1,65. 2024 : PUE = 45 900 ÷ 34 000 = 1,35.

2. Énergie non informatique = énergie totale − énergie informatique.

2021 : 52 800 − 32 000 = 20 800 MWh. 2024 : 45 900 − 34 000 = 11 900 MWh.

Baisse : 20 800 − 11 900 = 8 900 MWh, soit 8 900 ÷ 20 800 ≈ 0,428, c'est-à-dire une baisse d'environ 42,8 %.

3. L'énergie informatique passe de 32 000 à 34 000 MWh : elle augmente de 2 000 MWh (+6,25 %), le centre rend donc plus de service. Pourtant l'énergie totale baisse de 52 800 à 45 900 MWh (−6 900 MWh, environ −13,1 %), et le PUE passe de 1,65 à 1,35 : pour 1 MWh utile à l'informatique, le centre dépensait 0,65 MWh en plus, il n'en dépense plus que 0,35. Le PUE s'étant rapproché de 1, le centre est bien plus efficace.

4. D'après le document 2, en 2021 le refroidissement représentait 32 % de la consommation, soit le principal poste non informatique (32 % sur les 39 % hors serveurs). Le free cooling du document 3 remplace une partie de la climatisation par l'air extérieur, gratuit : c'est ce poste qui diminue, d'où la forte baisse de l'énergie non informatique. La récupération de chaleur ne réduit pas la consommation du centre lui-même, mais elle évite de consommer de l'énergie ailleurs pour chauffer la piscine : elle améliore le bilan global.

5. 45 900 ÷ 4,6 ≈ 9 978. Le centre consomme autant d'électricité qu'environ 10 000 foyers : même efficace, un centre de données reste un gros consommateur, ce qui justifie de ne pas stocker de données inutiles.

1. L'en-tête contient 4 descripteurs (id_borne, commune, puissance_kW, acces) : chaque ligne doit avoir 4 champs. La ligne BR-002,La Ciotat,7,4,public en compte 5. La puissance est un nombre décimal, 7,4 kW, écrit avec une virgule, alors que la virgule est aussi le séparateur : un programme lit « 7 » comme puissance, « 4 » comme accès, et « public » devient un cinquième champ sans descripteur. La ligne BR-002 est mal formée.

2. Première correction : mettre la valeur entre guillemets, BR-002,La Ciotat,"7,4",public ; la virgule interne n'est alors plus un séparateur. Seconde correction : changer de séparateur pour tout le fichier (« ; »), ce qui permet de garder la virgule décimale. On peut aussi écrire la puissance avec un point, 7.4, si le logiciel qui lira le fichier l'accepte.

3. La ligne BR-004 a bien 4 champs, mais le troisième est vide : la puissance de cette borne est inconnue (valeur manquante). La remplacer par 0 affirmerait que la borne ne délivre aucune puissance, ce qui est une information fausse ; et tout calcul ultérieur (puissance moyenne, par exemple) serait faussé. Une valeur manquante doit rester signalée comme telle.

4. Ces informations ne décrivent pas les bornes mais le fichier lui-même : ce sont des métadonnées. La licence indique ce que l'on a le droit de faire des données : la Licence Ouverte autorise la réutilisation, y compris commerciale, à condition de citer la source. L'encodage indique comment les caractères sont codés : si on ouvre le fichier avec un autre encodage, les lettres accentuées (« privé », « Gémenos ») s'affichent mal. La date de mise à jour et la fréquence, enfin, disent si les données sont récentes.

5. {"id_borne": "BR-003", "commune": "Cassis", "puissance_kW": 50, "acces": "privé"} : la puissance est un nombre, donc sans guillemets ; les autres valeurs sont des textes.

1. Le contenu est le texte de l'exposé sur les volcans. Les métadonnées décrivent le fichier sans en faire partie : par exemple l'auteur à la création (Maxime R.), la date de création (11/03/2026 à 20:12) et la durée totale d'édition (12 min 40 s). Elles sont enregistrées automatiquement par le logiciel.

2. Du 11/03 à 20:12 au 15/03 à 20:12, il s'écoule 4 jours. Du 15/03 à 20:12 au 16/03 à 07:55, il s'écoule 11 h 43 min (de 20:12 à minuit : 3 h 48 min ; puis 7 h 55 min). Durée totale : 4 jours 11 h 43 min.

3. Le fichier a existé pendant plus de 4 jours, mais n'a été ouvert en modification que 12 min 40 s au total, en 3 révisions : c'est très peu pour rédiger un exposé « toute la semaine ». De plus, le fichier a été créé par Maxime R., et Théo n'apparaît qu'à la dernière modification, le 16/03 à 7 h 55. Ces métadonnées suggèrent que Théo a récupéré le fichier d'un camarade et l'a peu modifié.

4. Non. Les métadonnées sont des indices, pas des preuves. Le champ « Créé par » reprend le nom du compte de l'ordinateur utilisé : Théo a pu créer le fichier sur l'ordinateur de Maxime, ou partir d'un modèle vide que Maxime lui a envoyé. Il a pu aussi rédiger dans un autre fichier et coller son texte à la fin. Enfin, ces métadonnées se modifient facilement. Le professeur peut s'en servir pour poser des questions, mais il faut comparer avec d'autres éléments (contenu, entretien avec Théo).

5. Avant de publier, on supprime les informations personnelles du fichier : nom de l'auteur, historique, commentaires (option « Supprimer les propriétés » ou « Inspecter le document » du logiciel, ou export en PDF sans métadonnées). Comme pour les photos, les métadonnées d'un document peuvent en dire plus que ce que l'on veut montrer.