Phase 1 : analyser l'expression des besoins

L'expression des besoins est le document que la commission te remet au début de l'épreuve E6 : elle décrit une évolution ou une correction à apporter à l'une de tes deux réalisations. Tu as 30 minutes de préparation pour l'analyser avant l'entretien de la phase 1. Ce chapitre montre comment lire ce document, trouver ce qu'il ne dit pas, rédiger tes spécifications techniques et choisir tes outils dans le temps imparti.

Le modèle officiel de l'expression des besoins

La circulaire propose à la commission un modèle de document. Il n'est pas obligatoire : ta commission peut présenter son sujet autrement, mais elle répondra aux mêmes questions. Chaque rubrique en traite une.

Ne néglige pas la dernière rubrique du recto. Si la commission coche « rapport de test », un code qui marche sans rapport ne remplit pas la production attendue.

Les conditions de la préparation

Tu prépares sur table, avec un ordinateur qui sert à consulter des ressources et, si tu le souhaites, à rédiger un document. Selon l'organisation du centre, tu y ouvres ta documentation, ton dépôt, la documentation officielle de tes outils. Tu ne réalises pas encore : la commission n'a pas validé ta démarche et elle peut te demander de l'ajuster. Garde tes 30 minutes pour penser.

Les 30 minutes, minute par minute

Qualifier la demande en quatre questions

Avant d'entrer dans les détails, réponds à quatre questions. Elles tiennent en cinq lignes et structurent tout le reste.

Trouver l'implicite : la grille des six axes

Un besoin a deux couches. L'explicite est écrit. L'implicite est ce qu'il faut décider pour que la solution tienne debout, et c'est là que la commission pose ses questions. Passe chaque besoin à ces six axes.

Tu n'auras pas une réponse sur chaque axe, mais tu dois tous les passer. Chaque ligne remplie est une question de la commission à laquelle tu as déjà répondu.

Lever une ambiguïté proprement

Quand un implicite n'a pas de réponse évidente, c'est une ambiguïté. Ne la cache pas et ne la tranche pas en silence. Formule ton hypothèse et son coût :

« Le besoin ne précise pas X. Je retiens Y, parce que Z. Si vous préférez W, il faudrait en plus… »

La commission peut confirmer, ou choisir l'autre option : c'est exactement à cela que sert l'ajustement de fin d'entretien. Une hypothèse annoncée qui se révèle fausse ne te coûte rien. Une hypothèse cachée qui se révèle fausse te coûte ta phase 2.

Écrire les spécifications techniques

L'entretien te demande de « proposer des spécifications techniques ». Ce n'est pas du code : c'est la description précise de ce que tu vas construire. Pour chaque élément, note :

• l'élément : route, écran, table, colonne, procédure, classe ;
• les entrées et les sorties : paramètres, corps de requête, réponse, codes HTTP ;
• les règles : contrôles, droits, transitions d'état autorisées ;
• les fichiers touchés : avec leur chemin réel dans ton projet ;
• les tests prévus : le cas nominal et deux cas d'erreur au moins.

Un diagramme rapide aide souvent plus qu'un paragraphe : un diagramme de séquence pour l'échange entre l'écran, l'API et la base, ou un diagramme d'états-transitions quand la demande touche au cycle de vie d'un objet (une note qui passe de « saisie » à « clôturée »).

Choisir les outils

Le texte parle du « choix des outils les plus adaptés pour la réalisation attendue ». Le meilleur outil est presque toujours celui que ton projet utilise déjà : ton framework, ta bibliothèque d'accès aux données, ton outil de test. Un nouvel outil le jour de l'épreuve, c'est une installation, une configuration et un risque. Si tu en proposes un, justifie-le par le besoin et prévois une solution sans lui.

Ce que ta feuille contient à la fin des 30 minutes

1. La reformulation en une phrase.
2. Les quatre questions et la grille des six axes, avec les hypothèses.
3. La fiche de spécification : éléments, entrées et sorties, règles, fichiers, tests.
4. Les outils et leur justification.
5. Le découpage vital et confort, et le plan minuté de la phase 2.
6. Un schéma du flux et tes trois phrases d'ouverture.

Pas une ligne de code soignée : une feuille qui fait que la suite s'enchaîne sans panique. Le chapitre l'entretien de phase 1 montre comment la présenter.

Exercice corrigé : la notification de clôture

