Monolithe modulaire Spring Boot 4 / Java 21, découpé par fonctionnalité et non par couche technique. Cette page répond à quatre questions : qui appelle qui, par où, avec quoi, et surtout pour quel périmètre — c’est-à-dire quelles données chaque chemin a le droit de voir.
Tout le reste en découle. Une requête arrive par l’une de ces trois portes, et c’est la porte qui détermine comment la société propriétaire est établie — donc ce que la requête a le droit de lire. La couleur de cette page encode cette distinction, partout.
ROLE_RECRUITER ou ROLE_ADMIN, jeton Keycloak validétenant du jeton, traduite en identifiant puis mise en cache pour la requête.Chaque requête SQL porte tenant_id = :tenantId, écrit à la main dans le service.
ROLE_ADMIN exclusivementLe périmètre est passé en paramètre (countFor(tenantId), overviews(tenantId)). Si le paramètre est faux, la donnée d’un autre client sort.
permitAll — aucune authentificationstarted_at + durée + marge : au-delà, la session est close et l’écriture refusée en 409 SITTING_TIME_OVER. La durée reste vive (dérivée du test), le réglage reste figé ; la marge est une tolérance serveur, non exposée dans l’interface.Le jeton est le seul justificatif. Tout ce qui est lu ensuite doit descendre de lui, jamais d’un identifiant envoyé par le client.
Quatre couches, toujours dans cet ordre, jamais de saut. Chaque module rejoue la même pile pour lui-même — c’est ce qui rend le découpage par fonctionnalité tenable.
Corrélation de requête, chaîne de sécurité, décodage du jeton Keycloak.
Traduit HTTP en appel de service. Aucune règle métier, aucun accès direct à un dépôt.
Le cœur : règles métier, transactions, et le filtre de société. C’est ici qu’on décide ce que l’appelant a le droit de voir.
Règles sans dépendance : barème, difficulté, validité d’une échéance, états d’une campagne. Testables sans Spring, sans base.
JPA. Tout est LAZY, les listes se chargent en quelques IN(...) groupés — jamais une requête par ligne.
Schéma détenu par Flyway (ddl-auto: none). L’application s’y connecte avec un seul compte, propriétaire du schéma.
Un module ne touche jamais les entités ni les dépôts d’un autre : il passe par le service propriétaire. Chaque losange est un appel réel, et sa couleur dit la surface depuis laquelle il part — donc si le périmètre y est établi par une identité, par un paramètre, ou par un jeton public.
| appelant → appelé | Cand. | Test | Quest. | Résult. | Q-aire | Régl. | Camp. | Client | Poste | Dash. | Compte | Annu. | Mails |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| AdminServiceadmin | |||||||||||||
| CampaignServicecampaign | |||||||||||||
| CampaignLaunchServicecampaign | |||||||||||||
| JourneyServicecampaign | |||||||||||||
| CampaignViewAssemblercampaign | |||||||||||||
| InvitationServicecandidate | |||||||||||||
| SurveillanceServicecandidate | |||||||||||||
| DossierServicecandidate | |||||||||||||
| CandidateViewAssemblercandidate | |||||||||||||
| DashboardServicedashboard | |||||||||||||
| TestShareServiceshare | |||||||||||||
| ShareDraftServiceshare | |||||||||||||
| ShareAdoptionServiceshare | |||||||||||||
| ShareViewAssemblershare | |||||||||||||
| SittingServicesitting | |||||||||||||
| TestServicetests | |||||||||||||
| PositionServiceposition | |||||||||||||
| InvitationMailServicecandidate | |||||||||||||
| ShareMailServiceshare |
Trois modules ont vu leur service unique éclater en services à une responsabilité, et la matrice le rend visible : les lignes qui portaient tout portent maintenant chacune leur part. Un module ne gagne pas de façade au passage — le contrôleur injecte les services dont il a besoin, et l’assembleur de vues reste package-private, jamais exposé hors module.
Module campaign — CampaignService tient le CRUD du brouillon
et le cycle DRAFT → RUNNING → CLOSED ;
CampaignLaunchService tient le lancement (génération des évaluations, un
e-mail parcours par candidat) et la vie du vivier d’une campagne ouverte ;
JourneyService tient le parcours public /p/ et le listener de fin de
parcours — le listener vit avec sa logique, jamais dans le service de CRUD. La composition
partagée de la fiche (lectures batch des catalogues, scores bornés aux évaluations de LA
campagne) vit dans CampaignViewAssembler.
Module share — TestShareService tient le cycle de vie du lien
(création, relance, prolongation, révocation, clôture) ; ShareDraftService tient
tout ce que le tiers fait de son lien public (consultation, verdict, éditeur du
chantier, plafonds) — c’est la seule ligne verte du module ;
ShareAdoptionService tient ce que le recruteur décide d’un rendu (revue,
acceptation, demande de modification). ShareViewAssembler décore la ligne, et
ShareMailService ne sert que les deux services recruteur — jamais le service
public.
Module candidate — il n’a plus un service unique mais
cinq services à une responsabilité : CandidateProfileService (profils, CV,
recherche paginée et facettes), InvitationService (cycle de vie des évaluations,
surface campagne), DossierService (dossiers questionnaire),
SurveillanceService (consentement, incidents, captures) et
SittingAccessService (le port du module sitting) — plus
CandidateViewAssembler, la composition batch des fiches, package-private,
jamais exposée hors module. Seuls ceux qui traversent une frontière apparaissent en ligne :
CandidateProfileService et SittingAccessService restent entièrement
dans le module.
Deux enseignements se lisent directement dans la matrice. Les services les plus consommés
sont TestService, ResultService et les services du module
candidate — ils sont appelés depuis les trois surfaces à la fois, ce qui en fait
les points où une erreur de périmètre se propage le plus loin. Et le graphe reste
acyclique : aucun couple de services ne s’appelle mutuellement, ce qui est obtenu en
passant par du SQL natif là où un cycle menaçait
(positions ↔ clients, campaigns ↔ positions).
tenant (un slug, ex. demo).403 TENANT_MISSING.countFor(tenantId), overviews(tenantId), adminSearch(tenantId, …)./t/ le passage d’une épreuve, /p/ le parcours d’une campagne, /s/ le partage d’un test à un tiers.410.Chaque module possède ses tables et personne d’autre ne les lit. Les carrés indiquent les couches présentes : api · application · domain · infra.
Profils, invitations, dossiers, surveillance, CV. Le module le plus chargé — cinq services à une responsabilité, un assembleur interne, et les trois surfaces. DossierService (V9) possède aussi le dépôt des pièces jointes du dossier — DossierFileView, lu par une projection explicite, jamais par une liste.
Banque de questions : 7 types de réponse, visuels d’énoncé, catalogue officiel partagé.
Sessions de passage et réponses. La note n’est jamais stockée : recalculée à chaque lecture.
Partage d’un test à un tiers par lien expirant, commande d’un test à écrire, et partage d’un rapport de candidat (/r/, consultation ou correction déléguée). Des services à une responsabilité — cycle du lien, chantier du tiers, décision du recruteur, accès public d’un rapport — plus un assembleur interne. Le rapport lui-même est lu par un port de result/application : le module n’en touche jamais l’infra ni l’api.
Brouillon → en cours → clôturée. Trois services à une responsabilité — CRUD et cycle, lancement, parcours public (JourneyController vit ici) — plus un assembleur interne.
Ensembles ordonnés de questions — du pur contenu depuis V6 : plus aucun réglage de déroulement sur tests. Agrégats recalculés à chaque écriture, jamais saisis, dont la durée dérivée qui sert de base à la borne d’un passage.
Le dossier déclaratif : ni note, ni chrono, ni catalogue officiel. Toujours privé. Les pièces à joindre (V9) sont déclarées ici — hors sections — et leur référentiel famille → extensions → content-types vit en un seul endroit, domain/AttachmentFormats.
La société cliente du cabinet. Fiche légère, réutilisable entre postes.
Le poste à pourvoir, réutilisable entre campagnes. Rattachement au client facultatif.
Compte par utilisateur ; marque blanche et gabarits d’e-mail par société.
Supervision de la plateforme. Ne possède aucune table : il agrège les autres modules.
« Contactez-nous » : écriture seule côté recruteur, lecture côté admin.
Agrégation de la page d’accueil. Aucune table, aucune entité : il compose.
Le passage du candidat. Petit, mais c’est la seule surface joignable sans authentification — et c’est lui qui fait respecter la borne de durée.
Le socle : identité de l’appelant, sociétés et comptes, modèle d’erreur RFC 9457, e-mails, événements — et shared/sitting, le type unique du déroulement, monté par candidate et campaign, lu par sitting : trois modules le partagent, il ne pouvait vivre dans aucun.
La chaîne de sécurité, le CORS, l’exécuteur asynchrone des e-mails et le format de logs.
Elles ne sont pas décoratives : chacune explique une forme qu’on retrouve partout dans le code.
jsonb, le vivant est une table
Une réponse fige la question telle qu’elle était : réviser la banque ne réécrit jamais un rapport passé.
IN(...) groupés. Jamais une requête par ligne — la règle est explicite et tenue.
ddl-auto: none partout. Hibernate ne crée ni ne modifie jamais une table : 9 migrations versionnées font foi (V1 schéma, V2 démo, puis V3 à V9 incrémentales).
test_name ou difficulty : le serveur ne les relit jamais sur le test. Une invitation partie est donc immuable, et deux envois du même test peuvent se dérouler différemment.
Les listes de candidats ne descendent plus entières : le serveur pagine, filtre et trie, et renvoie toujours la même enveloppe. Le contexte de score n’est calculé que pour les candidats de la page servie — un nombre fixe de requêtes batch, quelle que soit la taille du cabinet.
{ items, page, pageSize, totalCount } — totalCount est le total filtré, stable d’une page à l’autre.
page (défaut 0) et size (défaut 25, max 100), clampés en silence — jamais un 4xx pour une borne ; q trimé, insensible à la casse, jokers LIKE échappés ; sort = recent (défaut) ou alpha.
recent et alpha subsistent.
q + size=20 — aucun endpoint séparé.
| Endpoint | Contrat |
|---|---|
| GET /api/candidates | Paginé ; filtres portés par les évaluations du candidat (status — dont expired dérivé de l’échéance —, testId ou test, domain, source) ; q cherche sur prénom+nom et e-mail. |
| GET /api/candidates/facets | Les options de filtre du cabinet — { tests: [{id, name}…], domains: […] }, deux GROUP BY sur les évaluations. |
| GET /api/admin/candidates | Paginé pareil (page/size/sort) ; tenantId et q optionnels — q exige 2 caractères utiles, sinon il est ignoré. |
| GET /api/results | Supprimé. Il n’y a plus de liste de résultats : seuls restent GET /api/results/{id} et le PATCH de correction. |
| POST /api/results/{id}/shares | 201. Partage du rapport à un tiers — corps { clientId?, email, mode: VIEW|REVIEW, expiresAt, includeSurveillance?, message? }. Le rapport se partage entier ; seule la surveillance se retire (includeSurveillance, objet et non primitif, défaut vrai). Le rapport d’un autre cabinet est un 404. |
| GET /api/result-shares | La liste du cabinet — sa propre ressource, jamais une section greffée sur GET /api/shares : deux collections, deux contrats, deux onglets. Puis PUT …/{id}/expiry, POST …/{id}/close, POST …/{id}/remind (204), DELETE …/{id} (204). |
| GET /api/public/result-shares/{token} | Le rapport complet servi au tiers : réponses, instantanés entiers (corrigé, barème, consignes), identité du candidat et journal de surveillance — d’un seul aller-retour, pour que la page du tiers se dessine à l’identique de celle du recruteur ; la section surveillance est absente quand le partage l’exclut (sanitisation à la source). Les octets (captures, visuels d’énoncé) se tirent à part, bornés au token. 404 uniforme sur un token inconnu, 410 SHARE_EXPIRED passé l’échéance ou après clôture. Le tenant vient de la ligne du token, jamais d’un JWT. |
| PATCH /api/public/result-shares/{token}/answers/{questionId}/review | La correction déléguée — réservée au mode REVIEW, sinon 422 SHARE_INVALID (le token est valide, c’est le lien qui ne permet pas le geste). Mêmes règles que la correction du recruteur : FREE notée seulement, 0…barème de l’instantané, score re-dérivé. |
| PUT /api/public/result-shares/{token}/verdict | La décision du tiers sur le candidat — même corps et mêmes valeurs que le PUT recruteur (keep|review|reject|null). Réservée au mode REVIEW (422 SHARE_INVALID sinon) ; elle vit sur l’évaluation, via un port à périmètre explicite du module candidate — le tenant vient de la ligne du token, jamais d’un JWT. |
| GET/PUT /api/settings/result-share-email | Le gabarit tenant du partage de rapport — miroir de share-email, variables {{candidateName}}, {{testName}}, {{companyName}}, {{link}}, {{expiresAt}}. |
sitting
Le déroulement d’un passage — les dix interrupteurs de surveillance et le
passage en une seule fois — n’est plus une propriété du test mais un choix
fait à l’envoi, transporté par un bloc facultatif du corps, puis figé sur
l’évaluation. TestRequest/TestDto n’ont plus ni bloc
security ni timeLimitEnabled : le builder est du pur contenu.
| Endpoint | Contrat |
|---|---|
| POST /api/candidates/{id}/evaluations | Corps { testId | questionnaireId, expiresAt, cc?, sitting? }. Le bloc sitting est facultatif et vaut pour cette invitation. |
| POST /api/campaigns/{id}/launch | Corps facultatif { sitting? } — le même bloc. Un seul réglage pour toutes les épreuves de type test du parcours, validé contre la durée de chacune, figé sur la campagne puis recopié sur chaque évaluation de test générée. |
| GET /api/campaigns/{id} | Detail.sitting relit le réglage figé — neutre tant que la campagne est un brouillon. Un enrôlement tardif sur une campagne RUNNING réutilise ce réglage sans le redemander ni le rejuger. |
| GET /api/public/evaluations/{token} | Les mesures annoncées, le consentement et la borne de durée se lisent sur l’évaluation, jamais sur le catalogue. Idem pour monitored du parcours /p/. |
{ singleSitting?, marginMinutes?, security?: { fullscreenRequired, focusLossDetection, copyPasteBlocked, secondScreenDetection, cameraRequired, microphoneRequired, webcamCaptures, screenCaptures, shuffleQuestions, shuffleOptions } } — toutes les clés facultatives, et des objets, jamais des primitifs : une clé absente vaut « désactivé » au lieu d’un 400 Jackson.
marginMinutes absent avec singleSitting: true ⇒ 10 — le front ne l’envoie jamais, la tolérance reste serveur.
shared/
SittingSettings est un @Embeddable monté sur evaluations et campaigns, lu par le module sitting. Trois modules le touchent : un infra de module l’aurait rendu illégal partout ailleurs (ArchUnit).
Le recruteur déclare les pièces attendues sur le questionnaire — libellé,
required, familles de formats — dans des tables filles ordonnées
(questionnaire_attachments, questionnaire_attachment_formats),
jamais du jsonb vivant. Le gel à l’envoi les copie dans le gabarit du
dossier ; le dépôt du candidat (dossier_files) référence l’attachmentId
figé du gabarit — jamais une FK vers questionnaire_attachments — de sorte
qu’un questionnaire remanié ou supprimé après l’envoi ne change rien à un dossier déjà parti.
| Endpoint | Contrat |
|---|---|
| PUT /api/public/evaluations/{token}/dossier/files/{attachmentId} | Multipart, champ file. Réponse 200 { attachmentId, filename, contentType, sizeBytes, uploadedAt }. Refus 404 (pièce hors du gabarit figé), 422 FILE_TYPE_NOT_ALLOWED, 413 UPLOAD_TOO_LARGE, 409 si le dossier est déjà rendu. |
| DELETE /api/public/evaluations/{token}/dossier/files/{attachmentId} | Retire le dépôt. 204, idempotent — retirer une pièce jamais déposée ne casse rien. |
| GET /api/candidates/{id}/evaluations/{eid}/dossier/files/{attachmentId} | Téléchargement du binaire, authentifié, tenant-scopé, 404 uniforme, Content-Disposition: attachment. |
questionnaire/domain/AttachmentFormats. L’extension (minusculée, chemin retiré) tranche ; le content-type déclaré ne fait que confirmer — un type absent ou générique (application/octet-stream) ne déclare rien, l’extension décide seule.
app.questionnaire.file-max-mb (env QUESTIONNAIRE_FILE_MAX_MB, défaut 10, plafonné par spring.servlet.multipart) — pas une colonne par pièce, pas un choix du recruteur. Il est relu à chaque dépôt, jamais figé dans un dossier.
PublicRequestSizeFilter refuse par défaut tout corps /api/public/** au-delà de 4 Mo — sauf ce seul chemin, ce seul verbe (PUT .../dossier/files/{attachmentId}), où le plafond devient file-max-mb + 1 Mo d’enveloppe multipart. server.tomcat.max-swallow-size passe de 4 à 12 Mo pour que le refus 413 soit lisible au lieu de couper la connexion — ce réglage n’accepte rien de plus, il avale un corps déjà refusé.
FORM_REQUIRED_FIELD_MISSING — le même code que pour un champ texte obligatoire vide. Le rate limiting par jeton (4e segment de l’URL) couvre déjà l’endpoint, sans réglage propre.
Toute erreur sort au même format : Problem Details (RFC 9457) avec un code
stable et le requestId de corrélation — l’en-tête X-Request-Id
entrant est normalisé (64 caractères max, alphabet restreint, sinon remplacé). Aux codes
métier propres à chaque module s’ajoutent quatre refus transverses, indépendants de l’écran
— et les deux refus du déroulement, qui se répondent d’un bout à l’autre : l’un
garde le réglage à l’envoi, l’autre l’applique côté passage public.
| HTTP | Code | Déclencheur |
|---|---|---|
| 413 | UPLOAD_TOO_LARGE | Téléversement multipart au-delà de 10 Mo, ou tout corps /api/public/** au-delà de 4 Mo — refusé sur le Content-Length déclaré, avant toute matérialisation. Seule exception à ce dernier plafond : le dépôt d’une pièce jointe de dossier (voir § Pièces à joindre), borné par le réglage de plateforme à la place. |
| 409 | CONCURRENT_MODIFICATION | Verrou optimiste : deux écritures concurrentes sur une question, un test, un candidat, une évaluation ou un résultat. Traduit proprement — jamais un 500. |
| 429 | TOO_MANY_REQUESTS | Rate limiting : /api/public/** à 120/min avec un burst immédiat de 40, par jeton de lien ; e-mail de test et formulaire de support à 5/min par utilisateur. |
| 422 | SETTINGS_INVALID | Documents de préférences jsonb bornés : 32 clés racine max, valeurs simples (un niveau d’objet toléré), 16 Ko sérialisés — le document fusionné est jugé, un patch ne contourne pas la borne. |
| 409 | SITTING_TIME_OVER | Borne de durée dépassée sur une écriture de passage (réponse, remise, journal de surveillance, reprise) — l’évaluation portait le réglage passage en une seule fois. La session est d’abord close d’office avec les réponses déjà données — en transaction propre, sinon le rollback du refus emporterait la clôture — puis l’écriture est refusée. |
| 400 | INVALID_SITTING_SETTINGS | Réglage de déroulement refusé à l’envoi : marge hors de [0, 240] minutes (le miroir du CHECK de la base — borne API seulement, l’interface n’expose pas ce champ), ou passage en une seule fois demandé sur une épreuve qui ne dure rien — validé contre la durée de chacune des épreuves de type test au lancement d’une campagne. Même famille que TEST_NOT_SENDABLE : le front attend un 400 sur un refus d’envoi. TEST_INVALID a disparu avec la règle qu’il gardait. |
Un e-mail n’est jamais sur le chemin critique d’une requête HTTP — et il ne part jamais pour une transaction annulée.
skilltest.mail.sent / skilltest.mail.failures exposés par l’actuator.
logging (dev — journalise sans envoyer), smtp, brevo. Hors dev, l’application refuse de démarrer sans fournisseur explicite : le mode logging journaliserait les liens de passage des candidats.
V1__schema.sql (le modèle complet) et V2__demo.sql (le contenu de démonstration) sont figées — elles ne se rééditent jamais. Une base restée sur l’ancienne lignée doit être réinitialisée ; une base déjà sur V1/V2 — la production — ne l’est jamais.
V3 ajoute le verrou optimiste (évaluations, résultats) et le rattachement des images téléversées aux chantiers de partage, V4 installe l’extension unaccent de la recherche, V5 les deux colonnes du passage en une seule fois (activé ou non, marge CHECK [0, 240] — tolérance serveur, non exposée dans l’interface), V6 les déplace vers l’envoi, V7 ajoute result_shares (le partage d’un rapport à un tiers) et la colonne de gabarit tenant_settings.result_share_email, V8 ajoute share_messages (le fil de conversation d’une collaboration), V9 ajoute les pièces à joindre d’un dossier de questionnaire.
V9 : les pièces à joindre
questionnaire_attachments (libellé, required, position) + table enfant questionnaire_attachment_formats (familles dans un CHECK, lignes ordonnées) côté questionnaire, et dossier_files (le dépôt du candidat, UNIQUE (dossier_id, attachment_id) — un fichier par pièce, redéposer écrase — bytes en BYTEA, cascade totale sur questionnaire_dossiers) côté dossier. Aucune colonne de taille : le plafond est un réglage de plateforme, jamais figé par pièce.
V7 : partager un rapport
result_shares — jumelle de test_shares, en plus court : la cible est un result_id (ON DELETE CASCADE — un partage sans rapport n’a aucun sens), le mode vaut VIEW ou REVIEW, et il n’existe aucun équivalent d’allow_answers : un rapport se partage entier. Seule exception, include_surveillance (défaut TRUE) : les signaux anti-triche parlent du comportement du candidat, pas de sa copie — le recruteur peut les retirer, et la section ne quitte alors jamais le serveur. La colonne origin (CHECK ('MANUAL')) garde la place du futur avis automatique aux tiers en copie, sans le coder.
V6 : le déroulement quitte le test
Les dix colonnes sec_* et les deux colonnes de borne sont ajoutées sur evaluations et sur campaigns (défauts neutres NOT NULL, même CHECK [0, 240]), backfillées depuis le test de chaque évaluation — et depuis la première épreuve de type test des campagnes déjà lancées — puis DROPées de tests. Rien ne change pour une épreuve déjà envoyée : le backfill lui rend ce que son test portait.
skill-test-infra/northflank/*.env.example. L’application est fail-fast : une variable manquante refuse le démarrage, jamais un défaut silencieux.
Les règles d’architecture ne sont pas un document : elles cassent le build.
api/ ou à l’infra/ d’un autre module, faire dépendre un contrôleur d’un contrôleur, ou publier un contrôleur admin sans @PreAuthorize : le build échoue.
×Aucune politique de sécurité au niveau des lignes en base. PostgreSQL sert tout ce qu’on lui demande ; c’est le tenant_id = :tenantId des services qui borne, et lui seul.
×Un seul compte de connexion, propriétaire du schéma. Qui l’obtient lit toute la base, tous clients confondus.
×Une centaine d’endroits où le filtre doit être pensé. Rien ne signale un oubli : ni le compilateur, ni un test, ni la base.
×Les tables filles ne sont pas filtrables — réponses, options, champs de questionnaire n’ont pas de colonne de société. Elles ne sont protégées que par la convention « on part toujours du parent ».
Ce n’est pas une fuite connue : les 29 tests d’étanchéité passent, le filtrage actuel est correct. C’est un risque de prochain oubli. Le travail qui y répond — politique en base, second rôle SQL contraint — existe sur une branche dédiée, ni poussée ni fusionnée.