VESICA
IQSYS_IQ_4Brouillon

SYS_IQ_4 — Émettre une notification

Instruction· Direction des Systèmes d'Information (DSI) — Système & Infrastructure IA· émetteur VESICA SYS_PRO_4

SYS_IQ_4 — Émettre une notification

Mode opératoire + embryon de catalogue : les règles de routage et la RÈGLE D'OR portent leur source_ref. [CORPUS]

Objet (la tâche)

Émettre une notification Mattermost depuis un workflow, en choisissant le bon event_type, en alignant le payload sur le template, et en respectant le mode de rendu (dédié ou passthrough). [CORPUS]

Prérequis / matériel / sécurité

  • event_type déclaré dans routage_notifs.json (sinon exception). [CORPUS]
  • Template correspondant présent dans /vault/_CONFIG/templates_notifs/. [CORPUS]
  • Pour notify_business : dossier_id + channel_id connus de l'appelant. [CORPUS]
  • Le bot jarfish-bot est membre/admin du canal cible (auto pour canaux qu'il crée). [CORPUS]
  • Pas de donnée sensible côté SYS ; attention au contenu mis dans payload (peut contenir de la donnée métier — responsabilité de l'appelant). [STANDARD]

Étapes d'exécution

  1. Choisir event_type selon la nature (cf. table de routage SYS_FQ_4). [CORPUS]
  2. Construire payload{} dont chaque clé correspond à un {{payload.xxx}} du template (RÈGLE D'OR). [CORPUS]
  3. Pour un payload dynamique/variable : préformater le corps markdown dans un nœud Code et l'émettre comme payload.corps → template default.md (passthrough, ADR-040). [CORPUS]
  4. Appeler notify_system (system) ou notify_business (business, + dossier_id/channel_id/agent_source?). [CORPUS]
  5. Vérifier success dans l'OUTPUT ; un échec de notif ne doit jamais casser le flux métier (cf. anti-récursion). [CORPUS]

Règles, critères et seuils (embryon de catalogue — routage notif)

  • N1 — RÈGLE D'OR : payload.X ↔ {{payload.X}} du template, documentés au même endroit. Clé manquante = trou silencieux. (source_ref: 07 §B2.6 ; CLAUDE.md) [CORPUS]
  • N2 — system → canaux permanents system-errors (severity error/warning) / system-activity (info) ; business → canal du dossier (channel_id fourni). (source_ref: 07 §B2.2) [CORPUS]
  • N3 — Deux modes de rendu : template dédié nom_event.md (forme fixe, masquage ligne-à-ligne du vide) ou passthrough default.md ({{payload.corps}} préformaté). (source_ref: ADR-040) [CORPUS]
  • N4 — channel_id toujours passé en expression (le dropdown Channel natif est buggé). (source_ref: 07 §B2.4) [CORPUS]
  • N5 — team_id bindé par expression .data (déroulant loadOptions inutilisable — P-6e-8). (source_ref: 07 §B2.5) [CORPUS]
  • N6 — Une chaîne de livraison de notif ne porte jamais error_handler (anti-récursion storm). (source_ref: ADR-034 ; P-6g-1) [CORPUS]
  • N7 — Severity par défaut prise du routage si non fournie ; surcharge possible top-level severity. (source_ref: 07 §B2.6) [CORPUS]
  • N8 — Création de canal dossier : le dossier parent doit exister dans registre_dossiers avant l'appel (FK CASCADE). (source_ref: 07 §B2.5) [CORPUS]
  • N9 — Convention message riche (filet ---, titre ####, horodatage Paris, liste imbriquée, masquage du vide) réutilisable pour tout passthrough. (source_ref: _CONFIG/templates_notifs/README.md ; ADR-040) [CORPUS]

Points de contrôle / cas particuliers

  • event_type invalide → exception (remontée error_handler côté appelant si configuré). [CORPUS]
  • Payload non aligné (sync_model_capabilities Notif succès) : duration/timestamp vides + nb_* ignorés → à corriger (P30 doublon 04). [CORPUS]
  • Double notif à la création de canal : message système « added by » + bienvenue (jugé acceptable, V1 à ré-évaluer en prod). [CORPUS]

Sortie / enregistrement produit

  • Message Mattermost posté + OUTPUT { success, channel_id, post_id, error }. [CORPUS]

Agent responsable

notify_system / notify_business — appelés par le workflow émetteur. [CORPUS]