Cinquante fichiers de logs ouverts sur le même écran, et une seule ligne qui compte vraiment. Je suis technicien support, pas développeur, et je passe pourtant une bonne partie de mes soirées à comparer des adresses IP poste par poste, à la main. C'est cette corvée précise qui m'a poussé vers une formation JavaScript pensée pour l'automatisation en support technique, pas vers un cursus classique de développeur web. Un technicien n'a pas besoin de jolies animations sur une page, il a besoin d'un script qui trie le bruit à sa place.
Le JavaScript, un outil caché pour le support technique
On associe souvent ce langage à des boutons qui changent de couleur sur une page, ou à des animations un peu gadgets. C'était mon avis aussi, avant de creuser le sujet. Avec Node.js, le JavaScript est sorti du navigateur pour s'installer directement sur nos postes de travail, et pour un technicien, ça change beaucoup de choses.
La plupart des outils de supervision ou de gestion de parc que j'utilise au quotidien recrachent leurs données au format JSON, et le JSON, c'est un peu la langue maternelle du JavaScript. Savoir manipuler ce langage, c'est pouvoir lire, filtrer et transformer n'importe quel rapport de diagnostic sans ouvrir un tableur à la main. Je ne cherchais pas à devenir développeur web, seulement un technicien un peu mieux armé face à la répétition.
Choisir une formation JavaScript sans tomber dans le piège du Full Stack
Pendant les vacances de fin d'année, j'ai épluché pas mal de catalogues de formation-javascript. Le souci, c'est que la majorité des cursus vendent du « devenez développeur Full Stack en quelques mois », maquettes CSS et frameworks front en prime. Quand on bosse déjà à temps plein en support, réapprendre à aligner des boutons sur une page n'a aucun intérêt. J'ai fini par choisir un programme centré sur la logique pure et l'environnement Node.js, sans fioritures.
J'ai installé la version LTS de Node.js, celle qui ne lâche pas en plein milieu d'un script en production. Le programme ne demandait aucune connaissance préalable en code, mais il ne prenait pas non plus les débutants pour des enfants : variables, boucles, lecture de fichiers sur le disque, dans cet ordre. Pour un support, lire un fichier tout seul, c'est déjà énorme. Imaginez un script qui parcourt cinquante fichiers de logs à votre place et n'affiche que les lignes contenant une erreur.
Avant de me lancer, j'ai hésité avec d'autres langages. Cyril, un contact avec qui j'échange mes notes de cours sur un document partagé, m'avait prévenu : il lit toujours les commentaires des autres apprenants avant même de regarder le plan d'une formation, et ça change souvent son choix final. J'avais fini par trancher la question moi-même dans un article sur le fait de savoir s'il faut apprendre Python ou JavaScript pour travailler dans le support. Pour moi, le JavaScript l'a emporté sur la rapidité d'exécution face aux flux de données web.
Pourquoi l'asynchrone bloque presque tout le monde
Tout n'a pas été simple. Je bloquais sur un concept que toute la communauté JS adore et redoute à la fois : la programmation asynchrone, l'idée qu'un script peut lancer une tâche, comme interroger un serveur distant, et continuer autre chose en attendant la réponse. Dans le monde réseau, le principe du ping ne pose de problème à personne, mais en code, ça devient vite un casse-tête. On se retrouve avec des « promesses » partout, un peu comme quand on commande un burger : on vous tend un bipeur, vous retournez vous asseoir, et quand il vibre, vous allez chercher votre commande.
Vers la sixième semaine, ce blocage a fini par céder, pas d'un coup, plutôt par petites touches, exercice après exercice. Avant même d'en arriver là, j'avais tenté d'apprendre Python en solo, avec la documentation officielle en anglais ouverte à côté du clavier. Ça n'a pas tenu trois soirs : trop dense, trop théorique, personne pour recontextualiser. Cette fois, avec une formation construite autour du JavaScript et rien d'autre, j'ai fini par comprendre que le maîtriser demandait une gymnastique mentale que mes cours sur les bases des réseaux informatiques ne m'avaient pas préparé à affronter.
Mon script s'est emballé en pleine nuit
Il faut que je raconte ma plus grosse boulette de l'époque. Je voulais un petit outil qui m'envoie une alerte mail quand un service tombe. Une erreur dans ma boucle, une boucle infinie, et voilà mon terminal qui défile à toute vitesse. Le ventilateur de la tour s'est mis à ronfler comme au démarrage d'une machine virtuelle, ce bruit précis que je reconnais maintenant les yeux fermés, et j'ai compris en une seconde que j'étais en train d'inonder ma propre boîte mail de notifications.
Résultat : plusieurs centaines de mails en moins d'une minute, mon client mail qui a fini par planter, et une explication un peu gênante à donner à l'admin système le lendemain pour la charge inutile sur le serveur de messagerie. Depuis, avant de laisser tourner n'importe quel script, je fixe des limites très strictes, presque paranoïaques. L'automatisation multiplie tout, y compris les bêtises.
Faut-il tout automatiser en support technique ?
C'est ici que mon avis diverge un peu de ce qu'on apprend en cours. Beaucoup de formations poussent à tout automatiser, mais avec l'expérience du terrain, j'ai compris une chose : automatiser ses diagnostics via JavaScript ne sert à rien si on ne commence pas par restreindre drastiquement les logs générés en amont. Si le script doit brasser des gigaoctets de données inutiles pour trouver une seule ligne intéressante, on perd du temps, même si c'est la machine qui s'en charge.
Ma méthode de dépannage réseau n'a pas changé sur le fond, seul l'outillage a évolué : ce sont surtout les vérifications de base qui sont désormais automatisées, histoire d'arriver plus vite au vrai problème. Configurer mes équipements pour qu'ils ne soient bavards que sur ce qui compte, puis laisser Node.js faire le tri final, cette combinaison change tout. Ne cherchez pas à coder un outil qui analyse tout, cherchez plutôt un outil qui élimine le bruit.
Le déclic sur le diagnostic du port 443
Après un bon moment de pratique régulière, j'ai enfin écrit un script vraiment utile : lire un fichier de configuration listant des URLs critiques, puis vérifier que le port standard HTTPS répondait bien avec un code de succès. La première fois que mon terminal a renvoyé, ligne pour ligne, exactement ce que le formateur affichait dans sa vidéo de démonstration, j'ai su que je ne récitais plus un exercice : je comprenais enfin ce qui se passait derrière.
Ce qui me prenait une demi-heure à vérifier à la main sur chaque poste se fait maintenant en quelques secondes, une liste propre qui s'affiche dans le terminal. Si vous hésitez encore, jetez un œil à mon article sur comment utiliser une formation Python pour automatiser ses tâches de technicien : l'automatisation des tâches répétitives n'est pas propre à un seul langage, et l'approche reste assez complémentaire. Le JavaScript est plus nerveux sur le web, Python garde ses forces côté système.
Cette formation convient-elle à un débutant ?
Si vous démarrez de zéro en informatique, ne commencez pas par le JavaScript. Apprenez d'abord comment fonctionne un réseau : ce qu'est une adresse IP, un peu de routage et de commutation, et les grands protocoles qu'on utilise tous les jours sans y penser. Ce socle-là compte plus qu'on ne le croit, et je n'ai pas encore attaqué de mon côté la préparation d'une certification Cisco, ça viendra sans doute plus tard.
Ceux qui sont déjà en poste, qui en ont marre des tâches répétitives et qui n'ont pas peur de passer quelques soirées à s'arracher les cheveux sur des accolades mal placées, eux, je leur dis de foncer. J'ai croisé Lucille, ma voisine de palier reconvertie dans le développement web, un samedi matin place Sainte-Anne, café à la main ; elle m'a encore envoyé un message détaillé après la dernière formation que je lui avais conseillée, comme à chaque fois. Tout ce que j'ai construit sur JavaScript, je l'ai fait en autoformation, entre deux tickets, un rythme qui ne convient pas à tout le monde.
Verdict : oui, mais pas pour n'importe qui. La formation que j'ai suivie n'a pas fait de moi un ingénieur, et ce n'était pas le but recherché. Elle m'a surtout donné l'autonomie pour ne plus dépendre d'outils tout faits qui ne collent jamais exactement à mes besoins du moment. Un collègue m'a demandé récemment comment je traite mes tickets de diagnostic aussi vite : la réponse tient en une phrase, j'ai appris à déléguer les corvées à un script de quelques lignes plutôt qu'à mes deux mains.