@nodefony/framework 10.0.0-beta.5 → 10.0.0-beta.7

package/docs/controller.md

@@ -404,31 +404,111 @@ class MeController extends Controller {
 ## 🧰 Répondre — ce que ton `return` déclenche
 
 Le traducteur unique est `Resolver.returnController()` (`Resolver.ts#Resolver.returnController`). Il regarde le **type**
-de ce que tu as retourné :
+de ce que tu as retourné — dans l'ordre de fréquence : la promesse, puis le tableau et l'objet simple,
+le cas courant, qui ne paient aucun test de plus que nécessaire (`Resolver.ts#Resolver.returnObject`) :
 
 <!-- prettier-ignore -->
 | Tu retournes… | Ce qui se passe | Ancre |
 | --- | --- | --- |
-| Une `Promise` / un thenable | Déballée puis re-traitée (récursif) | `Resolver.ts#Resolver._areaSecurity` |
-| Une `string` | Envoyée telle quelle en corps | `Resolver.ts#Resolver._callWithIdempotency` |
-| Un objet simple ou un tableau | **Auto-JSON** : `application/json` + sérialisation | `Resolver.ts#Resolver.returnController` |
-| Un `number` / un `boolean` | Auto-JSON scalaire (RFC 8259 §2 : `42`, `true` sont des documents valides) | `Resolver.ts#Resolver._callWithIdempotency` |
-| Un `Buffer` | Envoyé brut | `Resolver.ts#Resolver.returnController` |
-| Une `Response` (via un `render*`) | Retournée telle quelle — l'envoi a déjà eu lieu | `Resolver.ts#Resolver._invokeAction` |
-| `void`/`null` **et** statut 204/205/304 | Réponse **vide envoyée** (RFC 9110 : ces statuts n'ont pas de corps) | `NO_BODY_STATUS` (`Resolver.ts#NO_BODY_STATUS`) |
-| `void`/`null` avec tout autre statut | `waitAsync` : « l'action enverra plus tard » | `Resolver.ts#Resolver.returnController` |
-| Une instance de classe (entité ORM, DTO) | **Non sérialisée** → `waitAsync` (le teardown avertit du blocage) | `Resolver.ts#Resolver.returnController` |
+| Une `Promise` / un thenable | Déballée puis re-traitée (récursif) | `Resolver.ts#Resolver.returnController` |
+| Une `string` | Envoyée telle quelle en corps | `Resolver.ts#Resolver.returnController` |
+| Un objet simple ou un tableau | **Auto-JSON** : `application/json` + sérialisation | `Resolver.ts#Resolver.returnObject` |
+| Un `number` / un `boolean` | Auto-JSON scalaire (RFC 8259 §2 : `42`, `true` sont des documents valides) | `Resolver.ts#Resolver.returnController` |
+| Un `Buffer` | Envoyé brut | `Resolver.ts#Resolver.returnObject` |
+| Une réponse Nodefony (rendue par un `render*`) | Retournée telle quelle — l'envoi a déjà eu lieu | `Resolver.ts#Resolver.returnObject` |
+| Une **`Response` Web standard** — `fetch()`, `new Response(…)`, `Response.json(…)` | **Envoyée en flux** : son statut, ses en-têtes, son corps (HTTP seulement) — détail ci-dessous | `HttpContext.openWebResponse()` (`HttpContext.ts#HttpContext.openWebResponse`, `@nodefony/http`) |
+| Un **flux d'octets nu** — `Readable` Node, `ReadableStream` Web | **Envoyé en flux**, comme `this.renderStream(source)` sans option (HTTP seulement) | `Resolver.ts#Resolver.returnObject` |
+| `void`/`null` **et** statut 204/205/304 | Réponse **vide envoyée** (RFC 9110 : ces statuts n'ont pas de corps) | `isContentlessStatus` (`Response.ts#isContentlessStatus`, `@nodefony/http`) |
+| `void`/`null` avec tout autre statut | `waitAsync` : « l'action enverra plus tard » | `Resolver.ts#Resolver.returnNothing` |
+| Une `Date`, une `RegExp`, une `Error` | Comme `void` : rien à rendre | `Resolver.ts#Resolver.returnNothing` |
+| Une instance de classe (entité ORM, DTO) | **Non sérialisée** → `waitAsync` (le teardown avertit du blocage) | `Resolver.ts#Resolver.returnObject` |
 
 > [!WARNING]
 > **Le piège n° 1 : `return null` sur un statut à corps.** Le framework l'interprète comme « je
 > répondrai moi-même » et attend — jusqu'au timeout. La distinction se fait sur le **statut** :
-> `NO_BODY_STATUS` (`Resolver.ts#NO_BODY_STATUS`) contient 204, 205 et 304. Donc un `@Delete` qui fait
+> `isContentlessStatus` (`Response.ts#isContentlessStatus`, liste unique de `@nodefony/http`) rend vrai pour 204, 205 et 304. Donc un `@Delete` qui fait
 > `@HttpCode(204)` puis `return null` répond bien 204 vide ; le même `return null` sans `@HttpCode`
 > laisse la requête pendue.
 
 Même règle pour une **instance de classe** (une entité ORM renvoyée telle quelle) : elle n'est
 volontairement pas passée à `JSON.stringify`. Retourne un objet simple — ou appelle `renderJson()`.
 
+### Renvoyer une `Response` Web ou un flux
+
+La `Response` est l'objet standard que rend `fetch()` — dans le navigateur, et dans Node depuis la
+version 18. Beaucoup de bibliothèques en produisent une toute prête (un kit d'IA qui rend son texte
+en flux, un client d'API). Ton action peut la **renvoyer telle quelle** : le framework envoie son
+statut, ses en-têtes et son corps EN FLUX, sans le lire d'avance.
+
+```ts
+import { Readable } from "node:stream";
+import { Controller, controller, route } from "@nodefony/framework";
+import type { Context } from "@nodefony/http";
+
+@controller("/examples")
+export class ExamplesController extends Controller {
+  constructor(context: Context) {
+    super("ExamplesController", context);
+  }
+
+  /** Relayer une API tierce : sa réponse, telle quelle. */
+  @route("weather", { path: "/weather" })
+  weather() {
+    // Le signal coupe l'appel amont si le client s'en va.
+    return fetch("https://api.exemple.org/meteo", {
+      signal: this.context?.signal ?? null,
+    });
+  }
+
+  /** Une réponse construite : statut, en-têtes et cookie à toi. */
+  @route("export", { path: "/export.csv" })
+  export() {
+    return new Response("id;libellé\n1;Cordage\n", {
+      status: 200,
+      headers: [
+        ["content-type", "text/csv; charset=utf-8"],
+        ["content-disposition", 'attachment; filename="export.csv"'],
+        ["set-cookie", "export=fait; Path=/; HttpOnly"],
+      ],
+    });
+  }
+
+  /** Un flux d'octets renvoyé nu. */
+  @route("lines", { path: "/lines" })
+  lines() {
+    return Readable.from(["une\n", "deux\n"], { objectMode: false });
+  }
+}
+```
+
+Ce que le framework fait de la réponse (`webResponse.ts#webResponseParts`, `@nodefony/http`) :
+
+| Origine de la `Response`                                                           | En-têtes envoyés                                                                                                                                                                                                                   |
+| ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Construite** par ton code (`new Response`, `Response.json`, `Response.redirect`) | tous les siens, **cookies compris**                                                                                                                                                                                                |
+| **Relayée** — rendue par `fetch()`                                                 | les siens, **sauf** `content-encoding` et `content-length` (`fetch` a déjà décompressé le corps : ils décriraient des octets qui ne sont plus là) et `set-cookie` (les cookies d'un service tiers seraient posés sous TON domaine) |
+
+Dans les deux cas, les en-têtes de connexion (`connection`, `keep-alive`, `transfer-encoding`,
+`upgrade`… — RFC 9110 §7.6.1) ne partent jamais : ils décrivent un saut, et HTTP/2 les refuse.
+La différence se lit sur `response.type` : `"default"` pour une réponse construite, `"basic"` ou
+`"cors"` pour une réponse de `fetch`.
+
+> [!TIP]
+> **Quand préférer `this.renderStream()`** : dès qu'il faut des options — délai de silence
+> (`idleTimeout`), durée maximale (`maxDuration`), écouteur de fin (`onClose`), ou ne recopier que
+> certains en-têtes de l'amont. `return response` est le geste court du cas courant ;
+> `renderStream` est le réglage fin. Les deux passent par la même tuyauterie
+> (`HttpContext.ts#HttpContext.openStream`) : contre-pression, arrêt au départ du client, `HEAD` sans
+> lire le corps.
+
+> [!WARNING]
+>
+> - **`Response.error()`** ne porte aucune réponse (statut 0) : le client reçoit un **502**.
+> - **WebSocket** : une `Response` ou un flux renvoyé par une action de message n'est pas envoyé — une
+>   trame n'a ni statut ni en-têtes. Renvoie un objet (envoyé en trame JSON) ou un `Buffer`.
+> - **Réponse déjà partie** (tu as appelé `render*` ou `streamFile` ET renvoyé une `Response`) : rien
+>   n'est réécrit, et le corps de la `Response` est annulé pour libérer l'amont.
+
 ### Les helpers de rendu
 
 Quand tu veux piloter l'envoi plutôt que retourner une valeur :
@@ -463,8 +543,10 @@ Deux besoins distincts, deux helpers.
 ### Téléchargement — `renderFileDownload()`
 
 `renderFileDownload(file, options?, headers?)` (`Controller.ts#Controller.renderFileDownload`) pose
-`Content-Disposition: attachment`, `Content-Length`, le type MIME du fichier, puis délègue au moteur
-de flux. Le fichier est résolu **sans bloquer l'event loop** (`getFileAsync()`, `Controller.ts#Controller.getFileAsync`) ;
+`Content-Disposition: attachment`, `Content-Length`, le type MIME du fichier et un `Expires` déjà
+passé, puis délègue au moteur de flux. Un nom de fichier accentué ou porteur de `"` part en
+`filename*` UTF-8, précédé d'un repli ASCII (RFC 6266 §4.3, RFC 8187) — un nom quelconque ne fait
+jamais lever la réponse. Le fichier est résolu **sans bloquer l'event loop** (`getFileAsync()`, `Controller.ts#Controller.getFileAsync`) ;
 la variante synchrone `getFile()` existe encore mais est marquée obsolète — elle appelle `lstatSync`
 et gèle le process le temps du stat.
 
@@ -473,25 +555,136 @@ et gèle le process le temps du stat.
 `renderMediaStream(file, headers?, options?)` (`Controller.ts#Controller.renderMediaStream`) implémente les **requêtes par
 plage** (RFC 9110 §14), ce qui permet à un lecteur vidéo de sauter dans le flux :
 
-| Le client envoie…                             | Réponse                                                         |
-| --------------------------------------------- | --------------------------------------------------------------- |
-| Pas de `Range`                                | 200 + fichier complet, `Accept-Ranges: bytes`                   |
-| `Range: bytes=0-499`                          | **206** + `Content-Range`, bornes clampées à la taille réelle   |
-| `Range: bytes=-500` (suffixe)                 | 206 sur les 500 derniers octets                                 |
-| Plage hors fichier                            | **416** + `Content-Range: bytes */<taille>` (RFC 9110 §15.5.17) |
-| Syntaxe invalide, multi-plage, unité inconnue | En-tête **ignoré** → 200 complet (jamais un 500)                |
+| Le client envoie…                                | Réponse                                                         |
+| ------------------------------------------------ | --------------------------------------------------------------- |
+| Pas de `Range`                                   | 200 + fichier complet, `Accept-Ranges: bytes`                   |
+| `Range: bytes=0-499`                             | **206** + `Content-Range`, bornes clampées à la taille réelle   |
+| `Range: bytes=-500` (suffixe)                    | 206 sur les 500 derniers octets                                 |
+| Plage hors fichier                               | **416** + `Content-Range: bytes */<taille>` (RFC 9110 §15.5.17) |
+| Syntaxe invalide, multi-plage, unité inconnue    | En-tête **ignoré** → 200 complet (jamais un 500)                |
+| `HEAD` avec `Range`                              | `Range` **ignoré** : en-têtes du GET complet (RFC 9110 §14.2)   |
+| `If-Range` égal à l'`ETag` ou au `Last-Modified` | 206 : la reprise est sûre, le fichier n'a pas changé            |
+| `If-Range` différent, ou étiquette faible        | `Range` **ignoré** → 200 complet (RFC 9110 §13.1.5)             |
+
+Une condition `If-Range` fausse sert le fichier entier — plutôt qu'une plage d'un fichier qui a
+changé, que le client recollerait à l'ancienne. Seuls un `ETag` FORTEMENT égal, ou une date égale
+à un `Last-Modified` vieux d'au moins une seconde, autorisent la reprise.
 
 La logique est isolée dans une fonction pure exportée, `parseByteRange()` (`Controller.ts#parseByteRange`) —
 donc testable sans serveur.
 
 ### Ce que `streamFile()` garantit
 
-`streamFile()` (`Controller.ts#Controller.streamFile`) est le moteur commun. Sa subtilité n'est pas le pipe, c'est le
-**nettoyage** : le flux est ouvert avec `autoClose: false`, et un client qui raccroche en plein
-téléchargement laisserait sinon un descripteur de fichier ouvert et une promesse pendue à jamais. Un
-écouteur `close` sur la réponse détruit le flux, ce qui déclenche la fermeture du descripteur et
-résout la promesse (`Controller.ts#Controller.streamFile`), puis se retire lui-même (`Controller.ts#Controller.streamFile`). Un
-téléchargement interrompu ne coûte donc **rien** en ressource retenue.
+`streamFile()` (`Controller.ts#Controller.streamFile`) est le moteur commun, et il repose sur le
+même cycle de vie que `renderStream()` ci-dessous (`HttpContext.openStream`) :
+
+- **la réponse est prise à l'appel**, les en-têtes partent au premier morceau ;
+- **un client qui raccroche détruit le flux**, donc ferme le descripteur : un téléchargement
+  interrompu ne retient rien ;
+- **un fichier illisible à l'ouverture** (`EACCES`) rend la page d'erreur ordinaire, 500 ; une
+  lecture qui échoue en route coupe la connexion, jamais une fin propre ;
+- **la longueur annoncée est tenue** : la lecture est bornée à la taille relevée (un fichier qui
+  grossit pendant l'envoi n'envoie pas plus que `Content-Length`), et un extrait `start`/`end`
+  annonce sa propre longueur ;
+- **un fichier n'est pas un flux vivant** : ni `X-Accel-Buffering: no`, ni délai d'inactivité.
+
+### Requêtes conditionnelles — 304, 412, reprise
+
+Les trois helpers posent sur le fichier ENTIER une `ETag` forte et un `Last-Modified`, tirés de sa
+taille et de sa date de modification, sans le lire. Les préconditions sont évaluées dans l'ordre de
+RFC 9110 §13.2.2, AVANT d'ouvrir le fichier (`conditionalRequest.ts#evaluatePreconditions`) :
+
+| Le client envoie…                                            | Réponse                                     |
+| ------------------------------------------------------------ | ------------------------------------------- |
+| `If-None-Match` égal (comparaison faible), ou `*`            | **304** en GET/HEAD, sans corps ; 412 sinon |
+| `If-Modified-Since` ≥ date du fichier (sans `If-None-Match`) | **304** en GET/HEAD                         |
+| `If-Match` différent (comparaison forte)                     | **412** `Precondition Failed`               |
+| `If-Unmodified-Since` < date du fichier (sans `If-Match`)    | **412**                                     |
+
+Le 304 porte ce qu'aurait porté le 200 : `ETag`, `Last-Modified`, `Cache-Control`, `Expires`,
+`Vary` (RFC 9110 §15.4.5). Le helper rend alors `null` : aucun fichier n'a été ouvert.
+
+**`Cache-Control: private, no-cache` par défaut.** Sans lui, `Last-Modified` rendrait la réponse
+« heuristiquement cacheable » (RFC 9111 §4.2.2) : un cache partagé pourrait garder le fichier et le
+resservir sans redemander — or un fichier servi par une action est le plus souvent protégé.
+`private` ferme les caches partagés, `no-cache` fait revalider avant chaque réutilisation, ce qui
+ne coûte qu'un 304. Un fichier public fixe le sien :
+
+```ts
+return this.renderMediaStream(file, {
+  "Cache-Control": "public, max-age=3600",
+});
+```
+
+Une `ETag` ou un `Last-Modified` passés dans les en-têtes (un hachage du contenu, une version)
+remplacent ceux du fichier ET servent à la comparaison. Un extrait `streamFile(f, h, { start, end })`
+n'est pas la représentation entière : il ne reçoit ni validateur ni évaluation.
+
+**Ce que l'application peut changer** :
+
+| Besoin                                                | Geste                                                                      |
+| ----------------------------------------------------- | -------------------------------------------------------------------------- |
+| Un autre `Cache-Control` (fichier public, `no-store`) | le passer dans les en-têtes, ou `@Header("Cache-Control", …)` sur l'action |
+| Sa propre `ETag` (hachage du contenu, version)        | la passer dans les en-têtes, ou `@Header("ETag", …)` — elle sert au 304    |
+| Aucun validateur, aucun 304, aucun `Cache-Control`    | `{ validators: false }` dans les options                                   |
+| Le défaut de toute l'application                      | la section `fileServing` de la config du module (ci-dessous)               |
+
+Un en-tête posé AVANT l'appel (`@Header`, `this.response.setHeader`) est respecté comme s'il était
+passé en argument.
+
+**Pour toute l'application**, la section `fileServing` de la config du module fixe le défaut
+(`config.ts#fileServingSchema`) ; un appel le remplace toujours :
+
+```ts
+use("@nodefony/framework", {
+  fileServing: {
+    validators: true, // false : aucun validateur, aucun 304, aucun Cache-Control par défaut
+    cacheControl: "private, no-cache", // null : n'en poser aucun
+  },
+});
+```
+
+`cacheControl` est validé au démarrage : une valeur porteuse d'un retour à la ligne (qui forgerait
+un en-tête de plus) l'interrompt en nommant la clé. `{ validators: true }` dans les options d'un
+appel rétablit les validateurs quand la config les a coupés.
+
+⚠️ **La date d'un fichier n'est pas toujours fiable.** Une archive décompressée ou un build
+reproductible donne la même date à tous les fichiers : deux contenus de même taille portent alors
+la même `ETag`, et le client garde l'ancien sur un 304 sans que rien ne le signale. Pour ces
+fichiers, passer une `ETag` tirée du contenu — le 304 reste juste — ou couper les validateurs :
+
+```ts
+// le 304 garde son sens : l'étiquette suit le contenu
+return this.renderMediaStream(file, { ETag: `"${hash}"` });
+// ou : aucune requête conditionnelle, le fichier part toujours entier
+return this.renderMediaStream(file, {}, { validators: false });
+```
+
+### Une source qui n'est pas un fichier — `renderStream()`
+
+La sortie d'un processus (ffmpeg, `tar`), le corps d'un `fetch()` relayé, une archive construite à
+la volée : `renderStream(source, options?)` (`Controller.ts#Controller.renderStream`) répond par
+ce flux d'octets, en HTTP/1.1 comme en HTTP/2. La réponse est prise à l'appel, ses en-têtes partent
+au premier morceau, et la source est **détruite** à la fin quelle qu'en soit la raison. La promesse
+ne rejette jamais : elle rend `{ reason, bytes }`.
+
+```typescript
+const ff = spawn("ffmpeg", args, {
+  stdio: ["ignore", "pipe", "ignore"],
+  windowsHide: true,
+});
+try {
+  await this.renderStream(ff.stdout, {
+    headers: { "content-type": "video/mp4" },
+  });
+} finally {
+  ff.kill("SIGKILL"); // le flux est fini, quelle qu'en soit la raison
+}
+```
+
+Page complète — options, raisons de fin, erreurs avant et après le premier octet, relais `fetch`,
+pièges : [Flux d'octets](../../http/docs/byte-stream.md). Pour des **événements texte** lus par
+`EventSource`, voir [Flux SSE](../../http/docs/sse.md).
 
 ## ⚠️ Erreurs — lever, rendre, observer
 
@@ -594,15 +787,21 @@ code du framework applique — et attend de toi — les règles suivantes :
 
 ## 📜 Normes appliquées
 
-| Domaine                          | Norme                    | Comment le code s'y conforme                                                         |
-| -------------------------------- | ------------------------ | ------------------------------------------------------------------------------------ |
-| Statuts sans corps (204/205/304) | RFC 9110 §15.3.5/§15.4.5 | `NO_BODY_STATUS` (`Resolver.ts#NO_BODY_STATUS`)                                      |
-| Requêtes par plage               | RFC 9110 §14.1.2, §14.2  | `parseByteRange()` (`Controller.ts#parseByteRange`)                                  |
-| Plage insatisfiable → 416        | RFC 9110 §15.5.17        | `renderResponse()` avec 416 (`Controller.ts#Controller.renderResponse`)              |
-| Redirections                     | RFC 9110 §15.4           | Liste blanche + repli 302 (`Response.ts#HttpResponse.send`)                          |
-| Média JSON sans `charset`        | RFC 8259 §11             | Auto-JSON (`Resolver.ts#Resolver.returnController`), vérifié par le banc `auto-json` |
-| Scalaire JSON de premier niveau  | RFC 8259 §2              | `number`/`boolean` rendus (`Resolver.ts#Resolver._callWithIdempotency`)              |
-| Codes de fermeture WebSocket     | RFC 6455 §7.4            | `renderWebsocket()` (`error-renderer.ts#DefaultErrorRenderer.renderWebsocket`)       |
+| Domaine                           | Norme                            | Comment le code s'y conforme                                                          |
+| --------------------------------- | -------------------------------- | ------------------------------------------------------------------------------------- |
+| Statuts sans corps (204/205/304)  | RFC 9110 §15.3.5/§15.3.6/§15.4.5 | `isContentlessStatus` (`Response.ts#isContentlessStatus`) — aucun corps ne part       |
+| Requêtes par plage                | RFC 9110 §14.1.2, §14.2          | `parseByteRange()` (`Controller.ts#parseByteRange`)                                   |
+| Plage insatisfiable → 416         | RFC 9110 §15.5.17                | `renderResponse()` avec 416 (`Controller.ts#Controller.renderResponse`)               |
+| `Range` hors GET, sous `If-Range` | RFC 9110 §14.2, §13.1.5          | `renderMediaStream()` (`Controller.ts#Controller.renderMediaStream`)                  |
+| Validateurs d'un fichier          | RFC 9110 §8.8.2, §8.8.3          | `fileValidators()` (`conditionalRequest.ts#fileValidators`)                           |
+| Ordre des préconditions → 304/412 | RFC 9110 §13.1, §13.2.2          | `evaluatePreconditions()` (`conditionalRequest.ts#evaluatePreconditions`)             |
+| Cache d'un fichier protégé        | RFC 9111 §4.2.2, §5.2.2          | `Cache-Control: private, no-cache` par défaut (`Controller.ts#Controller.streamFile`) |
+| Nom de fichier téléchargé         | RFC 6266 §4.3, RFC 8187          | `contentDisposition()` (`Controller.ts#contentDisposition`)                           |
+| Longueur du corps tenue           | RFC 9112 §6.3, RFC 9113 §8.1.1   | `streamFile()` (`Controller.ts#Controller.streamFile`) + `ByteStream.ts#ByteStream`   |
+| Redirections                      | RFC 9110 §15.4                   | Liste blanche + repli 302 (`Response.ts#HttpResponse.send`)                           |
+| Média JSON sans `charset`         | RFC 8259 §11                     | Auto-JSON (`Resolver.ts#Resolver.returnController`), vérifié par le banc `auto-json`  |
+| Scalaire JSON de premier niveau   | RFC 8259 §2                      | `number`/`boolean` rendus (`Resolver.ts#Resolver._callWithIdempotency`)               |
+| Codes de fermeture WebSocket      | RFC 6455 §7.4                    | `renderWebsocket()` (`error-renderer.ts#DefaultErrorRenderer.renderWebsocket`)        |
 
 ## 📡 Observabilité — Studio
 

package/docs/decorateurs.md

@@ -431,7 +431,7 @@ update(input: RouteInput<{ params: typeof postParams; body: typeof postBody }>)
 **Ce que fait le framework, dans l'ordre :**
 
 - chaque partie déclarée est un [Standard Schema](https://standardschema.dev) — Zod, Valibot,
-  ArkType… ; l'interface est recopiée au cœur (`runtime/standardSchema.ts#IStandardSchemaV1`), aucune
+  ArkType… ; l'interface est recopiée au cœur (`runtime/standardSchemaTypes.ts#IStandardSchemaV1`), aucune
   dépendance n'est imposée ;
 - la validation a lieu **après** les gardes (`@IsGranted` : un 403 ne révèle pas le contrat) et
   **avant** l'instanciation du contrôleur : une entrée invalide ne construit rien