Projet E5 — Méthodologie de l'épreuve

Table des matières

1. Comprendre l'épreuve E5
2. Les compétences évaluées (bloc 2 SLAM)
3. Le portfolio numérique
4. Structure du portfolio
5. Choisir ses réalisations
6. Documenter une réalisation
7. La fiche descriptive de réalisation
8. Préparer la présentation orale
9. La démonstration technique
10. L'entretien avec le jury
11. Questions pièges classiques
12. Compétences transversales
13. La veille technologique
14. Erreurs fatales
15. Grille d'évaluation décryptée
16. Planning de préparation
17. Exemples de portfolios réussis
18. Exercices et mises en situation

1. Comprendre l'épreuve E5

1.1 Cadre réglementaire

L'épreuve E5, intitulée "Production et fourniture de services informatiques", est une épreuve orale, individuelle et ponctuelle. Elle s'appuie sur le portfolio numérique du candidat et évalue sa capacité à concevoir, développer et maintenir des solutions applicatives (option SLAM) ou des infrastructures réseau (option SISR).

Coefficient : 4

Durée totale : 40 minutes, décomposées comme suit :

Phase	Durée	Contenu
Présentation	10 minutes	Le candidat présente une ou plusieurs réalisations de son portfolio. Il peut effectuer une démonstration technique. Le jury n'intervient pas.
Entretien	30 minutes	Le jury questionne le candidat sur ses réalisations, ses choix techniques, sa démarche et ses compétences.

Pas de temps de préparation : le candidat entre, s'installe, et commence directement sa présentation.

1.2 Ce que le jury reçoit avant l'oral

Le jury dispose, avant le passage du candidat, des éléments suivants :

L'adresse du portfolio numérique (URL ou document PDF).
Les fiches descriptives de réalisations professionnelles.
Le tableau de synthèse des compétences couvertes.
Les attestations de stage et/ou le contrat d'alternance.

Le jury a donc le temps de parcourir le portfolio et de préparer ses questions. Un portfolio bâclé ou inaccessible crée une première impression négative avant même que le candidat n'ouvre la bouche.

1.3 Conditions matérielles

Le candidat dispose d'un poste informatique avec connexion réseau. Il peut apporter son propre ordinateur portable. Un vidéoprojecteur ou un écran externe est généralement mis à disposition.

Le candidat est responsable du bon fonctionnement de son environnement de démonstration. Aucune aide technique n'est fournie par le centre d'examen.

1.4 Composition du jury

Le jury est composé de deux membres minimum :

Un enseignant de la spécialité (informatique).
Un professionnel du secteur ou un second enseignant.

Les deux membres évaluent conjointement le candidat selon la grille officielle.

2. Les compétences évaluées (bloc 2 SLAM)

2.1 Le référentiel de compétences

L'épreuve E5 évalue le bloc de compétences 2, intitulé "Conception et développement d'applications" pour l'option SLAM. Ce bloc se décompose en compétences précises que le candidat doit démontrer à travers ses réalisations.

2.2 Détail des compétences

Concevoir une solution applicative

Analyser un besoin exprimé et son contexte.
Identifier les acteurs et les cas d'utilisation.
Modéliser les données (MCD, MLD, diagramme de classes).
Concevoir l'architecture logicielle (MVC, couches, microservices).
Élaborer des maquettes et prototypes d'interface.
Rédiger des spécifications techniques.

Développer une solution applicative

Coder dans un ou plusieurs langages de programmation.
Utiliser un framework ou une bibliothèque adaptée.
Implémenter une base de données relationnelle ou non relationnelle.
Développer des composants d'accès aux données (ORM, requêtes SQL).
Réaliser des interfaces utilisateur (web, mobile, desktop).
Intégrer des API et des services tiers.

Maintenir une solution applicative

