Documentation

Modules

Ce que fait chaque module, regroupé par domaine de l’application.

Services Supervision Service desk Changements Configuration Finances et actifs Administration

Services

portefeuille de services, niveaux de service et catalogue de demandes

Base de données de configuration

Modèle général d’infrastructure : IBM Power (LPAR, VIOS, HMC), virtualisation VMware, Hyper-V et Azure Stack Hub, serveurs virtuels dans les clouds publics (Azure, AWS, GCP), clusters de conteneurs où qu’ils soient (OpenShift et HyperShift, AKS, EKS, GKE), applications, plateformes applicatives et bases de données, baies de disques, SAN et réseau (routeurs, commutateurs L3/L2, agrégation de ports LACP et vPC, VLAN, sous-réseaux, routage). Pour les LPAR, vous voyez le chemin des données via NPIV, le SAN et la zone jusqu’à la baie de disques. Les coûts de l’infrastructure sur site sont calculés directement à partir de la CMDB. La carte des dépendances affiche les éléments à partir du service métier, sous forme de graphe ou d’arbre, avec un filtre par client et par environnement. L’analyse d’impact simule la panne d’un élément choisi et montre les services, applications et clients touchés ; pour les éléments redondants (paires de commutateurs, nœuds de cluster, fabrics SAN A/B), elle distingue panne et dégradation. Pour les services métier, applications, plateformes et bases de données, la fiche Haute disponibilité simule la panne de chaque élément support, liste les points uniques de défaillance et montre les groupes redondants (cluster applicatif, Db2 HADR, Oracle Data Guard, PowerHA, paires de VIOS, volumes HyperSwap). Chaque élément a une icône selon son type (serveur physique, VM, LPAR, application, base de données, baie de disques, bibliothèque de bandes, commutateur SAN, routeur, pare-feu, commutateur L2/L3…), la couleur de l’icône correspond à la catégorie. Pour les hyperviseurs, VIOS et LPAR, une fiche Chemin de stockage couvre les deux fabrics SAN. Les relations montrent les groupes redondants et les relations dont la panne n’entraîne qu’une dégradation (par exemple réseau d’administration de la baie, bibliothèque de bandes). La relation « est sauvegardé par » indique quelle plateforme de sauvegarde protège l’élément. Sur téléphone, la carte s’ouvre sous forme d’arbre ; le graphe se fait défiler d’un doigt et se zoome à deux doigts. Chaque élément a une équipe responsable ; pour le matériel, vous voyez la date d’installation, la fin de garantie et la fin du support constructeur. L’emplacement des VM et des partitions (hôte, cluster, serveur Power) n’est modifié que par la découverte depuis l’outil d’administration de la virtualisation concernée (vCenter, SCVMM, Azure Stack Hub, API cloud, HMC). Depuis la fiche d’un élément, vous pouvez directement signaler un incident ou planifier un changement.

SLA

Gestion des niveaux de service (Services → SLA). Respect des SLA : part des incidents avec réponse et résolution dans les délais, par mois et par accord SLA, priorité, service, client ou équipe, comparaison avec l’objectif, liste des violations et respect des délais des demandes. Accords SLA (par défaut Gold, Silver, Bronze, Standard) : objectifs de réponse et de résolution pour P1–P4, heures ouvrées (modifiables par priorité, par exemple P1 24/7), taux de respect exigé en %, disponibilité cible et moment de notification (après expiration d’un % du délai). Vous attribuez un accord à un service métier ou à un client ; s’applique le SLA du service → le SLA du client → le SLA par défaut. Heures ouvrées : fenêtres hebdomadaires par jour, jours fériés tchèques (y compris le Vendredi saint et le lundi de Pâques) et autres jours chômés, aperçu sur 14 jours. Le temps SLA ne court que pendant les heures ouvrées et n’est pas consommé tant qu’un incident est en attente. Délais des demandes : délai de traitement de chaque élément du catalogue en heures et en heures ouvrées. Les modifications s’appliquent aux nouveaux incidents et demandes ; les incidents ouverts peuvent être recalculés par un bouton. Modifié par le gestionnaire des incidents et l’administrateur de la plateforme (sla.manage).

