Hub IT / ITSM

Objectif et carte du hub

Le Hub IT est le centre opérationnel IT selon le référentiel ITIL. Depuis ce hub, vous accédez à la console opérationnelle du service desk et du NOC, à la gestion des incidents, demandes, problems et changes, à la Knowledge Base, aux tableaux de bord et au reporting. C’est l’outil quotidien des opérateurs (L1/L2/L3), des chefs d’équipe et des managers IT, et le point d’accès aux vues de direction des services.

Cette page est organisée en fiches : d’abord les pages du hub (la page d’accueil, la console opérationnelle, Change, Problem, Major Incident, Knowledge Base, Voicemail), puis les modales transverses utilisées sur les tickets (Éditeur, Composer, Inspector, Taxonomies, Notes internes, Pièces jointes, Liens, Actions de masse, Playbooks, KB, Dashboard, Contrôle qualité, Données historiques). Les pages ITOM, Events&AIOps, Operations Cockpit, IT Report Center et Customer Service sont mentionnées ici mais décrites dans leurs pages respectives.

Page d’accueil du Hub IT

À quoi elle sert. C’est la page d’entrée du hub : elle présente les actions rapides du hub et les encadrés (tiles) vers les pages opérationnelles, de direction et de reporting.

Quand l’utiliser. Au début de la session IT, pour choisir la zone sur laquelle travailler, ou pour lancer les actions transverses (KB, CMDB, Contrôle qualité, Taxonomies).

Comment l’ouvrir. Depuis la Home de Core (encadré IT Hub) ou depuis la barre d’outils « IT Hub » présente sur les pages du hub.

Ce qu’elle affiche. En en-tête, une hero strip avec le titre « IT Hub — Centre opérationnel IT · Network Operations · Service Desk · Operations & ITSM » et les actions rapides du hub :

Knowledge Base — ouvre la KB du domaine IT.
CMDB / Assets — ouvre la CMDB centralisée.
Données historiques — ouvre la modale des données archivées (cold store) ; nécessite un client sélectionné (voir Données historiques).
Contrôle qualité — visible pour les rôles habilités ; ouvre la revue qualité des tickets clôturés (voir Contrôle qualité).
Taxonomies — visible pour les administrateurs ; ouvre la modale Taxonomies des tickets (Taxonomies des tickets).

En dessous, les encadrés sont regroupés en trois sections :

Opérations (CORE) — trois encadrés principaux :

NOC · Network Operations — file opérationnelle avec filtre de tier L1/L2/L3 : supervision, tri, investigation, escalade.
Service Desk · Assistance & demandes — file du service desk avec filtre de tier L1/L2/L3 : tri, réinitialisations, incident/problem, catalogue. (Le domaine interne reste OPS.)
Customer Service · groupes par client — tickets CS-* sur les groupes dédiés du client (Customer Service, Enterprise Service et ICC).

Direction des services — trois cockpits (visibles pour les rôles manager/directeur, *:MGR) :

NOC Service Director — P1/War Room en direct, SLA par client, couverture des équipes, escalades, broadcast team.
Service Desk Director — FCR, AHT, volumes par canal, CSAT, temps d’attente en file, performance des analystes.
Customer Service Director — direction de la ligne client sur les groupes par client.

Outils opérationnels & Reporting — encadrés compacts : ITOM, Events & AIOps, Problem Management, Change Management, IT Operations Dashboard, IT Report Center, Voicemail.

Chaque encadré affiche une icône, un badge d’état (LIVE/NEW/…) et une ligne de features (les tags des fonctions principales). En bas de la page se trouve le bottom dock unifié avec softphone, chat et présence.

Comment l’utiliser. Vous cliquez sur l’encadré de la zone souhaitée ; les actions rapides de l’en-tête ouvrent les modales/pages correspondantes. Les encadrés et les actions visibles dépendent du rôle (RBAC) : la page d’accueil filtre les tiles selon les profils d’accès de l’utilisateur et le tier requis.

Ce qui se passe ensuite. La navigation mène à la page/console choisie ; l’état de la session (client/tenant courant) est propagé aux pages de destination.

Remarques. Les KPI du hub ont été volontairement retirés de la page d’accueil : avec la vue multi-tenant, ils ne seraient pas significatifs ; les métriques se trouvent sur les pages dédiées (console NOC, tableau de bord SLA, cockpits).

