Guide d’intégration avec ServiceNow

Bienvenue dans le guide officiel d’implémentation de l’intégration Hector + ServiceNow.

⚙️ Aperçu fonctionnel

L’intégration fonctionne selon deux niveaux distincts : la synchronisation du dictionnaire de données (fabricants, modèles matériels) et la synchronisation des actifs/CI (matériel et éléments de configuration).

🧠 Comment ça fonctionne

Direction de la synchronisation (Hector → ServiceNow) : Pour les données d’inventaire, cette intégration est unidirectionnelle. Hector est la source de vérité et pousse les fabricants, les modèles, les actifs et les éléments de configuration vers ServiceNow. Les modifications effectuées directement dans ServiceNow sur ces enregistrements ne sont pas rapatriées dans Hector.

Direction de la synchronisation (ServiceNow → Hector) : La synchronisation des billets fait exception et fonctionne dans l’autre sens. Lorsqu’elle est activée, Hector récupère les billets rattachés à vos éléments de configuration synchronisés et les affiche en lecture seule sur l’actif. Rien n’est jamais réécrit vers ServiceNow à partir de l’onglet Billets d’Hector. Voir la section 3 ci-dessous.

Pour garantir l’intégrité des données, Hector synchronise les informations avec ServiceNow dans un ordre spécifique, basé sur les dépendances et entièrement déterminé par vos correspondances de catégories :

Mapping des catégories (Le Gardien) : Hector importe vos catégories de modèles ServiceNow afin que vous puissiez les associer à vos catégories Hector. Seuls les éléments appartenant à ces catégories associées seront synchronisés.
Fabricants : Pour les catégories mappées, Hector synchronise ses « Fabricants » (définis au niveau de la sous-catégorie) pour créer ou mettre à jour les fabricants/entreprises correspondants dans ServiceNow.
Modèles matériels : Une fois les fabricants établis, Hector crée ou met à jour les modèles matériels spécifiques, en les reliant à la catégorie de modèles correspondante.
Actifs et CI : Enfin, les actifs physiques sont créés. Hector utilise les catégories mappées pour déterminer la classe d’actif et la classe de CI appropriées pour chaque élément.
Affectation des utilisateurs : Lors de la création d’un actif, si un élément est affecté à un utilisateur dans Hector, le système recherche cet utilisateur par courriel dans ServiceNow et renseigne automatiquement le champ assigned_to.
Affectation des emplacements : Si l’actif n’est affecté à aucun utilisateur, Hector fait correspondre son magasin ou sa tablette à un emplacement ServiceNow et renseigne le champ location de l’actif (voir la configuration du mapping des emplacements).

✅ Capacités clés

L’intégration Hector-ServiceNow est une passerelle professionnelle conçue pour garantir une source unique de vérité pour votre matériel informatique et vos éléments de configuration. Ses principales fonctionnalités sont les suivantes :

🔄 Synchronisation automatisée du cycle de vie : Gardez vos actifs, modèles et fabricants parfaitement alignés sur les deux plateformes sans double saisie de données.
🏗️ Routage intelligent des classes : Hector achemine automatiquement les actifs et les CI vers les tables ServiceNow appropriées en fonction des classes de CI et d’actifs spécifiques définies dans votre mapping de catégories.
👥 Mapping automatique des identités : Lorsqu’un actif est affecté dans Hector, le système recherche l’adresse courriel de l’utilisateur dans ServiceNow et met automatiquement à jour le champ d’affectation.
✨ Enrichissement avancé des CI : Surmontez les limitations standard de ServiceNow en mappant des champs Hector spécifiques directement aux champs de classes CI distinctes, garantissant ainsi que votre CMDB est toujours riche en données précises.
📊 Synchronisation incrémentale : Après la synchronisation initiale complète, seuls les actifs modifiés depuis la dernière synchronisation réussie sont traités, gardant les cycles de synchronisation rapides et efficaces.
📍 Résolution des emplacements : Pour les actifs qui ne sont affectés à aucun utilisateur, Hector peut faire correspondre le magasin ou la tablette de l’actif à un emplacement ServiceNow et renseigner automatiquement le champ location de l’actif.
🎫 Visibilité des billets : Récupérez au besoin les billets ServiceNow rattachés à chaque élément de configuration synchronisé — ouverts comme fermés — et consultez-les directement sur l’actif, sans quitter Hector.

