Les outils d'e

Vue globale

┌───────────────────────────────┐
│ Postes Windows (clients)       │
│ - Script PowerShell (.ps1)     │
│ - Exécution planifiée (Task)   │
│ - Export JSON                 │
└───────────────┬───────────────┘
                │ HTTPS (POST JSON)
                ▼
┌───────────────────────────────┐
│ API d’ingestion (REST)         │
│ Node.js/Express ou PHP/Flask   │
│ - Validation du payload        │
│ - Auth (token/API key)         │
│ - Normalisation des champs     │
└───────────────┬───────────────┘
                │ Write
                ▼
┌───────────────────────────────┐
│ Stockage (historisation)       │
│ - SQL (Postgre/MySQL)          │
│   ou                           │
│ - NoSQL (MongoDB)              │
│ - Série temporelle (InfluxDB)  │
└───────────────┬───────────────┘
                │ Read
                ▼
┌───────────────────────────────┐
│ Dashboard / Supervision        │
│ - Web (tableaux, filtres)      │
│ - Grafana (metrics)            │
│ - Alerting (seuils, notif)     │
└───────────────────────────────┘

Détail “poste client”

PowerShell (poste)
  ├─ Collecte (CIM/WMI, cmdlets réseau, fichiers)
  ├─ Traitements (filtrer, trier, top N)
  ├─ Structuration (objet -> JSON)
  ├─ Envoi (Invoke-RestMethod / HTTP POST)
  └─ Journalisation (logs locaux + code retour)

Détail “serveur”

API REST
  ├─ Endpoint /ingest (POST)
  ├─ Authentification (API key par poste / par groupe)
  ├─ Validation schéma (champs attendus + types)
  ├─ Déduplication (clé machine + timestamp)
  ├─ Écriture DB (inventaire + historique)
  └─ Déclenchement alertes (règles)

Cas réel

Contexte

Une école/PME possède 65 postes Windows répartis en :

• salles de cours/bureaux (utilisation quotidienne)
• quelques postes “spéciaux” (graphisme / labo)
• un réseau mixte Ethernet + Wi-Fi
• un parc hétérogène (différentes générations de machines)

Objectifs du service IT :

• connaître rapidement l’inventaire matériel et logiciel
• détecter les postes en manque d’espace disque
• repérer des machines instables (services arrêtés, charge anormale)
• avoir un historique pour justifier un remplacement (pannes, vieillissement)

Contraintes réalistes :

• pas d’agent lourd à déployer au début
• priorité à une solution simple, robuste, maintenable
• respect des droits (exécution standard si possible, admin seulement si nécessaire)

Solution mise en place

Collecte côté postes (PowerShell planifié)

Chaque poste exécute un script .ps1 via Task Scheduler :

• fréquence : 1×/jour pour l’inventaire “statique” (OS, CPU, RAM, BIOS, logiciels)
• fréquence : toutes les 30–60 min pour la “surveillance légère” (disques, services clés, top processus)

Le script :

• collecte les blocs A/B/F + les blocs attribués (stockage, réseau, services…)
• applique des traitements simples : filtres (seuil en octets), tris, Top N
• produit un JSON structuré
• envoie le JSON en HTTPS vers l’API centrale

Bonnes pratiques appliquées :

• horodatage (timestamp) + identifiant machine (hostname)
• gestion d’erreur : si l’API est indisponible → log local + retry au run suivant
• limitation du volume : Top N pour éviter des payloads énormes

API centrale (ingestion)

Le serveur expose un endpoint unique, par exemple :

• POST /api/ingest

Fonctions :

• authentification (API key associée à un poste ou une salle)
• validation minimale : champs obligatoires présents, formats corrects
• normalisation : noms de champs, unités (bytes), cohérence des blocs
• écriture en base (inventaire courant + historique)

Stockage et historisation

Deux stratégies typiques :

SQL (PostgreSQL/MySQL)

• tables séparées : devices, snapshots, volumes, adapters, packages, services, processes_top
• fort contrôle (contraintes, jointures, rapports)

NoSQL (MongoDB)

• un document “snapshot” par poste et par exécution (JSON natif)
• très flexible, rapide à implémenter
• idéal si le schéma évolue (nouveaux blocs, nouveaux champs)

Dans un premier déploiement, on choisit souvent MongoDB pour aller vite, puis on migre vers SQL si besoin de reporting strict.

Dashboard et alerting

Le dashboard permet :

• vue parc : liste de postes + statut (OK / attention / critique)
• vue poste : historique + détails par bloc
• filtres : par salle, par modèle, par OS, par état réseau

Alertes simples (exemples réalistes) :

• volume système avec freeSpaceBytes < seuil
• service critique “arrêté” (si bloc services)
• ping passerelle échoué plusieurs fois (si bloc connectivité)
• top process mémoire anormalement élevé (si bloc performance)

Notifications :

• mail au support
• ou tableau “incidents à traiter”

Exemple d’incident et exploitation de l’historique

Un utilisateur se plaint : “le PC est lent depuis une semaine”.

Le technicien consulte :

• évolution de freeSpaceBytes (disque système qui se remplit rapidement)
• liste Top N fichiers dans Téléchargements (fichiers très lourds)
• top processus mémoire (application qui consomme trop)

Action :

• nettoyage ciblé + sensibilisation (bonnes pratiques stockage)
• si récurrent : règle d’alerte “disque < seuil” + procédure préventive

Ce que le jury attend typiquement à l’oral

• expliquer la différence inventaire vs monitoring
• justifier pourquoi PowerShell est adapté (objets/pipeline/CIM)
• expliquer la chaîne complète : poste → API → DB → dashboard
• justifier l’historisation (diagnostic, preuves, tendances)
• parler sécurité : auth, HTTPS, minimisation des données, logs