# 14. Évolutions demandées et backlog de reprise

Dernière mise à jour : 31 août 2026  
Statut : besoins exprimés en fin de stage, non livrés dans la version analysée

Ce chapitre conserve les demandes métier qui n'ont pas pu être terminées avant la passation. Elles ne doivent pas être considérées comme déjà disponibles. Toute réalisation doit passer par une validation fonctionnelle, des tests sur une copie de la base et une PR `feature/*` vers `dev`.

## Vue priorisée

| Priorité | Évolution | Charge indicative | Risque principal |
|---|---|---:|---|
| P0 | Agrandir les zones de saisie des documents automatiques | Faible | Régression responsive |
| P0 | Documenter et stabiliser les champs des modèles DOCX | Moyenne | Modèle invalide ou champ ambigu |
| P0 | Paramétrer les catégories et modèles documentaires | Faible à moyenne | Catégories incohérentes |
| P1 | Imprimer les éléments `typeobjet = E` | Moyenne | Reproduire une logique Access non explicitée |
| P1 | Notifier les administrateurs lors d'une première connexion | Moyenne | Mails multiples et compte sans droits adaptés |
| P1 | Ajouter le mode de remise d'un document | Moyenne à forte | Logique conditionnelle dans les modèles |
| P2 | Notifier les responsables de secteur lors d'événements RH | Forte | Confidentialité, doublons et routage erroné |

Les charges sont relatives au projet. Elles n'incluent pas le délai de validation métier ou DSI.

## Mail aux administrateurs lors d'une première connexion

### Besoin

Quand une personne inconnue se connecte pour la première fois par Microsoft Entra ID, son compte est créé avec le rôle `lecture`. Les administrateurs doivent recevoir un mail afin de lui attribuer les rôles, permissions et scopes nécessaires.

### État actuel

`authenticateSsoUser()` crée directement le nouvel enregistrement `auth_users`, puis renseigne `last_login_at`. Aucun message n'est envoyé. Une connexion suivante met seulement à jour les informations du fournisseur et la dernière connexion.

Fichiers principaux :

- `backend/backend_envie2e/src/lib/auth.ts` ;
- `backend/backend_envie2e/src/lib/sso/session.ts` ;
- `backend/backend_envie2e/src/app/api/auth/microsoft/callback/route.ts` ;
- services Microsoft Graph existants, à mutualiser plutôt qu'à recopier.

### Conception recommandée

1. Faire remonter explicitement l'information `created: true` depuis l'authentification SSO.
2. Créer le compte avec le minimum de droits prévu par la politique métier.
3. Identifier les administrateurs destinataires depuis une configuration validée, pas depuis une adresse codée en dur.
4. Envoyer un mail contenant l'identité, l'adresse professionnelle, la date et un lien vers les paramètres utilisateurs.
5. Rendre l'opération idempotente avec une date telle que `first_login_notified_at` ou une table d'événements unique.
6. Conserver l'échec d'envoi et permettre une relance contrôlée sans bloquer la connexion.

### Décisions attendues

- Le nouvel utilisateur doit-il être actif immédiatement ou attendre une validation ?
- Quels rôles reçoivent la notification ?
- L'échec du mail doit-il bloquer la première connexion ? Recommandation : non.
- Quel lien de production doit être placé dans le message ?

### Critères d'acceptation

- un seul mail est produit pour la création d'un compte ;
- aucune notification n'est renvoyée lors des connexions suivantes ;
- un échec Graph est journalisé sans créer deux comptes ;
- le compte possède uniquement les droits initiaux approuvés ;
- les tests couvrent nouvelle personne, personne existante, domaine refusé et compte inactif.

## Notifications aux responsables de secteur

### Besoin

Prévenir les responsables concernés lorsqu'un événement RH est créé ou atteint une échéance : absence, visite médicale ou autre événement à définir.

### Points à clarifier avant développement

- liste exacte des événements et des actions déclenchantes : création, modification, suppression ou échéance ;
- destinataires par établissement et secteur ;
- délai d'envoi : immédiat, regroupé ou quotidien ;
- contenu autorisé, en particulier pour les informations médicales ;
- cas d'un salarié ou contrat sans secteur ;
- traitement d'un responsable absent ou d'une adresse invalide ;
- règles de relance et de non-duplication.

### Conception recommandée