🛡️ Configuration : Accès API ServiceNow

Hector nécessite un accès API et des rôles spécifiques dans votre instance ServiceNow pour servir de pont sécurisé entre les systèmes. Suivez les étapes ci-dessous pour créer un utilisateur d’intégration dédié et lui accorder les accès requis.

Étape 1 : Créer un utilisateur d’intégration

Nous recommandons de créer un compte de service dédié pour l’intégration Hector plutôt que d’utiliser un compte administrateur personnel.

Dans ServiceNow, naviguez vers User Administration > Users.
Cliquez sur New pour créer un nouvel utilisateur.
Remplissez les champs requis :
- User ID : par ex., hector_integration
- First Name / Last Name : par ex., « Hector » / « Integration »
- Password : Définissez un mot de passe robuste et conservez-le — vous en aurez besoin pour la configuration Hector.
Cliquez sur Submit pour créer l’utilisateur.

Étape 2 : Attribuer les rôles

Ouvrez le profil de l’utilisateur nouvellement créé, puis faites défiler jusqu’à la liste associée Roles et cliquez sur Edit. Ajoutez les rôles suivants :

cmdb_read
model_manager
personalize_dictionary
rest_api_explorer
sn_cmdb_editor
snc_required_script_writer_permission
asset
user_admin
sn_incident_read — pour la synchronisation des billets
sn_request_read — pour la synchronisation des billets

Cliquez sur Save pour appliquer les rôles.

Étape 3 : Configurer les ACL (Listes de contrôle d’accès)

Selon la configuration de sécurité de votre instance ServiceNow, vous devrez peut-être vous assurer que l’utilisateur d’intégration dispose des permissions ACL suivantes au niveau des enregistrements. Naviguez vers System Security > Access Control (ACL) pour vérifier ou créer ces règles :

Table	Opération	Type
alm_asset	write	record
alm_asset	create	record
cmdb_ci	write	record
cmdb_ci	create	record
core_company	write	record
core_company	create	record
cmn_location	read	record
sys_db_object	read	record

🛠️ Configuration : Paramètres d’intégration Hector

Maintenant que votre instance ServiceNow est prête, vous pouvez configurer l’intégration dans Hector. Naviguez vers Paramètres > Intégrations > Inventaire > ServiceNow et cliquez sur Ajouter.

🔐 Étape 1 : Connexion et validation

Dans l’onglet Authentification, saisissez les identifiants que vous avez préparés lors de la configuration de l’API ServiceNow :

