BTS SIO 2025 SLAM – Casterman
Analyse détaillée et méthodologie complète

Hash, trigger MySQL, gestion des droits, requêtes SQL de surveillance, API REST, validation des paramètres et tests unitaires.

SLAMSession 2025HashTrigger SQLAPI REST

Le sujet Casterman est un cas très représentatif de l’épreuve BTS SIO SLAM : il mélange sécurité applicative, base de données, code Java, SQL et API REST. Pour réussir, il ne faut pas seulement réciter des notions : il faut expliquer les risques, corriger les erreurs et justifier les choix techniques. Cette page reprend les quatre axes utiles pour réussir : analyse du cas, méthodologies, exemples modèles et pièges à éviter.

Plan de l’analyse

1. Analyse du cas Casterman : comprendre le problème avant de répondre

Casterman est une librairie spécialisée dans la bande dessinée. Le sujet demande de sécuriser plusieurs éléments du système d’information : l’authentification des utilisateurs, l’historique des mots de passe, la gestion des droits, la détection d’activités anormales et l’accès à une API REST.

La grille d’analyse en 4 dimensions

  • Sécurité : protéger les mots de passe avec un hachage irréversible et éviter toute confusion avec le chiffrement.
  • Base de données : corriger un trigger MySQL en utilisant correctement OLD et NEW.
  • Application : vérifier les droits d’un utilisateur en Java sans provoquer de NullPointerException.
  • Surveillance : détecter les comportements anormaux grâce à une requête SQL avec GROUP BY et HAVING.

Le vrai fil conducteur du sujet

Le sujet Casterman évalue surtout votre capacité à distinguer une solution qui “fonctionne” d’une solution vraiment robuste. Un trigger peut être syntaxiquement correct mais métierement faux. Une méthode Java peut marcher dans un cas normal mais planter avec une liste vide. Une requête SQL peut sélectionner les bonnes lignes mais oublier le regroupement nécessaire. C’est exactement ce que le correcteur cherche à repérer.

Ce que le correcteur veut voir

Une bonne copie explique les mécanismes. Par exemple : “Dans un trigger BEFORE UPDATE, OLD.mdpActuel désigne l’ancien mot de passe à archiver, tandis que NEW.mdpActuel désigne le nouveau mot de passe. Utiliser NEW dans la vérification d’historique empêche d’enregistrer correctement l’ancien mot de passe.”

Les grands blocs techniques du sujet

BlocCompétence attendueErreur à éviter
Hash / mot de passeJustifier le hachage irréversibleProposer un chiffrement réversible pour stocker un mot de passe
Trigger MySQLUtiliser correctement OLD et NEWHistoriser le nouveau mot de passe au lieu de l’ancien
Droits JavaParcourir une collection de droits de manière robusteOublier de tester null ou liste vide
SQL surveillanceUtiliser GROUP BY puis HAVINGÉcrire WHERE COUNT(*) > 5
API RESTValider les paramètres et sécuriser l’accès aux donnéesFaire confiance à un paramètre reçu dans l’URL

2. Méthodologies : comment structurer les réponses

Méthode pour expliquer hash versus chiffrement

  1. Dire clairement que le chiffrement est réversible.
  2. Dire clairement que le hachage est irréversible.
  3. Expliquer que l’application n’a jamais besoin de retrouver le mot de passe en clair.
  4. Conclure que le stockage doit se faire avec un hachage robuste, par exemple bcrypt.

La formulation à retenir : on chiffre une donnée que l’on doit relire, mais on hache un mot de passe que l’on doit seulement vérifier.

Méthode pour corriger un trigger MySQL

  1. Identifier le type de trigger : BEFORE UPDATE, AFTER INSERT, etc.
  2. Repérer les valeurs anciennes et nouvelles.
  3. Utiliser OLD pour les valeurs avant modification.
  4. Utiliser NEW pour les valeurs après modification.
  5. Relier la correction à la règle métier : historiser l’ancien mot de passe.

Méthode pour une question Java sur les droits

Avant de parcourir une collection, il faut vérifier qu’elle existe et qu’elle n’est pas vide. Ensuite, la méthode peut parcourir les droits et comparer la table et l’opération demandées.

public boolean possedeDroit(String uneTable, String uneOperation) {
    if (this.lesDroits == null || this.lesDroits.isEmpty()) {
        return false;
    }
    for (Droit d : this.lesDroits) {
        if (d.getTable().equals(uneTable) &&
            d.getOperation().equals(uneOperation)) {
            return true;
        }
    }
    return false;
}

Méthode pour une requête SQL avec agrégats

Il faut filtrer les lignes avec WHERE, regrouper avec GROUP BY, puis filtrer les groupes avec HAVING.

SELECT idUtilisateur, COUNT(*) AS nbAjouts
FROM Log
WHERE nomTable = 'BandeDessinee'
  AND operation = 'insert'
  AND dateHeure >= CONCAT(CURRENT_DATE(), ' 08:00:00')
GROUP BY idUtilisateur
HAVING COUNT(*) > 5
ORDER BY nbAjouts DESC;

Niveau de difficulté : technique mais très structuré

