Un soir de novembre dernier, alors que le crachin rennais commençait à bien tremper les rues, je m’étais enfin posé dans mon canapé. C’est exactement à ce moment-là que mon téléphone a vibré : un utilisateur en colère parce qu’un switch de l’agence de Cesson-Sévigné était tombé depuis trois heures. Trois heures de silence radio de mon côté, parce que je n’avais aucun moyen d’être prévenu automatiquement. J’étais aveugle.
C’est ce soir-là que j’ai compris que le monitoring manuel, c’est un piège. On se dit qu’on va vérifier les voyants en passant, ou qu’on verra bien les logs le lendemain. Mais quand on est seul pour gérer un parc, on ne peut pas être partout. J’ai donc décidé de me lancer dans une formation Python, non pas pour devenir développeur chez Google, mais juste pour créer un script capable de crier à ma place quand un équipement lâche.
Pourquoi une formation Python plutôt qu’un logiciel tout fait ?
Au début, je me suis demandé s’il ne valait pas mieux installer un gros logiciel de supervision. Mais pour des petites structures ou des besoins très spécifiques, c’est souvent sortir l’artillerie lourde pour écraser une mouche. En suivant ma formation, j’ai découvert que Python est un peu comme un couteau suisse : on n’a pas besoin de connaître toutes les lames, il suffit de savoir déplier celle qui nous intéresse. Pour moi, c’était l’automatisation simple.
Dans les premières vidéos de la formation, on nous apprend les bases, mais ce qui m’intéressait vraiment, c’était de faire parler mon ordinateur avec le réseau. J’ai vite compris que Python utilise des « bibliothèques », qui sont comme des boîtes d’outils pré-remplies par des gens bien plus malins que moi. Au lieu de réinventer la roue, on appelle une fonction et le travail est fait à moitié.
Mes premiers pas avec le module subprocess
Fin février, j’ai atteint le module sur les interactions avec le système. C’est là que j’ai découvert subprocess. C’est un outil qui permet à Python de taper des commandes dans le terminal à votre place. Pour vérifier si un équipement est en vie, la méthode la plus simple reste le « ping ». En gros, votre script envoie un petit paquet de données et attend de voir s’il revient.
C’est là que j’ai appris un truc technique important : le protocole ICMP. Pour que le ping fonctionne, le script envoie une requête de type 8 (ICMP Echo Request). Si le switch d’en face reçoit ce paquet, il est censé répondre. Pendant mes tests, je me suis amusé à regarder la taille des paquets. On parle souvent de la MTU standard de 1500 octets, qui est la taille maximale d’un paquet sur un réseau Ethernet classique. Si votre paquet est trop gros ou si le réseau est saturé, ça coince. Mon petit script, lui, se contentait de paquets minuscules pour ne pas encombrer la bande passante.
Je me souviens d’un samedi matin où je testais mon code sur un vieux routeur de récup. J’ai passé la matinée à pester contre mon script qui ne détectait rien, pour finalement réaliser que j'avais écrit « loclahost » au lieu de « localhost » dans mon fichier de configuration. Une simple faute de frappe qui m'a fait douter de tout mon apprentissage. C’est le genre de moment où l’on se sent un peu bête, mais c’est comme ça qu’on apprend vraiment.
Le passage du script à l’outil concret
Après environ six semaines de code à raison d’une heure par-ci par-là, j’ai enfin vu mon terminal réagir en direct. J’avais débranché un câble exprès et, soudain, la fenêtre de commande s’est mise à clignoter. Je me rappelle encore la lueur bleue de la fenêtre du terminal qui se reflétait sur mon mug de café alors que je voyais enfin le statut passer de « Status: UP » à un gros « Status: DOWN » écrit en rouge dans mon propre code. C’était une petite victoire, mais pour un technicien support, c’est un sentiment incroyable de voir qu’on peut construire ses propres outils.
Si vous voulez aller plus loin dans la gestion de vos équipements, j’avais aussi écrit un retour sur comment analyser des journaux de logs réseaux avec une formation Python concrète, ce qui complète bien la simple détection de panne par ping.
L’étape cruciale : l’alerte par email
Détecter une panne, c’est bien. Être prévenu sur son téléphone quand on est en train de faire ses courses, c’est mieux. C’est là que la formation est devenue vraiment intéressante avec le module smtplib. C’est la bibliothèque qui gère l’envoi d’emails. On apprend à configurer une connexion sécurisée avec un serveur de messagerie.
Pour que ça fonctionne, il faut utiliser le port de soumission SMTP standard, le 587, qui permet l’envoi de mails avec un chiffrement STARTTLS. C’est beaucoup plus sûr que les vieux ports qui envoyaient tout en clair. J’ai aussi dû me pencher sur la structure d’un paquet IPv4. Même si on ne manipule pas directement l’en-tête IPv4, qui fait au minimum 20 octets, comprendre comment les données sont encapsulées aide à comprendre pourquoi certains mails ne partent pas à cause des pare-feux de l’entreprise.
C’est cette partie qui m’a vraiment sauvé la mise. Une fois que j’ai réussi à lier ma détection de panne à l’envoi d’un mail, mon script n’était plus un simple exercice de cours, c’était un vrai gardien. La première fois que j’ai reçu une alerte réelle, en début d’été, j’ai pu appeler le client avant même qu’il ne remarque que sa connexion internet avait sauté. Ça change totalement la relation avec les utilisateurs : on ne subit plus la panne, on la gère.
Le revers de la médaille : pourquoi Python n’est pas toujours la solution
C’est ici que je vais être un peu à contre-courant de ce qu’on entend souvent. On vous vend Python comme la solution à tous vos problèmes d’automatisation. Mais avec le recul, je me dois d’être honnête : n’utilisez pas de scripts Python pour surveiller votre réseau de production sur le long terme. C’est un excellent exercice d’apprentissage, mais c’est souvent instable.
Mon script, par exemple, consommait parfois plus de ressources que nécessaire parce que je l’avais mal optimisé. De plus, il générait pas mal de faux positifs. Si ma propre machine se mettait à ramer ou si une micro-coupure de WiFi survenait sur mon poste de monitoring, je recevais une alerte de panne alors que tout allait bien sur le switch. Les outils natifs dédiés (comme Zabbix, PRTG ou même Nagios) sont conçus pour éviter ces erreurs. Ils gèrent bien mieux les files d’attente et les vérifications multiples avant de lancer une alerte.
Cependant, apprendre à le faire soi-même est indispensable. Ça permet de comprendre comment ces outils fonctionnent sous le capot. Aujourd’hui, quand je configure une sonde sur un logiciel pro, je sais exactement ce qu’est un timeout ou un intervalle de scrutation, parce que je les ai codés à la main. Python m'a aussi permis de générer des rapports de tickets plus vite, ce qui est un usage bien plus stable et rentable de mes compétences en scripting au quotidien.
Ce que je retiens de cette expérience
Si vous êtes technicien support et que vous hésitez à prendre une formation Python, mon conseil est simple : n’attendez pas d’avoir une certification ou d’être un « expert » pour commencer à bricoler des petits outils. Python n’est pas réservé aux ingénieurs. C’est une compétence qui transforme votre manière de voir le réseau. On passe de celui qui répare à celui qui anticipe.
La formation que j’ai suivie m’a parfois perdu, notamment sur les concepts de programmation orientée objet, mais j’ai simplement sauté les chapitres qui me semblaient trop théoriques pour me concentrer sur le concret : les bibliothèques réseau et l’envoi de notifications. C’est ça l’avantage de se former seul, le soir : on prend ce dont on a besoin pour résoudre nos problèmes du lendemain au bureau.
Au final, mon script de monitoring tourne encore sur un vieux PC dans un coin, mais il me sert surtout de « backup » sentimental. Pour le reste, j’utilise des outils pro, mais avec une compréhension technique que je n’aurais jamais eue sans avoir mis les mains dans le cambouis du code pendant ces quelques mois.