Intra-RH — CTC Restauration

Modules livrés

22 modules livrés, déployés et servis à ce jour — l'écran des primes ponctuelles du contrat T-50 est le dix-huitième, ajouté au menu le 20/09/2026, le budget & la campagne N+1 du contrat T-46 est le dix-neuvième, ajouté le même jour, et l'espace prestataire F29 du contrat T-48 est le vingtième, ajouté le même jour également. La file des incohérences de paramètres (contrat T-51) est le vingt-et-unième : c'est la file de traitement RH des incohérences de paramétrage C4-4/C7-4, un magasin distinct du journal d'anomalies D-064. L'annuaire du vivier et les évaluations internes (contrat T-49) est le vingt-deuxième : c'est la recherche des anciens comme des présents (fiches archivées incluses, D-149) et la notation d'une mission de prestataire ou de CDD.

Socle technique déployé par le contrat T-13 — Infrastructure & exploitation : PostgreSQL 16, API FastAPI et frontend servi par nginx, en conteneurs Docker. Chaque module partage l'en-tête commun (charte D-193) avec la cloche de notifications F25 (D-196/Q177).

Fiche RH — fiche collaborateur (F14, segmentation 4 blocs D-153), référentiels (F17), file des anomalies (F23) et alertes profils incomplets (D-114) — contrat T-01, unité 2. Fonctionne actuellement en mode MOCK (données de démonstration) en attendant le backend des endpoints (voir API.md).

Admin RBAC — administration des droits par tenant (D-153/Q135) : rôles & capacités (98 capacités, matrice vivante D-017), attributions collaborateur par collaborateur (D-131) et multi-rôles (D-152), désactivation des comptes (D-144/WF-22), permissions réservées (D-040) — contrat T-02, unité 2. Fonctionne en mode MOCK (jeu généré depuis le seed du moteur backend/authz/) en attendant le backend des endpoints (voir API.md).

Planning — mon planning (réel = théorique + delta D-018), demande d'ajustement (motif typé D-031, fenêtre 48 h D-043), décisions du valideur (routage dynamique D-053) et administration des plannings types (D-046) — contrat T-07.1. Le backend /api/planning est livré : le module fonctionne en mode MOCK par défaut, bascule mode API disponible (voir API.md).

Journal — consultation consolidée F22 des 4 volets F9 (D-071) : liste unique chronologique, filtres, diff avant/après — réservée DSI + Direction (403 typé sinon) — contrat T-15. Le backend /api/auditlog est livré : le module fonctionne en mode MOCK par défaut, bascule mode API disponible (voir API.md).

Centre de notifications — badge numérique d'actions en attente (F25) dérivé du RBAC vivant (D-017/D-134 — action-vs-visibilité D-076) et panneau d'actions groupées par service, avec liens vers les écrans de traitement existants — contrat T-17.1. Le backend /api/notifications est livré (GET uniquement) : le module fonctionne en mode API par défaut ; un mode MOCK de démonstration reste disponible (voir API.md).

Super-admin — console plateforme : liste des tenants (identité marque-blanche D-012), provisionnement outillé d'un tenant (D-120 point 1, compte admin initial à mot de passe jetable D-042) et tableau de bord santé par tenant (D-120 point 2) — contrat T-19.1. Le backend /api/admin est livré : le module fonctionne en mode MOCK par défaut, bascule mode API disponible (voir API.md).

Alertes légales — file des alertes légales routées (WF-12 / D-041 annoté) : contingent annuel HS 130 h (CCN 1266), repos compensateur, JNT forfait-jours 218 j (accord D-085) et échéances datées D-080 — contrat T-21 (extraction transverse D-159). Moteur de calcul livré (backend/legal/) ; le frontend fonctionne en mode MOCK en attendant le branchement des endpoints (voir API.md).