Gestion des demandes

Le catalogue de services contient des demandes standard (nouveau serveur, extension de capacité, règle de pare-feu, accès, restauration depuis une sauvegarde, namespace dans OpenShift). Chaque élément a un formulaire, un mode d’approbation (sans approbation, responsable de service du client, chef de l’équipe de résolution, gestionnaire des changements), un délai, une équipe de résolution et des étapes de traitement. Une demande sans approbation passe directement au traitement. L’intervenant prend en charge la demande, coche les étapes et la marque comme traitée ; le demandeur la clôt. Un élément dont le traitement modifie l’infrastructure est lié à un modèle de changement – un changement est créé à partir de la demande, et la demande ne peut être traitée qu’une fois le changement terminé. Le catalogue est géré par le gestionnaire de configuration dans l’onglet Gestion du catalogue. Pour un élément lié à un modèle de changement standard, l’application crée elle-même le changement et le planifie au premier créneau libre sans autre approbation. La fiche Changements de la demande montre les changements liés, et le demandeur est informé quand ils sont planifiés, démarrés et terminés. Une demande qui est en réalité une panne est convertie par l’intervenant avec Convertir en incident.

Supervision

événements de supervision, leur corrélation et règles

Gestion des événements

Réception des événements de la supervision (Zabbix, Prometheus/Alertmanager, Checkmk, Grafana, Dynatrace, API générique) et réduction à ce à quoi l’opérateur doit réagir. Chaque événement est associé à un élément de configuration (nom d’hôte, FQDN, IP, numéro de série ou étiquette ci_id) et le service métier touché, le client et l’équipe responsable sont complétés à partir de la CMDB. Les règles de filtrage écartent le bruit ; les règles de suppression et les changements en cours sur l’élément suppriment l’alerte (sans réveiller l’opérateur). Les événements répétés d’un même problème (même empreinte) ne font qu’augmenter le compteur de l’alerte ; un message OK résout l’alerte, sinon elle est résolue après une période de silence. Une alerte instable (plusieurs changements d’état par fenêtre) est marquée comme flapping. Les alertes sont regroupées en situations : topologiquement, selon une simulation de panne dans la CMDB – seul un élément dont la panne explique réellement l’alerte peut en être la cause (un commutateur d’une paire n’est donc pas la cause de la panne d’un serveur), et parmi plusieurs candidats l’emporte celui qui explique le plus d’alertes (★). Les alertes expliquées par la cause sont des symptômes : visibles dans la situation, sans notification, exclues des indicateurs de bruit et résolues avec la cause. Lorsque plusieurs éléments émettent des alertes et partagent un support commun silencieux (par exemple des VM sur un même hôte), une situation avec une cause déduite est créée. Le regroupement se fait ensuite par service et par période, ainsi que par changement associé. La console classe les situations selon la criticité du service touché et la sévérité et se met à jour en direct ; l’opérateur confirme les situations, les attribue à une équipe, les met en sourdine pour un temps avec un motif, les fusionne et les scinde. Un incident créé depuis une situation est prérempli (élément, service, impact selon l’impact réel sur le service – panne, dégradation ou simple perte de redondance – et sa criticité, urgence selon la sévérité, équipe, chronologie des alertes, lien vers le changement) et les alertes restent liées à l’incident – les nouvelles alertes de la situation s’ajoutent, la résolution de toutes les alertes propose de résoudre l’incident et un problème qui revient rouvre l’incident. Une règle d’incident automatique crée un incident sans opérateur. La réduction du bruit montre l’entonnoir événements → alertes → situations → incidents, les contrôles qui n’ont jamais mené à un incident (suggestions d’ajustement des déclencheurs) et les hôtes sans élément dans la CMDB. Avec les données de démonstration, on peut simuler des événements (panne d’hyperviseur, base de données lente, flapping, bruit). La variante pilote traite les événements directement dans l’application ; pour de grands volumes, le traitement est déplacé vers Kafka et Flink (voir README).

