Chapitre 410 minIntermédiaire
Le dossier E6 : fiches descriptives et éléments techniques
Par Josselyn C., prof de BTS SIO. Mis à jour le .
À la fin de ce chapitre, tu sauras
- remplir la fiche descriptive rubrique par rubrique ;
- choisir les éléments techniques à joindre ;
- préparer un environnement qui démarre le jour de l'épreuve.
1 exercice corrigé1 schéma
Le dossier de l'E6 SLAM est le dossier numérique que tu remets avant l'épreuve : une fiche descriptive pour chacune de tes deux réalisations professionnelles, et les éléments techniques qui permettent de les consulter. La commission s'en sert pour choisir une réalisation et écrire ton expression des besoins. Ce chapitre montre comment remplir la fiche descriptive de réalisation professionnelle, quoi joindre, et comment préparer un environnement qui démarre le jour de l'épreuve.
Ce que contient le dossier
La circulaire nationale fixe le contenu du dossier numérique :
- les fiches descriptives des deux réalisations, sur le modèle de l'annexe de la circulaire (version B pour l'option SLAM), avec les modalités d'accès aux éléments techniques ;
- les éléments constitutifs de chaque réalisation : description des ressources matérielles et logicielles utilisées, schémas explicatifs, documentation utile.
Le tableau de synthèse et les attestations de stage appartiennent au dossier de l'E5, pas à celui de l'E6.
Qui lit ton dossier, et quand
- Le contrôle de conformité. Avant l'épreuve, une commission désignée par les autorités académiques (en ponctuel) ou ton équipe pédagogique (en CCF) vérifie que ton dossier existe et qu'il a été remis à temps. Absence de dossier ou dépôt après la date limite : tu n'es pas interrogé, tu reçois la mention « non valide » et le diplôme ne peut pas t'être délivré.
- La commission d'interrogation. Elle lit tes fiches et consulte tes réalisations avant l'épreuve, choisit celle sur laquelle elle t'interroge, puis rédige ton expression des besoins. Elle doit la rendre « suffisamment circonscrite pour permettre une réponse sur la durée de la préparation ».
Ta fiche est donc la seule chose que la commission connaît de toi quand elle écrit ton sujet. Une fiche vague donne un sujet vague, ou un sujet sur ce que tu as mal décrit.
Remplir la fiche descriptive, rubrique par rubrique
Le modèle officiel tient sur un recto, avec un verso libre qui peut continuer sur des pages suivantes.
| Rubrique | Ce que tu y écris | Piège à éviter |
|---|---|---|
| N° réalisation, nom, n° candidat, CCF ou ponctuel, date | l'identification | un numéro de réalisation différent de celui de ton dossier |
| Organisation support de la réalisation | l'organisation pour laquelle tu as travaillé, réelle (stage) ou fictive (atelier) | un nom sans une phrase sur son activité |
| Intitulé de la réalisation | ce que fait l'application, en une ligne | « Projet AP2 » : la commission ne sait pas de quoi il s'agit |
| Période et lieu | les dates de début et de fin, l'établissement ou l'entreprise | une période de trois jours pour une application complète |
| Modalité : seul(e) ou en équipe | la case, et en équipe ta part exacte | cocher « seul » pour un travail de binôme |
| Compétences travaillées | les trois compétences du bloc 2 que la réalisation mobilise | tout cocher par réflexe : la commission vérifiera |
| Conditions de réalisation | les ressources fournies (cahier des charges, base existante) et les résultats attendus | décrire le contexte au lieu de la demande |
| Ressources documentaires, matérielles et logicielles | langages et versions, framework, SGBD, IDE, outils de test et de versions, serveurs | « PHP, MySQL » sans version ni outil |
| Modalités d'accès aux productions et à leur documentation | URL du dépôt, URL de l'application, identifiants de test par rôle, organisation du stockage, lien vers la documentation | un dépôt privé, un mot de passe expiré |
| Verso : descriptif, productions, schémas | la description de la réalisation (voir plus bas) | un copier-coller du cahier des charges |
Un exemple de recto rempli
Voici la fiche de la réalisation 2 de Lina, l'étudiante fictive dont le chapitre Choisir tes deux réalisations analyse le dossier.
| Rubrique | Contenu |
|---|---|
| N° réalisation | 2 |
| Organisation support | Sorbier Logistique, organisation cliente fictive du contexte d'atelier, de 14 salariés (transport et entreposage), dont 4 commerciaux et techniciens qui se déplacent chaque semaine |
| Intitulé | Sorbier Frais : application web de saisie et de validation des notes de frais |
| Période, lieu | du 5 octobre 2026 au 12 février 2027 ; ateliers de professionnalisation |
| Modalité | en équipe de deux. Ma part : modèle de données, base MySQL, API REST, authentification, tests de l'API. Front React : mon binôme |
| Compétences travaillées | les trois |
| Conditions de réalisation | Cahier des charges de 4 pages fourni par le responsable administratif. Résultat attendu : les salariés saisissent leurs frais chaque mois, les comptables contrôlent, valident ou refusent, l'historique est conservé |
| Ressources | Node.js 24, Express 5, React 19, MySQL 8.4 ; VS Code, Postman, MySQL Workbench ; Vitest et supertest ; Git, GitHub (dépôt, tickets, GitHub Actions) ; serveur Debian 12 virtualisé de l'établissement |
| Modalités d'accès | Dépôt : URL du dépôt, accès invité pour la commission. Application : URL du serveur de l'établissement. Comptes de test : salarie1@sorbier.test et compta1@sorbier.test, mots de passe dans le README. Documentation : dossier docs/ (installation, API, modèle de données, guide utilisateur) |
Le verso : le descriptif de la réalisation
Le verso est libre. Une structure qui marche, en deux pages au plus :
- Le besoin, en cinq lignes : qui utilise l'application, pour quoi faire, ce qui se passait avant.
- L'architecture, avec un schéma : navigateur, API, base, et où tournent les composants.
- Les fonctionnalités, par rôle, avec les états métier (saisie, clôturée, validée, remboursée).
- Le modèle de données : le MLD ou un extrait, avec les contraintes importantes.
- Les choix techniques justifiés : une ligne par choix, avec l'alternative écartée.
- Les tests et les versions : combien de tests, comment ils se lancent, l'historique des versions et des corrections.
- Ta part, si tu as travaillé en équipe.
Écris pour la commission, qui va chercher une évolution à te demander : chaque fonctionnalité décrite est un sujet possible. Une fonctionnalité que tu ne maîtrises plus n'a rien à faire sur la fiche.
Les éléments techniques à joindre
| Élément | Contenu attendu | Pourquoi |
|---|---|---|
| Dépôt Git | tout le code, un historique lisible, un README | la commission lit ton code avant de rédiger le sujet |
| Script de la base | création des tables, contraintes, procédures, triggers | « Concevoir ou adapter une base » se prouve ici |
| Jeu d'essai | des comptes de chaque rôle, des données dans chaque état, des cas limites | la recette se fait sur des données réalistes |
| Documentation technique | installation, architecture, API, modèle de données | « un document pour chaque contexte d'utilisation » |
| Documentation utilisateur | une page d'aide par rôle, avec captures | idem, pour un autre lecteur |
| Schémas | architecture, MLD, diagramme de cas d'utilisation ou de classes | la commission comprend ton application en deux minutes |
| Rapport de tests | la liste des tests et leur résultat | « Réaliser les tests nécessaires à la validation » |
Un environnement qui démarre le jour de l'épreuve
L'annexe II.E exige que le code source de tes réalisations soit « accessible dans un environnement de développement opérationnel au moment de l'épreuve », et la circulaire te rend seul responsable de tes outils. Une application qui ne démarre pas te laisse sans rien à réaliser, et la commission peut alors élargir l'interrogation à ta maîtrise de l'environnement.
Prépare ton environnement comme une mise en production :
- Tout tourne en local, sans dépendre d'un hébergement gratuit qui s'endort après inactivité ni d'un service extérieur.
- Les dépendances sont déjà installées :
node_modulesprésent, paquets NuGet restaurés, images Docker téléchargées. Le réseau du centre peut être lent ou filtré. - La base est chargée avec le jeu d'essai, et un script la recrée en une commande si tu la casses.
- Les comptes de test fonctionnent, un par rôle, et leurs mots de passe sont dans le README.
- Le dépôt est propre : aucune modification en cours, la branche principale à jour, la dernière version poussée.
- Les outils sont ouverts : IDE, terminal, client HTTP (Postman ou curl), client de base de données.
- Tu as testé le démarrage à froid la veille, machine redémarrée, en chronométrant.
Et un plan B, parce que le matériel tombe en panne : une copie complète du dépôt et du dump de la base sur une clé USB, et une seconde machine prête si ton établissement le permet. La proposition d'organisation de la circulaire prévoit une marge de 10 minutes pour les incidents techniques pendant la préparation sur ton environnement. Ne compte pas dessus pour finir ton code.
Exercice
Exercice Corriger une fiche bâclée Réussi À revoir
Voici des extraits de la fiche de Tom. Pour chaque rubrique, dis ce qui ne va pas et réécris-la.
- Intitulé : « Projet AP 2e année »
- Modalité : seul (le projet a été fait à trois)
- Ressources : « PHP, MySQL, VS Code »
- Modalités d'accès : « voir GitHub »
- Verso : le cahier des charges du projet, recopié
Voir la réponseMasquer la réponse de l'exercice
- Intitulé. Il ne dit pas ce que fait l'application. Réécriture : « Biblio+ : application web de réservation et de prêt d'ouvrages pour une médiathèque ».
- Modalité. Fausse : c'est un travail d'équipe. La commission le découvrira dans l'historique Git, et la confiance tombe. Réécriture : « en équipe de trois. Ma part : gestion des réservations (contrôleur, modèle, vues), base de données, tests PHPUnit des réservations ».
- Ressources. Sans versions ni outils, la commission ne peut pas vérifier la conformité à l'annexe II.E. Réécriture : « PHP 8.4 sans framework, PDO, architecture MVC ; MySQL 8.4 avec deux procédures stockées ; VS Code, PHPUnit, Postman ; Git et GitHub (tickets) ; application mobile React Native (Expo) pour la consultation ».
- Modalités d'accès. Aucune URL, aucun identifiant. Réécriture : l'URL exacte du dépôt avec l'accès accordé à la commission, l'URL de l'application, un compte de test par rôle, le chemin de la documentation dans le dépôt.
- Verso. Le cahier des charges dit ce qui était demandé, pas ce que Tom a fait. Réécriture : besoin en cinq lignes, schéma d'architecture, fonctionnalités par rôle, MLD, choix justifiés, tests, sa part dans l'équipe.
Tu avais trouvé ?