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.
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 :
Le module est exclusivement accessible aux membres du tenant ISI-Groupe, selon les droits définis dans le module Core Model.
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) :
Deeplink : l'onglet Modèles est accessible via l'ancre #tab2, l'onglet
Livrables via #tab3 (ex. /mod/50100101/update/{idrestit}#tab3).
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.
Depuis « Suivi clients », le consultant ouvre la modale de listing du client puis clique sur « Nouvelle Restitution » et renseigne :
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 :
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).
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é.
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.
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 :
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.
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 :
À 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.
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.
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).
Corrections : pour chaque section, le consultant peut changer la dimension proposée via un sélecteur, ou la laisser tel quel.
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.
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.
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).
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 :
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 :
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.
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 :
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 :
Un dialogue de confirmation prévient avant l'action.