Le curseur clignote sur une ligne que je viens de retaper trois fois, et le ventilateur du vieux laptop se met à ronfler juste après la deuxième tasse de tisane, comme s'il partageait mon agacement. Sur l'écran, un message d'erreur que je ne comprends pas encore s'affiche en rouge, coincé entre le cahier de brouillon et les post-its collés au bord du clavier. C'est ça, apprendre Python en autoformation à la table de la cuisine, à Clermont-Ferrand, quand on est débutante en informatique et qu'on n'a jamais touché à un terminal avant la trentaine passée : on avance à tâtons, un message d'erreur à la fois.
Avant d'aller plus loin, une précision qui vaut ce qu'elle vaut : ce carnet contient des liens affiliés vers certaines ressources que j'ai testées moi-même, et je touche une petite commission si vous passez par là, sans que ça change votre prix. Je ne cite ici que ce qui a survécu à mes soirées sur cette table, thé refroidi à l'appui.
Apprendre Python en autoformation, sans étiquette de développeuse
Théophane Aumont, un lecteur assidu qui commente depuis Lyon, m'a laissé récemment un message si précis et si bien construit qu'il ressemblait presque à un article à lui tout seul : par où faut-il vraiment commencer quand on n'a aucun bagage, qu'on n'a jamais suivi de cursus technique, et qu'on veut comprendre, dans l'ordre, ce qui se passe sous le capot de Python ? Sa question méritait mieux qu'une anecdote de plus sur mon dernier bug du soir.
Pour une fois, je vais essayer de ranger les choses dans l'ordre plutôt que de raconter la soirée telle qu'elle est venue, avec ses détours et ses digressions habituelles. Ce carnet devient, pour un soir, une sorte de feuille de route pour qui débute vraiment de zéro, pas un cours, juste l'ordre dans lequel les choses ont fini par prendre sens chez moi, à la table de la cuisine.
Par où commencer quand on n'a jamais ouvert un terminal ?
L'installation elle-même mériterait tout un carnet à part, je laisse ce guide pas à pas à qui l'a déjà écrit, parce que c'est un vrai sujet en soi. De mon côté, j'ai téléchargé Python 3 directement depuis le site officiel, sans jamais regarder du côté de l'ancienne version : ce n'était pas un choix réfléchi, juste ce que tout le monde recommandait au moment où je m'y suis mise. Mon premier éditeur, celui qui vient avec l'installation, s'appelle IDLE, pas franchement séduisant, mais suffisant pour écrire mes toutes premières lignes, avant de découvrir plus tard des outils comme VS Code. C'est en cherchant comment structurer ces tout premiers essais que je suis tombée sur une Formation au langage Python, qui ne m'a jamais traitée comme une future ingénieure, juste comme quelqu'un qui veut arrêter de perdre ses soirées.
Valérian, mon collègue de bureau, doutait franchement que tout ça me mène quelque part, mais m'a quand même conseillé un soir de regarder des tutoriels vidéo pendant mes trajets, sans forcément ouvrir l'ordinateur en même temps. J'ai essayé, entre deux arrêts, en remontant vers la place de Jaude après le travail, et ça n'a rien donné du tout : sans les mains sur le clavier, rien ne reste vraiment. J'ai laissé tomber cette méthode au bout de quelques essais, pour revenir à la seule chose qui fonctionne chez moi, coder en même temps que je regarde, ou ne pas regarder du tout.
Les variables : la brique sur laquelle tout le reste tient
Une variable, dans ma tête, c'est une étiquette qu'on colle sur un bocal du placard : le nom écrit dessus ne veut rien dire tant qu'on n'a rien versé à l'intérieur, mais dès qu'on y met quelque chose, l'étiquette pointe vers ce contenu-là et pas un autre. En Python, c'est exactement ce qui se passe : une variable existe dès l'instant où on lui donne une valeur, il n'y a pas de formulaire à remplir avant, pas de case à cocher pour annoncer que ceci sera un nombre ou que cela sera un mot. Contrairement à ce qu'on ferait en Java ou en C, où il faut déclarer le type avant de s'en servir, ici on écrit simplement le nom, le signe égal, et ce qu'on veut ranger dedans, et la variable prend la forme de ce qu'on lui donne, comme le bocal prend la forme de ce qu'on y range.
La première fois que j'ai cru avoir tout compris à ce sujet, j'ai passé un long moment à chercher pourquoi mon script réclamait une variable qui, selon moi, existait déjà. En reprenant chaque ligne, j'ai fini par voir que je l'avais nommée d'une façon à un endroit et rappelée avec une orthographe légèrement différente plus loin, une lettre en trop, une majuscule oubliée. Python ne devine rien : deux noms qui ne s'écrivent pas exactement pareil restent deux choses différentes pour lui, aussi proches soient-elles à l'œil humain.
Compter les espaces sans perdre patience
L'indentation obéit à une règle simple sur le papier : quatre espaces par niveau, par convention, et c'est la cohérence qui compte vraiment plus que le chiffre exact, comme le formule noir sur blanc le standard d'indentation PEP 8. Le vrai piège arrive quand un fichier mélange des tabulations et des espaces sans qu'on le voie à l'écran : Python, lui, le voit très bien, et refuse d'avancer.
Le pire souvenir que je garde de mes débuts tient justement là-dedans. J'avais collé un bout de script trouvé en ligne dans un fichier que j'avais commencé moi-même, et plus rien ne voulait tourner : Python répétait obstinément la même IndentationError, sans que je comprenne ce qu'elle voulait dire. J'ai passé un temps que je préfère ne pas avouer à ajouter des espaces au hasard, à en retirer, à recommencer, persuadée que le problème venait de ma logique et pas de ma mise en page. Le fichier mélangeait simplement deux façons d'indenter, la mienne et celle du script copié, et Python refusait de trancher à ma place. Une fois les deux uniformisées à la main, tout a tourné du premier coup, et la formation que j'ai suivie m'a aidée, un peu plus tard, à comprendre pourquoi ce genre de mélange arrive si facilement quand on copie-colle du code trouvé un peu partout.
Ce que Python raconte quand ça plante
Python ne reste jamais silencieux quand quelque chose cloche : il renvoie un message d'erreur, souvent long, presque toujours plus clair qu'il n'en a l'air une fois qu'on prend l'habitude de le lire depuis la dernière ligne plutôt que la première, un réflexe que je détaille ailleurs tellement il y a à en dire.
Un vieux tutoriel trouvé en ligne, un soir où je cherchais une astuce rapide, utilisait une syntaxe pour afficher du texte à l'écran qui ne passait plus du tout chez moi : erreur de syntaxe immédiate, sans explication qui me parle sur le moment. J'ai fini par comprendre que la page datait d'une autre époque du langage, avec des habitudes qui ne collent plus à ce qu'on écrit aujourd'hui. Depuis, je me méfie des tutoriels sans date visible nulle part sur la page.
Autre piège classique, celui-là je m'y suis fait prendre en voulant simplement afficher une phrase avec un chiffre dedans, collés l'un à l'autre sans y réfléchir. Python a refusé net, avec un message parlant de types incompatibles entre texte et nombre. Il a fallu que j'apprenne à convertir explicitement l'un vers l'autre avant de les assembler, un détail qui paraît évident une fois qu'on l'a lu quelque part, mais qui ne l'est pas du tout la première fois qu'on tombe dessus tard un soir.
Les briques qu'on empile ensuite
Les boucles sont arrivées juste après, et honnêtement, ça a mis du temps à se décanter. La première fois qu'une boucle for a tourné sans que j'aie besoin de rouvrir mon cahier de notes, j'ai fixé l'écran une seconde de trop, presque surprise qu'elle obéisse du premier coup, sans accroc. Ce sujet-là, tout ce qui tourne en rond dans un script, mérite un carnet entier à lui tout seul, que j'ai déjà commencé ailleurs.
Une liste, chez moi, ressemble à un panier de courses qu'on peut ranger, trier ou vider article par article, et j'y reviens en détail dans un autre carnet consacré uniquement à ça. Les dictionnaires, eux, fonctionnent plutôt comme un répertoire où chaque nom renvoie à une information précise, un autre sujet traité à part tant il y a de nuances. Les chaînes de caractères, tout ce texte entre guillemets qu'on découpe ou qu'on assemble, ont aussi droit à leur propre entrée. Quant aux conditions, ce moment où le script choisit un chemin plutôt qu'un autre selon ce qui est vrai ou faux, elles reviennent tellement souvent que je leur ai consacré un carnet à elles seules.
J'aurais peut-être dû commencer par JavaScript plutôt, pour voir tout de suite quelque chose bouger dans un navigateur. C'est une question à laquelle j'ai répondu ailleurs, en détail, et je ne vais pas la trancher ici en quelques lignes ; j'ai quand même jeté un œil à une formation JavaScript par curiosité, avant de me rendre compte que vouloir avancer sur deux langages à la fois, en partant de zéro sur les deux, revenait surtout à ralentir sur les deux en même temps.
Les fonctions et les modules changent la façon d'écrire un script
Les fonctions et les modules changent vraiment la façon d'écrire un script, une fois qu'on arrête de tout recopier dix fois. Une fonction permet de donner un nom à un bout de logique qu'on rappelle ensuite, sujet que je développe ailleurs avec les erreurs qui vont autour. Importer un module, c'est un peu comme sortir un ustensile précis du tiroir plutôt que de tout fabriquer soi-même, et ça change la manière d'aborder un script, comme je le raconte dans une entrée dédiée. Gérer les exceptions avec try et except évite qu'un script entier s'écroule pour une seule ligne récalcitrante, un réflexe que j'ai mis du temps à adopter et que je détaille à part. Et demander une information à la personne devant l'écran, avec la fonction input, ouvre enfin la porte à des scripts qui réagissent à autre chose qu'à ce qui est déjà écrit dedans, encore un sujet gardé pour un autre soir.
Ce qu'il me reste à découvrir (et pourquoi Python porte ce nom)
Le nom du langage lui-même donne le ton : contrairement à ce qu'on croit souvent, il ne vient pas du serpent mais des Monty Python, ce qui en dit long sur l'esprit derrière ce langage, moins rigide qu'il n'y paraît, malgré la réputation sérieuse qui l'entoure. Ce genre de détail m'a beaucoup aidée les soirs où je me sentais complètement ridicule de buter sur un espace mal placé : le syndrome de l'imposteur fait partie du chemin, et il ne veut rien dire de particulier sur ce dont on est capable.
Côté réseaux et systèmes, la montagne reste entière, et je ne m'y suis pas encore attaquée. J'ai repéré une formation Cisco qui semble sérieuse pour le jour où la curiosité dépassera le code lui-même, mais ce jour n'est pas encore arrivé.
Ça fait maintenant deux ans que Python vit sur ce vieux laptop, entre les listes de courses et les brouillons de scripts, et la table de la cuisine reste mon seul bureau. Si vous démarrez avec autant d'incertitude que moi à l'époque, la formation que j'ai choisie au début reste, avec le recul, un point de départ honnête pour poser les bases sans se noyer dans le jargon. Reste une question que je me pose encore, sans vraiment savoir y répondre : à partir de quand est-ce qu'on arrête de se sentir débutante ?