---
title: "ISI Nova — Restitutions"
module: isi-nova
type: functional
status: active
updated: 2026-07-20
---

# ISI Nova — Restitutions

Module permettant aux consultants ISI-Groupe de produire des documents de
restitution (.docx/.pptx) à partir des réponses du Core Model d'un client,
assistés par IA, avec aller-retours de validation.

> **Statut :** MVP complet, workflow mapping/génération/révision refondu en
> wizard modale. Document maintenu à jour à chaque évolution du module.

## Vue d'ensemble

Le module Restitutions permet aux consultants ISI-Groupe de produire des
documents de restitution Word ou PowerPoint à partir des réponses
collectées dans le Core Model d'un client. Le processus s'appuie sur
l'intelligence artificielle pour générer le contenu narratif des
sections, tout en laissant au consultant la main pour valider, ajuster
ou re-personnaliser le document final.

Une **Restitution** regroupe :
- des **métadonnées** (titre, contexte, date du diagnostic, client cible) ;
- un ou plusieurs **documents modèles** uploadés par le consultant
  (.docx ou .pptx) qui définissent la structure du livrable attendu ;
- une fois la génération terminée, les **livrables** finaux téléchargeables.

Le module est exclusivement accessible aux membres du tenant ISI-Groupe,
selon les droits définis dans le module Core Model.

## Navigation

Le module Restitution est structuré autour d'un **workspace à 3
onglets**, accessible via `/mod/50100101/update/{idrestit}` (page generic-form,
même moteur que le reste de l'application) :

- **Infos** — Métadonnées de la Restitution (titre, client, contexte).
  Édition possible sauf pour le client (verrouillé après création).
- **Modèles** — badge affichant le nombre de documents modèles. Liste des
  documents modèles (tableau), avec pour chacun son format, son nombre de
  sections et son **statut de mapping** (Validé / À valider). Un bouton
  **« Ajouter un document modèle »** ouvre une **modale d'upload** (docx/pptx) ;
  après l'ajout, la modale de **mapping** s'enchaîne directement, et sa
  **validation ferme la modale** (retour à la liste, badge de mapping à jour).
  Chaque ligne offre un bouton **Mapper** dédié (associer chaque section à une
  dimension Core Model — le mapping est une propriété du modèle) et un **menu
  d'actions (⋮)** regroupant **Modifier** (changer le nom et la description du
  document), **Dupliquer** (créer une copie pour la générer avec un mapping
  différent) et **Supprimer**.
  La génération elle-même se pilote depuis l'onglet Livrables.
