# Evalixo : la documentation fonctionnelle

> Source : https://evalixo.com/fct/ (version du 21 octobre 2026). Ce fichier est généré automatiquement à partir de la page publique ; la page reste la référence.

Les règles de gestion, les états, les verrous et les codes d'erreur du produit. À lire pour répondre à « pourquoi ce bouton est grisé ? », « que se passe-t-il si… ? » ou « quelle limite s'applique ? ».

Plateforme d'évaluation technique en marque blanche — le logo et le nom du cabinet sur ce que voient candidats et tiers : un cabinet construit sa banque de questions et de tests, envoie des épreuves à des candidats sans compte, et exploite les copies corrigées.

## Le produit

Evalixo couvre la chaîne complète d'une évaluation de recrutement : construire le contenu, l'envoyer, encadrer le passage, corriger, décider.

#### Les cinq objets du métier

| Objet | Définition |
|---|---|
| Question | L'unité élémentaire : un énoncé, un type, un barème, un temps accordé (et, au besoin, une durée estimée). Vit dans une banque, réutilisable dans plusieurs tests. |
| Test | Une suite ordonnée de questions. Ses caractéristiques (durée, barème, niveau, compétences) sont **déduites** des questions, jamais saisies. |
| Questionnaire | Le dossier déclaratif — un formulaire sans notation ni chronomètre (motivation, administratif, auto-évaluation). |
| Évaluation | Un envoi : un candidat × une épreuve. C'est une ligne sur la fiche du candidat, avec son propre lien de passage, sa propre échéance et son propre **déroulement**, figé au moment de l'envoi. |
| Campagne | L'orchestration : un poste, des épreuves ordonnées, des candidats. Elle génère les évaluations en série. |

> **Le candidat n'a jamais de compte**
> 
> Son seul sésame est un lien opaque et daté (`/t/{token}` pour une épreuve, `/p/{token}` pour un parcours de campagne). Révoquer l'évaluation tue le lien.

## Personas & accès

#### Recruteur

Travaille dans un cabinet (*tenant*). Tout ce qu'il crée appartient au cabinet et est partagé avec ses collègues.

- Banque privée : questions, tests, questionnaires
- Recrutement : clients, postes, campagnes, candidats
- Consulte le catalogue officiel sans pouvoir le modifier

#### Administrateur plateforme

Ne recrute pas. Il conserve le catalogue officiel et supervise les cabinets.

- Catalogue officiel : questions et tests partagés à tous
- Sociétés, comptes recruteurs, candidats tous cabinets
- Messages du formulaire de contact

| Règle | Comportement |
|---|---|
| Authentification | Page hébergée par Keycloak, avant même le chargement de l'application. Aucun écran de connexion interne. |
| Ouverture d'un compte | **Self-service** depuis le site public : le recruteur s'inscrit, vérifie son e-mail, nomme son cabinet et entre (§3). La création d'un compte **par l'administrateur** reste possible et n'a pas changé (§20) — les deux voies coexistent. |
| Cloisonnement | Chaque lecture est filtrée par le cabinet. Un objet d'un autre cabinet est introuvable (404), jamais « interdit ». |
| Contenu officiel | Lecture pour tous, écriture réservée à l'administrateur. Une tentative d'écriture par un recruteur est refusée 403. |
| Séparation des espaces | Les écrans de recrutement sont fermés à l'administrateur, la supervision est fermée au recruteur — chacun est renvoyé vers son accueil. |

## Création de compte & espace de travail

Un recruteur ouvre son compte **lui-même** depuis le site public : le bouton **« Créer mon compte »** mène à l'écran d'inscription. Aucune invitation préalable, aucun devis, aucune création par l'administrateur n'est nécessaire. Le parcours va de l'inscription à un espace de travail **utilisable** : cabinet créé, plan posé, catalogue officiel ouvert.

### Le parcours

| Étape | Ce qui se passe |
|---|---|
| Inscription | Sur l'écran hébergé, le même que la connexion et aux couleurs d'Evalixo (§2). L'**e-mail est l'identifiant** : il n'y a pas d'autre nom d'utilisateur. |
| Vérification de l'e-mail obligatoire | Un lien de vérification part à l'adresse saisie. Tant qu'il n'a pas été suivi, la **connexion reste fermée** : le compte existe mais n'ouvre rien. |
| Première connexion | Le compte n'appartient encore à **aucun cabinet** et ne porte aucun rôle. L'application n'ouvre donc aucun écran de travail et renvoie sur **« Une dernière étape »**. |
| Nom du cabinet | Un champ, un seul. À la validation, l'espace est créé et le compte en devient **recruteur**. Le cabinet naît **vide** : aucun contenu n'y est posé. |
| Arrivée | Le **tableau de bord** (§17), avec un bandeau de bienvenue qui dit par où commencer. |

### L'écran « Une dernière étape »

| Règle | Comportement |
|---|---|
| Écran isolé | Il s'affiche **hors de l'application** : ni barre latérale, ni recherche globale, ni menu (§4). Il n'y a rien d'autre à faire que le franchir. |
| Un seul champ | Le **nom du cabinet**, obligatoire. Rien d'autre n'est demandé — ni logo, ni adresse, ni collègues : tout cela se règle ensuite (§18). |
| Nom déjà porté ailleurs | Le nom saisi est **conservé tel quel** — il n'est pas unique à l'échelle de la plateforme. L'identifiant de l'espace, lui, est rendu **unique automatiquement** : rien à corriger, aucun refus. |
| Plan de départ | Le cabinet s'ouvre sur le plan **Free** (§19). Le recruteur en lit les plafonds dès son arrivée, en lecture seule. |
| Franchie une fois | L'étape ne réapparaît plus : un compte rattaché à un cabinet entre directement dans l'application. |

> **Tout cabinet naît sur Free — on monte de plan ensuite**
> 
> L'inscription ne demande aucun choix d'offre et **aucune carte bancaire** : le cabinet naît sur **Free**. Le passage à **Starter** ou **Growth** se fait après coup, par carte, depuis l'écran « Abonnement & consommation » du cabinet (§19) — c'est aussi pour cela que les offres payantes du site public renvoient vers la **création de compte**. **Scale**, lui, se vend sur devis et s'active par l'équipe Evalixo (§20).

## Navigation