Corriger des anomalies (débogage, analyse de logs).
Faire évoluer une application existante.
Rédiger et exécuter des tests (unitaires, d'intégration, fonctionnels).
Gérer les versions avec un outil de gestion de configuration (Git).
Documenter le code et les procédures de déploiement.

Documenter et communiquer

Rédiger une documentation technique.
Rédiger une documentation utilisateur.
Présenter une solution à un public technique ou non technique.
Justifier ses choix techniques.

2.3 Le tableau de synthèse

Le candidat doit produire un tableau de synthèse qui met en correspondance chaque réalisation avec les compétences qu'elle couvre. Ce tableau est transmis au jury et sert de grille de lecture pour évaluer la couverture du référentiel.

Exemple de structure :

Réalisation	Concevoir	Développer	Maintenir	Documenter
Application de gestion de stock	X	X		X
API REST pour application mobile	X	X	X
Refonte d'un site web existant		X	X	X
Outil de monitoring interne	X	X		X

L'objectif est que l'ensemble des réalisations couvre la totalité des compétences du bloc 2.

3. Le portfolio numérique

3.1 Définition

Le portfolio numérique est le support central de l'épreuve E5. C'est un espace en ligne (ou un document numérique) dans lequel le candidat présente son parcours, ses compétences et ses réalisations professionnelles. Il constitue la preuve concrète de l'acquisition des compétences du référentiel.

Le portfolio n'est pas un simple CV. C'est un dossier de preuves organisé, argumenté et illustré.

3.2 Formats possibles

Site web personnel

C'est le format le plus courant et le plus apprécié des jurys. Il démontre en lui-même une compétence technique (développement web) et offre une navigation fluide.

Technologies recommandées :

Site statique avec générateur (Hugo, Jekyll, Astro, Next.js).
Site dynamique léger (WordPress, Laravel).
Hébergement : GitHub Pages, Vercel, Netlify, OVH.

Avantages : interactif, démonstratif, facile à mettre à jour, accessible en ligne. Inconvénients : nécessite du temps de développement, risque de panne le jour J.

GitBook ou documentation en ligne

Adapté aux candidats qui préfèrent un format structuré sans développer un site complet.

Avantages : rapide à mettre en place, bonne organisation, versionnement intégré. Inconvénients : moins personnalisé, moins impressionnant visuellement.

Document PDF

Acceptable mais déconseillé. Un PDF statique ne permet pas de navigation fluide, ne montre pas de compétence technique et limite les possibilités de démonstration.

Avantages : simple, portable, pas de risque de panne réseau. Inconvénients : statique, peu engageant, ne démontre aucune compétence web.

3.3 Exigences techniques

Quel que soit le format choisi :

Le portfolio doit être accessible en ligne via une URL stable.
La navigation doit être claire et intuitive.
Le contenu doit être lisible (typographie, contraste, mise en page).
Les illustrations (captures d'écran, diagrammes, extraits de code) doivent être de bonne qualité.
Le portfolio doit fonctionner le jour de l'épreuve. Tester la veille et prévoir une copie locale.

4. Structure du portfolio

4.1 Page d'accueil

La page d'accueil est la première chose que le jury voit. Elle doit contenir :

Le nom et le prénom du candidat.
La formation (BTS SIO option SLAM).
L'année de passage.
Un menu de navigation clair vers les différentes sections.
Éventuellement une photo professionnelle (pas obligatoire).

La page d'accueil ne doit pas être surchargée. Elle doit donner envie d'explorer le reste du portfolio.

4.2 Parcours

Cette section présente le contexte du candidat :

Formation suivie (BTS SIO SLAM, établissement, années).
Expériences professionnelles (stages, alternance, emplois).
Pour chaque expérience : nom de l'entreprise, secteur d'activité, missions confiées, durée.
Éventuellement : parcours antérieur si pertinent (bac, formations complémentaires).

Cette section ne doit pas être un roman. Quelques paragraphes concis suffisent.

4.3 Compétences

Cette section présente les compétences acquises, organisées selon le référentiel du BTS SIO :

Lister les compétences du bloc 2 (et éventuellement du bloc 1 si pertinent).
Pour chaque compétence, indiquer le niveau de maîtrise et les réalisations associées.
Inclure les compétences techniques transversales : langages maîtrisés, frameworks, outils, méthodologies.

Présentation possible sous forme de tableau ou de grille visuelle. Éviter les barres de progression fantaisistes (type "PHP : 80%") qui n'ont aucune signification objective.

4.4 Réalisations

C'est la section principale du portfolio. Chaque réalisation fait l'objet d'une page dédiée (voir chapitre 6 pour le détail de la documentation d'une réalisation).

Organiser les réalisations de manière cohérente :

Par ordre chronologique, ou
Par type (entreprise, école, personnel), ou
Par compétence principale.

Chaque réalisation doit être accessible en un clic depuis le menu ou depuis la section compétences.

4.5 Veille technologique

Section dédiée à la veille technologique du candidat (voir chapitre 13 pour le contenu détaillé).

4.6 Éléments complémentaires (optionnels)

Contact (adresse mail professionnelle).
Liens vers les dépôts de code (GitHub, GitLab).
Certifications éventuelles.
Mentions légales si le portfolio est un site web public.

5. Choisir ses réalisations

5.1 Combien de réalisations ?

Le nombre recommandé est de 4 à 6 réalisations. Ce nombre permet de couvrir l'ensemble des compétences du bloc 2 sans se disperser.

Moins de 4 : couverture insuffisante des compétences, impression de manque de travail.
Plus de 6 : risque de survoler chaque réalisation, difficulté à tout maîtriser pour l'oral.

La qualité prime sur la quantité. Quatre réalisations solides et bien documentées valent mieux que huit réalisations superficielles.

5.2 Diversité des compétences couvertes

L'ensemble des réalisations doit couvrir toutes les compétences du bloc 2. Chaque réalisation couvre naturellement plusieurs compétences, mais il faut vérifier qu'aucune compétence n'est oubliée.

Critères de diversité :

Au moins une réalisation impliquant de la conception (modélisation, architecture).
Au moins une réalisation impliquant du développement front-end.
Au moins une réalisation impliquant du développement back-end.
Au moins une réalisation impliquant de la base de données.
Au moins une réalisation impliquant de la maintenance ou de l'évolution d'un existant.
Au moins une réalisation impliquant des tests.

5.3 Types de réalisations

Projets en entreprise (stage ou alternance)

Ce sont les réalisations les plus valorisées par le jury. Elles démontrent la capacité du candidat à travailler dans un contexte professionnel réel, avec des contraintes de production, des utilisateurs finaux et des délais.

Attention : respecter la confidentialité. Anonymiser les données sensibles, demander l'autorisation de l'entreprise pour les captures d'écran et les extraits de code.

Projets réalisés en formation

Les projets de cours, les TP évalués et les projets de groupe sont des réalisations valides. Le jury s'attend à ce qu'une partie des réalisations provienne du contexte scolaire.

Préciser clairement ce qui a été fait par le candidat dans le cadre d'un projet de groupe.

Projets personnels

Les projets personnels sont un excellent complément. Ils montrent la curiosité, l'autonomie et la passion du candidat. Un projet personnel original peut faire la différence.

Exemples : application mobile pour un besoin personnel, contribution à un projet open source, bot Discord, site web pour une association.

5.4 Stratégie de sélection

Lister toutes les réalisations possibles.
Établir le tableau de synthèse (réalisations vs compétences).
Sélectionner les réalisations qui maximisent la couverture.
Vérifier que chaque réalisation est suffisamment riche pour soutenir un échange de 5 à 10 minutes avec le jury.
S'assurer de pouvoir faire une démonstration technique d'au moins une réalisation.

6. Documenter une réalisation

Chaque réalisation du portfolio doit être documentée de manière complète et structurée. Voici la structure recommandée.

6.1 Contexte

Lieu de réalisation (entreprise, formation, personnel).
Période et durée.
Cadre du projet : pourquoi ce projet existe, quel problème il résout.
Commanditaire ou destinataire.
Rôle du candidat dans le projet (seul, en équipe, responsabilités précises).
Contraintes (techniques, budgétaires, temporelles).

6.2 Cahier des charges

Expression du besoin : ce que le commanditaire ou l'utilisateur attend.
Fonctionnalités principales (liste hiérarchisée).
Contraintes techniques (technologies imposées, environnement cible, performances attendues).
Contraintes non fonctionnelles (sécurité, accessibilité, ergonomie).

6.3 Conception

Modélisation des données : MCD (Merise), diagramme de classes UML, MLD.
Modélisation des traitements : diagrammes de cas d'utilisation, diagrammes de séquence, diagrammes d'activité.
Architecture logicielle : schéma d'architecture (client-serveur, MVC, microservices), choix du pattern.
Maquettes d'interface (wireframes, mockups).
Choix technologiques argumentés.

Chaque diagramme doit être lisible, légendé et accompagné d'un commentaire explicatif.

6.4 Technologies utilisées

Langages de programmation (avec version).
Frameworks et bibliothèques.
Système de gestion de base de données.
Outils de développement (IDE, outils de build, CI/CD).
Environnement de déploiement.

Ne pas faire une simple liste. Justifier les choix : "J'ai choisi Laravel parce que le projet nécessitait un framework MVC mature avec un ORM intégré, et que l'équipe maîtrisait déjà PHP."

6.5 Code significatif

Présenter des extraits de code pertinents, pas la totalité du projet. Choisir des portions qui illustrent :

Une logique métier complexe.
Un algorithme intéressant.
Un pattern de conception appliqué.
Une interaction avec la base de données.
Un traitement de sécurité (authentification, validation, protection CSRF).

Chaque extrait doit être commenté et expliqué : ce qu'il fait, pourquoi il est écrit ainsi, quels choix techniques il reflète.

Exemple de présentation :

Extrait : Contrôleur de gestion des commandes (OrderController.php)

Ce contrôleur gère la création d'une commande. Il valide les données
d'entrée, vérifie la disponibilité du stock via le service InventoryService,
crée la commande en base de données dans une transaction, puis déclenche
un événement pour l'envoi du mail de confirmation.

[extrait de code avec coloration syntaxique]

Points notables :
- Utilisation du pattern Service pour isoler la logique métier.
- Transaction SQL pour garantir la cohérence des données.
- Événement asynchrone pour ne pas bloquer la réponse HTTP.

6.6 Tests

Types de tests réalisés (unitaires, d'intégration, fonctionnels, de recette).
Outils de test utilisés (PHPUnit, JUnit, Jest, Selenium, Postman).
Exemples de cas de test (entrée, sortie attendue, résultat).
Couverture de test si mesurée.
Stratégie de test : quels composants sont testés et pourquoi.

6.7 Résultats

Livraison : le projet a-t-il été mis en production ? Utilisé par de vrais utilisateurs ?
Retours utilisateurs ou du commanditaire.
Métriques si disponibles (nombre d'utilisateurs, performances, réduction du temps de traitement).
Captures d'écran du produit final.

6.8 Bilan

Ce qui a bien fonctionné.
Les difficultés rencontrées et comment elles ont été surmontées.
Ce qui aurait pu être amélioré (recul critique, indispensable).
Compétences acquises ou renforcées grâce à cette réalisation.
Perspectives d'évolution du projet.

Le bilan est la section la plus importante pour le jury. Un candidat capable d'analyser son propre travail avec lucidité démontre une maturité professionnelle que le jury valorise fortement.

7. La fiche descriptive de réalisation

7.1 Qu'est-ce que c'est ?

La fiche descriptive est un document officiel, au format imposé par le référentiel, qui résume une réalisation professionnelle. Elle est transmise au jury avant l'oral et sert de support à l'entretien.

Chaque candidat doit produire au moins deux fiches descriptives, correspondant à deux réalisations distinctes.

7.2 Contenu de la fiche

La fiche descriptive contient les rubriques suivantes :

Identification

Nom et prénom du candidat.
Numéro de candidat.
Intitulé de la réalisation.
Période de réalisation.
Lieu (entreprise, établissement).

Description de la réalisation

Contexte de la réalisation (environnement, besoin).
Objectifs de la réalisation.
Place de la réalisation dans le projet global (si applicable).

Environnement technologique

Langages, frameworks, SGBD, outils utilisés.
Environnement matériel et logiciel.

Compétences mises en oeuvre

Liste des compétences du référentiel couvertes par cette réalisation.

Modalités de réalisation

Seul ou en équipe.
Si en équipe : composition de l'équipe et rôle du candidat.
Méthodologie employée (agile, cycle en V, etc.).

Productions

Livrables produits (code, documentation, maquettes, tests).
Résultats obtenus.

7.3 Conseils de rédaction

Être factuel et concis. La fiche n'est pas une dissertation.
Utiliser un vocabulaire technique précis.
Ne pas confondre la fiche et la documentation complète dans le portfolio. La fiche est un résumé structuré.
Relire plusieurs fois pour éliminer les fautes d'orthographe et les imprécisions.
Faire valider la fiche par un enseignant avant soumission.

7.4 Relation entre fiche et portfolio

La fiche est un résumé. Le portfolio est le développement complet. Le jury lit la fiche avant l'oral, puis explore le portfolio pour approfondir. Les deux documents doivent être cohérents.

8. Préparer la présentation orale

8.1 Structure recommandée (10 minutes)

La présentation de 10 minutes est un exercice de communication structurée. Le candidat ne doit pas improviser. Voici une structure éprouvée :

Accroche (1 minute)

Capter l'attention du jury dès les premières secondes.

Se présenter brièvement (nom, formation, contexte de stage/alternance).
Annoncer le plan de la présentation.
Introduire la réalisation principale avec une phrase d'accroche qui donne envie d'en savoir plus.

Exemple : "Lors de mon stage chez X, j'ai été confronté au problème suivant : les commerciaux perdaient en moyenne 45 minutes par jour à saisir manuellement des données dans trois systèmes différents. J'ai conçu et développé une application qui a automatisé ce processus."

Contexte et problématique (2 minutes)

Présenter l'entreprise ou le contexte en quelques phrases.
Expliquer le problème ou le besoin à l'origine du projet.
Définir les objectifs et les contraintes.

Conception et choix techniques (3 minutes)

Présenter la modélisation (montrer un diagramme, pas le commenter pendant 10 minutes).
Expliquer les choix d'architecture et de technologies.
Justifier ces choix (pas simplement "j'ai utilisé React parce que c'est bien").

Démonstration technique (5 minutes)

Montrer l'application en fonctionnement.
Suivre un scénario préparé (voir chapitre 9).
Commenter ce que l'on montre.
Montrer du code si pertinent.

Bilan et recul critique (3 minutes)

Résultats obtenus.
Difficultés rencontrées et solutions apportées.
Points d'amélioration identifiés.
Compétences acquises.

Ouverture (1 minute)

Perspectives d'évolution du projet.
Lien avec d'autres réalisations du portfolio si pertinent.
Phrase de conclusion.

8.2 Gestion du timing

10 minutes passent très vite. Le risque principal est de dépasser le temps ou, à l'inverse, de finir en 5 minutes.

Conseils :

Chronométrer chaque section lors des répétitions.
Prévoir des contenus "extensibles" que l'on peut développer ou raccourcir selon le temps restant.
Ne pas tenter de présenter toutes ses réalisations en 10 minutes. Se concentrer sur une ou deux réalisations principales et mentionner les autres brièvement.
Avoir un repère temporel : à 7-8 minutes, on doit avoir commencé la démo.

8.3 Support visuel

Le support visuel (diaporama) est facultatif mais recommandé. Il structure la présentation et donne des repères visuels au jury.

Règles :

Maximum 6-8 diapositives pour 10 minutes.
Peu de texte par diapositive (mots-clés, pas de phrases complètes).
Des visuels : diagrammes, captures d'écran, schémas d'architecture.
Pas d'animations complexes.
Lisible depuis le fond de la salle (taille de police suffisante).
Le diaporama accompagne le discours, il ne le remplace pas.

Le candidat ne doit jamais lire ses diapositives. Si le contenu est projeté, le jury sait lire. Le candidat apporte la valeur ajoutée : l'explication, le contexte, l'argumentation.

8.4 Répétitions

Répéter au minimum cinq fois la présentation complète :

Deux fois seul, en se chronométrant.
Deux fois devant un public (camarades, enseignants, famille).
Une fois dans les conditions réelles (avec l'ordinateur, le vidéoprojecteur, la démonstration).

Enregistrer une répétition en vidéo permet d'identifier les tics de langage, les passages confus et les problèmes de rythme.

9. La démonstration technique

9.1 Pourquoi démontrer ?

La démonstration technique est l'élément qui distingue un bon candidat d'un candidat moyen. Elle prouve que le candidat a réellement développé ce qu'il présente et qu'il maîtrise le fonctionnement de son application.

Un candidat qui ne fait pas de démonstration perd des points. Un candidat dont la démonstration ne fonctionne pas perd des points et de la crédibilité.

9.2 Préparer l'environnement

Avant le jour J :

Installer l'ensemble de l'environnement sur l'ordinateur qui sera utilisé le jour de l'épreuve.
Vérifier que tout fonctionne sans connexion internet (si possible) ou avec une connexion limitée.
Préparer les données de démonstration (jeu de données réaliste, pas des "test123" ou "aaa").
Tester l'affichage sur un écran externe (résolution, taille de police, visibilité).
Fermer toutes les notifications et applications inutiles.
Charger la batterie à 100% et prévoir le chargeur.

Le jour J :

Arriver en avance pour installer le matériel.
Brancher l'écran externe et vérifier l'affichage.
Lancer l'environnement (serveur, base de données, application) avant le début du passage.
Vérifier que la démonstration fonctionne une dernière fois.
Laisser les fenêtres ouvertes et prêtes.

9.3 Scénarios de démonstration

Préparer un ou plusieurs scénarios de démonstration qui mettent en valeur les fonctionnalités principales et les choix techniques intéressants.

Chaque scénario doit :

Raconter une histoire (un utilisateur qui fait quelque chose de concret).
Montrer le parcours utilisateur de bout en bout.
Mettre en évidence les fonctionnalités clés.
Permettre de montrer du code si le jury le demande.

Exemple de scénario pour une application de gestion de stock :

1. Connexion avec un compte administrateur.
2. Ajout d'un nouveau produit avec photo et description.
3. Passage d'une commande qui décrémente automatiquement le stock.
4. Consultation du tableau de bord avec les alertes de stock bas.
5. Génération d'un rapport PDF des mouvements de stock.
6. Montrer le code du calcul automatique de stock (extrait pertinent).

9.4 Plan B : si ça plante

Les pannes arrivent. Le candidat qui a prévu un plan B montre sa maturité professionnelle.

Plans de secours :

Captures d'écran de l'application en fonctionnement, intégrées dans le diaporama.
Vidéo de démonstration pré-enregistrée (30 secondes à 2 minutes).
Copie locale complète du projet (pas de dépendance à un serveur distant).
Deuxième jeu de données si le premier est corrompu.
Navigateur alternatif si le premier pose problème.

En cas de panne pendant la démonstration :

Ne pas paniquer. Ne pas s'excuser pendant 5 minutes.
Dire calmement : "L'environnement rencontre un problème technique. Je vais vous montrer le fonctionnement via les captures d'écran que j'ai préparées."
Basculer sur le plan B sans perdre de temps.
Continuer la présentation en montrant le code et les diagrammes.

Le jury évalue la capacité du candidat à gérer l'imprévu. Un candidat qui rebondit proprement impressionne plus qu'un candidat dont tout fonctionne mais qui ne sait pas expliquer son code.

10. L'entretien avec le jury

10.1 Objectif de l'entretien

L'entretien de 30 minutes permet au jury d'évaluer :

La profondeur de compréhension technique du candidat.
Sa capacité à justifier ses choix.
Son recul critique sur son travail.
L'authenticité de ses réalisations (a-t-il vraiment fait ce qu'il présente ?).
Ses compétences transversales (communication, analyse, esprit critique).

10.2 Types de questions

Questions techniques

Portent sur le code, les technologies, l'architecture. Le jury teste la compréhension réelle.

Exemples :

"Expliquez-moi comment fonctionne cette requête SQL."
"Quel est le rôle de ce middleware dans votre application ?"
"Comment avez-vous géré l'authentification ?"
"Quelle est la complexité de cet algorithme ?"
"Qu'est-ce qu'une injection SQL et comment vous en protégez-vous ?"

Questions méthodologiques

Portent sur la démarche, l'organisation, les processus.

Exemples :

"Comment avez-vous organisé votre travail ?"
"Quelle méthodologie de développement avez-vous suivie ?"
"Comment avez-vous recueilli les besoins de l'utilisateur ?"
"Comment avez-vous versionné votre code ?"
"Comment avez-vous testé votre application ?"

Questions de recul critique

Portent sur la capacité d'analyse et l'honnêteté intellectuelle.

Exemples :

"Quelles sont les limites de votre solution ?"
"Si vous deviez refaire ce projet, que changeriez-vous ?"
"Quels problèmes avez-vous rencontrés ?"
"Comment votre solution se comporterait-elle avec 10 000 utilisateurs ?"

Questions d'approfondissement

Le jury explore un sujet connexe pour tester la culture technique du candidat.

Exemples :

"Vous avez utilisé MySQL. Connaissez-vous les bases NoSQL ? Dans quel cas les utiliseriez-vous ?"
"Vous avez développé en PHP. Que pensez-vous des langages typés statiquement ?"
"Connaissez-vous le concept de conteneurisation ? L'avez-vous utilisé ?"

10.3 Comment répondre

Structurer sa réponse

Même sous pression, structurer : "Pour répondre à votre question, je vais d'abord expliquer le contexte, puis la solution que j'ai choisie, et enfin pourquoi."

Être honnête

Si le candidat ne sait pas, il doit le dire : "Je ne connais pas ce concept en détail, mais d'après ce que j'en comprends..." ou "C'est un point que je n'ai pas exploré, mais je pense que...".

Le jury détecte immédiatement le bluff. L'honnêteté est toujours valorisée.

Montrer du code

Si une question porte sur un aspect technique, proposer de montrer le code correspondant : "Je peux vous montrer la portion de code qui gère cette fonctionnalité si vous le souhaitez."

Ne pas se justifier inutilement

Si le jury pointe une faiblesse, ne pas se braquer. Accepter la critique et montrer que l'on comprend le problème : "Effectivement, cette partie du code n'est pas optimale. Avec plus de temps, j'aurais implémenté un système de cache pour améliorer les performances."

11. Questions pièges classiques

Cette section liste les questions les plus fréquemment posées par les jurys E5 et propose des stratégies de réponse.

11.1 "Pourquoi ce choix technologique ?"

Ce que le jury teste : La capacité à argumenter un choix technique, pas à réciter une liste de fonctionnalités.

Mauvaise réponse : "Parce que c'est ce qu'on a appris en cours" ou "Parce que c'est le plus populaire."

Bonne réponse : "J'ai choisi Laravel pour trois raisons : premièrement, le projet nécessitait un framework MVC structuré avec un ORM intégré, ce qui correspond à Eloquent. Deuxièmement, la documentation de Laravel est très complète, ce qui facilitait la montée en compétence. Troisièmement, l'hébergeur du client supportait nativement PHP 8, ce qui évitait des contraintes de déploiement."

Structure de réponse : Critères de choix + adéquation au besoin + contraintes prises en compte.

11.2 "Qu'auriez-vous fait différemment ?"

Ce que le jury teste : Le recul critique et la capacité d'amélioration.

Mauvaise réponse : "Rien, tout a bien fonctionné" (arrogance) ou "Tout" (manque de confiance).

Bonne réponse : "Avec le recul, j'aurais mis en place des tests unitaires dès le début du projet. J'ai passé beaucoup de temps en fin de développement à corriger des régressions qui auraient été détectées plus tôt avec une suite de tests. J'aurais aussi mieux structuré mon code en séparant davantage la logique métier des contrôleurs."

Structure de réponse : Point d'amélioration concret + conséquence observée + solution que l'on appliquerait.

11.3 "Comment gérez-vous les erreurs ?"

Ce que le jury teste : La connaissance des bonnes pratiques de robustesse et de gestion d'exceptions.

Bonne réponse : "Dans mon application, j'ai mis en place plusieurs niveaux de gestion des erreurs. Côté back-end, j'utilise des blocs try-catch pour les opérations critiques comme les accès base de données et les appels API. Les exceptions sont loguées avec un niveau de détail suffisant pour le débogage. Côté front-end, les erreurs sont interceptées et l'utilisateur reçoit un message explicite sans détail technique. J'ai également mis en place une validation des données en entrée pour prévenir les erreurs en amont."

11.4 "Expliquez cette partie du code"

Ce que le jury teste : L'authenticité de la réalisation. Le candidat a-t-il réellement écrit ce code ?

Piège : Le jury ouvre le portfolio, pointe un extrait de code au hasard et demande une explication ligne par ligne.

Préparation : Relire l'intégralité de son code avant l'oral. Être capable d'expliquer chaque fichier, chaque fonction, chaque choix. Si le code a été partiellement généré ou copié, le comprendre parfaitement.

Si le candidat ne reconnaît pas son propre code : C'est un signal d'alerte majeur pour le jury. Cela suggère que le candidat n'a pas réellement réalisé le projet. Il n'y a pas de rattrapage possible à ce stade.

11.5 "Comment avez-vous travaillé en équipe ?"

Ce que le jury teste : Les compétences de collaboration et d'organisation.

Bonne réponse : "Nous étions trois développeurs. Nous avons utilisé Git avec une stratégie de branches : une branche main pour la production, une branche develop pour l'intégration, et une branche par fonctionnalité. Nous faisions des revues de code croisées avant chaque merge. Nous avions un daily meeting de 10 minutes chaque matin pour synchroniser nos travaux. J'étais responsable du module de gestion des utilisateurs et de l'API d'authentification."

11.6 "Comment votre application gère-t-elle la sécurité ?"

Bonne réponse : "J'ai mis en place plusieurs mesures de sécurité. L'authentification utilise le hachage bcrypt pour les mots de passe. Les sessions sont sécurisées avec des tokens CSRF sur chaque formulaire. Les entrées utilisateur sont validées côté serveur et les requêtes SQL utilisent des requêtes préparées pour prévenir les injections SQL. Les données sensibles sont transmises en HTTPS. J'ai également configuré les en-têtes de sécurité HTTP (Content-Security-Policy, X-Frame-Options)."

11.7 "Qu'est-ce que le pattern MVC et comment l'avez-vous appliqué ?"

Bonne réponse : "Le pattern MVC sépare l'application en trois couches. Le Modèle gère les données et la logique métier : dans mon cas, ce sont les classes Eloquent qui interagissent avec la base de données. La Vue est responsable de l'affichage : j'ai utilisé les templates Blade pour générer le HTML. Le Contrôleur fait le lien entre les deux : il reçoit la requête HTTP, appelle le modèle approprié et retourne la vue. Par exemple, quand un utilisateur accède à la liste des produits, le ProductController appelle le modèle Product pour récupérer les données, puis transmet ces données à la vue products/index.blade.php."

11.8 "Comment garantissez-vous la qualité de votre code ?"

Bonne réponse : "J'applique plusieurs pratiques. Le nommage des variables et des fonctions est explicite et suit les conventions du langage (PSR-12 pour PHP). Je découpe le code en fonctions courtes avec une responsabilité unique. J'utilise un linter pour détecter les erreurs de style. Je versionnne le code avec Git et je fais des commits réguliers avec des messages descriptifs. Quand c'est possible, j'écris des tests unitaires pour les fonctions critiques."

11.9 "Connaissez-vous les méthodes agiles ?"

Bonne réponse : "Les méthodes agiles sont des approches itératives et incrémentales du développement logiciel. La plus connue est Scrum, qui organise le travail en sprints de durée fixe avec des cérémonies définies : sprint planning, daily, sprint review et rétrospective. Kanban est une autre approche qui se concentre sur le flux de travail avec un tableau visuel. Dans mon projet, j'ai utilisé un tableau Kanban sur Trello pour suivre l'avancement des tâches avec les colonnes A faire, En cours, En test et Terminé."

11.10 "Pourquoi ne pas avoir utilisé telle technologie à la place ?"

Ce que le jury teste : La connaissance de l'écosystème et la capacité de comparaison.

Stratégie : Montrer que l'on connaît l'alternative mentionnée, expliquer ses avantages, puis justifier pourquoi le choix fait était plus adapté au contexte.

"Effectivement, React aurait été une alternative intéressante. React est performant pour les interfaces dynamiques avec beaucoup d'état côté client. Dans mon cas, l'application était principalement côté serveur avec peu d'interactions dynamiques, donc un rendu serveur classique avec Blade était suffisant et plus simple à mettre en place. Si le projet avait eu une interface plus riche, React aurait été un choix pertinent."

12. Compétences transversales

12.1 Travail en équipe

Le jury évalue la capacité du candidat à collaborer. Les points clés :

Utilisation d'outils collaboratifs (Git, gestionnaire de projet, messagerie d'équipe).
Répartition des tâches et coordination.
Gestion des conflits (techniques ou humains).
Communication avec les autres membres de l'équipe.
Revue de code et partage de connaissances.

Même si le candidat a travaillé seul sur un projet, il peut mentionner les interactions avec le tuteur de stage, les utilisateurs ou les autres développeurs de l'entreprise.

12.2 Gestion de projet

Le jury apprécie les candidats qui montrent une approche structurée :

Planification du travail (diagramme de Gantt, backlog, roadmap).
Suivi de l'avancement (burndown chart, tableau Kanban).
Gestion des priorités et des risques.
Respect des délais.
Adaptation face aux imprévus.

Outils à mentionner : Trello, Jira, GitHub Projects, Notion, Gantt Project.

12.3 Communication

La présentation orale est en elle-même une démonstration de la compétence de communication. Mais le jury évalue aussi :

La capacité à vulgariser un concept technique.
L'adaptation du discours au public (technique vs non technique).
La clarté de la documentation écrite (portfolio, code commenté).
La qualité de la rédaction (orthographe, syntaxe, structure).

13. La veille technologique

13.1 Ce que le jury attend

La veille technologique est une compétence du référentiel BTS SIO. Le jury attend que le candidat :

Explique ce qu'est la veille technologique et pourquoi elle est importante.
Décrive sa méthode de veille (sources, outils, fréquence).
Donne des exemples concrets de découvertes issues de sa veille.
Montre comment la veille a influencé ses choix techniques.

13.2 Sources de veille

Agrégateurs et flux RSS

Feedly : agrégateur de flux RSS, permet de centraliser ses sources.
Inoreader : alternative à Feedly.

Réseaux sociaux et communautés

Twitter/X : suivre des développeurs influents, des comptes de frameworks et d'outils.
Reddit : subreddits spécialisés (r/programming, r/webdev, r/php, r/javascript).
Hacker News : actualité technologique et discussions de fond.
Dev.to et Hashnode : plateformes de blogs techniques.

Sites spécialisés

Le blog officiel des technologies utilisées (blog Laravel, blog React, etc.).
Medium (publications techniques).
Stack Overflow (tendances, nouvelles réponses).

Podcasts et vidéos

Chaînes YouTube techniques.
Podcasts de développement (Syntax, Laravel News Podcast, etc.).

Newsletters

JavaScript Weekly, PHP Weekly, etc.
TLDR Newsletter (résumé quotidien de l'actualité tech).

13.3 Outils de veille

Feedly ou équivalent pour centraliser les flux.
Pocket ou Instapaper pour sauvegarder les articles à lire.
Notion ou un document dédié pour organiser les découvertes.
Google Alerts pour surveiller des mots-clés spécifiques.

13.4 Structurer la veille dans le portfolio

Créer une page dédiée dans le portfolio qui contient :

Explication de la démarche de veille.
Liste des sources suivies (avec liens).
Exemples concrets : "Grâce à ma veille, j'ai découvert la bibliothèque X qui m'a permis de résoudre le problème Y dans mon projet Z."
Analyse d'une tendance technologique (par exemple : l'essor des frameworks full-stack comme Next.js, l'adoption de TypeScript, l'IA dans le développement).

13.5 Exemples concrets à préparer

Le jury demande souvent : "Donnez-moi un exemple concret de votre veille technologique."

Préparer au moins deux exemples détaillés :

Exemple 1 : "En suivant le blog officiel de Laravel, j'ai découvert la fonctionnalité des Livewire components qui permet de créer des interfaces réactives sans JavaScript. J'ai testé cette approche sur un projet personnel et j'ai ensuite proposé à mon tuteur de stage de l'utiliser pour le module de recherche en temps réel de notre application. Cela a réduit le temps de développement de cette fonctionnalité."

Exemple 2 : "Via ma veille sur Twitter, j'ai appris l'existence de Tailwind CSS au moment où je devais choisir une solution de styling pour mon projet. Après avoir comparé Tailwind avec Bootstrap que j'utilisais habituellement, j'ai décidé de l'adopter pour sa flexibilité et j'ai pu créer une interface plus personnalisée sans écrire de CSS custom."

14. Erreurs fatales

Les erreurs suivantes sont rédhibitoires ou très pénalisantes. Les connaître permet de les éviter.

14.1 Lire ses notes

Le candidat qui lit un texte préparé (sur papier ou sur écran) montre qu'il ne maîtrise pas son sujet. Le jury n'évalue pas la capacité à lire à voix haute. Quelques mots-clés sur une fiche sont acceptables. Un texte rédigé, non.

14.2 Ne pas connaître son propre code

Si le jury ouvre le portfolio, pointe une ligne de code et que le candidat est incapable de l'expliquer, la crédibilité de l'ensemble du portfolio s'effondre. Tout le code présenté doit être compris et maîtrisé.

14.3 Pas de démonstration

Ne pas faire de démonstration technique, c'est renoncer à des points. Même une démonstration simple (lancer l'application, montrer les fonctionnalités principales) est mille fois préférable à l'absence de démonstration.

14.4 Portfolio vide ou incomplet

Un portfolio avec une seule réalisation, des pages "en construction" ou des sections vides montre un manque de préparation flagrant. Le portfolio doit être terminé et complet au moins une semaine avant l'épreuve.

14.5 Hors-sujet

Présenter des réalisations qui ne relèvent pas du bloc de compétences évalué. Par exemple, pour un candidat SLAM, présenter uniquement des réalisations réseau/infrastructure sans aucun développement.

14.6 Absence de recul critique

Affirmer que tout est parfait dans ses réalisations est un signal négatif. Le jury sait qu'aucun projet n'est parfait. L'absence de recul critique suggère soit un manque de lucidité, soit un manque de compétence pour identifier les faiblesses.

14.7 Bluffer

Prétendre maîtriser une technologie que l'on ne connaît pas, inventer des métriques, exagérer son rôle dans un projet d'équipe. Le jury est composé de professionnels qui détectent rapidement les incohérences.

14.8 Mauvaise gestion du temps

Passer 12 minutes sur le contexte de l'entreprise et 3 minutes sur la réalisation technique. Ou terminer en 8 minutes et n'avoir plus rien à dire.

14.9 Portfolio inaccessible le jour J

L'URL ne fonctionne plus, le serveur est en panne, le certificat SSL a expiré. Toujours vérifier l'accessibilité la veille et prévoir une copie locale.

14.10 Fautes d'orthographe massives

Un portfolio truffé de fautes donne une impression de négligence. Faire relire le portfolio par un tiers avant la soumission.

15. Grille d'évaluation décryptée

15.1 Structure de la grille

La grille d'évaluation officielle est organisée par compétences du bloc 2. Pour chaque compétence, le jury évalue le degré de maîtrise selon une échelle (généralement : non acquis, en cours d'acquisition, acquis, maîtrisé).

