Retour au blog

Les projets informatiques à réaliser pour briller en BTS SIO

À l'épreuve E6, tu fais évoluer l'un de tes projets en une heure : choisis des sujets SLAM ou SISR qui s'y prêtent et entraîne-toi sur trois exercices corrigés.

Cet article a été rédigé à des fins pédagogiques. Les informations présentées peuvent évoluer. Nous t’invitons à vérifier auprès de sources officielles.

Le projet qui fait briller en BTS SIO n'est pas le plus gros : c'est celui que tu sais faire évoluer seul, en une heure. À l'épreuve E6, la commission choisit l'une de tes deux réalisations professionnelles et te demande une évolution, que tu analyses puis réalises sur place. Une application de congés, avec comptes, base de données et droits par rôle, s'y prête bien ; un site vitrine sans données n'offre presque rien à faire évoluer.

Ce que l'épreuve attend de tes deux réalisations

Une réalisation professionnelle est un projet mené pendant ta formation et décrit dans une fiche, avec l'accès à ses éléments techniques (code, schémas, documentation). Tes deux réalisations doivent couvrir ensemble toutes les compétences du bloc de ton option, le groupe de compétences que l'E6 évalue (arrêté du 29 avril 2019, version applicable depuis la session 2025). La fiche RNCP40792 les liste ainsi :

