Il y a un moment précis où ce script existe : tu as un portable client qui "ne tient plus la charge", et tu dois trancher en cinq minutes entre "batterie morte" et "rien à voir, c'est un réglage". Le faire à la main, c'est trois commandes, deux rapports HTML à lire en diagonale, et un calcul de pourcentage que tu fais de tête en croisant les doigts. Le script fait exactement la même chose, mais il croise tout, calcule tout, et te donne un verdict écrit noir sur blanc. Voilà comment il s'y prend, et pourquoi il a fallu plus de tentatives que prévu pour qu'il marche vraiment partout.

Pourquoi un seul outil plutôt que trois commandes à la main

Voici ce que tu risques si tu diagnostiques une batterie à la main, sous pression, devant le client ou en atelier avec dix postes qui attendent : tu oublies une étape, tu lis mal un chiffre, ou tu donnes un verdict à l'instinct alors que la donnée existait déjà dans Windows. Diag_Batterie.ps1 existe pour supprimer cette marge d'erreur. Il lance dans l'ordre tout ce qu'un technicien ferait s'il avait le temps de tout faire proprement : lire la capacité de la batterie, générer le rapport d'historique Windows, chercher les causes logicielles, et si tu veux, mesurer une vraie décharge en direct.

Concrètement, une fois lancé, le script demande le nom du client, te propose où ranger le rapport (un disque "outils" si tu en as un branché, le Bureau, ou un chemin libre), puis tourne seul pendant que tu fais autre chose. À la fin, tu as un dossier complet : le rapport, ses annexes techniques, un fichier PDF prêt à envoyer.

l'image à garder

C'est la différence entre faire l'inventaire d'un magasin rayon par rayon avec un carnet, et appuyer sur un bouton qui scanne tout le magasin d'un coup et imprime le rapport. Même résultat, mais l'un prend vingt minutes de concentration, l'autre tourne pendant que tu bois ton café.

Ce que le script va chercher, et pourquoi il ne se contente jamais d'une seule source

Voici le piège que la plupart des scripts trouvés en ligne ne gèrent pas : ils supposent que toutes les données seront toujours là. Sur le terrain, ce n'est jamais vrai. Certains firmwares de constructeurs n'exposent pas le compteur de cycles. Certains postes n'ont pas le module WMI étendu activé. Un script qui plante à la première donnée manquante, c'est un script que tu ne peux pas utiliser en confiance chez un client.

Diag_Batterie.ps1 est construit en cascade : il essaie d'abord la source la plus fiable (le module WMI étendu), et si elle est absente, il va chercher la même information ailleurs, dans le rapport HTML généré par powercfg /batteryreport, puis dans le XML brut si même le HTML est incomplet. Le lecteur, lui, ne voit jamais l'échec : juste le résultat final, avec une mention discrète de la source utilisée.

// à retenir

Aucune étape du script ne s'arrête sur un échec partiel. Une donnée manquante est contournée, jamais bloquante. C'est ce qui permet de le lancer sur n'importe quel Windows 10/11, n'importe quelle marque, sans savoir d'avance ce que le firmware va bien vouloir donner.

Ton premier réflexe en lisant "trois sources de repli en cascade" serait de penser que c'est de la sur-ingénierie pour un simple diagnostic batterie. En fait, c'est l'inverse : un script de diagnostic qui ne gère qu'un seul cas de figure n'est fiable que sur les postes qui correspondent exactement à ce cas. Sur le parc varié d'un technicien (marques, âges, firmwares différents), c'est cette redondance qui transforme un script "qui marche chez moi" en outil qu'on peut vraiment déployer chez n'importe quel client.

Le test de décharge en direct : la mesure qui confirme ou contredit le calcul théorique

Le compteur d'usure et l'historique Windows donnent une estimation. Mais une estimation reste une estimation. Le script propose, en option, un vrai test : débrancher le chargeur, choisir une durée entre 5 et 60 minutes, et regarder la batterie se vider en direct, pourcentage par pourcentage, à l'écran.

À la fin du test, le script ne se contente pas d'afficher "il a perdu X%". Il convertit cette perte en énergie réelle consommée (en mWh, pas juste en pourcentage), projette l'autonomie complète que ça donnerait depuis une pleine charge, et la compare directement à l'estimation tirée de l'historique Windows sur plusieurs semaines. Si les deux chiffres se rejoignent, le diagnostic est solide. S'ils divergent fortement, c'est le signal qu'autre chose (une appli en tâche de fond, une synchronisation lancée pendant le test) a faussé la mesure du moment.

l'image à garder

C'est comme comparer la consommation d'essence annoncée par le constructeur et celle que tu mesures vraiment sur un plein. Si l'écart est petit, tu fais confiance au chiffre du constructeur. Si l'écart est énorme, ce n'est pas le moteur qui a un problème : c'est ta façon de conduire ce jour-là qu'il faut regarder.

  1. Débrancher le chargeur avant de lancer le test, le script le vérifie et te bloque sinon.
  2. Choisir une durée, 10 minutes suffisent pour une mesure exploitable.
  3. Laisser tourner, le script affiche la charge en temps réel pendant le test.
  4. Lire la confrontation finale entre la mesure directe et l'estimation longue durée, affichée automatiquement.

Pourquoi le verdict final n'est jamais un simple "bon" ou "mauvais"

Voici l'erreur facile à faire en écrivant ce genre d'outil : réduire la sortie à un seul critère, par exemple l'usure en pourcentage, et juger toute la batterie sur ce seul chiffre. Le script ne fait pas ça, et c'est volontaire.

Une batterie peut afficher une usure faible et pourtant donner une autonomie réelle catastrophique, ou inversement, une usure élevée mais une autonomie encore tout à fait correcte pour l'usage du client. Le verdict croise donc l'usure calculée ET l'autonomie réelle mesurée, et seulement après ça regarde les causes logicielles annexes : plan d'alimentation gourmand, luminosité d'écran élevée, erreurs détectées par le rapport énergétique de Windows, top 5 des processus qui consomment le plus de CPU au moment du diagnostic. Le rapport final liste ces pistes une par une, pas juste un chiffre brut.

la règle terrain

Le verdict du script n'est jamais "remplace la batterie" tout court. C'est toujours "voilà l'état réel, et voilà ce qui pourrait expliquer le ressenti du client si la batterie elle-même n'est pas en cause."

Ce que tu fais en vrai, concrètement

Voilà ce qu'il y a dans la boîte : pas de magie, juste toutes les étapes qu'un bon diagnostic batterie demande, enchaînées sans qu'aucune ne soit oubliée sous la pression d'un planning serré.

// l'outil à emporter
Diag_Batterie.ps1 — script PowerShell

Tu le poses sur le poste, tu le lances, c'est fait. Disponible sur Ko-fi, gratuit.

Télécharger — gratuit

Sources

Ce site est gratuit et le restera. Si un truc t'a aidé et que tu veux soutenir, tu peux m'offrir un café. Et si tu prends juste l'outil et que tu files, c'est très bien aussi.