15.2 Ce que le jury note vraiment

La compréhension technique (poids fort)

Le candidat comprend-il ce qu'il a développé ? Peut-il expliquer le fonctionnement de son code, justifier ses choix, répondre à des questions techniques ? C'est le critère le plus discriminant.

Comment maximiser : connaître son code par coeur, être capable d'expliquer chaque choix technique, maîtriser les concepts sous-jacents (pas seulement la syntaxe).

La qualité des réalisations (poids fort)

Les réalisations sont-elles pertinentes, complètes, fonctionnelles ? Le code est-il propre et structuré ? Les bonnes pratiques sont-elles respectées ?

Comment maximiser : choisir des réalisations ambitieuses mais maîtrisées, montrer du code propre, appliquer les patterns et bonnes pratiques vus en cours.

La démarche de conception (poids moyen)

Le candidat a-t-il suivi une démarche structurée ? A-t-il modélisé avant de coder ? A-t-il documenté ses choix ?

Comment maximiser : inclure des diagrammes UML/Merise dans le portfolio, expliquer la démarche de conception lors de la présentation.

Le recul critique (poids moyen)

Le candidat est-il capable d'analyser ses propres réalisations avec lucidité ? Identifie-t-il les points d'amélioration ?

Comment maximiser : préparer un bilan honnête pour chaque réalisation, anticiper les questions sur les faiblesses de ses solutions.

