Situation Professionnelle : Data Injection — Import massif CMDB (GLPI)

1. Contexte et Objectifs

Dans la continuité de l'opération Solutech-Horizon, le groupe a absorbé l'Agence Nova : 45 collaborateurs et 52 actifs (postes et serveurs) doivent être intégrés dans GLPI avant la fin de la semaine. Leo, technicien de proximité à l'Agence Horizon, ne peut pas tout ressaisir manuellement.

J'ai été chargé d'industrialiser l'alimentation de la CMDB : préparer les sources CSV, configurer l'injection, importer utilisateurs puis parc, traiter les erreurs et valider par recette. L'enjeu n'est pas d'importer vite, mais d'importer juste — une CMDB erronée fausse les tickets, les contrats de maintenance et le MCO.

2. Besoins identifiés

• Massification fiable : Intégrer des dizaines de lignes sans ressaisie manuelle ni perte de cohérence.
• Traçabilité patrimoine : Chaque poste doit être lié à un utilisateur, une entité (Agence Nova) et un numéro de série unique.
• Qualité des données : Normaliser encodage, séparateurs, listes (fabricants, entités) avant tout passage en production.
• Exploitabilité support : Permettre à un technicien d'ouvrir un ticket sur un matériel Nova sans ambiguïté.
• MCO continu : Supporter les mises à jour incrémentales (imports delta) sans réimport complet.

3. Solution technique retenue et justifications

Pour répondre à ces besoins sur la plateforme GLPI déjà en place (entités Solutech-Horizon) :

• Chaîne d'import CSV structurée (UTF-8, séparateur ;) :
  • Justification : Format reproductible pour RH et parc ; les fichiers utilisateurs_nova_READY.csv et parc_nova_READY.csv servent de référence pour les prochaines fusions.
• Modèle d'injection avec mapping explicite :
  • Justification : Chaque colonne source (login, serial, entite…) est documentée vers un champ GLPI. Cela évite les corruptions massives liées à un mauvais mapping.
• Principe « Simulation avant Production » :
  • Justification : Validation sur échantillon ou mode test avant l'import réel — une erreur de mapping peut dupliquer des centaines d'actifs.
• Ordre d'exécution Utilisateurs → Parc :
  • Justification : Les liens utilisateur/matériel du parc nécessitent des comptes déjà présents en base.
• Charte qualité CMDB et journal de fiabilisation :
  • Justification : Cinq règles documentées (série obligatoire, entité normalisée, etc.) et trace datée des rejets pour justifier chaque correction auprès du jury E5.
• Recette en trois scénarios (ticket, recherche série, import delta) :
  • Justification : Prouve que la CMDB est exploitable par le support et résistante à une mise à jour incrémentale (utilisateurs_nova_DELTA.csv, parc_nova_DELTA.csv).

---

4. Réalisation (Ce que j'ai fait)

1. Audit et préparation des sources (Étape A) : Ouverture des fichiers bruts utilisateurs_nova.csv et parc_nova.csv, détection des anomalies (casse login NOVA04, entité agence nova, fabricant DELL, série vide), production des versions *_READY.csv et tableau de mapping colonnes → GLPI.
2. Configuration du modèle d'import : Définition des correspondances pour utilisateurs (login, nom, prenom, email, entite, profil) et parc (name, serial, type, fabricant, modele, entite, utilisateur, statut).
3. Import massif des utilisateurs (Étape B) : Exécution en mode contrôlé (simulation puis production), affectation à l'entité Agence Nova, vérification des fiches utilisateurs importées.
4. Import massif du parc (Étape C) : Intégration des 52 lignes (45 postes affectés, 5 serveurs, 2 postes en stock), contrôle des liens utilisateur et des numéros de série.
5. Fiabilisation (Étape D) : Contrôles croisés (comptages par entité), traitement des doublons et rejets, journal de fiabilisation (3 entrées minimum documentées).
6. Recette finale (Étape E) : Création d'un ticket d'incident avec élément de parc Nova associé, recherche par numéro de série, import delta (2 utilisateurs + 1 poste) sans réimport complet.
7. Livrables documentaires : Charte qualité CMDB (5 règles), tableau de mapping, journal de fiabilisation et dossier de captures pour le portfolio.

---

5. Preuves de réalisation finale

Cinq preuves obligatoires (captures légendées). Les productions de travail dans fichiers/CMDB sont des annexes vérifiables liées sous chaque preuve — elles ne comptent pas comme preuves supplémentaires.

Preuve 1 — Audit / nettoyage

Ce que je contrôle : anomalie détectée dans les sources Nova et correction retenue dans le journal de fiabilisation.
Pourquoi c'est important en entreprise : l'import repose sur des données nettoyées et chaque décision de reprise est justifiable.

Annexe vérifiable : audit_sources.csv · corrections_tracees.csv · controles_avant_import.csv · ecarts_et_decisions.csv

Preuve 2 — Import plugin (fichier READY)

Ce que je contrôle : rapport Data Injection indiquant que le fichier READY a été importé sans erreur bloquante.
Pourquoi c'est important en entreprise : un import propre limite les incidents de support et évite d'alimenter la CMDB avec des données incohérentes.

Annexe vérifiable : utilisateurs_nova_READY.csv · parc_nova_READY.csv

Preuve 3 — Delta sans doublon

Ce que je contrôle : la vague Delta met à jour ou ajoute les éléments attendus sans créer de doublon (comptage final).
Pourquoi c'est important en entreprise : la CMDB reste fiable dans le temps et peut absorber de nouvelles vagues de reprise.

Annexe vérifiable : rapport(s) Delta déposés dans fichiers/CMDB (si produits en fichier)

Preuve 4 — API REST (serveurs Nova)

Ce que je contrôle : exécution PowerShell réussie (Succès : 5 / 5) ou rapport CSV confirmant les 5 serveurs Nova créés via l'API REST.
Pourquoi c'est important en entreprise : l'automatisation réduit les saisies manuelles et garantit une traçabilité des créations techniques.

Annexe vérifiable : Inject-GLPI-Servers.ps1 (tokens masqués) · rapport CSV API (rapport_upsert_api_*.csv) dans fichiers/CMDB

Preuve 5 — Recette support

Ce que je contrôle : un ticket GLPI lié à PC-NOVA-001 ou SRV-NOVA-006.
Pourquoi c'est important en entreprise : le support peut relier l'incident au bon équipement et suivre l'historique de traitement.

(Aucune annexe fichier obligatoire — la capture du ticket suffit.)

Preuves optionnelles (max. 2)

+1 Mapping détaillé

Capture du mapping si un choix technique doit être justifié.

+2 Baseline / série

Recherche unique SRV2026-008 ou extrait de baseline.

Annexe vérifiable : baseline (baseline_agence_nova_*.csv) dans fichiers/CMDB

---

6. Bilan et lien avec les autres SP

Parcours réalisé	Lien avec Data Injection
Gestion du parc informatique	Entités, agents, gouvernance GLPI — socle technique
FAQ / Shift-Left	Leo, Agence Horizon — exploitabilité des données importées
Data Injection (cette SP)	Alimentation massive et fiabilisation de la CMDB

Preuves et annexes alignées sur le livrable 99-Livrable-Portfolio-CMDB-DATA-Injection (parcours SIO U5 — CMDB DATA Injection).