Le terminal affiche la liste des fichiers temporaires à effacer, ligne après ligne, sans que j'aie à taper une seule commande. Le script tourne seul sur une machine de test. Je repense aux purges de logs que je faisais encore à la main il y a peu — toute une automatisation IT née d'une formation Python suivie en marge de mon poste de technicien support, et devenue mon terrain de scripting serveur préféré.
Avant d'aller plus loin : certains liens de cet article sont affiliés, et si vous passez par eux pour acheter une formation, je touche une petite commission, sans surcoût pour vous. Je ne recommande que ce que j'ai testé moi-même, modules compris.
Ma règle de tri, après coup : si une purge ou un nettoyage revient chaque semaine sous la même forme, ça vaut le coup de la scripter avec Python ; si c'est un cas isolé, mieux vaut garder la main dessus plutôt que de passer une soirée à l'automatiser. C'est tout l'intérêt de cette formation, et c'est aussi sa limite — elle vous apprend à automatiser, pas à savoir quand s'en abstenir.
Ce que la formation couvre vraiment avant de scripter quoi que ce soit
La Formation au langage Python [Bon complément] ne vous jette pas dans la théorie des structures de données complexes dès le premier module. On commence par des exercices de calcul simples, puis on glisse vers la manipulation de fichiers et de répertoires — exactement ce qui m'intéressait pour mes histoires de serveurs. Les bases de variables et de fonctions sont détaillées ailleurs sur ce site, donc je ne vais pas réexpliquer ici comment Python stocke une valeur ou découpe un traitement en blocs réutilisables ; je préfère vous dire ce que ça donne une fois appliqué à un vrai dossier de logs. Même chose pour la logique conditionnelle : bien posée dans le cours, mais ce n'est pas le sujet de cet article.
Le déclic, chez moi, n'est pas venu d'un chapitre entier mais d'une phrase du formateur comparant une boucle de suppression à un tri de linge sale, pièce par pièce, plutôt qu'un sac jeté en vrac dans la machine : d'un coup, la logique du parcours de fichiers avait un sens concret. Pour un technicien habitué à taper des commandes une par une, c'est un peu comme découvrir qu'on peut programmer une machine à laver au lieu de rester planté devant à tourner les boutons soi-même.
Pourquoi Python plutôt qu'un bricolage de commandes Bash ?
Avant cette formation, j'avais tenté un MOOC en anglais sur la programmation système, et j'ai abandonné au bout de quelques semaines : trop de vocabulaire technique d'un coup, pas assez d'exemples qui parlaient à un technicien support plutôt qu'à un étudiant en informatique. Repartir sur un cours en français, pensé pour quelqu'un qui vient du helpdesk, a changé la donne. Le choix entre Python et JavaScript comme première porte d'entrée mérite son propre comparatif ailleurs sur ce site ; pour mes scripts de serveur, Python s'est imposé simplement parce que la bibliothèque réseau dont j'avais besoin tournait dessus sans complication.
Après quatre ans à dépanner des réseaux et des postes sans avoir jamais touché à un vrai langage de programmation, je ne suis pas parti d'une feuille blanche : je savais déjà ce qu'un script devait accomplir, juste pas comment l'écrire. Un copain qui joue dans un groupe de musique amateur me demandait souvent pourquoi je n'automatisais pas ces tâches qui revenaient sans arrêt ; je n'avais simplement pas les outils pour ça. Les soirs où le code refusait d'entrer, j'allais courir au Parc des Gayeulles pour décompresser, et je revenais souvent avec la solution plus claire en tête que devant l'écran.
Automatiser le nettoyage sans détruire les preuves
Un reproche que je ferais à pas mal de tutoriels trouvés en ligne : ils vous poussent à tout automatiser pour ne plus jamais voir une alerte de disque plein, sans jamais mentionner ce qu'on perd en chemin. Si le script purge les journaux d'accès chaque nuit pour gagner de la place, et qu'une intrusion a eu lieu la semaine précédente, les traces dont on aurait besoin pour comprendre ce qui s'est passé disparaissent avec le reste. L'analyse fine de ces journaux réseau est un sujet à part entière, traité en détail ailleurs sur ce site ; ici, je me contente de la règle que j'applique moi-même : archiver avant de supprimer, toujours.
La sécurisation d'un réseau dépasse largement ce qu'un script Python peut couvrir seul, et je ne vais pas prétendre le contraire. Ce que je fais, en revanche, c'est coupler ces connaissances avec d'autres outils, comme on le voit en détail quand on cherche à organiser ses fichiers de sauvegarde automatiquement avec un script Python. Un bon réflexe de support technique, selon moi, consiste à toujours garder une marge de sécurité plutôt que de viser le disque parfaitement vide.
Mettre en place le script : SSH, seuils de disque et CRON
Techniquement, voici ce que fait le script une fois les bases du cours digérées. Il se connecte en SSH (22) à la machine cible grâce à la bibliothèque `paramiko`, vérifie l'occupation du disque, repère les dossiers temporaires vieux de plus de trente jours, puis m'envoie un résumé avant de proposer la purge — jamais après. Sur une distribution comme Ubuntu, Python 3 est déjà installé, donc aucune bataille d'installation côté serveur cible, ce qui compte quand on gère plusieurs machines à la fois.
Avant de laisser un script supprimer quoi que ce soit en production, je fais tourner une version qui affiche d'abord ce qu'elle va effacer, sans rien supprimer réellement : un chemin de répertoire mal concaténé ou un slash oublié, et la liste à effacer peut déraper largement au-delà de ce qui était visé. Cette vérification rapide évite une restauration de sauvegarde complète. Une fois ce test passé, le job CRON prend le relais : le script déplace les vieux fichiers vers un stockage froid et ne supprime que ce qui est sans valeur, comme les sessions web expirées, jamais un journal critique. Le seuil qui déclenche l'alerte chez moi reste simple à retenir : au-delà de 90 % d'occupation disque, il est déjà temps d'agir, pas d'attendre.
Ce qui manque encore à cette formation
Le point faible, et je ne vais pas y aller par quatre chemins : la gestion des erreurs plus complexes reste traitée en surface. Quand le script plante parce qu'un fichier est verrouillé par un autre processus, il faut aller fouiller la documentation officielle, en anglais, pour comprendre ce qui bloque. C'est un bon complément à une base de support technique, pas un remplacement de l'expérience de terrain accumulée sur de vrais incidents.
Autre limite, plus structurelle : une fois les vidéos terminées, le suivi s'arrête net. Pas de communauté active, pas de retour sur vos propres scripts, pas de projet plus ambitieux pour aller au-delà du nettoyage de base. Pour qui veut automatiser un inventaire de parc informatique ou pousser plus loin la logique de ses scripts, il faudra chercher ces réponses ailleurs — un sujet que je laisse d'ailleurs à un autre article de ce site, centré sur l'inventaire automatisé.
À qui s'adresse cette formation, et à qui non
Si vous êtes technicien support, à l'aise avec le réseau mais tétanisé devant une page de code vide, cette formation est un point d'entrée raisonnable. Elle ne vous transforme pas en développeur du jour au lendemain, mais elle suffit à sortir des tâches répétitives qui mangent vos soirées de garde. En revanche, si les bases réseau ne sont pas encore solides, mieux vaut commencer par la Formation Cisco : réseaux et systèmes [Mon premier choix] : c'est elle qui m'a permis de comprendre ce qui se passe réellement derrière un port ouvert ou une passerelle mal configurée, avant même d'écrire la première ligne de script.
Il m'arrive encore de buter sur un script qui n'atteint pas un serveur distant, et de devoir revenir à mes bases réseau pour résoudre les pannes de connectivité complexe. La méthode pour diagnostiquer ce genre de panne mérite son propre article détaillé ; retenez simplement que code et réseau sont les deux faces d'un même métier, pas deux compétences séparées. Les critères qui permettent de juger si une formation IT tient vraiment la route méritent eux aussi un article à part — ici, je me limite à mon retour sur celle-ci, suivie sur mon temps personnel, un peu comme on apprendrait à conduire : d'abord les commandes du véhicule, ensuite seulement la circulation dense.
Si le sujet vous parle, regardez d'abord les premières vidéos gratuites avant de vous engager : c'est ce qui m'a permis de voir si le style du formateur me convenait, avant même de penser au reste.
Résultat concret au quotidien : moins d'interventions de nuit pour « disque plein », moins de fautes de frappe dans mes commandes de purge, et un peu de recul en plus sur mon propre métier de support. Rien de spectaculaire. Verdict, pour un technicien qui veut cesser de refaire chaque semaine la même purge à la main : oui. Pour quelqu'un qui cherche une vraie formation de développeur, clairement pas assez. Je ne suis toujours pas développeur, et je n'ai pas vraiment l'ambition de le devenir ; mais aujourd'hui, quand un serveur approche de son seuil critique, je lance le script, je vérifie ce qu'il va toucher, et je retourne à autre chose.