Phase 2 : réaliser la solution en une heure

La phase 2 de l'E6 SLAM commence par une heure de préparation pendant laquelle tu réalises, seul et en autonomie, la solution que tu as présentée à la commission, ajustement compris. Tu travailles sur ton environnement, sous ta responsabilité, « dans le respect des consignes de sécurité, de sauvegarde des données et des ressources utilisées ». Ce chapitre organise cette heure pour qu'à la fin, quelque chose fonctionne, soit testé et puisse être prouvé pendant la recette.

L'heure en cinq blocs

Ces durées sont un repère. L'ordre, lui, ne se discute pas : le vital avant le confort, et du temps gardé pour les tests et la documentation.

Les cinq premières minutes

Ne code pas tout de suite. Ces gestes t'évitent les pires surprises de l'heure.

1. Relis le verso de l'expression des besoins et corrige ton plan si un ajustement a été demandé.
2. Lance l'application et les tests existants. Tout doit être vert avant que tu touches au code : sinon, tu ne sauras pas si c'est toi qui as cassé quelque chose.
3. Sauvegarde la base si tu vas la modifier : mysqldump -u root -p frais > avant-e6.sql. Une migration ratée se répare en une commande.
4. Vérifie que ton dépôt est propre avec git status, et crée une branche pour l'évolution : git switch -c e6-renvoi.

Le vital avant le confort

Le vital, c'est le plus court chemin vers une solution qui répond au besoin de bout en bout et que la commission peut vérifier. Le confort, c'est tout ce qui l'améliore : l'écran soigné, les messages d'erreur détaillés, la pagination. Pour classer un élément, pose-toi une question : sans lui, la commission peut-elle constater que le besoin est rempli ? Si non, c'est du vital.

Une règle de sécurité demandée par le sujet, comme « seul un comptable peut… », fait toujours partie du vital : sans elle, la solution ne répond pas à la demande.

Avancer par petits pas testés

Ne code pas quarante minutes avant de tester. Écris cinq à dix lignes, vérifie, puis continue. Un bug ne peut venir que de ce que tu viens d'écrire, et tu le trouves en une minute au lieu de quinze.

Quand une erreur apparaît, lis-la avant de chercher. La première ligne dit quoi (TypeError: Cannot read properties of undefined (reading 'motif')), la première ligne de la pile qui cite ton fichier dit où (controllers/notes.js:42:31). Les lignes qui citent node_modules ne sont pas ton code.

Git, ton filet de sécurité

Un commit après chaque étape qui marche. Si la suivante casse tout, tu reviens en arrière en quelques secondes.

git add -A
git commit -m "renvoi : table renvoi et migration"
# … une tentative qui casse tout …
git restore .              # annule les modifications non commitées
git log --oneline          # l'historique raconte ta démarche

git restore . jette toutes les modifications depuis le dernier commit : vérifie avec git status ce que tu vas perdre avant de la lancer. Tes messages de commit servent aussi pendant la recette : git log --oneline montre à la commission que tu as travaillé par étapes testées. Le cours Git et GitHub détaille ces commandes.

La documentation demandée

L'expression des besoins indique la documentation à présenter « en appui de la solution » : rapport de test, documentation technique, rapport d'incident ou documentation utilisateur. Elle fait partie de la production attendue. Prévois dix minutes et un modèle prêt dans ton dépôt.

Un rapport de test court, mais rempli avec de vrais résultats, vaut mieux qu'un rapport long qui décrit des tests jamais lancés. Un exemple complet figure dans l'épreuve blanche n° 1.

Quand tu bloques

Fixe-toi une règle : quinze minutes sans progrès sur un point, tu changes d'approche.

• Simplifie : la version la plus simple qui répond au besoin (un calcul en JavaScript au lieu d'un pipeline d'agrégation, une requête au lieu d'une procédure).
• Contourne : passe au point suivant du vital et reviens plus tard.
• Laisse une trace : un commentaire // À FAIRE : … qui dit ce qui manque et comment tu le ferais. Tu t'en serviras à la recette.

Un blocage expliqué pendant la recette rapporte plus qu'un silence. La commission évalue aussi ta démarche, pas seulement le résultat.

Les cinq dernières minutes

Arrête de coder. Prépare la recette :

• les données de démonstration en base (une note clôturée à renvoyer, un compte de chaque rôle) ;
• les commandes curl ou les requêtes Postman enregistrées, dans l'ordre où tu vas les montrer ;
• les tests lancés une dernière fois, leur sortie visible dans un terminal ;
• une note de trois lignes : ce qui marche, ce qui manque, comment tu le finirais.

Le chapitre la recette et l'entretien d'explicitation montre comment présenter tout cela.

Exercice