Service desk

incidents, problèmes et traitement des demandes

Gestion des incidents

Un incident est une interruption ou une dégradation non planifiée d’un service. À la création, vous choisissez l’élément de configuration où le problème se manifeste – l’application calcule quels services sont touchés et propose le service touché, l’impact et l’équipe de résolution (équipe responsable de l’élément). La priorité P1–P4 découle de l’impact et de l’urgence ; les délais de réponse et de résolution sont fixés par le SLA du service touché (ou du client, ou par défaut) pendant ses heures ouvrées – le formulaire affiche à l’avance le SLA applicable et l’échéance. Les états et transitions sont définis par le workflow (Administration → Workflow), par défaut : nouveau → attribué → en cours → (en attente, attente fournisseur) → résolu → clos. Les boutons de la fiche correspondent aux transitions qui vous sont permises ; certaines exigent un commentaire. La mise en attente décale les échéances SLA. La résolution exige un code et une description ; le déclarant peut rouvrir l’incident. Le gestionnaire des incidents déclare un incident majeur. La fiche montre l’impact issu de la CMDB, les changements autour de l’ouverture de l’incident (un changement peut être marqué comme cause) et les boutons Proposer un changement et Changement urgent. Les incidents d’un élément sont visibles dans sa fiche ; la supervision peut les créer via l’API. La fiche Changements montre les changements qui résolvent l’incident – un changement peut être lié à plusieurs incidents et un changement existant peut être lié à l’incident ; le déclarant est informé quand le changement est planifié, démarré et terminé. S’il ne s’agit pas d’une panne mais d’une demande de service, convertissez l’incident avec Convertir en demande : choisissez un élément du catalogue, le déclarant devient le demandeur et l’incident est annulé avec un lien vers la nouvelle demande.

War room

Coordination d’un incident majeur (P1/P2). La war room s’ouvre depuis la fiche de l’incident. L’application propose la composition de l’équipe à partir des données – noyau et renfort selon les alertes, les changements candidats, la chaîne de support dans la CMDB et les incidents similaires – et la compare à un « pont élargi ». Elle suit la présence et le coût selon les taux horaires des équipes ainsi que les hypothèses (zone écartée → suggestion de libérer une équipe), et à la clôture écrit un résumé dans le journal de l’incident.

Gestion des problèmes

Un problème est la cause d’incidents récurrents ou majeurs. Il naît d’un incident, de l’analyse d’un incident majeur, d’une revue après changement ou du contrôle quotidien des incidents récurrents (le nombre et la période sont définis dans les paramètres des processus). La cause devient une erreur connue avec un contournement que les intervenants voient sur les incidents suivants. La correction définitive est réalisée par un changement créé directement depuis le problème ou lié à celui-ci (fiche Changements). Lorsque le changement se termine avec succès, un problème dont la cause est documentée passe de lui-même à Résolu ; un changement en échec le renvoie en analyse ; clôturez le problème une fois la correction vérifiée. Un problème créé à partir d’un incident parent reprend aussi ses incidents enfants.

Changements

changements, approbations et correctifs

Gestion des changements