Ne pas placer l'envoi directement dans un composant frontend ni dans un trigger MySQL. Après la transaction métier, créer un événement ou une entrée d'outbox, puis laisser un service d'envoi la traiter. Réutiliser `sector-emails.service.ts`, les services Graph et l'historique d'envoi existant.

Fichiers probablement concernés :

- `backend/backend_envie2e/src/services/absences.service.ts` ;
- `backend/backend_envie2e/src/services/visites-medicales.service.ts` ;
- `backend/backend_envie2e/src/services/sector-emails.service.ts` ;
- services Graph et historique des alertes ;
- `frontend/src/components/parametres/SectorEmailsPanel.tsx` ;
- schéma Prisma et migration éventuelle pour l'outbox.

### Critères d'acceptation

- le bon responsable reçoit le bon événement pour son périmètre ;
- aucune information médicale non nécessaire n'est envoyée ;
- une même action métier ne génère pas plusieurs mails ;
- l'échec est visible et relançable ;
- une modification ou suppression possède une règle explicite ;
- les tests couvrent plusieurs secteurs, destinataire absent et échec Graph.

## Agrandissement des zones de saisie documentaire

### Besoin

Les champs longs des documents automatiques doivent être plus confortables à saisir et à relire.

### État actuel

Dans `DynamicDocumentsAutomatiques.tsx`, un champ texte devient une zone de quatre lignes seulement lorsque sa valeur préremplie dépasse 120 caractères. Un champ manuel initialement vide reste donc un simple champ sur une ligne, même si son contenu futur est long.

### Modification recommandée

- afficher les champs texte manuels dans une zone multiligne, ou disposer d'une métadonnée de présentation ;
- augmenter la largeur utile de la colonne « Valeurs du document » ;
- conserver une mise en page responsive sur un écran plus petit ;
- éviter qu'un aperçu PDF sticky réduise excessivement la saisie ;
- tester une valeur proche de la limite backend de 10 000 caractères.

Fichier principal : `frontend/src/components/impressions/DynamicDocumentsAutomatiques.tsx`.

### Critères d'acceptation

- les textes longs sont visibles sans défilement horizontal ;
- les champs courts, dates, nombres et booléens restent compacts ;
- l'écran reste utilisable aux résolutions courantes de l'entreprise ;
- les téléchargements Word/PDF restent inchangés.

## Impression des éléments `typeobjet = E`

### Besoin

Ajouter une interface d'impression pour les entrées de la configuration historique dont `typeobjet` vaut `E`.

### Éléments connus dans la source Access

| Ordre | Libellé | Nom historique | Source historique |
|---:|---|---|---|
| 200 | Courrier fin CMU | `Alerte_FinCMU` | `Prov_CourrierCMU` |
| 210 | Liste Salariés | `Etat Alarme` | `Salariés En Cours` |
| 220 | Courrier Mutuelle | `Alerte_CourrierMutuelle` | `Prov_CourrierMutuelle` |
| 230 | Convocations à venir | `Etat_SanctionsConvocationsAVenir` | `Alert_Sanctions3` |

Cette liste décrit l'historique Access ; elle ne prouve pas que les quatre éditions doivent être reproduites à l'identique. Le tuteur doit valider le résultat attendu, les filtres, l'ordre et le format.

### Conception recommandée

- ajouter un filtre ou une section « Éditions » fondée sur `listes_alertes.typeobjet = 'E'` ;
- associer chaque édition à une requête métier maintenable plutôt qu'à un nom Access ;
- produire une page imprimable ou un PDF cohérent avec les états RH ;
- appliquer les habilitations et scopes au backend ;
- traiter explicitement l'absence de résultat.

Fichiers probablement concernés :

- `backend/backend_envie2e/src/services/alertes-mail.service.ts` ou un service d'états dédié ;
- `backend/backend_envie2e/src/services/etats.service.ts` ;
- routes sous `src/app/api/impressions/` ;
- page Documents/Impressions côté frontend.

### Critères d'acceptation

- seules les éditions validées sont proposées ;
- le résultat respecte les scopes de l'utilisateur ;
- l'impression possède un titre, une date d'édition et des colonnes validées ;
- les cas vides et les erreurs sont lisibles ;
- chaque édition possède un test métier.

## Mode de remise d'un document automatique

### Besoin

