1. Principe général

L'outil propose trois espaces :

• Espace étudiant : consulter son planning, déclarer ses heures ;
• Espace cadre : piloter les étudiants d'un ou plusieurs services ;
• Administration : pas d'interface web dédiée — vous travaillez directement dans le document Grist qui contient toutes les données (services, comptes cadres, codes horaires, jours fériés…).

C'est dans Grist que vous créez les services, activez les comptes cadres et ajustez le référentiel utilisé par les deux espaces web.

2. Accéder au document Grist

Le document GESTION-ETUDIANT est hébergé sur l'instance DINUM grist.numerique.gouv.fr, organisation de l'établissement. Un lien direct est aussi proposé sur l'écran de connexion de l'espace étudiant (« Vous êtes administrateur ? »).

3. Identité de l'établissement

Table ETABLISSEMENT (première ligne uniquement) : l'identité affichée dans l'en-tête des espaces web. Elle permet de déployer l'outil pour un autre établissement sans toucher au code.

Tout ce qui suit se règle désormais aussi depuis l'espace administrateur, onglet « Établissement » (nom, description, sous-titre, logo, domaine mail, habillage du site, bandeau bêta, pied de page) : plus besoin d'ouvrir Grist pour ces réglages courants.

4. Gérer les services

Table SERVICES, une ligne par service accueillant (ou non) des étudiants. Les sites géographiques sont, eux, listés dans la table SITES (colonne NOM).

5. Gérer les comptes cadres

Table UTILISATEURS, une ligne par cadre (ou responsable) susceptible de se connecter à l'espace cadre.

Le code PIN, en pratique

La connexion cadre demande email + code d'accès + code PIN. Le PIN n'est pas transmis par vous : le cadre le choisit lui-même (4 à 6 chiffres) à sa première connexion, et peut le changer ensuite depuis le menu de son avatar. Deux conséquences pour vous :

• Un lien de connexion directe (email + code d'accès dans l'URL) ne suffit plus à ouvrir un espace : le PIN reste à saisir. C'est ce qui rend ces liens acceptables.
• Écrivez ces liens avec un dièse, pas un point d'interrogation : espace-cadre.html#email=…&code=… et non espace-cadre.html?email=…. Ce qui suit le dièse n'est jamais envoyé au serveur : le code d'accès n'apparaît donc pas dans les journaux d'accès de l'hébergeur. Avec un point d'interrogation, si. Les anciens liens continuent de fonctionner, mais régénérez-les (formule Grist, modèles d'e-mail) ; il en va de même du lien administrateur, qui porte en plus la clé de dépannage.
• Vous ne pouvez pas retrouver un PIN oublié, seulement le réinitialiser : cochez Reinit_PIN sur la ligne du cadre et prévenez-le. Le bouton « Code PIN oublié ? » de l'écran de connexion prépare justement cette demande sous forme d'e-mail.

L'espace administrateur, sans passer par Grist

