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) : Cette intégration est unidirectionnelle. Hector est la source de vérité et pousse les données vers ServiceNow. Les modifications effectuées directement dans ServiceNow ne sont pas rapatriées dans Hector.
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.
✅ 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.
🛡️ 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.
- User ID : par ex.,
- 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_readmodel_managerpersonalize_dictionaryrest_api_explorersn_cmdb_editorsnc_required_script_writer_permission
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 |
🛠️ 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_classde typealm_hardware. Chaque catégorie possède sa propreasset_class(détermine la table d’actifs cible) et sacmdb_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 Enregistrer 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 Champs 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.

🔄 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_idServiceNow. 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
manufacturerdéfini àtrueet 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 pièce Hector →
sys_idServiceNow) 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 pièce Hector. |
| SKU du fabricant | model_number | Alimenté directement à partir de la pièce Hector. |
| Prix | cost | Alimenté directement à partir de la pièce 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_idServiceNow). 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 Pièce → Modèle → Catégorie →
asset_classdétermine la table exacte (par ex.,alm_hardware). Si la chaîne ne peut être résolue, le système se rabat suralm_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_userde ServiceNow. Si une correspondance est trouvée, le champassigned_toest 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_classde 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_toest renseigné en faisant correspondre l’adresse courriel de l’utilisateur Hector avec la tablesys_userde 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_classde typealm_hardware, et les modèles sont synchronisés exclusivement vers la tablecmdb_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_classdéfinie, l’enrichissement CI ciblera la table de base génériquecmdb_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 incidents (ServiceNow → Hector) — À venir
Une mise à jour future introduira la synchronisation entrante pour les incidents et les tickets ServiceNow. Lorsqu’un ticket dans ServiceNow est associé à un élément de configuration qui a été synchronisé vers un actif Hector, l’intégration récupérera automatiquement les informations de base du ticket dans Hector.
Fonctionnalités prévues :
- Découverte automatique des tickets : Hector détectera les incidents liés aux CI synchronisés et les affichera sur la fiche de l’actif correspondant.
- Informations de base du ticket : Les champs clés tels que le numéro de ticket, la description courte, l’état, la priorité et le groupe d’affectation seront visibles directement dans Hector.
- Lien direct vers ServiceNow : Chaque ticket inclura un lien cliquable qui ouvre l’enregistrement complet de l’incident dans votre instance ServiceNow, permettant aux utilisateurs de consulter les détails sans quitter Hector.
Nous espérons que ce guide vous a été utile et nous vous souhaitons bonne chance dans votre parcours avec Hector!