Console opérationnelle L1/L2/L3 (NOC et Service Desk)

À quoi elle sert. C’est la console de traitement des tickets en file, partagée par le NOC et le Service Desk grâce au même moteur de disposition. Elle permet de surveiller la file, de sélectionner un ticket, d’en voir le détail et d’agir avec des actions rapides et des outils de contexte. Un seul écran couvre les trois niveaux (L1/L2/L3) grâce au filtre de tier.

Quand l’utiliser. C’est le poste de travail de l’opérateur pour toute la journée : prise en charge, diagnostic, escalade, résolution.

Comment l’ouvrir. Depuis la page d’accueil de l’IT Hub, encadrés NOC ou Service Desk. La console Problem (Problem Management Console) utilise la même disposition.

Ce qu’elle affiche. Une disposition à trois panneaux :

File (gauche) — la liste des tickets, avec :
- des filtres rapides : Tous, P1/P2, Les miens, Unassigned, + L2/L3 ;
- une recherche par clé, objet ou CI ;
- une actualisation automatique toutes les 60 secondes (avec l’heure de la dernière actualisation et un compteur).
Détail (centre) — le ticket sélectionné avec toutes ses données ; de là, vous ouvrez l’Éditeur (Éditeur de ticket) et les actions.
Outils (droite) — des onglets de contexte qui changent selon le tier.

En haut, une bande de KPI. Pour le NOC L1 : Tickets ouverts, P1/P2 actifs, SLA dépassés, MTTR (min), Résolus aujourd’hui.

Les actions rapides (L1) : Prendre en charge (me l’assigner), Escalate L2/L3 (équipe GRP-NOC_L2), Résoudre, Ouvrir un Major Incident (escalade MIM). Les outils L1 : CI liés (CMDB explorer), Runbook (KB NOC L1, Playbook incident), Supervision (Grafana, Alertmanager), Minuteur SLA (temps restant), Dashboard (ouvre le tableau de bord des KPI dans une modale).

Lors du passage au tier L2, les KPI, les actions et les outils changent : KPI Incidents ouverts, P1/P2 ouverts, Change window, MTTR, Root-cause pending ; actions Take ownership, Escalate L3, Lancer la RCA (5-why + chronologie), Ouvrir un change (RFC → CAB), Escalate MIM ; outils RCA workspace (constructeur de chronologie, modèle 5-why), Change mgmt (calendrier du CAB, nouvelle RFC), Runbook L2/L3.

En bas, les liens vers Service Topology et ITOM Health, et le bottom dock avec softphone (SIP), chat et présence.

Comment l’utiliser. Vous filtrez et cherchez dans la file, sélectionnez un ticket (détail au centre), agissez avec les actions rapides ou ouvrez l’Éditeur pour le traitement complet ; les outils de droite donnent accès à la CMDB, aux runbooks, à la supervision et aux SLA. Les sélections multiples activent les actions de masse (Actions de masse).

Ce qui se passe ensuite. « Prendre en charge » assigne le ticket à l’opérateur ; « Escalate » le transfère à l’équipe de niveau supérieur ; « Résoudre » le clôture ; « Ouvrir un Major Incident » lance le workbench MIM (Major Incident Workbench). Chaque action met à jour la file, les KPI, la chronologie et les notifications.

Remarques. Le filtre de tier et les matrices d’escalade, les noms des équipes (GRP-NOC_*, GRP-OPS-*) et les files sont gérés de manière centralisée ; l’actualisation automatique maintient la file à jour sans recharger la page.

Éditeur de ticket

C’est la fenêtre la plus utilisée de tout exoCortex Core : nous la décrivons en deux sections.

À quoi elle sert, quand et comment l’ouvrir

À quoi elle sert. L’Éditeur de ticket est le panneau (tiroir) de traitement d’un ticket : il permet d’en lire toutes les données, de changer son état (transitions de workflow), de modifier ses champs, de commenter, de gérer les pièces jointes et les notes internes, de consulter les SLA, la chronologie, les tickets liés et la piste d’audit.

Quand l’utiliser. Chaque fois que vous prenez en charge ou mettez à jour un ticket : prise en charge, mise à jour de l’avancement, demande d’informations, résolution, clôture.

Comment l’ouvrir. En cliquant sur un ticket dans n’importe quelle liste (console opérationnelle, files, résultats de recherche, widgets), ou avec le raccourci ⌘O (Ctrl+O) qui ouvre un sélecteur où saisir la clé du ticket.