Tout ce qui précède se fait désormais aussi depuis le site, dans l'espace administrateur : même connexion que l'espace cadre (email + code d'accès + PIN), réservée aux comptes dont la case Administrateur est cochée. Un bouton « ⚙ Administration » apparaît alors dans l'en-tête de l'espace cadre.

L'écran « Comptes des cadres » permet de :

• créer un compte — le Code_acces est tiré au sort (6 chiffres) et affiché une seule fois : copiez-le à ce moment-là, ou régénérez-en un plus tard ;
• rattacher le cadre à ses services — cases à cocher, qui écrivent dans SERVICES.Cadres_secondaires. Les services dont il est le référent (Cadre_ref) ou dont il est CSS de pôle s'affichent mais restent à modifier dans Grist, pour ne pas laisser un service sans responsable ;
• réinitialiser un PIN, débloquer un compte après 5 essais manqués, régénérer un code d'accès, activer ou désactiver un compte, accorder ou retirer les droits d'administration ;
• préparer l'e-mail d'invitation, avec le lien de connexion déjà écrit en #.

Le rattachement se fait par deux listes déroulantes — le site, puis le service — et ce qui est retenu s'affiche juste en dessous, groupé par site, avec une croix pour retirer. Passer par le site d'abord évite de confondre deux services de même nom sur des sites différents (plusieurs « EHPAD HEB », par exemple).

L'onglet « Services »

Le second onglet de l'espace administrateur gère la table SERVICES et la table SITES : créer un site, créer un service, changer son nom, son code UF, son site, son pôle, son cadre référent, et l'ouvrir ou le fermer aux étudiants. Les services y sont présentés groupés par site, avec le nombre de cadres rattachés en plus du référent.

La fiche d'un service porte aussi ses codes horaires (SERVICES.Codes_horaires) : les codes cochés sont les seuls proposés aux cadres du service dans le planning. Aucun coché = tous les codes du document — c'est la même règle que l'onglet « Codes horaires » de l'espace cadre, avec lequel cet écran est interchangeable.

L'onglet « Pôles »

Créer un pôle, le renommer, et surtout désigner son ou ses cadres supérieurs, qui accèdent alors à tous les services du pôle. Le tableau montre, pour chaque pôle, ses cadres supérieurs et les services qui lui sont rattachés (le rattachement lui-même se règle sur la fiche du service).

L'onglet « Organigramme »

Une vue de synthèse en lecture seule, imprimable : le récapitulatif par lieu (site → pôle → service, avec pour chaque service son référent, les cadres rattachés et le cadre supérieur), puis le récapitulatif par cadre — ce dont chacun s'occupe et où. Les comptes sans aucun service y apparaissent explicitement : ce sont ceux qui ne peuvent pas ouvrir l'espace cadre.

6. Cadres de pôle (CSS)

Le cadre supérieur de santé (CSS) d'un pôle a automatiquement accès à tous les services de son pôle, sans avoir à être ajouté service par service. Ce lien se règle sur la table Pole : le champ CSS pointe vers l'UTILISATEURS qui doit superviser le pôle.

Le CSS dispose des mêmes droits que les cadres de service (édition du planning, validation des déclarations, fiches étudiants) sur l'ensemble des services de son pôle.

7. Codes horaires et jours fériés

Table CODES_HORAIRES : référentiel des codes utilisables dans le planning (ex. M Matin, S Soir, N Nuit, J Journée, R/RH-S/RH-D Repos, IFSI, ABS Absence, JF Jour férié, RF Récupération jour férié). Chaque code porte ses horaires et le nombre d'heures associé, utilisés pour tous les calculs de compteurs.

Table JOURS_FERIES : liste des dates fériées de l'année. À tenir à jour chaque année civile — c'est elle qui pilote le grisage des jours fériés dans les plannings et le calcul des heures à réaliser (voir le mode d'emploi cadre, section jours fériés, pour le détail des règles).

Les cadres peuvent aussi, depuis leur espace (onglet « Codes horaires »), choisir les codes actifs pour leur service et créer de nouveaux codes — ceux-ci s'ajoutent au référentiel commun CODES_HORAIRES. Un code créé n'est jamais supprimé automatiquement : la suppression éventuelle relève de l'administrateur (attention aux plannings qui l'utilisent).

8. Journal d'activité

Table JOURNAL_ACTIVITE : le Worker y consigne automatiquement les connexions et les actions des étudiants, des cadres et des administrateurs (colonnes Horodatage, Role, Qui, Nom, Action, Detail). Utile pour comprendre « qui a fait quoi » en cas de question.

Trois colonnes complètent la ligne et rendent le journal filtrable dans Grist : Site, Service et Etudiant (l'étudiant concerné par l'action). Elles sont créées automatiquement à la première écriture — si elles n'apparaissent pas dans une vue existante, ajoutez-les avec le sélecteur de colonnes du widget.

Ce qui s'enregistre

La colonne Role dit toujours de quel espace vient la ligne — Étudiant, Cadre ou Administrateur — et Qui identifie l'auteur (code anonymat pour un étudiant, adresse e-mail pour un cadre).

• Le Detail dit ce qui a réellement changé : « Mardi 14/07/2026 : MAT → AS », « tuteur : (vide) → Mme MARTIN · fin : 14/08/2026 → 21/08/2026 », « Rattrapage du 15/07/2026, 08:00–12:00 — validée », « Dr MARTIN — droits d'administration accordés, 2 service(s) rattaché(s) ou détaché(s) ».
• Les lignes Consultation de l'espace cadre indiquent le service réellement affiché (et l'onglet), pas la liste des services auxquels le cadre a accès. Chaque couple service/onglet n'est journalisé qu'une fois par session, et un simple rafraîchissement d'écran après une action ne crée plus de ligne en double. Même règle pour l'espace administrateur : une ligne par onglet et par session.
• L'ouverture du planning personnel d'un étudiant par un cadre est tracée nommément (Consultation d'un dossier étudiant), tout comme les auto-inscriptions depuis la page « entrée en stage ».
• L'écriture est en best-effort : un échec du journal ne bloque jamais l'utilisateur ;
• Les lignes de plus de 30 jours sont purgées automatiquement (à chaque connexion, par lots) — pas d'entretien manuel à prévoir.
• Les actions sensibles y sont tracées, notamment la suppression d'une période par un cadre (bouton « Supprimer cette période » dans un dossier étudiant) : elle retire en cascade la période, son planning hebdomadaire et ses rendez-vous. Les semaines de planning devenues orphelines (période disparue) et vieilles de plus de 30 jours sont elles aussi purgées automatiquement.

Connexions refusées

Les tentatives qui n'aboutissent pas sont journalisées elles aussi, sous l'action Connexion refusée : c'est ce qui permet de repérer un essai en série sur un compte. Le Detail donne le motif — code anonymat ou adresse e-mail incorrect, e-mail ou code d'accès incorrect, code PIN incorrect, compte désactivé, compte bloqué après plusieurs codes PIN erronés.

• Seul l'identifiant visé est enregistré (code anonymat ou adresse e-mail). Le secret essayé — code d'accès, code PIN — n'est jamais écrit dans le journal.
• Ces lignes sont les seules qu'un visiteur non connecté puisse provoquer : un garde-fou les borne (une ligne par compte visé et par motif toutes les 10 minutes, et au plus 5 lignes par appareil). Une attaque par essais en série laisse donc une trace sans chasser du journal les 30 jours d'activité réelle.
• Le motif reste volontairement flou côté étudiant (« code anonymat ou adresse e-mail incorrect ») : c'est le même message que celui affiché à l'écran, pour ne pas révéler quels codes existent.

9. Verrouillage des stages terminés

Côté espace cadre, le planning personnel, les déclarations et les rendez-vous d'un stage se verrouillent automatiquement 5 jours après la fin du stage (interface et API). Passé ce délai, le cadre ne peut plus rien y modifier et voit un message l'invitant à vous contacter.

C'est volontaire : cela fige les données une fois le stage bouclé. Si une correction reste nécessaire au-delà de ce délai (erreur avérée, litige…), vous pouvez toujours intervenir directement dans le document Grist, qui n'est pas soumis à ce verrou.

10. Tableau de bord satisfaction

Une page Grist dédiée (« Tableau de bord satisfaction ») affiche les résultats des questionnaires envoyés aux étudiants en fin de stage : KPI globaux (nombre de réponses, note moyenne, taux de recommandation), scores par thème, verbatims (points forts, axes, suggestions) et fréquentation par service. Deux champs de dates permettent de restreindre la période analysée.

11. Sécurité — points d'attention

• Le code anonymat étudiant (1^re lettre prénom + date de naissance + 1^re lettre nom) est volontairement simple, parce qu'un étudiant doit pouvoir le recomposer de mémoire. Il est donc complété par un 2^e facteur : l'adresse e-mail du dossier, exigée dès qu'une adresse y figure. Un dossier sans e-mail reste accessible au seul code — renseigner l'adresse des étudiants est ce qui protège leur espace.
• L'étudiant peut modifier lui-même son téléphone et son e-mail depuis son espace : changer l'e-mail change son propre 2^e facteur, et rien d'autre.
• Le code d'accès cadre donne, lui, accès à toutes les données d'un service entier : transmettez-le de façon confidentielle, et révoquez-le (décochez Utilisateur_de_l_outil) dès qu'un cadre quitte ses fonctions. Il ne fait que 6 chiffres — assez court pour se dicter au téléphone, trop court pour tenir tout seul : ce qui protège réellement la connexion, c'est le code PIN qui le double (choisi par le cadre, stocké haché, illisible pour vous comme pour le document Grist, et le compte se bloque 15 minutes après 5 essais manqués — voir section 5). Un code d'accès seul, deviné, n'ouvre rien.
• Une clé d'accès administrateur, gardée comme secret côté Worker (jamais dans le code ni dans les mails d'invitation), permet d'ouvrir l'espace d'un cadre sans son PIN — pour du dépannage. Toute connexion de ce type est signalée comme telle dans le journal d'activité. Traitez cette clé comme le secret le plus sensible de l'installation.
• La clé API Grist qui permet au site web de lire/écrire dans le document n'est jamais stockée dans le code : elle vit uniquement en secret côté Cloudflare Worker (proxy).
• Ni les étudiants ni les cadres ne peuvent accéder aux tables sensibles du document (autres services, autres pôles) : le proxy limite strictement chaque requête à leur périmètre.
• Un journal d'activité (table JOURNAL_ACTIVITE) trace, pour des raisons de sécurité, les connexions et les actions des utilisateurs (auteur, date, étudiant concerné, détail). Les lignes de plus de 30 jours sont purgées automatiquement.

