Get-SystemMapping.ps1 : l'état des lieux complet d'un poste, sans rien oublier

Il y a un réflexe qu'on prend tous, débutant : noter ce qu'on voit au fur et à mesure qu'on avance dans une intervention. Le problème, c'est que ce qu'on note "au fur et à mesure" oublie toujours un truc. Une tâche planifiée louche qu'on n'a pas pensé à vérifier. Un disque dont on n'a jamais regardé l'état de santé réel. Get-SystemMapping.ps1 part d'un principe différent : tout collecter d'un coup, dans l'ordre, sans rien zapper, puis ranger ça dans deux documents qui ne se ressemblent pas du tout. Voilà comment il s'y prend, et pourquoi le plus dur n'était pas de tout récupérer, mais de savoir quoi laisser de côté.

Pourquoi un inventaire complet plutôt qu'une vérification au cas par cas

Voici ce qui se passe quand tu vérifies un poste "à l'instinct" : tu regardes ce qui te semble pertinent sur le moment, en fonction du symptôme qu'on t'a décrit. Sauf que le truc qui explique vraiment le problème est parfois ailleurs, dans une section que tu n'avais aucune raison de regarder ce jour-là. Get-SystemMapping.ps1 retourne le problème : il collecte tout, par défaut, et c'est à toi de décocher ce qui ne t'intéresse pas, pas l'inverse.

Concrètement, le script propose onze sections au lancement : la machine et son système, la RAM jusqu'au détail de chaque barrette, les disques (volumes et santé physique), le réseau actif, les partages réseau montés, les imprimantes, les logiciels installés (classiques et applications Microsoft Store), les services tiers qui démarrent automatiquement, les tâches planifiées qui ne viennent pas de Microsoft, et les certificats du magasin personnel. Tout est coché par défaut. Tu décoches seulement ce qui ne t'intéresse pas pour cette intervention précise.

Le vrai travail n'est pas de tout montrer, c'est de savoir quoi cacher

Ton premier réflexe en lisant "inventaire complet" serait de penser qu'un bon script de cartographie liste absolument tout ce qu'il trouve. En fait, c'est l'inverse : un inventaire qui montre tout, sans filtre, devient illisible. Windows fait tourner des centaines de services et des dizaines de tâches planifiées juste pour exister. Si le rapport les liste tous, le technicien doit lui-même refaire le tri à la main, et le script n'a servi à rien.

Sur la section des services, le script ne retient que ceux dont l'exécutable ne vit pas dans les dossiers système de Windows lui-même. Sur les tâches planifiées, il exclut tout ce qui est rangé sous le chemin Microsoft interne. Le résultat n'est pas "tout ce qui existe sur ce poste", c'est "tout ce qui a été ajouté par quelqu'un d'autre que Windows". C'est cette ligne de filtre qui transforme une liste de deux cents entrées en une liste de cinq ou dix, celles qui méritent vraiment un coup d'œil.

Pourquoi le disque physique se vérifie de deux façons différentes

Voici un piège classique quand on écrit un script qui doit tourner sur n'importe quel poste : utiliser uniquement la commande la plus moderne, et planter sur les postes plus anciens où elle n'existe pas. Pour lire l'état de santé des disques physiques, Windows propose une commande récente qui donne une vraie évaluation de santé (bon état, attention, défaillant). Mais elle n'est pas disponible partout, en particulier sur certaines configurations plus anciennes ou limitées.

Get-SystemMapping.ps1 essaie d'abord cette commande moderne. Si elle échoue, il bascule automatiquement sur l'ancienne méthode, plus basique, qui donne au moins le modèle et la taille du disque sans l'évaluation de santé. Le lecteur du rapport ne voit jamais l'échec intermédiaire, juste le tableau rempli avec ce qui a pu être récupéré.

Pourquoi deux fichiers, et pas un seul

Voici l'erreur facile à faire : produire un seul rapport et l'envoyer tel quel au client. Le problème, c'est qu'un rapport assez détaillé pour être utile à un technicien (tableaux complets, numéros de série, chemins d'exécutables) est souvent imbuvable pour un client qui veut juste comprendre l'état général de son poste.

Get-SystemMapping.ps1 tranche en produisant deux fichiers à partir des mêmes données collectées : un fichier technique brut (.md) qui garde tout, sans mise en forme particulière, pour celui qui doit creuser ou comparer dans le temps, et un fichier PDF mis en forme proprement, pensé pour être montré ou envoyé tel quel. Les deux viennent de la même collecte, donc aucune incohérence possible entre les deux versions.

Le PDF se génère via un navigateur en mode invisible (Chrome en priorité, Edge en repli), exactement comme pour la conversion d'un rapport de diagnostic batterie déjà vue sur ce site. Si aucun des deux n'est trouvé sur le poste, le script le signale franchement et garde le rapport technique disponible : pas de PDF cassé, juste l'absence honnête d'un format en plus.

Ce que tu fais en vrai, concrètement

• Lance le script en administrateur, certaines sections (disques physiques, certains services) demandent ce niveau pour donner une information complète.
• Décoche les sections qui ne t'intéressent pas pour cette intervention précise, plutôt que de tout laisser tourner par automatisme.
• Indique un nom de client ou de poste, ça sert uniquement à classer le rapport dans un dossier daté.
• Choisis où ranger le résultat : disque "outils" si tu en as un, sinon le Bureau fonctionne très bien.
• Laisse tourner sans toucher au clavier, la collecte prend quelques dizaines de secondes selon les sections cochées.
• Garde le .md pour toi, et envoie le .pdf si tu dois montrer l'état des lieux à quelqu'un d'autre.

Voilà ce qu'il y a dans la boîte : pas un inventaire qui note tout en vrac, mais un inventaire qui sait déjà ce qui mérite d'être regardé deux fois, et qui le présente sous deux formes selon qui va le lire.