Caractéristique distinctive — multi-tickets. L’Éditeur gère jusqu’à 6 tickets ouverts simultanément, chacun dans son propre onglet en haut. Vous passez d’un ticket à l’autre d’un clic ou avec ⌘Tab. Un onglet contenant des modifications non enregistrées affiche l’indicateur « modifié » (dirty). Chaque ticket se ferme avec le « x » de son onglet.

Modes d’affichage. Le tiroir prend en charge trois modes : ancré sur le côté (side-by-side), plein écran (focus) et réduit en vignette (PIP) en bas. Échap réduit le tiroir (collapse) sans en perdre le contenu.

Ce qu’elle affiche : barre d’état et onglets internes

Sous les onglets des tickets, une barre d’état présente les attributs clés et les contrôles rapides : état courant et boutons de transition (confirmation ⌘↵) ; priorité (Highest/High/Medium/Low/Lowest) ; assigné (contrôle « Assigner » qui ouvre le sélecteur d’utilisateur) ; indicateurs de file/équipe, type et clé.

Le corps est organisé en onglets internes :

Détail — les champs du ticket : objet, description (texte brut), priorité et les champs personnalisés (custom fields) de l’issue type, chargés depuis le catalogue et modifiables avec les autres. Vous enregistrez avec ⌘S.
Chronologie — l’historique des événements (création, transitions, commentaires, modifications).
Commentaires — l’historique des commentaires (auteur, date), rendu en Markdown, avec la zone de saisie et le bouton Envoyer le commentaire (actif uniquement s’il y a un brouillon).
SLA — les SLA associés avec un compte à rebours « en direct ».
Linked — les objets liés (tickets, appels, chats, liens) avec date et origine ; vous les ajoutez avec le Link Picker (Lier des tickets).
Pièces jointes — la liste des fichiers avec Afficher, Télécharger, Supprimer et l’ajout de fichiers ; les pièces jointes sont immuables (pour « modifier », vous supprimez puis rechargez).
Notes internes — annotations réservées à l’équipe (Notes internes).
Audit — la chronologie du cycle de vie.
Postmortem — la fiche de post-incident review, pour les types qui la prévoient (Major Incident, SOC Incident).

Quand le ticket concerne un CI/hôte, la Console PAM est disponible (accès privilégié zero-knowledge au système).

Comment l’utiliser et ce qui se passe ensuite

Changer d’état : vous choisissez la transition ; le workflow avance, la chronologie enregistre l’événement et les notifications et automatisations se déclenchent (assignations, SLA, escalades).
Modifier les champs : vous modifiez dans l’onglet Détail et enregistrez avec ⌘S ; les modifications sont envoyées en bloc. La description et les commentaires sont en texte brut (source unique) : ce que vous écrivez est ce qui est enregistré et relu.
Commenter : vous écrivez dans l’onglet Commentaires et envoyez ; le commentaire entre dans l’historique et génère des notifications selon la matrice de notification.
Gérer les pièces jointes / assigner : depuis les onglets/contrôles correspondants.

Raccourcis : ⌘O ouvrir le sélecteur · ⌘S enregistrer · ⌘↵ transition · Échap réduire · ⌘Tab ticket suivant.

Remarques. Les actions disponibles (transitions, modification des champs, suppression des pièces jointes, visibilité des notes internes) dépendent des permissions du rôle. L’onglet Postmortem n’apparaît que pour les types qui le prévoient.

Composer, création de ticket

À quoi elle sert. C’est la fenêtre de création d’un nouveau ticket par l’opérateur (pour le compte d’un utilisateur/client ou suite à un appel/chat).

Quand l’utiliser. À l’ouverture d’un nouveau cas : appel au service desk, demande par chat, signalement à surveiller, création manuelle d’un incident/d’une demande/d’un change.

Comment l’ouvrir. Depuis le bouton de création des listes/cockpits ou avec Ctrl+N. Le contexte peut être hérité d’un chat ou d’un appel en cours : demandeur, objet, description, CI, pièces jointes, incident lié, type.

Ce qu’elle affiche. Une modale centrée (avec un mode focus plein écran et un PIP en bas à gauche), en trois étapes à affichage progressif :