Les changements sont créés à partir de modèles de changement. Le modèle détermine le type de changement (standard préapprouvé, normal, urgent), qui approuve (responsable du service touché, gestionnaire des changements, CAB, ou personne pour un changement standard), si la date doit tomber dans une fenêtre de maintenance, le délai de prévenance requis en jours, si le changement peut être réalisé progressivement élément par élément, s’il peut avoir lieu pendant un gel des changements, à quelles classes d’éléments il s’applique et quelles étapes il comporte. Démarche : choisissez un modèle, puis un service métier et les éléments de son arbre (ou directement les éléments). L’application calcule à partir de la CMDB quels services et applications seront indisponibles et lesquels seulement dégradés, trouve des dates selon les règles du modèle (fenêtres de maintenance, gels, collisions avec d’autres changements, délai de prévenance) et crée les approbations après l’envoi. En cas d’indisponibilité, le responsable du service métier approuve (A) et les responsables des applications sont consultés (C). L’intervenant démarre le changement approuvé, coche les étapes et le termine – il ne peut être terminé qu’une fois toutes les étapes réalisées. Un changement lié à un incident (y compris urgent) se crée directement depuis la fiche de l’incident, un changement correctif depuis la fiche du problème ; un changement standard pour une demande du catalogue est créé par l’application elle-même. Les modèles de changement sont gérés par le gestionnaire des changements dans l’onglet Modèles de changement, les fenêtres de maintenance par les responsables de service dans l’onglet Fenêtres de maintenance. La fiche Enregistrements traités montre les incidents, problèmes et demandes que le changement résout ; vous en liez d’autres par leur numéro (le lien d’origine du changement ne peut pas être supprimé). Lorsque le changement est planifié, démarré et terminé, les déclarants des incidents liés et les demandeurs des demandes liées sont informés. Le résultat se propage aux enregistrements liés : un problème dont la cause est documentée passe à Résolu, un changement en échec le renvoie en analyse, les incidents et demandes reçoivent une entrée indiquant l’étape suivante. Pendant 24 h après la fin, l’application surveille les alertes sur les éléments du changement – s’il en apparaît, la revue post-implémentation est obligatoire. Depuis un changement en cours ou en échec, terminé avec des problèmes ou avec des alertes après la fin, le bouton Créer un incident ouvre un incident qui enregistre le changement comme cause.

Gestion des correctifs

Vulnérabilités des serveurs, accords de correctifs avec les responsables de service et assistant du coordinateur des changements pour le plan de correctifs : il calcule les services touchés à partir de la CMDB et propose des créneaux dans leurs fenêtres de maintenance, hors gels et collisions avec d’autres changements ; les responsables de service approuvent l’indisponibilité. Les vulnérabilités d’un élément apparaissent aussi sur sa fiche CMDB.

Configuration

CMDB, centres de données et architecture d’entreprise

Centres de données

Vue d’ensemble des centres de données (indicateurs, salles, points d’attention), plan de salle et baie avec l’emplacement du matériel issu de la CMDB. L’installation ou le déplacement d’un équipement physique crée un changement ou une demande ; les positions planifiées apparaissent en contour dans la baie.

Paramètres

Base de données : données de production ou données de démonstration séparées (s’applique à toute l’application, enregistré dans la piste d’audit) ; en mode démonstration, les utilisateurs en tchèque voient la démo tchèque et ceux en anglais la démo anglaise. Conservation : la piste d’audit est conservée 5 ans et la base de données ne permet ni de supprimer ni de modifier un enregistrement plus tôt ; historique des éléments et relations selon le paramétrage (5 ans par défaut), exécutions de découverte et de connexions pendant 13 mois. Équipes : responsables des éléments, services et changements, et intervenants sur les incidents et demandes, avec membres et chef. Qualité des données de la CMDB : incohérences (emplacement des VM, équipe responsable manquante, détail de classe, coûts) et sources de vérité pour l’emplacement. Cycle de vie du matériel : fin de commercialisation et de support des modèles. Taux de change de la Banque nationale tchèque pour convertir les coûts en devises.

Architecture d’entreprise

Un modèle ArchiMate : capacités, acteurs, processus, applications et services applicatifs, objets de données et technologie liée à la CMDB. Les applications sont évaluées selon TIME (Tolerate, Invest, Migrate, Eliminate) et leur phase de cycle de vie ; l’état cible est décrit par des plateaux et des lots de travaux liés aux changements. La fiche d’un artefact montre les coûts, la disponibilité, les incidents, les changements et la chaîne jusqu’à l’infrastructure. Export au format Open Exchange.

