Centralisation du parc réseau

Le problème

Nous manquions de visibilité globale sur nos équipements réseau et n'avions aucun suivi centralisé de leurs mouvements (stockrooms, mises en production, historique d'affectation). Le seul référentiel existant était un CSV extrêmement lourd et mal maintenu, dont plusieurs versions circulaient en parallèle dans l'équipe, rendant tout suivi précis impossible. Le risque technique était réel : injecter des données brutes Meraki sans adaptation les aurait rendues inexploitables dans les tables strictes de ServiceNow, un capteur IoT ne se modélise pas comme un switch cœur de réseau.

Ce que j'ai fait

• Audité les attributs critiques par type d'équipement (MAC, serial, modèle, garantie, localisation) en arbitrant avec les PO ServiceNow et réseau.
• Mappé les champs de l'API REST Meraki vers les tables CMDB ServiceNow : switches vers cmdb_ci_ip_switch, APs vers cmdb_ci_wap_network, capteurs IoT MT10 vers une table custom faute de correspondance native.
• Piloté le projet en Agile via Jira en tant que Product Owner, absorbé les réorganisations successives de l'équipe ServiceNow sur environ un an.
• Intégré le load initial des 350+ équipements et contrats, puis mis en place des loads incrémentaux via un fichier template normalisé.
• Configuré l'alerting dégressif de fin de contrat (3 mois, 1 mois, 2 semaines, 48 h) et rédigé la KB de transfert pour l'équipe.

Résultats

La table est aujourd'hui le point d'entrée fiable pour le suivi du parc Cisco/Meraki : l'équipe IT a une visibilité totale sur l'historique et les mouvements en stockroom, et lors des incidents, garantie, firmware et localisation exacte sont accessibles immédiatement sans croiser les sources manuellement. La prochaine étape visée est l'automatisation complète via l'API ServiceNow, synchronisation directe depuis Meraki, dès que l'équipe ServiceNow sera prête techniquement.

Ce que j'en retiens

Sur ce projet, la technique était la partie simple, le data mapping champ par champ se fait. La difficulté, c'était d'aligner deux équipes qui ne parlent pas le même langage, réseau et ITSM, sur environ un an, avec des réorganisations à absorber en cours de route. Le fichier template normalisé reste une solution intermédiaire, fonctionnelle mais pas idéale : la synchronisation API directe est l'étape d'après.