La communication (poids moyen)

Le candidat s'exprime-t-il clairement ? La présentation est-elle structurée ? Le portfolio est-il bien rédigé ?

Comment maximiser : répéter la présentation, soigner la rédaction du portfolio, structurer ses réponses.

La couverture des compétences (poids moyen)

L'ensemble des réalisations couvre-t-il les compétences du bloc 2 ? Y a-t-il des lacunes ?

Comment maximiser : vérifier le tableau de synthèse, s'assurer qu'aucune compétence majeure n'est oubliée.

15.3 Stratégie de maximisation

Concentrer ses efforts sur la compréhension technique : c'est ce qui rapporte le plus de points.
Avoir au moins une réalisation très solide, avec démonstration fonctionnelle, code propre et conception documentée.
Préparer des réponses argumentées aux questions classiques (chapitre 11).
Montrer du recul critique spontanément, sans attendre que le jury le demande.
Soigner la forme : portfolio propre, présentation structurée, expression claire.

16. Planning de préparation

16.1 M-3 (trois mois avant l'épreuve)

Semaine 1 : Inventaire

Lister toutes les réalisations possibles (entreprise, formation, personnel).
Établir le tableau de synthèse (réalisations vs compétences).
Identifier les compétences non couvertes et planifier une réalisation complémentaire si nécessaire.
Choisir le format du portfolio (site web, GitBook, PDF).

Semaine 2-3 : Structure du portfolio

Créer la structure du portfolio (pages, navigation).
Rédiger la page d'accueil et la section parcours.
Commencer la documentation de la première réalisation.

Semaine 4 : Première réalisation documentée

Terminer la documentation complète de la première réalisation.
Inclure les diagrammes, les extraits de code, les captures d'écran.
Faire relire par un pair ou un enseignant.

16.2 M-2 (deux mois avant l'épreuve)

Semaine 5-6 : Réalisations suivantes

Documenter la deuxième et la troisième réalisation.
Préparer les diagrammes UML/Merise manquants.
Compléter les extraits de code significatifs.

Semaine 7-8 : Complétion du portfolio

Documenter les réalisations restantes.
Rédiger la section veille technologique.
Rédiger la section compétences.
Compléter le tableau de synthèse.
Rédiger les fiches descriptives de réalisation.

16.3 M-1 (un mois avant l'épreuve)

Semaine 9 : Relecture et correction

Relire l'intégralité du portfolio.
Corriger les fautes d'orthographe et les incohérences.
Faire relire par un enseignant.
Vérifier que tous les liens, images et diagrammes fonctionnent.

Semaine 10 : Préparation de la présentation

Rédiger le plan détaillé de la présentation orale (pas le texte, le plan).
Créer le diaporama si utilisé.
Préparer les scénarios de démonstration.
Installer et configurer l'environnement de démonstration.

Semaine 11 : Répétitions

Première répétition seul, chronométrée.
Deuxième répétition seul, en corrigeant les problèmes de timing.
Préparer les réponses aux questions classiques (chapitre 11).

Semaine 12 : Répétitions en conditions réelles

Répétition devant un public (camarades, enseignant).
Répétition avec l'ordinateur et le vidéoprojecteur.
Tester la démonstration technique de bout en bout.
Préparer le plan B (captures, vidéo).

16.4 Dernière semaine (S-1)

J-5 à J-3 :

Dernière relecture du portfolio.
Dernière répétition de la présentation.
Vérifier que l'URL du portfolio est accessible.
Charger le portfolio en local (copie de secours).

J-2 :

Préparer le matériel : ordinateur chargé, chargeur, adaptateur vidéo, clé USB de secours.
Vérifier que la démonstration fonctionne.
Relire les fiches descriptives.
Se coucher tôt.

J-1 :

Relire le plan de la présentation (pas tout le portfolio, juste le plan).
Vérifier une dernière fois le matériel.
Se détendre. Ne pas réviser jusqu'à minuit.

16.5 Le jour J

Arriver 30 minutes en avance.
Installer le matériel et tester l'affichage.
Lancer l'environnement de démonstration.
Vérifier le portfolio en ligne.
Respirer. Le travail de préparation est fait.

16.6 Checklist finale

17. Exemples de portfolios réussis

17.1 Exemple 1 : Portfolio site web statique (Hugo)

Structure :

/ (Page d'accueil)
  - Présentation en 3 phrases
  - Photo professionnelle
  - Navigation claire

/parcours
  - Formation BTS SIO SLAM
  - Stage chez [Entreprise] (6 mois)
  - Bref historique

/competences
  - Tableau compétences bloc 2
  - Technologies maîtrisées (organisées par catégorie)
  - Pas de barres de progression

/realisations
  /gestion-stock
    - Contexte détaillé
    - Diagramme de classes (image SVG)
    - Architecture MVC schématisée
    - 3 extraits de code commentés
    - Captures d'écran de l'application
    - Résultats et bilan
  /api-mobile
    - [même structure]
  /refonte-site
    - [même structure]
  /outil-monitoring
    - [même structure]
  /projet-personnel-bot
    - [même structure]

/veille
  - Méthodologie de veille
  - Sources listées avec liens
  - 2 articles analysés en détail
  - Tendance : adoption de TypeScript

/contact
  - Email professionnel
  - Lien GitHub

Points forts :

Navigation simple et rapide.
Chaque réalisation suit la même structure (cohérence).
Diagrammes intégrés directement dans les pages.
Code source du portfolio lui-même sur GitHub (démontre Git).
Site hébergé sur GitHub Pages (gratuit, fiable).

Points d'attention :

Le site est en lui-même une sixième réalisation à maîtriser.
Tester la compatibilité navigateur.

17.2 Exemple 2 : Portfolio GitBook

Structure :

Sommaire
  1. A propos
     1.1 Parcours
     1.2 Contact
  2. Compétences
     2.1 Tableau de synthèse
     2.2 Technologies
  3. Réalisations
     3.1 Réalisation 1 (titre explicite)
     3.2 Réalisation 2
     3.3 Réalisation 3
     3.4 Réalisation 4
  4. Veille technologique

Points forts :

Rapide à mettre en place.
Structure claire et navigable.
Recherche intégrée.
Versionnement via Git.

Points d'attention :

Moins personnalisé visuellement.
Ne démontre pas de compétence en développement web.

17.3 Ce qui distingue un bon portfolio

La profondeur de documentation de chaque réalisation (pas juste "j'ai fait un site web", mais le détail complet de la conception au bilan).
La présence de diagrammes techniques (UML, Merise, schémas d'architecture).
Des extraits de code pertinents et commentés (pas tout le code, les parties intéressantes).
Un bilan critique pour chaque réalisation.
Une veille technologique avec des exemples concrets et datés.
Zéro faute d'orthographe.
Une navigation fluide et un design professionnel (sobre, lisible).

18. Exercices et mises en situation

Exercice 1 : Rédiger une fiche descriptive

Consigne : Choisir l'un de vos projets (scolaire, personnel ou professionnel) et rédiger une fiche descriptive complète en suivant le format officiel décrit au chapitre 7.

Critères de réussite :

Toutes les rubriques sont complétées.
Le vocabulaire technique est précis.
Les compétences du référentiel sont correctement identifiées.
La fiche tient sur une à deux pages maximum.

Solution commentée :

Intitulé : Application web de gestion des absences
Période : Janvier 2026 - Mars 2026
Lieu : Stage - Société XYZ (éditeur de logiciels éducatifs)

Contexte : La société XYZ développe des solutions pour les
établissements scolaires. Le service de vie scolaire du lycée
partenaire utilisait un tableur Excel pour gérer les absences,
ce qui entraînait des erreurs de saisie et une perte de temps
considérable.

Objectif : Développer une application web permettant la saisie,
le suivi et le reporting des absences des élèves.

Environnement : PHP 8.2, Laravel 10, MySQL 8, Bootstrap 5,
PHPUnit, Git, VS Code, Docker (développement local).

Compétences : Concevoir une solution applicative, développer
des composants d'accès aux données, développer la présentation,
tester, documenter.

Modalités : Seul, sous la supervision du lead developer.
Méthodologie Kanban avec revue hebdomadaire.

Productions : Application fonctionnelle déployée sur le serveur
de test. Documentation technique (README, PHPDoc). Suite de
15 tests unitaires. Manuel utilisateur de 5 pages.

Exercice 2 : Préparer un plan de présentation

Consigne : À partir de la fiche descriptive de l'exercice 1, rédiger le plan détaillé d'une présentation de 10 minutes. Indiquer le timing de chaque partie.

Critères de réussite :

Le plan couvre les 10 minutes.
Chaque partie a une durée réaliste.
La démonstration est prévue.
Un plan B est mentionné.

Solution commentée :

1. Accroche et introduction (1 min)
   - Se présenter.
   - "Les personnels de vie scolaire perdent 2h par semaine
     à gérer les absences sur Excel. J'ai développé une
     application qui divise ce temps par quatre."

2. Contexte (2 min)
   - Présentation de l'entreprise (30 sec).
   - Description du problème (1 min).
   - Objectifs et contraintes (30 sec).

3. Conception (3 min)
   - Diagramme de cas d'utilisation (1 min).
   - MCD / diagramme de classes (1 min).
   - Architecture MVC avec Laravel (1 min).

4. Démonstration (5 min)
   - Connexion en tant que CPE.
   - Saisie d'absences pour une classe.
   - Consultation du tableau de bord.
   - Génération d'un rapport mensuel.
   - Montrer le code du calcul de statistiques.

   Plan B : captures d'écran dans le diaporama.

5. Bilan (3 min)
   - Résultats : application en test, retour positif du CPE.
   - Difficulté : gestion des emplois du temps variables.
   - Amélioration : ajout de notifications par SMS.
   - Compétences acquises : Laravel, tests, relation client.

6. Conclusion (1 min)
   - Ce projet m'a permis de mener un développement complet,
     de l'analyse du besoin au déploiement.
   - Ouverture vers la réalisation suivante (API mobile).

Exercice 3 : Répondre aux questions du jury

Consigne : Pour chacune des questions suivantes, rédiger une réponse structurée de 30 secondes à 1 minute.

"Pourquoi avoir choisi Laravel plutôt qu'un autre framework ?"
"Comment avez-vous géré la sécurité de l'authentification ?"
"Qu'est-ce qu'une migration de base de données ?"
"Comment testeriez-vous cette fonctionnalité ?"
"Quelles sont les limites de votre application ?"

Solutions commentées :

Question 1 : "J'ai choisi Laravel pour trois raisons principales. D'abord, le projet nécessitait un framework PHP car le serveur du client était configuré pour PHP. Ensuite, Laravel propose Eloquent, un ORM qui m'a permis de travailler avec la base de données de manière productive. Enfin, la documentation de Laravel est complète et la communauté active, ce qui m'a aidé à résoudre rapidement les problèmes rencontrés. J'ai aussi considéré Symfony, mais sa courbe d'apprentissage était plus raide pour la durée de mon stage."

Question 2 : "L'authentification est gérée par le système intégré de Laravel. Les mots de passe sont hachés avec bcrypt avant stockage en base. Les sessions utilisent un token CSRF vérifié sur chaque requête POST. J'ai ajouté une limitation du nombre de tentatives de connexion pour prévenir les attaques par force brute. Les routes protégées utilisent le middleware auth qui redirige les utilisateurs non connectés vers la page de connexion."

Question 3 : "Une migration est un fichier PHP qui décrit une modification de la structure de la base de données. Chaque migration contient une méthode up qui applique le changement (créer une table, ajouter une colonne) et une méthode down qui l'annule. Les migrations sont versionnées avec Git, ce qui permet à chaque développeur de l'équipe de mettre à jour sa base locale en exécutant les nouvelles migrations. C'est l'équivalent d'un système de contrôle de version pour la base de données."

Question 4 : "Pour tester la fonctionnalité de saisie d'absence, j'écrirais un test unitaire qui vérifie que le modèle Absence est correctement créé avec les bonnes données. Puis un test d'intégration qui envoie une requête HTTP POST au contrôleur et vérifie que l'absence est bien enregistrée en base de données. Je testerais aussi les cas d'erreur : saisie sans élève sélectionné, date invalide, utilisateur non autorisé. J'utiliserais PHPUnit avec la base de données de test que Laravel réinitialise entre chaque test."

Question 5 : "L'application a plusieurs limites. Elle ne gère pas les emplois du temps variables : si un cours est déplacé, l'absence est associée au créneau initial. L'interface n'est pas responsive, ce qui la rend peu pratique sur mobile. Les performances n'ont pas été testées avec un grand volume de données : avec plusieurs années d'historique, les requêtes de reporting pourraient devenir lentes. Enfin, l'application ne propose pas de notifications en temps réel aux parents."

Exercice 4 : Analyser un portfolio

Consigne : Voici la description d'un portfolio fictif. Identifier les forces et les faiblesses.

Portfolio de Jean D. :

Page d'accueil avec nom, photo, lien vers CV PDF.
Section "Mes projets" avec 2 projets :
- Projet 1 : "Site web pour une pizzeria" - capture d'écran de la page d'accueil, mention "HTML/CSS/JavaScript".
- Projet 2 : "Application Java" - description de 3 lignes, pas de capture d'écran.
Pas de section compétences.
Pas de section veille technologique.
Pas de diagramme.
Portfolio hébergé sur un serveur gratuit avec publicités.

Solution :

Forces :

Le portfolio existe (c'est un début).
Il y a un effort de présentation sur la page d'accueil.

Faiblesses (critiques) :

Seulement 2 réalisations : couverture des compétences insuffisante.
Documentation quasi inexistante : pas de contexte, pas de conception, pas de code, pas de bilan.
Pas de section compétences : le jury ne peut pas évaluer la couverture du référentiel.
Pas de veille technologique : compétence non démontrée.
Pas de diagramme UML/Merise : la compétence de conception n'est pas illustrée.
Hébergement avec publicités : impression d'amateurisme.
Le deuxième projet n'a même pas de capture d'écran.

Recommandations :

Ajouter au moins 2 à 4 réalisations supplémentaires.
Documenter chaque réalisation en suivant la structure du chapitre 6.
Ajouter des diagrammes de conception.
Créer la section veille technologique.
Migrer vers un hébergement sans publicité (GitHub Pages est gratuit).

Exercice 5 : Préparer une démonstration

Consigne : Choisir un de vos projets et rédiger un scénario de démonstration de 5 minutes. Inclure un plan B.

Critères de réussite :

Le scénario suit un fil conducteur logique (pas une succession de clics aléatoires).
Les fonctionnalités clés sont montrées.
Un passage par le code est prévu.
Le plan B est concret et réalisable.

Solution commentée :

Projet : Application de gestion de stock

Scénario principal (5 min) :

1. Ouvrir l'application dans le navigateur (déjà lancée).
   Montrer la page de connexion. (15 sec)

2. Se connecter en tant qu'administrateur.
   Montrer le tableau de bord : nombre de produits,
   alertes de stock bas, graphique des mouvements. (45 sec)

3. Naviguer vers la liste des produits.
   Filtrer par catégorie. Montrer la pagination. (30 sec)

4. Ajouter un nouveau produit avec photo.
   Remplir le formulaire, valider,
   montrer le message de confirmation. (45 sec)

5. Simuler une commande qui décrémente le stock.
   Montrer le stock avant, passer la commande,
   montrer le stock après. (45 sec)

6. Montrer le code du service de gestion de stock.
   Ouvrir VS Code sur StockService.php.
   Expliquer la méthode decrementStock()
   et la gestion de la transaction SQL. (1 min)

7. Montrer un test unitaire du service.
   Lancer le test en terminal.
   Montrer le résultat vert. (30 sec)

8. Revenir sur le tableau de bord.
   Montrer que l'alerte de stock bas est apparue
   pour le produit commandé. (30 sec)

Plan B :
- 8 captures d'écran correspondant aux étapes ci-dessus,
  intégrées dans le diaporama après la slide "Démonstration".
- Vidéo de 2 minutes pré-enregistrée sur clé USB.
- Code source ouvert dans VS Code hors connexion.

Exercice 6 : Rédiger un bilan critique

Consigne : Rédiger le bilan critique d'un projet que vous avez réalisé. Le bilan doit comporter : réussites, difficultés, solutions apportées, points d'amélioration et compétences acquises.

Critères de réussite :

Le bilan est honnête (pas uniquement positif).
Les difficultés sont concrètes et les solutions réelles.
Les points d'amélioration montrent un recul technique.
Les compétences acquises sont en lien avec le référentiel.

Solution commentée :

Bilan de la réalisation : Application de gestion des absences

Réussites :
- L'application a été livrée dans les délais (8 semaines).
- Le CPE l'a testée pendant 2 semaines et a validé
  les fonctionnalités principales.
- La saisie des absences prend désormais 30 secondes
  au lieu de 3 minutes par classe.

Difficultés rencontrées :
- La modélisation des emplois du temps a été complexe
  car les créneaux varient selon les semaines paires/impaires.
  J'ai dû reprendre mon MCD deux fois avant de trouver
  une structure adaptée.
- L'intégration de la génération PDF (librairie DomPDF)
  a posé des problèmes de mise en page. J'ai passé
  une journée entière à déboguer un problème d'encodage
  des caractères accentués.

Solutions apportées :
- Pour les emplois du temps, j'ai créé une table
  de liaison avec un champ "semaine_type" (A/B) qui
  permet de gérer les alternances.
- Pour le PDF, j'ai configuré les polices UTF-8
  dans DomPDF et créé un template Blade dédié
  à la génération PDF.

Points d'amélioration :
- L'interface n'est pas responsive. Avec plus de temps,
  j'aurais utilisé les breakpoints Bootstrap pour
  adapter l'affichage sur tablette.
- Les tests ne couvrent que 40% du code. J'aurais dû
  écrire les tests en parallèle du développement
  et non à la fin.
- Le déploiement est manuel (FTP). Un pipeline CI/CD
  avec GitHub Actions aurait automatisé le processus.

Compétences acquises :
- Conception de base de données complexe (Merise).
- Développement full-stack avec Laravel.
- Gestion d'un projet en autonomie avec reporting
  hebdomadaire au tuteur.
- Relation avec l'utilisateur final (recueil de besoins,
  démonstrations intermédiaires, ajustements).

Exercice 7 : Simuler un entretien complet

Consigne : Demander à un camarade ou un enseignant de jouer le rôle du jury pendant 30 minutes. Lui fournir la liste de questions ci-dessous (il peut en ajouter). Après l'entretien, demander un retour sur les points forts et les points faibles.

Liste de questions pour le jury simulé :

Présentez-vous brièvement.
Pourquoi avez-vous choisi cette réalisation à présenter ?
Expliquez-moi l'architecture de votre application.
Pourquoi avoir choisi [technologie X] ?
Montrez-moi le code qui gère [fonctionnalité Y].
Comment avez-vous testé votre application ?
Quelles difficultés avez-vous rencontrées ?
Comment gérez-vous la sécurité ?
Si vous deviez refaire ce projet, que changeriez-vous ?
Comment votre application gère-t-elle les erreurs ?
Qu'est-ce qu'une API REST ?
Expliquez-moi le concept d'ORM.
Comment avez-vous organisé votre travail ?
Parlez-moi de votre veille technologique.
Quels sont vos projets professionnels après le BTS ?

Grille d'évaluation pour le jury simulé :

Clarté de l'expression (1-5).
Précision technique (1-5).
Capacité à justifier ses choix (1-5).
Recul critique (1-5).
Gestion du stress (1-5).
Honnêteté face aux questions difficiles (1-5).

Exercice 8 : Construire le tableau de synthèse

Consigne : Lister vos réalisations et créer le tableau de synthèse qui met en correspondance chaque réalisation avec les compétences du bloc 2.

Modèle :

Compétences du bloc 2 SLAM :
C1 - Concevoir une solution applicative
C2 - Développer des composants d'accès aux données
C3 - Développer la présentation (interface utilisateur)
C4 - Mettre à disposition / déployer une solution applicative
C5 - Tester une solution applicative
C6 - Maintenir / faire évoluer une solution applicative
C7 - Documenter une solution applicative

Tableau :

| Réalisation          | C1 | C2 | C3 | C4 | C5 | C6 | C7 |
|----------------------|----|----|----|----|----|----|-----|
| Réalisation 1        |    |    |    |    |    |    |     |
| Réalisation 2        |    |    |    |    |    |    |     |
| Réalisation 3        |    |    |    |    |    |    |     |
| Réalisation 4        |    |    |    |    |    |    |     |
| Réalisation 5        |    |    |    |    |    |    |     |

Critère de réussite : Chaque colonne contient au moins un X. Chaque ligne contient au moins deux X.

Exercice 9 : Expliquer du code à voix haute

Consigne : Ouvrir le code d'un de vos projets. Choisir un fichier au hasard. Expliquer à voix haute, pendant 3 minutes, ce que fait ce code, ligne par ligne, en justifiant les choix.

Objectif : S'entraîner à l'exercice le plus redouté de l'épreuve E5 : expliquer du code que le jury pointe au hasard.

Méthode :

Lire le nom du fichier, de la classe, de la fonction.
Expliquer le rôle de ce fichier dans l'architecture globale.
Parcourir le code de haut en bas.
Pour chaque bloc logique, expliquer : ce qu'il fait, pourquoi, comment.
Identifier les points techniques intéressants (pattern, optimisation, gestion d'erreur).

Critère de réussite : Pouvoir expliquer n'importe quel fichier de son projet sans hésitation. Si un fichier pose problème, c'est le signal qu'il faut le réétudier.

Exercice 10 : Préparer la veille technologique

Consigne : Mettre en place une routine de veille et rédiger la section veille technologique du portfolio.

Étapes :

Créer un compte sur Feedly (ou équivalent).
S'abonner à au moins 5 flux RSS en rapport avec les technologies utilisées dans ses projets.
Suivre au moins 5 comptes techniques sur Twitter/X ou LinkedIn.
Pendant 2 semaines, lire au moins un article technique par jour.
Sélectionner 2 articles particulièrement intéressants.
Pour chacun, rédiger un paragraphe de synthèse : de quoi parle l'article, en quoi c'est pertinent pour le développement, comment cela pourrait s'appliquer à un de ses projets.
Intégrer ces éléments dans la section veille du portfolio.

Critère de réussite : Pouvoir répondre spontanément à la question "Parlez-moi de votre veille technologique" avec des exemples concrets, datés et argumentés.

Exercice 11 : Gérer une panne de démonstration

Consigne : Simuler une panne pendant une démonstration. Un camarade ferme l'application ou coupe le serveur au milieu de la démo. S'entraîner à basculer sur le plan B sans perdre son sang-froid.

Objectif : Automatiser la réaction face à une panne. Le jour J, le réflexe doit être naturel.

Déroulement :

Commencer la démonstration normalement.
Le camarade provoque une panne à un moment aléatoire.
Le candidat bascule sur le plan B (captures d'écran, vidéo, code source).
Le candidat continue la présentation sans interruption visible.

Critère de réussite : La transition vers le plan B prend moins de 15 secondes. Le candidat reste calme et professionnel.

Exercice 12 : Oral blanc complet

Consigne : Réaliser un oral blanc de 40 minutes dans les conditions réelles de l'examen.

Organisation :

Trouver un jury de deux personnes (enseignants ou camarades sérieux).
Réserver une salle avec vidéoprojecteur.
Transmettre le portfolio et les fiches descriptives au jury 48 heures avant.
Chronométrer strictement (10 minutes de présentation + 30 minutes d'entretien).
Le jury doit couper la présentation à 10 minutes même si le candidat n'a pas fini.

Après l'oral blanc :

Demander un retour détaillé au jury.
Identifier les trois points d'amélioration principaux.
Planifier un second oral blanc une semaine plus tard pour vérifier la progression.

Critère de réussite : Terminer la présentation dans le temps imparti, répondre à au moins 80% des questions sans hésitation, recevoir un retour globalement positif du jury.

Conclusion

L'épreuve E5 se prépare sur plusieurs mois, pas la veille. La clé du succès tient en trois piliers : un portfolio solide et bien documenté, une présentation orale répétée et maîtrisée, et une compréhension technique profonde de chaque réalisation présentée.

Le candidat qui connaît son code, qui sait justifier ses choix et qui est capable de prendre du recul sur son travail a toutes les chances de réussir cette épreuve.

La préparation technique ne suffit pas : la communication est essentielle. Un excellent développeur qui ne sait pas s'exprimer obtiendra un résultat moyen. Un développeur correct qui communique clairement, qui structure son propos et qui démontre sa capacité d'analyse obtiendra un excellent résultat.

Commencer tôt. Travailler régulièrement. Répéter sans relâche. Le jour J n'est que la dernière étape d'un travail de fond.