Épreuve blanche E6 n° 1 : renvoyer une note de frais

1. Reformulation. « Un comptable doit pouvoir renvoyer à son auteur une note clôturée, avec un motif obligatoire ; la note repasse en saisie, le salarié voit le motif, corrige et clôt à nouveau. »

2. Les quatre questions.

3. La grille des six axes.

Les deux implicites que le sujet n'écrit pas : la date de clôture à effacer, et le renvoi simultané par deux comptables.

Ambiguïté, telle que tu la dis. « Le besoin demande le motif du dernier renvoi. Je retiens une colonne motif_renvoi sur la note, qui garde le dernier motif : c'est le plus simple et cela répond à la demande. Si vous voulez l'historique de tous les renvois, il faut une table renvoi, avec la date et le comptable, et une transaction pour écrire dans les deux tables. »

4. Spécifications techniques.

• Base : ALTER TABLE note_frais ADD COLUMN motif_renvoi VARCHAR(500) NULL; (facultative : les notes existantes n'en ont pas).
• Route : PATCH /api/notes/:id/renvoi, middlewares requireAuth puis requireRole('comptable'). Corps : { "motif": "…" }.
• Effet : etat = 'saisie', date_cloture = NULL, motif_renvoi = motif, en une seule requête UPDATE … WHERE id_note = ? AND etat = 'cloturee'. Si aucune ligne n'est modifiée, une lecture de l'état distingue 404 et 409.
• Codes : 200 avec la note, 400 motif invalide, 401 sans jeton, 403 salarié, 404 note absente, 409 note non clôturée.
• Lecture : GET /api/notes/:id renvoie aussi motif_renvoi.
• Tests : supertest pour 401, 403 et 400 ; curl pour 404, 409 et le cas nominal ; résultats dans le rapport de test.

5. Outils. Ceux du projet : Express 5, mysql2, Vitest et supertest, curl et le client MySQL. Aucune installation.

6. Vital, confort et plan.

Plan : 0 à 5, relire et sauvegarder la base ; 5 à 12, migration ; 12 à 30, route et contrôles testés avec curl ; 30 à 38, motif dans la lecture ; 38 à 48, tests ; 48 à 55, rapport ; 55 à 60, préparer la recette.

1. « La note n'est plus clôturée : garder la date serait faux. Les listes et les statistiques par date de clôture la compteraient dans le mois de sa première clôture. Quand le salarié la clôturera de nouveau, la route existante enregistrera la nouvelle date. »
2. « Ma requête modifie la note seulement si elle est encore cloturee, et MySQL exécute ce UPDATE de façon atomique. Le premier renvoi passe ; le second ne modifie aucune ligne, ma route relit l'état, trouve saisie et répond 409. Aucun renvoi en double. »
3. « La requête est bien formée et la note existe : ce n'est ni un 400 ni un 404. C'est l'état actuel de la ressource qui interdit l'opération, ce que signale 409 Conflict. Le message indique l'état actuel pour que le comptable comprenne. »
4. « Non. Seule la route de renvoi écrit le motif, et elle est réservée aux comptables. Le salarié le lit par la route de détail, qui vérifie déjà qu'il est propriétaire de la note. »
5. « Pour la demande telle qu'elle est écrite, oui : le salarié voit le dernier motif. Mais une colonne efface le motif précédent à chaque renvoi : si le service veut savoir combien de fois une note a été renvoyée et par qui, il faut une table. Je peux faire l'un ou l'autre dans l'heure. »
6. « Je relance les 31 tests existants après chaque étape, en particulier ceux de la clôture et de la validation. J'ajoute trois tests pour la nouvelle route, et je vérifie à la main qu'une note renvoyée peut être clôturée de nouveau. »

1. Le plan corrigé. La colonne devient une table renvoi. Le renvoi écrit maintenant dans deux tables : il faut une transaction. L'UPDATE conditionnel ne suffit plus pour distinguer les cas avant d'insérer, on verrouille la note avec SELECT … FOR UPDATE.

2. La migration.

-- migrations/2027-04-renvoi.sql
CREATE TABLE renvoi (
  id_renvoi    INT AUTO_INCREMENT PRIMARY KEY,
  id_note      INT          NOT NULL,
  id_comptable INT          NOT NULL,
  date_renvoi  DATETIME     NOT NULL DEFAULT CURRENT_TIMESTAMP,
  motif        VARCHAR(500) NOT NULL,
  CONSTRAINT ck_renvoi_motif CHECK (CHAR_LENGTH(motif) >= 10),
  CONSTRAINT fk_renvoi_note FOREIGN KEY (id_note) REFERENCES note_frais (id_note),
  CONSTRAINT fk_renvoi_comptable FOREIGN KEY (id_comptable) REFERENCES utilisateur (id_utilisateur)
);
-- Annulation : DROP TABLE renvoi;

3. La route et le contrôleur.

// routes/notes.js
router.patch('/:id/renvoi', requireAuth, requireRole('comptable'), renvoyerNote);

// controllers/notes.js
const MOTIF_MIN = 10;
const MOTIF_MAX = 500;

export async function renvoyerNote(req, res) {
  const idNote = Number(req.params.id);
  const motif = typeof req.body?.motif === 'string' ? req.body.motif.trim() : '';
  if (!Number.isInteger(idNote)) return res.status(400).json({ erreur: 'Identifiant de note invalide' });
  if (motif.length < MOTIF_MIN || motif.length > MOTIF_MAX) {
    return res.status(400).json({ erreur: `Le motif doit faire entre ${MOTIF_MIN} et ${MOTIF_MAX} caractères` });
  }

  const conn = await pool.getConnection();
  try {
    await conn.beginTransaction();
    // FOR UPDATE verrouille la note : un second renvoi simultané attend la fin de celui-ci.
    const [notes] = await conn.execute('SELECT etat FROM note_frais WHERE id_note = ? FOR UPDATE', [idNote]);
    if (notes.length === 0) {
      await conn.rollback();
      return res.status(404).json({ erreur: 'Note introuvable' });
    }
    if (notes[0].etat !== 'cloturee') {
      await conn.rollback();
      return res.status(409).json({ erreur: `Seule une note clôturée peut être renvoyée (état actuel : ${notes[0].etat})` });
    }
    await conn.execute("UPDATE note_frais SET etat = 'saisie', date_cloture = NULL WHERE id_note = ?", [idNote]);
    await conn.execute('INSERT INTO renvoi (id_note, id_comptable, motif) VALUES (?, ?, ?)', [idNote, req.user.id, motif]);
    await conn.commit();
    res.json({ id_note: idNote, etat: 'saisie', motif });
  } catch (err) {
    await conn.rollback();
    throw err; // Express 5 transmet l'erreur au middleware d'erreur : réponse 500
  } finally {
    conn.release();
  }
}

4. La lecture du dernier motif, dans la requête de lireNote (le contrôle de propriété ne change pas) :

SELECT n.id_note, n.id_utilisateur, n.mois, n.etat, n.montant_valide,
       (SELECT r.motif FROM renvoi r
         WHERE r.id_note = n.id_note
         ORDER BY r.date_renvoi DESC, r.id_renvoi DESC
         LIMIT 1) AS dernier_motif
  FROM note_frais n
 WHERE n.id_note = ?

Le second critère de tri départage deux renvois dans la même seconde.

5. Les tests.

// tests/renvoi.test.js
import jwt from 'jsonwebtoken';
import request from 'supertest';
import { expect, test } from 'vitest';
import { app } from '../app.js';

const jeton = (role) => jwt.sign({ id: 3, role }, process.env.JWT_SECRET, { expiresIn: '5m' });
const renvoyer = (role, corps) =>
  request(app).patch('/api/notes/41/renvoi').set('Authorization', `Bearer ${jeton(role)}`).send(corps);

test('sans jeton : 401', async () => {
  const res = await request(app).patch('/api/notes/41/renvoi').send({ motif: 'Ticket illisible.' });
  expect(res.status).toBe(401);
});

test('un salarié ne peut pas renvoyer : 403', async () => {
  expect((await renvoyer('salarie', { motif: 'Ticket illisible.' })).status).toBe(403);
});

test('un motif trop court est refusé : 400', async () => {
  expect((await renvoyer('comptable', { motif: 'flou' })).status).toBe(400);
});

6. Le rapport de test.

Tests 1 à 3 automatisés ; tests 4 à 7 faits avec curl et le client MySQL.

7. L'historique.

$ git log --oneline
a41c2e9 renvoi : tests et rapport de test
7f03b1d renvoi : dernier motif dans le détail d'une note
2c9e8a4 renvoi : route PATCH /api/notes/:id/renvoi
9b1d6f0 renvoi : table renvoi (migration)

Le bouton du front n'est pas fait : c'était du confort, et le vital, les tests et le rapport ont pris l'heure.

1. Le déroulé.

2. Les réponses.

• FOR UPDATE. « La transaction garantit que les deux écritures sont faites ensemble ou pas du tout, mais elle n'empêche pas deux comptables de lire en même temps l'état cloturee et de renvoyer tous les deux. FOR UPDATE verrouille la ligne de la note : le second attend la fin du premier, puis lit saisie et reçoit 409. »
• La contrainte CHECK. « La route n'est pas le seul chemin vers la base : un script de reprise ou une autre application peuvent écrire dans renvoi. La contrainte est le dernier rempart. MySQL applique les contraintes CHECK depuis la version 8.0.16. »
• La sous-requête. « Elle renvoie une seule valeur par note, le motif le plus récent, sans changer le reste de la requête de détail. Une jointure sur renvoi donnerait une ligne par renvoi. Le second critère de tri départage deux renvois dans la même seconde. »
• L'affichage. « GET /api/notes/:id renvoie déjà dernier_motif. Dans NoteDetail.jsx, j'afficherais un encadré quand la note est en saisie et que dernier_motif n'est pas vide. React échappe le texte, donc un motif qui contiendrait du HTML s'afficherait tel quel, sans être exécuté. »