12. Déploiement technique

Cette section concerne uniquement la personne qui héberge et maintient le code de l'application (pas la gestion quotidienne des services et des cadres, décrite ci-dessus).

L'application repose sur trois briques : le site (GitHub Pages, dossier docs/), un proxy (Cloudflare Worker, dossier worker/) qui protège la clé API Grist, et le document Grist lui-même. Le détail des étapes (clé API, déploiement du worker, configuration du site, sécurisation de l'origine) est décrit dans le README.md du dépôt ; pour déployer une copie de l'outil pour un autre service ou établissement, voir INSTALL.md.

Un second secret, facultatif, est posé de la même façon : wrangler secret put ADMIN_KEY. C'est la clé d'accès administrateur évoquée en section 11 (connexion à l'espace d'un cadre sans son PIN, pour du dépannage). Tant qu'elle n'est pas définie, cet accès n'existe simplement pas.

Un troisième secret, également facultatif, signe les sessions cadre : wrangler secret put SESSION_SECRET (une longue chaîne aléatoire). Après la connexion — donc après vérification du PIN — le worker délivre un jeton signé, valable 12 heures, et c'est lui, et non le code d'accès, que le navigateur présente ensuite à chaque requête. S'il n'est pas défini, la clé API Grist sert de clé de signature et tout fonctionne de la même façon ; le poser reste préférable, car les deux secrets deviennent alors indépendants. Changer ce secret déconnecte tous les cadres, sans autre conséquence.