Identify — projet/tenant de destination, canal, demandeur (reporter).
Classify — type de ticket (issue type) et domaine (menu filtré selon la section du domaine), priorité et catégorie.
Detail — objet, description, champs spécifiques, pièces jointes, éventuelle note interne initiale.

Chaque étape a un indicateur d’état (à faire/en cours/terminée). À côté, le panneau AI Copilot : suggestion de titre, proposition de priorité, catégorisation, détection des doublons, articles de KB et runbooks pertinents.

Comment l’utiliser. Vous remplissez les trois étapes (le type détermine les champs obligatoires — Demandes de service). Multi-brouillons : jusqu’à 5 brouillons ouverts, conservés côté serveur et en local, avec enregistrement automatique toutes les 3 secondes. Envoi avec Ctrl+Enter ou depuis le bouton : le ticket est créé ; l’éventuelle note interne initiale est ajoutée juste après. Raccourcis : Ctrl+N nouveau brouillon · Ctrl+S enregistrer · Ctrl+Enter envoyer · Échap réduire.

Ce qui se passe ensuite. Le ticket entre dans le workflow de son type, est routé vers la file/l’équipe compétente selon les règles de routage du domaine, et les notifications sont générées. Le ticket peut être ouvert immédiatement dans l’Éditeur (Éditeur de ticket).

Remarques. Le tenant de destination doit être concret : les valeurs génériques (*, __ALL__) sont refusées. Si aucun domaine n’est indiqué, aucun type par défaut n’est imposé.

Aperçu du ticket

À quoi elle sert. Elle affiche un ticket en lecture seule avec aperçu, impression et export, sans l’ouvrir en modification.

Quand l’utiliser. Pour une consultation rapide, pour imprimer ou pour copier le lien d’un ticket à partager.

Comment l’ouvrir. Depuis les listes et les widgets, avec l’action d’aperçu.

Ce qu’elle affiche. Les données du ticket et les commentaires : objet, demandeur, état, priorité, description et historique des commentaires.

Comment l’utiliser. Boutons d’impression/export et Copier le lien.

Ce qui se passe ensuite. Aucune modification des données (lecture seule). Pour intervenir, vous passez à l’Éditeur.

Remarques. Les commentaires sont facultatifs (s’il n’y en a pas, la vue reste valide).

Taxonomies des tickets

À quoi elle sert. Elle définit les catégories et sous-catégories de service utilisées par le Composer pour classer les tickets. C’est l’outil de configuration de la taxonomie globale.

Quand l’utiliser. Quand l’administrateur doit créer/modifier les catégories de classement des tickets.

Comment l’ouvrir. Depuis l’action Taxonomies dans le bandeau de la page d’accueil IT (visible pour les administrateurs).

Ce qu’elle affiche. L’arborescence globale Category/Subcategory avec les entrées existantes et les contrôles de création/modification/suppression.

Comment l’utiliser. Vous ajoutez ou modifiez des catégories et des sous-catégories ; elles alimentent le sélecteur « Type/Catégorie » du Composer (Composer, création de ticket) et servent au routage et au reporting.

Ce qui se passe ensuite. Les modifications deviennent disponibles dans le Composer et dans les outils de classement ; les taxonomies constituent une source unique.

Remarques. C’est une fonction d’administration.

Notes internes

À quoi elle sert. Elle gère les annotations réservées à l’équipe sur un ticket, invisibles pour le demandeur.

Quand l’utiliser. Pour noter des informations de traitement, des hypothèses, des contacts ou des détails sensibles qui ne doivent pas apparaître dans la communication avec l’utilisateur.

Comment l’ouvrir. Depuis l’onglet Notes internes de l’Éditeur (Éditeur de ticket).

Ce qu’elle affiche. La liste des notes internes du ticket avec auteur et date, et la zone de saisie d’une nouvelle note.

Comment l’utiliser. Vous ajoutez une note ; elle reste visible uniquement pour les opérateurs/équipes autorisés.

Ce qui se passe ensuite. La note est enregistrée sur le ticket (canal distinct des commentaires publics) et contribue à la traçabilité interne.

Remarques. La visibilité des notes internes dépend des permissions du rôle.

Visionneuse de pièces jointes

À quoi elle sert. Elle permet d’afficher, imprimer et télécharger les pièces jointes d’un ticket sans avoir à les télécharger localement pour les ouvrir.

Quand l’utiliser. Pour examiner un fichier joint (image, PDF, log) pendant le traitement.