Exercice Analyser une expression des besoins en 30 minutes Réussi À revoir

Réalisation retenue : Sorbier Frais, application web de notes de frais (API Express, front React, base MySQL). Une note passe par quatre états : saisie, cloturee, validee, remboursee. Le salarié clôt sa note par la route existante PATCH /api/notes/:id/cloture.

Circonstances. Le service comptable découvre les notes clôturées en ouvrant la liste, parfois une semaine plus tard. Les salariés se plaignent des délais de remboursement.

Spécifications fonctionnelles. Les comptables doivent être prévenus dans l'application quand une note est clôturée, et retrouver la liste des notes à traiter.

Production attendue. L'évolution de l'API et de la base. L'affichage dans le front si le temps le permet.

Documentation à présenter. Documentation technique de l'évolution.

Produis ta feuille de préparation : reformulation, quatre questions, grille des six axes avec au moins une ambiguïté, spécifications techniques, outils, découpage vital et confort.

Voir la réponseMasquer la réponse de l'exercice

Reformulation. « Quand un salarié clôt sa note, l'application crée une notification visible par les comptables, qui retrouvent la liste des notes clôturées non encore traitées. »

Les quatre questions.

Question	Réponse
Quoi ?	une notification créée à la clôture, une route qui liste les notifications non lues
Où ?	la table notification (nouvelle), controllers/notes.js (fonction cloturerNote), routes/notifications.js et controllers/notifications.js (nouveaux), le middleware requireRole existant
Quel impact ?	une ligne ajoutée dans la clôture, dans la même transaction ; aucune route existante ne change de comportement
Quelles compétences ?	concevoir et développer (nouvelle route), gérer les données (nouvelle table)

La grille des six axes.

Axe	Explicite	Implicite et décision
Canal	« dans l'application »	une notification stockée en base et un compteur dans le front ; pas d'email
Déclencheur	« quand une note est clôturée »	au passage de saisie à cloturee, dans la route de clôture
Acteurs	« les comptables »	seuls les comptables lisent les notifications ; le salarié n'y a pas accès
Cas limites	rien	une note renvoyée puis clôturée à nouveau crée une seconde notification ; une note déjà clôturée ne doit pas en créer une de plus
Données	rien	numéro de note, salarié, mois, date de clôture ; « lue » ou non
Sécurité	rien	une notification révèle le nom du salarié et son mois : route réservée au rôle comptable

Ambiguïté. « Le besoin ne dit pas si "lue" est propre à chaque comptable. Je retiens un état commun au service : dès qu'un comptable a ouvert la notification, elle est traitée pour tous, parce que les trois comptables se répartissent les notes. Si vous voulez un suivi par comptable, il faut une table de lecture en plus, notification_lecture (id_notification, id_comptable). »

Spécifications techniques.

• Table notification : id_notification (clé primaire), id_note (clé étrangère vers note_frais), date_creation DATETIME DEFAULT CURRENT_TIMESTAMP, lue BOOLEAN NOT NULL DEFAULT FALSE.
• Dans cloturerNote : après le UPDATE de l'état, un INSERT INTO notification, dans la même transaction, pour ne jamais avoir une note clôturée sans notification.
• GET /api/notifications : réservé aux comptables (401 sans jeton, 403 pour un salarié), renvoie 200 avec la liste des notifications non lues, jointe à la note et au salarié, triée de la plus ancienne à la plus récente. Liste vide : 200 et [].
• PATCH /api/notifications/:id/lue : réservé aux comptables, 200 si la notification existe, 404 sinon.
• Tests : comptable reçoit la liste (200), salarié refusé (403), une clôture crée exactement une notification.

Outils. Ceux du projet : Express, mysql2, Vitest et supertest déjà configurés, Postman pour la démonstration. Rien à installer.

Vital et confort.

Vital	Confort
table notification et script de migration	compteur dans l'en-tête du front
insertion à la clôture, dans la transaction	route PATCH …/lue
route GET /api/notifications protégée	tri et pagination
deux tests automatisés, documentation technique	email, plus tard

Alternative écartée. Un email par clôture : il demande un serveur SMTP configuré et ne se démontre pas en une heure. La notification en base répond au besoin, se teste avec un simple GET et pourra déclencher un email dans une version suivante.

Tu avais trouvé ?

Oui, j'avais bonPas encore