Copier une commande trouvée sur un forum et taper la même commande en sachant précisément ce qu'elle fait : ça produit exactement le même résultat à l'écran, et pourtant ce n'est pas du tout le même geste. Je m'en suis rendu compte, une fois de plus, ce soir, penchée sur mon vieux switch Cisco, en pleine autoformation improvisée. Débutante complète en réseau, ce petit boîtier gris métallisé est entré dans ma vie presque par accident, et ma formation Cisco maison tient plus du bricolage patient que d'un vrai parcours structuré.
Valérian, mon collègue de bureau, m'a tendu un café de la machine sans un mot quand je suis arrivée ce matin-là avec la tête de quelqu'un qui n'a pas assez dormi, il fait toujours ça quand il me voit débarquer fatiguée, allez savoir comment il devine. Je lui avais raconté la veille que je butais sur un câble bizarre censé relier mon ordinateur à ce switch, et je crois qu'il n'a rien compris à l'histoire, mais le café, lui, était bienvenu.
Le câble bleu et le switch Cisco qui refusait de répondre
Ce fameux câble s'appelle un câble rollover : bleu, plat, un peu vintage, et complètement incompatible avec un port USB sans adaptateur. Brancher, espérer le petit bruit familier de Windows qui reconnaît un périphérique, puis constater qu'il ne se passe rien. C'est souvent une histoire de pilote, ce petit programme qui explique à l'ordinateur ce qu'est l'adaptateur. Une fois réglé, il faut encore un logiciel pour dialoguer avec le matériel.
PuTTY, ce logiciel qui ressemble à une relique tout droit sortie des années 90, fait très bien le travail une fois qu'on sait quoi lui dire. Il ne suffit pas de cliquer sur « Ouvrir » : il faut renseigner des paramètres que tout le monde semble connaître sauf les débutantes comme moi. La vitesse de transmission se règle sur 9600, les bits de données sur 8, le bit d'arrêt sur 1, un standard Cisco que personne ne prend la peine d'expliquer nulle part. Un seul chiffre de travers, et l'écran affiche une soupe de caractères illisibles, ou pire, rien du tout.
Copier une commande n'est pas vraiment l'avoir comprise
Pendant longtemps, ma méthode a été simple et un peu lâche : je copiais un bloc de commandes trouvé en ligne, je le collais dans le terminal, et je regardais si ça marchait. Ça marchait, d'ailleurs, la plupart du temps. Le problème, c'est que le lendemain, face au même écran, je ne savais plus rien refaire toute seule, j'avais le résultat sans la moindre idée de comment j'y étais arrivée.
Un soir où j'étais coincée sur un problème de parité dans les paramètres du terminal, j'avais tapé des commandes dans le vide pendant un bon moment sans que rien ne s'affiche, persuadée d'avoir pourtant tout bien fait. Le lendemain, j'étais partie marcher du côté du Bois de Montjuzet pour me vider la tête, et c'est en remontant le chemin que j'ai enfin compris où j'avais inversé les réglages, pas devant l'écran, mais loin de lui. Ce genre de déclic ne se produit jamais quand on colle une solution toute faite : il faut être resté assez longtemps avec le problème pour que la logique se mette en place toute seule.
La vraie différence, je l'ai sentie le jour où j'ai rouvert le script de la veille sans l'aide de personne, et où chaque ligne m'a semblé évidente, presque familière, comme si je l'avais écrite en pleine possession de mes moyens. Ce qui était littéralement le cas, mais ça ne va jamais de soi à ce stade-là. Aucune commande copiée ne procure cette sensation. Comprendre chaque instruction avant de l'exécuter, c'est plus lent, ça demande d'accepter de rester bloquée plus longtemps devant l'écran noir, mais c'est la seule chose qui reste une fois que l'écran s'éteint.
Ce que mon script a fini par apprendre à faire
Configurer trois ports à la main, un par un, avec le risque de faire une faute de frappe à chaque fois, a fini par me sembler absurde, j'en parlais déjà quand je cherchais à découvrir l'automatisation réseau avec python pour simplifier ses tâches, et c'est exactement ce soir-là que le déclic a eu lieu. C'est là que mon apprentissage Python a pris tout son sens : au lieu de voir la console comme une fin en soi, j'ai commencé à la voir comme une cible pour un petit script.
Ce script s'est construit petit bout par petit bout, et chaque bout m'a forcée à revenir sur une notion apprise séparément ailleurs. Une boucle a fini par répéter la même commande sur mes trois ports plutôt que de me faire la retaper trois fois. Chaque paramètre — le port, la vitesse, le nom du VLAN — a atterri dans une variable, ce qui paraît tout bête mais évite pas mal d'oublis idiots. Plutôt que de copier le même bloc trois fois, j'ai fini par écrire une petite fonction qui envoie la commande et attend la réponse, ce qui m'a évité de dupliquer mes propres erreurs. La liste des ports à traiter reste rangée dans l'ordre, et je vais chercher chaque valeur par son index quand j'en ai besoin. Pour associer un port à son VLAN, un dictionnaire s'est révélé bien plus pratique qu'une liste de plus. La commande envoyée au switch n'est jamais, au fond, qu'une chaîne de caractères assemblée à partir de petits bouts de texte. Rien de tout ça n'aurait tourné sans importer un module fait pour parler aux équipements réseau, ce que je n'aurais jamais deviné toute seule. Le script vérifie d'abord, avec un if, que le port n'est pas déjà configuré avant de foncer, et cette condition s'appuie sur un and, parce qu'il faut que deux choses soient vraies à la fois pour continuer. J'ai entouré la partie qui parle au switch d'un bloc try/except, parce que la connexion refusait de coopérer une fois sur trois au début. Je demande encore le numéro du port à la main avec un input, je n'ai pas osé automatiser cette étape-là non plus. La liste des commandes à envoyer, je la lis maintenant depuis un fichier texte plutôt que de la coller en dur dans le script. Le numéro de port qui arrive sous forme de texte doit être converti en entier avant que la comparaison fonctionne, sinon Python compare des choses qui n'ont rien à voir. J'ai aussi mis un moment à comprendre pourquoi une variable définie à l'intérieur de ma fonction refusait d'exister en dehors, une histoire de portée que j'ai fini par admettre plutôt que par vraiment maîtriser. Quand rien ne marchait, je me suis remise à chercher la panne méthodiquement, sans raccourci, une variable à la fois.
Tout ça tourne sur l'installation Python que j'avais fini par stabiliser sur mon ordinateur, après des débuts plus laborieux que prévu avec les chemins d'accès qui ne se parlaient pas entre eux. La première fois que l'indentation d'un bloc a foiré dans ce script, j'ai revécu exactement la même angoisse que mes tout premiers jours avec Python, l'installation d'une bibliothèque avec pip comprise : l'écran qui refuse tout net pour un espace de travers, sans grand-chose pour m'expliquer pourquoi.
Copier vite ou comprendre lentement : comment trancher
Copier un bloc de commandes reste utile pour débloquer vite une situation sur un appareil de test, un de ceux qu'on peut réinitialiser sans drame si tout part de travers. Comprendre chaque ligne avant de la taper devient indispensable dès que la configuration doit être relue, réutilisée ou expliquée à quelqu'un d'autre, un script à moitié compris finit toujours par se venger, en général un soir où on est pressée. Ma règle tient maintenant en une phrase : copier pour avancer vite sur ce qui ne compte pas, comprendre pour tout ce qu'on compte garder.
Le switch est configuré comme je le voulais, ce soir, et la comparaison entre les deux méthodes me paraît enfin claire au lieu de rester une vague intuition. Ça me rappelle ce que j'ai vécu en apprenant à faire la somme d'une liste python pour mes premiers calculs : tant qu'on tâtonne sur la syntaxe, on n'a pas de recul sur la méthode, et c'est seulement une fois que le geste devient naturel qu'on peut juger ce qui vaut le coup d'être fait vite et ce qui mérite d'être fait bien. J'ai aussi réussi à réussir à mettre à jour python windows sans casser mes anciens scripts de test, ce qui n'a rien à voir avec les switches mais m'a rassurée : je commence à savoir où chercher quand quelque chose casse, plutôt que de tout recopier depuis le début en espérant que ça marche.
Demain, j'essaierai peut-être de comprendre les VLANs d'un peu plus près, ou peut-être pas, le petit boîtier gris ne va nulle part, et la copie facile sera toujours là pour les urgences. Ce que je ne sais toujours pas, c'est pourquoi la console met parfois trois bonnes secondes à répondre alors que tout est branché correctement. Tant que le curseur clignote au bon endroit, j'imagine que je peux vivre avec ce mystère-là.