Lors de la génération, choisir entre :

- `Remise en main propre` : bloc de signature des parties et mention du double remis au salarié ;
- `Courrier recommandé` : affichage du numéro de recommandé.

Les deux blocs sont exclusifs et le document doit s'adapter au choix.

### Conception recommandée

Ajouter dans l'écran de génération :

- un champ obligatoire `modeEnvoi` ;
- un champ `numeroRecommande`, visible et obligatoire uniquement en mode recommandé.

Éviter de demander aux auteurs de modèles de maîtriser une syntaxe conditionnelle non documentée. Le backend peut calculer des chaînes prêtes à insérer :

| Balise proposée | Valeur en main propre | Valeur en recommandé |
|---|---|---|
| `{modeEnvoi}` | `Remise en main propre` | `Courrier recommandé` |
| `{blocRemiseMainPropre}` | texte et emplacements de signatures | vide |
| `{blocEnvoiRecommande}` | vide | texte du recommandé et numéro |
| `{numeroRecommande}` | vide | numéro saisi |

Si une véritable mise en page conditionnelle devient nécessaire, vérifier d'abord la syntaxe supportée par la version de Docxtemplater utilisée et ajouter des tests avec tableaux, sauts de ligne et paragraphes vides.

Fichiers principaux :

- `frontend/src/components/impressions/DynamicDocumentsAutomatiques.tsx` ;
- `backend/backend_envie2e/src/validators/documents-modeles-generation.ts` ;
- `backend/backend_envie2e/src/services/documents-modeles-generation.service.ts` ;
- modèles DOCX concernés.

### Décisions attendues

- formulation juridique exacte de chaque bloc ;
- format et caractère obligatoire du numéro de recommandé ;
- présence d'une date et d'un lieu de remise ;
- mode d'envoi applicable à tous les modèles ou seulement à certaines catégories.

### Critères d'acceptation

- un seul bloc apparaît dans le document final ;
- le recommandé est impossible sans numéro si celui-ci est obligatoire ;
- la main propre comporte les mentions et signatures validées ;
- Word et PDF produisent le même contenu ;
- changer de mode efface ou ignore les données incompatibles.

## Paramétrage des catégories et modèles

### État actuel

Les catégories de base sont définies dans `DocumentTemplatesPanel.tsx` : Attestations, Courriers, Sanctions et avertissements, Mutuelle et prévoyance, Préfecture et titres de séjour, Visites médicales, Contrats, Avenants et Autres. Les catégories déjà présentes dans les modèles sont également ajoutées dynamiquement à la liste.

Cette coexistence peut créer des variantes comme `Courrier`, `Courriers`, des différences d'accents ou des espaces invisibles.

### Travail métier à effectuer

1. Valider la liste officielle et l'ordre des catégories.
2. Affecter chaque modèle à une seule catégorie.
3. Vérifier l'établissement éventuel de chaque modèle.
4. Contrôler le code technique, le libellé et la description.
5. Tester l'aperçu avant activation.
6. Désactiver ou archiver les doublons et anciennes versions.
7. Vérifier les signataires actifs.
8. Documenter le propriétaire métier de chaque modèle.

### Évolution technique recommandée

À terme, stocker les catégories dans un référentiel administrable avec un identifiant stable, un libellé, un ordre, un statut actif et éventuellement une portée par établissement. Prévoir une migration des valeurs texte existantes avant de remplacer le fonctionnement actuel.

### Critères d'acceptation

- aucune catégorie équivalente en doublon ;
- tous les modèles actifs ont une catégorie validée ;
- chaque modèle actif a été prévisualisé ;
- les modèles sont rangés dans le même ordre en Paramètres et Documents ;
- la liste et ses responsables sont consignés dans la passation.

## Ordre de reprise conseillé

1. Valider les décisions métier ouvertes.
2. Finaliser les catégories et le dictionnaire des champs.
3. Corriger le confort de saisie des documents.
4. Réaliser et tester le mode de remise.
5. Implémenter les impressions `typeobjet = E` une par une.
6. Ajouter la notification de première connexion avec idempotence.
7. Concevoir les notifications de secteur avec la DSI et les responsables RH.

Chaque évolution terminée doit mettre à jour ce chapitre : déplacer son statut vers « livré », indiquer la PR, les migrations éventuelles et la procédure de recette.