Finances et actifs

coûts, facturation, actifs, achats et contrats

Vue d’ensemble des coûts

Coûts mensuels de tous les clients ou d’un client sélectionné. Les tuiles indiquent les coûts, la puissance de calcul allouée, son utilisation, la mémoire et le stockage. Le graphique couvre les 12 derniers mois ; un clic sur une colonne change de mois. Un clic sur la ligne d’un client restreint toute la page à ce client. Le bouton Télécharger le CSV FOCUS exporte les lignes au standard FOCUS.

Analyse des coûts

Vues personnalisées des données : vous choisissez jusqu’à 4 dimensions pour les lignes (client, projet, cluster, poste…), une pour les colonnes (en général le mois), ainsi que les mesures et les filtres. Le tableau se recalcule immédiatement. Un tableau enregistré est disponible pour tous les utilisateurs ; l’export CSV s’ouvre dans Excel (séparateur point-virgule).

Facturation

Modèles mensuels pour la facturation. Dans l’onglet Modèles, vous définissez le regroupement des lignes, la majoration, la remise et la TVA ; dans Données de facturation, le numéro d’entreprise (IČO), l’adresse et le contrat du client. Les modèles sont générés pour tout le mois en une fois ; un brouillon peut être régénéré, un modèle approuvé est figé. États : brouillon → approuvé → envoyé, l’annulation est possible à tout moment.

Grille tarifaire

Finances → Grille tarifaire des services. Versions de la grille (brouillon, en vigueur, archive) avec des prix unitaires par section : infrastructure, machines virtuelles par plateforme (VMware vSphere, Azure Stack Hub, OpenShift Virtualization – vCPU, mémoire, disque), systèmes d’exploitation (Windows Server, RHEL, SUSE, Ubuntu), serveurs standard Windows et Linux, niveaux de support et services d’exploitation, traitement des demandes (lien vers le catalogue) et réalisation des changements (type de changement, modèle de changement). Les prix sont modifiés par un rôle disposant de l’autorisation rate.manage ; le calculateur de serveurs virtuels compare les plateformes. Chaque ligne de coût porte une référence à la version de la grille, de sorte que l’on sait toujours à quel prix elle a été valorisée.

Registre des actifs

Fiches d’actifs liées aux éléments de configuration : achat, réception, factures, mise en service, amortissements, centres de coûts, stocks de pièces de rechange et procès-verbaux de remise. Un changement d’installation matérielle clôturé met la fiche en service ; la mise au rebut tient compte des amortissements comptabilisés.

Licences logicielles

Droits issus des contrats de licence par éditeur et produit, attribution des licences aux serveurs, bases de données et utilisateurs, et conformité avec les installations trouvées dans la CMDB. La consommation est la plus élevée entre les licences attribuées et les installations découvertes ; une consommation supérieure aux droits est mise en évidence.

Fournisseurs et contrats de service