OptionCompétences du bloc
SISR (solutions d'infrastructure, systèmes et réseaux)Concevoir une solution d'infrastructure réseau ; l'installer, la tester et la déployer ; exploiter, dépanner et superviser une infrastructure réseau.
SLAM (solutions logicielles et applications métiers)Concevoir et développer une solution applicative ; en assurer la maintenance corrective ou évolutive ; gérer les données.

Définition : l'expression de besoins est la demande écrite par la commission à partir d'une de tes réalisations : ce que la solution doit faire en plus ou autrement. À la recette, elle vérifie que ta solution y répond.

En épreuve ponctuelle comme en contrôle en cours de formation (CCF), l'E6 se joue en quatre temps, devant deux professeurs dont au moins un de ton option.

Étape 1 : 30 minutes pour analyser la demande.

Étape 2 : 20 minutes au plus pour présenter ton analyse et tes choix ; la commission peut proposer un ajustement.

Étape 3 : une heure pour réaliser la solution, seul, dans l'environnement du centre.

Étape 4 : la recette et un entretien de 20 minutes au plus.

Tes outils et ressources techniques, tu les apportes toi-même, sous ta seule responsabilité.

Piège classique : soigner une réalisation et bâcler l'autre. La commission choisit celle qu'elle interroge, et elle peut prendre la plus faible.

Quatre sujets SLAM à faire évoluer

Un bon sujet SLAM part d'un vrai métier, avec des données liées entre elles et des rôles (qui a le droit de faire quoi) : la commission a de quoi écrire une demande d'évolution.

SujetDonnéesÉvolution possible
Congés d'une PMEEmployés, demandes, soldesMotif obligatoire en cas de refus
Prêt du matériel d'un lycéeMatériel, emprunteurs, prêtsBloquer un prêt si un retour est en retard
Interventions d'un plombierClients, interventions, piècesTotal facturé par mois
Salles d'une associationSalles, créneaux, réservationsRefuser deux réservations qui se chevauchent (exercice 3)

Ce qui fait la différence se voit dans le code : des requêtes préparées (exercice 1), des mots de passe hachés (transformés par une fonction qu'on ne sait pas inverser), des droits vérifiés sur le serveur et pas seulement par un bouton caché. Prévois aussi une base de test recréable par un script, pour repartir d'un état propre le jour J.

Quatre sujets SISR à concevoir, déployer et surveiller

En SISR, pars d'une organisation précise et d'un sujet qui te fait concevoir, déployer puis surveiller : un serveur installé puis oublié laisse de côté la troisième compétence.

Un VLAN est un réseau séparé créé sur les mêmes commutateurs que les autres ; le DHCP attribue les adresses, le DNS traduit les noms en adresses.

SujetCe que tu montresÉvolution possible
Réseau d'un cabinet médicalVLAN, routage, filtrageWi-Fi des patients coupé du reste (exercice 2)
Sauvegarde d'un serveur de fichiersPlanification, copie hors site, restauration testéeRestaurer un dossier supprimé la veille
Supervision des serveurs d'une mairieSondes, seuils, alertesAlerte à 90 % de disque rempli
DNS et DHCP redondantsDeux serveurs, service maintenu si l'un tombeAdresse réservée pour une imprimante

Piège classique : sur la plupart des pare-feu, les règles se lisent de haut en bas et la première qui correspond s'applique. Un « tout autoriser » placé au-dessus d'un refus rend ce refus inutile.

Préparer l'heure de réalisation

Pour chaque réalisation, fais-toi écrire cinq demandes d'évolution plausibles par un camarade, puis réalise chacune en une heure, chronomètre en marche. Celles qui débordent montrent ce qui te ralentit : une base impossible à recréer, une configuration introuvable, une requête que tu cherches.

Pendant les 30 minutes d'analyse, note ce qui change dans les données ou la configuration, ce qui change dans le traitement, et les cas de recette : ceux qui doivent passer, ceux qui doivent être refusés. Ce plan, tu le présentes, puis tu le suis.

Conseil : un sujet trop gros n'est maîtrisé qu'en partie, et la demande peut viser le reste. Choisis-en un dont tu expliques chaque fichier ou chaque règle sans tes notes.

Exercices corrigés

Cherche chaque exercice sur ta feuille avant d'ouvrir sa correction.

Exercice 1 : Dans l'application de congés, cette page PHP affiche les demandes de l'employé dont l'identifiant arrive dans l'adresse, comme demandes.php?id=7.

$sql = "SELECT * FROM demande WHERE id_employe = " . $_GET['id'];
$demandes = $pdo->query($sql)->fetchAll();

Que renvoie la requête si l'identifiant reçu vaut 0 OR 1=1 ? Corrige le code.

Correction :

La requête devient SELECT * FROM demande WHERE id_employe = 0 OR 1=1. Comme 1=1 est toujours vrai, elle renvoie les demandes de tous les employés. C'est une injection SQL : l'utilisateur écrit un morceau de ta requête. La parade est la requête préparée, où la valeur voyage à part et n'est jamais lue comme du SQL.

$stmt = $pdo->prepare("SELECT * FROM demande WHERE id_employe = :id");
$stmt->execute(['id' => $_GET['id']]);
$demandes = $stmt->fetchAll();

Reste un trou : avec id=8, on lit les demandes d'un collègue. L'identifiant doit venir de la session, par exemple $_SESSION['id_employe'].

Exercice 2 : Le cabinet médical découpe 192.168.20.0/24 en quatre sous-réseaux de même taille, reliés entre eux et à Internet par un routeur pare-feu : VLAN 10 (soins), 20 (secrétariat), 30 (serveurs), 40 (patients), dans cet ordre. Expression de besoins : « Les patients accèdent à Internet par le Wi-Fi, mais à aucune machine du cabinet. » Donne le masque, puis la passerelle et la plage DHCP du VLAN 40, les règles de filtrage dans l'ordre, et ce que tu montres à la recette.

Correction :

Il faut 4 sous-réseaux et $4 = 2^2$ : on emprunte 2 bits, d'où /26, soit le masque 255.255.255.192. Il reste $32 - 26 = 6$ bits pour les machines, soit $2^6 = 64$ adresses par sous-réseau : .0, .64, .128 et .192.

Le VLAN 40 est donc 192.168.20.192/26 : adresses utilisables de .193 à .254, la .255 servant à la diffusion (envoi à tout le sous-réseau). La passerelle prend souvent la première, 192.168.20.193, et le DHCP distribue de .194 à .254, soit $254 - 194 + 1 = 61$ adresses. Comme DNS, il annonce un serveur joignable, un DNS public par exemple, et pas un serveur du VLAN 30, que la règle 1 bloquerait.

Pour ce qui part du VLAN 40, dans cet ordre :

  1. refuser vers 192.168.20.0/25 (VLAN 10 et 20) et vers 192.168.20.128/26 (serveurs) ;
  2. refuser l'accès aux pages d'administration du pare-feu ;
  3. autoriser le reste, donc Internet.

La règle 2 compte : l'adresse .193 du pare-feu n'est dans aucune plage de la règle 1. À la recette, un téléphone sur le Wi-Fi des patients reçoit une adresse entre .194 et .254 et ouvre un site web, mais n'atteint ni un serveur comme 192.168.20.130, ni l'administration du pare-feu.

Exercice 3 : Dans l'application de réservation de salles, la table reservation a les colonnes id_salle, debut et fin (date et heure). Expression de besoins : « Refuser une réservation qui en chevauche une autre dans la même salle. Un créneau qui commence quand un autre finit reste permis. » Un camarade refuse la demande si son début tombe pendant une réservation existante. Trouve un chevauchement que ce test laisse passer, puis écris la bonne requête.

Correction :

La salle est réservée de 10 h à 11 h. Une demande de 9 h à 12 h commence avant 10 h : le test l'accepte, alors qu'elle recouvre toute la réservation.

Raisonne sur le contraire. Deux créneaux $[d_1\,;\,f_1[$ et $[d_2\,;\,f_2[$ ne se chevauchent pas si l'un finit avant que l'autre commence : $f_1 \leqslant d_2$ ou $f_2 \leqslant d_1$. Ils se chevauchent donc si $d_1 \lt f_2$ et $d_2 \lt f_1$. Les inégalités strictes laissent passer un créneau qui commence pile quand l'autre finit.

$stmt = $pdo->prepare("SELECT COUNT(*) FROM reservation
    WHERE id_salle = :salle AND debut < :fin AND :debut < fin");
$stmt->execute(['salle' => $salle, 'debut' => $debut, 'fin' => $fin]);
$conflits = $stmt->fetchColumn();

Si $conflits dépasse 0, la réservation est refusée. À la recette, avec 10 h à 11 h déjà pris, les créneaux de 9 h à 12 h et de 10 h 30 à 11 h 30 sont refusés, celui de 11 h à 12 h passe.

À retenir

À retenir :

  • À l'E6, la commission choisit une de tes deux réalisations et te demande de la faire évoluer en une heure, après 30 minutes d'analyse.
  • Ensemble, tes deux réalisations couvrent toutes les compétences du bloc ; chacune doit tenir seule face à la commission.
  • Un bon sujet part d'une organisation précise, offre de quoi évoluer et se maîtrise en entier.

Sources

Tu peux partager cette page librement, en citant ORBITECH AI Academy avec son lien.