URL de l’instance : L’URL complète de votre instance ServiceNow (par ex., https://VOTREINSTANCE.service-now.com).

Nom d’utilisateur : Le User ID du compte de service d’intégration que vous avez créé.

Mot de passe : Le mot de passe du compte de service d’intégration. Cette valeur est stockée de façon chiffrée dans Hector.

Cliquez sur Valider. Lors de la validation, Hector teste l’accès API à chaque table ServiceNow requise (catégories, entreprises, modèles, utilisateurs, emplacements, actifs et champs CI). Si une table est inaccessible — en raison d’identifiants incorrects, de rôles manquants ou de problèmes réseau — la validation échouera avec un message d’erreur spécifique.

Une fois la validation réussie, l’onglet Inventaire devient disponible, déverrouillant la configuration du mapping.

🗂️ Étape 2 : Mapping des catégories et des classes

Passez à l’onglet Inventaire, puis ouvrez le sous-onglet Catégories. C’est ici que vous établissez le mapping qui pilote l’ensemble de la synchronisation. Seuls les éléments appartenant aux catégories mappées seront synchronisés.

Cliquez sur Ajouter pour créer une nouvelle ligne de correspondance. Pour chaque ligne, sélectionnez :

Catégorie Hector (liste déroulante de gauche) : L’une de vos catégories Hector existantes. Chaque catégorie Hector ne peut être mappée qu’une seule fois.
Catégorie de modèle ServiceNow (liste déroulante de droite) : La catégorie de modèle ServiceNow correspondante. Cette liste déroulante n’affiche que les catégories ayant une asset_class de type alm_hardware. Chaque catégorie possède sa propre asset_class (détermine la table d’actifs cible) et sa cmdb_ci_class (détermine le type de CI pour l’enrichissement).

Répétez pour chaque catégorie que vous souhaitez synchroniser. Vous pouvez supprimer un mapping à tout moment en cliquant sur le bouton de suppression de la ligne. Cliquez sur Sauvegarder lorsque vous avez terminé.

🎛️ Étape 3 : Mapping avancé des champs CI (Optionnel)

Une fois que vous avez enregistré au moins un mapping de catégorie, le sous-onglet CI devient disponible. Cette étape est optionnelle mais recommandée si vous souhaitez pousser des données Hector supplémentaires dans les éléments de configuration ServiceNow au-delà des champs d’actifs de base.

Par défaut, lorsque ServiceNow génère un CI à partir d’un nouvel actif, il ne copie que les informations de base. Cette fonctionnalité vous permet d’aller plus loin en mappant des colonnes d’actifs Hector spécifiques directement aux champs CI.

Comment ça fonctionne :

Découverte de champs agrégés : Hector examine dynamiquement toutes les classes CI associées à vos catégories mappées et rassemble tous les champs CI distincts disponibles. Seuls les champs avec des types de données pris en charge (chaîne, entier, booléen, date/heure, durée, adresse IP, chemin de domaine, nom de champ) sont inclus. Si plusieurs classes CI partagent le même champ (par ex., « Processeur » ou « Adresse MAC »), celui-ci n’apparaît qu’une seule fois.
Mapping : Pour chaque champ CI découvert, vous pouvez optionnellement sélectionner une colonne d’actif Hector à y associer.
Exécution intelligente : Lors de la synchronisation, Hector vérifie si le CI spécifique en cours de mise à jour prend en charge ce champ. Si le champ appartient à la classe de ce CI, la valeur mappée est poussée. Les valeurs date/heure sont automatiquement converties au format UTC.

📍 Étape 4 : Mapping des emplacements (Optionnel)

Le sous-onglet Emplacements permet à Hector de renseigner le champ location d’un actif dans ServiceNow selon l’endroit où l’actif est physiquement situé dans Hector. Cette étape est optionnelle et ne touche que les actifs qui ne sont pas affectés à un utilisateur : lorsqu’un actif a un utilisateur, son affectation a toujours priorité et aucun emplacement n’est renseigné.

Le mapping définit une clé de correspondance entre un emplacement Hector et un emplacement ServiceNow (la table cmn_location). Pour chaque type d’emplacement Hector pris en charge, vous choisissez un champ Hector et un champ d’emplacement ServiceNow. Lors de la synchronisation, Hector considère qu’il y a correspondance lorsque les valeurs de ces deux champs sont identiques.

Deux types d’emplacements Hector sont pris en charge, chacun sur sa propre ligne :

Magasin — champs Hector proposés : Nom, Description, Note, ainsi que tout attribut personnalisé de magasin d’un type simple à valeur unique (texte, nombre entier ou liste à sélection unique). Les attributs décimaux, de type date, case à cocher, à sélection multiple ou de type référence sont volontairement exclus.
Tablette — champs Hector proposés : Nom et Description.

La liste déroulante Champs ServiceNow est alimentée dynamiquement à partir du dictionnaire de données de la table cmn_location : vous pouvez donc faire correspondre n’importe quel champ d’emplacement, standard ou personnalisé.

Configurez la ou les lignes dont vous avez besoin, puis cliquez sur Sauvegarder. Laissez une ligne vide pour ne pas mapper ce type d’emplacement. Puisqu’une tablette se trouve toujours dans un magasin, un actif rangé sur une tablette est d’abord comparé au mapping Tablette, puis retombe sur le mapping Magasin si aucune correspondance de tablette n’est trouvée (ou si aucun mapping de tablette n’est configuré).

🔄 Utilisation et synchronisation

Une fois la connexion initiale établie, l’intégration gère le cycle de vie de votre dictionnaire matériel et des actifs individuels pour toutes les catégories mappées.

🕒 Fréquence de synchronisation

Tâche planifiée : La synchronisation s’exécute comme une tâche planifiée à un intervalle configuré. Elle peut également être déclenchée manuellement depuis les paramètres d’intégration.
Incrémentale par défaut : Après la synchronisation initiale, seuls les actifs modifiés depuis la dernière synchronisation réussie sont inclus. Cela permet de garder les cycles de synchronisation efficaces.
Option de synchronisation complète : Une synchronisation complète peut être forcée au besoin, retraitant tous les actifs actifs dans les catégories mappées indépendamment de leur date de modification.

🔍 La logique « Rechercher, lier ou créer »

Pour chaque entité synchronisée avec ServiceNow (fabricants, modèles et actifs), Hector suit un processus de validation strict afin d’éviter les doublons :

Recherche : Hector recherche dans ServiceNow un enregistrement existant en fonction de champs de correspondance prédéfinis.
Liaison et mise à jour : Si une correspondance est trouvée, Hector associe son identifiant interne au sys_id ServiceNow. Lors des synchronisations ultérieures, il mettra simplement à jour cet enregistrement existant.
Création : Si aucune correspondance n’est trouvée lors de la recherche initiale, Hector crée un nouvel enregistrement dans ServiceNow et établit le lien pour les mises à jour futures.

📥 1. Synchronisation du dictionnaire (Hector → ServiceNow)

Avant de synchroniser les éléments physiques individuels, Hector s’assure que ServiceNow dispose des données de base correctes pour vos catégories mappées.

A. Fabricants

Hector consulte la table core_company dans ServiceNow pour les fabricants liés aux catégories mappées.

Champ de correspondance : Nom (insensible à la casse)

🔁 Comportement de synchronisation :

Si trouvé : Hector établit le lien avec l’entreprise existante. Si l’entreprise n’est pas déjà marquée comme fabricant, il met à jour le drapeau manufacturer à true.
Si non trouvé : Hector crée une nouvelle entreprise avec le drapeau manufacturer défini à true et une note indiquant qu’elle a été créée automatiquement via la synchronisation Hector.

Champ d’item Hector	Champ ServiceNow	Notes
Fabricant	`name`	Utilisé pour trouver les fabricants correspondants.
–	`manufacturer`	Défini à `true` pour identifier l’entreprise comme fabricant.
–	`notes`	Défini à « Auto-created via Hector Sync » lors de la création uniquement.

B. Modèles matériels

Hector consulte la table cmdb_hardware_product_model dans ServiceNow pour les modèles liés aux catégories mappées.

Champs de correspondance : Nom + Fabricant

🔁 Comportement de synchronisation :

Si un mapping existe déjà : Hector met à jour le modèle existant dans ServiceNow avec les dernières données d’Hector.
Si aucun mapping n’existe : Hector crée un nouveau modèle et enregistre le lien (ID de sous-catégorie Hector → sys_id ServiceNow) pour les synchronisations futures.

Champ d’item Hector	Champ ServiceNow	Notes
Modèle	`name`	Le nom du modèle.
Fabricant	`manufacturer`	Lié à l’entreprise synchronisée à l’étape A.
Catégorie	`cmdb_model_category`	Lié à la catégorie de modèle ServiceNow définie dans votre mapping d’intégration.
Description	`short_description`	Alimenté directement à partir de la sous-catégorie Hector.
SKU du fabricant	`model_number`	Alimenté directement à partir de la sous-catégorie Hector.
Prix	`cost`	Alimenté directement à partir de la sous-catégorie Hector.

📥 2. Synchronisation des actifs et des CI (Hector → ServiceNow)

Une fois les données structurelles en place, Hector synchronise les actifs physiques et les éléments de configuration appartenant à vos catégories mappées à l’aide d’un processus d’enrichissement spécialisé.

Actifs et éléments de configuration

Hector consulte la table d’actifs appropriée (déterminée par l’asset_class de la catégorie, typiquement alm_hardware) dans ServiceNow.

Champs de correspondance : Numéro de série OU étiquette d’actif (via le lien de mapping existant)

🔁 Comportement de synchronisation et logique de création :

Recherche : Hector vérifie s’il possède déjà un mapping (ID d’actif Hector → sys_id ServiceNow). Si un mapping existe, il met à jour l’enregistrement. Si l’enregistrement mappé n’existe plus dans ServiceNow (par ex., il a été supprimé), Hector se rabat sur la création d’un nouvel enregistrement.
Routage des tables : La table ServiceNow cible est déterminée par la catégorie de l’actif. La chaîne Sous-catégorie → Modèle → Catégorie → asset_class détermine la table exacte (par ex., alm_hardware). Si la chaîne ne peut être résolue, le système se rabat sur alm_asset.
Affectation des utilisateurs : Si l’actif est affecté à un utilisateur dans Hector, le système recherche l’adresse courriel de cet utilisateur dans la table sys_user de ServiceNow. Si une correspondance est trouvée, le champ assigned_to est renseigné. Sinon, le champ reste vide.
✨ Enrichissement CI en deux étapes :
- Étape 1 – Création standard : Hector crée l’actif, ce qui déclenche la génération par ServiceNow de l’élément de configuration (CI) de base.
- Étape 2 – Mise à jour ciblée du CI : Immédiatement après, Hector lit la référence CI de l’actif nouvellement créé. En utilisant la classe CI déterminée par la cmdb_ci_class de la catégorie, Hector pousse les valeurs des champs mappés dans l’enregistrement CI. Cet enrichissement s’applique également lors des mises à jour d’actifs existants.

🧱 Mapping des champs d’actifs de base

Champ d’actif Hector	Champ ServiceNow	Notes
Étiquette d’actif	`asset_tag`	L’identifiant unique de l’actif.
Numéro de série	`serial_number`	Alimenté à partir de l’attribut numéro de série de l’actif.
Modèle	`model`	Lié au modèle matériel synchronisé à l’étape 1B (référence par `sys_id`).
Catégorie	`model_category`	Hérité de la `cmdb_model_category` du modèle.
Fabricant	`manufacturer`	Hérité du fabricant du modèle (référence par `sys_id`).
Affectation (si utilisateur seulement)	`assigned_to`	Renseigné automatiquement si l’utilisateur est trouvé dans ServiceNow par courriel. Laissé vide sinon.
Date d’acquisition	`purchase_date`	Formaté en `yyyy-MM-dd`.
Prix	`cost`	Alimenté directement à partir de votre actif Hector.
Devise	`currency`	Alimenté directement à partir de votre actif Hector.
[Champs personnalisés mappés]	[Champs CI distincts]	Poussés vers l’enregistrement CI lors de l’étape 2 de l’enrichissement, à condition que le champ existe dans la classe spécifique du CI.

🚫 Contraintes de l’intégration

Synchronisation unidirectionnelle : Cette intégration pousse les données d’Hector vers ServiceNow uniquement. Les modifications effectuées directement dans ServiceNow (mises à jour de champs, changements de statut, suppressions) ne sont pas reflétées dans Hector.
Aucune propagation des suppressions : Lorsque des enregistrements sont supprimés ou désactivés dans Hector (actifs, catégories, items, fabricants, etc.), ils ne sont pas retirés de ServiceNow. Le nettoyage dans ServiceNow doit être effectué manuellement.
Drapeau « Exclure de la synchronisation » : Des actifs individuels peuvent être exclus de la synchronisation en activant le drapeau Exclure de la synchronisation sur l’actif dans Hector.
Filtrage par catégorie : Seuls les actifs appartenant à des catégories explicitement mappées dans les paramètres d’intégration seront synchronisés. Les catégories non mappées sont complètement ignorées.
Correspondance des utilisateurs par courriel uniquement : Le champ assigned_to est renseigné en faisant correspondre l’adresse courriel de l’utilisateur Hector avec la table sys_user de ServiceNow. Si le courriel n’existe pas dans ServiceNow, le champ reste vide — aucune erreur n’est générée.
Matériel uniquement : Cette intégration est conçue exclusivement pour le matériel. La liste déroulante de mapping des catégories n’affiche que les catégories de modèles ServiceNow ayant une asset_class de type alm_hardware, et les modèles sont synchronisés exclusivement vers la table cmdb_hardware_product_model. Les autres types de modèles ServiceNow (par ex., modèles logiciels, modèles de consommables) et les classes d’actifs non matériels ne sont pas pris en charge.
Repli de la classe CI : Si une catégorie ServiceNow mappée n’a pas de cmdb_ci_class définie, l’enrichissement CI ciblera la table de base générique cmdb_ci. Pour de meilleurs résultats avec le mapping des champs CI, assurez-vous que vos catégories ServiceNow ont une classe CI spécifique assignée (par ex., cmdb_ci_computer, cmdb_ci_server).

📥 3. Synchronisation des billets (ServiceNow → Hector)

Lorsque la synchronisation des billets est activée, Hector récupère automatiquement les données des billets ServiceNow dans vos fiches d’actifs. Lorsqu’un billet ServiceNow — incident, problème ou demande de changement — est rattaché à un élément de configuration qui correspond à un actif suivi dans Hector, Hector reproduit les champs de billet sélectionnés et les affiche directement dans l’onglet Billets de l’actif.

⚙️ Configuration : Étape 1 — Sélection des tables

Rendez-vous dans l’onglet Billets des paramètres de votre intégration ServiceNow et ouvrez le sous-onglet Tables. C’est ici que vous choisissez les tables ServiceNow dérivées de task qu’Hector surveillera pour y trouver des billets.

La liste est alimentée automatiquement avec toutes les tables dérivées de task disponibles dans votre instance ServiceNow — le plus souvent incident, problem, change_request, sc_req_item et sc_task, ainsi que toute table personnalisée définie dans votre instance.

Aucune table n’est sélectionnée par défaut. Activer la synchronisation des billets ne récupère rien à elle seule : vous devez cocher au moins une table ici, puis cliquer sur Sauvegarder. Tant qu’aucune table n’est sélectionnée, la synchronisation des billets s’exécute et se termine sans rien importer, et l’onglet Billets de l’actif reste vide.

Un nombre de billets est affiché à côté de chaque table pour vous aider à choisir. Ce nombre correspond à tous les billets de la table rattachés à un élément de configuration — ouverts comme fermés — dans l’ensemble de votre instance ServiceNow, et non uniquement aux CI synchronisés avec Hector. Voyez-le comme une indication de l’endroit où se trouvent vos billets plutôt que comme un aperçu de ce qui sera importé.

⚙️ Configuration : Étape 2 — Sélection des champs

Une fois les tables sélectionnées, ouvrez le sous-onglet Champs. Les champs sont chargés automatiquement à partir du dictionnaire de données de ServiceNow pour toutes les tables sélectionnées, et regroupés en trois catégories :

Toujours synchronisé : les champs de suivi essentiels (numéro du billet, référence du CI, statut actif, date de dernière mise à jour), toujours inclus et impossibles à désélectionner.
Champs communs (toutes les tables sélectionnées) : les champs partagés par toutes les tables sélectionnées (par exemple description courte, état, priorité, affecté à).
Par table : les champs qui n’existent que sur certaines tables, affichés par table avec une mention indiquant à quelles tables ils appartiennent.

Utilisez la zone de recherche pour filtrer rapidement les champs par nom ou par libellé. Cliquez sur Sauvegarder pour enregistrer votre sélection. Les champs apparaîtront comme colonnes dans l’onglet Billets de l’actif, dans l’ordre où ils ont été sélectionnés.

🔄 Comportement de la synchronisation

La synchronisation des billets s’exécute avec la synchronisation de nuit des intégrations, juste après la synchronisation des actifs dont elle dépend :

Résolution CI → actif : pour chaque billet, Hector lit l’élément de configuration rattaché (cmdb_ci) et le résout vers un actif Hector à l’aide du mapping de CI établi lors de la synchronisation des actifs. Les billets rattachés à des CI qui ne sont pas suivis dans Hector sont ignorés silencieusement — aucune erreur n’est signalée.
Billets ouverts et fermés : tous les billets rattachés à un CI suivi sont importés, quel que soit leur état. Fermer un billet dans ServiceNow ne le retire pas d’Hector : l’actif conserve tout son historique de billets. Sélectionnez le champ state (voir l’étape 2) si vous souhaitez une colonne permettant de distinguer d’un coup d’œil les billets ouverts des billets fermés.
Aperçu des champs : les champs sélectionnés sont enregistrés sous forme d’aperçu sur chaque fiche de billet Hector, avec leurs libellés d’affichage. Les valeurs sont stockées prêtes à afficher — aucune requête supplémentaire vers ServiceNow n’est nécessaire pour consulter l’onglet Billets de l’actif.

Vous n’avez pas à attendre l’exécution de nuit. Le bouton Synchroniser à côté de ServiceNow dans Paramètres → Intégrations met la synchronisation des billets en file d’attente juste après celle des actifs, et le bouton Synchroniser de l’onglet Intégrations d’un actif rafraîchit immédiatement les billets de cet actif — pratique pour vérifier un billet précis sans lancer un balayage complet.

🛡️ Réconciliation des billets

Une tâche de réconciliation dédiée s’exécute avec la synchronisation de nuit des intégrations, immédiatement après la synchronisation des billets, afin de détecter les billets sortis discrètement du périmètre — par exemple les billets supprimés directement dans ServiceNow ou réaffectés à un élément de configuration qu’Hector ne suit pas.

Toute fiche de billet Hector que la synchronisation n’a pas revue depuis 90 jours ou plus est considérée comme obsolète et est désactivée : elle cesse d’apparaître sur l’actif, mais la fiche elle-même n’est jamais supprimée. Un billet fermé n’est pas obsolète — la synchronisation continue de le retourner, il demeure donc visible indéfiniment.

La réconciliation est volontairement prudente : si aucune synchronisation des billets n’a réussi au cours des trois derniers jours, elle s’abstient complètement plutôt que de risquer de désactiver des billets en se fiant à une synchronisation qui n’a jamais eu lieu.

🗂️ Consulter les billets d’un actif

Dès qu’au moins un billet a été synchronisé pour un actif, un onglet Billets apparaît sur la fiche de l’actif. Le compteur de l’onglet indique le nombre de billets conservés pour cet actif, ouverts comme fermés. Un actif sans billet synchronisé n’affiche aucun onglet.

Le tableau des billets affiche les colonnes suivantes :

Colonne	Description
Numéro	Le numéro du billet ServiceNow, affiché sous forme de lien cliquable qui ouvre la fiche complète directement dans votre instance ServiceNow.
Source	La table ServiceNow d’où provient le billet (par exemple `incident`, `problem`).
Mise à jour	La date et l’heure de la dernière mise à jour du billet dans ServiceNow.
[Champs sélectionnés]	Une colonne par champ sélectionné lors de la configuration, dans l’ordre de sélection.

🚫 Limitations

Synchronisation unidirectionnelle : les données de billets circulent de ServiceNow vers Hector uniquement. Aucune information n’est réécrite vers ServiceNow à partir de l’onglet Billets.
Mapping de CI requis : seuls les billets rattachés à des CI déjà suivis comme actifs Hector seront synchronisés. Les billets associés à des CI non suivis sont ignorés.
Pas de propagation des suppressions : les billets supprimés directement dans ServiceNow ne sont pas retirés d’Hector immédiatement. Ils cessent d’être retournés par la synchronisation et sont désactivés par la tâche de réconciliation une fois franchie sa fenêtre d’obsolescence de 90 jours. Fermer un billet n’est pas une suppression : les billets fermés restent visibles sur l’actif, par choix de conception.
Configuration partagée : la sélection des tables et des champs s’applique globalement à tous les actifs. Il n’existe aucun filtre de billets par actif ou par catégorie.
Dépendance au CI matériel : la synchronisation des billets repose sur le mapping de CI établi par la synchronisation des actifs (section 2). Celle-ci doit s’être exécutée au moins une fois pour que l’actif correspondant à un CI puisse recevoir des billets.

Nous espérons que ce guide vous a été utile et nous vous souhaitons bonne chance dans votre parcours avec Hector!

Updated on 10 septembre 2026

Tagged: integration servicenow

Was this article helpful?

Yes No