C’était un mardi soir pluvieux en novembre dernier, le genre de soirée où l’on se demande pourquoi on n’a pas choisi un métier plus calme. J'étais accroupi dans le local technique, une lampe torche entre les dents, à essayer de déchiffrer une étiquette de Service Tag à moitié effacée sur un vieux serveur Dell. Mes yeux me brûlaient à force de fixer ces petits caractères gris sur fond noir. C'est là, dans l'odeur de poussière chaude et le bruit sourd de la ventilation du serveur, que j'ai pris une décision : plus jamais ça. J'allais enfin ouvrir cette formation Python que j'avais achetée sur un coup de tête trois mois plus tôt.
Je ne suis pas développeur. Je suis Romain, le gars qu’on appelle quand l'imprimante fait des siennes ou que le switch du deuxième étage décide de faire grève. Mon truc, c’est le réseau et le support de proximité. Mais ce soir-là, l'idée de passer encore des heures à remplir un fichier Excel à la main pour l'inventaire annuel m'a poussé à bout. Je voulais que la machine travaille pour moi, pas l'inverse.
Le premier contact : entre enthousiasme et frustration
Après trois semaines de tutoriels intensifs, j'ai réalisé que Python, c’est un peu comme une recette de cuisine. Si vous oubliez le sel, le plat est raté. Si vous mettez une majuscule là où il faut une minuscule, le script explose. La formation que j'ai suivie commençait doucement, mais elle est vite entrée dans le vif du sujet : comment faire parler Windows ?
C'est là que j'ai découvert Windows Management Instrumentation (WMI). Pour nous les techniciens, c’est une mine d’or. C’est comme si chaque composant de l’ordinateur avait son propre petit dossier médical que l’on peut consulter à distance. La formation expliquait comment utiliser une bibliothèque Python spécifique pour interroger ce système. Mais avant d'en arriver là, j'ai mangé mon pain noir.
Je me souviens d'un après-midi de rush au bureau, vers la mi-février. J'essayais de faire tourner un script tout simple pour récupérer le modèle de la carte mère. L'écran s'est soudainement rempli de rouge à cause d'une simple erreur d'indentation. Pour ceux qui ne connaissent pas, Python est une brute : si vos lignes ne sont pas parfaitement alignées, il refuse de bosser. Ça m'a rappelé que le code est bien plus pointilleux que mes notes de support habituelles où je peux gribouiller un truc vite fait. Là, c’était le silence radio du programme tant que je n'avais pas corrigé mon petit décalage de quatre espaces.
Parler à Windows avec Python 3.12
Pour mon projet, j'ai utilisé la version stable de Python 3.12. La formation insistait beaucoup sur le fait de rester à jour pour profiter des dernières améliorations de performance. Le but était simple : écrire un script qui se connecte à chaque PC du réseau, demande poliment le numéro de série au BIOS, et enregistre tout ça dans un fichier CSV propre, respectant le standard RFC 4180.
Le CSV, c’est un peu le langage universel de l'informatique. C’est juste du texte avec des virgules, mais ça permet à Excel de comprendre les données sans faire de caprice. Dans la formation, on nous apprenait à utiliser le module csv intégré à Python. C'est simple, efficace, et ça évite de s'embêter avec des bibliothèques externes trop lourdes. C'est exactement ce que je cherche : des outils légers qui font le job.
Mais pour que Python puisse parler aux autres PC, il doit passer par un tuyau. Ce tuyau, c’est le protocole Remote Procedure Call (RPC), et il utilise généralement le port 135. C'est là que les choses deviennent sérieuses pour un tech réseau. Ouvrir des ports, c'est comme laisser une fenêtre entrouverte dans une maison : ça laisse entrer l'air, mais aussi les cambrioleurs si on ne fait pas attention.
Le déclic : quand le premier numéro s'affiche
Le moment de vérité est arrivé un après-midi de rush au bureau. J'avais enfin fini de configurer mon environnement virtuel (un petit espace isolé pour que mon script ne sème pas la pagaille dans le reste de l'ordinateur). J'ai lancé la commande. Mon cœur battait un peu plus vite, comme quand on redémarre un switch central après une mise à jour de firmware.
Pendant quelques secondes, rien. Puis, une ligne est apparue. Puis deux. Puis dix. Les numéros de série de tous les postes de l'étage défilaient sur mon écran sans que je n'aie à bouger de ma chaise. C'était magique. J'avais passé des mois à apprendre les bases de l'automatisation, et là, je voyais le résultat concret. J'ai compris que je n'avais plus besoin d'être un ingénieur pour apprendre Python pour automatiser son réseau quand on est technicien.
Cependant, la formation m'a aussi montré ses limites. Elle expliquait très bien comment coder le script, mais elle passait un peu vite sur les droits administrateur nécessaires. Pour interroger le WMI d'un poste distant, il faut des privilèges élevés. Si vous n'êtes pas admin du domaine, votre script se fera jeter par Windows comme un malpropre. C'est le genre de détail qu'on n'apprend qu'en se cassant les dents sur le terrain.
L'envers du décor : pourquoi WMI n'est pas parfait
C'est ici que je vais être un peu plus critique que le formateur de ma vidéo. Dans le cours, on nous présente WMI comme la solution miracle pour l'inventaire. C'est vrai, ça marche. Mais avec le recul et mes lectures sur les forums de sécurité, j'ai réalisé une chose importante : extraire les numéros de série via WMI est une mauvaise pratique dans un environnement de production moderne.
Pourquoi ? Parce que pour laisser passer ces requêtes, vous devez laisser le port 135 et une plage de ports dynamiques ouverts sur vos postes de travail. C'est une surface d'attaque énorme. Un pirate qui arrive à s'introduire sur votre réseau va adorer que le RPC soit activé partout, car cela lui permet de se déplacer latéralement très facilement. La formation ne m'avait pas prévenu de ce risque. Elle se concentrait sur le "comment faire" sans trop s'attarder sur le "est-ce prudent de le faire".
Aujourd'hui, je préfère utiliser PowerShell ou passer par des agents d'inventaire plus sécurisés, mais l'exercice m'a énormément appris sur la structure de Windows. Si vous débutez, c'est un super projet pour comprendre comment les données circulent, mais ne déployez pas ça sur 500 machines sans en parler à votre responsable sécurité.
Mon bilan sur cette formation Python
Alors, est-ce qu'un débutant devrait commencer par là ? Oui, mais avec de la patience. La formation m'a permis de passer du stade de "je subis mon inventaire" à "je comprends comment automatiser mes tâches". Ce n'est pas du temps perdu, même si je n'utilise plus exactement le même script aujourd'hui. Cela m'a aussi ouvert des portes pour d'autres projets, comme analyser des journaux de logs réseaux avec une formation Python concrète afin de repérer des erreurs de connexion avant que les utilisateurs ne m'appellent.
Ce que j'ai aimé :
- Les exercices concrets sur des vrais cas de support informatique.
- La clarté sur l'utilisation des bibliothèques système.
- Le fait de ne pas avoir besoin de bases en maths pour réussir.
Ce qui m'a manqué :
- Plus d'infos sur la sécurité et les alternatives à WMI.
- Des conseils sur la gestion des erreurs réseau (quand un PC est éteint, par exemple).
En résumé, si vous en avez marre de vous abîmer les yeux sur des étiquettes poussiéreuses, Python est un allié de poids. Ne vous laissez pas impressionner par le côté "codeur". Au fond, c'est juste une nouvelle boîte à outils pour nous, les techniciens. Prenez le temps de faire les exercices, acceptez que votre écran devienne rouge de temps en temps, et vous verrez que la satisfaction de voir un script tourner vaut bien quelques soirées de galère.