Comment l’ouvrir. Depuis l’action Afficher de l’onglet Pièces jointes de l’Éditeur, ou depuis les endroits où une pièce jointe est affichée.

Ce qu’elle affiche. L’aperçu du fichier avec les commandes d’impression et de téléchargement.

Comment l’utiliser. Vous ouvrez la pièce jointe, la consultez, et éventuellement l’imprimez ou la téléchargez.

Ce qui se passe ensuite. Aucune modification du fichier (les pièces jointes sont immuables).

Remarques. Pour « modifier » une pièce jointe, vous la supprimez et chargez une nouvelle version.

Lier des tickets

À quoi elle sert. Elle crée un lien entre tickets (relation typée : ex. « duplique », « bloque », « lié »).

Quand l’utiliser. Pour relier un ticket à d’autres (incidents liés au même problem, demandes en double, dépendances).

Comment l’ouvrir. Depuis l’onglet Linked de l’Éditeur.

Ce qu’elle affiche. Le type de lien et un champ de recherche du ticket de destination (le ticket source est exclu pour éviter les liens vers lui-même) et un commentaire facultatif.

Comment l’utiliser. Vous choisissez le type, cherchez et sélectionnez le ticket de destination, puis confirmez.

Ce qui se passe ensuite. Le lien est créé et l’onglet Linked du ticket se recharge en affichant la nouvelle relation.

Remarques. Le catalogue des types de liens est une source unique ; le lien d’un ticket vers lui-même est empêché.

Actions de masse

À quoi elle sert. Elle exécute des actions sur plusieurs tickets sélectionnés en une seule fois : clôture de masse et escalade de masse.

Quand l’utiliser. Pour traiter en bloc plusieurs tickets homogènes (ex. clôturer une série d’alertes résorbées, ou escalader un groupe de tickets vers la même équipe).

Comment l’ouvrir. En sélectionnant plusieurs tickets dans la file/liste et en choisissant l’action de masse.

Ce qu’elle affiche. La liste des tickets sélectionnés, le choix de l’action (clôturer/escalader), et les paramètres requis (résolution pour la clôture, équipe de destination pour l’escalade — fournis par le contexte, non codés en dur).

Comment l’utiliser. Vous confirmez l’action : clôturer clôture les tickets sélectionnés, escalader les fait passer au niveau supérieur. Une sélection valide est requise.

Ce qui se passe ensuite. Les tickets sont mis à jour en bloc ; la file et les KPI se rechargent ; chaque modification est enregistrée dans l’audit.

Remarques. Les résolutions et les équipes disponibles proviennent de la configuration du tenant.

Playbook launcher

À quoi elle sert. Elle liste et exécute les playbooks/runbooks applicables au contexte de la page ou du ticket.

Quand l’utiliser. Pour appliquer une procédure standardisée (diagnostic, remédiation, communication) à un incident ou à un CI.

Comment l’ouvrir. Depuis l’action rapide Playbook des pages de gestion ou depuis l’icône enregistrée dans le bottom dock.

Ce qu’elle affiche. Les playbooks applicables, filtrés par domaine et par tag et activés pour le tenant, avec la possibilité de fournir des entrées de contexte (ex. CI concerné).

Comment l’utiliser. Vous choisissez un playbook et l’exécutez en Dry-run (simulation) ou avec Exécuter (exécution réelle), en réutilisant l’API des playbooks.

Ce qui se passe ensuite. L’exécution produit ses effets (actions automatiques, mises à jour du ticket/CI) et en enregistre le résultat.

Remarques. Le tenant est celui de la session et ne se saisit pas à la main ; les actions sensibles sont protégées par des barrières.

Knowledge Base

À quoi elle sert. Elle recherche et affiche les articles de la Knowledge Base directement pendant le traitement, pour une résolution rapide et la KB-deflection.

Quand l’utiliser. Pendant le tri/diagnostic, pour trouver une procédure ou un article utile sans quitter la page.

Comment l’ouvrir. Depuis l’action rapide KB des outils de la console opérationnelle, ou depuis les endroits qui intègrent la recherche dans la KB.

Ce qu’elle affiche. Un champ de recherche et la liste des résultats ; en sélectionnant un article, la vue de l’article avec titre, métadonnées et corps.

Comment l’utiliser. Vous saisissez une requête et lancez la recherche ; vous ouvrez l’article et le consultez ; vous revenez à la liste avec « retour ».