Avancement de la paie — tableau de suivi d'avancement de la paie PAR ÉTABLISSEMENT (F24 — D-075, statuts D-074, mise à jour EN CONTINU à chaque téléversement) et anomalies du contrôle d'exhaustivité croisé contrat ↔ planning ↔ bulletin (F23 — D-072, 5 types, traitement SERVICE RH / RRH — jamais la Direction en notification directe, D-076) — contrat T-16. Le backend /api/ingestion/exhaustivite est livré : le module fonctionne en mode MOCK par défaut, bascule mode API disponible (voir API.md).

Résiduels de migration — écran dédié au traitement des bulletins bloqués des lots de migration (Q208) : motifs de blocage lisibles, éligibilité à la remédiation (D-306 — absences de champs de classification uniquement) et décision DSI « ajouter à la grille des salaires » OU « intégrer uniquement au budget » (D-307), table append-only — la dernière décision fait foi. Écran réservé au rôle DSI (garde homologue de la clôture de migration, D-158). Le backend /api/ingestion/migration/residuels est livré : le module fonctionne en mode MOCK par défaut, bascule mode API disponible (voir API.md).

Upload de bulletins PDF — interface autonome de dépôt des bulletins PDF (T-22, créée D-196/Q175 : refusée comme sous-écran du tableau d'avancement) : un lot = un seul appel HTTP pour un ou plusieurs PDF, fenêtre factuelle de 45 jours (D-189 — capacité ingestion:lancer, rôle DSI au-delà) relayée telle qu'elle vient du backend, résultat par bulletin (traité / anomalie bloquante unitaire — D-056) et lien direct vers l'écran de traitement d'anomalie du module Avancement de la paie (T-16). Le backend /api/ingestion/lots/bulletins-pdf est livré et déployé : le module fonctionne en mode MOCK par défaut (rapports de lot simulés — D-144), bascule mode API disponible (voir API.md).

Espace collaborateur — self-service du collaborateur (F6/F7/F16) : home personnelle PRIVÉE (D-155 — aucune visibilité entre pairs, Q142) avec jours travaillés + lieu des semaines courante/suivante, complétude du profil (D-089), soldes CP/récupération (grand livre T-06 — D-023), résumé du centre de notifications F25, prochaines absences et actions rapides ; self-édition partielle de sa fiche (champs Q28/D-068 — les champs RH-only restent en lecture seule) et demandes d'absence (codes réels D-022, congés payés et récupération avec contrôle de solde AVANT le circuit de validation — D-135). Mobile-first et PWA (D-136) — contrat T-14a. Le backend /api/selfservice est livré : le module fonctionne en mode API par défaut, bascule mode MOCK disponible (voir API.md).

Espace documentaire RH — vérification documentaire du service RH (contrat T-47) : file de vérification des pièces justificatives sur le moteur générique D-090/D-096 (types, file par statut en attente / conforme / non conforme, consultation du contenu chiffré réservée au RH et à la RRH, décision conforme / non conforme avec motif obligatoire au refus, purge des pièces échues, modifications de fiche bloquées) et tableau de suivi des onboardings F27 (D-091 : statut par pièce et par collaborateur, tri par urgence sur la date de début de contrat, dossier en drill-down, état vérifié du blocage WF-19). Le volet « ENVOI » de WF-19 (email de bienvenue + identifiants) est hors périmètre : canal email non activé en production (Q203/D-346) — l'écran constate, il n'envoie rien. Les backends /api/pieces (T-14b) et /api/onboarding (T-14c) sont livrés : le module fonctionne en mode API par défaut, bascule mode MOCK disponible (voir API.md).

Échéances RH — file des échéances du moteur générique D-080 (type configurable + règle de récurrence + délai d'alerte + responsable/valideur + statut recalculé à la date de lecture : à venir / dans le délai d'alerte / en retard / traitée), ses jalons (règle générale D-134 #7 « jamais de silence » : ouverture de fenêtre, approche, passage en retard, puis relances J+7 / J+14 / hebdomadaires jusqu'à 180 jours — la preuve de notification) et le tableau des infractions F28 (D-107, amendé D-331) avec son diagnostic obligatoire — carence du processus d'escalade vs comportement d'un individu —, jamais un cinquième système de statuts (D-074). La synchronisation de la file est idempotente et à la demande : le déclencheur périodique est porté par T-43 et reste une question ouverte (écart E-3, D-449, Q270) — l'écran le dit plutôt que de laisser croire à un cron. Écran autonome (arbitrage E-5/D-449 : ce n'est pas un bloc du dashboard budget T-46) — contrat T-52. Le backend /api/echeances est livré et déployé (T-12.2) : le module fonctionne en mode API par défaut, bascule mode MOCK disponible (voir API.md).

Contrats et avenants — écran F15 (contrat T-45), maquetté au § B.5 de wireframes.md et jamais créé jusqu'ici : bibliothèque des modèles (les 8 modèles de contrat CTC de D-087 + les 3 avenants du périmètre strict D-113, avec leur cycle de vie — dépôt par le Service RH puis validation de la DIRECTION avant toute mise en production, D-156/Q130, version datée et empreinte) ; génération depuis la fiche (pré-remplissage des champs de fusion du « Fichier contrat » D-087 par le backend, blocage WF-19 tant que le dossier de pièces D-089 n'est pas complet et vérifié, autorité SIRET D-041/D-060) ; circuit de validation D-112/WF-21 (rédigé par le Service RH → validé par le CHEF DE SECTEUR, ou la RRH pour un siège sans secteur Q132 → signature → archivage 5 ans D-049) — la Direction est HORS circuit des contrats ; 3 avenants automatiques (« tout autre avenant reste MANUEL ») et un volet DPAE (génération sans jamais recopier le NIR, export sous capacité fiche:nir:voir, transmission par le SEUL canal branché — export manuel — et refus du canal automatisé, D-114). ⚠ La signature Zoho Sign est RÉELLEMENT ACTIVE en production sur ce contrat (D-346) : l'écran n'émet aucun envoi automatique et n'expose le geste irréversible que derrière deux confirmations nommées. Le backend /api/contracts (T-09) est livré et déployé : le module fonctionne en mode API par défaut, bascule mode MOCK disponible (voir API.md).

Primes ponctuelles — écran F18 (workflow D-016) qui n'avait JAMAIS existé : Q173/D-196 avait assigné « validation primes → T-14 », T-14b a livré le backend sans code de production ajouté (D-326 : déjà construit par T-03/T-24) et T-14c a clos « aucun changement frontend » (D-327) — aucune route /engine/primes* n'était appelée par un écran. Demande motivée (motif obligatoire, Q44) pour un collaborateur, puis double validation : la Direction des Opérations prévalide (étape non terminale) avant la validation terminale du Service RH (Q43) — une saisie directe du Service RH est, elle, validée d'office. La chaîne s'appuie sur le moteur d'autorisation (D-040) : l'écran affiche l'étape et le valideur servis et rend les refus du moteur tels quels — aucun rôle codé en dur. Le motif n'est servi qu'aux porteurs de prime:motif:voir (jamais le collaborateur concerné, jamais le manager de site), et l'écran le dit quand il ne l'est pas. Une prime validée entre dans la couche 3 du calcul de paie de sa période (F5) — l'écran ne déclenche aucun calcul. Contrat T-50. Le backend /api/engine est livré : le module fonctionne en mode API par défaut, bascule mode MOCK disponible (voir API.md).

Tâches de fin de mois — clôture mensuelle en deux temps (D-044, statuts budget fusionnés D-074) en 5 écrans : checklist par établissement + relances (projection en cours de mois étiquetée ESTIMATION), clôture paie du secteur (WF-05 — délai butoir suivi, jamais bloquant), prestations annexes (WF-06 — déclaration par lot J+30, validation comptable D-045, clôture « incomplet documenté » Q73), rapprochement projeté vs réalisé (WF-15, fenêtre M+1, justification obligatoire, validation RRH SEUL D-070) et exports CSV + journal des anomalies (D-019/Q56, archivage 3 mois Q80, journal D-064 dont le garde-fou pluriemploi Q168/D-194) — contrat T-08. Le backend /api/close est livré : le module fonctionne en mode MOCK par défaut, bascule mode API disponible (voir API.md).

Dashboard manager — page d'accueil des managers (F26, D-078), filtrée AUTOMATIQUEMENT sur le périmètre RBAC du rôle connecté (D-017 ; capacité dashboard:manager:consulter — un collaborateur terrain reçoit un refus 403) : six blocs, chacun issu d'une source unique — synthèse budgétaire EN % sans aucun montant (D-079), actions en attente (même mécanisme que le centre de notifications F25 — pas de seconde source), échéances à venir (file D-080/T-12.2), informations sans action (fin CDD / sortie prévue CDI — F14/D-102), anniversaires (naissance JOUR+MOIS sans année D-092, opt-out individuel D-081 et toggle tenant T-23) et congés/affectations à venir avec mention « remplacement géré / non géré » (fact_affectation D-026 — aucun champ nouveau) ; blocs cliquables avec drill-down (Q146/D-155), courbe budgétaire à deux vues (12 mois glissants / année civile par défaut) — contrat T-18. Module branché en mode API (aucun jeu de démonstration). Le thème du tenant est appliqué par /assets/theme.js (T-23/D-213).

Paramètres du tenant — socle UNIQUE de paramètres déclarés et datés (contrat T-23, D-213) : lignes de portée tenant du registre (/api/parametres), façade marque-blanche (nom, logo, mentions légales obligatoires non vides, organigramme, palette — données restant dans leurs colonnes typées, migration 001, aucune duplication dans le registre clé/valeur) et thème runtime appliqué au chargement des surfaces (/assets/theme.js, D-213 point 4d). L'écriture de certains paramètres est réservée par rôle (mode double validation des absences D-148 — RRH/DIRECTION), la règle étant tranchée par le backend sur le paramètre, le frontend ne faisant que restituer le refus — module branché en mode API. Les lignes de portée system (feature flags) sont éditées par la console super-admin : MÊME registre, jamais un second mécanisme.

Budget & campagne N+1 — module maquetté au § B.11/B.12 de wireframes.md et jamais créé jusqu'ici (Q233) : campagne enveloppes N+1 (calendrier des jours fériés et vacances par zone — préalable bloquant de l'export, D-123 ; référentiel daté des zones scolaires où le rattachement automatique par code postal n'est jamais qu'une proposition, Q115 ; simulation N+1 ré-exécutable, Q118 ; enveloppes par site saisies par le Service RH puis validées par la Direction, D-111 ; export XLSX produit par le backend ; référentiel daté des charges patronales du tenant — migration 035, seule source opposable, le moteur CCN n'est pas attendu : arbitrage D-449 § 3.1) et dashboard budget F10/F11 : statuts par composante du modèle D-074 restitués par le moteur de clôture, courbe mois par mois avec N-1 superposée, vue budget historique distincte (D-161), projection toujours étiquetée ESTIMATION, top des écarts par établissement (D-342) avec pastilles RAG dont les bornes sont un paramètre du tenant (registre T-23, seuils_rag_dashboard), statut du remplacement F13 en lecture seule (le workflow est T-43) et compteurs d'échéances D-080/F28 (le rendu de la file et le tableau F28 restent l'écran autonome T-52 — arbitrage E-5/D-449). Règle d'affichage de tous les montants : D-079 — la granularité (MONTANT ou POURCENTAGE) est celle que le BACKEND publie, aucun montant n'est jamais composé ni calculé par l'écran. Contrat T-46 ; les backends consommés (/api/budget, /api/close, /api/planning, /api/echeances, /api/prestataires, /api/parametres) sont livrés et déployés — le module fonctionne en mode API par défaut, bascule mode MOCK disponible (voir API.md).

Espace prestataire F29 — la conformité documentaire d'une entreprise prestataire (population externe : ce n'est pas un espace salarié), contrat T-48 (Q233) : les 4 documents exigés par D-108 — extrait Kbis ou avis de situation SIRENE, attestation de vigilance URSSAF, attestation de RC Pro, contrat de prestation ou devis signé — sur le moteur de pièces générique D-090 (dépôt, contrôle antivirus fail-closed, contenu chiffré, vérification conforme / non conforme avec motif obligatoire au refus : aucune duplication du moteur, et les libellés de statut restent ceux du composant partagé posé par T-47) ; la situation URSSAF : cumul annuel civil des factures prestataire, seuil de 5 000 € lu par le backend dans le référentiel daté (regle_ccn — D-122 : jamais codé en dur, jamais recalculé par l'écran) et case de dérogation manuelle décochable réservée à la COMPTABILITÉ et à la DIRECTION (piece:prestataire:deroger, D-128 — les deux mécanismes coexistent) ; la saisie manuelle des factures (le projet n'a aucune intégration comptable) et l'échéance de renouvellement du moteur D-080 avec sa synchronisation de file idempotente. Le module est l'espace de RECUEIL tenu par le service RH : l'accès direct du prestataire à son propre dossier n'existe pas dans le dépôt et n'a pas été inventé (point tracé). Backends déjà livrés (/api/pieces, /api/prestataires, /api/annuaire) — mode API par défaut, bascule mode MOCK disponible (voir API.md).

Incohérences de paramètres — la file de traitement RH des incohérences de paramétrage de site (C4-4/C7-4, D-011 annoté Q74), contrat T-51 (Q236 (d)) : les deux natures d'une ligne — CONFLIT (le paramètre du site est moins favorable que la branche : la CCN s'applique) et ÉCART (le paramètre du site est plus favorable : il doit être validé explicitement) — puis le cycle NOUVELLE → EN_COURS → CORRIGEE avec une décision explicite (ALIGNER_SUR_CCN : le paramètre de site est corrigé sur la branche, ou APPLIQUER_SITE : la valeur du site s'applique, possible seulement sur un écart — D-011). La capacité exigée (referentiel:prime:modifier) est vérifiée par le moteur d'autorisation (D-040) : l'écran affiche le refus servi tel quel et n'anticipe aucun refus du moteur (transition hors cycle, décision manquante, écart refusé sur un conflit). ⚠ Magasin DISTINCT du journal d'anomalies D-064 (/api/close/anomalies, table anomalie) : autre population (anomalies individuelles de paie/présence, jamais un paramètre ni une personne ici) et autre traitement (validée / rejetée) — les deux files ne sont pas fusionnées et la frontière est dite à l'écran. Les lignes naissent de la détection au calcul (POST /api/engine/calculs) : cet écran traite, il ne détecte pas et ne relance aucun calcul. Backend /api/engine déjà livré (moteur T-03/T-24) — mode API par défaut, bascule mode MOCK disponible (voir API.md).

Annuaire du vivier et évaluations — deux écrans, un seul module, contrat T-49 (Q233) : l'annuaire du vivier réunit les collaborateurs et les entreprises prestataires ayant travaillé avec l'entreprise, fiches archivées et inactives INCLUSES (c'est l'exigence même de D-149 : l'annuaire qui exclurait les sortis n'aurait aucun intérêt) avec les filtres que le contrat accepte — texte, cible, période, nature, poste, site, entreprise prestataire, limite — et l'évaluation interne : notation d'une MISSION de prestataire individuel (D-147) ou de collaborateur en CDD, note 1 à 5 et commentaire libre porté par le composant transverse D-150, avec la charte de gouvernance dans l'encart de saisie. Les capacités sont réutilisées telles quelles (aucune créée) : fiche:consulter pour une fiche collaborateur, piece:prestataire:gerer pour une fiche entreprise prestataire, evaluation:noter et evaluation:consulter pour la notation et l'historique, aide:contenu:gerer pour une nouvelle version de la charte — chaque cible est servie sous sa propre capacité, sans élargissement croisé. Règle de fond (D-095) : l'historique des évaluations n'est jamais servi à la personne évaluée, par double verrou côté backend (capacité et exclusion de soi) et sans exception de sommet — l'écran affiche le refus tel quel et ne construit aucun contournement. ⚠ Gate d'activation (Q32) : la charte courante est un texte d'attente (« à valider par un DPO ») et l'écran affiche en bandeau permanent l'avertissement de production que le backend sert tant que ce statut n'a pas changé — c'est une condition d'activation, pas un blocage de construction. Backends /api/annuaire et /api/evaluations déjà livrés (T-14c) — mode API par défaut, bascule mode MOCK disponible (voir API.md).

Modules à venir

Les écrans métier ci-dessous ne sont pas encore construits. Trois modules pourtant livrés, déployés et servis (/taches-fin-mois/, /dashboard-manager/, /parametres-tenant/) ont été retirés de cette liste le 14/09/2026 et figurent désormais au menu ci-dessus (Q234/D-402 — trou T-6 wireframes.md). Un quatrième l'a été le 20/09/2026 : l'écran F18 des primes ponctuelles (contrat T-50), livré au menu sous /primes/ — le module existe et répond, cette liste ne pouvait plus l'annoncer. Un cinquième l'a été le même jour : l'écran budget & campagne N+1 (contrat T-46), livré au menu sous /dashboard/, qui retire aussi « budget & pilotage (T-12) » de la liste ci-dessous — les écrans T-12.1/T-12.2 sont désormais livrés et servis. Un sixième l'a été le même jour : l'écran de l'espace prestataire F29 (contrat T-48), livré au menu sous /prestataires/, qui retire « espace prestataire F29 » de la liste ci-dessous — le backend de T-14b était déjà livré et déployé, l'écran des 4 documents de conformité ne l'était pas. Un septième l'a été le même jour : l'annuaire du vivier et les évaluations internes (contrat T-49), livrés au menu sous /annuaire/, qui retirent « annuaire/vivier, évaluations internes » de la liste ci-dessous — les backends de T-14c étaient livrés et déployés, leurs écrans ne l'étaient pas. Il reste à construire : gamification F30 (T-20) et l'export/suppression de fin de contrat du super-admin (point 6 de T-19.2, bloqué par Q189).

Précision volontaire, pour ne pas confondre « contrat livré » et « écran livré » : les backends de T-14b/T-14c, T-12 et T-09 sont livrés et déployés (T-09 avec Zoho Sign actif en production) alors que leurs écrans restaient à construire — pour T-09, l'écran est désormais LIVRÉ (/contrats/, contrat T-45, 20/09/2026), il a donc été retiré de cette liste le même jour ; pour T-12, l'écran est également LIVRÉ (/dashboard/, contrat T-46, 20/09/2026), retiré de la liste le même jour ; pour T-14b, l'écran des documents de conformité prestataire est LIVRÉ (/prestataires/, contrat T-48, 20/09/2026) ; pour T-14c, les écrans de l'annuaire/vivier et des évaluations internes sont LIVRÉS (/annuaire/, contrat T-49, 20/09/2026) — il ne reste donc AUCUN écran à construire de T-14b/T-14c ; et le module Super-admin, déjà accessible ci-dessus, couvre les points 3/4/5/7 de T-19.2 — seul le point 6 manque.

État de la plateforme

Interrogation de l'API…