Finances → Fournisseurs et contrats (contrats de service et fournisseurs). Un fournisseur a une hotline, un portail de support, un numéro client et des contacts avec niveau d’escalade (hotline, 1re et 2e escalade, direction). Un contrat (support, maintenance, abonnement ou extension de garantie) a une durée, un préavis de résiliation, une reconduction automatique, des jours d’alerte préalable, un prix et une facturation, un client et un gestionnaire de contrat. Les niveaux de support sont les SLA du fournisseur : heures ouvrées du fournisseur, délai de réponse et de réparation, technicien sur site. Les équipements couverts sont les lignes du contrat – éléments de la CMDB avec leur propre niveau, numéro de série, période et éventuellement prix (sinon le prix du contrat est réparti). Les documents (contrats, avenants, conditions, 10 Mo max.) sont stockés dans la base de données. La fin de validité est surveillée chaque jour : alerte au gestionnaire du contrat, à l’équipe et au rôle Administrateur des contrats au premier seuil dépassé, message « terminé » après l’échéance, les contrats à reconduction automatique sont prolongés. Dans un incident, la fiche Fournisseur trouve le support valide de l’élément ou du matériel sur lequel il tourne ; Signaler au fournisseur (ou la transition vers l’état Attente fournisseur) démarre les délais du fournisseur, Le fournisseur a répondu / Corrigé les clôt. La vue d’ensemble des contrats montre les contrats arrivant à échéance avec le dernier jour de préavis, la couverture du matériel par le support, le matériel sans support, les coûts annuels par fournisseur et par client et le respect des SLA des fournisseurs. Géré par l’administrateur des contrats (contract.manage) ; le gestionnaire des incidents et le gestionnaire de configuration peuvent aussi consulter (contract.read).

Administration

intégrations, personnes et accès, paramètres de l’application

Connexions