Ce qui se passe ensuite. L’article peut résoudre le cas (deflection) ou fournir les étapes à suivre ; la KB alimente aussi les suggestions de l’AI Copilot du Composer.

Remarques. L’endpoint de recherche est canonique ; la KB complète se gère sur la page dédiée (Knowledge Base).

Dashboard KPI

À quoi elle sert. Elle ouvre en superposition un tableau de bord éditorial de KPI, sans ouvrir de page séparée.

Quand l’utiliser. Pour consulter rapidement les KPI d’une zone (ex. NOC L1 Monitoring) tout en travaillant sur la console.

Comment l’ouvrir. Depuis l’action rapide Ouvrir le Dashboard KPI des outils de la console.

Ce qu’elle affiche. Le rapport éditorial généré à partir des données réelles : KPI, tendances, ventilations.

Comment l’utiliser. Vous l’ouvrez et consultez les graphiques et les valeurs ; il remplace les anciens tableaux de bord séparés.

Ce qui se passe ensuite. Aucune modification des données (lecture seule) ; la fermeture vous ramène à la console.

Remarques. Si le runtime du rapport n’est pas disponible, la modale échoue de manière explicite (fail-loud), sans données factices.

Change Management

À quoi elle sert. Elle pilote le cycle de vie des changes d’infrastructure selon ITIL : Standard (pré-approuvé, sans CAB), Normal (approbation du CAB) et Emergency (approbation de l’eCAB), avec les fenêtres de Change Freeze.

Quand l’utiliser. Pour enregistrer, évaluer, approuver et planifier les changements ; pour gérer les réunions du CAB et les fenêtres de gel.

Comment l’ouvrir. Depuis la page d’accueil de l’IT Hub, encadré Change Management, ou depuis la console opérationnelle (action « Ouvrir un change » au tier L2).

Ce qu’elle affiche. Une ligne de KPI et quatre onglets :

Liste — les changes avec leur état, type, risque, fenêtre et résultat.
CAB — l’ordre du jour du Change Advisory Board : RFC en discussion, participants, votes (type IT-CAB-MEETING).
Calendar Window — le calendrier des fenêtres de changement (grille mensuelle), avec la « Window proposée ».
Audit Trail — la trace des actions sur les changes.

Comment l’utiliser. Vous créez/évaluez un change (RFC), le présentez au CAB pour approbation, planifiez la fenêtre d’exécution ; depuis chaque change, vous ouvrez l’Éditeur pour l’avancement et l’enregistrement des approbations (Approbation des changes (CAB)).

Ce qui se passe ensuite. Un Normal Change exige l’approbation du CAB avant l’exécution ; un Emergency suit le parcours de l’eCAB (approbation rétroactive). Pendant un freeze, les changes ne peuvent pas être approuvés sans autorisation explicite du Change Manager.

Remarques. Les réunions du CAB peuvent être générées périodiquement ; le compte rendu et le résultat du vote sont tracés sur le IT-CAB-MEETING correspondant.

Approbation des changes (CAB)

À quoi elle sert. Elle enregistre la décision d’approbation d’un change (généralement un Normal Change en CAB).

Quand l’utiliser. En séance de CAB/eCAB, quand le change est en attente d’approbation et que l’utilisateur fait partie des approbateurs.

Comment l’ouvrir. Depuis l’onglet CAB ou depuis l’Éditeur du change (onglet Approbations). C’est la même modale que celle décrite dans Approbation, appliquée ici aux changes.

Ce qu’elle affiche et comment l’utiliser. La chaîne d’approbation avec les étapes et leur état, et les décisions Approuver / Rejeter / Demander des informations / Déléguer, avec commentaire. Si elle est requise, la signature.

Ce qui se passe ensuite. L’approbation de la dernière étape autorise l’exécution du change dans la fenêtre planifiée ; un refus le renvoie ; toutes les décisions sont notifiées et tracées.

Remarques. Les règles CAB/eCAB et les gels conditionnent le résultat (voir Cockpits et vues de direction/Processus IT).

Problem Management Console

À quoi elle sert. Elle gère les problems et l’analyse des causes racines (RCA), jusqu’aux Known Errors avec contournement documenté.

Quand l’utiliser. Quand plusieurs incidents partagent une cause commune, ou pour mener une analyse structurée des causes racines.

