Rapproche les inventaires et traite les doublons sans perdre l'historique

L’idée reçue

« Deux machines avec le même serial sont forcément le même actif. »

Le serial est une preuve forte, mais il peut être vide, mal remonté, cloné dans une image, modifié après réparation ou réutilisé par erreur. La décision doit combiner plusieurs indices et l’historique.

01Définis l’ordre de confiance

1. type + serial non vide
2. type + UUID non vide
3. type + MAC stable
4. nom + entité comme signal faible

Le type fait partie de la clé. Un écran et un ordinateur ne doivent pas être rapprochés uniquement parce qu’ils partagent une valeur mal renseignée.

02Observe le doublon exact

INV-001,ORL-PC-001,...,SN-DL-001,UUID-DL-001,00:11:22:33:44:01,...,08:00
INV-002,orleans-pc-001,...,SN-DL-001,UUID-DL-001,00:11:22:33:44:01,...,09:00

Les trois identifiants concordent. Le plan produit :

MERGE_HISTORY_KEEP_NEWEST

Cela signifie conserver la fiche ou l’inventaire de référence le plus récent tout en transférant les informations et relations validées. Ce n’est pas une suppression aveugle.

03Observe le conflit ambigu

INV-003,...,SN-HP-014,UUID-HP-014,00:11:22:33:44:14
INV-007,...,SN-HP-014-R,UUID-HP-014,00:11:22:33:44:15

L’UUID correspond, mais serial et MAC diffèrent. Plusieurs explications sont possibles :

- remplacement de carte mère
- clone de machine virtuelle
- erreur de firmware
- copie d'image avec identifiant dupliqué
- deux actifs distincts mal inventoriés

Le plan impose :

MANUAL_REVIEW_PRESERVE_BOTH

04Rassemble les preuves avant fusion

identifiants matériels
historique des inventaires
utilisateur et lieu
relations avec tickets et contrats
logiciels et composants
date de dernière remontée
journal de réparation ou remplacement
source de l'inventaire

Une fusion qui détruit tickets, documents, contrats ou historique est plus grave que le doublon initial.

05Utilise quatre décisions explicites

UPDATE_EXISTING
- même actif, nouvelle remontée cohérente

MERGE_HISTORY_KEEP_NEWEST
- doublon certain, fiche de référence choisie

MANUAL_REVIEW_PRESERVE_BOTH
- indices contradictoires ou impact important

CREATE_NEW
- aucune identité forte correspondante

Chaque décision doit produire un auteur, une date, des preuves et un rollback.

06Exécute le laboratoire

bash module2-glpi-assets-inventory.sh run "$lab"
column -s, -t "$lab/output/duplicate-candidates.csv"
column -s, -t "$lab/output/reconciliation-plan.csv"

Résultat attendu : exactement deux candidats, un rapprochement fort et un conflit conservé pour revue.

07Vérifie l’immutabilité des sources

cat "$lab/evidence/source-immutability.diff"
sha256sum -c "$lab/evidence/source-checksums-after.sha256"

Le diff doit être vide. Le lab fabrique des sorties et des recommandations, mais ne modifie jamais les données d’entrée.

08Prépare la procédure sur GLPI réel

1. sauvegarder base et fichiers
2. exporter les deux fiches et leurs relations
3. identifier la fiche de référence
4. documenter le mapping des champs
5. tester sur clone de la base
6. vérifier tickets, contrats, documents et historique
7. exécuter pendant une fenêtre contrôlée
8. valider puis conserver la preuve

Projet du lot 2

Présente un rapport de qualité du parc

Fournis la taxonomie, les référentiels, la matrice de tags, le plan agent, les inventaires normalisés, les candidats au rapprochement et la justification de chaque décision. Aucun actif ambigu ne doit être supprimé.

✓Lot 2 terminé

Tu sais structurer les actifs, normaliser les référentiels, préparer GLPI Agent et traiter les anomalies d’identité sans sacrifier l’historique.