> For the complete documentation index, see [llms.txt](https://documentation.efalia.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.efalia.com/specifique/musee-du-louvre/spec-demande-de-travaux.md).

# Spéc. — Demande de travaux

Cette spécification décrit la modélisation, dans **Efalia Process**, du processus de **demande de travaux (DT)** dématérialisé pour le **Musée du Louvre (MDL)** : procédures, acteurs, workflow (états et opérations), règles de gestion, formulaires, champs et intégrations.

{% hint style="info" %}
**Document de spécification** issu d'un parcours du *Designer* Efalia Process (réunion de cadrage). Il décrit le **modèle** (le « comment ça marche » côté conception), pas un mode d'emploi utilisateur. Source : transcription de la réunion + captures du Designer. Les points non tranchés ou incertains sont signalés par un **encadré rouge « À VALIDER »**.
{% endhint %}

***

## 1. Objectif & contexte

* **Client** : Musée du Louvre (MDL).
* **Produit** : Efalia Process (modélisation via le *Designer*).
* **Objet** : dématérialisation des **demandes de travaux** émises par les directions du musée, de la création à la clôture, en passant par la validation hiérarchique, la planification et la réalisation en atelier.
* **Processus** (nom affiché) : `Demande de travaux MDL`.
* **Procédure principale** : `Créer une DT` — **nom interne** : `Creer_une_DT`.

***

## 2. Périmètre — le processus et ses procédures

Le **processus** `Demande de travaux MDL` orchestre le cycle de vie d'une demande de travaux : un **demandeur** crée la DT → elle est éventuellement **validée** par son responsable → **planifiée** par la planification → **réalisée** en atelier (via des **fiches ateliers**, documents fils) → **clôturée** automatiquement une fois tous les ateliers terminés.

| # | Procédure                         | Rôle(s) principal(aux)                                   | Objet                                                                                        |
| - | --------------------------------- | -------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| 1 | **Créer une DT** (`Creer_une_DT`) | Demandeur / Valideur / Planification / Chef d'atelier DT | Cœur du processus (création → validation → planification → réalisation → clôture).           |
| 2 | **GERER LES DEMANDES**            | Administration des listes                                | Met à jour les **listes déroulantes** du formulaire, chacune via son connecteur (voir §8.2). |

La procédure **Créer une DT** génère des **documents fils** — les **fiches ateliers** — par dérivation (voir §8.1).

<figure><img src="/files/iT9hJVHCFOuAoPGAKQ81" alt="Projet Demande de travaux MDL dans le Designer Efalia Process"><figcaption><p>Le projet « Demande de travaux MDL » dans le Designer : à gauche, l'arbre (processus, les 2 procédures « Créer une DT » et « GERER LES DEMANDES », unités, formulaires numérotés) ; au centre, le diagramme de la procédure « GERER LES DEMANDES » et ses 5 opérations de mise à jour des listes.</p></figcaption></figure>

***

## 3. Acteurs & rôles

### Acteurs humains (procédure « Créer une DT »)

| Acteur                        | Rôle                                                                                                                                               |
| ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Demandeur DT**              | Crée la demande ; la corrige sur demande du valideur ou de la planification ; peut annuler ; ajoute des pièces jointes à tout moment.              |
| **Valideur DT** (responsable) | Valide la demande, la refuse (→ annulée) ou demande des modifications.                                                                             |
| **Planification DT**          | Planifie (partiellement ou totalement), demande des modifications, annule, reprogramme, clôture ; assure un **double visa** (deux planificateurs). |
| **Chef d'atelier DT**         | Traite la **fiche atelier** : la met en cours puis la clôture (travaux réalisés).                                                                  |
| **Conducteur DT**             | **Consultation seule** des documents.                                                                                                              |
| **Consultation DT**           | **Consultation seule** (lecture) à l'état planifié.                                                                                                |

### Agents automatiques (non humains)

| Agent                     | Déclenche                                        | Rôle                                                                                                     |
| ------------------------- | ------------------------------------------------ | -------------------------------------------------------------------------------------------------------- |
| **Agent d'envoi de mail** | fiche atelier `À traiter`                        | Envoie un mail au chef d'atelier pour l'avertir qu'une fiche lui est affectée (`À traiter` → `Affecté`). |
| **Agent de clôture**      | toutes les fiches ateliers en `Travaux réalisés` | Clôture automatiquement la DT (synchronisation des documents fils).                                      |

{% hint style="info" %}
**Affectation des acteurs.** Un valideur agit sur une DT s'il est le **responsable** du demandeur ; les acteurs planification / chef d'atelier sont ceux **rattachés à l'unité / l'atelier** concerné. La règle exacte (rôle + unité) est décrite au §RG1 pour la validation.
{% endhint %}

{% hint style="danger" %}
**⚠️ À VALIDER** — noms exacts des agents automatiques (l'un est décrit comme « l'agent qui envoie le mail », l'autre « agent de clôture ») et intitulés confirmés des rôles `Chef d'atelier DT`, `Conducteur DT`, `Consultation DT` (les rôles `Demandeur DT`, `Valideur DT`, `Planification DT` sont confirmés par le Designer).
{% endhint %}

***

## 4. Workflow — procédure « Créer une DT »

Une **opération** est définie par un ou plusieurs **états d'entrée** et un ou plusieurs **états de sortie**, avec un **formulaire** associé. Les **états** matérialisent l'avancement du document.

<figure><img src="/files/EYm4NQeM98eJY0yVM4jq" alt="Machine à états de la procédure Créer une DT dans le Designer"><figcaption><p>Machine à états de la procédure « Créer une DT » dans le Designer : couloirs par acteur (Demandeur DT, Valideur DT, Planification DT…), états et opérations.</p></figcaption></figure>

### 4.1 États du document

**Demande de travaux (DT)** : `Nouveau` · `À valider` · `À modifier` · `Modifié par le demandeur` · `Modification demandée` · `Modifié` *(retour planification)* · `À planifier` · `Planifié partiellement` · `Validé` · `Planifié` · `Clôturé` · `Annulé`.

`Annulé` et `Clôturé` sont des états **terminaux**.

**Fiche atelier** (document fils) : `À traiter` · `Affecté` · `En cours` · `Travaux réalisés`.

{% hint style="danger" %}
**⚠️ À VALIDER** — libellés exacts des états (le parcours était oral) : notamment `Modifié` (retour planification) vs `Modifié par le demandeur`, `Planifié partiellement` vs `Planifié`, le libellé de l'état de **clôture** (`Clôturé` ?), et les états de la fiche atelier (`Affecté` après passage de l'agent).
{% endhint %}

### 4.2 Opérations par acteur

{% tabs %}
{% tab title="Demandeur DT" %}

| État(s) d'entrée                                 | Opération                                                     | État(s) de sortie                                             | Formulaire                                       |
| ------------------------------------------------ | ------------------------------------------------------------- | ------------------------------------------------------------- | ------------------------------------------------ |
| `Nouveau`                                        | Créer la demande                                              | `À valider` **ou** `À planifier` *(routage, voir RG1)*        | Formulaire demandeur                             |
| `À modifier`                                     | Modifier                                                      | `Annulé` **ou** `Modifié par le demandeur` (→ Valideur DT)    | Formulaire demandeur 2                           |
| `Modification demandée` *(par la planification)* | Modifier                                                      | `Annulé` **ou** `Modifié` (→ Planification DT pour planifier) | Formulaire demandeur modifié                     |
| `À planifier`, `Validé`                          | **Modifier avant planification** *(optionnelle)*              | mise à jour de la demande                                     | Formulaire demandeur modifié spontané            |
| `Planifié partiellement`, `Planifié`, `Validé`   | **Ajouter des pièces jointes** *(optionnelle, à tout moment)* | état inchangé + mail à la Planification *(voir RG9)*          | Formulaire demandeur lecture sauf pièces jointes |

Sur une demande de modification (valideur ou planification), un **commentaire est obligatoire** ; l'annulation l'est aussi (voir RG2).
{% endtab %}

{% tab title="Valideur DT" %}
Le valideur agit lorsque la DT est à l'état `À valider` **ou** `Modifié par le demandeur` (retour du demandeur après une demande de modification : il y retrouve les **trois mêmes opérations**). Formulaire : **Formulaire responsable**.

| État(s) d'entrée                        | Opération           | État(s) de sortie                                      |
| --------------------------------------- | ------------------- | ------------------------------------------------------ |
| `À valider`, `Modifié par le demandeur` | Valider             | `À planifier` (→ Planification DT)                     |
| `À valider`, `Modifié par le demandeur` | Demander à modifier | `À modifier` (commentaire obligatoire, → Demandeur DT) |
| `À valider`, `Modifié par le demandeur` | Refuser             | `Annulé` (commentaire obligatoire)                     |
| {% endtab %}                            |                     |                                                        |

{% tab title="Planification DT" %}
Formulaire : **Formulaire planificateur** (planification) puis **Formulaire planifié / modif / clôture** (après planification).

| État(s) d'entrée | Opération                                                 | État(s) de sortie                                                              |
| ---------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------ |
| `À planifier`    | Planifier partiellement                                   | `Planifié partiellement`                                                       |
| `À planifier`    | Demander une modification                                 | `Modification demandée` (→ Demandeur DT)                                       |
| `À planifier`    | Annuler / Supprimer                                       | `Annulé` (commentaire obligatoire)                                             |
| `À planifier`    | **Valider les travaux**                                   | `Validé` → **création des fiches ateliers** *(voir RG4)*                       |
| `Validé`         | **Viser** *(double vérification, voir RG3)*               | `Planifié` **ou** `Annulé`                                                     |
| `Planifié`       | Reprogrammer / Modifier / Clôturer la DT *(optionnelles)* | `Planifié` (reprogrammer/modifier) **ou** `Clôturé` (clôturer) — *à confirmer* |

{% hint style="info" %}
**Deux opérations « planifier » (détail technique).** La modélisation distingue **deux** opérations : l'une autorise un **retour en arrière / une annulation**, l'autre **valide** et déclenche la **création des documents fils** (fiches ateliers). Objectif : ne **pas** créer les fiches ateliers en cas de refus ou de demande de modification.
{% endhint %}

{% hint style="danger" %}
**⚠️ À VALIDER** — **moment exact de création des fiches ateliers.** RG4 les crée à `Validé`, mais l'opération *Viser* (entrée `Validé`) peut aboutir à `Annulé`. À quel instant la dérivation se déclenche-t-elle (`Validé` ou seulement après le visa, à `Planifié`) pour éviter des fiches créées pour une DT finalement annulée ? *(Point explicitement laissé en suspens en réunion — « pour l'instant, on passe outre ».)*
{% endhint %}

{% hint style="danger" %}
**⚠️ À VALIDER** — **sorties de workflow non définies** : quelles opérations repartent de `Planifié partiellement` ? Et vers quels états mènent précisément les opérations optionnelles de `Planifié` (*Reprogrammer* / *Modifier* / *Clôturer la DT* → `Clôturé` ?) ?
{% endhint %}
{% endtab %}

{% tab title="Chef d" %}
Agit sur la **fiche atelier**. Formulaire : **Fiche atelier**.

| État(s) d'entrée      | Opération       | État(s) de sortie  |
| --------------------- | --------------- | ------------------ |
| `Affecté`             | Mettre en cours | `En cours`         |
| `Affecté`, `En cours` | Clôturer        | `Travaux réalisés` |

Le chef d'atelier et la planification peuvent également **visualiser** la fiche atelier.
{% endtab %}

{% tab title="Agents & consultation" %}

| Acteur                    | État(s) d'entrée                             | Opération                    | État(s) de sortie | Formulaire                  |
| ------------------------- | -------------------------------------------- | ---------------------------- | ----------------- | --------------------------- |
| **Agent d'envoi de mail** | `À traiter`                                  | Envoyer le mail aux ateliers | `Affecté`         | Fiche atelier lecture       |
| **Agent de clôture**      | fiches ateliers toutes en `Travaux réalisés` | Clôturer la DT               | DT clôturée       | —                           |
| **Consultation DT**       | `Planifié`                                   | Consulter                    | *(état inchangé)* | Formulaire en lecture seule |
| **Conducteur DT**         | tout état visible                            | Consulter                    | *(état inchangé)* | Formulaire en lecture seule |

Le rôle **`Conducteur DT`** ci-dessus est un rôle de **consultation seule** : il ne crée pas de DT. À distinguer d'un **demandeur ayant le profil « conducteur »** (conducteur de travaux) qui, lui, crée des DT mais **sans responsable** — sa demande part alors directement en planification (voir RG1).

{% hint style="danger" %}
**⚠️ À VALIDER** — le rôle **`Conducteur DT`** (consultation) et le **demandeur au profil conducteur** (RG1, sans responsable) désignent-ils la **même population** ? Et sur **quels états** le Conducteur DT a-t-il une visibilité (« tout état » ?) ?
{% endhint %}
{% endtab %}
{% endtabs %}

### 4.3 Règles de gestion

> **RG1 — Routage à la création.** À l'opération *Créer la demande*, deux règles priorisées s'appliquent : **`Responsable` (priorité 1)** — si le demandeur a un **responsable**, la DT part à l'état `À valider` (Valideur DT) ; sinon **`Pas de responsable` (priorité 2)** — la DT part directement à l'état `À planifier` (Planification DT). Un **demandeur ayant le profil « conducteur »** (conducteur de travaux) n'a pas de responsable → routage direct vers `À planifier`, sans validation.

{% hint style="danger" %}
**⚠️ À VALIDER** — **source de la donnée « responsable »** utilisée par RG1 (profil du demandeur, annuaire, connecteur RH ?) : elle conditionne tout l'aiguillage de la validation.
{% endhint %}

> **RG2 — Commentaire obligatoire.** Toute opération de *refus*, de *demande de modification* (valideur ou planification) ou d'*annulation / suppression* exige un **commentaire**.

> **RG3 — Double visa de la planification.** À l'état `Validé`, une **seconde personne** de la planification doit **viser** la DT validée par la première (double vérification), avant passage à `Planifié`. Une **prise en charge / libération de prise en charge** évite que deux planificateurs travaillent simultanément sur le même document.

{% hint style="danger" %}
**⚠️ À VALIDER** — comment le modèle garantit-il que le **second viseur** est une personne **différente** du premier planificateur (règle d'affectation du visa) ?
{% endhint %}

> **RG4 — Création conditionnelle des fiches ateliers.** Les **fiches ateliers** (documents fils) ne sont créées **que si la DT est validée** (`Validé`), jamais en cas de refus ou de demande de modification. Il est créé **une fiche par atelier coché** dans la liste des ateliers du formulaire.

> **RG5 — Clôture automatique de la DT.** Lorsque **toutes** les fiches ateliers sont à l'état `Travaux réalisés`, une **synchronisation** déclenche l'**agent de clôture** qui clôture la DT.

> **RG6 — Notification du chef d'atelier.** Lorsqu'une fiche atelier arrive à l'état `À traiter`, l'**agent d'envoi de mail** prévient le **chef d'atelier** que la demande lui est affectée (état → `Affecté`).

> **RG7 — Délai d'urgence (< 10 jours).** Si la **date de début** saisie est à **moins de 10 jours**, un **avertissement non bloquant** s'affiche (la saisie peut se poursuivre) : *« Délai inférieur à 10 jours, vous êtes hors procédure, c'est une procédure d'urgence. Merci de contacter la planification avant de continuer. »* **À VALIDER** : blocage dur attendu ou simple avertissement ?

> **RG8 — Cohérence des dates.** Par défaut, la **date de fin souhaitée** se positionne sur la **date de début**. Une **date de fin antérieure à la date de début** est refusée (contrôle bloquant).

> **RG9 — Ajout de pièces jointes à tout moment.** Aux états `Planifié partiellement`, `Planifié` et `Validé`, le demandeur peut **ajouter des pièces jointes** (uniquement) ; un **mail est envoyé à la planification** si des ajouts ont été faits.

> **RG10 — Aiguillage « cariste ».** Si la réponse à *« S'agit-il d'une demande cariste ou transfert interne uniquement ? »* est **Oui**, seul le pavé **Installation** (nom interne `cariste`) s'affiche ; si **Non**, le formulaire complet est présenté.

> **RG11 — GERER LES DEMANDES par JavaScript.** Dans la procédure annexe, l'**opération empruntée dépend de la liste choisie** : l'aiguillage est fait **par JavaScript au clic du bouton** (pas par règles de gestion), chaque liste ayant son **connecteur** dédié (voir §8.2).

***

## 5. Formulaires

Les formulaires sont **numérotés** dans le Designer et se distinguent surtout par les champs en **lecture seule / écriture** et par l'étape à laquelle ils interviennent.

| Formulaire                                           | Utilisé par                  | Rôle                                                              |
| ---------------------------------------------------- | ---------------------------- | ----------------------------------------------------------------- |
| **Formulaire demandeur**                             | Demandeur DT                 | Création de la demande.                                           |
| **Formulaire demandeur 2**                           | Demandeur DT                 | Correction après *demande à modifier* du valideur.                |
| **Formulaire demandeur modifié**                     | Demandeur DT                 | Réponse à une *modification demandée* par la planification.       |
| **Formulaire demandeur modifié spontané**            | Demandeur DT                 | Modification de la demande **avant planification** (optionnelle). |
| **Formulaire demandeur lecture sauf pièces jointes** | Demandeur DT                 | Ajout de **pièces jointes** uniquement (reste en lecture).        |
| **Formulaire responsable**                           | Valideur DT                  | Validation / refus / demande de modification.                     |
| **Formulaire planificateur**                         | Planification DT             | Planification de la demande.                                      |
| **Formulaire planifié / modif / clôture**            | Planification DT             | Reprogrammation, modification, clôture après planification.       |
| **Fiche atelier lecture**                            | Agent d'envoi de mail        | Lecture de la fiche pour l'envoi du mail.                         |
| **Fiche atelier**                                    | Chef d'atelier DT            | Traitement de la fiche atelier.                                   |
| **Formulaire (lecture seule)**                       | Consultation / Conducteur DT | Consultation.                                                     |

{% hint style="info" %}
**Formulaires dans le Designer.** L'arbre des Formulaires liste des entrées numérotées (`1- Formulaire demandeur`, `2- Formulaire responsable`, `3- Formulaire planificateur`, `4- …`, `5- …`). La numérotation reflète l'ordre du workflow.
{% endhint %}

{% hint style="danger" %}
**⚠️ À VALIDER** — correspondance exacte **numéro ↔ usage** de chaque formulaire, et intitulés définitifs (`Formulaire planifié / modif / clôture`, `Formulaire demandeur modifié spontané`, formulaire de consultation).
{% endhint %}

***

## 6. Formulaire demandeur — sections & champs

Le formulaire de création est **dynamique** : l'affichage des champs et des sections dépend des réponses (question « cariste », type de demande, ateliers cochés).

<figure><img src="/files/0B3dss7emjp7lzouR2Rl" alt="Formulaire de demande de travaux (front office) au Musée du Louvre"><figcaption><p>Application « Demande de travaux » (front office) : document « Demande de travaux [Nouveau] », section « Informations demandeur » et liste des directions (Département concerné).</p></figcaption></figure>

### 6.1 Section « Informations demandeur »

| Champ                        | Type / comportement                                                                                                                                                                                                                            |
| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Nom Prénom`                 | Rapatrié automatiquement (utilisateur connecté).                                                                                                                                                                                               |
| `ID de la demande`           | Rapatrié automatiquement (identifiant de la DT).                                                                                                                                                                                               |
| `Directions` / `Téléphone`   | Rapatriés automatiquement (direction de rattachement, téléphone).                                                                                                                                                                              |
| `Autre personne à contacter` | Saisie libre (demande pour le compte d'un tiers).                                                                                                                                                                                              |
| `Département concerné`       | Liste déroulante des **directions** du musée (ex. `DAGER`, `DAI`, `DAO`, `DOA`, `DP`, `DS`, `MNED`…), pré-positionnée sur la direction de rattachement ; un autre département peut être choisi si la demande est faite pour quelqu'un d'autre. |
| `Conducteur de travaux`      | Liste déroulante (lié au profil « conducteur » de RG1 — cf. §À VALIDER conducteur).                                                                                                                                                            |

### 6.2 Question d'aiguillage

**« S'agit-il d'une demande cariste ou transfert interne uniquement ? »** (Oui / Non) — voir RG10.

* **Oui** → seul le pavé **Installation** (nom interne `cariste`) s'affiche.
* **Non** → le formulaire complet ci-dessous s'affiche.

{% hint style="danger" %}
**⚠️ À VALIDER** — champs du pavé **Installation** (`cariste`) affiché quand la réponse est « Oui » : leur contenu n'a pas été détaillé en réunion.
{% endhint %}

### 6.3 Formulaire complet (réponse « Non »)

| Champ / section                            | Type / comportement                                                                                                                                                                        |
| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `Type de demande`                          | Cases à cocher.                                                                                                                                                                            |
| `Liste des opérations / projet exposition` | Liste déroulante **obligatoire** (ex. *« Collections permanentes – Opérations ponctuelles ou récurrentes »*) ; la sélection **renseigne le champ `Titre`** (ex. *« Programme peinture »*). |
| `Titre`                                    | Texte — **renseigné automatiquement** à partir de la valeur choisie dans *Liste des opérations*.                                                                                           |
| `Description de la demande`                | Texte libre.                                                                                                                                                                               |
| `Secteur / réserve`                        | Champ(s) de localisation.                                                                                                                                                                  |
| `Demande obligatoire le mardi ?`           | Oui / Non.                                                                                                                                                                                 |
| `Date de début`                            | Date — contrôle **< 10 jours** (RG7).                                                                                                                                                      |
| `Date de fin souhaitée`                    | Date — par défaut = date de début ; **≥ date de début** (RG8).                                                                                                                             |
| `Liste des ateliers`                       | Cases à cocher ; **chaque atelier coché fait apparaître sa section** et générera une **fiche atelier** (RG4).                                                                              |
| `Pièce jointe`                             | Ajout de documents.                                                                                                                                                                        |

{% hint style="info" %}
**Inventaire non exhaustif.** La formatrice a indiqué *« pas mal de petits champs à renseigner »* et n'a pas détaillé chaque champ. La **liste complète** (noms internes, conditions d'affichage) figure dans le **formulaire du Designer** et dans les **listes** gérées par la procédure *GERER LES DEMANDES*.
{% endhint %}

### 6.4 Formulaire planificateur (aperçu)

Côté planification, seuls **certains champs** de l'« information projet » sont modifiables. Deux questions structurent l'écran : **« Validez-vous cette proposition ? »** (Oui → aucune modification ; Non → tous les champs saisis par le demandeur, dates comprises, deviennent modifiables) et, en fin de formulaire, **« Validez-vous toutes les planifications ? »** (Oui / Non ; si Non, chaque validation se met à *Non* par défaut). Les actions disponibles sont *demander des modifications*, *supprimer*, *planifier partiellement*, avec **prise en charge / libération** (RG3).

{% hint style="danger" %}
**⚠️ À VALIDER** — comportement exact lorsque **« Validez-vous toutes les planifications ? » = Oui** (phrase non terminée en réunion), et inventaire complet des champs modifiables par la planification.
{% endhint %}

***

## 7. Intégrations & connecteurs

| Brique                       | Rôle                                                                                                                           |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| **Agent d'envoi de mail**    | Envoie le mail d'affectation au chef d'atelier (RG6).                                                                          |
| **Agent de clôture**         | Clôture automatique de la DT après synchronisation des fiches ateliers (RG5).                                                  |
| **Connecteurs de listes**    | Un connecteur par liste déroulante, mobilisé par la procédure *GERER LES DEMANDES* (§8.2).                                     |
| **JavaScript (externalisé)** | Aiguillage de *GERER LES DEMANDES* au clic, contrôles de dates (RG7, RG8), dynamique du formulaire. Le **JS est externalisé**. |
| **Notifications mail**       | Affectation atelier (RG6), ajout de pièces jointes (RG9).                                                                      |

{% hint style="info" %}
**Création des fiches ateliers (détail technique).** Les fiches ateliers sont créées via le champ **`Autoreceiver`** et **`Work for each derivation`** (dérivation d'un document fils par atelier coché). *Instruction laissée pour la personne qui reprendra la modélisation.*
{% endhint %}

***

## 8. Procédures annexes

### 8.1 Fiche atelier (document fils)

À la validation des travaux, la procédure **génère une fiche atelier par atelier coché** dans le champ **`Liste des ateliers`** du formulaire (dérivation pilotée par `Autoreceiver` / `Work for each derivation`). Chaque fiche **naît à l'état `À traiter`**. Cycle de vie :

`À traiter` → *(agent d'envoi de mail)* `Affecté` → *(chef d'atelier)* `En cours` → `Travaux réalisés`.

Quand **toutes** les fiches d'une DT sont en `Travaux réalisés`, l'**agent de clôture** clôture la DT (RG5).

### 8.2 GERER LES DEMANDES

Procédure d'administration (rôle `ADMIN DT`) permettant de **mettre à jour les listes déroulantes** utilisées par le formulaire. États : `Nouveau` et `Modifié`. Elle comporte **5 opérations**, une par **liste** à mettre à jour, chacune associée à son **connecteur** :

| Opération                          | Liste mise à jour         |
| ---------------------------------- | ------------------------- |
| Mettre à jour les types de demande | Types de demande          |
| Mettre à jour les architectes      | Architectes               |
| Mettre à jour les départements     | Départements (directions) |
| Mettre à jour les lieux de RDV     | Lieux de rendez-vous      |
| Mettre à jour les secteurs         | Secteurs                  |

L'opération empruntée est déterminée **par JavaScript au clic** (pas par règles), selon la liste choisie (RG11).

{% hint style="danger" %}
**⚠️ À VALIDER** — définition exacte des **connecteurs** associés à chacune de ces 5 opérations (source et cible de chaque liste).
{% endhint %}

***

## 9. Cas particuliers & limites

* **Modélisation en cours.** Le passage par les fiches ateliers est encore partiellement finalisé (*« pour l'instant, les fiches ateliers, on passe outre »*) ; certaines étapes sont explicitement laissées *« pour le prochain qui prendra la suite sur la modélisation »*.
* **Deux opérations « planifier »** techniques (retour arrière vs validation + création des fiches) — voir §4.2.
* **JavaScript externalisé** : une partie de la logique (aiguillage, contrôles) est portée par du JS hors des règles du Designer.

***

## 10. Points à valider (récapitulatif)

Cette spec est issue d'un parcours oral du Designer. Restent à confirmer avec l'équipe / le modèle :

{% hint style="danger" %}
**⚠️ À VALIDER — récapitulatif**

**Bloquants pour l'implémentation (machine à états / aiguillage) :**

1. **Moment de création des fiches ateliers** (`Validé` vs après visa / `Planifié`) — risque de fiches créées pour une DT ensuite annulée par le visa.
2. **Sorties de workflow** de `Planifié partiellement` et des opérations optionnelles de `Planifié` (*Reprogrammer* / *Modifier* / *Clôturer* → `Clôturé` ?).
3. **Source de la donnée « responsable »** (RG1) : profil, annuaire, connecteur RH ?
4. Règle d'**affectation** planification / chef d'atelier (rôle + unité / atelier) et **résolution du destinataire** du mail (quel chef pour quel atelier).

**Libellés, rôles & formulaires :** 5. Libellés exacts des **états** — notamment `Modifié` (retour planification) vs `Modifié par le demandeur`, et l'état de **clôture** (`Clôturé` ?) — et des **opérations**. 6. Intitulés exacts des **rôles** `Chef d'atelier DT`, `Conducteur DT`, `Consultation DT` et des **agents** (envoi de mail, clôture). 7. **Conducteur** : même population que le demandeur au profil conducteur ? périmètre de **visibilité**. 8. Règle d'affectation du **second viseur** (≠ premier — RG3). 9. Correspondance **numéro ↔ usage** des **formulaires** et intitulés définitifs.

**Champs & procédures :** 10. Champs du pavé **`cariste`** et **inventaire exhaustif des champs** du formulaire demandeur (+ conditions d'affichage), et champs modifiables par la planification. 11. Comportement exact de **« Validez-vous toutes les planifications ? » = Oui**. 12. Définition des **connecteurs** de *GERER LES DEMANDES* (les 5 opérations sont identifiées : types de demande, architectes, départements, lieux de RDV, secteurs). 13. RG7 **bloquant ou avertissement** ? Condition de déclenchement du **mail** d'ajout de pièces jointes (RG9).
{% endhint %}

***

{% hint style="warning" %}
**Spécification générée à partir d'une transcription (Whisper) et de captures du Designer.** À relire et compléter par l'équipe projet avant diffusion. Le diagramme d'états complet (par couloir) et l'inventaire exhaustif des champs gagneraient à être ajoutés en annexe.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://documentation.efalia.com/specifique/musee-du-louvre/spec-demande-de-travaux.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.