Comment l’ouvrir. Depuis la page d’accueil de l’IT Hub, encadré Problem Management.

Ce qu’elle affiche. La disposition en file de la console opérationnelle (KPI, liste avec actualisation automatique toutes les 60 s), spécialisée pour les problems, avec le lien vers le calendrier du CAB et les incidents liés. Elle expose la RCA (5-why + moteur) et la Known Error DB (KEDB).

Comment l’utiliser. Vous ouvrez un problem, menez l’analyse RCA (modèle 5-why, chronologie) et documentez la cause racine et le contournement ; à partir d’un problem, vous promouvez un Known Error et créez l’article de KB correspondant.

Ce qui se passe ensuite. Un Known Error publié met le contournement à disposition du premier niveau (KB-deflection) et réduit le délai de résolution des incidents récurrents. Le modèle KEDB regroupe : Symptôme, Root cause, Contournement temporaire, Correctif permanent / change associé, CI impactés, Incidents liés.

Remarques. La RCA peut aussi être lancée depuis le tier L2 de la console opérationnelle (action « Lancer la RCA »).

Major Incident Workbench

À quoi elle sert. C’est le tableau de bord de gestion des crises (Major Incident) : il coordonne la war room, les mises à jour, les actions et la clôture.

Quand l’utiliser. Quand un Major Incident est déclaré (manuellement ou par une règle automatique quand un Incident P1 dépasse 30 minutes).

Comment l’ouvrir. Depuis l’action Ouvrir/Escalate Major Incident de la console opérationnelle, ou depuis les liens directs.

Ce qu’elle affiche. Le titre Major Incident Workbench, le bouton Resolve Major Incident, le panneau Impact et quatre onglets :

Timeline — la chronologie des événements de l’incident.
Actions — les Action items, les actions assignées pendant la crise.
Comms — les communications (mises à jour aux parties prenantes/au client).
Postmortem — la post-incident review.

L’Incident Bridge est disponible (bouton Config MI / modifier le bridge) : lien vers l’appel de crise, Incident Commander, participants, chronologie des mises à jour en temps réel. La section Linked tickets affiche les tickets liés à l’incident.

Comment l’utiliser. Vous ouvrez/mettez à jour le bridge, enregistrez les action items et les communications, mettez à jour la chronologie ; à la clôture, vous appuyez sur Resolve Major Incident.

Ce qui se passe ensuite. À la résolution, un PIR (Post-Incident Review) obligatoire est prévu, rempli dans l’onglet Postmortem. Les mises à jour sont communiquées aux parties prenantes selon les communications configurées.

Remarques. Les seuils et la classification des Major Incidents (P0–P3) se configurent dans la modale Config MI (Configuration des Major Incidents (Config MI)) et sur la page Admin MI Config (Admin MI Config).

Configuration des Major Incidents (Config MI)

À quoi elle sert. Elle configure les paramètres des Major Incidents : seuils de déclenchement et classification de sévérité.

Quand l’utiliser. Lors de la mise en place ou de la révision des politiques MIM.

Comment l’ouvrir. Depuis le bouton Config MI du Major Incident Workbench ou depuis la page Admin MI Config (Admin MI Config).

Ce qu’elle affiche et comment l’utiliser. Les paramètres de seuil (ex. délai au-delà duquel un Incident P1 devient Major) et la classification P0–P3 (Classification des Major Incidents). Vous les définissez et les enregistrez.

Ce qui se passe ensuite. Les règles automatiques de création des Major Incidents utilisent ces paramètres.

Remarques. C’est une fonction d’administration.

Knowledge Base

À quoi elle sert. C’est la gestion complète de la Knowledge Base : recherche, articles, rédaction, analyse d’utilisation et administration. Elle alimente le libre-service et la KB-deflection.

Quand l’utiliser. Pour rechercher, créer, mettre à jour et analyser les articles de KB (type IT-KB).

Comment l’ouvrir. Depuis l’action Knowledge Base de la page d’accueil IT ou depuis l’encadré KB.

Ce qu’elle affiche. Cinq onglets :

Search — recherche d’articles avec un champ de requête, les résultats et le test d’une requête (pour vérifier ce que l’utilisateur trouverait) ainsi que des suggestions.
Articles — la liste des articles avec un filtre par catégorie et la liste des catégories ; bouton Nouvel article.
Editor — la rédaction de l’article : 1 phrase de résumé, catégorie, tags, corps, pièces jointes et état de publication.
Analytics — les métriques d’utilisation (nombre d’articles, articles par catégorie).
Admin — l’administration de la KB (catégories, applicabilité par pays — ex. « IT, FR, DE »).