Tenants et comptes depuis lesquels les données sont collectées : Azure, Azure Stack Hub, AWS, Google Cloud, Oracle Cloud, OpenShift et centre de données. Seuls les identifiants et les références au coffre-fort (kv://, vault://…) sont stockés, jamais de mots de passe ni de clés – l’application refuse de les enregistrer.

Import et API

Chargement de fichiers FOCUS (CSV/JSON) et documentation de l’API REST pour les scripts de collecte, la supervision (incidents) et les intégrations. Un import répété de la même source pour le même mois remplace les données précédentes sans les dupliquer. Les lignes en devises sont converties en CZK au taux de la Banque nationale tchèque du premier jour de la période. Les saisies exigent un administrateur ou un jeton API.

Notifications

Messages par e-mail (Resend ou SendGrid) et dans Slack (webhook entrant vers un canal). Règle = enregistrement (incident, demande, changement, élément de configuration) + événement (création, changement d’état, attribution, commentaire, demande d’approbation, décision, SLA proches de l’échéance et dépassés) + conditions (priorité, incident majeur, état cible) + modèle + canaux + destinataires (intervenant, équipe de résolution, déclarant, demandeur, approbateurs, équipe responsable, titulaires d’un rôle, équipe, utilisateur, adresse quelconque). Le modèle comporte un objet et un texte dans un éditeur enrichi (gras, titres, listes, citations, liens, source HTML) et des paramètres {{incident.id}}, {{incident.priority_name}}, {{transition.to}}… insérés par un bouton depuis le panneau de droite ; les valeurs sont remplies à partir de l’enregistrement et échappées. L’aperçu montre l’e-mail et Slack avec des données d’exemple ou un enregistrement choisi ; un envoi de test vérifie le canal. Un canal ne contient qu’une référence à un secret du Worker (env:RESEND_API_KEY, env:SLACK_WEBHOOK_PROVOZ…), l’application ne stocke ni clés ni webhooks. Les SLA sont vérifiés toutes les 5 minutes (notifications 30 minutes avant l’échéance et après le dépassement, une seule fois chacune). Avec les données de démonstration, les messages ne sont par défaut que journalisés, les adresses des domaines de test (.example) ne sont jamais livrées. L’onglet Envoyés montre un journal de livraison, y compris les erreurs et les messages ignorés.

Accès et responsabilités

Rôles du personnel IT (administrateur de la plateforme, gestionnaire de configuration, responsable de service, responsable d’application, spécialiste infrastructure, gestionnaire des changements, gestionnaire des incidents, service desk, auditeur, compte de service de découverte) avec un périmètre client, équipe (selon la gestion des équipes) ou élément précis. La matrice RACI détermine qui réalise, approuve, est consulté et est informé pour les données de configuration et les changements ; l’application veille à ce que les rôles R et A disposent des autorisations correspondantes. Les comptes de service reçoivent des jetons API ; la piste d’audit enregistre chaque saisie.

Workflow

États et transitions des incidents, demandes, changements et éléments de configuration. Chaque état appartient à un état système sur lequel repose la logique de l’application (SLA, approbations, étapes de changement, retrait des éléments) – un état personnalisé comme « Attente fournisseur » se comporte comme Suspendu et le temps SLA s’arrête. Matrice des transitions : ligne = état de départ, colonne = état cible ; un clic sur une cellule ajoute ou modifie une transition. Pour une transition, vous définissez le libellé du bouton, les autorisations (évaluées dans le périmètre équipe, client ou service), si le déclarant / demandeur / auteur du changement peut l’utiliser, s’il s’agit d’une étape d’approbation (demandes), le commentaire et les champs obligatoires (résolution, intervenant) et l’apparence du bouton. Seule l’application peut mener aux états approbation en attente, approuvé et refusé des changements (par l’envoi et les décisions des approbateurs). Les états système ne peuvent pas être supprimés, seulement renommés ; désactivez un état personnalisé utilisé par un enregistrement. La configuration est commune aux données de production et de démonstration. Modifié par l’administrateur de la plateforme et le gestionnaire de configuration (workflow.manage).

Assistant IA

Un modèle de langage aide partout où l’on travaille avec du texte – il ne fait que proposer, c’est une personne qui décide. Résumé de situation (gestion des événements) : ce qui se passe, la cause probable avec l’élément de la CMDB, les étapes recommandées et un niveau de confiance ; créé automatiquement pour les situations à partir d’une sévérité définie, sinon par un bouton. Préremplissage d’incident : lors de la création d’un incident depuis une situation, le bouton « Proposer avec l’IA » ; dans Signaler un incident, le champ « Décrivez le problème avec vos mots » – l’élément, le service et l’équipe sont choisis uniquement dans la CMDB et la priorité est toujours calculée par l’application à partir de l’impact et de l’urgence. Ce qui a aidé la dernière fois : incidents résolus similaires selon le sens du texte et conseils tirés de leur résolution. Communication : brouillon d’information d’avancement pour les clients et de rapport de clôture – à modifier, copier ou enregistrer comme commentaire, rien n’est envoyé automatiquement. Revue de changement : contrôles basés sur des règles (description, retour arrière, risque vs indisponibilité d’un service critique, vérification après changement, communication) et résumé pour les approbateurs. Les données personnelles et secrets sont masqués avant l’envoi, chaque proposition est journalisée (Administration → Assistant IA → Dernières propositions) et l’évaluation « Cela vous a-t-il aidé ? » mesure la qualité. Pour les clients ayant une politique « sur site uniquement » ou « sans IA », aucune donnée n’est envoyée au modèle cloud. Sans modèle, ou une fois la limite quotidienne atteinte, une proposition déterministe s’affiche. Géré par l’administrateur de la plateforme (ai.manage) : interrupteurs, limite, prompts versionnés, politique client.

Plus

Vue d’ensemble opérationnelle

Écran d’accueil pour la direction. Tuiles : services métier en production, services sans point unique de défaillance, nombre de serveurs, serveurs avec un OS non supporté, changements à approuver et coûts du dernier mois – chacune mène au détail. En dessous : l’état des services métier (criticité, SLA, état, résilience, prochaine indisponibilité), l’infrastructure (Power, virtualisation, cloud, conteneurs, applications, réseau, SAN, sauvegarde et chaque baie de disques avec son taux d’occupation, le nombre de volumes, la réplication HA et DR et les ports FC), la redondance (serveurs sur deux éléments réseau, SAN dans les deux fabrics, LPAR sur une paire de VIOS, datastores de production sur des volumes en miroir, serveurs de production sauvegardés, services sans SPOF), le cycle de vie et les correctifs, les changements et indisponibilités (y compris les changements en retard et le gel des changements), la découverte et la qualité des données, et les coûts. Sur téléphone, les services s’affichent sous forme de cartes.