- **Livrables** — badge affichant le nombre de sections en attente de
  validation (prioritaire), sinon le nombre de livrables finalisés. Liste des
  **livrables produits** (générés par l'IA ou re-uploadés), avec téléchargement,
  remplacement manuel et suppression. Deux boutons de génération : **« Générer un
  livrable »** (choix d'**un** modèle) et **« Générer tout »** (génère en une
  fois les livrables de **tous** les modèles joints), plus un rappel **« Reprendre
  la révision (N) »** quand des sections attendent d'être validées.

**Deeplink** : l'onglet Modèles est accessible via l'ancre `#tab2`, l'onglet
Livrables via `#tab3` (ex. `/mod/50100101/update/{idrestit}#tab3`).

### Création d'une Restitution

Un client peut avoir **plusieurs Restitutions** (ex. un diagnostic par
an, ou par périmètre). La création se fait via une **modale**,
accessible depuis :

Le sous-onglet « Suivi clients » du Core Model : l'action ligne
ouvre une **modale de listing** des Restitutions du client
(« Restitutions (N) », ou « Créer Restitution » si le client n'en a
aucune), avec un bouton « Nouvelle Restitution » qui bascule sur la
modale de création.

À la validation, l'utilisateur est redirigé vers l'onglet
« Modèles » du workspace de la nouvelle Restitution.

## Workflow utilisateur

### Étape 1 — Créer une Restitution

Depuis « Suivi clients », le consultant ouvre la modale de listing du
client puis clique sur « Nouvelle Restitution » et renseigne :

- **Titre** (obligatoire)
- **Client cible** (obligatoire) — sélection dans la liste des clients
  d'ISI-Groupe
- **Date du diagnostic** (obligatoire)
- **Contexte** (optionnel) — note libre (éditeur enrichi, comme sur la fiche
  d'édition) pour décrire le périmètre

Une fois la Restitution enregistrée, le consultant peut y joindre un ou
plusieurs documents modèles (.docx ou .pptx, max 20 Mo par fichier) via
le bouton **« Ajouter un document modèle »** (onglet Modèles), qui
ouvre une **modale d'upload**. Le **nom du template est facultatif** : s'il
est laissé vide, le nom du fichier (sans extension) est utilisé par défaut.
À l'upload, le module détecte automatiquement les **sections** du document :

- Pour un fichier Word : chaque style **Heading 1 à 6** devient une
  section.
- Pour une présentation PowerPoint : chaque **slide** devient une section.

> Après l'ajout, le compteur de modèles (badge de l'onglet **et** de la sidebar)
> se met à jour immédiatement, **sans rechargement de la page**. Il en va de même
> à la suppression ou à la duplication d'un modèle, et à l'ajout/suppression d'un
> livrable — les badges reflètent le changement en direct.
- Si le document Word ne contient pas de styles Heading, le module
  propose automatiquement un découpage sémantique généré par IA. Le
  consultant n'a rien de spécial à faire — le résultat est identique
  visuellement.

Les sections détectées peuvent contenir les marqueurs `[ISI_PRATIQUE]` et
`[ITIL_PRATIQUE]` — ils seront remplacés par les bonnes pratiques
correspondantes lors de la génération IA (étape Génération du wizard,
cf. étape 2).

#### Mapper un modèle depuis l'onglet Modèles

Le **mapping** (association de chaque section à une dimension Core Model) est une
propriété du **modèle**. On peut le faire/le corriger directement depuis l'onglet
Modèles via l'action **« Mapper »** d'une ligne (même écran que l'étape Mapping du
wizard, cf. étape 2), sans lancer de génération. Le badge « Mapping » de la ligne
passe alors à « Validé ». Le wizard de génération réutilise ce mapping et saute son
étape mapping si le modèle est déjà validé.

#### Plusieurs livrables d'un même modèle (mappings différents)

Le principe « **un livrable = un modèle** » implique qu'un modèle ne produit qu'un
livrable à la fois. Pour générer **plusieurs livrables d'un même document avec des
mappings différents**, on **duplique** le modèle (action **« Dupliquer »** de
l'onglet Modèles) : la copie reprend le fichier, le nom, la description et le mapping
de l'original comme point de départ. La duplication ouvre alors, en séquence : d'abord
la fenêtre **d'édition** (nom / description **pré-remplis**, à ajuster pour distinguer
la copie), puis, à la validation, la fenêtre de **mapping** pour adapter l'association
des sections. Chaque copie est un modèle indépendant → son propre mapping et son propre
livrable, coexistant avec l'original.

### Étape 2 — Générer un livrable : le wizard

Depuis l'onglet **Livrables**, le bouton **« Générer un livrable »** ouvre un
**wizard en modale** qui déroule 4 étapes, **un livrable = un modèle** :

1. **Choix du modèle** — le consultant sélectionne le document modèle à partir
   duquel générer le livrable (parmi ceux uploadés dans l'onglet Modèles). Un
   badge indique si le mapping du modèle est déjà validé.
2. **Mapping** — confirmation/correction des dimensions Core Model par section
   (sauté si le mapping du modèle est déjà validé).
3. **Résumé** — récapitulatif avant lancement : nombre de sections à générer et
   **estimation du nombre de tokens**.
4. **Génération** — traitement IA en arrière-plan avec barre de progression.

Le bouton « Générer un livrable » est désactivé tant qu'aucun modèle n'a été
ajouté (un message invite alors à en créer un dans l'onglet Modèles).

> **Adaptation au format du modèle.** L'IA calibre automatiquement le contenu
> selon le format du document modèle : un modèle **PowerPoint** produit une
> synthèse en **puces courtes** (une idée par puce, l'essentiel par slide),
> tandis qu'un modèle **Word** produit une rédaction **narrative** en
> paragraphes. Un même contenu Core Model donne donc un rendu plus dense en
> Word et plus synthétique en PowerPoint.
>
> **PowerPoint — sections longues.** Si une section dépasse ce qu'une seule
> diapositive peut afficher, elle est automatiquement **répartie sur plusieurs
> diapositives** : la première garde le titre, les suivantes indiquent
> « Titre (2/3) », « Titre (3/3) »… Le texte reste ainsi lisible sans
> débordement.

#### Générer tout (tous les modèles d'un coup)

Le bouton **« Générer tout »** ouvre le même wizard mais cible **tous** les
documents modèles de la Restitution. Il **saute le choix du modèle** et enchaîne :

1. **Mapping séquentiel** — les modèles dont le mapping n'est pas encore validé
   sont présentés **un par un** (indicateur « Document X sur N ») ; ceux déjà
   validés sont ignorés. Si tous sont déjà mappés, cette étape est sautée.
2. **Résumé** — nombre total de sections à générer et estimation de tokens
   **agrégés** sur tous les modèles.
3. **Génération** — toutes les sections de tous les modèles sont générées dans un
   **seul traitement parallèle** en arrière-plan.

À la fin, l'écran de révision s'ouvre sur **tous** les modèles ; le livrable de
chaque modèle est produit automatiquement dès que ses sections sont validées.

#### Étape Mapping (dans le wizard)

Avant de pouvoir lancer la génération IA, chaque document doit avoir
un **mapping validé** : pour chaque section, le consultant confirme
(ou corrige) la dimension Core Model à laquelle elle se rapporte.

1. **Premier passage** : le consultant clique sur « Proposer le
   mapping ». L'IA analyse les titres et contenus de chaque section,
   et propose une dimension parmi celles disponibles. Chaque
   proposition est accompagnée d'un score de confiance (en couleur :
   vert ≥ 80%, amber 50-79%, rouge < 50%) et d'une justification en
   langage naturel (accessible au clic sur le badge de confiance).

2. **Corrections** : pour chaque section, le consultant peut changer
   la dimension proposée via un sélecteur, ou la laisser tel quel.

3. **Validation** : une fois satisfait, le consultant clique sur
   « Valider le mapping ». Toutes les sections passent en état validé
   en bloc, et le wizard passe à l'étape Résumé.

> **Cas particulier — Re-mapping :** si le consultant veut relancer la
> proposition IA sur un document déjà mappé, un dialogue de
> confirmation apparaît avant — la nouvelle proposition écrasera
> toutes les corrections existantes.

> **Cas particulier — Sections mal mappées :** un score de confiance
> rouge (< 50%) signale une section où l'IA hésite. Le consultant
> doit y prêter une attention particulière et corriger si nécessaire.

#### Étape Résumé (dans le wizard)

Avant de lancer la génération, le wizard affiche un récapitulatif : le
**nombre de sections** qui seront générées et une **estimation grossière du
nombre de tokens** (basée sur les titres de section + un overhead constant ; la
consommation réelle peut être supérieure). Le bouton **« Lancer la génération »**
démarre le traitement.

#### Étape Génération (dans le wizard)

Le traitement IA des sections se fait en arrière-plan.

Pendant la génération, le wizard affiche une barre de progression
(« 23 / 50 sections générées ») qui se rafraîchit automatiquement.
Le consultant peut **fermer le wizard à tout moment** : la génération
continue en arrière-plan, et relancer « Générer un livrable » sur le même
modèle plus tard reprend au bon endroit (l'état réel est réévalué à chaque
ouverture — rien n'est perdu).

Une seule génération peut être active à la fois pour une Restitution
donnée ; tenter d'en lancer une seconde affiche un message d'attente.

**Reprise après échec :** le système REPREND uniquement les sections
non encore générées (pending ou failed) ; les sections déjà générées
sont conservées. Pour régénérer une section déjà générée, le
consultant passe par l'écran de révision.

Une fois la génération terminée, un bouton **« Voir les résultats »**
ouvre l'écran de révision (en remplaçant le wizard).

### Étape 3 — Réviser et valider le contenu

L'écran de révision s'ouvre en **modale**, soit depuis le wizard
(bouton « Voir les résultats »), soit depuis le rappel **« Reprendre la
révision »** de l'onglet Livrables (qui rouvre la révision sur toute la
Restitution).

Il présente une **vue en 2 colonnes** :

- **Colonne gauche — Sommaire** : le ou les documents concernés (le modèle
  qui vient d'être généré depuis le wizard, ou tous les documents si l'on
  reprend la révision globale), expandables, listant leurs sections. Chaque
  section porte un badge coloré et une bordure indiquant son statut :
  - **Bleu — Générée** : le contenu IA est prêt à être relu.
  - **Vert — Validée** : le contenu est figé pour le livrable final.
  - **Rouge — Échec** : la génération a échoué et doit être relancée.
  - **Amber — En cours** : une régénération est en cours.

- **Colonne droite — Détail** : le titre et le contenu HTML de la
  section sélectionnée, avec les actions disponibles.

**Pour une section générée**, trois actions sont disponibles :

1. **Modifier** : ouvre l'éditeur WYSIWYG (RichEditor) pour retoucher
   manuellement le contenu. À la sauvegarde, la section est marquée
   "Éditée".
2. **Régénérer** : ouvre une modale avec un champ optionnel pour une
   consigne (« raccourcis ce passage », « rajoute un exemple »…).
   L'IA régénère la section en arrière-plan avec le contexte Core
   Model. Si la section a été éditée manuellement, une confirmation
   prévient avant l'écrasement.
3. **Valider** : fige le contenu de la section (snapshot). Une section
   validée n'est plus modifiable tant qu'on n'annule pas la
   validation.

**Pour une section en échec**, un bouton « Relancer cette section »
permet de retenter la génération sans avoir à relancer toute la
Restitution.

**Bouton global « Valider toutes »** : en haut de page, valide en bloc
toutes les sections au statut "Générée" (les "Échec" et "Validée" déjà
sont ignorées). Confirmation avant exécution. Une fois la validation faite,
l'écran de révision **se ferme automatiquement** et la liste des livrables se
recharge pour faire apparaître les livrables produits.

**Pendant qu'une régénération est en cours**, le contenu de la section
est masqué et un indicateur visuel signale l'attente. La page se
rafraîchit automatiquement toutes les 5 secondes.

> À la **fermeture** de l'écran de révision (bouton « Fermer »), la liste des
> livrables se rafraîchit pour refléter les documents produits.

> **Note sur les retouches fines dans l'éditeur** : RichEditor intègre
> aussi un assistant IA natif (`doctechsi`) accessible dans la toolbar
> pour de petites corrections ponctuelles (reformuler une phrase,
> corriger une tournure). Cet assistant travaille au niveau du texte
> sélectionné, sans contexte Core Model — contrairement au bouton
> "Régénérer" qui re-rédige toute la section avec le contexte complet.

### Étape 4 — Télécharger le livrable

Le livrable final est **généré automatiquement**, sans action manuelle :
dès que toutes les sections d'un document (hors échecs) sont validées,
le rendu se déclenche en arrière-plan. Dès que le fichier est prêt (quelques
secondes), il **apparaît tout seul dans la liste des livrables** — la table et le
compteur « Livrables » (badge onglet + sidebar) se mettent à jour **sans
rechargement de page** — avec un bouton **« Télécharger »**.

> Si un rendu **échoue**, une alerte s'affiche en tête de l'onglet Livrables
> (« N livrable(s) n'ont pas pu être générés ») ; revalider les sections du modèle
> concerné relance le rendu.

Le livrable reste consultable/téléchargeable à tout moment depuis cet onglet.
Un bouton **« Remplacer par un upload manuel »** permet de remplacer le fichier
généré par une version corrigée à la main (.docx ou .pptx selon le format du
document, max 50 MB) — filet de rattrapage pour les cas où le rendu automatique
ne convient pas. Un livrable peut aussi y être **supprimé** (le modèle source et
ses sections sont conservés).

> Le remplacement manuel et la suppression d'un livrable mettent à jour le
> compteur de livrables (badge onglet + sidebar) en direct, sans rechargement.

**Principe de rendu** : les deux formats réutilisent le document
modèle uploadé en étape 1 comme **châssis**. La mise en forme, la
charte, les en-têtes/pieds-de-page et le slideMaster/layouts/theme
sont conservés. Seul le contenu est remplacé par les sections
générées par l'IA.

> **Point d'attention** : si une section est dévalidée puis recorrigée
> après qu'un livrable a déjà été généré, celui-ci n'est **pas**
> régénéré automatiquement — il faut revalider les sections pour
> déclencher un nouveau rendu.

**Limitations MVP** :
- **Images dans .pptx** : préservées dans le rendu .docx mais
  remplacées par une mention textuelle « [Image: nom_du_fichier] »
  dans le rendu .pptx.
- **Sections en échec** : ignorées dans le rendu avec mention discrète
  « [Section non disponible — à compléter manuellement] ».
- **Préservation lossy du template .docx** : certaines features Word
  avancées (SmartArt complexe, macros, certains champs liés) peuvent
  être perdues au round-trip PHPWord. La charte de base (styles,
  en-têtes/pieds, fonts) est préservée.

### Suppression d'une Restitution

Le bouton « Archiver » de la sidebar (commun à tout module de
l'application) supprime **définitivement** une Restitution — malgré son
libellé, il n'y a pas d'archive réversible sur ce module. La suppression est
**IRRÉVERSIBLE** :
- Toutes les sections, jobs, deliverables supprimés en BDD.
- Tous les fichiers physiques (templates et livrables) supprimés du
  disque.

Un dialogue de confirmation prévient avant l'action.

## Prérequis utilisateur

- Être membre du tenant **ISI-Groupe** (le module est invisible aux autres
  tenants).
- Disposer des droits adéquats (lecture, création, édition, suppression) sur
  le module Restitution.
- Le **client cible** doit exister dans ISI-Groupe ; idéalement il a déjà
  renseigné son Core Model — sinon la génération IA produit un contenu moins
  riche.