Architecte ITOM
1Discovery, Service Mapping, Event Management, architecture Mid Server, intégrations protocoles (SNMP, WMI, SSH, vCenter)
Loading...
Loading...
Déploiement ServiceNow ITOM : Discovery, Service Mapping, Event Management, Orchestration. Cartographie du patrimoine IT et monitoring 24/7 avec corrélation d'événements.
Chaque phase regroupe une ou plusieurs des dix étapes ATLAS. Aucune phase ne démarre tant que la précédente n'a pas livré son artefact validé. La méthodologie ATLAS rend la migration AS/400 prévisible et auditable.
Cartographier le périmètre Discovery (réseau, plages IP, OS, applications, vCenter), recenser les sources monitoring à intégrer (Nagios, Zabbix, SCOM, Prometheus, Datadog…), définir les services métier prioritaires pour le Service Mapping. Validation des credentials privilégiés et gouvernance CyberArk.
Déployer les Mid Servers sur les zones réseau cibles, valider les credentials, tester Discovery sur un sous-périmètre, mesurer les temps de réponse, ajuster les plages IP et la planification pour rester non bloquant pour la production.
Industrialisation Discovery sur l'ensemble du périmètre, enrichissement CMDB avec les CIs détectés, Service Mapping top-down depuis les services métier critiques, validation des relations parent/enfant et des impacts métier.
Connecter les sources monitoring via connecteurs natifs ou REST, déployer le catalogue de règles de corrélation (déduplication, parent/enfant, suppression maintenance, enrichissement CMDB), mesurer la réduction du volume d'incidents générés, ajuster pour atteindre -70 à -90% vs outils sources.
Formation des équipes astreintes au tableau de bord ITOM unifié, automatisations Orchestration ciblées (remédiation auto sur incidents répétitifs), transfert d'exploitation à l'équipe cliente avec documentation et runbooks.
ServiceNow ITOM s'installe naturellement comme suite logique d'un déploiement ITSM réussi. Une fois l'ITSM en place avec une CMDB gouvernée, l'ITOM apporte trois briques manquantes : la Discovery automatique qui enrichit la CMDB avec les CIs techniques (serveurs, bases, applications, réseau), le Service Mapping qui modélise les dépendances entre services métier et infrastructure, et l'Event Management qui consolide les alertes des outils de monitoring existants pour créer des incidents qualifiés. La cible : réduire le bruit d'alerte (corrélation, déduplication) et accélérer le diagnostic (vue de bout en bout des dépendances).
La plupart des grandes organisations opèrent un patchwork de 3 à 8 outils de monitoring : Nagios pour le réseau, Zabbix pour les Linux, SCOM pour les Windows, Prometheus + Grafana pour les conteneurs, AppDynamics ou Dynatrace pour l'APM, sans compter les outils sectoriels et les scripts maison. Résultat : alertes redondantes, manque de corrélation entre couches, astreintes débordées par le bruit, diagnostic lent car les ingénieurs naviguent entre 5 consoles. ServiceNow ITOM Event Management ne remplace pas ces outils — il les agrège via connecteurs et applique une couche de corrélation et d'enrichissement CMDB.
Outils de supervision éclatés (Nagios, Zabbix, SCOM, custom)
Un déploiement ServiceNow ITOM se structure typiquement sur six à douze mois selon le périmètre Discovery, Service Mapping et Event Management. La cellule combine un architecte ITOM, deux à trois consultants ServiceNow Discovery / Service Mapping, un ingénieur intégrations monitoring, un référent infrastructure côté client. Pour un parc de quelques milliers de CIs et 5 à 10 sources d'événements, comptez huit à dix mois en cellule de quatre à cinq personnes.
Lancer la Discovery sans préparation réseau. Discovery sonde le SI via des credentials privilégiés et des protocoles (SNMP, WMI, SSH, vCenter) — sans préparation, échecs massifs et frustration équipe.
Phase de préparation Discovery dédiée : Mid Servers déployés et autorisés sur le réseau, credentials gouvernés via CyberArk ou équivalent, plages IP cibles définies, planning de Discovery non bloquant pour la production. Tests sur sous-périmètre avant industrialisation.
Activer Event Management sans règles de corrélation. Sans règles, ServiceNow ne fait que recopier les alertes des outils sources — aucun gain.
Catalogue de règles de corrélation établi par classe d'incident : déduplication (alerte identique 30 min), regroupement parent/enfant (un serveur down = N alertes services consolidées), suppression (alertes maintenance planifiée), enrichissement CMDB (impact métier auto-calculé). Le but : réduire de 70 à 90% le volume d'incidents générés par rapport aux outils sources.
Plusieurs profils distincts, mobilisés sur la durée du programme. Reproduire cette cellule en interne est rarement réaliste — la pénurie des compétences legacy et la profondeur d'expertise ATLAS rendent l'externalisation structurellement plus rapide et moins risquée.
Discovery, Service Mapping, Event Management, architecture Mid Server, intégrations protocoles (SNMP, WMI, SSH, vCenter)
ServiceNow ITOM administration, scripts JS, règles de corrélation, intégrations REST/MID
Configuration Mid Servers, patterns Discovery, modélisation top-down Service Mapping depuis les services métier
Connecteurs Nagios, Zabbix, SCOM, Prometheus, AppDynamics, Datadog vers Event Management
Modèle de données CMDB, gouvernance CIs, enrichissement automatique via Discovery, qualité des relations
Topologie réseau, credentials privilégiés (CyberArk), plages IP cibles, calendrier de Discovery non bloquant pour la production
Non. ServiceNow ITOM agrège les alertes des outils existants plutôt que de les remplacer. Les outils continuent à monitorer les couches techniques pour lesquelles ils sont efficaces (Datadog pour l'APM, Prometheus pour les conteneurs, Nagios pour le réseau). ITOM Event Management collecte ces alertes via connecteurs natifs ou REST, applique des règles de corrélation, enrichit avec la CMDB et crée des incidents ServiceNow qualifiés. Les ingénieurs travaillent dans ServiceNow plutôt que de naviguer entre N consoles.
Très fortement recommandé. ITOM s'appuie sur la CMDB ITSM pour enrichir les événements et créer des incidents qualifiés. Sans CMDB minimale (au moins les services métier critiques, les serveurs et applications les plus exposés), ITOM peut techniquement fonctionner mais perd la majeure partie de sa valeur. Le scénario typique : déployer ITSM + CMDB en année 1, étendre à ITOM en année 2.
Pour un périmètre de quelques milliers de CIs et 5 à 10 sources d'événements monitoring, comptez trois cent mille à six cent mille euros d'implémentation en co-delivery nearshore, plus les licences ServiceNow ITOM (Discovery, Service Mapping, Event Management) variables selon le volume. Les gains opérationnels (réduction MTTR, baisse du nombre d'astreintes activées) se mesurent dès la première année.
Trois manières de démarrer — du POC Discovery au programme ITOM complet. Notre approche s'appuie sur la méthodologie ATLAS et un catalogue éprouvé de règles de corrélation Event Management.