La barre latérale groupe les écrans par monde : **Bibliothèque** (le contenu), **Dossiers** (les formulaires), **Recrutement** (l'action), puis **Collaboration** — un groupe repliable comme les autres, avec une seule sous-entrée, *Demandes / Partages*, qui ouvre l'écran du travail confié à un tiers (§12) — et enfin **Finance**, en **dernière position**, lui aussi à sous-entrée unique : *Facturation* (§13). L'ordre n'est pas décoratif : on va en Finance en fin de mois, une fois le travail fait. Les groupes se replient et l'état est mémorisé. Une recherche globale coiffe l'application.

[capture d'écran : Tableau de bord du recruteur]

*L'accueil recruteur : la barre latérale à gauche, la recherche globale en haut, les actions à traiter au centre.*

## Bibliothèque de questions

Deux périmètres coexistent : **Officielles** (le catalogue de la plateforme) et **Personnalisées** (celles du cabinet). Une question officielle se copie dans sa propre bibliothèque pour être adaptée.

Une question personnalisée peut aussi être **rédigée avec l'IA** : elle arrive alors en brouillon, à relire puis à adopter, et n'entre dans la bibliothèque qu'à ce moment-là (§16).

[capture d'écran : Banque de questions officielles]

*La banque : recherche plein texte, filtres par domaine, niveau et type.*

[capture d'écran : Éditeur de question]

*L'éditeur : le type se choisit d'abord, l'aperçu candidat se met à jour en direct.*

### Les sept types de question

| Type | Ce que fait le candidat | Notation |
|---|---|---|
| QCM | Coche une seule bonne réponse. | Tout ou rien |
| Choix multiples | Coche plusieurs bonnes réponses. | Tout ou rien |
| Réponse libre | Rédige un texte. | Correction manuelle |
| Échelle | S'auto-évalue sur une échelle. | Déclaratif — non noté |
| Ordonnancement | Remet les étapes dans l'ordre. | Tout ou rien |
| Association | Relie chaque item à sa correspondance. | Proportionnelle |
| Texte à trous | Complète les `{{n}}` de l'énoncé. | Proportionnelle |

#### Règles de gestion

| Règle | Comportement |
|---|---|
| Éditeur visuel | L'énoncé et la **réponse attendue** d'une question libre se rédigent dans un éditeur visuel (gras, italique, code, listes, bloc de code **coloré pendant la frappe** — 16 langages, détection automatique). Les **réponses** (propositions d'un QCM, étapes d'un ordonnancement) acceptent gras, italique et code, sur une seule ligne. La **description d'un poste** se rédige dans le même éditeur. Le format stocké reste du texte à marqueurs : les questions existantes ne bougent pas. Les autres zones de texte (notes, commentaires) restent des notes simples. |
| Visuel d'énoncé | Une question porte **soit** une image, **soit** un visuel HTML — jamais les deux. Le visuel HTML est réservé à l'administrateur (il s'exécute chez le candidat, dans un cadre isolé). |
| Options mélangées | Pour l'ordonnancement et l'association, l'ordre affiché au candidat est brassé côté serveur — jamais l'ordre de saisie, qui est la solution. |
| Suppression | Refusée 409 dès qu'un test référence la question **ou** qu'un candidat y a répondu : une réponse est une preuve, l'effacer réécrirait des scores passés. |
| Copie d'une officielle | Une seule copie par question et par cabinet. La deuxième tentative renvoie vers la copie existante. |
| Pas de métier | Une question porte un **domaine** et des **compétences**, jamais un métier. Le champ n'existe ni au formulaire de création, ni en facette du banc de questions. Le métier est l'**intention d'un test** (§6) : la même question sert dix métiers, l'y enfermer obligerait à la dupliquer. |

> **Les rapports déjà rendus ne bougent pas**
> 
> Chaque réponse d'un candidat fige la question telle qu'elle était le jour du passage. Les instantanés produits *avant* le retrait du métier gardent le champ tel quel : un document gelé ne se réécrit pas, même pour le nettoyer.

## Bibliothèque de tests

Même découpage que les questions : **Officielles** et **Personnalisées**. Chaque carte affiche les caractéristiques déduites du contenu et porte le bouton d'envoi.

Un test personnalisé peut être **composé par l'IA** — métier visé, répartition des types, questions comprises. Il arrive en brouillon, se relit question par question, et ne devient un test envoyable qu'une fois adopté (§16).

[capture d'écran : Catalogue officiel des tests]

*Le catalogue officiel : consultable et envoyable par tous, modifiable par le seul administrateur.*

[capture d'écran : Liste des tests personnalisés]

*« Mes tests » : le CTA *Envoyer* à gauche du pied de carte, les autres gestes sous le menu « ⋯ ».*

### Grille ou liste

Les listes s'affichent au choix en **liste** (une ligne par objet, pour balayer et comparer des chiffres alignés) ou en **grille** (des tuiles, pour découvrir un catalogue). La **liste est l'affichage par défaut** : on vient sur ces écrans pour retrouver un objet parmi d'autres, pas pour contempler un catalogue. Le sélecteur est au-dessus de la liste, à droite ; le choix est **général** — il vaut pour les tests, les questions et les campagnes — et il est retenu d'une visite à l'autre.

Chaque écran a la vue qui lui manquait : le test se couche sur une ligne (identité, signature, gestes), la question gagne sa tuile (énoncé sur trois lignes et la rangée barème · durée · niveau, qui se compare d'une tuile à l'autre), la campagne se couche en gardant sa barre d'avancement — alignées, dix barres se lisent d'un coup d'œil.

### Le constructeur

Deux colonnes : le test en construction à gauche, la banque de questions à droite. Une question s'ajoute d'un clic, l'ordre se règle par glisser-déposer. Sous 1024 px, les deux colonnes deviennent des onglets.

En tête, un **bandeau épinglé** porte les chiffres du test — *questions · durée · barème · niveau · type* — dans la **même rangée à séparateurs** que la carte du banc de tests : on reconnaît la signature d'un test d'un écran à l'autre. La carte « Informations du test », en dessous, ne garde que ce qui **se décide** : le nom sur une ligne, puis le **métier visé** et les **domaines** côte à côte, enfin le **niveau annoncé**. Ce qui est **déduit** des questions est repoussé sous un filet, en pied de carte : les *compétences évaluées*. La **durée** n'est plus dans la carte — c'est un chiffre, elle vit dans le bandeau avec les autres.

> **Le test est du contenu, rien d'autre**
> 
> Le constructeur ne porte plus aucun réglage de déroulement : ni *passage en une seule fois*, ni mesures anti-triche. Ces choix se font **à l'envoi**, épreuve par épreuve — voir §11. Un même test peut donc partir surveillé chez un candidat et libre chez un autre, sans être dupliqué : c'est ce qui permet de régler un test **officiel**, qu'un recruteur ne peut pas modifier.

#### Règles de gestion

| Règle | Comportement |
|---|---|
| Tout est déduit | Durée (somme des questions), barème, niveau, type (noté / déclaratif) et compétences sont recalculés à chaque enregistrement. Aucun de ces champs ne se saisit. |
| Métier visé — obligatoire | Un test déclare le **métier** qu'il évalue, choisi dans une **liste fermée** (une vingtaine de valeurs couvrant les domaines du référentiel). Il est **obligatoire** : absent ou hors liste, l'enregistrement est refusé 422 (`VALIDATION_FAILED` / `UNKNOWN_JOB_ROLE`). Le bouton n'est jamais grisé — un enregistrement incomplet marque le champ. La valeur **« Transversal »** est la réponse d'un test qui ne vise aucun métier en particulier : un choix, jamais un oubli. Le **domaine**, lui, reste dérivé des questions. |
| Métier ↔ domaines — cohérence | Chaque métier du référentiel appartient à **UN domaine** (Développeur backend → IT, Comptable → Comptabilité…). Sur un test, le domaine du métier doit **FIGURER PARMI** les domaines du test — il suffit qu'il y soit, les autres restent libres (un test backend peut aussi couvrir Data). Sinon 422 `JOB_ROLE_DOMAIN_MISMATCH`. **« Transversal » est exempté** : il ne vise aucun domaine. En pratique le refus ne se rencontre pas — l'écran ajoute le domaine du métier choisi et l'**épingle** (plus de « × ») tant que ce métier tient. |
| Métier — facette et carte | Le banc de tests porte un filtre **Métier** résolu **côté serveur** (multi-valeurs, comme le domaine), et le métier se lit sur chaque carte de test à côté des domaines. C'est aussi lui qui préfiltre le sélecteur d'épreuves d'une campagne (§9). |
| Condition d'envoi | Un test est envoyable dès qu'il contient **au moins une question**. C'est l'unique règle : un test vide se crée et se garde, il ne part jamais. |
| Test « vivant » | Un test déjà envoyé s'édite, avec un bandeau d'avertissement : des candidats détiennent son lien. Les copies déjà rendues ne bougent pas — elles sont figées. |
| Officiel en lecture | Un recruteur consulte un test officiel, l'envoie directement et en règle le déroulement à l'envoi (§11). Pour le **modifier**, il l'ajoute d'abord à sa bibliothèque : « Ajouter à mes tests » en fait une copie privée. Le **partager** à un tiers, en revanche, ne demande **aucune copie préalable** (§12). |
| La FICHE d'un officiel — ce qu'elle porte, et ce qu'elle ne porte pas | Ouvrir un test officiel mène au **même écran** qu'un des siens, en consultation. Deux gestes ne suivent pas la même règle et il ne faut pas les confondre. **« Partager à un tiers » y figure** : la fiche l'exigeait en copie **PRIVÉE**, alors que le pied de carte du banc de tests l'offrait déjà sur le catalogue et que le serveur ne l'a **jamais** refusé — c'était une divergence entre deux écrans, pas une règle de gestion, et la fiche était le seul des deux à mentir. **La suppression, elle, reste réservée aux tests PRIVÉS** : le lien de la zone dangereuse ne s'affiche que sur une copie du cabinet, l'officiel étant tenu par l'administrateur depuis la banque. Rien n'a changé de ce côté-là. |
| Le panneau « Partagé pour relecture » de la fiche | La colonne de droite porte les liens posés sur ce test. Conséquence de la règle ci-dessus, il paraît **aussi sur un officiel**. Trois comportements : il arrive **REPLIÉ** — c'est l'historique du test, pas l'objet de la visite —, son en-tête porte le **nombre de partages** même fermé (le compte suffit à le rendre découvrable, sans coûter une colonne), et il **ne s'affiche pas du tout** quand le test n'a aucun partage : un panneau vide n'apprend rien. Point contre-intuitif, à dire au support : il liste les partages **DU CABINET** sur ce test, pas ceux du recruteur connecté — un test appartient à la banque du cabinet, ses liens aussi. |
| Suppression | Toujours possible. Voir §22 pour l'effet en cascade. |

[capture d'écran : Menu d'actions d'une carte de test]

*Le menu « ⋯ » d'une carte : dupliquer, partager, supprimer. L'envoi reste à part, en bouton coloré.*

## Questionnaires (dossiers)

Le questionnaire est un formulaire — **pas un test** : pas de score, pas de chronomètre, pas de niveau, pas de catalogue officiel. Il sert à recueillir ce qui ne se note pas : motivation, disponibilité, auto-évaluation, informations administratives.

[capture d'écran : Liste des questionnaires]

*La liste : compteurs de sections et de questions, badge d'usage, structure dépliable.*

[capture d'écran : Structure d'un questionnaire dépliée]

*Le plan déplié : sections numérotées, nombre de questions et de champs requis.*

[capture d'écran : Constructeur de questionnaire]

*Le constructeur : des sections, des champs ordonnés, chacun requis ou non.*

#### Les sept types de champ

Texte court · Texte long · Choix unique · Choix multiples · Échelle · Nombre · Date.

| Règle | Comportement |
|---|---|
| Champs à options | Un choix unique ou multiple exige **au moins deux options**. |
| Condition d'envoi | Comme un test : au moins un champ. |
| Gel à l'envoi | La structure est **figée dans le dossier du candidat au moment de l'envoi**. Modifier le questionnaire ensuite ne change aucun dossier déjà parti. |
| Champs obligatoires | Vérifiés à la remise contre la structure figée, pas contre la version courante. |
| Statuts | Un dossier n'est jamais « en cours » côté suivi : *Envoyé*, puis *Dossier reçu*. |

#### Pièces à joindre

Le recruteur déclare, **au niveau du questionnaire** — jamais dans une section, jamais numérotée avec les champs — les pièces attendues du candidat : un libellé, obligatoire ou non, et une ou plusieurs familles de formats parmi un référentiel **fermé** (Documents, Images, Tableurs, Archives).

| Règle | Comportement |
|---|---|
| Gel à l'envoi | Les pièces déclarées sont **figées dans le dossier** au moment de l'envoi, comme le reste du gabarit. Modifier le questionnaire ensuite — ajouter, retirer, rendre obligatoire — ne change **aucun dossier déjà parti**. |
| Un fichier par pièce | Le candidat dépose un fichier unique par pièce ; un nouveau dépôt **écrase** le précédent, il n'y a pas d'historique à conserver. |
| Validation serveur | Extension, type déclaré et taille sont vérifiés **côté serveur** à chaque dépôt : extension hors des familles figées ou type incohérent 422 `FILE_TYPE_NOT_ALLOWED`, au-delà du plafond 413 `UPLOAD_TOO_LARGE`. |
| Plafond plateforme | Variable d'environnement `QUESTIONNAIRE_FILE_MAX_MB` (défaut **10 Mo**), elle-même bornée par la taille multipart globale du serveur. Ce n'est jamais un choix du recruteur ni une valeur figée dans un dossier : elle est relue à **chaque** dépôt. |
| Remise | Une pièce obligatoire encore manquante refuse la remise 422 `FORM_REQUIRED_FIELD_MISSING` — le même code que pour un champ texte obligatoire vide. |
| Dossier rendu | Plus aucun dépôt ni retrait possible une fois le dossier remis. |
| Suppression en cascade | Supprimer le candidat ou son dossier efface les fichiers **en cascade** — aucun octet ne survit à son dossier. |
| Lecture | Les octets ne sont **jamais chargés** avec les listes ni avec le gabarit du questionnaire : une pièce se télécharge à la demande, individuellement. |

## Clients & postes

Le **client** est la société pour laquelle le cabinet recrute — y compris un service ou une filiale de la maison, si on compte lui refacturer (le client est celui qui reçoit la facture). Le **poste** est la fiche de besoin réutilisable ; il déclare obligatoirement **pour qui l'on recrute** (son intention), et se rattache nommément à un client quand l'intention le dit.

[capture d'écran : Liste des clients]

*Les clients, avec le nombre de postes rattachés.*

[capture d'écran : Liste des postes]

*Les postes, avec le nombre de campagnes **en cours** qui les utilisent.*

[capture d'écran : Fiche client]

*La fiche client : secteurs, contact, notes internes et les postes rattachés.*

[capture d'écran : Fiche poste]

*La fiche poste : listes fermées, compétences attendues, client facultatif.*

| Règle | Comportement |
|---|---|
| Client — unicité | Le nom est unique dans le cabinet, à la casse et aux espaces près 409. |
| Client — suppression | Refusée tant qu'un poste y est rattaché 409. Détacher d'abord. |
| Poste — listes fermées | Domaine, séniorité, type de contrat et mode de travail sont des listes fermées ; une valeur inconnue est rejetée 422. |
| Poste — métier facultatif | Le poste porte un **métier visé** pris dans la **même liste fermée** que les tests, mais **facultatif** (une valeur hors liste reste refusée 422 `UNKNOWN_JOB_ROLE`). L'intitulé du poste demeure libre, le domaine reste obligatoire. L'asymétrie avec le test est délibérée : le test est l'objet **indexé** — un index doit être complet —, le poste est un **consommateur** de cet index, et un critère de recherche peut manquer. |
| Poste — métier ↔ domaine | Un poste ne porte qu'**UN** domaine : la règle est l'**ÉGALITÉ**, pas l'appartenance — le domaine du métier doit être exactement celui du poste, sinon 422 `JOB_ROLE_DOMAIN_MISMATCH` (« Transversal » exempté). L'écran borne d'ailleurs la liste des métiers au domaine du poste (+ « Transversal »), avec un *Voir tous les métiers* pour la rouvrir ; changer le domaine re-filtre et lâche un métier devenu incohérent. |
| Poste — intention obligatoire | Chaque poste déclare son intention, référentiel fermé à trois valeurs : `CLIENT` (un client nommé), `INTERNAL` (recrutement interne — une campagne visant un tel poste ne peut pas être facturée), `TBD` (client à définir plus tard — exigé au moment de marquer le recrutement). Valeur inconnue 422 `POSITION_INVALID`. |
| Poste — intention ↔ client | `CLIENT` exige un client nommé ; `INTERNAL` et `TBD` en interdisent un, sinon 422 `CLIENT_INTENT_MISMATCH`. La règle est **applicative, jamais une contrainte de base** : supprimer un client détache ses postes (l'intention `CLIENT` reste, le nom disparaît) sans jamais bloquer d'autres écritures. Les postes antérieurs à la règle ont été repris : `CLIENT` s'ils avaient un client, `TBD` sinon — une intention ne se devine pas. |
| Poste — clôture | Le poste se **clôture** quand le recrutement est terminé (ou abandonné) : *⋯ → Clôturer* sur l'écran Postes, confirmation à l'appui. Il n'y a **pas de statut** séparé — la **date de clôture** est l'état : absente = en cours, présente = clôturé. Le geste est **toujours permis**, même quand des campagnes en cours visent le poste : c'est un marqueur de cycle de vie, il ne verrouille rien. |
| Poste — clôture réversible | *⋯ → Remettre en cours* efface la date et rend le poste à la sélection, **sans confirmation** (un geste qui rend la main ne se fait pas confirmer). Clôturer un poste déjà clos, ou rouvrir un poste en cours, est refusé 409 (`POSITION_ALREADY_CLOSED` / `POSITION_NOT_CLOSED`) — un geste sans effet laisserait croire qu'on l'a posé deux fois. |
| Poste clôturé — effets | Le poste clôturé **ne se propose plus** là où l'on **choisit** un poste (création et édition de campagne) : le filtre est serveur. En revanche l'écran **Postes continue de tout lister**, en deux temps — « En cours · n » puis « Clôturés · n » —, la rangée portant une pastille *Clôturé*. Les **campagnes existantes** qui le visent sont intactes : elles se lisent, se suivent et se clôturent normalement, et la fiche du poste reste affichée dans leur détail. La fiche elle-même reste lisible et modifiable, et **dupliquer** un poste clôturé crée un poste **en cours**. |
| Poste — deux compteurs de campagnes | Le poste porte **deux** comptes dérivés, qui ne répondent pas à la même question et peuvent donc diverger. **Campagnes en cours** (`activeCampaignCount`) : celles dont le statut n'est pas `CLOSED` — donc les `RUNNING` **et** les brouillons, exactement le périmètre de la section « En cours » de l'écran Campagnes. C'est le **seul** compte AFFICHÉ : bandeau de la fiche de poste, pastille de l'écran Postes, carte « Postes rattachés » d'une fiche client. **Total** (`campaignCount`) : toutes les campagnes, **clôturées comprises** ; il ne s'affiche pas seul — il n'existe que pour armer et EXPLIQUER la garde de suppression. Les deux sortent d'une **seule** requête (un `GROUP BY` à deux colonnes sur la liste, un agrégat à deux colonnes sur la fiche) : jamais un aller-retour de plus. |
| Poste — suppression | Refusée si une campagne l'utilise 409 `POSITION_IN_USE` — et la garde compte le **TOTAL**, pas les campagnes en cours : une campagne **clôturée** retient le poste tout autant qu'une campagne vivante. Ce n'est pas un choix produit mais une contrainte d'**intégrité** : `campaigns.position_id` référence le poste sans `ON DELETE`, et relâcher la garde ne libérerait pas la suppression — elle sortirait en 500 sur violation de contrainte. Les messages le disent explicitement, sans quoi l'écran se contredirait : le bandeau de la fiche annonce « *Aucune campagne en cours n'utilise ce poste, mais 2 campagnes clôturées le référencent encore : il ne peut pas être supprimé* », et le refus lui-même « *Une campagne utilise ce poste — même clôturée, elle le retient* ». **Inchangé** par la clôture DU POSTE : clôturer n'est pas supprimer, et un poste clôturé mais utilisé reste indestructible. |
| Client — barème | Facultatif, **trois volets indépendants** : *placement* (`PERCENT` + un pourcentage de ]0;100], ou `FLAT` + un forfait), *passation* (`UNIT` + un prix unitaire, ou **pas de barème**) et *campagne* (`FLAT` + un forfait, `PER_SITTING` — à la copie rendue —, ou **pas de barème**). **« Incluse » a disparu des deux volets** : elle se comportait exactement comme « pas de barème » (aucun prix proposé, rien de bloqué) — deux réglages pour un même comportement, un seul reste ; les fiches qui la portaient ont été migrées vers « pas de barème ». Un mode **sans** sa valeur est refusé 422 `CLIENT_BILLING_INVALID` ; une valeur que le mode ne désigne pas est simplement **écartée** — le mode tranche, il n'y a rien à deviner. Le barème existe dès qu'**un seul** des trois volets est posé. Détail et usage : §13. |
| Client — volet campagne | Le **troisième volet** a son mode comme les deux autres : `FLAT` propose un forfait (> 0) quand on facture la campagne, `PER_SITTING` la propose **aux copies rendues** au prix du volet passation, mode absent = rien n'est convenu. La carte « Barème de facturation » de la fiche client affiche **trois lignes** — *Placement* · *Passation de test* · *Campagne* —, chacune retombant sur « Non défini ». Il ne se surcharge **pas** au poste : seul le placement se négocie ainsi. |
| Poste — surcharge du barème | La fiche de poste **ne montre plus la finance** : le bloc « Barème applicable » a quitté l'éditeur (le barème se lit et se règle sur la fiche **client**, et le montant s'ajuste au besoin dans la modale « Facturer »). Une surcharge **déjà en base** — un **taux** chez un client au pourcentage (]0;100]), un **forfait** chez un client au forfait (> 0), bornes toujours tenues par le serveur (422 `POSITION_INVALID`) — continue de **faire foi** : prévisionnel du poste, montant proposé au placement, ligne qui retient que la valeur venait du poste. Elle ne remplace jamais le MODE, qui vient toujours du **client**. |
| Surcharge dormante | Les deux colonnes de surcharge (taux et forfait) **coexistent** et ne se nettoient **jamais** quand le client change de mode : un nettoyage détruirait une négociation à chaque bascule de barème. La surcharge que le mode ne désigne pas dort, et reparle inchangée le jour où le client revient à son mode d'origine. Depuis que l'éditeur de poste ne montre plus la finance, enregistrer la fiche **renvoie les surcharges telles quelles** : un simple enregistrement n'en efface aucune. |
| Poste — surcharge dormante | Les deux surcharges coexistent sur la fiche. Si le client change de mode, celle qui ne correspond plus **n'est pas effacée** — on n'efface pas une négociation : elle dort et redevient active si le client revient à son mode d'origine. |

## Campagnes

Une campagne réunit un poste, des épreuves ordonnées (tests et/ou questionnaires) et des candidats. Le lancement génère toutes les évaluations et envoie **un seul e-mail** par candidat, contenant le lien de son parcours.

**Qui et quoi, en toutes lettres.** La **liste** comme la **fiche** d'une campagne préfixent explicitement les deux noms qui la situent : « **Poste :** Développeur backend » et « **Client :** Atelier Nova ». Nus et côte à côte, un intitulé et une raison sociale se lisaient comme deux étiquettes de même nature et l'on ne savait plus laquelle disait *sur quoi* et laquelle disait *pour qui*. Le client vient du **poste** (une campagne n'en porte pas elle-même) : il ne paraît donc que là où un poste est rattaché, et reste muet sur un poste interne ou dont le client n'est pas encore choisi.

Le **préfixe** est teinté et la valeur ne l'est pas : « Poste : » et « Client : » se lisent en **corail**, ce qu'ils annoncent garde la couleur du texte. Aucun mot n'est ajouté — on fait seulement entendre celui qui y était déjà.

#### La liste en deux temps : « En cours » et « Clôturées »

La page de campagnes se lit en **deux sections nommées**. « **En cours** » réunit les campagnes *lancées* et les *brouillons* — un brouillon est du travail en cours, pas de l'archive ; il y garde son badge « Brouillon ». « **Clôturées** » vient ensuite. Le classement n'a pas bougé (il est résolu serveur) : la frontière est simplement **dite**.

| Règle | Comportement |
|---|---|
| Le compte est celui de la PAGE | L'intitulé porte le nombre de lignes **affichées** (« En cours · 4 »), jamais le total serveur : il doit décrire ce qu'on a sous les yeux. La pagination reste inchangée (10 par page). |
| Une section vide ne paraît pas | Si la page courante n'a rien à mettre dans une section, l'intitulé **disparaît** — un titre suivi de rien se lit comme un manque. Filtré sur « Clôturée », seule la seconde section s'affiche. |
| Les deux affichages | Le découpage vaut en **liste** comme en **grille** : intitulé, puis les lignes ou les tuiles de la section. |

#### Le menu « ⋯ » d'une campagne, depuis la liste

Chaque ligne (et chaque tuile) porte un menu **⋯** — au bout de la ligne en liste, en tête de la tuile en grille. Il donne les gestes de la fiche **sans ouvrir la fiche**, et ce qu'il propose dépend du **statut**.

| Statut | Ce que le menu propose |
|---|---|
| Brouillon | **Modifier** (retour au builder) · **Partager** *désactivé*, avec la raison : « Disponible après le lancement ». Le geste existe mais n'est pas atteignable — un brouillon n'a pas de liste vivante, il n'y a encore personne à montrer. Absent, on le chercherait ailleurs. |
| En cours | **Modifier** (l'écran de suivi, qui *est* le lieu d'édition d'une campagne lancée) · **Partager** · **Clôturer**. |
| Clôturée | **Partager** · **Remettre en cours**. |

| Règle | Comportement |
|---|---|
| Partager = la feuille de la fiche | Le geste ouvre **exactement** la même feuille que « Partager au client » depuis la fiche, avec la **même liste vivante** (le vivier, relu à chaque ouverture du lien) et le même campaignId — donc la même garde : **un seul lien vivant par adresse et par campagne**, avec la sortie « **Clôturer et remplacer** » (voir le partage). La liste n'ayant qu'un résumé de la campagne, le détail est relu au clic avant d'ouvrir la feuille. |
| Clôturer passe par une question | La confirmation partagée s'ouvre, puis la campagne est clôturée et la page courante se relit — la campagne change de section sous vos yeux. La clôture n'est **pas définitive** : le texte de la confirmation le dit (« Vous pourrez la remettre en cours »). |
| Remettre en cours part directement | Aucune confirmation : un geste qui **rend la main** ne se fait pas confirmer. Même comportement que sur la fiche. |
| Le menu ne vole pas le clic de la carte | Un clic sur une ligne ouvre la campagne ; un clic dans le menu ne l'ouvre pas. Le menu s'affiche hors de la carte et arrête la propagation. |

[capture d'écran : Liste des campagnes]

*Les campagnes et leur avancement.*

[capture d'écran : Constructeur de campagne]

*Le brouillon : poste, épreuves ordonnées, candidats.*

[capture d'écran : Détail d'une campagne]

*Le suivi : entonnoir en tête, avancement global, puis une ligne dépliable par candidat.*

#### Le sélecteur d'épreuves se préfiltre sur le poste

Quand la campagne vise un poste, « Ajouter une épreuve » s'ouvre **déjà filtré sur le métier du poste**. Si le poste n'en porte pas — il est facultatif —, le préfiltre retombe sur son **domaine** ; sans poste, rien n'est préfiltré.

| Règle | Comportement |
|---|---|
| Ordre de priorité | Métier du poste, sinon domaine du poste, sinon aucun préfiltre. Le métier prime : c'est l'indice le plus précis. |
| Débrayable d'un clic | Le préfiltre arrive sous la forme d'une **puce ordinaire** de la barre de recherche — même dessin, même « × » que celles qu'on pose soi-même. La retirer rouvre toute la bibliothèque : c'est une amorce, pas un verrou. |
| Il ne compte pas comme un critère | La bascule automatique vers l'onglet « Personnalisées » (quand le catalogue officiel ne rend rien) continue de jouer sous préfiltre : celui-ci n'est pas une recherche du recruteur. |

#### Lancer la campagne — l'assistant en trois étapes

Le bouton **Lancer la campagne** ouvre un assistant, lui aussi en trois temps.

| Étape | Ce qu'on y fait | Détail |
|---|---|---|
| ① | Déroulement du passage | **Un seul réglage** — rythme et mesures anti-triche — pour **toutes les épreuves de type test** du parcours. Les questionnaires l'ignorent. Voir §11. |
| ② | Récapitulatif | Le poste, les épreuves dans l'ordre, les candidats, l'échéance, et le déroulement retenu affiché en pastilles. *Retour* ramène à l'étape ①. |
| ③ | Informer en copie, puis Lancer | Les adresses tierces simplement prévenues du lancement — aucun lien de passage. Le bouton **Lancer** génère toutes les évaluations et envoie un e-mail de parcours par candidat. La même case facultative qu'à l'envoi — *« Partager automatiquement le résultat aux personnes en copie dès qu'il est disponible »*, **décochée par défaut** — apparaît dès qu'une adresse est en copie **et** que le parcours contient au moins une épreuve de type **test**. Cochée, un **encadré** annonce le partage à venir et le recruteur choisit le **droit** du lien — **Consultation** (défaut) ou **Correction** — qui vaudra **aussi pour les candidats qui termineront plus tard** : la liste du partage suit la campagne. Chaque candidat qui termine un test fait naître (ou enrichit) pour ces adresses un **lien d'accès au rapport** (échéance **J+14**, prolongée à chaque nouveau résultat), visible dans *Collaboration → Résultats partagés* — **un seul lien vivant par adresse et par campagne** : le tiers y voit la **liste vivante** du parcours, qui s'enrichit au fil des complétions. Le **droit choisi au lancement vaut pour toute la vie du lien** — un envoi ultérieur ne le change pas. Si tous les candidats du lien sont effacés, le lien **survit vide** et se révoque à la main. |

#### Cycle de vie

| Statut | Ce qui est possible |
|---|---|
| Brouillon | Tout se modifie : poste, épreuves, candidats. Aucune évaluation n'existe encore. |
| En cours | Les épreuves sont **figées**. La campagne reste ouverte : un candidat ajouté reçoit aussitôt ses épreuves et son lien. |
| Clôturée | Plus d'ajout de candidat. Les évaluations déjà envoyées **restent valides** — la clôture n'invalide aucun lien. |

| Règle | Comportement |
|---|---|
| Sens unique | Brouillon → En cours → Clôturée. Aucun retour en arrière. |
| Condition de lancement | Au moins une épreuve **et** au moins un candidat. |
| Échéance | La date limite de la campagne devient l'échéance commune des évaluations générées. Elle doit être **aujourd'hui ou plus tard** : une date déjà passée est refusée **au clic** (enregistrement du brouillon comme lancement), marquée sous le champ « Date limite » — le serveur ne voit pas ce cas. S'il le refuse malgré tout (400 `INVALID_EXPIRY_DATE`), le message s'affiche dans la fenêtre de l'assistant, jamais sur l'écran qu'elle recouvre. |
| Épreuves figées | Retirer un test d'une campagne lancée n'est pas possible : le geste de suivi, c'est retirer un **candidat**. |
| Déroulement figé au lancement | Le réglage de l'étape ① est figé **sur la campagne** et recopié sur chaque évaluation de test générée. Un candidat ajouté à une campagne **en cours** en **hérite** — l'assistant ne le redemande pas, et le réglage n'est pas rejugé. La fiche de campagne l'affiche en pastilles (neutre tant que la campagne est un brouillon). |
| Réglage refusé | 400 `INVALID_SITTING_SETTINGS` — le *passage en une seule fois* est validé contre la durée de **chacune** des épreuves de type test du parcours. |
| Refus pendant l'assistant | Tout refus survenu pendant les étapes de lancement (`INVALID_EXPIRY_DATE`, `CAMPAIGN_NOT_LAUNCHABLE`, `INVALID_SITTING_SETTINGS`…) s'affiche **dans la fenêtre de l'étape courante**, en bandeau au-dessus des boutons, avec une phrase **propre au code** (générique pour un code inconnu). L'assistant reste ouvert ; changer d'étape efface le bandeau. |
| Retrait d'un candidat | Possible à tout statut. Voir §22. |

## Candidats & invitations

La fiche candidat centralise l'identité, le CV, les notes privées du recruteur et **toutes ses évaluations**, séparées en tests et questionnaires.

[capture d'écran : Liste des candidats]

*La liste : chaque candidat porte le décompte de ses évaluations par statut.*

#### Liste, recherche et filtres

| Règle | Comportement |
|---|---|
| Pagination | La liste est paginée côté serveur, **10 candidats par page**. Le compte affiché est le total **filtré**, stable d'une page à l'autre. |
| Recherche | Porte sur le nom complet, l'e-mail **et le nom des épreuves passées** (l'instantané porté par chaque évaluation), insensible à la casse et aux accents. Elle s'applique au serveur, jamais à la page affichée. |
| Filtres mono-choix | Quatre filtres — **statut, test, domaine, source** (campagne ou envoi direct) — à un seul choix chacun. Le statut *Expiré* est déduit de l'échéance : un lien mort n'apparaît plus sous *Invité*. Les options de test et de domaine proposées sont celles réellement présentes dans le cabinet. |
| Tri | *Récents* (par défaut) ou *ordre alphabétique*. Le tri par **score** a été retiré : le score est recalculé à la lecture, il ne peut pas ordonner la liste. |
| Créer un candidat — le bouton n'est JAMAIS grisé | Le formulaire d'ajout désactivait *Enregistrer* tant que l'e-mail n'était pas valide : on avait un bouton mort sous les yeux **sans savoir pourquoi**. C'était un écart à la règle générale des formulaires de l'application, pas un choix. Le bouton est actif ; le **clic** sur un formulaire incomplet marque le champ fautif, fait défiler jusqu'à lui et **dit le motif** — avec deux messages distincts, parce que ce sont deux fautes différentes : *« L'e-mail est obligatoire : c'est la clé du candidat »* quand il est vide, *« Cette adresse e-mail n'est pas valide (exemple : prenom.nom@societe.fr) »* quand il est mal formé. L'e-mail reste la **seule** exigence : prénom et nom peuvent attendre. Le doublon garde son propre encart, avec le lien vers la fiche existante. |
| Toute carte se déplie | Chaque candidat est une carte à chevron qui s'ouvre **en place** sur ses panneaux d'évaluations (Tests / Questionnaires). Un candidat *sans aucune évaluation* (« Fiche seule ») porte le **même chevron** et s'ouvre sur une ligne sobre — *« Pas de résultat encore reçu. »* Auparavant il n'en avait pas du tout : on cliquait dans le vide en cherchant le sien, et la carte semblait d'une autre espèce. Une absence **annoncée** se lit mieux qu'une carte qui ne réagit pas — et une simple phrase grise suffit là où un état vide illustré pèserait plus lourd que la carte. |

[capture d'écran : Fiche candidat]

*Une ligne par évaluation : origine (campagne ou envoi direct), statut, dates, score une fois terminée.*

#### La fiche vivante — présenter, pas seulement suivre

La fiche n'est plus un simple dossier de suivi : c'est le **document de présentation** que vous partagez à vos clients. Sa colonne principale se lit dans l'ordre où un client la lirait — la synthèse d'abord, les données ensuite — et chaque carte annonce sa visibilité : **Visible client** (elle peut partir dans un partage) ou **Interne** (elle ne sort jamais du cabinet).

| Règle | Comportement |
|---|---|
| Statut de la fiche | Une pastille à côté du nom — *Disponible*, *En process*, *Recruté*, *Inactif* — qui se change d'un clic, sans mode édition. Une seule écriture automatique : **enregistrer un recrutement passe la fiche à « Recruté »** ; tout le reste est votre décision. |
| Synthèse du cabinet | Le paragraphe que le client lit en premier : qui est ce candidat, et pourquoi vous le présentez. Rédigée dans l'**éditeur visuel** (gras, listes…), rendue à l'identique sur la page du client. Vide, la carte vous le dit avec l'enjeu : *le client ne verra que les données brutes*. |
| Conditions & recherche | Les questions pratiques du client, structurées : **contrat** (référentiel), **prétentions** (fourchette en k€), **télétravail**, **mobilité**. Les prétentions sont marquées **Interne par défaut** : elles ne partent au client que si le partage les coche explicitement. |
| Compétences & tags | Des compétences à **niveau** (Notions / Confirmé / Expert) — libellé libre, doublon refusé à la saisie, jamais dédupliqué en silence. Dessous, les **tags libres** du cabinet (#cooptation…), affichés au héros de la fiche : eux sont **internes**, ils ne sortent jamais. |
| Activité — dérivée, jamais saisie | La carte raconte le process toute seule : création (et sa source), invitations, épreuves terminées (avec le score), partages (et l'identité masquée le cas échéant), **avis des clients**, recrutements et annulations. Tout est recomposé depuis l'existant — il n'y a rien à tenir à jour, et rien de tout cela ne sort du cabinet. |
| Partager depuis la fiche | Le bouton **Partager au client**, à côté de l'envoi de test, ouvre la **même feuille de partage** que la liste et les campagnes — avec ce seul candidat et ses épreuves rendues. Un geste, pas un parcours. |
| Effacer une valeur | Sur la fiche comme au serveur, l'effacement est explicite : un champ texte se vide, une borne salariale s'efface en la laissant **blanche**, le contrat en re-choisissant sa valeur courante. Une fourchette à l'envers est refusée (min ≤ max), à l'écran comme en base. |

#### Marquer un recrutement

La carte **Recrutements** du rail droit de la fiche enregistre le fait qu'un candidat a été embauché — chez un client, ou en interne. Un recrutement est une **pièce** : le nom du client et l'intitulé du poste y sont **figés** à la création (supprimer ou renommer la fiche ensuite ne change rien à la pièce). Un recrutement qui n'a pas tenu s'**annule**, horodaté et motivé : la suppression est réservée à l'erreur de saisie (voir le tableau).

**Un recrutement ne porte plus aucun montant.** La carte alimente le suivi et rien d'autre : ni honoraires saisis, ni honoraires affichés, et **aucune ligne de facturation n'est créée** par le geste. Ce qui se facture se décide depuis l'écran **Facturation** (§13), jamais en marge d'un suivi — la modale le dit elle-même en sous-titre. Le *salaire brut annuel* reste sur la pièce, mais c'est un attribut du recrutement, pas un honoraire : il sert de **base** au montant que le barème proposera le jour où l'on facturera ce placement.

| Règle | Comportement |
|---|---|
| Client ou interne | Un recrutement non interne exige un client 422 `CLIENT_REQUIRED` ; un recrutement interne n'en nomme aucun 422 `INTERNAL_WITH_CLIENT`. L'interne est enregistré pour le suivi ; sans client, il ne sert de base à aucune proposition de barème. |
| Salaire obligatoire | Le brut annuel est un **entier strictement positif**, en euros 422 `INVALID_SALARY` — c'est la **base** sur laquelle le barème proposera un montant au moment de facturer le placement, jamais un honoraire en soi. |
| Date d'embauche | Seule la **forme** se juge (`AAAA-MM-JJ`) 422 `INVALID_HIRED_ON` : une embauche passée comme une prise de poste future sont légales. |
| Poste facultatif, cohérent | Fourni, le poste doit être rattaché au client facturé (ou à aucun) 422 `POSITION_CLIENT_MISMATCH`. |
| Pré-remplissage | La fenêtre se pré-remplit depuis la **dernière campagne** du candidat quand son poste vise un client encore existant — modifiable, et la chaîne s'arrête net sinon (jamais la campagne d'avant). |
| Second recrutement actif | **Jamais bloqué** — c'est une situation (double embauche, saisie à corriger), pas une erreur. L'interface prévient avant d'enregistrer, le serveur accepte toujours. |
| Annulation | Une seule fois 422 `ALREADY_CANCELLED` ; la ligne reste visible, barrée, datée, motivée. Re-recruter le même candidat plus tard est une **nouvelle** ligne, pas une réouverture. |
| Suppression ≠ annulation | `DELETE …/placements/{id}` → 204. Réservé à l'**erreur de saisie** : le recrutement n'a jamais eu lieu, il est réellement supprimé. Possible qu'il soit annulé ou non ; 404 uniforme sur un id inconnu ou étranger. |
| Aucune cascade vers la facturation | Annuler ou supprimer un recrutement ne touche **aucune ligne de facturation** : les deux objets vivent leur vie. Une embauche qui n'a pas tenu se solde en annulant *aussi* la ligne, depuis l'écran Facturation (§13) — c'est une décision commerciale, pas une conséquence mécanique. |
| Badge « Recruté » | Sur la liste des candidats dès qu'au moins un recrutement non annulé existe — dérivé serveur, jamais stocké. |
| Deux chemins, un seul recrutement | La modale de la fiche candidat n'est pas le seul point d'entrée : la feuille **Facturer**, sur la nature « Un placement » en création, peut marquer le recrutement dans la foulée (mêmes règles, mêmes messages, même carte) — et le **salaire brut annuel** s'y saisit dans le **même champ** que celui du barème. Voir §13. |

#### Envoyer une épreuve — l'assistant en trois étapes

L'envoi se déclenche depuis la bibliothèque ou depuis la fiche candidat. Dans les deux cas, la popup est un **assistant en trois étapes** : on avance avec *Suivant*, on revient avec *Retour*, et rien n'est perdu aux allers-retours. L'envoi ne part qu'au bouton **Envoyer** de la dernière étape.

| Étape | Ce qu'on y fait | Détail |
|---|---|---|
| ① | L'épreuve et l'échéance | Depuis la bibliothèque : le **candidat** (existant, ou un simple e-mail — la fiche est créée à la volée) ; depuis la fiche : l'**épreuve** (test ou questionnaire). Puis la date limite du lien. |
| ② | Déroulement du passage | Le *Rythme* (passage en une seule fois) et les *Mesures anti-triche* (préréglages, puis les interrupteurs au détail). Voir §11. **Étape sautée pour un questionnaire** : un dossier ne se surveille pas. |
| ③ | Informer en copie | Facultatif. Ces personnes reçoivent **un e-mail les informant que le candidat a reçu le test** — elles ne passent pas l'épreuve et **ne reçoivent aucun lien de passage**. Elles sont prévenues à nouveau quand la copie est rendue. Sous le champ, une case facultative — *« Partager automatiquement le résultat aux personnes en copie dès qu'il est disponible »* — **décochée par défaut** : elle n'apparaît que pour un **test** (un questionnaire ne produit pas de rapport) et **seulement** tant qu'au moins une adresse est en copie ; vider la copie la décoche. Cochée, un **encadré** annonce qu'un **partage sera créé** dans *Collaboration → Résultats partagés*, et le recruteur choisit le **droit** du lien : **Consultation** (défaut — le tiers lit, sans rien modifier) ou **Correction** (le tiers peut noter les questions ouvertes). Chaque adresse reçoit à la fin du passage un **lien d'accès au rapport** (échéance **J+14**), créé par le serveur au moment où le candidat termine. Aucun doublon : si un lien vivant existe déjà pour cette adresse sur ce rapport, rien n'est recréé. |

Le sélecteur de candidats des popups (envoi direct, ajout à une campagne) cherche **côté serveur**, par **pages de 20** : au-delà, on **tourne les pages** (« 1–20 sur 42 », « Page 1 sur 3 ») avec la même pagination que les listes de l'application — la liste complète du cabinet n'est jamais téléchargée. Elle n'apparaît qu'à partir de deux pages, et toute nouvelle recherche ramène à la première. Les **trois** popups de sélection la partagent : choix d'une épreuve, envoi à un candidat, ajout de candidats à une campagne. Ses lignes sont dessinées **comme celles du sélecteur d'épreuves** — filet coloré à gauche, nom puis e-mail, coche ronde à droite : choisir un candidat et choisir un test sont le même geste, les trois popups de sélection (envoi à un candidat, ajout de candidats à une campagne, choix d'une épreuve) se lisent pareil. La ligne *« Créer le candidat … »* garde son icône, pour rester une action et non un résultat.

Le **filet** dit la nature de la ligne : **corail** pour un candidat, **violet** pour un test, **vert** pour un questionnaire. Chaque liste est coiffée d'une étiquette qui dit ce qu'on regarde — *« Mes candidats »*, *« Tests officiels »*, *« Mes tests »*, *« Mes questionnaires »* : une liste nue laisserait deviner d'où viennent ses lignes. Dans le parcours de partage, où les onglets de portée sont masqués, cette étiquette porte seule la règle — on y lit *« Mes tests »*.

[capture d'écran : Actions d'une évaluation]

*Les actions d'une évaluation dépendent de son statut.*

#### Actions selon le statut

| Statut | Actions offertes |
|---|---|
| Invité | Copier le lien · Relancer · Prolonger · Révoquer |
| En cours | Copier le lien · Relancer · Prolonger · Révoquer *(le candidat est éjecté)* |
| Terminé | Voir le rapport, ou Corriger s'il reste des réponses libres |
| Expiré | Prolonger — la seule issue d'un lien mort |

| Règle | Comportement |
|---|---|
| Échéance | Entre **demain** et **un an** après l'envoi. Par défaut : 30 jours. |
| Expiration | Déduite de la date, jamais stockée : le lien cesse d'ouvrir, mais une session déjà commencée peut se terminer — sous la seule réserve d'une invitation envoyée en **passage en une seule fois** (§11), qui, elle, borne l'épreuve. |
| Déroulement figé | Le rythme et les mesures anti-triche choisis à l'étape ② sont **figés sur l'évaluation**. Aucune modification ultérieure — du test comme des réglages — n'atteint une invitation déjà partie (§11). |
| Relance | Exige un lien encore vivant 400 sinon. Prolonger envoie aussi la relance. |
| Unicité e-mail | Un e-mail = une fiche par cabinet 409. |
| CV | PDF ou Word (**.pdf, .doc, .docx**), 10 Mo max. Le contenu réel est vérifié — un fichier renommé est refusé 422, et le téléchargement (fiche comme partage) sert le vrai type du fichier. |
| Décision | À retenir / À revoir / Non adapté, posée sur l'évaluation, visible sur la liste et la fiche. |
| Suppression d'une fiche | Jamais bloquée — elle emporte évaluations, dossiers, copies, journal de surveillance et CV. |

## Déroulement du passage

Le **déroulement** — le rythme du passage et les mesures anti-triche — n'est pas une propriété du test : c'est un choix fait **à l'envoi**, puis **figé sur l'évaluation** comme le nom du test ou son niveau. Deux envois du même test peuvent donc se dérouler différemment, et un test **officiel** se règle sans être copié — c'était le but.

### Où le réglage se pose

| Envoi | Où |
|---|---|
| Envoi direct | Étape **②** de l'assistant d'envoi (§10), depuis la bibliothèque comme depuis la fiche candidat. Le réglage vaut pour **cette invitation**. |
| Lancement de campagne | Étape **①** de l'assistant « Lancer la campagne » (§9) : **un seul réglage** pour toutes les épreuves de type test du parcours. |
| Questionnaire | **Aucune étape** : l'assistant la saute. Un dossier déclaratif ne se chronomètre ni ne se surveille. |

### Rythme : reprise libre ou passage en une seule fois

La durée d'un test reste **déduite** de ses questions ; ce qui se choisit à l'envoi, c'est la manière dont le candidat la consomme. Le groupe *Rythme* rappelle la durée de l'épreuve retenue et porte une seule option.

| Réglage | Ce que vit le candidat |
|---|---|
| Reprise libre défaut | Seul le chronomètre de chaque question le limite. Il peut s'interrompre et revenir autant de fois qu'il veut — une session commencée reste ouverte aussi longtemps qu'il le faut. |
| Passage en une seule fois | Le temps court à partir du démarrage, sans pause possible : le candidat dispose de la durée du test **plus trois minutes**, d'un seul tenant. Ces trois minutes absorbent la lecture des consignes et l'autorisation de la caméra ; ce n'est pas du temps de réponse, et le recruteur n'a rien à régler. Au-delà, le serveur refuse toute nouvelle réponse et **clôt la session** avec les réponses déjà validées. |

### Mesures anti-triche : trois préréglages, puis le détail

| Préréglage | Contenu |
|---|---|
| Aucune | Passage libre, aucune mesure. |
| Standard | Plein écran + détection de sortie d'onglet. |
| Stricte | Standard + caméra, micro, captures, mélanges — et la **détection d'un passage repris ailleurs**. |

« Personnaliser les mesures » déplie la liste complète pour composer un réglage sur mesure. Les mesures sont **annoncées au candidat avant le départ** et son acceptation est horodatée.

### Les mesures disponibles

| Mesure | Effet pendant le passage |
|---|---|
| Plein écran forcé | Le passage s'ouvre en plein écran. |
| Détection de sortie d'onglet | Chaque sortie est journalisée comme incident. |
| Copier-coller bloqué | Le collage est refusé et journalisé. |
| Détection second écran | La présence d'un écran additionnel est signalée. |
| Détecter un passage repris ailleurs Stricte | Signale que le passage a continué depuis un **autre appareil** — le lien a été ouvert ailleurs. Le passage n'est **jamais bloqué** ; le rapport en porte la trace. Aucune adresse ni aucun matériel ne sont conservés en clair. Voir §15. |
| Caméra / micro obligatoires | L'autorisation est demandée au démarrage ; sans elle, le test ne commence pas. |
| Captures webcam périodiques | Photos à intervalle aléatoire, jointes au rapport. |
| Captures d'écran périodiques | Idem, sur l'écran du candidat. |
| Questions / options mélangées | L'ordre change d'un candidat à l'autre, de façon stable pour un même passage. |

#### Règles de gestion

| Règle | Comportement |
|---|---|
| Figé à l'envoi | Le réglage est **recopié sur l'évaluation** au moment où l'invitation part. Le serveur ne le relit jamais sur le test : modifier le test, le dupliquer ou le supprimer ne change **aucune** invitation déjà partie. |
| Jamais rétroactif | Corollaire : on ne « libère » plus un passage en cours en décochant quelque chose, et on ne l'enferme plus après coup. Pour changer le déroulement, on renvoie une invitation. |
| Deux envois, deux déroulements | Le même test peut partir surveillé et minuté chez un candidat, libre chez un autre. Aucun besoin de dupliquer le test — un **officiel** se règle donc aussi. |
| Héritage en campagne | Le réglage choisi au lancement est figé **sur la campagne**. Un candidat ajouté à une campagne en cours **hérite** de ce réglage sans qu'on le redemande : le dernier inscrit passe la même épreuve que le premier. |
| Réglage refusé | 400 `INVALID_SITTING_SETTINGS` : *passage en une seule fois* demandé sur une épreuve qui ne dure rien, ou tolérance technique hors de ses bornes API. En campagne, la validation est faite contre la durée de **chacune** des épreuves de type test. |
| Tolérance technique | Une tolérance de quelques minutes est incluse au-delà de la durée affichée — **elle n'est pas réglable** et n'apparaît nulle part dans l'interface. Le candidat n'a jamais qu'un seul chiffre en tête : la durée du test. |
| Ce que fait le dépassement | Le serveur termine la session lui-même : la copie est *rendue*, la durée réelle figée, l'évaluation passe à *Terminé* et les adresses en copie sont prévenues comme pour une remise normale. L'écriture qui a déclenché la clôture, elle, est refusée 409. |
| Ce que voit le candidat | L'accueil l'annonce avant tout engagement : « *Ce test se passe en une seule fois : une fois commencé, vous disposez de N minutes, sans pause possible.* » Rien ne s'affiche en reprise libre. Au dépassement, l'écran *Temps écoulé* confirme que **les réponses déjà validées ont été transmises**. Voir §14. |
| Aucune tâche planifiée | Rien ne tourne en fond : le dépassement se constate **à l'écriture suivante** du candidat. Une session abandonnée en cours de route reste « en cours » jusqu'à ce qu'il revienne — ou jusqu'à ce que le recruteur révoque l'invitation. |
| Durée vive, réglage figé | La limite effective se recompose à la lecture : réglage figé de l'évaluation + durée **vive** du test. Ajouter une question à un test allonge donc la limite des passages en cours — la durée, elle, reste dérivée. |

> **Deux horloges à ne pas confondre**
> 
> L'**échéance du lien** (§10) décide jusqu'à quand le candidat peut *ouvrir* son invitation ; elle n'interrompt jamais une session déjà commencée. Le **passage en une seule fois** décide combien de temps dure l'épreuve *une fois démarrée*. L'une gouverne l'accès, l'autre le chronomètre.

> **Le consentement est une preuve**
> 
> Un test surveillé ne démarre pas sans la case d'acceptation. L'horodatage du consentement est conservé avec l'évaluation : c'est la trace de l'information préalable du candidat. Le refus d'une capture non demandée se juge lui aussi sur le réglage **de l'évaluation**, jamais sur celui du catalogue.

[capture d'écran : Écran d'accueil du candidat]

*Ce que voit le candidat : les mesures annoncées une par une, et la case à cocher qui conditionne le départ.*

## Demandes & partages

Un client ou un expert externe travaille sur vos tests sans compte : un lien `/s/{token}` daté lui ouvre l'écran correspondant à ce qu'on lui demande. Trois natures, une seule table — et un écran qui les suit toutes, ouvert par le menu **Collaboration** (dernier groupe de la barre latérale, une seule sous-entrée *Demandes / Partages* — voir §4).

> **Le tiers voit la marque du cabinet**
> 
> Les deux surfaces publiques de ce chapitre — `/s/` (partage d'un test) et `/r/` (partage de candidats et de résultats) — portent le **logo** et le **nom** du cabinet en **en-tête** et dans le **titre de l'onglet** dès que le plan inclut la **marque blanche** (§19) ; le **pied du rapport imprimable** devient « *Rapport établi par {nom du cabinet}* … ». L'e-mail qui porte le lien part sous le **nom d'expéditeur** du cabinet. Sans la fonction, ou sans marque configurée, tout cela reste à l'identité **Evalixo**, sans erreur (§18).

| Nature | Ce que le tiers fait | Ce qui bouge chez vous |
|---|---|---|
| Relecture | Il consulte le test comme un candidat le verrait et rend un avis. | Rien : le test ne bouge jamais. |
| Édition | Il travaille sur une COPIE du test et vous la rend. | À l'acceptation, la copie remplace le contenu de l'original — qui garde son identité, donc ses envois passés et ses rapports. |
| Création | Il n'y a pas de test : il en compose un à partir de votre brief (intitulé, domaine, **métier visé** — facultatif, et soumis à la même règle d'ÉGALITÉ qu'un poste : le domaine du métier doit être celui du brief, sinon 422 `JOB_ROLE_DOMAIN_MISMATCH` —, niveau, consignes). | À l'acceptation, le test naît dans votre bibliothèque, avec les questions qu'il a écrites, et **hérite du métier du brief** (« Transversal » si vous n'en aviez pas fixé — un test en porte toujours un). |

Deux portes d'entrée. Depuis un **test** : le bouton *Partager* ouvre la popup sur ce test-là, en une seule feuille — au **pied de sa carte** comme sur sa **fiche**, catalogue officiel compris, les deux écrans offrant enfin le même geste. Depuis l'écran **Demandes / Partages** : *« Ajouter une collaboration »* propose d'abord la **nature** — **quatre** cartes, dans cet ordre : *« Faire relire ou modifier un test »* (cochée par défaut), *« Partager des candidats (avec ou sans résultats) »*, *« Partager une campagne »*, puis *« Commander un test »*. Relecture et édition n'ouvrent qu'**une seule porte** : après la nature, leur parcours était le même au mot près, et le **droit** — relecture ou modification — se règle de toute façon à l'étape suivante, sur la pilule qui le porte déjà. Deux cartes obligeaient à trancher le droit avant même de savoir sur quel test. Cet écran de nature **EST l'étape 1** du parcours (« 1/… » dans l'en-tête), et le **total suit la nature cochée**, sous les yeux : trois temps pour un test confié ou un résultat, deux pour une création. Pour un test confié : **2.** choisir le test dans le **sélecteur d'épreuves de l'application** — le même qu'à l'envoi à un candidat (recherche, filtres domaine et niveau, tri), ici verrouillé sur les *tests* et sur la *banque personnelle*, la pilule des droits au-dessus ; **3.** la popup « Partager le test », exactement celle de la fiche. *Retour* ramène au temps précédent sans rien perdre — le droit et le test restent cochés. Une création, elle, ne vise aucun test et va droit à son brief (2/2). La nature *« Partager des candidats (avec ou sans résultats) »* ne vise pas un test mais des **candidats** : elle enchaîne *« Choisir les candidats à partager »* — en **multi-sélection**, sur la liste ENTIÈRE des candidats du cabinet — puis la feuille « Partager des candidats » — voir « Partager des CANDIDATS à un tiers » plus bas. Son libellé **dit désormais que l'épreuve est facultative** : la nature acceptait déjà un profil sans test, mais « Partager des candidats » laissait croire qu'il fallait un résultat sous la main — ambiguïté devenue coûteuse depuis que la carte « campagne » vit juste à côté.

La **quatrième nature — « Partager une campagne »** — mène à la **même feuille** et à la **même collection** (l'onglet « Candidats et résultats partagés ») : ce qui la distingue n'est pas un réglage du partage, c'est la **nature de sa liste**. Elle est **vivante** — le vivier du parcours est relu à chaque ouverture du lien —, et cela se décide *avant* de choisir quoi que ce soit : d'où une carte à part plutôt qu'une case dans la précédente. Le parcours fait trois temps : **2.** *« Choisir la campagne à partager »*, un sélecteur paginé (vingt par page, recherche débouncée sur le nom du parcours, l'intitulé du poste et le client, ligne « n candidats · n terminés ») qui ne propose que les campagnes **LANCÉES ou closes** — un brouillon n'a encore personne à montrer, et le serveur le refuserait ; une campagne au vivier **vide** se voit mais ne se coche pas ; **3.** la feuille de partage **préremplie campagne** — aucune sélection de candidats, récap en lecture seule, encadré « La liste suit la campagne », et tous les réglages habituels (fiche, identité masquée, CV, avis, échéance, Consultation / Correction). C'est exactement la feuille qu'ouvre *Partager au client* depuis la fiche campagne : deux portes, un seul écran.

Les **droits** (relecture ou édition) ne se demandent **plus** à l'écran de nature : ils se posent à l'étape **2/3**, sur *Relecture* par défaut, et se revoient à l'étape **3/3** — la même pilule segmentée aux deux endroits. Le dernier choix fait foi où qu'il ait été fait : revenir de la feuille de partage vers le sélecteur remontre le droit effectivement retenu, et remonter jusqu'aux trois natures y trouve la carte du test confié cochée — le droit, lui, attend intact qu'on redescende. La **ligne créée**, elle, porte bien le droit effectif : elle atterrit dans *Tests partagés* en *relecture* ou en *édition*.

Le sélecteur ne borne pas le partage aux tests *envoyables* : un test encore incomplet ne s'envoie pas à un candidat, mais c'est précisément ce qu'on peut confier à un tiers pour qu'il le complète.

[capture d'écran : Popup de partage d'un test]

*Le partage lancé depuis un test : le commanditaire — un client du cabinet ou une adresse libre —, l'échéance du lien, la nature et le corrigé inclus ou non.*

> **La PORTE décide d'où l'on part, la NATURE du test décide de ce qu'on peut confier**
> 
> Un test **officiel** se partage — depuis le **pied de sa carte** au banc de tests, et depuis sa **fiche** — mais **en RELECTURE seulement**. Ce qui reste borné aux **tests personnalisés**, c'est le parcours *« Ajouter une collaboration »* : son sélecteur d'épreuves est verrouillé sur la banque du cabinet (fixedScope="mine"), parce qu'on y vient chercher quelque chose à faire **retoucher**. Quand cette banque est vide, la popup l'explique au lieu de proposer une liste vide. Ce cadrage-là est un choix d'écran ; la restriction sur l'**édition**, elle, est une règle de gestion, tenue par le serveur : il accepte la **relecture** d'un officiel depuis n'importe quelle porte, et refuse l'**édition** dès la création du lien (422 SHARE_INVALID), comme il refuse la **demande de retouche** qui s'ensuivrait (voir « Un test OFFICIEL se confie en RELECTURE seulement » plus bas).

### Les états, et qui doit agir

Le statut enregistre le dernier mot du tiers ; ce qui pilote l'écran, c'est **qui a la balle**.

| État | Qui doit agir | Où |
|---|---|---|
| En attente d'avis (relecture) | Le tiers : il doit rendre un **avis**. | Chez un tiers |
| En attente de la remise (édition, création) | Le tiers : il doit vous **rendre une copie**. Le mot suit la nature du lien — un tiers en édition n'a pas d'avis à donner. | Chez un tiers |
| Proposition reçue | Vous : accepter ou renvoyer — les deux gestes sont SUR la ligne du rendu. | Chez un tiers |
| Modifs demandées (relecture) | Vous : le tiers demande une correction (son message se lit dans le **fil**, sous la ligne). Une fois corrigé, *« Redemander un avis »* renvoie la balle. | Chez un tiers |
| Modifs demandées (édition, création) | Le tiers : vous lui avez renvoyé sa copie. | Chez un tiers |
| Validé / Appliqué / Accepté | Personne — mais le lien vit encore. | Chez un tiers, jusqu'à la clôture |

### L'écran Demandes / Partages

Il n'y a PAS de file « à traiter » séparée : une décision se prend là où elle se pose, sur la ligne du rendu. L'écran tient en deux temps.

- **Chez un tiers** — trois onglets, parce qu'ils ne se lisent pas de la même façon ; le compte vit sur l'onglet, et l'adresse dit lequel on regarde (`/collaboration/demandes`, `/collaboration/partages`, `/collaboration/resultats`) :
  - *Demandes* — l'ancien onglet « Commandes ». Une carte par demande, titre préfixé « Commande : », le cadre de la demande (domaine · métier · niveau) sous le titre — la consigne, elle, ouvre le **fil** que déplie la pastille d'état —, et le tiers occupe un BANDEAU corail pleine largeur — le corail est la couleur du TIERS, quelle que soit la nature du lien : trois lignes (« Commandé à », son nom, son adresse) à gauche, l'état et les gestes à droite. Sous le fil *« └ Test livré »*, une seule ligne : le nom de ce qui a été livré — ses chiffres au survol — puis « Ouvrir le test » une fois accepté, ou « Demander une modif » et « Accepter » tant que le rendu attend votre décision. Rien encore livré : un cadre pointillé dit ce qu'on attend et depuis quand.
  - *Tests partagés* — groupés PAR TEST : la carte du test une seule fois, COUCHÉE sur une ligne (identité à gauche, la signature du test au centre — questions, durée, niveau, type —, « Ouvrir le test » à droite), puis un bandeau par destinataire — le MÊME composant que sur une commande, avec la nature du partage (Relecture, Édition) collée au nom. Sur un rendu, les deux gestes de décision y figurent aussi ; après un verdict, « Redemander un avis ».
  - *Résultats partagés* — les **rapports de candidats** confiés à un tiers, groupés **PAR RAPPORT** comme les tests le sont par test : une carte par rapport, ses destinataires en dessous. En tête de carte, la signature du rapport — l'**anneau de score miniature** (mêmes seuils de couleur que le rapport, pourcentage au centre), le nom du **candidat** derrière un mini-rail **corail** (la couleur d'une personne) et celui de l'**épreuve** derrière un mini-rail à la **couleur de la bibliothèque** (violette par défaut, réglable — voir Apparence), puis la ligne de détail « 36/53 pts · ce qu'il reste à corriger » (ambre tant qu'il en reste, neutre une fois tout corrigé) et « Ouvrir le rapport ». Puis *« └ Partagé à N tiers »* et une ligne par lien : le MÊME bandeau destinataire que partout, la puce du droit (Consultation, Correction), la trace d'ouverture au survol des initiales, l'état du lien et ses gestes. Le compte de l'onglet est celui des **rapports**, pas des e-mails partis. *Ce qu'il reste à corriger appartient au RAPPORT, pas au lien* : il se lit une fois, en tête de carte, et non répété sur chaque destinataire. Les partages d'une **même campagne** se regroupent dans **UNE carte** : le nom de la campagne en titre, une ligne de provenance « **Campagne — liste vivante** » qui **mène à la fiche de campagne**, et un bandeau par destinataire. La ligne « **Partagé au tiers :** 3 candidats · 5 épreuves » se **déplie** en **deux listes nommées** — « **Candidats :** » et « **Épreuves :** » — qui disent *qui* part et *quel test* : la seconde ne paraît pas quand le partage ne porte aucune épreuve (une liste de profils est un partage légitime). L'**origine** ne se dit plus sur les bandeaux : dès qu'**au moins un** lien de la carte est né d'une copie d'envoi, une **chipsette** « **Créé(s) automatiquement (copie d'envoi)** » se lit **en tête de carte**, au compte des liens concernés — un groupe mixte garde donc sa trace d'origine. Chaque **bandeau destinataire** porte en revanche ses **conditions à lui**, en petites puces neutres et seulement celles qui sont vraies : *Fiche jointe*, *Identité masquée*, *CV*, *Surveillance*, *Avis demandé* — deux tiers du même envoi peuvent recevoir deux choses différentes, et rien ne le disait.
- **Terminé** — replié par défaut, sous les onglets : les liens morts, clôturés ou expirés, **des trois onglets à la fois** (c'est une étagère de l'écran, pas d'un onglet), avec le dernier avis du tiers et la date de fin. La **clôture** laisse elle aussi son jalon dans le fil du partage.

**Tout se pagine par dix** — chaque onglet ET l'étagère des clôturés (une seule liste à l'œil, les deux collections comptées ensemble). La pagination n'apparaît qu'au-delà de dix : en dessous, rien à naviguer.

### Les deux façons de finir

| Geste | Effet |
|---|---|
| Clôturer | À tout moment, quelle que soit la nature. Le lien meurt (échéance anticipée) et la ligne descend dans « Terminé » en gardant le dernier avis. Elle ne se prolonge plus : pour reprendre, on repartage. Si le tiers avait un chantier ouvert, sa copie et les questions qu'il avait écrites sont abandonnées — la popup l'annonce, chiffre à l'appui. |
| Révoquer (supprimer) | La ligne disparaît et le lien meurt : il ne reste aucune trace de la collaboration. Pour la garder dans l'historique, il faut clôturer. |
| Le score de la carte | Le score d'un rapport reste **dérivé** — recalculé à la lecture, réponse par réponse, à partir du barème de chaque question, jamais stocké. La liste des partages le sert désormais (scorePercent / scoreEarned / scoreMax sur GET /api/result-shares) : la carte porte l'**anneau miniature** — pourcentage au centre, seuils de couleur du rapport, provisoire tant qu'il reste des questions à corriger — et les points se lisent sur la ligne de détail (« 36/53 pts · À corriger : n »). Une épreuve purement **déclarative** n'a pas de score : la carte garde alors le repère neutre dont l'infobulle renvoie au rapport. |
| Le doublon n’est plus refusé (V20) | Une garde refusait autrefois deux liens vivants du **même rapport** vers la **même personne** (409 SHARE_ALREADY_ACTIVE), sur les trois gestes qui pouvaient la créer — créer, prolonger, rouvrir. Elle a été **retirée avec la règle qu’elle protégeait** : un partage porte désormais une SÉLECTION de candidats, et deux sélections qui se recoupent partiellement sont la situation normale. Le code existe toujours pour le partage d’un **test**, où la règle garde son sens — et il sert de nouveau au partage d’une **CAMPAGNE**, sur un critère exact cette fois (cabinet, adresse, campagne, origine manuelle) : voir « Le doublon d’une CAMPAGNE, lui, est refusé ». |
| Rouvrir un rapport partagé | Comme un test partagé : une ligne **clôturée** se remet en route sous une nouvelle échéance, et « Rouvrir » prend la place de « Prolonger » dans son menu. Aucun avertissement ici — il n'y a pas de chantier à perdre, et les **corrections déjà posées par le tiers restent acquises au rapport** quoi qu'il advienne du lien. La réouverture est soumise à la même garde anti-doublon. |
| Rouvrir (une clôture n'est plus un aller simple) | Une ligne **clôturée** se remet en route : le lien redevient valable jusqu'à une **nouvelle échéance** (obligatoire, forcément future), le tiers est prévenu par e-mail, et la ligne remonte de « Terminé » vers « Chez un tiers ». Le geste **remplace « Prolonger »** sur une ligne close : un lien rangé ne se prolonge pas, il repart — les deux ne coexistent jamais dans le menu. Il n'est PAS offert sur une ligne simplement **expirée** (elle, se prolonge), ni sur une **commande déjà acceptée** : sa copie est dans la bibliothèque, il n'y a plus rien à attendre. |
| Le chantier abandonné ne revient pas | La clôture d'une **édition** ou d'une **création** jette la copie du tiers et les questions qu'il avait écrites. Rouvrir ne les ressuscite pas : un brouillon **NEUF** est rebâti — la copie actuelle du test pour une édition, une page blanche pour une création — et le partage repart « En attente de la remise ». La popup de réouverture le dit **avant** de confirmer, dans un encadré ambre. Une **relecture** n'avait pas de chantier à perdre : elle garde son dernier verdict, et la popup n'affiche aucun avertissement. |

| Règle | Comportement |
|---|---|
| Périmètre | Relecture et édition portent sur un test — **personnalisé ou officiel**. Seul le parcours *« Ajouter une collaboration »* se borne à la banque du cabinet (voir l'encadré plus haut) ; les deux autres portes — pied de carte du banc de tests, fiche du test — offrent aussi le catalogue. La **nature** du test décide de ce qu'on peut confier : un test **personnalisé** se confie en relecture COMME en édition, un test **officiel** en **relecture SEULEMENT** — l'édition est refusée dès la création du lien (422 SHARE_INVALID). Sur un officiel, le tiers valide ou commente ; il ne demande pas de retouches et ne propose pas de réécriture. Création : aucun test visé, un brief. |
| Banque personnelle vide | L'étape « Choisir un test à partager » ne tend pas une liste vide : elle affiche la règle dans un **encadré d'information** (« Seuls vos tests personnalisés peuvent être partagés… ») — une règle du produit, pas une micro-aide sous le champ. Une *recherche* qui ne trouve rien reste, elle, un simple « aucun résultat ». Ni l'un ni l'autre ne s'affiche **tant que le serveur n'a pas répondu** : on ne commente pas un vide qu'on ne connaît pas encore. |
| Retrouver ce qui est confié | Le sélecteur de tests porte un filtre **Collaboration → « En collaboration »**, offert sur **vos tests seulement** — c'est une facette de la banque du cabinet, pas du catalogue ; un officiel confié se retrouve, lui, par l'écran *Demandes / Partages* — : il ne garde que les tests ayant au moins un partage *encore vivant*. Il se combine à la recherche, aux filtres et au tri. Chaque ligne concernée porte en plus une **puce corail** avec la ou les natures en cours — « Relecture », « Édition », « Création », ou plusieurs séparées d'un point médian. |
| « Encore vivant », au sens exact | Ni **clôturé** par vous, ni passé son **échéance** — mot pour mot ce que l'écran Collaboration range sous « Chez un tiers », le reste étant descendu dans « Terminé ». Révoquer supprimant le partage, il n'y a rien à exclure de ce côté. Une **commande** n'y entre que **livrée et acceptée** : avant cela elle ne vise aucun test. |
| Le choix des droits | Une **pilule segmentée** — *Relecture* / *Édition* — où chaque segment porte la **pastille de sa nature** (vert relecture, violet édition), visible des deux côtés : le code couleur est celui des puces de l'écran Collaboration. Le segment retenu prend le fond teinté de sa nature, et une ligne sous la pilule dit ce que le droit engage. Le même sélecteur sert **partout** — depuis la fiche d'un test comme aux deux étapes du parcours Collaboration. |
| Ce que dit la popup de partage | La phrase d'en-tête suit les **droits** choisis et change à la bascule : en relecture, « le tiers consulte le test et rend son avis — il ne le passe pas » ; en édition, « il travaille sur une COPIE et vous la rend — l'original reste intact tant que vous n'acceptez pas ». Le **corrigé** ne s'offre qu'en relecture : passer en édition retire la bascule. |
| Banque du tiers | En édition et en création, il pioche dans le catalogue officiel et la banque du cabinet, bornés au domaine demandé, plus les questions qu'il écrit lui-même. Celles-ci restent hors banque jusqu'à l'acceptation. **Cette règle est énoncée UNE fois**, dans le descriptif de la nature « Commander un test » de la popup « Ajouter une collaboration » — au moment où l'on décide. L'encadré qui la répétait dans le formulaire de commande a disparu : il arrivait après le choix, et les deux textes avaient fini par se contredire (l'un fermait la banque du cabinet, l'autre l'ouvrait au domaine demandé). |
| Le tiers ne choisit ni le MÉTIER ni les DOMAINES | Sur un chantier d'**édition**, le domaine était déjà imposé par la demande et affiché épinglé — mais le sélecteur de **métier** restait ouvert, et l'écran **remplace les domaines** quand on change de métier (règle de cohérence métier ↔ domaines, §6) : l'interdiction se contournait par la porte d'à côté. Le métier s'affiche donc désormais en **lecture seule** chez le tiers — même puce, même cadenas que les domaines, infobulle *« Métier fixé par la demande — il ne se change pas ici »*. La vraie raison n'est pas la cohérence mais le **contrat de la remise** : ni le métier ni les domaines n'ont JAMAIS été transmis au serveur depuis un chantier de tiers. Ce qui remonte, c'est la **COMPOSITION** — nom du test, questions et leur ordre. Le geste ne produisait donc aucun effet et laissait croire le contraire. Corollaire : le métier ne peut plus **bloquer un enregistrement** côté tiers (il sort de la liste des champs obligatoires) — un champ qu'on ne peut pas remplir ne doit jamais retenir un « Enregistrer ». |
| Corrigé | Relecture seulement, masqué par défaut : le recruteur décide à l'envoi. En édition, le tiers compose — le corrigé lui est servi pour choisir. |
| Verdict | *Valider* ou *Demander des modifications* — le commentaire est alors obligatoire. Le tiers garde la main jusqu'à l'échéance : le dernier verdict fait foi, horodaté. |
| Un test OFFICIEL se confie en RELECTURE seulement | Le partage d'un test du **catalogue** était interdit par l'écran : il fallait d'abord en faire une copie privée. La restriction n'avait aucune justification pour la **relecture**, et elle bloquait un geste courant — *« je vous propose ce test standard, ça vous va ? »*. Elle est **levée pour la relecture** : « Partager » figure au pied de chaque test du catalogue, à côté de *+ Ajouter* / *Ma copie*, **et sur la FICHE du test**. En revanche l'**ÉDITION d'un officiel est refusée**, et elle l'est **à la création du lien** : 422 SHARE_INVALID. **Pourquoi :** confier un test en édition, c'est promettre au tiers que sa copie **REMPLACERA l'original** à l'acceptation. Or le catalogue **appartient à toute la plateforme** — il n'a pas de propriétaire, aucun cabinet n'a le droit de l'écrire (403 OFFICIAL_ITEM_IMMUTABLE) : la copie rendue **n'aurait personne pour l'adopter**, et le tiers aurait travaillé pour rien. Deuxième raison, aussi lourde : le tiers écrit ses questions dans la banque du **cabinet** ; les adopter ferait entrer de la matière **privée** d'un tenant dans un test que **tous** les cabinets lisent. Pour pouvoir retoucher, on ajoute d'abord le test à ses tests et on partage **sa copie** : elle, se réécrit. Ce qui reste vrai pour le tiers en relecture : il peut **valider** et **commenter**, jamais **demander des retouches** — la demande mettrait le cabinet devant une requête qu'il n'a pas le droit de satisfaire, un état sans issue que seule une révocation effacerait. La règle est dite **trois fois**, à trois niveaux : la feuille de partage n'offre plus la bascule sur un officiel (« Relecture — un test du catalogue ne se confie pas en édition ») et retombe sur *Relecture* même si un parcours amont avait pré-choisi *Édition* ; la page du tiers ne montre que « Valider » et écrit pourquoi (SharedTestDto.canRequestChanges porte la règle, jamais la taxonomie — le tiers n'a aucune raison de savoir ce qu'est un « test officiel ») ; et le serveur REFUSE. Un écran n'est jamais la seule autorité sur une règle. Sur une **copie privée**, rien ne bouge : édition et demande de retouche restent ouvertes. |
| Deux gardes serveur, pas une | La règle « un officiel ne se réécrit pas » est tenue à **deux endroits**, volontairement redondants. **À l'entrée** : la création d'un partage en *Édition* sur un officiel est refusée en 422 SHARE_INVALID, **avant tout effet de bord** — aucune ligne de collaboration, aucune copie de travail, aucun e-mail ne naît d'un geste sans issue. **Au point d'écriture** : l'**acceptation** d'un rendu dont la cible serait un officiel est refusée en 403 OFFICIAL_ITEM_IMMUTABLE, la même garde que toute écriture sur le catalogue. La seconde peut sembler inutile puisque la première interdit d'y arriver : c'est précisément la leçon du défaut qu'elle corrige. Une règle d'**intégrité** ne doit pas dépendre du seul chemin qui l'a violée — l'écran du tiers refusait déjà de « demander des retouches » sur un officiel, mais le chemin qui **ÉCRIT**, lui, n'avait aucune garde, et le partage en édition le traversait sans rencontrer personne. |
| Redemander un avis | La SUITE d'une relecture : le tiers a tranché, vous avez corrigé le test. Le geste ouvre une **popup** avec un **mot facultatif** pour le tiers — sans lui, il recevait un rappel sans savoir CE QUI avait changé depuis son passage ; le champ ne bloque rien, une relance sans commentaire reste possible. Le mot rejoint le **fil** (bulle *« redemande un avis »*). Le partage repart en attente d'avis et l'e-mail repart avec lui ; tout l'historique reste lisible sous la ligne. Disponible après un *Validé* comme après un *Modifs demandées*, tant que le lien vit. L'édition et la commande n'en ont pas besoin : leur aller-retour est déjà modélisé (renvoyer la copie, le tiers reprend la main). |
| Accepter quand même | Vous avez renvoyé la copie d’un tiers (édition ou commande), puis vous changez d’avis : elle vous convient telle quelle. La ligne en *« Modifs demandées »* porte alors **« Accepter quand même »** — le libellé le dit, « Accepter » tout court ferait croire qu’on adopte une nouvelle version qui n’existe pas. Sans ce geste, la seule issue était d’attendre un nouveau passage du tiers, pour rien. Le geste est le MÊME que depuis l’examen d’un rendu (la copie rejoint la bibliothèque). Il n’a de sens que là où une copie EXISTE : jamais sur une relecture, jamais sur un lien mort. |
| L'attente se dit selon la NATURE | Un lien en attente n'attend pas la même chose selon ce qu'on a confié : une **relecture** attend un *avis* (« En attente d'avis »), une **édition** ou une **commande** attendent qu'on vous *rende* quelque chose (« En attente de la remise »). Le libellé suit donc la nature du partage, partout où l'état s'affiche. (Auparavant : une commande en cours annonçait « En attente d'avis », alors que le tiers n'a aucun avis à rendre.) |
| Atterrir là où l'objet est parti | Après une création depuis *« Ajouter une collaboration »*, l'écran s'ouvre sur **l'onglet correspondant** — une commande sur *Demandes*, une relecture ou une édition sur *Tests partagés*, un rapport sur *Résultats*. Rafraîchir l'onglet qu'on regardait laissait croire que rien ne s'était passé : la nouvelle ligne était sur un autre onglet. |
| Une couleur, un état | L’état d’un partage porte la MÊME teinte partout où il s’affiche — lignes de l’écran Collaboration, panneau des partages d’un test, pages publiques : **Validé** et **Appliqué** en **vert**, **Copie rendue** à la **couleur de la bibliothèque** (violette par défaut — il y a une copie de test à lire), **Modifs demandées** en **ambre** (quelque chose vous attend), **En attente d’avis** en neutre. Un picto double la couleur, pour qui ne la distingue pas. La table vit à UN endroit (styles/_pills.scss) : un état ne peut pas être vert ici et gris là. |
| « Copie rendue », des deux côtés | Le tiers lit *« Copie rendue »* sur son écran après avoir remis son travail ; le recruteur lit le MÊME mot sur sa ligne. (Auparavant : « Proposition reçue » côté recruteur.) |
| Un FIL de conversation, pas un dernier mot | La pastille d’état devient **cliquable** (chevron, aria-expanded, accessible au clavier) et déplie **sous la ligne** le **fil complet** des échanges : des **bulles datées** du plus ancien au plus récent, corps coupé à trois lignes. Auparavant, seul le *dernier* commentaire s’affichait — au deuxième aller-retour, ni le recruteur ni le tiers ne savait plus ce qui avait été demandé au premier. Le **même dessin des deux côtés du lien** : la page du tiers (relecture comme édition/commande) montre exactement le même fil. L’infobulle au survol a disparu — elle tronquait la pensée du tiers, s’échappait au clavier et interdisait le copier-coller. |
| Ce que porte une bulle | Surtitre *« {AUTEUR} · {date} — {ce qu’il a fait} »* : *« demande des modifications »*, *« a validé »*, *« redemande un avis »*. Une simple **note** ne s’annonce pas — le nom et la date suffisent. Les sauts de ligne sont conservés. |
| Un seul dessin de bulle | Toutes les bulles ont le **même fond discret**, quel que soit l’auteur ou la nature du message — pas de rail vertical, pas d’aplat coloré. C’est le **NOM** qui porte la couleur : le **tiers** en corail-ambre (la teinte de l’externe dans toute l’application), le **cabinet** en violet (celle des tests et de l’édition). Un aplat ambre sur les seules demandes de modifications faisait deux styles de bulle dans un même fil : on y lisait deux encadrés qui se répondent, pas une conversation. Seule l’*étiquette* « — demande des modifications » garde l’ambre. |
| Les JALONS du partage | Entre les bulles, à leur date, des lignes sobres à pastille de couleur qui disent ce qui s’est **produit** plutôt que ce qui s’est dit : *« Copie rendue par {adresse} · {date} »*, *« Partage clôturé · {date} »*. Elles sont **dérivées des champs du partage**, pas des messages — un partage peut donc avoir une histoire sans que personne n’ait écrit un mot. |
| Le mot de création est CONSERVÉ | Le « message d’accompagnement » saisi à la création d’un partage ou d’une commande n’est plus perdu après l’envoi de l’e-mail : il rejoint le fil, attribué au recruteur. Le tiers le relit à tout moment, le recruteur aussi. |
| La CONSIGNE est le premier échange | Sur une **commande**, le brief n’est plus un encadré à part : il ouvre le fil, en **première bulle** (auteur : le recruteur), suivi du mot d’accompagnement. C’est bien ce qu’une consigne est — quelque chose que quelqu’un a écrit, à une date —, et elle se lit donc comme le reste, avec son auteur, son horodatage et sa coupe à trois lignes. Il n’y a plus d’encadré de consigne ni côté tiers (l’écran d’édition/commande) ni sur la carte de commande de l’écran Collaboration. Ce qui RESTE de part et d’autre, c’est le **cadre** de la demande : intitulé · domaine · métier visé · niveau visé. Sur la carte de commande, la pastille d’état s’ouvre comme sur un test partagé pour dérouler ce fil. |
| Rendre sa copie avec un mot | La fenêtre de confirmation « Rendre votre copie ? » propose au tiers **un mot pour le recruteur, facultatif** — il a souvent quelque chose à signaler en rendant (« j’ai laissé de côté la partie réseau, faute de matière »), et il n’avait aucun endroit où l’écrire. Le champ ne bloque rien : une remise muette reste le geste normal. Le mot rejoint le fil, **après** le jalon « Copie rendue ». |
| Une copie RENDUE est figée | Après *« Rendre ma copie »*, l'écran du tiers ne disparaît pas — il relit ce qu'il a livré — mais il passe **entièrement en lecture seule** (SUBMITTED comme APPLIED). Seuls les trois boutons *Enregistrer* / *Aperçu* / *Rendre* s'effaçaient jusqu'ici : tout le reste du builder répondait encore. Le tiers pouvait renommer le test, forcer le niveau annoncé, réordonner et supprimer des questions, en ajouter depuis la banque, et même en **ÉCRIRE une nouvelle** — laquelle partait au serveur pour s'y faire refuser, sans qu'aucun bouton ne puisse plus enregistrer quoi que ce soit. **Le serveur a toujours été correct** (il refuse toute écriture sur un partage déjà rendu) ; c'est l'écran qui mentait, et un écran ne doit jamais offrir un geste dont le seul destin est d'être perdu en silence. Un **bandeau** l'annonce — *« Votre composition reste consultable ci-dessous, mais elle n'est plus modifiable »* — sous le titre qui distingue les deux fins : **« Copie rendue »** (le recruteur l'examine, il peut encore la renvoyer) et **« Copie acceptée »** (elle a rejoint la bibliothèque du cabinet). Sous **1024 px**, l'onglet *Banque* disparaît en même temps que la colonne qu'il ouvrait, et le volet retombe sur *Test* : un onglet choisi AVANT la remise aurait laissé le tiers devant une colonne vide, sans rien pour en revenir. |
| On NOMME la personne | Jamais « le recruteur » ni « le client » : chaque bulle porte un **nom**, **figé au moment où le message a été écrit** (un renommage ultérieur ne réécrit pas l’histoire). Si ce nom stocké est vide, un repli propre à l’écran s’applique : côté **recruteur**, un message du tiers prend le nom du **client** destinataire, à défaut son **adresse** ; côté **tiers**, un message du cabinet prend le nom de la **société** (companyName). En dernier recours seulement, un tiret — jamais un rôle générique. |
| Trois lignes, puis « Afficher plus » | Tout message d’échange — bulle du fil, **consigne d’une commande** — se coupe à **trois lignes** avec *« Afficher plus » / « Réduire »*. Le bouton n’apparaît que si le texte **déborde réellement** (mesuré, pas deviné). La mesure est **continue** et non prise une fois pour toutes : elle est refaite quand les **polices** de la page ont fini de charger et à chaque **changement de largeur**. Sans quoi, sur une page chargée à froid (celle du tiers), le premier rendu se faisait avec la police de repli, un texte de quatre lignes en tenait trois, et la consigne restait coupée **sans bouton pour l’ouvrir**. Un seul composant porte ce motif partout. |
| Les sauts de ligne sont de l’information | Un message écrit en trois paragraphes se lit en trois paragraphes — de la saisie à la base (TEXT, seul un trim aux extrémités) jusqu’à l’écran de l’autre côté (white-space: pre-line), dans les DEUX sens. |
| Ouverture | La première ouverture du lien est horodatée. L'information se lit au survol de la pastille d'initiales du tiers — « Partagé le … · Jamais ouvert » —, ce qui rend la relance sensée sans alourdir la ligne. |
| Fin de vie | Le lien meurt à l'échéance, à la clôture, ou immédiatement si le partage est supprimé. **Prolonger** ressuscite un lien EXPIRÉ ; **Rouvrir** remet en route un lien CLÔTURÉ (sauf commande déjà acceptée). Seule la révocation est sans retour. |
| Indépendance | Un partage ne verrouille rien : le test reste modifiable et supprimable. |

### Partager des CANDIDATS à un tiers

Le partage précédent porte sur un **test** — un sujet à relire ou à composer. Celui-ci porte sur des **candidats** : des personnes, et ce qu'elles ont rendu. Le lien public est `/r/{token}`, daté, opaque et anonyme, sur le même modèle que `/s/` et `/t/` : le token est le seul identifiant, le tenant est lu sur la ligne du lien, jamais sur un jeton d'authentification.

**L'unité a changé.** Jusqu'ici un partage montrait UN rapport : un candidat, une épreuve. Trois demandes qui semblaient distinctes — *plusieurs résultats*, *une campagne*, *une liste de profils sans test* — se sont révélées être le MÊME objet : des candidats portant 0..n épreuves. Une seule structure les couvre, aucun objet nouveau n'a été ajouté au produit, et le partage d'un rapport isolé en est devenu le **cas dégénéré** (un membre, une épreuve, aucune commande de navigation) : les liens déjà envoyés s'ouvrent à l'identique. Le mot **« épreuve »** est celui du parcours de campagne — un test rendu et un dossier de questionnaire reçu entrent par la même porte : « rapport » exclurait le questionnaire, « dossier » se confondrait avec la fiche du candidat.

| Règle | Comportement |
|---|---|
| Points d'entrée | Quatre. **Candidats** → le bouton **« Partager des candidats »** arme un mode de cases : la barre d'action « n candidats sélectionnés » ouvre la feuille. Il s'appelait *Sélectionner* et ne disait pas POUR QUOI — on arrivait sur l'écran sans savoir qu'on pouvait y présenter des profils à un tiers ; l'encadré d'information de la page bascule en outre sur l'INSTRUCTION dès que le mode s'arme. La barre est **FIXE** au bas de la fenêtre : en « sticky » elle se collait au bas de son CONTENEUR et remontait au milieu des cartes dès que la liste dépassait l'écran — elle en recouvrait une. **Fiche campagne** → *Partager au client* (dès qu'elle est lancée et qu'elle a un inscrit). **Collaboration** → *Ajouter une collaboration*, nature *« Partager des candidats (avec ou sans résultats) »* — ou, pour un parcours entier, la nature *« Partager une campagne »*, qui ouvre la MÊME feuille préremplie que la fiche campagne. Et les deux chemins historiques d'un rapport isolé : le bouton *Partager* du bandeau d'un rapport, l'action *« Partager le résultat »* du menu **⋯** d'une épreuve — inchangés, ils produisent un partage à un membre. Hors mode sélection, la liste des candidats reste ce qu'elle était : aucune case parasite sur une page qu'on vient consulter, et sortir du mode **oublie** la sélection (la garder ferait repartir un partage avec des gens choisis pour autre chose). |
| La SOURCE décide si la liste bouge | Deux sources, exactement l'une des deux. Une **campagne** : les membres SONT son vivier et les épreuves celles du parcours, **relus à chaque ouverture du lien** — un candidat inscrit demain apparaît chez le tiers sans geste du recruteur, une copie rendue demain aussi. La feuille le dit (« La liste suit la campagne ») et passe son récap en **lecture seule** : c'est le vivier qui fait foi. Une **sélection à la main** : la liste est ce qui a été coché, et rien ne la fait bouger toute seule. Les deux à la fois sont refusées (SHARE_INVALID, 422) — il faudrait dire laquelle l'emporte le jour où le vivier change. Corollaire assumé : on ne retire pas quelqu'un d'un partage de campagne ; pour un sous-ensemble, on fabrique une sélection. |
| Composer la sélection — on coche des PERSONNES | Dans *Ajouter une collaboration*, l’étape s’appelle « **Choisir les candidats à partager** » et liste **TOUS les candidats** — exactement la liste de l’écran Candidats, mêmes pages de 20, même recherche débouncée sur prénom+nom, e-mail et nom d’épreuve. **C’est un changement d’UNITÉ, pas de vocabulaire** : on y cochait des *rapports* (`status=completed` + `hasResult=true`) là où l’écran Candidats coche des *personnes* — deux réponses à la même question selon la porte empruntée, et surtout l’impossibilité de partager d’ici une **liste de profils sans test**, pourtant l’un des trois cas d’usage. La ligne du candidat se coche ; ses **épreuves rendues partent avec lui**, et le tri de ce qu’on montre se fait ensuite dans le récap de la feuille — une seule question par écran. Un candidat à plusieurs épreuves se **déplie** par un chevron séparé : *déplier n’est pas choisir*, et ce qui s’ouvre est en LECTURE. Re-cliquer une ligne la **décoche**. Le groupement par candidat n’est plus une précaution d’écran, il est **structurel**. |
| La règle « ce qu’un candidat apporte », écrite UNE fois | Deux chemins la posent désormais (la liste des candidats et Collaboration) : elle vit donc dans le modèle du partage et se réutilise telle quelle, jamais réécrite en face — deux copies auraient divergé. Seules les épreuves **RENDUES** entrent, test et dossier confondus. Corollaire d’un défaut trouvé à cette occasion : le sélecteur bâtissait sa liste sur `resultId`, donc sur les TESTS seuls — un **dossier de questionnaire reçu** n’en a pas, il partait avec le candidat *sans que la ligne l’annonce*, et l’écran pouvait afficher « aucune épreuve rendue » sur quelqu’un qui en apportait une. Il lit maintenant le même critère que le partage ; `resultId` ne décide plus que de l’anneau de score. |
| L’onglet et les mots | *« Résultats partagés »* devient **« Candidats et résultats partagés »** : le nom dit les DEUX, l’ancien laissant croire qu’un profil sans test n’y avait pas sa place. Les trois onglets de Collaboration portent en outre un **encart explicatif permanent** — ils se ressemblent et ne racontent pas la même histoire ; chacun dit ce qu’on regarde ET d’où ça vient. Permanent et non masquable : un texte qu’on masque une fois ne réexplique jamais, et c’est justement quand on doute qu’on en a besoin. Enfin, sur un profil sans épreuve ni CV, la feuille dit **« seule la fiche sera partagée »** plutôt que d’énumérer deux manques. |
| Le RÉCAP dépliable — le cœur de la feuille | On ne coche pas une catégorie qu'on ne voit pas : la feuille montre **ce qui part**. Un candidat par ligne, dépliable sur ses épreuves, chacune **décochable** (« elle s'est plantée au Frontend, je ne montre que le Java » est un geste de short-list, pas un raffinement), et une mention *« CV joint »* / *« pas de CV »* qui évite de promettre un CV que deux candidats sur trois n'ont pas. Le compteur en tête compte **ce qui PART**, jamais ce qui existe : décocher une épreuve le fait baisser. |
| Un candidat SANS épreuve est légitime | Partager une **liste de profils** — sans aucun test — est un des trois cas d'usage, pas une donnée manquante. La feuille l'affiche (« Aucune épreuve rendue »), la page publique aussi (« Ce candidat vous est présenté sur sa fiche seule »). Une invitation encore ouverte n'apparaît nulle part : on ne montre que ce qui a été **rendu**. |
| Ce que le tiers verra — cinq réglages, plus la surveillance | **La fiche candidat** (activée par défaut) : poste recherché, ville, disponibilité, LinkedIn — **jamais** les notes du recruteur, ni les recrutements, ni la facturation ; ce ne sont pas des oublis, c'est la définition de la vue. **Masquer l'identité** (désactivé). **Joindre le CV** (désactivé). **Inclure la surveillance** (activée — le recruteur retire, il n'a pas à penser à ajouter), et sous elle **les captures webcam**. Le cinquième n’est pas une visibilité mais une **question posée** : **Demander un avis** (activé — voir plus bas). Ce sont des décisions de *politique* : elles valent pour tout le monde d'un coup, là où le récap choisit pièce par pièce. |
| Le CONTENU de la fiche — quatre sous-réglages | Sous « Inclure la fiche », le partage choisit désormais **ce qui la compose** : la **synthèse du cabinet** (cochée), les **conditions** — contrat, télétravail, mobilité — (cochées), les **compétences** et leurs niveaux (cochées), et les **prétentions salariales** — **décochées** par défaut : la donnée est sensible et chaque cabinet a sa pratique, on ne la présume pas. Fiche décochée ⇒ **rien** de tout cela ne part, quoi que disent les sous-cases. Les **liens déjà envoyés** n'exposent rien de plus qu'avant : les quatre réglages naissent à FAUX en base, seuls les nouveaux partages portent les défauts produit. Le statut, les tags et l'activité de la fiche ne sortent **jamais**. |
| La synthèse sous identité masquée — on prévient | La synthèse est du texte libre : si celle d'un candidat contient un morceau de **son propre nom**, « Candidat A » ne masque plus rien. La feuille le détecte et l'écrit — *corrigez-la ou passez en identité visible* — mais ne bloque jamais : même doctrine que le CV. |
| « Masquer », jamais « anonymiser » | Le réglage remplace le nom par **« candidat A », « candidat B »…** à la *position* du membre — position **stockée**, si bien que deux ouvertures du même lien ne renomment jamais personne et que le tiers peut dire « le candidat C » à son collègue. Le masquage est fait **à la source** : e-mail, téléphone et LinkedIn ne sont pas mis dans la réponse, et le **rapport lui-même** est rebâti sans nom, sans e-mail et sans identifiant de candidat — masquer la fiche en laissant le rapport nommer son auteur n'aurait rien masqué. Ce qui reste est ce qui fait juger un profil sans le nommer : poste, ville, disponibilité, et la totalité de la copie. **Le produit ne promet pas l'anonymat** : une réponse libre qui raconte « je faisais ça chez Decathlon » n'est pas nettoyable — d'où le mot du réglage. |
| Le CV : on prévient, on ne bloque pas | Le CV porte l'identité **même sous masquage**. La feuille **avertit** (bandeau ambre : « Le CV porte l'identité du candidat : le masquage ne s'y applique pas ») et laisse faire — un CV anonymisé par le cabinet lui-même est un livrable courant, et l'humain tranche. Le fichier ne descend que par la porte du partage : **404** quand le lien ne le joint pas. |
| Les captures : la seule exception à cette doctrine | Sous identité masquée, les **captures webcam** partent d'office — c'est le seul endroit du produit où l'on ne se contente pas d'avertir. La raison est de degré : un nom se devine, un **visage** se reconnaît, et la fuite est irrattrapable. La bascule reste offerte avec sa raison écrite (« Retirées : elles montrent le visage du candidat. À recocher en connaissance de cause »), si bien que les remettre reste possible — mais en le sachant. Le journal, lui, part quand même : il ne parle pas de la copie mais du **comportement**. Sanitisation à la source dans les deux cas : ce qui est retiré ne quitte jamais le serveur, et la porte des images se ferme avec la section (404). |
| La visite du tiers — DEUX niveaux | La racine du lien sert la **liste** : le cabinet, l'échéance, les membres avec leur fiche et leurs épreuves. Volontairement **légère** — un partage de trente candidats n'a aucune raison de télécharger quatre-vingt-dix rapports pour dessiner un rail. Le tiers navigue **entre les candidats** (rail cliquable, flèches ← →, et les **flèches du clavier** — un dossier de candidatures se feuillette ; ignorées dès qu'une saisie a le focus, sinon le correcteur ne pourrait plus déplacer son curseur), puis **entre les épreuves** de celui qu'il lit (onglets portant le score). Les **flèches** ne paraissent qu’à plusieurs personnes (il n’y a rien à parcourir) et portent la couleur d’ACTION : c’est la commande principale de cette page, elle était grise et de la taille d’une puce ; celle qui bute en fin de file reste en place — la retirer ferait sauter la mise en page à chaque candidat — mais cesse d’appeler. Les **ONGLETS d’épreuve, eux, s’affichent MÊME à UNE seule épreuve** : l’onglet ne sert pas qu’à naviguer, il *NOMME* ce qu’on lit — sans lui le tiers avait un rapport sous les yeux sans savoir de quelle épreuve il s’agissait, et deux candidats se lisaient différemment selon qu’ils en avaient une ou trois. Le contenu d'une épreuve se charge **à la demande**, quand le tiers y arrive. |
| Le CONFORT du tiers | La **fiche candidat** est une CARTE titrée, avec le rail corail des cartes de l’application : c’était une bande de libellés sans en-tête, qui se lisait comme un chapeau de page — on ne savait pas qu’on regardait une fiche. Et les **trois pages publiques** (`/r/`, `/s/`, `/t/`) portent désormais la bascule **clair / sombre** : ni le tiers ni le candidat n’ont de menu où la chercher, alors qu’un passage dure parfois une heure. C’est le MÊME composant partagé qu’utilisaient déjà `/t/` et `/p/` — il ne manquait qu’à `/r/` et `/s/` — et le choix est PERSISTÉ : revenir sur le lien retrouve son réglage. |
| Le PÉRIMÈTRE : ce qui n'est pas partagé n'existe pas | Toutes les portes du second niveau — un rapport, un dossier, une pièce jointe, une capture, un visuel d'énoncé, un CV — se jugent contre le **contenu du partage**, et rien d'autre. Une épreuve **décochée**, fût-elle celle d'un membre du partage, répond **404 uniforme** : dire « ça existe mais pas pour vous » serait déjà dire quelque chose. |
| Test ou dossier, même niveau | Un **test rendu** ouvre son rapport complet ; un **questionnaire reçu** ouvre son dossier — sections, réponses, pièces jointes téléchargeables. Jamais les deux : la nature de l'épreuve décide, et elle se lit sur son instantané. Les deux se lisent avec **les mêmes composants** que le recruteur (corps de rapport, corps de dossier) : il n'existe pas de « version tiers ». |
| Ce que le tiers voit d'un rapport — PAS un réglage | Le **rapport complet** : réponses du candidat ET bonnes réponses, barème et guide de correction compris. Aucune bascule « inclure le corrigé », contrairement au partage d'un test : on ne juge pas un candidat sur la moitié d'une copie, et on ne corrige pas sans barème. |
| Les deux droits | **Consultation** (pastille verte) — le tiers regarde. **Correction** (pastille violette) — il peut en plus **noter les questions ouvertes en attente**, épreuve par épreuve. Même pilule segmentée que le partage d'un test, mêmes couleurs. Elle vit à un seul endroit : la feuille de partage, sur *Consultation* par défaut. |
| La CORRECTION, par épreuve | Noter une question ouverte porte sur **une épreuve**, et reste réservée au droit **Correction**. Mêmes bornes et mêmes refus que le chemin recruteur (ANSWER_NOT_REVIEWABLE, REVIEW_POINTS_OUT_OF_RANGE, CONCURRENT_MODIFICATION) ; le score est **re-dérivé**, jamais persisté. En **Consultation** le serveur refuse en 422 SHARE_INVALID — le token est valide, c’est CE lien qui ne le permet pas. |
| L'ORIGINE de la correction | Chaque note écrit **qui l'a posée** : le **genre** (RECRUITER \| THIRD_PARTY) et, pour un tiers, le **libellé de son partage** — nom du client sinon adresse —, résolu à l'instant de la correction et **FIGÉ** : un partage clôturé puis supprimé n'efface pas l'attribution. **La dernière correction gagne** — un recruteur qui repasse derrière un tiers remet l'origine sur le cabinet et le repère tombe (une correction du cabinet est la norme, pas une information). L'information voyage **uniquement** sur le rapport du recruteur (GET /api/results/{id}) : la surface publique /r/ ne la porte pas — le tiers n'a pas à voir qui a corrigé quoi, et c'est presque toujours lui. |
| L’AVIS du tiers — sur la PERSONNE | La moitié **retour** du geste : le cabinet dit « voici cinq profils », le tiers répond « celui-là, oui ». Il porte sur le **candidat** et non sur une de ses copies — c’est l’unité du partage, et la **seule qui existe toujours** : une liste de profils sans test n’a aucune épreuve à quoi accrocher une décision. Un partage à cinq candidats produit donc **cinq avis**, un par personne. Trois valeurs, celles du recruteur mot pour mot (keep / review / reject) — seuls les MOTS de l’écran changent de côté : le tiers lit « je veux le rencontrer », le cabinet lit « à rencontrer ». Re-cliquer la pastille déjà choisie **efface** l’avis : se raviser doit être aussi facile que se prononcer. L’avis se **relit et se révise** — il est renvoyé au tiers à chaque ouverture, redemander ce qu’on a déjà répondu étant le meilleur moyen d’obtenir deux réponses différentes. |
| Le MOT qui l’accompagne | Sous la pastille, un champ libre **facultatif** (2 000 caractères) : « à revoir » sans raison ne sert personne. Il ne s’ouvre **qu’une fois la décision prise** — un mot sans pastille serait un avis à moitié dit, illisible sur la carte du cabinet. Une note **vide** et une note **absente** sont la même chose (trimée à la source, jamais rattrapée à l’affichage) ; la borne est jugée APRÈS normalisation, et un dépassement sort en 422 SHARE_INVALID. Ce n’est **pas une note chiffrée** : la pastille est la réponse, le mot est ce qu’on ajoute. |
| Le MODE n’entre PAS dans la règle | L’avis dépend du seul réglage *Demander un avis*, jamais du droit : on peut vouloir l’avis d’un client **sans** lui déléguer la correction des questions ouvertes — et c’est même le cas le plus courant. C’est ce qui comble le trou de V20 : un lien de **consultation** ne pouvait répondre que par e-mail. Un partage qui ne demande rien n’affiche aucun panneau, et l’écriture y est refusée en 422 SHARE_INVALID — même nuance que le refus de correction. Les liens nés d’une **copie en CC** ne demandent rien : ils annoncent un résultat, poser une question que personne n’a voulu poser serait un piège. |
| L’avis ne touche PLUS la décision du recruteur | Jusqu’à V20 le tiers écrivait dans evaluations.verdict, c’est-à-dire **la colonne du cabinet** : son « pas pour moi » **effaçait sans bruit** le « à garder » du recruteur, et rien à l’écran ne disait qui avait tranché. L’avis a désormais sa propre table, fille du **partage** et du **candidat** — pas du membre, un partage de campagne n’en ayant aucun. Deux jugements, deux endroits : le verdict de la fiche candidat n’appartient plus qu’au cabinet. Corollaire : **deux partages différents peuvent porter deux avis opposés** sur la même personne — ce sont deux interlocuteurs, et c’est souvent tout l’intérêt de la question. |
| Où la réponse atterrit | Sous le bandeau du **destinataire** dans *Résultats partagés*, et non sur la carte : la carte décrit la sélection, l’avis appartient à celui qui l’a rendu. Un résumé — « 2 à rencontrer · 1 écarté · 2 sans réponse » — puis le détail : une pastille colorée, le **vrai nom** (le masquage vaut pour le tiers, pas pour le cabinet) et le mot en entier. Le **reste attendu** est compté sur les candidats du partage : sans lui, trois avis sur cinq profils se liraient comme une réponse complète. Tant que rien n’est venu, la ligne le **dit** (« Aucun avis rendu pour l’instant ») — un vide passerait pour un bug d’affichage. Les avis voyagent AVEC la ligne, en lecture groupée : c’est la réponse qu’on attendait en envoyant le lien, elle ne se mérite pas par un clic de plus. |
| Le doublon d'une SÉLECTION n'est pas refusé | La garde SHARE_ALREADY_ACTIVE (409) — un seul lien vivant par rapport, destinataire et droit — **a été retirée avec la règle qu'elle protégeait**. Dès qu'un partage porte cinq candidats, deux sélections qui se recoupent partiellement sont la situation **normale** (« je lui renvoie les trois profils retenus ») : la refuser bloquerait un geste légitime. Une garde qui se déclenche à peu près est pire que pas de garde. Le sélecteur ne marque donc rien comme « déjà partagé », et la prolongation comme la réouverture ne peuvent plus répondre 409. |
| Le doublon d'une CAMPAGNE, lui, est refusé | Une garde revient, sur le seul critère qui n'a rien d'approchant : le triplet **(cabinet, adresse normalisée, campagne)**. À la création **manuelle** d'un partage portant un campaignId, un second lien **vivant** (ni clôturé ni expiré) et d'origine **MANUELLE** vers la même adresse est refusé en **409 SHARE_ALREADY_ACTIVE**. La raison tient à la liste : deux liens de campagne vers la même personne portent **exactement la même liste vivante** — c'est deux URL pour une conversation, deux échéances et deux jeux de réglages à tenir. Le **mode n'entre pas** dans le critère (contrairement au partage d'un test) : passer de Consultation à Correction sur le même parcours n'est pas une seconde conversation, c'est un droit à changer sur le lien qui existe. **Un lien AUTOMATIQUE (origine CC) ne bloque PAS** : il annonce des résultats au fil de l'eau, sans fiche ni avis demandé, alors que le recruteur qui pose un partage de campagne partage délibérément plus riche — prendre la trace d'un envoi pour une décision serait un contresens. Les deux cohabitent, et la feuille le *dit* plutôt que de le refuser. Enfin, ce 409 n'est **pas une impasse** : voir « Clôturer et remplacer » ci-dessous. |
| « Clôturer et remplacer » — la sortie du 409 | Le refus n'est pas un échec technique : le lien existe, et le recruteur voulait manifestement partager. Une confirmation s'ouvre — *« Un lien vivant existe déjà pour cette adresse, avec ses conditions. »* — et propose le geste qu'il avait en tête : **clôturer l'ancien puis créer le nouveau** avec les réglages qui viennent d'être saisis. Dans **cet ordre, et jamais l'inverse** : deux liens vivants sur la même campagne sont précisément ce que la garde refuse. Si la **clôture échoue, RIEN n'est créé** et l'erreur s'affiche — un geste qui n'a pas eu lieu vaut mieux qu'un doublon que personne n'a demandé. Le serveur **désigne lui-même** le lien à clôturer (champ manualCampaignShareId de la lecture d'annonce) : l'écran n'a pas à charger la liste entière des partages du cabinet pour retrouver une ligne que le serveur vient de nommer. |
| Les ANNONCES non bloquantes de la feuille | Ce qui n'est pas refusé est **dit**. À l'ouverture de la feuille et à chaque saisie d'adresse (débouncée), un encadré discret — la recette bleue des encadrés de règle, jamais l'ambre d'un avertissement — annonce ce que cette adresse **tient déjà**. Deux cas, un seul à la fois : sur une **sélection**, « Cette adresse tient déjà n lien(s) vivant(s) portant certains de ces candidats » — la doctrine laisse passer, mais laisser passer n'est pas taire, et le recruteur tranche entre recréer et aller prolonger ; sur une **campagne**, « Cette adresse reçoit déjà un lien automatique — il continuera de vivre », le seul cas qui mérite d'être annoncé puisqu'il ne bloque pas et produirait sinon deux e-mails inexpliqués. Le lien **manuel** d'une campagne n'est pas annoncé : il refusera à l'enregistrement, et un 409 qui propose sa sortie vaut mieux qu'un avertissement lu deux minutes plus tôt. L'encadré est **silencieux quand il n'y a rien à dire** (un encadré permanent ne se lit plus), ne grise **aucun bouton**, et une lecture en échec le laisse simplement vide — un encadré d'information n'a pas le droit d'empêcher de partager. La lecture est servie par `GET /api/result-shares/live` (paramètres tous facultatifs, candidateIds répétable) : elle ne peut retourner aucun 4xx, une adresse en cours de frappe rendant « rien à annoncer ». |
| Aucun rapport encore | L'étape de sélection ne tend pas une liste vide : elle explique **d'où vient un rapport**. Une *recherche* sans résultat reste un simple « aucun candidat ne correspond ». Ni l'un ni l'autre ne s'affiche tant que le serveur n'a pas répondu. |
| Destinataire · Échéance | Un **client** du module ou une **adresse libre**, comme le partage d'un test ; l'adresse est toujours portée en propre (instantané). Échéance **J+14** par défaut, validée comme toute échéance d'invitation (demain → J+365, sinon SHARE_INVALID). |
| Cycle de vie | Identique au partage d'un test : **copier le lien**, **relancer** (refusée sur un lien mort), **prolonger** (ressuscite un expiré, jamais un clôturé), **clôturer** (idempotent) et **révoquer**. Une clôture n'abandonne rien : les corrections déjà posées restent acquises. |
| La carte du recruteur | Dans l'onglet *Résultats partagés* : **une carte par partage** — grouper deux sélections parce qu'elles se recoupent n'aurait aucun sens. Elle porte le **nombre de personnes** là où l'anneau de score se trouvait (une sélection n'a pas de score à elle), son objet (un nom quand elle n'a qu'une personne, un compte au-delà, le nom du parcours pour une campagne), la ligne « n candidats · n épreuves », une chip *Identité masquée* le cas échéant, et *Suit la campagne* quand la liste est vivante. Les **vrais noms** y figurent : le masquage vaut pour le TIERS — cacher au cabinet les candidats qu'il vient de choisir n'aurait aucun sens. |
| Partages nés d'une copie | Inchangé : quand un envoi (ou un lancement de campagne) a coché *« Partager automatiquement le résultat aux personnes en copie »*, le serveur crée tout seul, à la complétion, un partage en **Consultation** (J+14) par adresse en copie — origine CC, signalée par la **chipsette de carte** « Créé(s) automatiquement (copie d'envoi) » — elle paraît dès qu'**un** lien de la carte en vient et en donne le compte ; les bandeaux, eux, ne portent plus l'origine. Il pose bien son **membre** et son **épreuve** (sans quoi le tiers ouvrirait une liste vide), n'inclut **pas** la fiche (on informe d'un résultat, on ne fait pas circuler un profil) et ne masque rien. Aucun geste ne change. Le doublon n'y est plus jugé non plus. |
| Un partage meurt avec son DERNIER membre | Effacer un candidat le retire des partages qui le montraient. Quand c'était le **dernier**, le partage disparaît : un lien qui ouvre sur rien n'a pas à survivre. « Meurs quand ton dernier membre s'en va » est une règle sur un *ensemble* qu'aucune clé étrangère ne sait dire — elle vit donc dans le module partage, déclenchée par un événement d'effacement. Un partage de **campagne** est épargné : sa liste n'a jamais été à lui. |
| Les liens DÉJÀ envoyés gardent leur pouvoir | Le réglage arrive avec un défaut de base **FAUX** et un défaut produit **VRAI** — l’écart est voulu, comme pour la fiche candidat en V20 : le défaut de base ne concerne que les lignes *déjà écrites*. Un rattrapage les remet ensuite à l’état exact d’hier : un lien de **correction** affichait les pastilles de décision (il était le seul), il demande donc un avis ; un lien de **consultation** n’a jamais rien pu répondre, il ne demande rien. Aucun tiers ne voit un panneau apparaître — ni disparaître — entre deux ouvertures du même lien. Les avis posés par l’ancienne route restent, eux, **indiscernables** de ceux du recruteur : on ne fabrique pas un historique qu’on ne sait pas reconstituer. |
| Lien mort · Cloisonnement | **410** SHARE_EXPIRED passé l'échéance ou après clôture ; **404** uniforme sur un token inconnu ou révoqué. Un candidat, une épreuve ou un partage d'un autre cabinet : **404**, à la création comme sur tout geste. |
| E-mail | Gabarit tenant **« partage de résultat »** (`GET/PUT /api/settings/result-share-email`). **Il obéit au masquage et il sait compter les épreuves** (deux défauts de recette corrigés : l'objet nommait la personne d'un partage *masqué* — le masquage s'arrêtait à la boîte de réception, c'est-à-dire qu'il ne masquait rien — et la variable d'épreuve recevait le nom de la *campagne*, vide sur une sélection, d'où un « pour l'épreuve « » »). Trois variables, et **aucune ne sort vide** : {{candidateName}} = le nom, le nom de **substitution** (« Candidat A », celui de la page) sous masquage, ou « n candidats » au-delà d'une personne ; {{testName}} = le **titre** de l'épreuve unique, « n épreuves » au-delà, « aucune épreuve » quand il n'y en a pas ; {{shareSummary}} (**nouvelle**) = la phrase entière, déjà conjuguée — « le résultat de X pour l'épreuve « T » », « … pour les 2 épreuves de ce candidat », « le profil de X » quand le partage est une liste de profils. Le gabarit **par défaut** s'appuie sur cette dernière ; un cabinet qui a personnalisé le sien garde ses variables et continue de lire une phrase juste. La liste d'un partage de **campagne** est relue à l'envoi comme à l'ouverture. Envoi best-effort après commit ; le lien rejoint aussi le presse-papiers. |

## Facturation

L'écran **Facturation** vit dans le groupe **Finance** de la barre latérale (§4), route `/billing`, **persona recruteur uniquement** — l'administrateur plateforme n'a pas de cabinet, donc rien à facturer. Evalixo ne produit **aucune facture** : il tient l'état et l'exporte — la facturation électronique reste l'affaire de l'outil comptable du cabinet.

### La doctrine

**Rien ne se crée automatiquement.** Déclarer un recrutement (§10), rendre une copie ou régler un barème n'écrit **aucune** ligne. Il n'existe plus ni valorisation à la déclaration, ni ligne de passation posée par le système, ni rattrapage des copies non facturées, ni cascade d'annulation. Une ligne existe parce que quelqu'un a cliqué **Ajouter une ligne** (l'ex-« Facturer » — le mot « facturer » désigne désormais un passage d'état, voir le cycle de vie plus bas). Et la règle qui gouverne tout : **le barème propose des prix, il n'en impose jamais** — tout montant s'écrase, l'écart est simplement marqué « ajusté ».

Une ligne reste une **pièce** : le nom du destinataire, le libellé, le montant, le prix unitaire, le montant calculé par le barème, le candidat et la campagne y sont **figés** à la création. Réviser un barème ne réécrit AUCUNE ligne existante.

### Le cycle de vie d'une ligne (V6)

Evalixo ne produit toujours **aucune facture** — mais il sait désormais **où en est** chaque ligne : **À facturer → Facturée → Réglée**. « Facturée » se marque avec la **référence de la facture émise dans votre outil comptable** (c'est le pont entre les deux mondes), une date et une échéance ; « Réglée » d'un clic. Chaque pas est **réversible**, un seul à la fois. L'**annulation** reste orthogonale et PRIME à l'affichage — un comptable qui lit « Facturée » sur une annulée la compterait.

| Règle | Comportement |
|---|---|
| Un lot = une facture | **Marquer facturées…** — depuis la **pastille d'état** d'une ligne, ou depuis le bouton de la section client, qui embarque tout son « à facturer » (décochable dans la feuille) — exige des lignes du **même destinataire** 422 sinon. Chaque ligne porte UN id et part pour elle-même : une **campagne facturée est une ligne**, elle entre dans un lot comme les autres (l'agrégat qui devait « partir entier » n'existe plus). |
| L'échéance — proposée, jamais imposée | Sans échéance saisie : la date de facture + le **délai du client** (nouveau champ « Échéance des factures » de son barème), sinon **30 jours**. Elle n'arme QUE la pastille « en retard » et les compteurs — aucune relance automatique, Evalixo n'envoie rien. |
| Le pilotage — dérivé, jamais saisi | Quatre **tuiles de lecture** en tête d'écran (À facturer, Facturé en attente, En retard, Réglé — « en retard » est un sous-ensemble de « facturé », jamais une cinquième famille) et les **six derniers mois** en barres empilées. Montants HT, annulées exclues, calcul serveur. Les tuiles n'ont AUCUN geste : une statistique ne se devine pas cliquable (retour utilisateur) — le filtre d'état vit dans la **rangée de chips** sous la barre de contrôle (Tous · À facturer · Facturée · En retard · Réglée, chacune avec son compte), à côté du **sélecteur de client** et de la recherche élargie au **nom, prénom ou e-mail du candidat** (l'adresse se lit sur la fiche vivante — la ligne fige le nom, pas l'e-mail). |
| La fiche client gagne sa carte Finance | Facturé cette année, en attente, en retard (avec la plus ancienne facture et son échéance), à facturer — en **lecture seule** : les gestes vivent sur l'écran Facturation. Sous le barème, fiche client (§9). |
| Les liens antérieurs | Toute ligne née avant V6 est « À facturer » : rien n'est deviné, le rattrapage est un geste du recruteur. |

### Le barème campagne — quatre branches, aucune n'impose

| Règle | Comportement |
|---|---|
| Le volet Campagne du barème | TROIS branches : **Forfait par campagne**, **« Facturer à la copie rendue »** (l'ancien sens CACHÉ de « Pas de forfait », enfin nommé — au prix unitaire du volet passation), et le VRAI **« Pas de forfait »** (défaut) : le barème ne propose rien, la feuille reste entièrement libre. « **Incluse** » a été retirée — même comportement observable que « pas de forfait », un seul état suffit ; les fiches qui la portaient ont été migrées. Les barèmes qui vivaient sur l'ancien sens caché ont été migrés vers « à la copie rendue » — leur comportement n'a pas bougé. |
| La feuille « Une campagne » ne bloque plus rien | Les **deux modes se choisissent toujours** — renommés « Une seule ligne (forfait) » et « Une ligne par copie » : le choix dit ce qu'il PRODUIT sur l'état, plus un prix. « Une seule ligne » n'est plus éteinte faute de barème — le montant se saisit dessous. Le forfait du barème **pré-remplit et se corrige** (marqué « ajusté »). Sans suggestion du barème, **le recruteur tranche** le mode — plus d'auto-sélection ; seule impossibilité de FAIT : « aux copies » à zéro copie rendue. |

### Le barème du client — trois volets

Le barème se règle sur la **fiche client** (§8) et se lit ici : c'est lui qui **propose** les montants. Il porte **trois volets indépendants**, tous facultatifs — la carte « Barème de facturation » de la fiche client affiche donc **trois lignes**, dans cet ordre : *Placement* · *Passation de test* · *Campagne*, chacune retombant sur *« Non défini »* quand elle n'est pas réglée.

| Volet | Ce qu'on règle | Ce qu'il propose |
|---|---|---|
| Placement | Un **mode** : `PERCENT` + un pourcentage de ]0;100], ou `FLAT` + un forfait (> 0). | Le montant d'un placement : le pourcentage s'applique au **salaire brut annuel**, le forfait se propose tel quel. |
| Passation de test | Un **mode** : `UNIT` + un prix unitaire, ou rien. | Le prix d'**une** copie rendue. Sans mode, aucun prix n'est proposé — l'ex-« incluse » a fusionné avec ce silence. |
| Campagne (parcours complet) | Un **mode** : `FLAT` + un forfait (> 0), `PER_SITTING`, ou rien. | Le forfait proposé quand on facture une campagne **au forfait** ; `PER_SITTING` propose **aux copies rendues**, au prix unitaire du volet passation. Mode absent ⇒ rien n'est convenu, la feuille reste libre. |

| Règle | Comportement |
|---|---|
| Trois volets, trois questions | Les volets sont **indépendants** : un client peut n'avoir qu'un forfait de campagne, ou qu'un taux de placement. Un barème existe dès qu'**un seul** des trois est posé. |
| « Incluse » a fusionné avec « pas de barème » | La distinction a été **retirée** (retour utilisateur) : les deux réglages produisaient exactement le même comportement — aucun montant proposé, rien de bloqué — et une décision qui ne change rien n'est pas une décision enregistrable. Il ne reste qu'**un** silence, « pas de barème » ; la migration a remis à ce silence les fiches qui portaient `INCLUDED` (passation et campagne), et un `INCLUDED` envoyé est désormais un mode inconnu 422 `CLIENT_BILLING_INVALID`. Rien n'interdit de facturer sans barème : le barème propose, il n'impose jamais. |
| Bornes | Forfait de campagne **strictement positif** — le zéro est refusé 422 `CLIENT_BILLING_INVALID` : un forfait à zéro, c'est un forfait absent. (Le prix unitaire d'une passation, lui, accepte le zéro : « offert » n'est pas « inclus ».) |
| Surcharge du poste | Elle ne concerne que le **placement** (taux ou forfait négocié pour ce poste, §8). Il n'existe **aucune surcharge de poste** pour la passation ni pour le forfait de campagne : une campagne ne vise qu'un poste, mais le forfait se négocie au contrat cadre. |

### Le geste « Facturer »

Le bouton ouvre une feuille unique qui commence par la nature de ce qu'on facture. La nature est le **geste**, pas forcément le type de la ligne produite : « Une campagne » crée **une ou N** lignes de type *passation* selon le mode retenu. En **modification**, le sélecteur disparaît — la nature d'une ligne ne change pas.

| Nature | Ce qu'on saisit | Ce qui se passe |
|---|---|---|
| Un placement | Destinataire + candidat, le **salaire brut annuel** quand le barème est un pourcentage, puis libellé, montant HT et date (proposés). | Le devis propose un montant : **surcharge du poste d'abord**, mais le **MODE vient toujours du client** — `PERCENT` ⇒ taux × brut annuel arrondi au centime, `FLAT` ⇒ le forfait. Sans barème, aucune proposition (jamais un 0 : « rien à proposer » n'est pas « zéro euro »). **Une** ligne de type placement. Voir plus bas. |
| Une campagne | La campagne, puis **comment la facturer** — au forfait ou aux copies rendues. | Le récapitulatif affiche le client, le nombre de **copies rendues**, le forfait par campagne, le prix unitaire et le total proposé. *Une seule ligne (forfait)* ⇒ **UNE** ligne ; *Une ligne par copie* ⇒ le détail dépliable. Le destinataire est **déduit** du client du poste visé : il ne se saisit pas. Voir plus bas. |
| Une passation | Destinataire + candidat + **la copie rendue**, puis libellé, montant et date. | Le sélecteur de copie reste **désactivé tant qu'aucun candidat n'est choisi** et ne liste que ses copies **rendues** (les questionnaires en sont exclus). Le devis propose le prix unitaire du barème et cale la **date sur celle de la copie**, pas sur aujourd'hui. |
| Libre | Destinataire + libellé + montant + date. | Ce qu'aucune des trois autres ne dit : frais annexes, régularisation. Aucun devis, aucun avertissement. |

| Règle | Comportement |
|---|---|
| Destinataire — deux formes exclusives | Soit un **client du référentiel**, soit **hors référentiel** : un **nom** (≤ 120) ET un **e-mail** (≤ 180, normalisé en minuscules), les deux **obligatoires** ensemble. Les deux formes à la fois, aucune des deux à la création, ou un couple incomplet 422 `BILLING_LINE_INVALID` ; client inconnu ou d'un autre cabinet → 404 uniforme. Dans les deux cas le **nom est figé** sur la ligne : une ligne a toujours quelqu'un à facturer. |
| « Hors référentiel » en TÊTE de liste | La liste des destinataires s'ouvre sur *« — Hors référentiel — »*, **avant** les clients du cabinet. C'est une **échappatoire**, pas le dernier client de l'annuaire : reléguée en queue, il fallait dérouler cent noms pour découvrir qu'elle existait. |
| Le barème du destinataire est rappelé | Dès que le destinataire retenu porte un barème, un **bandeau** le rappelle en tête de feuille — *« Barème {client} : 22 % du brut annuel »*, *« … forfait de 8 000 € »*, *« … 90 € la copie »*, *« … Forfait 2 500 € »*, ou *« Incluse dans les honoraires de placement »* ; plusieurs volets se joignent par « · ». Pas de barème, **pas de bandeau** : on n'annonce pas une absence. Il ne paraît qu'en **création** (on ne re-propose pas une pièce qu'on corrige) et ne coûte aucun appel de plus — la fiche du destinataire est déjà chargée pour le sélecteur. |
| Le devis n'écrit rien | Les trois endpoints de proposition sont en **lecture seule** : les consulter cent fois ne laisse aucune trace. Ils répondent aussi `alreadyInvoiced` et sa date. Un devis de passation sur une copie **non rendue** est un 404, pas un « 0 € ». |
| Déjà facturé — on prévient | Facturer un placement, une campagne ou une passation déjà facturés affiche un **avertissement daté** (la date de la dernière ligne vivante correspondante) et **n'est jamais refusé** : second lot, régularisation — c'est une situation, pas une erreur. Aucun code d'erreur de doublon n'existe dans le module. L'avertissement de placement est nominatif : même candidat ET même destinataire. |
| Marque « ajusté » | Le montant proposé est **conservé à côté** du montant retenu dès qu'il existe, même identique (une confirmation est une information) ; seule la **marque** exige un écart : *ajusté* ⇔ montant retenu ≠ montant proposé. À la modification, la marque est **recalculée** : revenir au montant proposé n'est plus un ajustement. Dans la feuille, la proposition s'affiche **barrée** sous la mention « Montant ajusté ». |
| Bornes de saisie | Libellé non vide, ≤ 200. Montant HT > 0 et ≤ 10 000 000 : le **zéro est refusé** sur une ligne. Date au format `AAAA-MM-JJ`, **sans borne temporelle** — on régularise le passé comme on provisionne l'avenir. Tout écart 422 `BILLING_LINE_INVALID`. Seule exception : le **prix unitaire forcé** d'une campagne, où le **zéro est légal** (« facturé mais offert » n'est pas « inclus »). |
| Bouton jamais grisé | Conformément à la règle générale des formulaires, *Facturer* n'est désactivé que pendant l'enregistrement. Un clic incomplet marque chaque champ manquant. Les refus du serveur s'affichent **dans la feuille**, pas en toast sur l'écran qu'elle recouvre. |

### Facturer un placement — le salaire fait le montant

Quand le barème applicable est un **pourcentage** — le taux surchargé du poste s'il existe, sinon celui du client —, la feuille demande le **Salaire brut annuel** : un pourcentage sans base ne calcule rien. Sur un barème au **forfait**, le champ n'apparaît pas : le montant est proposé d'emblée, demander un brut ne servirait à rien.

| Règle | Comportement |
|---|---|
| Pré-rempli, jamais imposé | Le champ arrive **pré-rempli depuis le recrutement actif** du candidat s'il en a un, **vide** sinon — et il reste modifiable dans les deux cas. Le barème s'applique même sans recrutement : c'est la **base** qui manquait, pas le contrat. |
| Recalcul à la frappe | Le montant se recalcule à **chaque frappe** — taux × brut annuel, arrondi au centime — et la trace du calcul se lit sous le montant : *« Barème : 22 % × 42 000 € = 9 240 € »*, ou *« Taux du poste (18 %) × … »* quand la valeur vient de la surcharge. Saisir un autre montant barre la proposition et pose la marque *ajusté*. |
| UN seul champ pour DEUX usages | Le **même** champ sert au recrutement quand la case *« Marquer aussi {candidat} comme recruté chez {client} »* est cochée — l'aide sous le champ le dit. Demander deux fois le même salaire dans une même feuille, ce serait inviter à le saisir deux fois différemment. Le champ vit **plus haut** dans la feuille ; seule la **date d'embauche** apparaît sous la case. |
| Obligatoire ou facultatif | Le salaire est **exigé** dès que la case de recrutement est cochée (mêmes règles et mêmes messages que la modale de la fiche candidat : entier strictement positif 422 `INVALID_SALARY`). Sans la case, il reste **facultatif** — marqué comme tel : on peut toujours saisir le montant à la main. |
| Le salaire ne part pas avec la ligne | Ce qui est envoyé au serveur, c'est le **montant retenu** (et le montant proposé), jamais le salaire : la ligne de facturation n'a pas à porter une rémunération. Le brut annuel n'est stocké que là où il décrit quelque chose — sur le **recrutement**. |
| Marquer recruté dans la foulée | Sur la nature « Un placement » **en création** seulement. La case n'apparaît **que** si un candidat est choisi, que le destinataire est un **vrai client du référentiel** (un recrutement ne se rattache pas à un nom libre) et que le devis répond `hasActivePlacement: false`. Décochée par défaut, et remise à zéro dès qu'on change de nature, de destinataire ou de candidat. |
| Ordre et échec | Le **recrutement part d'abord**. S'il est refusé, **aucune ligne n'est facturée** — une ligne orpheline serait pire que l'échec. L'inverse est admis et n'est **jamais compensé en silence** : si la ligne échoue après un recrutement réussi, le recrutement reste et la feuille rouvre son erreur pour retenter la ligne. |

### Facturer une campagne — au forfait ou aux copies rendues

Une campagne se facture de **deux façons**, et la feuille pose la question sous le titre *« Comment facturer ? »*. **Les deux branches sont toujours affichées** : celle qui ne s'applique pas reste visible, **désactivée, avec sa raison**. Cacher une branche laisserait croire qu'elle n'existe pas ; la montrer éteinte dit ce qu'il manque et où le corriger.

| Mode | Ce qu'il produit | Désactivé quand… |
|---|---|---|
| Une seule ligne (forfait) | **UNE ligne**, « Forfait — campagne {nom} », **indépendante des copies rendues** : une campagne **sans aucune copie** se facture ainsi. Elle ne porte ni candidat, ni prix unitaire, **aucun détail à déplier**, et sa date est celle du **geste** — rien dans la campagne ne date un forfait ; elle se corrige comme n'importe quelle date. | **Jamais** : sans forfait au barème, le montant se saisit simplement dessous — le barème propose, il n'impose pas. |
| Une ligne par copie | **UNE ligne** également — qui **totalise les copies retenues** (toutes cochées par défaut, décochables une à une) au prix unitaire retenu, et porte leur **liste figée** en détail dépliable (candidat, épreuve, jour). Sa date est celle de la copie la **plus récente** parmi les retenues. Le montant vaut *copies × prix* et reste **écrasable** : l'écart sera marqué « ajusté ». | La campagne n'a **aucune copie rendue**, ou toutes ont été décochées : *« aucune copie à facturer »* — la seule impossibilité de FAIT (le forfait existe pour facturer sans compter). |

| Règle | Comportement |
|---|---|
| Deux praticables ⇒ le recruteur choisit | Aucun mode n'est présélectionné : le forfait et les copies ne disent pas la même chose au client, l'outil n'a pas à trancher. Valider sans avoir choisi marque le champ — *« Choisissez comment facturer cette campagne. »* |
| Un seul praticable ⇒ retenu d'office | Le mode applicable est **coché d'emblée** ; l'autre reste affiché, éteint, avec sa raison. Un clic sur une branche éteinte ne change rien — sinon on choisirait un mode que le serveur refuserait. |
| Aucun praticable ⇒ à la main | Ni forfait au barème, ni copie rendue : les deux branches disparaissent au profit d'un simple **Montant HT** à saisir — *« Aucun mode automatique sur cette campagne — indiquez le montant à facturer. »* Le résultat est **une ligne au forfait** pour ce montant. |
| Prix unitaire modifiable | En mode *aux copies rendues*, un **Montant unitaire facultatif** peut forcer le prix ; laissé vide, le barème fait foi. Le **zéro y est légal** — « facturé mais offert » n'est pas « inclus ». |
| Campagne non facturable | Le poste visé par la campagne ne désigne **aucun client** (recrutement interne, ou client à définir), ou aucun prix n'est disponible dans le mode retenu 422 `BILLING_LINE_INVALID`. Une campagne **sans copie rendue** facturée *aux copies* répond 200 avec une liste **vide** : n'avoir rien à faire n'est pas une erreur, et un 201 annoncerait une création qui n'a pas eu lieu. Au *forfait*, la même campagne crée bien sa ligne 201. |

### Lire l'état

Deux vues d'un même jeu de lignes, un même jeu de filtres — et l'export sert exactement ce que l'écran vient d'afficher : il n'y a pas de second calcul à maintenir.

| Règle | Comportement |
|---|---|
| Deux vues | **Par client** : une section par destinataire, son total, et le **Total général** en pied — **non paginée**, un état à facturer se lit ENTIER. **Toutes les lignes** : tableau à plat **paginé** (10 par page, la taille de toutes les listes), le destinataire dans la ligne puisque aucune section ne le nomme. Changer de vue revient à la page 1. |
| Filtres | Tous **facultatifs** : une **recherche** texte (libellé, nom du destinataire, nom du candidat — insensible à la casse et aux accents, déclenchée après une pause de frappe) et **deux dates libres** `from` / `to` (`AAAA-MM-JJ`), bornes **incluses** sur la date de l'événement. Chacune peut manquer : sans borne, on lit tout l'historique. **Il n'y a pas de sélecteur de mois.** Bornes mal formées ou **inversées** 422 `BILLING_LINE_INVALID`. |
| Groupement | Par **nom de destinataire FIGÉ**, pas par identité : deux lignes du même nom se regroupent même si la fiche client a été supprimée entre-temps. Destinataires par ordre alphabétique (collation française), lignes par date puis libellé. Les totaux viennent du **serveur**, annulées déjà déduites — l'écran n'additionne rien. |
| Facturer une campagne = UNE ligne | Le geste crée **une seule ligne**, de nature **Campagne** — au *forfait* (un montant, quel que soit le nombre de copies) ou *aux copies rendues* (les copies retenues × leur prix). L'ancien fonctionnement — N lignes de passation, re-groupées à la lecture en un « agrégat » sans identité — a **disparu** : il produisait un bloc que l'on ne pouvait ni modifier, ni annuler, ni suivre, et dont les filles portaient chacune un état séparé. Une campagne facturée est désormais une **pièce** comme les autres : son id, son état, son menu, sa place dans un lot. |
| Ce qui se DÉPLIE : les copies retenues | Une ligne de campagne *aux copies rendues* porte la **liste des copies** qu'elle totalise (candidat, épreuve, jour — tous **figés** à la création) et se déplie dessus. Ce détail n'est **pas** une ligne : ni montant propre, ni état propre, ni action — **seule la ligne mère se modifie, s'annule et se suit**. Un *forfait*, lui, ne totalise aucune copie : rien à déplier. |
| Les anciennes lignes ne sont PAS fusionnées | Les campagnes facturées avant la refonte ont produit de **vraies lignes** de passation, chacune avec son id, son état et sa possible annulation. Les fondre après coup en une seule détruirait ces faits : elles restent telles quelles et se lisent désormais **une par une** (nature *Copie*), l'agrégation qui les réunissait à l'écran ayant disparu. |
| Chaque ligne dit le FAIT | La ligne s'ouvre sur ce qu'elle facture, **dérivé des colonnes figées** — jamais du libellé libre, qui se modifie et ne prouve rien : une **pastille de nature**, l'**objet** (le candidat, ou la campagne), et la **méthode** de calcul (« 22 % × 42 000 € », « 3 copies × 18 € », « forfait global — indépendant du nombre de copies », « montant saisi »). Les deux vues (par client, à plat) racontent la même chose. |
| UNE pastille par NATURE, et sa FORME | Quatre natures — exactement les **quatre choix de la feuille « Facturer »** : *Placement* · *Campagne* · *Copie* · *Ligne libre*. Elle ne se devine plus d'un couple de colonnes : c'est le **type figé** de la ligne. La pastille dit en plus la **forme** quand il y en a une — « *Campagne · forfait* », « *Campagne · copies* », « *Placement · %* », « *Placement · forfait* » : « au forfait ou à l'unité ? » se pose sur chaque ligne, la pastille y répond seule. Les couleurs sont celles du système : une **copie** prend le jeton *bibliothèque* (le test), une **campagne** le jeton *recrutement* (corail), un **placement** le dégradé des deux, une **ligne libre** le neutre — le cabinet rethème les deux blocs, rien n'est écrit en dur. Une ligne d'AVANT la refonte qui porte une campagne **sans nommer personne** est un ancien forfait : elle se lit « Campagne · forfait », pas « Copie » — une vraie copie nomme toujours son candidat. |
| Les lignes s'ALIGNENT | Toutes les lignes d'un destinataire partagent **UNE grille** — dépliage · date · nature · objet et méthode · état · montant · actions : les colonnes sont résolues une fois pour la carte entière, si bien que tout tombe au même endroit d'une ligne à l'autre. Une grille *par ligne* calait au contraire chaque colonne sur le contenu de SA ligne, et la pastille d'état sautait d'une rangée à l'autre. Un plancher de largeur accorde aussi les cartes entre elles. Sur écran étroit, la rangée redevient une pile : mieux vaut replier que déborder. |
| Le libellé est DÉMOTÉ | Le libellé libre passe en seconde ligne — « *Libellé sur l'état : « … »* » — et **seulement quand il s'écarte du fait** : un libellé qui répète l'objet n'apprend rien. Une **copie** le garde dès qu'il diffère (lui seul porte le nom du test) ; une **ligne libre** ne le démote jamais — son libellé EST la ligne. L'**impression** et le **CSV**, eux, gardent le libellé en tête : c'est le document que le client lit, rien n'y change. |
| Pastilles | annulée sur une ligne mise de côté, hors référentiel sur l'**en-tête de section** quand le destinataire n'est pas un client du référentiel. La marque ajusté vit désormais **à côté du montant** — c'est le prix qu'elle qualifie — avec la **proposition écartée, barrée**, dessous quand elle est connue (« proposé 2 000 € »). Jamais « ajusté » sur une annulée : annulée l'emporte. |
| La pastille d'état est une LISTE DÉROULANTE | La pastille du cycle (« À facturer », « Facturée · F2026-041 », « Réglée le … »), à droite de la ligne, **se clique** (retour utilisateur) : elle n'offre que les **crans que le serveur accepte**, un à la fois — depuis « à facturer », *Marquer facturée…* (la feuille du n°) ; depuis « facturée », *Marquer réglée* ou *Repasser « à facturer »* ; depuis « réglée », *Repasser « facturée »*. Les gestes du cycle ont donc **quitté le menu ⋯** (qui garde Modifier · Annuler · Supprimer) ; l'**agrégat** se pilote par SA pastille (ses filles suivent) et n'a plus aucun menu. Une **annulée** garde une pastille muette : son état se lit, il ne se pilote pas. Le bouton de section « Marquer facturées… » (le lot) ne change pas. |
| Lignes annulées | **Présentes** dans l'écran et dans l'export, barrées, avec leur motif — mais **hors de tous les totaux** (destinataire et général). |
| Export CSV | Servi par le **serveur** (mêmes filtres, même requête, même assemblage que l'écran) : **BOM UTF-8** et **point-virgule** pour Excel FR, nombres à virgule décimale, fins de ligne CRLF, dates en **ISO** (sans ambiguïté jour/mois d'un tableur à l'autre). Colonnes : *Client ; Date ; Type ; Libellé ; Candidat ; Quantité ; Prix unitaire ; Montant HT ; État ; N° facture ; Échéance ; Motif* — l'État porte le cycle (*À facturer / Facturée / Facturée — en retard / Payée / Annulée*, l'annulation prime). Seules les lignes de **premier niveau** sont exportées — un agrégat dit « 12 copies à 35 € », ses filles restent à l'écran. Ligne de total finale hors annulées. |
| Export PDF | Impression du navigateur, sans rendu serveur : chrome, filtres et actions masqués, en-tête révélé — titre **Facturation**, **Période : {du} → {au}** en dates longues (ou « toutes les lignes » si aucune borne) et **Généré le {jour}**. La période s'y nomme **absolument** — une feuille archivée doit se relire des mois plus tard. Une section de destinataire ne se coupe pas entre deux pages. |

### La vie d'une ligne

Quatre gestes, tous à la main du recruteur. Rien n'est irréversible sauf *Supprimer*, qui est justement le geste de l'erreur de saisie. Chaque écriture est suivie d'une **relecture complète** de l'état : rien n'est deviné côté écran.

| Geste | Comportement |
|---|---|
| Une PASSATION nomme sa copie | « Une passation d'un test, c'est une épreuve » : une ligne de cette nature facture UNE copie rendue, elle doit donc dire **laquelle**. `POST /api/billing/lines` avec `kind: SITTING` et sans `evaluationId` est refusé 422 `BILLING_LINE_INVALID` — le champ cesse d'être facultatif pour cette seule nature (les autres n'en portent pas ; une ligne de campagne facture ses copies par son détail). L'invariant se juge **À L'ÉCRITURE, jamais en base** : `evaluation_id` reste `ON DELETE SET NULL`, si bien qu'une évaluation supprimée plus tard laisse la ligne sans lien — et elle se relit sans erreur, ses noms figés prenant le relais. Une contrainte SQL rendrait la base incohérente au premier effacement légitime. |
| Modifier | **Le LIBELLÉ, le MONTANT et la DATE — rien d'autre** (décision produit) : une coquille dans ce que le client LIT, une négociation qui bouge, une date mal saisie se rattrapent ; une pièce mal QUALIFIÉE, elle, se **supprime et se refait** — corriger après coup la nature, le destinataire, le candidat ou la copie fabriquerait une ligne qui dirait autre chose que ce qu'on a facturé. La feuille l'énonce dans son sous-titre, et **LIT** ce qu'elle ne change pas — nature, objet, méthode, destinataire — avec les mots exacts de l'écran d'état (même dérivation, pas une seconde formulation). Le corps du `PATCH` ne porte donc que `label`, `amount` et `eventOn` ; le serveur en accepterait davantage, c'est l'écran qui décide. Une ligne **annulée reste modifiable** : on corrige AVANT de remettre. |
| Annuler | Sa propre fenêtre (récapitulatif + **motif facultatif**, ≤ 300). La ligne reste **visible, barrée, motivée, hors totaux** et sort de l'agrégation. Ce qui est annulé, c'est la **facturation**, jamais l'événement : la copie reste rendue, le recrutement reste vrai. Deux fois 422 `ALREADY_CANCELLED` — le premier motif fait foi. |
| Remettre | Action **directe**, sans fenêtre : la ligne redevient facturable, date et motif d'annulation repassent à vide. **Aucun historique d'annulation n'est conservé** — décision produit assumée. Sur une ligne qui n'est pas annulée 422 `BILLING_LINE_INVALID` : il n'y a rien à remettre. |
| Supprimer | Confirmation *danger* → `DELETE` 204, suppression **réelle et définitive**. Réservé à l'**erreur de saisie** : la ligne n'aurait jamais dû exister. Possible qu'elle soit annulée ou non. Pour une ligne qui a bien eu lieu mais qu'on ne facture pas, c'est *Annuler*. |
| Sur une ligne de campagne | Les gestes sont ceux de **toute ligne** — modifier, annuler, remettre, supprimer, et le cycle de vie —, car c'en est une. Ses **copies retenues** ne se corrigent pas à l'unité : la sélection se fait au moment de facturer ; pour la changer, on supprime la ligne et on refacture. La suppression emporte le détail. |
| Aucune cascade depuis le recrutement | Annuler ou supprimer un recrutement (§10) ne touche **aucune** ligne : les deux objets vivent leur vie. Une embauche qui n'a pas tenu se solde en annulant *aussi* la ligne, ici — c'est une décision commerciale, pas une conséquence mécanique. |

## Le passage candidat

Trois surfaces publiques, sans compte ni mot de passe : l'épreuve, le dossier et le parcours de campagne. Le lien porte l'identité.

[capture d'écran : Accueil du passage]

*L'accueil annonce le contenu, la durée, la validité du lien et les règles du jeu avant tout engagement.*

| Règle | Comportement |
|---|---|
| Une question à la fois | Chaque question a son propre chronomètre. Valider est définitif : pas de retour en arrière. |
| Chronomètre d'une question | À son terme, la question passe automatiquement à la suivante. Le passage, lui, continue. |
| Une seule fois — annoncé | Quand l'invitation a été envoyée en **passage en une seule fois** (§11), l'accueil prévient avant l'engagement : « *Ce test se passe en une seule fois : une fois commencé, vous disposez de N minutes, sans pause possible.* » En reprise libre, rien n'est annoncé — il n'y a rien à annoncer. |
| Une seule fois — temps écoulé | Le serveur clôt la session avec les réponses déjà validées et sert l'écran *Temps écoulé* : plus rien ne se saisit, et la copie part telle quelle au recruteur. Rien n'est perdu de ce qui avait été validé. |
| Reprise | Une session interrompue se reprend où elle s'est arrêtée ; l'ordre mélangé reste le même. Sur une invitation envoyée en une seule fois, revenir après le temps imparti ne rouvre rien : la session se clôt à ce moment-là. |
| Dossier | Pas de chronomètre, brouillon enregistré au fil de l'eau, remise en une fois. |
| Parcours de campagne | Un lien unique donne accès aux épreuves successives et indique celles déjà rendues. |
| Confort | Thème clair ou sombre, modifiable à tout moment pendant le passage. |
| La marque du cabinet | Quand le plan inclut la **marque blanche** (§19), `/t/` et `/p/` portent le **logo** et le **nom** du cabinet en **en-tête** et dans le **titre de l'onglet** ; le candidat sait qui le fait passer. Sinon — plan sans la fonction, ou cabinet qui n'a rien configuré — la page garde l'identité **Evalixo**, sans erreur. Les **couleurs** du cabinet ne s'appliquent **pas** ici, sa **police** oui (§18). |

## Résultats & correction

Il n'y a pas d'écran « liste des résultats » : les copies se lisent depuis la fiche du candidat. Le rapport détaille la copie question par question, regroupée par compétence.

[capture d'écran : Rapport de copie]

*Le rapport : score global, incidents de surveillance, décision, puis le détail par compétence.*

| Règle | Comportement |
|---|---|
| Score recalculé | Jamais stocké : recalculé à la lecture depuis les réponses. Corriger une réponse libre met le score à jour immédiatement. |
| Score provisoire | Tant qu'une réponse libre attend sa correction, le score est marqué *provisoire*. |
| Copie figée | Chaque réponse conserve **la question telle qu'elle a été passée**. Réviser la banque ne réécrit aucun rapport. |
| Correction | Le recruteur attribue les points d'une réponse libre (0 au barème) et peut joindre un commentaire. Les copies à corriger se retrouvent depuis le bloc *À traiter* du tableau de bord — le rapport ne propose plus de « copie suivante ». Une note posée par un **tiers** depuis un partage en droit *Correction* porte, à côté d'elle, une pastille neutre *« Corrigé par le client »* ; une note du cabinet n'affiche rien, et les rapports antérieurs à cette trace non plus. |
| Correction assistée | Sur demande, l'IA propose une note et sa justification pour une réponse libre, ou corrige le rapport entier. Elle propose, le recruteur valide, et la note reste modifiable ensuite — le détail en §16. |
| Export | Le rapport s'exporte en PDF. Le **pied de page** du document imprimé porte la marque du cabinet quand son plan inclut la **marque blanche** — « *Rapport établi par {nom du cabinet}* … », sans mention d'Evalixo ; sinon il garde le pied Evalixo (§18). |

### Journal de surveillance

Sous le détail des réponses, le rapport reconstitue le passage minute par minute : l'horodatage du consentement, les compteurs par type d'incident, puis la chronologie — chaque incident renvoie à **la question affichée à cet instant**, et les captures webcam et écran s'intercalent à leur heure.

[capture d'écran : Journal de surveillance d'un passage]

*Compteurs d'incidents, puis la chronologie horodatée du passage avec ses captures.*

| Incident journalisé | Déclencheur |
|---|---|
| Sortie d'onglet ou de fenêtre | Le candidat quitte la page du test. |
| Sortie / retour en plein écran | Le plein écran est interrompu, puis rétabli. |
| Collage bloqué | Tentative de coller du texte dans une réponse. |
| Copie bloquée | Clic droit ou Ctrl+C sur l'énoncé. |
| Second écran détecté | Un écran additionnel est présent. |
| Le passage a changé d'appareil | Le passage a continué depuis un **autre appareil** que celui qui l'avait commencé — le lien a été ouvert ailleurs. Uniquement si la mesure était active à l'envoi (§11). |
| Captures | Photos webcam et copies d'écran prises pendant le passage. |

### Origine du passage

Quand le passage a été repris depuis un autre appareil, le journal ouvre un bloc **Origine du passage**. Il n'apparaît qu'à partir de **deux** origines : un passage resté sur un seul appareil — le cas normal — n'affiche rien, pour ne pas ajouter de bruit à un rapport qui n'a rien à signaler.

| Élément | Ce qu'il dit |
|---|---|
| Le bandeau | À deux origines : le passage a commencé sur un appareil et s'est poursuivi sur un autre. Au-delà, la phrase annonce le **nombre** d'appareils. Dans les deux cas, à vérifier avec le candidat. |
| Une ligne par origine | *Origine 1*, *Origine 2*… : la **famille d'appareil** en clair (ordinateur, mobile, tablette, appareil inconnu) et la plage horaire pendant laquelle elle a répondu. Les origines au-delà de la première sont mises en évidence. |
| Réponses en alternance | Mention renforcée quand les plages de deux appareils **se chevauchent** — le signal le plus sérieux : ce n'est plus une reprise, ce sont deux passages entremêlés. Au-delà de deux origines, la mention dit « au moins deux » : le chevauchement se juge par paire, rien ne garantit que toutes se recouvrent. |

#### Règles de gestion

| Règle | Comportement |
|---|---|
| On signale, jamais on ne bloque | Aucun passage n'est interrompu, aucune copie n'est invalidée. Un changement d'appareil peut être parfaitement **légitime** : batterie vide, plantage du navigateur, poste indisponible. Le rapport le dit, le recruteur décide. |
| Ce n'est pas une preuve | Le bloc établit qu'un *autre appareil* a écrit, rien de plus : il ne dit ni qui, ni où, ni pourquoi. Il appelle une vérification avec le candidat, pas une conclusion. |
| Rien n'est conservé en clair | Seules des **empreintes** sont comparées entre elles. **Aucune adresse ni aucun matériel** n'est enregistré ni affiché — ni pour le recruteur, ni pour un tiers, ni dans un export. La mesure ne parle que d'*appareil*. |
| Mesure figée à l'envoi | Comme toutes les mesures anti-triche : activée à l'envoi ou pas du tout. Un passage parti sans elle n'a pas d'origines à montrer, même a posteriori. |
| Visible aussi côté tiers | Le bloc part avec le rapport partagé quand la surveillance est incluse (§12) : le tiers voit le même signal que le recruteur, sans qu'aucun autre candidat n'y soit nommé. |

## Assistance IA

L'IA **propose**, l'humain **décide**. Elle ne pose aucun verdict, n'envoie rien à un candidat et n'enregistre rien dans la bibliothèque sans un geste explicite du recruteur. Une note qu'elle a suggérée est une note comme les autres : elle reste **modifiable** à tout moment, y compris longtemps après.

Elle n'est jamais une destination : aucune entrée de menu, aucune conversation. Un geste, sur l'écran où le travail se fait déjà — le rapport, la campagne, la banque de questions, la banque de tests.

> **La signature ✦**
> 
> Tout ce que l'IA propose porte le glyphe ✦ et le liseré dégradé cyan → violet → vert. Cette signature ne sert à rien d'autre dans l'application : là où elle n'est pas, l'IA n'est pas intervenue. Elle échappe volontairement au thème du cabinet (§18) — un geste d'IA doit se reconnaître à l'identique sur un écran Résultats et sur un écran Bibliothèque.

### Où l'IA se pose

| Écran | Le geste proposé |
|---|---|
| Rapport d'une copie | Une suggestion de note par réponse libre, et la correction automatique du rapport entier. |
| Rapport partagé à un tiers | Les mêmes suggestions, **si et seulement si** le partage porte le droit de correction (§12). Sinon, aucune trace d'IA. |
| Détail d'une campagne | La file des corrections en attente, tous candidats confondus. |
| Mes questions | La génération de brouillons de questions. |
| Mes tests | La génération d'un test complet en brouillon. |
| Paramètres → IA | Activation, correction automatique en fin de passage, quotas et consommation. |

Les catalogues **officiels** n'offrent aucune génération : l'IA écrit dans la bibliothèque du cabinet, jamais dans celle de la plateforme. Le tableau de bord, les candidats et les écrans d'administration n'en portent pas non plus.

### Correction assistée d'une réponse libre

| Règle | Comportement |
|---|---|
| Qui peut la demander | Seul qui peut déjà **poser une note** : le recruteur du cabinet, ou le tiers dont le partage porte le droit de correction. Un lecteur en simple relecture ne voit pas le bouton. |
| Le geste | ✦ Proposer une correction, à côté de *Corriger* sur une réponse en attente, dans l'éditeur de correction ouvert, et à côté de *Modifier* sur une réponse **déjà notée** — une note posée n'est pas une note figée. |
| Ce qui est proposé | Une **note** sur le barème de la question (les demi-points sont admis) et une **justification** rédigée. Rien n'est enregistré à ce stade. |
| Les trois issues | *Valider* écrit la note telle quelle. *Ajuster…* verse la proposition dans les champs de correction manuelle, points et commentaire compris, et rend la main. *Ignorer* referme sans rien écrire. |
| Traçabilité | Une note issue de l'IA porte la pastille ✦ corrigée avec l'IA sur sa ligne du rapport. La modifier ensuite à la main est toujours possible. |
| Suggestion mémorisée | Redemander une suggestion sur **la même réponse** ressort celle qui a déjà été calculée, immédiatement et **sans consommer de quota**. On peut donc rouvrir un rapport autant de fois qu'on veut. |
| Copie blanche | Une réponse vide n'est pas notée par l'IA : elle se corrige à la main. |
| Score | Inchangé : le score reste *provisoire* tant qu'une réponse libre attend sa note, et se recalcule à chaque note posée (§15). |

### Correction automatique d'un rapport

| Règle | Comportement |
|---|---|
| Quand le geste apparaît | ✦ Corriger automatiquement n'est proposé en tête de rapport que s'il **reste** au moins une réponse libre à corriger. |
| Ce qui est annoncé | La fenêtre dit combien de questions seront notées et prévient que les notes seront **enregistrées sans validation individuelle**. On confirme, ou on renonce. |
| Pendant | Une progression réponse par réponse (« 3 réponses sur 7 corrigées »). La fenêtre reste ouverte jusqu'au bout — elle le demande explicitement. |
| Après | Chaque note reste **ajustable** depuis le rapport, une par une, comme n'importe quelle correction manuelle. |
| Interruption | Les notes déjà enregistrées sont **conservées** ; les réponses non traitées restent simplement en attente. |
| Une à la fois | Deux corrections automatiques ne peuvent pas tourner sur le même rapport. |

#### L'option « Corriger automatiquement en fin de passage »

Réglage d'organisation, **désactivé par défaut** (§18). Activé, il déclenche la correction dès qu'un candidat **termine** son épreuve, sans que personne ne l'ait demandé — la nuit et le week-end compris. Deux conséquences à assumer : la consommation mensuelle monte toute seule, et un rapport peut arriver **déjà pré-corrigé**. Le rapport le dit alors à l'ouverture. Les notes restent ajustables.

### File de corrections d'une campagne

| Règle | Comportement |
|---|---|
| Où | Sur le détail de la campagne (§9), sous l'avancement — et seulement si au moins un passage est terminé. |
| Ce qu'elle enchaîne | Les questions libres **en attente de cette campagne**, tous candidats confondus, l'une après l'autre : « Question 3 sur 12 », le nom du candidat, l'énoncé, la réponse, les consignes de correction s'il y en a. |
| Le geste | La même carte de suggestion que sur le rapport, avec trois sorties : *Valider*, *Ajuster…* — points et commentaire se modifient **sur place**, sans quitter la file — et *Passer*. |
| Ce qui est passé | Reste à corriger : passer n'est pas écarter. Le bilan de fin le rappelle (« 9 questions corrigées, 3 passées »). |
| File vide | Message explicite : aucune question libre en attente sur cette campagne. |

### Génération de questions

Depuis **Mes questions** (§5). Les **sept types** sont générables — QCM, choix multiple, réponse libre, échelle, remise en ordre, association, texte à trous.

| Champ | Ce qu'il pilote |
|---|---|
| Type de question | Un des sept types. Il est **figé** sur les brouillons produits. |
| Domaine | Obligatoire ; figé lui aussi sur le brouillon. |
| Compétences | Facultatives, saisies en étiquettes. Dès qu'il y en a une, un réglage **Cibler** arbitre entre *ces compétences uniquement* et *élargir au domaine*. Sans compétence saisie, l'IA couvre les compétences les plus représentatives du domaine. |
| Difficulté | Facile, moyen ou difficile. |
| Nombre de brouillons | De 1 à 5 par demande. |
| Précision | Consigne libre (« orienter vers la gestion des erreurs », « viser un profil junior »). |

#### Le brouillon, et les trois décisions

| Règle | Comportement |
|---|---|
| Rien n'entre tout seul | Une question générée arrive en **brouillon**. Tant qu'elle n'est pas adoptée, elle n'est ni dans la banque, ni utilisable dans un test. |
| Adopter | Enregistre la question dans la bibliothèque du cabinet, telle quelle. |
| Relire | Ouvre le brouillon dans l'éditeur de question habituel. Le domaine et le type sont fixés ; **tout le reste se modifie librement** — énoncé, réponses, barème, compétences. La bonne réponse est déjà cochée : c'est bien ce qu'il faut relire. |
| Écarter | Abandonne le brouillon. |
| Ne rien décider | Le brouillon reste en attente — c'est ce qui rend honnête le compteur de reprise. |
| Origine non exposée | Une question adoptée est une question comme une autre : rien à l'écran ne dit qu'elle vient d'une génération, et l'API ne le rend jamais. Le fait est conservé en base pour la mesure interne, il ne sort pas. |
| Régénérer remplace | Relancer une génération **perd** les brouillons non traités. L'application le dit et demande confirmation, avec leur nombre. |

### Génération d'un test entier

Depuis **Mes tests** (§6). L'IA compose un test complet — ses questions comprises — au lieu de les produire une à une.

| Champ | Ce qu'il pilote |
|---|---|
| Domaine et métier visé | Les deux sont obligatoires, le métier se choisit parmi ceux du domaine retenu. C'est ici que le **métier** se déclare : une question n'en porte pas, un test si (§6). |
| Compétences | Facultatives, avec le même arbitrage **Cibler** que pour les questions. |
| Difficulté | Difficulté visée de l'ensemble. |
| Nombre de questions | De 3 à 15 (8 par défaut). |
| Types de questions | **Variée** — recommandé, et proposé en premier : l'IA répartit elle-même les types. Sinon, on impose les types voulus. |
| Précision | Consigne libre, comme pour les questions. |

#### Relecture du brouillon de test

| Règle | Comportement |
|---|---|
| Le récapitulatif | En tête : le **nom du test** (modifiable), son domaine, son métier, sa difficulté, le nombre de questions et la durée estimée, puis l'avancement de la relecture (« 5 sur 8 décidées »). |
| Question par question | Trois décisions : *Garder telle quelle*, *Relire* — l'éditeur habituel — ou *Écarter*. |
| Adopter le test | Enregistre le test **et ses questions** dans la bibliothèque du cabinet. Il faut avoir tranché sur chaque question, et en garder au moins une : un test vide ne s'envoie pas. |
| Rien n'est envoyé | Un brouillon de test ne part à aucun candidat. L'envoi reste le geste normal, après adoption (§10). |
| Un seul à la fois | Un seul brouillon de test par recruteur : en relancer un demande confirmation. |
| Échec en cours d'adoption | Les questions déjà enregistrées sont **conservées** dans la banque. |

### Brouillons persistants

Les brouillons ne vivent pas dans le navigateur : ils **survivent** à la fermeture de la fenêtre, au rafraîchissement de la page et au changement de session ou de poste. Une génération lancée continue même si l'on ferme la fenêtre.

| Règle | Comportement |
|---|---|
| Où on les retrouve | Sur le bouton ✦ lui-même, qui change de libellé : *Reprendre les brouillons (4)* côté questions, *Reprendre le brouillon de test* côté tests. Il n'y a pas d'écran « mes brouillons » à aller chercher. |
| Génération en cours | Le bouton l'annonce également (*Génération en cours…*), et la retrouve après un rafraîchissement. |
| Ils sont personnels | Un brouillon appartient au recruteur qui l'a demandé ; il n'apparaît pas chez ses collègues. |
| Ils ne s'accumulent pas | Les brouillons laissés sans décision finissent par expirer, et leur nombre en attente est plafonné : au-delà, l'application demande d'en traiter quelques-uns avant d'en générer d'autres. |

### Réglages d'organisation

Onglet **IA** des Paramètres (§18). Les réglages valent pour **toute l'organisation**, pas pour un recruteur.

| Réglage | Effet |
|---|---|
| IA activée | Actif par défaut. Coupé, **aucune** fonctionnalité d'IA n'est proposée nulle part : ni suggestion de correction, ni génération. |
| Corriger automatiquement en fin de passage | Inactif par défaut. Voir plus haut. |
| Quotas mensuels | Quatre plafonds distincts — *suggestions de correction*, *corrections automatiques*, *générations de questions*, *générations de tests*. Champ **vide** = pas de limite ; **0** = usage interdit. |
| Consommation du mois | Un compteur par usage, avec sa jauge et son reste, et la date de bascule du mois. Les usages non consommés ne sont pas affichés. |
| Ce qui compte pour un | Une **suggestion** se compte à la réponse notée. Une **correction automatique**, une **génération de questions** ou de **test** se comptent au **lot lancé** : un geste, une unité, quel que soit le nombre de questions à l'intérieur. |
| Ce qui ne coûte rien | Une demande qui **échoue** ne consomme rien, et une suggestion déjà obtenue redemandée non plus. |
| Le mois | Un mois calendaire, identique pour toute l'organisation quel que soit le fuseau de chacun. Rien n'est « remis à zéro » : la période bascule. |
| Le tiers correcteur | Un tiers qui demande une suggestion depuis un rapport partagé consomme le quota du **cabinet** qui lui a ouvert le partage. |

#### Ce qui peut refuser

| Situation | Ce que voit le recruteur |
|---|---|
| IA désactivée | Message renvoyant vers Réglages → IA. Aucun bouton ✦ n'est affiché de toute façon. |
| Quota atteint | Le message nomme **l'usage concerné**, le plafond atteint et la date de bascule du mois — les autres usages restent disponibles. |
| Trop de demandes d'un coup | Invitation à réessayer dans un instant. |
| Indisponibilité passagère | Le travail en cours **n'est pas perdu** : on réessaie. |

> **Ce que l'IA ne fait pas**
> 
> Elle ne pose pas de verdict sur un candidat, ne classe personne, n'écarte personne. Elle ne modifie aucune copie rendue — un rapport reste figé tel qu'il a été passé (§15). Elle n'écrit pas dans les catalogues officiels, ne remplace aucune note sans qu'on le lui demande, et n'empêche jamais de corriger à la main.

## Tableau de bord

Une seule page d'entrée, orientée action.

| Bloc | Contenu |
|---|---|
| À traiter | Les copies à corriger et les dossiers reçus, avec le geste direct. |
| Le pouls · 30 jours | Tests envoyés, taux de complétion, score moyen, en attente de correction. Ces compteurs portent sur les **tests seuls** : les dossiers de questionnaire ont leur propre carte « dossiers reçus », et la fenêtre de 30 jours se compte depuis la **date d'envoi** de l'invitation. |
| Recrutements en cours | Les campagnes actives, leur avancement et leur échéance. |
| Activité récente | Le fil des événements — chaque ligne ouvre l'objet concerné. Chaque ligne est datée de l'heure réelle du geste : l'envoi quand l'invitation est partie, la remise quand le dossier a été rendu. |
| Entonnoir | Invités → commencés → terminés sur 30 jours, pour les **tests** envoyés sur la période. |

## Paramètres

### E-mails aux candidats

Quatre modèles éditables : **Invitation**, **Relance**, **Questionnaire**, **Parcours de campagne**. Les variables entre accolades sont remplacées à l'envoi et un aperçu se met à jour en direct.

Le **nom d'expéditeur** de ces e-mails — et de ceux qui portent un lien de partage à un tiers — suit la **marque blanche** : c'est le nom du cabinet quand son plan l'inclut, « Evalixo » sinon. L'**adresse d'envoi**, elle, ne change jamais, et aucun **logo** n'est inséré dans les e-mails à ce stade (voir *Apparence* ci-dessous).

[capture d'écran : Paramétrage des e-mails]

*Sujet, message, variables disponibles et aperçu rendu avec des valeurs d'exemple.*

### IA

Un onglet dédié règle ce que l'IA a le droit de faire pour l'organisation : son **activation**, la correction automatique en fin de passage, les **quotas mensuels** par usage et le suivi de la **consommation** du mois. Le détail est en §16.

### Apparence

La **marque blanche** d'Evalixo, c'est le **logo** et le **nom** du cabinet, posés sur tout ce que voient les **candidats** et les **tiers**. Les **trois couleurs de bloc** et la **police** du même écran ne changent pas de rôle : elles habillent l'**espace du recruteur** — la police atteignant, seule, les pages candidat. Les **couleurs ne s'appliquent pas aux pages publiques** : c'est une décision produit, pas une limite technique (voir l'encadré plus bas).

#### Ce qui se règle

| Réglage | Règle |
|---|---|
| Logo | **PNG ou JPEG**, **300 Ko** au plus. L'image est **redimensionnée** à l'enregistrement — on dépose le fichier tel qu'on l'a, l'écran s'occupe du reste. Un logo posé se **retire** depuis la même zone. |
| Nom de marque | Le nom affiché aux candidats et aux tiers. Il est **prérempli avec le nom du cabinet** (§3) et se modifie librement — un cabinet peut évaluer sous une enseigne différente de sa raison sociale. Vidé, il **retombe sur le nom du cabinet** : la marque n'est jamais vide. |
| Aperçu | Un aperçu **fidèle** montre le rendu — l'en-tête tel que le candidat le verra, avec le logo et le nom — pendant le réglage, avant enregistrement. |
| Police | Habille l'espace du recruteur **et** les pages candidat : c'est le seul réglage typographique qui franchit la porte publique. |
| Trois couleurs de bloc | Une par groupe du menu — **Bibliothèque** (violette par défaut, écrans Tests et Questions), **Questionnaires** (verte par défaut), **Recrutement** (corail par défaut : Campagnes, Postes, Clients, Candidats et les rapports, qui se lisent toujours depuis un candidat). Il n'y a **pas** de « couleur de la marque » : **l'accent d'un écran suit le bloc où l'on se trouve** — boutons, onglets actifs, rails, en-têtes pleins, halos de focus. L'aperçu montre les trois rails côte à côte pendant le réglage. |
| Réinitialiser | Un seul bouton, et il ramène **TOUT** à l'identité Evalixo : les trois couleurs, la police, le nom de marque — et le **logo, purgé**. Il ne reste rien du cabinet après le geste, sur aucune surface. |
| Portée | Réglage de **cabinet** : il vaut pour tous ses recruteurs et pour tous les liens qu'ils envoient. Il n'existe pas de marque par recruteur, par campagne ni par client. |

#### Où la marque apparaît

Quand le plan du cabinet inclut la **marque blanche** (§19) et que le cabinet a posé sa marque, le logo et le nom remplacent l'identité Evalixo sur les surfaces suivantes.

| Surface | Ce qui porte la marque |
|---|---|
| Passage candidat `/t/` | **En-tête** de la page (logo + nom) et **titre de l'onglet** du navigateur. |
| Parcours de campagne `/p/` | Idem : en-tête et titre d'onglet, sur toute la traversée du parcours. |
| Partage de résultat `/r/` | Idem, pour le tiers qui lit des candidats et leurs épreuves (§12). |
| Partage de test `/s/` | Idem, pour le tiers qui relit ou compose un test (§12). |
| Rapport imprimable | Le **pied de page** devient « *Rapport établi par {nom du cabinet}* … » : plus aucune mention d'Evalixo sur le document que le client reçoit. |
| E-mails aux candidats et aux tiers | Le **nom d'expéditeur** devient celui du cabinet. L'**adresse d'envoi ne change pas** — elle reste celle d'Evalixo — et il n'y a **pas de logo dans les e-mails** à ce stade. Vaut pour les quatre gabarits candidats comme pour les envois de partage. |
| Espace recruteur | Le logo et le nom s'y affichent aussi, aux côtés des couleurs de bloc et de la police — mais c'est l'espace du cabinet, pas une surface publique. |

> **Le repli Evalixo est le comportement par défaut**
> 
> Un cabinet qui **n'a rien configuré**, ou dont le plan **n'inclut pas** la marque blanche, voit toutes ces surfaces garder l'**identité Evalixo** — logo, nom, titre d'onglet, nom d'expéditeur, pied du rapport. **Aucune erreur**, aucun trou, aucun encart « logo manquant » : le repli est un état normal, pas une panne. Le repli se joue **réglage par réglage** : un cabinet qui a posé un logo mais pas de nom de marque affiche son logo et le nom du cabinet.

> **L'écran reste utilisable sans la fonction**
> 
> En **Free** — ou sur tout plan sans marque blanche — l'écran *Apparence* n'est **pas fermé** : le cabinet y prépare sa marque, la dépose, la voit dans l'aperçu, et l'écran **le dit** — elle s'appliquera aux pages candidat et tiers à la **montée de gamme**, sans rien avoir à refaire. C'est l'exception à la règle « fonction non incluse ⇒ geste fermé » de §19 : ici on prépare, on n'expose pas.

> **Les couleurs ne franchissent pas la porte publique**
> 
> Décision produit : les trois couleurs de bloc **ne s'appliquent pas** aux pages `/t/`, `/p/`, `/r/` et `/s/`. Elles disent *où l'on est* dans une application qu'on parcourt tous les jours ; un candidat voit un écran, une fois, et n'a aucun bloc à distinguer. Ce qui l'intéresse — *qui me fait passer ce test* — tient dans le **logo** et le **nom**. Les aplats de ces pages gardent donc les couleurs Evalixo, quel que soit le réglage du cabinet.

#### Erreurs

| Situation | Ce que voit le recruteur |
|---|---|
| Logo trop lourd | Le fichier dépasse **300 Ko** : le dépôt est refusé par un message clair qui **rappelle la limite** — « *Logo trop lourd* », avec le poids accepté. Le logo en place n'est pas touché. |
| Format non pris en charge | Autre chose qu'un **PNG** ou un **JPEG** : refus explicite nommant les deux formats acceptés. |
| Fichier illisible | Une image corrompue est refusée de la même façon ; rien n'est enregistré. |
| Aucun refus silencieux | Un dépôt refusé ne modifie **rien** : l'écran garde l'état précédent et le recruteur peut redéposer aussitôt. |

> **Le chrome reste indigo**
> 
> Les écrans qui n'appartiennent à aucun bloc gardent l'**indigo** par défaut, non réglable : le **tableau de bord**, les **paramètres** et les écrans d'**administration**. La **barre latérale** et la **barre du haut** aussi : le cadre de l'application ne change pas de couleur quand on passe d'un monde à l'autre — c'est lui qui dit qu'on est revenu au même endroit. Dans la barre latérale, seule l'*entrée active* porte la couleur de son bloc.

> **Une teinte claire n'est jamais refusée**
> 
> Les **rails et pastilles** gardent exactement la teinte choisie. Seuls les **aplats** (boutons, en-têtes pleins) sont assombris juste assez pour que le texte reste lisible — et si la teinte est vraiment lumineuse, c'est le texte du bouton qui passe au sombre. Une note discrète l'annonce pendant le choix. Une bibliothèque en jaune donne donc des rails jaunes et des boutons lisibles.

> **Côté candidat : le logo, le nom et la police**
> 
> Les écrans vus par le candidat portent le **logo**, le **nom de marque** et la **police** du cabinet. Le candidat ne navigue pas dans vos blocs : il voit un écran, une fois — les aplats y gardent les couleurs Evalixo par défaut.

> **Un test porte la couleur de sa bibliothèque**
> 
> Il n'y a pas de « couleur des tests » séparée : un test **fait partie de la bibliothèque**, il en porte donc la couleur. Le réglage « Bibliothèque » déplace d'un coup toute référence à un test dans l'application — rails et pastilles de test, mini-rail des cartes « Résultats partagés », lignes des sélecteurs d'épreuve, panneaux Tests d'un candidat ou d'une campagne, référence test du fil « Demandes / Partages ».
> 
> Échappent au thème les **couleurs sémantiques** (danger, avertissement, succès, pastilles de domaine et de difficulté) et les **couleurs du fil d'échanges d'un partage** — noms colorés par auteur, jalons de la conversation : un fil doit se lire pareil des deux côtés du lien. La **signature de l'IA** y échappe aussi (§16) : elle doit se reconnaître à l'identique d'un écran à l'autre.

> **Le menu latéral suit les blocs**
> 
> Le **filet** qui longe un groupe et l'**entrée sélectionnée** portent la couleur de leur bloc : violet Bibliothèque, vert Questionnaires, corail Recrutement, dégradé Collaboration. Le fond de la barre, lui, reste indigo.

> **Collaboration : une identité en dégradé**
> 
> La Collaboration est le seul bloc qui tient les deux bouts — ce qu'on confie (la *Bibliothèque*) et à qui on le confie (le *Recrutement*). Son identité est donc un **dégradé** de la couleur Bibliothèque à la couleur Recrutement, présent à trois endroits : l'entrée *Demandes / Partages* du menu quand elle est sélectionnée, le bouton *« Ajouter une collaboration »*, et le soulignement de l'onglet actif de l'écran. Les libellés restent à l'encre forte, lisibles en thème clair comme en sombre.
> 
> Le dégradé se construit sur les deux réglages : changer l'un ou l'autre déplace la borne correspondante. Les autres accents pleins de cet écran (liens, halos de focus, boutons) prennent la couleur *Bibliothèque* — la borne gauche, celle qui dit ce dont il s'agit.

[capture d'écran : Paramètres d'apparence]

*Identité visuelle du cabinet.*

[capture d'écran : Paramètres du compte]

*Compte personnel et notifications — réglage par utilisateur, pas par cabinet.*

> **Portée des réglages**
> 
> Les e-mails et l'apparence appartiennent au **cabinet** : ils s'appliquent à tous ses recruteurs. Le compte et les notifications appartiennent à l'**utilisateur**.

## Plans & abonnement

Chaque cabinet est rattaché à un **plan** qui **borne son usage** de la plateforme : combien de recruteurs y travaillent, combien d'épreuves partent chaque mois, quelle quantité de contenu la banque accueille, et quelles **fonctions** lui sont ouvertes. Quatre plans, du plus léger au plus complet — **Free**, **Starter**, **Growth** et **Scale** : plus le plan monte, plus les plafonds s'élèvent et plus de fonctions s'ouvrent.

Un cabinet créé en **self-service** démarre sur **Free** (§3), compteurs à zéro. Le cabinet **monte lui-même** sur Starter ou Growth, par carte bancaire, depuis son écran « Abonnement & consommation » ; Scale se négocie et s'active par l'équipe Evalixo. Les **bornes** d'un plan, elles, ne se règlent jamais côté cabinet : c'est l'**administrateur de la plateforme** qui tient la grille (§20).

### La grille

| Plan | Pour qui | Prix | Comment il s'obtient |
|---|---|---|---|
| Free | Pour découvrir Evalixo, sans limite de temps. | **0 €** / mois | À la création du compte, sans geste et **sans carte bancaire**. C'est aussi le plan sur lequel on **retombe** après une résiliation. |
| Starter | Indépendant ou premier recrutement. | **29 €** / mois | **Self-service** : paiement par **carte** depuis l'écran d'abonnement, facturé mensuellement, **sans engagement**. |
| Growth le plus choisi | Cabinet ou équipe qui recrute en continu. | **89 €** / mois | Idem Starter : carte, mensuel, sans engagement. |
| Scale | Multi-équipes, volume et exigences sur mesure. | **Sur devis** | **Sur devis** : on prend contact, l'équipe Evalixo active l'offre et envoie les **factures par e-mail**. |

**Les prix sont HORS TAXES.** La **TVA applicable est ajoutée au moment du paiement**, selon le pays et le statut du client : le montant de la grille est une **base**, pas le total débité. Le taux n'est écrit nulle part dans le produit — il dépend de l'acheteur, et un taux gravé mentirait au premier client hors de France. Le total, taxe comprise, est celui qu'affiche la page de paiement et que porte la facture.

Un plan peut aussi être posé **à la main** par l'équipe Evalixo, quel qu'il soit — offre négociée, geste commercial, dépannage. Le cabinet en profite exactement comme s'il l'avait acheté ; simplement, il n'a rien à payer en ligne (voir « Une offre gérée par Evalixo » plus bas).

### Ce qu'un plan borne

| Limite | Ce qu'elle compte |
|---|---|
| Sièges recruteurs | Le nombre de comptes recruteurs que le cabinet peut faire vivre. Au plafond, on n'en ajoute plus tant qu'un siège ne s'est pas libéré ou que le plan n'a pas grandi. |
| Passages par mois | Le nombre d'épreuves envoyées sur le **mois en cours**. Compteur **mensuel**. |
| Tests créés | La taille de la banque de tests du cabinet (§6). Plafond de stock, pas de rythme. |
| Questions créées | La taille de la banque de questions (§5). Plafond de stock lui aussi. |
| Candidats | Le nombre de candidats enregistrés dans le cabinet (§10). |
| Quotas IA | Des plafonds d'IA — **suggestions** de correction et **générations** de questions ou de tests — portés par le plan, en plus des quotas fins que le cabinet peut resserrer lui-même dans Paramètres → IA (§16). Compteurs **mensuels**. |

Les plafonds de **stock** (tests, questions, candidats, sièges) comptent ce qui **existe** à l'instant ; les plafonds **mensuels** (passages, IA) comptent ce qui a été **consommé** depuis le début du mois.

### Fonctions incluses ou non

Au-delà des compteurs, un plan **ouvre ou ferme des fonctions entières** :

| Fonction | Ce qu'elle recouvre |
|---|---|
| Marque blanche | Le **logo** et le **nom** du cabinet sur ce que voient les **candidats** et les **tiers** — pages `/t/`, `/p/`, `/r/`, `/s/` (en-tête et titre d'onglet), pied du rapport imprimable, nom d'expéditeur des e-mails (§18). Sans elle, ces surfaces gardent l'identité **Evalixo**, sans erreur. L'écran *Apparence* reste accessible quel que soit le plan : le cabinet y prépare sa marque, elle s'appliquera à la montée de gamme. |
| Collaboration / partage à un tiers | Confier un test ou un rapport à un tiers pour relecture, édition ou correction (§12). |
| Anti-triche webcam | Les mesures de surveillance par **webcam** au passage (§11). Les autres mesures ne dépendent pas de cette fonction. |
| Exports | Les exports de données — la sortie CSV de l'état de facturation, notamment (§13). |
| Pré-facturation | L'écran **Facturation** lui-même (§13) : préparer, suivre et exporter ce que les clients doivent. |

### Quand une limite est atteinte

| Situation | Ce que voit le recruteur |
|---|---|
| Plafond de stock atteint | La création est **bloquée** — un test, une question, un candidat ou un siège de plus est refusé — avec une invitation à **passer au plan supérieur**. Ce qui existe déjà n'est jamais touché. |
| Plafond mensuel atteint | L'action du mois — un envoi de plus, une demande d'IA — est **bloquée** jusqu'à la bascule du mois, avec la même invitation. Les autres usages restent disponibles. |
| Fonction non incluse | Le geste (partage, webcam, export, facturation, placement) est fermé **dès le clic** : la modale de montée de gamme s'ouvre à la place de l'action, sans aller-retour serveur — le serveur garde la même garde en 422 `FEATURE_NOT_IN_PLAN`. Dans le réglage du déroulement d'un envoi, les deux mesures webcam (caméra obligatoire, captures webcam) sont marquées « Non inclus dans votre plan » et le niveau *Stricte* s'applique **sans elles** ; le micro et les captures d'écran restent de l'anti-triche basique, ouvert à tous. La **marque blanche** fait exception : l'écran *Apparence* reste ouvert et le cabinet y prépare sa marque — ce sont les **surfaces publiques** qui gardent l'identité Evalixo tant que le plan ne l'inclut pas (§18). |
| Le blocage n'efface rien | Une limite atteinte arrête l'action à venir ; elle ne supprime ni ne dégrade jamais ce qui est déjà en place. |

### Consulter son plan et sa consommation

Paramètres → **« Abonnement & consommation »** (§18). Le recruteur y lit le plan du cabinet, chaque limite avec sa jauge et son reste, l'état des fonctions incluses, et la date à laquelle les compteurs mensuels basculent. C'est aussi **de cet écran** que part l'abonnement.

### S'abonner et payer

Le paiement est confié à **Stripe**, notre prestataire : aucune donnée de carte ne transite par Evalixo ni n'y est conservée.

Un visiteur peut arriver avec une **intention d'achat** : les boutons des cartes Starter et Growth du site public mènent à l'inscription en **emportant le plan visé**. Dans ce cas, l'espace **propose** de finaliser l'abonnement à la première connexion, par un **bandeau refermable** — il ne l'impose jamais, et le cabinet naît bien sur **Free** tant que rien n'est payé.

| Geste | Ce qui se passe |
|---|---|
| Passer à Starter ou Growth | Le bouton du plan ouvre une **page de paiement Stripe** (carte bancaire), puis ramène le recruteur sur son écran d'abonnement. L'abonnement est **mensuel, sans engagement**. |
| Le prix affiché est **HORS TAXES** TVA en sus | La page de paiement **ajoute la TVA applicable**, selon le pays et le statut de l'acheteur : un Starter annoncé **29 € HT** est débité **29 € plus la taxe**. L'écran et la vitrine le disent **au prix**, jamais en note de bas de page : une taxe découverte à la page de paiement est la pire des surprises, et c'est elle qui fait abandonner un panier. Le **taux n'est écrit nulle part** dans le produit — il dépend de l'acheteur. Le total figure sur la facture, consultable depuis le portail. |
| Le plan s'active au **paiement confirmé** jamais avant | C'est **Stripe qui annonce** le paiement à Evalixo ; le plan bascule à cette annonce, pas au retour du navigateur. Revenir sur l'écran depuis une page de paiement abandonnée ne change donc rien — et le plan peut apparaître avec quelques secondes de décalage. |
| L'ARGENT du cabinet n'appartient qu'à son PROPRIÉTAIRE | Souscrire, changer d'offre et ouvrir le portail de facturation sont réservés au **créateur du cabinet** (V45). Un recruteur invité partage l'espace de travail, **pas la carte bancaire** de celui qui l'a invité — et le portail du prestataire lui montrerait d'ailleurs le moyen de paiement du cabinet. L'écran d'abonnement reste **entièrement LISIBLE** par toute l'équipe (plan, jauges, fonctions incluses) : connaître ses plafonds n'a jamais engagé une dépense. Seuls les **gestes** disparaissent, remplacés par une phrase qui dit **qui** peut agir. Le serveur refuse les deux appels par 403 BILLING_OWNER_ONLY : un écran n'est jamais la seule autorité sur une règle. **L'exception qui n'en est pas une :** un cabinet **SANS propriétaire** ne verrouille personne. L'index unique partiel garantit « au plus un », jamais « au moins un » — un cabinet provisionné à la volée, ou dont la ligne du créateur a disparu, n'en a aucun ; lui refuser le paiement reviendrait à l'enfermer dehors avec une serrure dont personne n'a la clé. L'écran d'administration sait désigner un propriétaire quand il en manque un. Le verdict voyage dans le récap (canManageBilling) : l'écran lit le MÊME que celui opposé au geste, il ne le redérive pas, et ne montre donc jamais un bouton refusé au clic. |
| Raccourci « Améliorer mon offre » barre du haut | Un bouton orange à côté du « ? », sur tous les écrans : la montée de gamme n'existait que dans **Paramètres > Abonnement**, et personne ne l'y cherchait. Il mène à cet écran, la même destination que la modale de blocage. Il ne s'affiche **que s'il y a vraiment quelque chose à faire** : un palier existe au-dessus (le rang vient de la **grille publique**, jamais d'une liste de codes figée, puisqu'elle est éditable côté admin), l'appelant peut engager la dépense, et l'offre n'est pas une offre **négociée** posée par l'équipe. Dans tous les autres cas il disparaît : un appel à l'action qui mène à « contactez-nous » n'est pas un raccourci, c'est une impasse. |
| « Gérer mon abonnement » | Ouvre le **portail client Stripe**, hors d'Evalixo : le recruteur y **change de carte**, **change de plan**, retrouve ses **factures** et **résilie**. Ce portail n'apparaît que si le cabinet a déjà payé au moins une fois. |
| Changer de plan (Starter ⇄ Growth) | Se fait **dans le portail**, jamais par un **second achat** : tant qu'un abonnement est en cours, l'écran d'abonnement ne propose plus de payer, il renvoie vers « Gérer mon abonnement ». Le nouveau plan est **répercuté automatiquement** sur le cabinet dès que Stripe l'annonce — montée comme descente —, sans aucun geste côté Evalixo. Le cabinet ne peut pas porter **deux abonnements**. |
| Résilier | Depuis le portail. Rien n'est coupé le jour de la demande : l'abonnement **va jusqu'au bout de la période déjà payée**, puis le cabinet **retombe sur Free**. Rien n'est supprimé : le contenu reste, seules les bornes du plan Free s'appliquent de nouveau — ce qui dépasse n'est pas détruit, mais la création est refusée tant qu'on est au-dessus. |
| Le bandeau d'annulation jusqu'à l'échéance | Dès que l'annulation est enregistrée, l'écran « Abonnement & consommation » affiche un **bandeau** : le plan reste actif **jusqu'à la date de fin** de la période payée, puis le cabinet **reviendra sur Free**. Pendant tout ce délai, plafonds et fonctions du plan payant restent **entièrement ouverts** — l'annulation ne dégrade rien par avance. |
| Reprendre (annuler l'annulation) | Tant que l'échéance n'est pas passée, le recruteur **revient sur sa décision** depuis le portail, à tout moment : l'abonnement repart, la facturation reprend normalement à la période suivante, et le **bandeau disparaît** de l'écran d'abonnement. Aucun nouvel achat n'est nécessaire. |
| Free | Ne demande **aucune carte** : aucun bouton de paiement, aucun portail tant que le cabinet n'a jamais payé. |
| Scale | Ne s'achète **pas en ligne**. Le cabinet prend contact, l'équipe Evalixo active l'offre et lui envoie des **factures par e-mail** (lien de paiement hébergé, relances automatiques — voir §20). |

> **Une offre gérée par Evalixo**
> 
> Quand le plan a été posé **à la main** par l'équipe — offre négociée, Scale, geste commercial —, le cabinet n'a **rien à payer en ligne** : l'écran d'abonnement affiche le plan et sa consommation, et la gestion (changement, arrêt) se fait avec l'équipe Evalixo. Cette attribution manuelle **fait autorité** : elle n'est jamais écrasée par le prestataire de paiement.

### Les accès du cabinet

Le plan ne dit pas seulement combien de tests ou de candidats un cabinet peut détenir : il dit aussi **combien de personnes** y travaillent. Free et Starter ouvrent **un accès**, Growth **cinq**, Scale autant que le contrat le prévoit. Ces accès se tiennent depuis les paramètres, onglet **Équipe**.

| Règle | Comportement |
|---|---|
| Un seul gestionnaire le créateur | L'onglet Équipe appartient à la personne qui a **créé le cabinet** (§3), et à elle seule. Les autres ne le voient pas ; s'ils en forcent l'adresse, l'écran le leur dit au lieu de se taire. |
| Ajouter | Une adresse e-mail, un prénom ou un nom. Le compte est créé aussitôt et un **mot de passe provisoire** s'affiche **une seule fois** : c'est au créateur de le transmettre. La personne le change à sa première connexion. |
| Retirer | Le compte disparaît, mais **pas son travail** : tests, questions, candidats et campagnes appartiennent au cabinet et y restent. |
| Plafond | L'ajout au-delà du nombre d'accès du plan est **refusé**, avec l'invitation habituelle à monter de plan (§19). |
| Descendre de plan rien n'est supprimé | Un cabinet qui repasse à un plan comptant moins d'accès ne perd **aucun compte** : les accès en trop sont **SUSPENDUS**. La personne ne peut plus se connecter, tout le reste est intact. Remonter de plan, ou retirer un accès, la fait revenir **immédiatement** : rien n'est à recréer. |
| Qui est suspendu | Le **créateur** jamais : c'est lui qui paie, et c'est lui qui doit pouvoir régler la situation. Les autres le sont dans l'ordre inverse de leur arrivée, jusqu'à tenir dans le nombre d'accès du plan. |
| Changer de propriétaire administrateur | Le propriétaire est celui qui a créé le cabinet, et pour les cabinets ouverts avant cette règle, le compte le plus ancien. L'**administrateur de la plateforme** peut en désigner un autre depuis la fiche du cabinet (§20) : un créateur finit parfois par quitter le cabinet. Le cabinet n'a jamais deux propriétaires, et peut n'en avoir aucun, auquel cas la fiche le dit. |
| Ce que voit la personne suspendue | Sa connexion réussit, puis un **écran d'explication** s'affiche, seul : son accès est suspendu, rien n'a été supprimé, et il faut en parler à la personne qui a créé le cabinet. |

> **Les compteurs mensuels repartent de zéro le 1er**
> 
> Les compteurs **mensuels** — passages du mois, usages d'IA — se remettent à **zéro le 1er de chaque mois**. Les plafonds de stock (tests, questions, candidats, sièges), eux, ne « repartent » pas : ils comptent ce qui existe, et ne baissent qu'en supprimant.

## Supervision (administrateur)

[capture d'écran : Écran des sociétés]

*L'espace admin : sociétés, comptes recruteurs, candidats tous cabinets, messages de support.*

[capture d'écran : Comptes recruteurs]

*Les comptes recruteurs et leur société de rattachement.*

[capture d'écran : Candidats tous cabinets]

*Les candidats, tous cabinets confondus.*

[capture d'écran : Messages de support]

*Les demandes reçues via « Contactez-nous ».*

| Écran | Ce qu'on peut faire |
|---|---|
| Sociétés | Créer, renommer, supprimer un cabinet. L'identifiant technique est dérivé du nom à la création et **ne change jamais** : c'est la clé d'appartenance des comptes. |
| Recruteurs | Créer un compte, le rattacher à une société, réinitialiser son mot de passe. Le mot de passe temporaire n'est affiché **qu'une fois**. Cette voie subsiste à côté de l'inscription self-service (§3) : un compte ouvert ici est déjà rattaché, il ne passe donc pas par « Une dernière étape ». Chaque ligne affiche la **société** du recruteur et l'**offre** de cette société, en pastille colorée. |
| Candidats | Recherche et gestion transverses, tous cabinets confondus. |
| Messages | Les demandes envoyées via « Contactez-nous ». |
| Bibliothèque officielle | Création et révision des questions et tests officiels — sans jamais toucher les copies privées des cabinets. |

### L'offre, lisible depuis la liste des recruteurs

La colonne **Offre** dit à quel plan appartient le cabinet de chaque recruteur, sans ouvrir sa fiche. Elle se lit en **pastille**, et la couleur ne dépend pas du nom du plan mais de sa **manière de se vendre** : **gris** pour le palier gratuit, **orange** pour un abonnement payé par carte, **vert** pour un contrat sur devis — celui où l'administration peut avoir des gestes à faire à la main (facture, limites négociées).

| Règle | Pourquoi |
|---|---|
| L'offre vient de la société | Un plan se porte par **cabinet**, jamais par personne : deux recruteurs d'une même société affichent donc la même offre. |
| Sans société, pas d'offre | Un compte créé mais jamais connecté n'a pas encore de rattachement. Les deux colonnes affichent un tiret plutôt qu'une offre inventée. |
| La couleur suit le mode de vente | Les plans sont créés et renommés par l'administration. Teinter la pastille d'après le *nom* du plan se serait cassé au premier renommage ; gratuit / carte / devis, eux, ne bougent pas. |

> **Supprimer une société**
> 
> L'opération emporte toute sa production. Les comptes recruteurs doivent être supprimés **d'abord** : sans cela, leur prochaine connexion recrée la société automatiquement.

### Superviser un cabinet

Une page dédiée donne à l'administrateur la vue d'ensemble d'un cabinet. Il **choisit un cabinet** — et, s'il le veut, **un recruteur** de ce cabinet pour affiner —, puis lit d'un coup **tous les compteurs** : candidats, postes, clients, campagnes, tests et questions personnels, passages. À côté figure la **consommation** du cabinet — usage rapporté à son plan (§19), avec ce qu'il reste.

| Règle | Comportement |
|---|---|
| Le choix du périmètre | Le cabinet est obligatoire ; le recruteur est facultatif. Sans recruteur, les compteurs valent pour **tout le cabinet** ; avec, ils se restreignent à ce qu'il a produit. |
| Chaque compteur se déplie | Un compteur se **clique** et ouvre la **liste détaillée** de ce qu'il totalise — les candidats, les postes, les campagnes… — sans quitter la supervision. |
| Lecture, pas recrutement | L'administrateur observe ; il n'entre pas dans les écrans de recrutement du cabinet, fermés à son persona (§2). |

### Gestion des plans

C'est ici que se définissent les plans que les cabinets consulteront (§19). L'administrateur **crée** un plan, l'**édite** — ses plafonds et les fonctions qu'il ouvre — et l'**assigne** à un cabinet. Changer le plan d'un cabinet déplace aussitôt ses bornes ; ce qui dépasse alors le nouveau plafond n'est pas détruit, mais la création reste bloquée tant qu'on est au-dessus.

La fiche d'un plan porte aussi son **volet commercial** : son **accroche**, son **prix mensuel** et son **mode de vente**.

| Réglage | Règle |
|---|---|
| Mode de vente | Trois valeurs, et c'est le mode qui **désigne** ce qu'on attend : **gratuit** et **sur devis** ne portent **aucun prix** ; **libre-service** en exige un, **strictement positif** (un abonnement à 0 €, c'est le plan gratuit). Un prix saisi sous un mode qui n'en veut pas est simplement **ignoré**. |
| Prix mensuel hors taxes | En **euros**, c'est le prix **HORS TAXES** : la TVA applicable s'ajoute au paiement, selon le pays de l'acheteur. Ce qu'on saisit ici est donc une **base de calcul**, pas le montant débité. Les plans en libre-service sont publiés chez le prestataire de paiement : le premier enregistrement les y crée, un renommage y suit. |
| Changer un prix n'affecte pas les abonnés | Un nouveau tarif ne vaut que pour les **abonnements à venir** : les cabinets déjà abonnés **gardent le prix** auquel ils ont souscrit, jusqu'à ce qu'ils changent eux-mêmes de plan. Aucune facture passée n'est réécrite. |
| Accroche | La phrase affichée sous le nom du plan (site public et écran d'abonnement). Du texte, jamais une règle. |
| Le nom se change, la clé jamais | Le **libellé commercial** est libre ; l'identifiant technique du plan, lui, **ne change pas** — c'est lui qui relie la grille, les cabinets et le prestataire de paiement. |
| Supprimer un plan | Refusé tant qu'un cabinet y est rattaché. Il faut d'abord les réassigner ailleurs. |

### Assigner un plan à la main

Depuis la fiche d'un cabinet, l'administrateur pose **n'importe quel plan**, sans paiement : offre négociée, Scale, geste commercial, dépannage. Deux règles encadrent la cohabitation avec le paiement en ligne.

| Règle | Comportement |
|---|---|
| Une attribution manuelle fait autorité jamais écrasée | Un plan posé à la main n'est **jamais** modifié par le prestataire de paiement : ni un changement de plan, ni une résiliation venus de son côté ne le déplacent. |
| Un paiement abouti, si | Seul un **achat effectivement payé** par le cabinet reprend la main : le cabinet vient d'être débité, son plan doit suivre. À partir de là, l'abonnement est piloté par le paiement — jusqu'à ce qu'un administrateur repose un plan à la main. |
| La fiche dit d'où vient le plan | Elle indique si le plan a été **posé à la main** ou **payé en ligne**, et si le cabinet a un abonnement en cours — de quoi savoir s'il faut le facturer soi-même ou le laisser à son abonnement. |

### Facturer une offre sur devis (Scale)

Scale n'a pas de prix catalogue : il se négocie, s'assigne à la main, puis se **facture** depuis la fiche du cabinet — une **facture ponctuelle** par période convenue, plutôt qu'un abonnement automatique.

| Règle | Comportement |
|---|---|
| Émettre une facture | La modale demande un **montant**, un **libellé**, un **e-mail de facturation** — **obligatoire** : c'est à cette adresse que Stripe envoie la facture — et, si l'on veut, un **délai de paiement** (30 jours par défaut). La facture part aussitôt : le prestataire l'envoie **par e-mail** au cabinet, avec un **lien de paiement hébergé**, et **relance** tout seul jusqu'au règlement. Comme pour la grille, le montant se saisit **hors taxes** : la TVA applicable est ajoutée par le prestataire, et le total figure sur la facture. |
| Refus de saisie | Montant nul ou négatif, montant déraisonnable, libellé vide ou trop long, **e-mail de facturation manquant ou mal formé**, délai hors bornes : la facture n'est pas émise et la feuille le dit. |
| L'historique vit chez le prestataire | La fiche affiche les **dernières factures** du cabinet avec leur état et leur lien — **lues chez le prestataire**, jamais recopiées ici : la numérotation, l'encaissement et les relances lui appartiennent. Un cabinet jamais facturé affiche simplement une liste vide. |
| Ne pas doubler un abonnement | Rien n'interdit d'émettre une facture à un cabinet par ailleurs abonné par carte — mais il serait alors facturé **deux fois** : la fiche indique l'abonnement en cours pour que le cas se voie. |

### Réglages IA d'un cabinet

L'administrateur peut aussi régler l'**IA d'un cabinet** depuis la supervision : son activation et ses quotas, les mêmes leviers que le cabinet trouve dans Paramètres → IA (§16), pilotés cette fois côté plateforme.

## Cycles de vie

#### Évaluation (une ligne de la fiche candidat)

| Statut | Signification | Origine |
|---|---|---|
| Invité | Le lien est parti, le candidat n'a pas ouvert. | Envoi |
| En cours | Le passage a démarré. | Premier accès du candidat |
| Terminé | La copie est rendue (ou le dossier reçu). | Remise |
| Expiré | L'échéance est passée sans remise. | **Déduit** de la date, jamais posé |

#### Campagne

Brouillon → En cours → Clôturée, et **Clôturée → En cours** : la clôture se défait (« Remettre en cours », depuis la fiche ou depuis le menu **⋯** de la liste). Seul le passage par le brouillon est sans retour. Voir §9.

## Suppression & révocation

Tout le système obéit à une phrase : **une épreuve non terminée se révoque toujours, une épreuve terminée ne se détruit jamais — elle se détache.**

| Geste | Invité | En cours | Terminé |
|---|---|---|---|
| Supprimer un test / questionnaire | Révoquée | Révoquée *(éjecté)* | Conservée, détachée |
| Retirer un candidat d'une campagne | Révoquée | Révoquée *(éjecté)* | Conservée, détachée |
| Supprimer une campagne | Révoquée | Révoquée *(éjecté)* | Conservée, détachée |
| Révoquer une évaluation à la main | Révoquée | Révoquée *(éjecté)* | Refusé — 409 |

#### Ce que « révoquer » et « détacher » veulent dire

- **Révoquer** — la ligne d'évaluation disparaît, le lien `/t/` tombe en 404. Un candidat en plein passage est éjecté et ses réponses partielles sont perdues.
- **Détacher** — la copie rendue reste sur la fiche du candidat, elle perd seulement son lien vers le test supprimé. Le rapport est intégralement lisible : nom du test et forme de chaque question sont des instantanés.

#### Effets de bord d'une suppression de test

- Les partages `/s/` de ce test meurent avec lui.
- Les étapes de campagne qui le portaient disparaissent ; la campagne survit avec une épreuve de moins.
- Les copies privées nées d'un test officiel survivent, elles perdent seulement leur filiation.

> **Le rapport est autonome**
> 
> Un rapport ne dépend jamais du catalogue vivant : le nom du test, l'énoncé de chaque question et les options proposées sont figés au moment du passage. C'est ce qui permet de supprimer un test sans réécrire l'histoire des candidats.

[capture d'écran : Confirmation de suppression d'un test]

*La popup annonce la cascade quand le test a déjà été envoyé.*

## Verrous & unicité

| Ce qui est verrouillé | Condition | Réponse |
|---|---|---|
| Supprimer une question | Utilisée par un test ou déjà répondue | 409 |
| Supprimer un client | Un poste y est rattaché | 409 |
| Supprimer un poste | Une campagne l'utilise — **même clôturée** | 409 |
| Révoquer une évaluation | Elle est terminée | 409 |
| Modifier une campagne | Elle est lancée | 409 |
| Écrire sur un contenu officiel | L'auteur est un recruteur | 403 |
| Créer un candidat | L'e-mail existe déjà dans le cabinet | 409 |
| Créer un client | Le nom existe déjà dans le cabinet | 409 |
| Copier un contenu officiel | La copie existe déjà | 409 |
| Envoyer une épreuve vide | Zéro question / zéro champ | 400 |
| Écrire dans un passage | Le temps imparti est écoulé (passage en une seule fois) — la session vient d'être close | 409 |
| Envoyer en une seule fois | Épreuve sans durée : aucune question à chronométrer | 400 |

## Notation

| Règle | Comportement |
|---|---|
| Barème | Porté par la question. Le total du test est la somme de ses questions. |
| Temps accordé | Porté par la question, **en secondes** — le temps que l'on DONNE au candidat. C'est LA durée : celle d'un test en est la somme, et c'est elle qui borne un passage « en une seule fois ». Il se saisit en minutes + secondes (un QCM se tranche en 30 à 45 s) et se propose d'après le type et la difficulté tant qu'on n'y touche pas. |
| Durée estimée | Facultative, portée par la question — le temps qu'il faut **probablement** pour répondre. Vide dans la plupart des cas et purement indicative : elle ne borne rien et ne coupe rien. Elle ne peut jamais dépasser le temps accordé. |
| Test « X · estimé à Y » | Les deux durées d'un test sont déduites : sa durée est la somme des temps accordés, son estimation la somme des durées estimées — une question non estimée comptant pour son temps accordé. Sans aucune estimation, les deux sont égales et l'écran n'affiche que la durée. Les **cartes** de la bibliothèque, elles, n'affichent que la durée en minutes arrondies ; la lecture « X · estimé à Y » se fait sur le détail du test. |
| Tout ou rien | QCM, choix multiples et ordonnancement : la réponse est juste ou fausse. |
| Proportionnelle | Association et texte à trous : les points suivent la part d'éléments corrects. |
| Réponse libre | Notée à la main par le recruteur, entre 0 et le barème. |
| Échelle | Déclarative : jamais comptée dans un score. |
| Test déclaratif | Un test composé uniquement de questions non notées n'a ni score ni niveau. |
| Dossiers | Un questionnaire n'entre dans aucune statistique de score. |

## Codes d'erreur

Chaque refus métier porte un code stable, affiché à l'utilisateur sous forme de message.

| Code | HTTP | Sens |
|---|---|---|
| QUESTION_IN_USE | 409 | Question utilisée par un test ou déjà répondue. |
| CLIENT_IN_USE | 409 | Client encore rattaché à un poste. |
| POSITION_IN_USE | 409 | Poste utilisé par une campagne — la garde compte le **TOTAL**, campagnes **clôturées comprises** (la clé étrangère les retient), et non le compteur « en cours » qu'affichent les écrans. Voir §8. |
| POSITION_ALREADY_CLOSED | 409 | Clôture refusée : le poste est déjà clôturé. |
| POSITION_NOT_CLOSED | 409 | Remise en cours refusée : le poste n'est pas clôturé. |
| CLIENT_NAME_EXISTS | 409 | Nom de client déjà pris dans le cabinet. |
| CANDIDATE_EMAIL_EXISTS | 409 | E-mail déjà porté par une fiche du cabinet. |
| COPY_ALREADY_EXISTS | 409 | Copie privée déjà présente dans la bibliothèque. |
| EVALUATION_ALREADY_COMPLETED | 409 | Révocation refusée : la copie est rendue. |
| CAMPAIGN_ALREADY_LAUNCHED | 409 | Édition refusée : la campagne est lancée. |
| CAMPAIGN_CANDIDATE_EXISTS | 409 | Candidat déjà inscrit à la campagne. |
| SITTING_WRONG_KIND | 409 | Flux de test appelé avec un lien de dossier (ou l'inverse). |
| SITTING_TIME_OVER | 409 | Temps écoulé, session close : l'invitation avait été envoyée *en une seule fois* et l'écriture arrive au-delà du temps imparti (tolérance technique comprise). La session vient d'être terminée avec les réponses déjà validées — plus rien ne s'écrit. |
| CONCURRENT_MODIFICATION | 409 | L'objet a été modifié entre-temps (un collègue, un autre onglet) : recharger la page avant de réenregistrer. |
| OFFICIAL_ITEM_IMMUTABLE | 403 | Écriture d'un recruteur sur un contenu officiel — y compris par la bande : l'**acceptation d'un rendu de tiers** dont la cible serait un test du catalogue est refusée au même titre qu'une modification directe. |
| VISUAL_HTML_FORBIDDEN | 403 | Visuel HTML réservé à l'administrateur. |
| TENANT_MISSING | 403 | Compte sans rattachement à un cabinet. |
| TEST_NOT_SENDABLE | 400 | Test sans question. |
| QUESTIONNAIRE_NOT_SENDABLE | 400 | Questionnaire sans champ. |
| INVALID_EXPIRY_DATE | 400 | Échéance hors bornes (demain … +1 an). |
| INVITATION_NOT_ACTIVE | 400 | Relance sur un lien mort. |
| CAMPAIGN_NOT_LAUNCHABLE | 400 | Lancement sans épreuve ou sans candidat. |
| INVALID_SITTING_SETTINGS | 400 | Déroulement refusé à l'envoi : *passage en une seule fois* demandé sur une épreuve qui ne dure rien (en campagne, la règle vaut pour **chacune** des épreuves de type test), ou tolérance technique hors de ses bornes API — celle-ci n'étant pas exposée dans l'interface, seul le premier cas se rencontre à l'usage. |
| QUESTIONNAIRE_INVALID | 422 | Champ à options avec moins de deux options. |
| POSITION_INVALID | 422 | Valeur hors des listes fermées du poste, ou **surcharge de barème** hors bornes (taux particulier hors de ]0;100], montant particulier négatif ou nul). |
| UNKNOWN_JOB_ROLE | 422 | Métier hors du référentiel fermé — sur un **test** (où il est obligatoire) comme sur un **poste** (où il est facultatif mais tout aussi fermé). |
| JOB_ROLE_DOMAIN_MISMATCH | 422 | Métier incohérent avec le domaine : son domaine ne figure pas parmi ceux du **test**, ou n'est pas celui du **poste** / du **brief de commande**. « Transversal » ne vise aucun domaine : il n'est jamais refusé ici. |
| CLIENT_INVALID | 422 | Secteur d'activité inconnu. |
| CLIENT_INTENT_MISMATCH | 422 | Intention du poste incohérente : `CLIENT` sans client nommé, ou `INTERNAL`/`TBD` avec un client. |
| CLIENT_BILLING_INVALID | 422 | Barème client incohérent : un mode de facturation déclaré sans sa valeur (pourcentage, forfait ou prix unitaire), une valeur hors bornes, ou un **forfait de campagne** nul ou négatif — ce volet-là n'a pas de mode, mais son montant doit être strictement positif. |
| BILLING_LINE_INVALID | 422 | Le code fourre-tout du module facturation, côté **saisie** comme côté **lecture**. Saisie : nature inconnue, destinataire ambigu ou incomplet (les deux formes à la fois, aucune des deux, un nom ou un e-mail manquant ou hors bornes), libellé vide ou trop long, montant hors bornes, date mal formée, campagne non facturable (poste sans client, mode de facturation inconnu, ou aucun prix disponible dans le mode retenu), remise d'une ligne **qui n'est pas annulée**. Lecture : période mal formée ou **inversée** — les deux bornes, elles, sont facultatives. |
| CLIENT_REQUIRED | 422 | Recrutement non interne déclaré sans client. |
| INTERNAL_WITH_CLIENT | 422 | Recrutement interne déclaré avec un client — l'interne n'en nomme aucun. |
| INVALID_SALARY | 422 | Salaire brut annuel absent, nul ou négatif : un entier strictement positif, en euros. |
| INVALID_HIRED_ON | 422 | Date d'embauche mal formée (`AAAA-MM-JJ`) — passée ou future, les deux sont légales. |
| POSITION_CLIENT_MISMATCH | 422 | Le poste du recrutement est rattaché à une autre société que le client de ce recrutement. |
| ALREADY_CANCELLED | 422 | Objet déjà annulé — un **recrutement** comme une **ligne de facturation**. Le premier motif fait foi, rien ne se ré-annule. |
| FORM_REQUIRED_FIELD_MISSING | 422 | Dossier remis avec un champ obligatoire vide, ou une **pièce à joindre obligatoire** non déposée. |
| FILE_TYPE_NOT_ALLOWED | 422 | Pièce jointe de questionnaire refusée : extension hors des familles de formats figées sur la pièce, ou type déclaré incohérent avec l'extension. |
| SHARE_INVALID | 422 | Partage refusé : commentaire manquant, domaine ou métier hors référentiel, rendu déjà remis, geste impossible sur une collaboration close (relancer, prolonger), **test du catalogue OFFICIEL confié en ÉDITION** (il se confie en relecture seulement — refusé dès la création du lien, avant tout effet de bord), ou **correction demandée depuis un lien de simple consultation** (partage de résultat). |
| SHARE_EXPIRED | 410 | Lien de relecture `/s/` ou de rapport `/r/` échu — ou clôturé, ce qui est une échéance anticipée. |
| UPLOAD_TOO_LARGE | 413 | Fichier trop volumineux : 10 Mo max pour un téléversement (CV, image), 4 Mo max pour tout envoi depuis un lien public — sauf le dépôt d'une **pièce jointe de questionnaire**, plafonné par le réglage plateforme `QUESTIONNAIRE_FILE_MAX_MB` (10 Mo par défaut). |
| SETTINGS_INVALID | 422 | Préférences hors bornes (document trop volumineux ou structure inattendue). |
| TOO_MANY_REQUESTS | 429 | Trop de requêtes en peu de temps (liens publics, e-mail de test, formulaire de contact) : réessayer dans un instant. |

Documentation fonctionnelle Evalixo — captures réalisées sur l'environnement de démonstration (cabinet « Demo »). Les règles décrites sont celles appliquées par le serveur : l'interface les reflète, elle ne les invente pas.