Il est un peu plus de minuit, un soir de novembre bien pluvieux près de Rennes, et je suis encore devant mon écran. Sur mon bureau, une tasse de café vide dont le fond a séché depuis deux heures. J'ai une cinquantaine de fichiers de logs ouverts. Ma mission ? Identifier pourquoi une série de postes clients n'arrive pas à joindre notre serveur de base de données. Je passe mon temps à copier-coller des adresses IP d'un terminal à un tableur Excel. Mes yeux brûlent. C'est là que je me suis dit : « Romain, tu ne peux pas passer ta carrière à faire le travail d'un robot. »
Pourquoi un tech support devrait s'intéresser au JavaScript
Quand on parle de JavaScript, on pense tout de suite à des boutons qui changent de couleur sur un site web ou à des animations un peu gadgets. C'est ce que je pensais aussi avant de creuser le sujet. Mais en réalité, avec l'arrivée de Node.js, le JavaScript est sorti du navigateur pour s'installer sur nos machines de travail. Pour un technicien comme moi, c'est devenu un outil de couteau-suisse incroyable.
Le gros avantage, c'est que presque tous les outils modernes qu'on utilise en supervision ou en gestion de parc crachent des données au format JSON. Le JSON, c'est la langue maternelle du JavaScript. Si vous savez manipuler ce langage, vous savez lire, filtrer et transformer n'importe quel rapport de diagnostic sans même ouvrir un éditeur de texte. C'est ce qui m'a poussé à chercher une formation-javascript sérieuse, mais pas pour devenir développeur web. Je voulais juste être un technicien « augmenté ».
Le choix de la formation : Éviter le piège du 'Full Stack'
Pendant la trêve des confiseurs, j'ai passé pas mal de temps à éplucher les catalogues. Le problème, c'est que 90 % des cours vous vendent du « Devenez développeur Full Stack en 3 mois ». Entre nous, quand on bosse déjà 39 heures par semaine en support, on n'a pas envie de réapprendre à faire des maquettes CSS. J'ai finalement opté pour un cursus qui mettait l'accent sur la logique pure et l'environnement Node.js.
J'ai installé la version 20 de Node.js, qu'on appelle aussi la version LTS (Iron). C'est la version stable, celle qui ne va pas vous lâcher en plein milieu d'un script de prod. Ce qui m'a plu, c'est que la formation ne demandait pas de connaissances préalables en code, mais elle ne nous prenait pas non plus pour des enfants. On a commencé par les bases : les variables, les boucles, et surtout, comment lire un fichier sur le disque. Pour un tech support, c'est le Graal. Imaginez un script qui scanne vos 50 fichiers de logs à votre place et ne vous affiche que les lignes qui contiennent une erreur.
Au début, j'ai hésité avec d'autres langages. D'ailleurs, si vous vous posez la question, j'avais écrit un petit topo sur le fait de savoir s'il faut apprendre Python ou JavaScript pour travailler dans le support. Pour moi, le JavaScript l'a emporté à cause de sa rapidité d'exécution sur les flux de données web.
La phase de douleur : Les promesses et l'asynchrone
Tout n'a pas été rose. Fin mars, au retour des beaux jours, j'ai bien failli tout plaquer. Je bloquais sur un concept que tous les développeurs adorent : la programmation asynchrone. En gros, c'est l'idée que votre script peut lancer une tâche (comme interroger un serveur distant) et continuer à faire autre chose en attendant la réponse.
Dans le réseau, on comprend bien le principe du ping, mais en code, c'est un casse-tête. On se retrouve avec des « promesses » partout. C'est un peu comme quand vous commandez un burger : on vous donne un bipeur (la promesse). Vous retournez vous asseoir (le script continue), et quand le bipeur vibre, vous allez chercher votre burger (le résultat). J'ai mis deux semaines à piger comment ne pas me mélanger les pinceaux. C'est là que j'ai compris que maîtriser le JavaScript demandait une certaine gymnastique mentale que mes cours sur les bases des réseaux informatiques ne m'avaient pas préparé à affronter.
Le moment de panique : Quand le script s'emballe
Il faut que je vous raconte ma plus grosse boulette. C'était un soir d'avril. Je voulais créer un petit outil qui m'envoyait une alerte par mail quand un service tombait. J'ai fait une erreur dans ma boucle, une « boucle infinie ». J'ai lancé le script et, en l'espace de quelques secondes, j'ai vu mon terminal défiler à une vitesse folle. J'ai ressenti ce moment de panique pure quand j'ai réalisé que j'étais en train d'inonder ma propre boîte mail de notifications.
Résultat : 500 mails en moins d'une minute. Mon client mail a planté, et j'ai dû aller m'excuser auprès de l'admin système le lendemain parce que j'avais fait grimper la charge du serveur de mail pour rien. Ça m'a appris une leçon fondamentale : avant d'automatiser quoi que ce soit, il faut toujours tester avec des limites très strictes. L'automatisation, c'est un multiplicateur de force. Si vous faites une bêtise, elle est multipliée par mille.
L'angle mort : Pourquoi trop d'automatisation tue l'efficacité
C'est ici que mon avis diverge un peu de ce qu'on apprend en cours. La formation vous pousse à tout automatiser. Mais avec l'expérience du terrain, j'ai compris une chose : automatiser vos diagnostics via JavaScript est totalement inutile si vous ne commencez pas par restreindre drastiquement les logs générés. Si votre script doit mouliner 10 Go de données inutiles pour trouver une ligne intéressante, vous perdez du temps, même si c'est la machine qui travaille.
Mon approche aujourd'hui, c'est de configurer mes équipements pour qu'ils soient bavards uniquement sur ce qui compte, puis de laisser Node.js faire le tri final. C'est cette combinaison — réglage fin du réseau + script de tri — qui fait la différence. Ne cherchez pas à coder un outil qui analyse tout, cherchez à coder un outil qui élimine le bruit.
Le déclic : Le script de diagnostic Port 443
Après environ deux mois de pratique assidue, j'ai enfin écrit mon premier script vraiment utile. L'idée était simple : lire un fichier de configuration contenant une liste d'URLs critiques et vérifier si le Port standard HTTPS (443) était bien ouvert et répondait avec un Code d'état HTTP succès (200).
Ce qui me prenait une demi-heure à vérifier manuellement sur chaque poste client se fait désormais en deux secondes. Je lance la commande, et le terminal m'affiche une liste propre. Je me souviens encore du reflet bleu de mon écran sur ma tasse de café vide à minuit, alors que le terminal affichait enfin 'Success' en vert pour tous les tests. C'était une petite victoire, mais pour moi, c'était le signe que j'avais passé un cap. Je n'étais plus seulement celui qui subit les problèmes, j'étais celui qui construit ses propres outils pour les résoudre.
Si vous hésitez encore, je vous conseille de jeter un œil à mon article sur comment utiliser une formation Python pour automatiser ses tâches de technicien, car l'approche est assez complémentaire. Le JavaScript est plus nerveux pour le web, mais Python a ses forces pour le système pur.
Bilan : Est-ce que ça vaut le coup pour un débutant ?
Si vous commencez 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 et comment circulent les paquets. Mais si vous êtes déjà en poste, que vous en avez marre des tâches répétitives et que vous n'avez pas peur de passer quelques soirées à vous arracher les cheveux sur des accolades mal placées, alors foncez.
La formation que j'ai suivie n'a pas fait de moi un ingénieur, et ce n'était pas le but. Elle m'a donné l'autonomie nécessaire pour ne plus dépendre des outils tout faits qui ne correspondent jamais exactement à mes besoins. Aujourd'hui, quand un collègue me demande comment je fais pour traiter mes tickets de diagnostic si vite, je lui réponds simplement que j'ai appris à déléguer les corvées à un script de quelques lignes. C'est ça, la vraie magie du code en support technique : regagner du temps pour les problèmes qui demandent vraiment de la réflexion humaine.