Réalisation : Ingénierie des besoins & gestion d'inventaire
Centralisation du parc réseau
Définition de l'architecture de la donnée et pilotage transverse en Agile pour l'intégration de 350+ équipements réseau et contrats dans la CMDB ServiceNow.
Présentation du projet
Le déclencheur de ce projet a été un constat critique : nous manquions de visibilité globale sur nos équipements réseau et n'avions aucun suivi centralisé de leurs mouvements à jour (gestion des stockrooms, mises en production, historique d'affectation). Historiquement un fichier CSV extrêmement lourd et pas maintenu existait, mais diverses versions circulaient, rendant impossible un suivi précis.
Pour reprendre le contrôle sur le cycle de vie et la visibilité du matériel, on a lancé l'intégration de notre parc de devices et contrats directement dans la CMDB (Configuration Management Database) de ServiceNow, déjà utilisé par une équipe dédiée. Sur ce projet, je suis intervenu en tant que référent technique réseau et Product Owner du rendu final.
Points clés
350+ équipements
Switches Meraki MS et Cisco Catalyst, firewalls, APs MR46, capteurs IoT MT10.
Source de vérité unique
Fin du CSV non maintenu, visibilité centralisée sur le cycle de vie et les mouvements du matériel.
Alerting de fin de contrat
Suivi des garanties et licences avec alertes automatiques pour anticiper les renouvellements.
Objectifs, enjeux et risques
L'objectif principal était d'obtenir une source de vérité unique et dynamique pour un parc d'environ 350 équipements critiques 100% Cisco et Meraki, avec une gestion des contrats liés (licensing et warranty) et la mise en place d'un alerting de fin de contrat.
Le risque principal était d'injecter des données brutes extraites de Meraki les rendant potentiellement inexploitables dans l'outil cible. Il fallait s'assurer que les informations s'insèrent parfaitement dans les tables très strictes de ServiceNow, tout en gérant les spécificités de chaque type de matériel (un capteur IoT ne se modélise pas comme un switch cœur de réseau).
Points clés
Source de vérité unique et dynamique
Parc d'environ 350 équipements critiques 100% Cisco et Meraki, avec gestion des contrats liés (licensing et warranty).
Alerting de fin de contrat
Mise en place d'un alerting pour anticiper les fins de garantie et de licence avant qu'elles n'impactent les opérations.
Risque : données inexploitables
Injecter des données brutes Meraki sans adaptation risquait de les rendre inutilisables dans les tables strictes de ServiceNow.
Étapes et acteurs
Le point de départ a été un audit de l'existant. Le CSV utilisé jusque-là était tellement lourd et mal maintenu que plusieurs versions circulaient en parallèle dans l'équipe, rendant impossible un suivi fiable des mouvements de matériel. La décision a été prise de migrer vers ServiceNow CMDB, déjà en place chez Criteo. Sur ce projet, j'ai endossé le rôle de référent technique réseau et de Product Owner du rendu final.
La première vraie étape technique a été de définir précisément quoi intégrer. J'ai mené un audit des attributs critiques pour chaque type d'équipement : switches Meraki MS et Cisco Catalyst, APs MR46, firewalls Palo Alto, capteurs IoT MT10. Pour chacun, j'ai déterminé les champs indispensables : MAC Address, Serial Number, modèle précis, statut et date de fin de garantie, localisation (site, bâtiment, rack). La difficulté ici, c'est qu'un capteur IoT et un switch cœur de réseau ne se modélisent pas de la même façon dans une CMDB. J'ai consulté les PO côté ServiceNow et côté réseau pour arbitrer les compromis.
La phase de data mapping a été la plus complexe. Les données extraites via l'API REST Meraki (`GET /organizations/[orgId]/devices`) retournent du JSON avec les champs natifs Meraki, qui ne correspondent pas directement aux tables CMDB ServiceNow. J'ai animé les réunions de synchronisation avec l'équipe intégration pour définir la correspondance champ par champ : switches MS et Catalyst vers `cmdb_ci_ip_switch`, APs MR46 vers `cmdb_ci_wap_network`, capteurs IoT MT10 vers une table custom faute de correspondance native. Cas particuliers à gérer : les noms de modèles Meraki ne matchent pas les `model_id` ServiceNow, les champs de localisation physique (rack, bâtiment, salle) n'existent pas dans l'API Meraki et nécessitent un enrichissement manuel, et certains équipements remontaient sans serial number exploitable.
Le pilotage s'est fait en Agile via Jira. J'ai créé et suivi les tickets, défini les itérations et géré les changements de besoin qui arrivent inévitablement en cours de projet (nouvelles exigences de l'équipe Finance sur les contrats, ajout de types d'équipements non prévus initialement). J'ai organisé des points réguliers avec les équipes IT et Finance pour valider les données au fur et à mesure. Le projet s'est étalé sur environ un an, une durée longue en grande partie due aux réorganisations successives de l'équipe ServiceNow, qu'il a fallu absorber sans perdre le fil du projet.
L'intégration s'est faite en deux temps : un load initial pour peupler la table avec les 350+ équipements et les contrats associés (garanties et licences), puis des loads incrémentaux au fil de l'eau. Aujourd'hui ce n'est volontairement pas full-automatisé, car l'équipe ServiceNow n'est pas encore prête techniquement pour cette automatisation : pour ajouter de nouveaux objets, on renseigne un fichier template normalisé qui garantit que les données s'insèrent proprement dans la table. Une fois les données en place, j'ai mis en place l'alerting de fin de contrat : mails de warning envoyés selon un échéancier dégressif (3 mois, 1 mois, 2 semaines, 48 h avant l'échéance).
En clôture, j'ai rédigé l'article Knowledge Base qui documente toute l'utilisation de la solution : architecture de la donnée, logique de correspondance des champs, et surtout la procédure complète pour ajouter de nouveaux équipements sans dépendre de moi.
Points clés
Phase 1 · Constat et cadrage
Audit de l'existant : CSV non maintenu, versions multiples qui circulent, aucune traçabilité sur les mouvements en stockroom. Décision de migrer vers ServiceNow CMDB. Périmètre : 350+ équipements Cisco/Meraki (MS, Catalyst, MR46, Palo Alto, IoT MT10) + contrats.
Phase 2 · Définition des attributs
Audit des attributs critiques par type d'équipement : MAC Address, Serial Number, modèle précis, statut et date de fin de garantie, localisation (site, bâtiment, rack). Consultation des PO ServiceNow et réseau pour arbitrer les compromis.
Phase 3 · Data mapping
La phase la plus complexe : les champs JSON de l'API Meraki ne correspondent pas aux tables strictes de ServiceNow. Animation des réunions de sync pour définir la correspondance champ par champ. Cas particuliers : model_id, localisation physique absente de l'API, serial numbers manquants.
Phase 4 · Pilotage Agile (Product Owner)
Gestion via Jira en tant que PO : création et suivi des tickets, itérations à chaque changement de besoin, points réguliers avec les équipes IT et Finance. Projet étalé sur environ un an en raison des réorganisations successives de l'équipe ServiceNow.
Phase 5 · Intégration et alerting
Load initial des 350+ équipements et contrats, puis loads incrémentaux via fichier template normalisé. Alerting dégressif sur les fins de contrat : 3 mois, 1 mois, 2 semaines, 48 h avant échéance.
Phase 6 · Documentation et transfert
Rédaction de l'article KB : architecture de la donnée, logique de correspondance des champs, procédure complète pour ajouter de nouveaux équipements sans dépendre de ma disponibilité.
Résultats et lendemains
La table est aujourd'hui opérationnelle et est le point d'entrée fiable pour le suivi de notre parc Cisco/Meraki. L'équipe IT a enfin une visibilité totale sur l'historique et les mouvements des matériels en stockroom. Lors des incidents, le support gagne un temps précieux : les informations de garantie, de firmware et les localisations exactes de nos 350 équipements sont immédiatement accessibles depuis ServiceNow, sans avoir à croiser les sources manuellement.
La prochaine étape visée est l'automatisation complète via l'API ServiceNow : synchronisation directe depuis Meraki, sans intervention manuelle à chaque ajout ou retrait d'équipement. À terme, l'intégration pourrait alimenter des tableaux de bord de monitoring en temps réel, pour passer d'un inventaire statique à une visibilité dynamique du parc réseau. Un format "docs-as-code" versionné sur Git pour la documentation de l'architecture de données est également envisagé, pour garantir la traçabilité des évolutions du schéma.
Points clés
Source de vérité opérationnelle
Fin du CSV multi-versions. Point d'entrée fiable pour le suivi du parc Cisco/Meraki, visibilité totale sur l'historique et les mouvements en stockroom.
Gain de temps sur les incidents
Garantie, firmware et localisation exacte des 350+ équipements accessibles immédiatement depuis ServiceNow, sans croiser les sources manuellement.
Alerting dégressif actif
Mails de warning 3 mois, 1 mois, 2 semaines, 48 h avant échéance de contrat, plus jamais de renouvellement manqué.
KB de transfert
Procédure complète pour ajouter du matériel dans la CMDB sans dépendre de ma disponibilité. N'importe quel membre de l'équipe peut intervenir.
Mon regard critique
Sur ce projet, la technique était la partie simple. Le data mapping champ par champ, ça se fait. La difficulté, c'était d'aligner deux équipes qui ne parlent pas le même langage (réseau d'un côté, ITSM de l'autre), sur une durée d'environ un an, avec des réorganisations à absorber en cours de route. J'ai endossé le rôle de Product Owner pour garder le cap.
Sur la partie automatisation, j'aurais aimé aller plus loin : synchronisation directe Meraki → ServiceNow via API, sans passer par un fichier template. Ce n'était pas possible, l'équipe ServiceNow n'était pas prête. On a mis en place le fichier template normalisé comme solution intermédiaire, fonctionnel, mais pas idéal. C'est l'étape d'après.
Points clés
Gestion de projet transverse sur ~1 an
Réorganisations successives de l'équipe ServiceNow absorbées sans perdre le fil, le pilotage Agile a été le fil conducteur.
Le vrai défi : deux équipes, deux référentiels
La technique sous-jacente était simple. La difficulté : aligner réseau et ServiceNow sur une même modélisation de données, champ par champ.
Enseignement clé
Un bon ingénieur en architecture SI sait structurer le travail, définir un besoin précis, et piloter une livraison fonctionnelle de bout en bout.
Limite technique : automatisation conditionnée
L'automatisation complète via API ServiceNow est prévue, mais bloquée côté équipe ServiceNow. Le fichier template normalisé est la solution intermédiaire.
Compétences mises en œuvre
Points clés
Gestion d'équipements réseau
Référent technique réseau, audit du parc Cisco/Meraki, définition des attributs critiques à intégrer.
Organisation & méthodologie
Pilotage Agile via Jira, Product Owner, itérations, coordination entre équipes aux référentiels différents.
Documentation technique
Rédaction de l'article Knowledge Base pour les futurs ajouts de matériels dans la CMDB.
Automatisation & scripting
Data mapping et extraction des données Meraki vers ServiceNow, template d'ajout incrémental réutilisable.
Collaboration & travail d'équipe
Animation des réunions de synchronisation, arbitrages de data mapping entre équipes aux référentiels différents.