@eqs/http : des codes d'erreur distincts pour les refus d'un sortant délégué #128

Closed
opened 2026-10-08 10:46:13 +00:00 by nicolas-fryder · 0 comments

Constat

Dans jetonDeLAppelant (packages/http/src/index.ts), les trois refus d'un sortant délégué lèvent tous une ApiError avec un code générique. Seul le texte du message les distingue :

Cas Statut Code Message
Hors requête (aucun appelant) 500 INTERNAL « … aucun utilisateur n’appelle : cet appel part hors requête »
L'appelant n'est pas une personne (clé d'API, service) 403 FORBIDDEN « … et l’appelant est un apiKey »
Consentement absent (compte non lié) 403 FORBIDDEN « aucune délégation hq pour cet utilisateur : lier le compte… »

Un satellite doit pourtant les traiter différemment :

  • non lié → proposer de lier le compte ;
  • appelant non humain → refuser la route ;
  • hors requête → c'est un défaut de l'application.

Nuage le fait aujourd'hui en comparant le texte des messages (apps/api/src/hq/hq-delegue.ts de EQS/NUAGE, branche accueil-affaires), y compris l'apostrophe typographique de « n’appelle ». Une simple reformulation dans le socle ferait basculer, sans aucune erreur visible, un « non lié » en « HQ refuse », ou une panne interne en « HQ indisponible ».

Ce qui est attendu

  • Un code distinct par cas, par exemple DELEGATION_ABSENTE, APPELANT_NON_HUMAIN et HORS_REQUETE, porté par ApiError.code ou par un champ dédié. Le statut HTTP ne change pas.
  • Les codes sont exportés comme constantes, pour qu'un satellite les compare sans recopier de chaîne.
  • Un test par cas.
  • Le cahier des charges (§5 « Sortant délégué ») et un changeset mineur pour @eqs/http.

Critère de fin

Un satellite distingue les trois cas par leur code seul. Nuage pourra alors retirer ses comparaisons de messages (MARQUE_NON_LIE et ses voisines dans hq-delegue.ts).

Ouvert depuis une session de travail sur Nuage.

## Constat Dans `jetonDeLAppelant` (`packages/http/src/index.ts`), les trois refus d'un sortant délégué lèvent tous une `ApiError` avec un code générique. Seul le texte du message les distingue : | Cas | Statut | Code | Message | |---|---|---|---| | Hors requête (aucun appelant) | 500 | `INTERNAL` | « … aucun utilisateur n’appelle : cet appel part hors requête » | | L'appelant n'est pas une personne (clé d'API, service) | 403 | `FORBIDDEN` | « … et l’appelant est un apiKey » | | Consentement absent (compte non lié) | 403 | `FORBIDDEN` | « aucune délégation hq pour cet utilisateur : lier le compte… » | Un satellite doit pourtant les traiter différemment : - **non lié** → proposer de lier le compte ; - **appelant non humain** → refuser la route ; - **hors requête** → c'est un défaut de l'application. Nuage le fait aujourd'hui en **comparant le texte des messages** (`apps/api/src/hq/hq-delegue.ts` de EQS/NUAGE, branche `accueil-affaires`), y compris l'apostrophe typographique de « n’appelle ». Une simple reformulation dans le socle ferait basculer, sans aucune erreur visible, un « non lié » en « HQ refuse », ou une panne interne en « HQ indisponible ». ## Ce qui est attendu - Un code distinct par cas, par exemple `DELEGATION_ABSENTE`, `APPELANT_NON_HUMAIN` et `HORS_REQUETE`, porté par `ApiError.code` ou par un champ dédié. Le statut HTTP ne change pas. - Les codes sont exportés comme constantes, pour qu'un satellite les compare sans recopier de chaîne. - Un test par cas. - Le cahier des charges (§5 « Sortant délégué ») et un changeset mineur pour `@eqs/http`. ## Critère de fin Un satellite distingue les trois cas par leur code seul. Nuage pourra alors retirer ses comparaisons de messages (`MARQUE_NON_LIE` et ses voisines dans `hq-delegue.ts`). *Ouvert depuis une session de travail sur Nuage.*
nicolas-fryder referenced this issue from a commit 2026-10-12 07:57:22 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Infrastructure/eqs-platform#128
No description provided.