Diagnostiquer une panne réseau chez un particulier et dépanner une baie de brassage professionnelle, ce sont deux métiers qui n'ont presque rien en commun. Le premier se règle souvent en éteignant la box trente secondes. Le second demande une méthode, sinon on tourne en rond pendant des heures devant un switch qui refuse de coopérer. C'est cette différence qui m'a poussé, comme technicien IT, vers une formation Cisco, après des années de dépannage réseau au flair, en autoformation, sans toujours savoir pourquoi telle manipulation marchait plutôt qu'une autre.
Ça fait quatre ans que j'exerce ce métier, en grande partie autodidacte, et les questions qu'on me pose avant d'acheter une formation Cisco reviennent presque toujours les mêmes. Autant y répondre franchement, dans l'ordre où elles se posent.
Faut-il être ingénieur réseau pour comprendre Cisco ?
Non, et c'est la première question qu'on me pose systématiquement. Le vocabulaire fait peur, les schémas ressemblent à des plans de métro, mais rien dans ce métier n'exige un diplôme d'ingénieur pour commencer à comprendre les bases du réseau informatique. Au début, j'avais acheté un manuel réseau bien trop technique pour un débutant ; je l'ai refermé au bout de quelques pages, perdu dans des définitions qui ne parlaient qu'à quelqu'un qui savait déjà de quoi il retournait.
Ce qui a débloqué les choses, c'est plus simple qu'un bouquin : le jour où j'ai regardé une adresse IP comme un numéro de rue accompagné d'un code postal, plutôt qu'une suite de chiffres à retenir par cœur, la moitié du jargon a arrêté de me résister. L'adressage IP, une fois qu'on a cette image en tête, cesse d'être une devinette, un peu comme apprendre le code de la route avant de prendre le volant.
Ma méthode de dépannage réseau, dans l'ordre
La méthode ne change pas, que la panne soit un problème de VLAN mal assigné, une boucle bloquée par le Spanning Tree, ou une route qui refuse de s'établir. Je commence toujours par la couche physique : un câble mal enclenché ou un port éteint règle parfois le problème en trente secondes, avant même d'ouvrir un terminal.
Une fois cette vérification faite, vient la question qui structure tout le reste : est-ce que ça touche un seul poste, un port précis, tout un segment, ou l'ensemble du bâtiment ? La réponse oriente immédiatement où chercher, et évite de perdre une heure sur un équipement qui n'a rien à voir avec la panne.
Direction la ligne de commande ensuite, mais pour observer avant d'agir, jamais l'inverse. Un coup d'œil aux statuts de port suffit souvent à savoir si le souci est électrique, logique, ou plus haut dans la pile, surtout quand on a pris l'habitude de s'entraîner sur Packet Tracer plutôt que sur du matériel qui sert vraiment. Un exercice de simulation qui part complètement dans le mur, ça arrive, et c'est même souvent là qu'on retient le mieux dans quel ordre les choses cassent.
Il y a ces quelques secondes où plus rien ne bouge à l'écran, juste un curseur qui clignote pendant qu'un ping tente de joindre 8.8.8.8, et l'attente semble toujours plus longue qu'elle ne l'est vraiment. C'est là qu'on est tenté de changer trois réglages à la fois pour aller plus vite. Mauvaise idée. Je change une seule variable, je vérifie le résultat, et seulement après je passe à la suivante, un réglage qui a l'air de fonctionner mais qu'on n'a pas vérifié n'est pas un réglage qui fonctionne, c'est un problème qu'on a juste repoussé.
Je me méfie aussi de ce que raconte la CLI toute seule : un log qui affiche que tout va bien ne garantit rien si le signal physique dit autre chose. Les deux doivent se confirmer l'un l'autre avant que je considère le dossier clos.
Une formation ne remplace pas un vrai appel de panique
C'est exactement ce que cette méthode a changé dans mon quotidien de technicien IT. Un collègue m'appelle un matin, en panique, parce qu'un segment entier du bureau ne voit plus le serveur de fichiers partagé. Avant la formation, j'aurais probablement redémarré deux ou trois appareils au hasard en espérant que ça reparte tout seul.
Maintenant, j'isole d'abord : un poste ou plusieurs, un switch ou plusieurs, un câblage suspect ou pas. La réponse arrive en quelques minutes, pas en fin de journée, et le collègue en question a fini par comprendre que crier sur l'écran n'accélère jamais rien.
Cisco ou une autre marque : est-ce transférable ?
La question revient presque à chaque fois : apprendre sur du matériel Cisco, est-ce que ça sert seulement si on reste sur du Cisco ? Non. Une fois qu'on a compris leur logique, les commandes changent d'un constructeur à l'autre, mais les concepts qu'on manipule restent les mêmes chez HP, Aruba ou Ubiquiti. Cisco, c'est surtout l'alphabet : une fois qu'on le maîtrise, lire une autre langue devient une question de vocabulaire, pas de grammaire.
Choisir sa formation avant de payer
Avant de sortir la carte bancaire, je regarde toujours la même chose : est-ce que la formation explique le pourquoi, ou seulement le geste à reproduire ? Un module qui fait juste refaire une manipulation sans dire ce qui se passe derrière ne sert pas à grand-chose le jour où la panne ne ressemble pas exactement à l'exercice.
Ça, c'est un critère que j'applique à toutes les formations que je regarde, réseau ou code. Il existe un autre article, déjà en ligne sur ce site, qui détaille comment préparer une certification Cisco sans être ingénieur réseau, pour ceux qui veulent transformer cette autoformation en diplôme reconnu ; moi, je n'ai pas encore franchi le pas, et je le dis sans détour.
Le réseau et le code ne s'apprennent pas dans le même ordre
Certains lecteurs me demandent si le code aide à comprendre le réseau, ou l'inverse. Les deux finissent par se nourrir, mais pas tout de suite : apprendre les variables et les fonctions en Python, ou la logique conditionnelle d'un script, ça devient utile plus tard, pas pendant qu'on apprend encore à lire un switch.
Je me suis posé la question Python contre JavaScript pour un poste de support, et la réponse dépend surtout de ce qu'on veut automatiser derrière, pas d'une préférence de principe. Une fois qu'on sait configurer un équipement à la main, l'envie d'utiliser une formation Python pour automatiser les tâches répétitives de technicien arrive vite, reconfigurer cinquante switches un par un, personne n'a signé pour ça.
Par où commencer si le terminal vous fait peur ?
Par où commencer, alors, si un terminal noir vous donne envie de fuir ? Pas par la théorie pure. Un voisin à moi joue au badminton en salle deux fois par semaine, du côté du Colombier, et il ne s'est jamais amélioré en lisant des articles sur la biomécanique du smash : c'est la répétition qui a fait le travail, jusqu'à ce que le geste devienne automatique sans qu'il y pense.
Le réseau fonctionne pareil. On commence par des manipulations simples, on les refait jusqu'à ce qu'elles ne demandent plus de réfléchir, puis on complexifie petit à petit. Le protocole exact utilisé, la couche du modèle concernée, tout ça vient après avoir pris le réflexe, pas avant. Le soir, après une journée de tickets, ce n'est jamais le moment idéal pour attaquer un chapitre compliqué, mais c'est souvent le seul créneau disponible quand on apprend en autodidacte, alors autant apprendre les bons gestes plutôt que les bonnes définitions.