Tron Script : un entretien découpé en étapes numérotées, chacune désactivable
Résumé
Aucun bouton, seulement un fichier de commandes qui déroule des étapes numérotées, journalise chacune et laisse chacune se désactiver en ligne de commande. Une passe complète demande officiellement de 3 à 10 heures.
Recommander- Nom
- Tron Script
- Version
- 12.0.6
- Tarif
- Gratuit
- Open source
- Open source
- Système
- Windows
- Mis à jour
- 2026-10-06 15:34
Les outils de nettoyage font en général la même chose : ils emballent l'entretien qu'on devrait faire dans un bouton. Ce script va plus loin et retire aussi le bouton, il ne reste qu'un fichier de commandes. La page d'accueil du dépôt le dit sobrement, un script de nettoyage automatique de l'ordinateur. L'explication de l'auteur : il s'est lassé de lancer ces utilitaires à la main, un par un, alors il a mis la série entière en script pour que le nettoyage et la désinfection d'une machine Windows se fassent tout seuls. Le nom vient d'une formule sur le combat mené pour l'utilisateur, la licence est une licence libre permissive, et le dépôt a accumulé 2611 commits, 6600 étoiles et 416 duplications.

Il travaille par étapes, pas par boutons
Les notes du projet découpent tout le déroulé en étapes numérotées, chacune avec son fichier de commandes, et l'auteur précise que ces sous-scripts peuvent tourner seuls, sans le script principal. La description et le dossier des ressources en donnent la forme. L'étape de préparation crée un point de restauration, prend avant le lancement un instantané des programmes installés et du disque entier pour permettre une comparaison ensuite, vérifie l'interface de gestion du système et tente de la réparer, cale l'horloge sur une source de temps du réseau, sauvegarde la base de registre et appelle plusieurs outils anti-malveillants extérieurs en avant-passe. Le nettoyage des fichiers temporaires et la déduplication forment des étapes à part, l'étape de désinfection rassemble l'analyse des virus et des rootkits, et la défragmentation est placée vers la fin.
Cette conception a un bénéfice pratique : quand quelque chose se passe mal, le retrouver est facile. Les journaux sont tenus par étape, le journal principal s'écrit par défaut dans un dossier de journaux sur le disque système, si bien que l'étape qui a calé et ce que chaque étape a modifié se consultent. Pour une machine qui demande un entretien répété, la traçabilité vaut bien plus qu'un message annonçant que l'optimisation est terminée.
Trois avertissements écrits dans les notes
Le premier : redémarrer avant. En capitales, les notes exigent un redémarrage pour laisser finir les mises à jour en attente, car si le script est à mi-chemin et que le système redémarre à cause d'une mise à jour suspendue, le système peut être abîmé. Cela ressemble à une phrase de manuel, mais avec des heures d'exécution encore devant, c'est une assurance nécessaire.
Le deuxième est la durée. Le chiffre officiel est de 3 à 10 heures d'attente, avec l'insistance qu'il faut vraiment ce temps et qu'il ne faut pas interrompre en route. L'observation de l'auteur va de 4 à 8 heures, et des utilisateurs ont rapporté une passe de 30 heures. Ce n'est donc pas un outil qu'on lance deux minutes, mais un traitement profond complet, et le conseil est de le lancer puis de le laisser. Le troisième est le mode : il tourne en mode sans échec ou en mode normal, et sauf infection grave, le mode normal est recommandé.

Commutateurs : chaque étape peut être coupée
Le script accepte pleinement l'appel en ligne de commande, tous les commutateurs étant facultatifs et combinables. Les commutateurs listés tombent en gros en trois familles. Comment lancer : un mode automatique qui saute l'écran d'accueil et les questions, un mode automatique avec redémarrage préalable en mode sans échec, une marche à blanc qui déroule le flux sans exécuter la moindre tâche, extinction à la fin, redémarrage à la fin. Ce qu'on coupe : sauter toutes les analyses antivirales, sauter un outil d'analyse précis, sauter les correctifs d'applications, sauter les scripts maison. Ce qu'on garde : garder les applications fournies avec le système, garder les réglages d'alimentation, garder un programme de sécurité précis.
Un commutateur mérite sa propre phrase : un vidage de configuration qui montre les réglages en cours, de quoi voir d'avance ce que le script ferait, et dès que ce paramètre est utilisé, le script n'exécute plus rien pour de bon. Pour une première rencontre avec un outil de ce genre, une marche à blanc ou un vidage de configuration d'abord est bien plus rassurant que de le laisser partir.
Une bizarrerie de versions et d'obtention
La page de publication donne la dernière version pour 12.0.6, avec 49 repères au total et un historique qui remonte jusqu'à la série 10. Curieusement, la note sous chaque version est la même phrase : les notes de publication et la manière de l'obtenir se trouvent sur la page communautaire correspondante, et le prendre depuis l'hébergeur de code ne fonctionnera pas. Les notes du projet répètent cela en capitales.

La raison : le dépôt ne contient que le texte source du script, alors que les outils et ressources extérieurs dont il dépend n'y sont pas, si bien que la source seule ne tourne pas. Autrement dit, l'hébergeur de code sert ici de lieu pour lire, examiner et contribuer, non de canal de distribution. Un autre détail montre le même décalage : le journal des changements à l'intérieur du dépôt atteint déjà 12.0.9, tandis que le repère le plus récent de la page de publication reste à 12.0.6.
À qui il convient, et ce qu'il faut surveiller
Trois publics. D'abord ceux qui doivent traiter des machines par lots, où un script permet une exécution sans surveillance et où les commutateurs rognent le flux au nécessaire. Ensuite les utilisateurs avancés qui préfèrent regarder avant d'agir, puisque le vidage de configuration et la marche à blanc montrent exactement ce qui sera touché et que les sous-scripts se retirent à part. Enfin les cas qui demandent une preuve après coup, où un journal complet étape par étape convainc davantage que n'importe quel message affirmant que la machine est optimisée.
Trois mises en garde. C'est une longue tâche, officiellement de 3 à 10 heures, et une interruption en route peut laisser un système à demi traité, donc vérifier avant que la machine peut tenir tout ce temps sans coupure de courant ni besoin de vous. Il modifie des réglages système de lui-même, dont la part du disque réservée aux points de restauration, les réglages d'alimentation et les applications fournies, donc décider d'avance si ces changements sont voulus, les notes offrant des commutateurs pour les garder. Et l'obtention est inhabituelle : la source chez l'hébergeur de code ne tourne pas seule, ce que le projet dit clairement dans le dépôt comme sur la page de publication.
Écrire l'entretien sous forme de script, c'est au fond passer de se souvenir comment faire à le laisser s'en souvenir. Ce qui s'est accumulé ici au fil des années n'est pas un algorithme ingénieux mais un ordre d'exécution reprisé encore et encore : sauvegarder avant de toucher, consigner avant de modifier, et laisser chaque étape désactivable seule. Ce labeur ingrat est précisément la part de l'automatisation qui tient.