Casterman n’est pas difficile parce qu’il serait imprévisible. Il est difficile parce qu’il exige de la précision : un mauvais mot-clé, une confusion OLD/NEW ou un HAVING oublié peuvent coûter beaucoup de points. En revanche, les réponses deviennent très solides si vous structurez toujours votre raisonnement.

3. Exemples modèles 📗 : ce qu’une excellente réponse peut donner

Exemple modèle 1 : hachage des mots de passe

“Le mot de passe ne doit pas être chiffré car le chiffrement est réversible : si la clé est compromise, tous les mots de passe peuvent être retrouvés en clair. Il faut utiliser un hachage robuste comme bcrypt. Lors de la connexion, on hache le mot de passe saisi et on compare le résultat avec le hash stocké.”

Exemple modèle 2 : correction du trigger

“Dans le trigger BEFORE UPDATE, l’ancien mot de passe doit être récupéré avec OLD.mdpActuel. La valeur NEW.mdpActuel correspond au nouveau mot de passe et ne doit pas être utilisée pour historiser l’ancien. La correction permet de conserver l’historique des mots de passe déjà utilisés.”

Exemple modèle 3 : méthode Java robuste

“La méthode doit d’abord vérifier si la liste des droits est nulle ou vide. Si c’est le cas, elle retourne false. Ensuite seulement, elle parcourt les droits et vérifie simultanément la table et l’opération demandées.”

Exemple modèle 4 : requête de surveillance

“La requête doit regrouper les logs par utilisateur afin de compter les ajouts. La clause HAVING COUNT(*) > 5 filtre les utilisateurs ayant ajouté plus de cinq bandes dessinées depuis huit heures, ce qui permet de détecter une activité anormale.”

Exemple modèle 5 : sécurisation API REST

“Un paramètre reçu par une API REST doit être validé avant utilisation. Pour un ISBN, on peut imposer un format numérique attendu, puis utiliser une requête préparée. Cette double protection limite les erreurs et empêche l’injection SQL.”

4. Pièges à éviter ⚠️ : les erreurs qui coûtent des points

Piège 1 : dire qu’il faut chiffrer les mots de passe

Pour un mot de passe, le chiffrement est une mauvaise réponse car il est réversible. Le correcteur attend le hachage irréversible, idéalement avec bcrypt ou Argon2.

Piège 2 : utiliser NEW à la place de OLD

Dans un trigger de mise à jour, NEW contient la nouvelle valeur et OLD l’ancienne. Pour historiser l’ancien mot de passe, il faut donc utiliser OLD.mdpActuel.

Piège 3 : parcourir une liste Java sans vérifier qu’elle existe

Une collection nulle provoque une NullPointerException. Le test de nullité et de liste vide est indispensable dans une méthode robuste.

Piège 4 : écrire WHERE COUNT(*)

COUNT(*) est un agrégat calculé après regroupement. Il faut donc utiliser HAVING COUNT(*) > 5, pas WHERE COUNT(*) > 5.

Piège 5 : valider une API uniquement côté client

Une validation JavaScript côté navigateur peut être contournée. Les contrôles doivent être faits côté serveur avant toute requête SQL ou tout accès aux données.

Stratégie pour viser 15/20 ou plus

Plan d’attaque pendant l’épreuve

  1. Commencer par les questions de sécurité : hachage, trigger, droits, API.
  2. Expliquer chaque correction : ne jamais donner du code sans justification.
  3. Utiliser les bons mots-clés : irréversible, réversible, OLD, NEW, HAVING, requête préparée.
  4. Tester mentalement les cas limites : liste vide, mot de passe déjà utilisé, paramètre invalide.
  5. Relier au métier : protéger les comptes, les droits et les données de la librairie.

La copie qui dépasse 15/20

Une très bonne copie ne se contente pas de corriger. Elle démontre la compréhension : pourquoi le hachage est adapté, pourquoi OLD est nécessaire, pourquoi HAVING est obligatoire et pourquoi une API doit valider ses paramètres côté serveur.

FAQ – Sujet Casterman BTS SIO 2025 SLAM

Quel est le thème principal du sujet Casterman ?

Le sujet porte sur la sécurité applicative : hachage des mots de passe, trigger MySQL, gestion des droits, requêtes SQL de surveillance et API REST.

Pourquoi faut-il hacher les mots de passe ?

Parce que le hachage est irréversible. Même si la base est volée, les mots de passe en clair ne peuvent pas être retrouvés directement.

Quelle est l’erreur classique dans le trigger ?

L’erreur consiste à utiliser NEW.mdpActuel alors qu’il faut utiliser OLD.mdpActuel pour historiser l’ancien mot de passe.

Pourquoi utiliser HAVING dans la requête SQL ?

HAVING filtre les résultats après le regroupement, ce qui permet de sélectionner les utilisateurs dont le nombre d’ajouts dépasse un seuil.

Comment sécuriser l’API REST ?

Il faut valider les paramètres reçus, refuser les formats incorrects, utiliser des requêtes préparées et ne jamais faire confiance directement aux données reçues dans l’URL.

📥 Télécharger le document officiel

Sujet complet BTS SIO 2025 SLAM Casterman pour travailler l’épreuve.

📄 Sujet complet PDF

📚 Autres sujets SIO

Retrouvez les autres sujets BTS SIO disponibles pour compléter vos révisions.