Comment l’utiliser. Vous recherchez et consultez ; avec la permission de rédaction, vous créez/mettez à jour un article (résumé, catégorie, tags, corps, pièces jointes) et le publiez ; l’onglet Search permet de tester l’efficacité de la recherche ; l’onglet Analytics mesure l’adoption.

Ce qui se passe ensuite. Les articles publiés sont disponibles dans la modale KB (Knowledge Base), lors du tri (deflection) et en libre-service ; l’applicabilité par pays en régit la visibilité.

Remarques. Il existe une vue publique (KB de domaine, article et KB publique) pour la consultation externe.

KB de domaine, article et KB publique

KB de domaine — la vue des articles filtrée par domaine (IT/NOC/OPS/ITSM), accessible depuis l’action KB du hub.
Article de KB — la page de détail/rédaction d’un article avec catégorie, tags, auteur et corps.
KB publique — la vue de consultation publique des articles destinés à l’extérieur.

Voicemail

À quoi elle sert. Elle regroupe les messages vocaux acheminés vers le service desk (utilisateurs / signalements IT) et permet de les écouter, d’en lire la transcription et de les transformer en tickets.

Quand l’utiliser. Pour gérer les messages vocaux reçus en dehors des heures ouvrées ou quand le softphone n’a pas répondu.

Comment l’ouvrir. Depuis la page d’accueil de l’IT Hub, encadré Voicemail (avec le compteur de messages non lus).

Ce qu’elle affiche. La boîte de réception des messages vocaux avec lecteur audio, transcription par IA (Whisper), risk scoring (Claude) et le rappel intégré au softphone.

Comment l’utiliser. Vous écoutez/lisez le message, évaluez le risque, rappelez l’expéditeur d’un clic (rappel via le softphone) ou ouvrez un ticket à partir du contenu.

Ce qui se passe ensuite. Le rappel lance un appel ; l’ouverture d’un ticket mène au Composer avec le contexte du message vocal.

Remarques. La page est partagée avec les zones liées (même endpoint canonique).

Contrôle qualité

À quoi elle sert. Elle effectue la revue qualité des tickets clôturés : documentation, ownership, respect des SLA, processus, résultat et sécurité.

Quand l’utiliser. Pour les vérifications de qualité par échantillonnage ou systématiques sur les tickets IT clôturés.

Comment l’ouvrir. Depuis l’action Contrôle qualité de la page d’accueil IT (visible pour les rôles habilités au contrôle qualité).

Ce qu’elle affiche et comment l’utiliser. La liste des tickets clôturés à revoir et la grille des critères de qualité ; vous évaluez chaque critère et enregistrez le résultat de la revue.

Ce qui se passe ensuite. Les résultats alimentent les indicateurs de qualité du service et peuvent rouvrir/signaler les tickets non conformes (QC-Gate).

Remarques. C’est une fonction réservée aux rôles qualité/management.

Données historiques

À quoi elle sert. Elle permet de consulter les données historiques archivées qui ne sont plus présentes dans la base opérationnelle.

Quand l’utiliser. Pour récupérer des tickets/données archivés au-delà de la fenêtre opérationnelle.

Comment l’ouvrir. Depuis l’action Données historiques de la page d’accueil IT.

Ce qu’elle affiche et comment l’utiliser. L’interface de recherche dans l’archive historique ; un client sélectionné est requis (si le contexte est « Tous les tenants » / *, la modale vous demande d’en sélectionner un).

Ce qui se passe ensuite. Les résultats sont affichés en lecture seule depuis l’archive froide.

Remarques. Concerne les données transférées dans l’archive historique selon la politique d’archivage.

Pages liées au hub (décrites ailleurs)

Depuis la page d’accueil IT, vous accédez aussi à des pages traitées dans leurs pages respectives, auxquelles nous vous renvoyons : ITOM et Events & AIOps (NOC, Observability et ITOM), IT Operations Dashboard / Operations Cockpit et les vues Service Director (Cockpits et vues de direction), IT Report Center (Cockpits et vues de direction/Reporting), Customer Service (Customer Service, Enterprise Service et ICC), CMDB / Assets (Asset Management et CMDB).