
Il est tard, sans doute bien plus tard que ce qui est raisonnable pour quelqu’un qui doit embaucher demain matin. La lueur bleue de mon vieil ordinateur qui se reflète sur ma tasse de verveine froide alors que le reste de l'appartement dort est devenue ma routine préférée, ou ma punition volontaire, je ne sais plus trop. Ce soir-là, à Clermont-Ferrand, le silence était seulement rompu par le clic-clic de mon clavier et le vent qui faisait trembler les vitres. Je fixais mon curseur qui clignotait, obstiné, sur une ligne qui refusait de fonctionner. Je voulais simplement faire comprendre à mon ordinateur qu'il est temps d'arrêter de travailler si l'heure dépasse une certaine limite. Un truc tout bête, une petite règle de vie que j'essaie de m'appliquer à moi-même, mais que je n'arrivais pas à traduire en Python.
Depuis que j'ai commencé cette aventure en autodidacte à la fin de l'hiver dernier, il y a environ 5-6 mois, j'ai réalisé que programmer, c'est un peu comme donner des instructions à un commis de cuisine extrêmement zélé mais totalement dépourvu d'initiative. Si vous ne lui dites pas exactement quoi faire quand le lait bout, il va simplement regarder la casserole déborder jusqu'à ce que l'alarme incendie se déclenche. C'est là qu'entrent en scène les conditions if et else. C'est le fameux "si... alors... sinon". Sur le papier, c'est limpide. Dans l'éditeur de texte, sur ma nappe cirée, c'est une autre paire de manches.
Mes premiers pas hésitants avec le budget loisirs
Tout a commencé un mardi soir pluvieux en mars. J'avais cette envie de créer un petit script tout simple pour gérer mon budget de loisirs. L'idée était basique : je rentre la somme qu'il me reste après les courses, et Python me dit si je peux m'acheter ce roman qui me fait de l'œil ou si je ferais mieux de finir celui qui traîne sur ma table de chevet. Je voulais juste que Python me dise "Oui" ou "Non" selon la somme restante. Mais devant l'écran, je me sentais comme devant un mur de briques. Comment on dit "si" en informatique sans que tout explose ?
J'ai tapé mes premières lignes en tremblant un peu. En Python, la structure de base ressemble à ça : on pose une question avec if, on met deux points, et on écrit ce qu'on veut faire en dessous. Si la réponse à la question est vraie — ce qu'on appelle une valeur booléenne (True) — le code s'exécute. Sinon, on passe au else. C'est binaire. Il n'y a que 2 valeurs possibles pour ces booléens : True ou False. Pas de "peut-être" ou de "on verra demain". C'est cette rigidité qui m'a d'abord déstabilisée.

La guerre des deux points et le drame de l'indentation
Après trois semaines de tâtonnements, j'ai compris que mon plus grand ennemi n'était pas la logique, mais la ponctuation. Mon erreur classique, celle qui me faisait pester tout haut dans la cuisine : oublier les deux points ":" à la fin de la ligne if. Sans ces deux malheureux points, Python lève les bras au ciel et affiche une SyntaxError. C'est comme oublier de mettre le contact avant d'essayer de démarrer la voiture.
Et puis, il y a eu l'indentation. Pour moi, au début, l'espace devant une ligne, c'était juste pour faire joli, comme une marge dans un cahier d'écolier. Grave erreur. En Python, l'indentation n'est pas esthétique mais structurelle : elle définit quel bloc de code appartient à quelle condition. Le standard officiel, ce qu'ils appellent le PEP 8, recommande d'utiliser exactement 4 espaces par niveau d'indentation. Si vous mettez trois espaces au lieu de quatre, ou pire, si vous mélangez avec des tabulations, tout s'écroule. Cette frustration sourde quand je réalise que mon script a planté juste parce qu'il manquait un seul petit espace devant une ligne... c'est une leçon d'humilité constante. J'en parlais d'ailleurs quand je cherchais à créer un environnement virtuel python pour mieux organiser ses codes, car la structure, c'est vraiment le nerf de la guerre.
L'embrouille du signe égal
Une autre chose qui m'a rendue dingue, c'est l'opérateur de comparaison. Dans la vie, si je dis "le prix est égal à 10 euros", j'utilise un seul signe égal. En Python, si vous écrivez if budget = 10:, le programme vous insulte. Il faut utiliser 2 signes égaux (==) pour tester l'égalité. Le signe égal tout seul sert à ranger une valeur dans un tiroir (une variable), alors que le double égal sert à vérifier ce qu'il y a dans le tiroir. C'est une nuance qui m'a coûté quelques soirées de cheveux arrachés avant que ça ne devienne un réflexe. Pour m'aider, je me suis souvent replongée dans mes astuces pour déboguer son code python sans perdre patience le soir, parce que ces petites erreurs de frappe sont les plus dures à voir quand on a les yeux fatigués par une journée de boulot.

Le piège du code en escalier : mon conseil de débutante
Au fil de mes essais, j'ai fini par créer des scripts qui ressemblaient à des escaliers sans fin. Je mettais un if, puis un autre if à l'intérieur, puis encore un autre... Le code partait tout à droite de l'écran, et je devais scroller horizontalement pour lire la fin de mes phrases. C'est ce qu'on appelle le code en escalier (ou le code "pyramide"), et c'est un enfer à relire.
C'est là que j'ai découvert une astuce qui a tout changé : n'imbriquez pas systématiquement vos conditions. Apprenez à utiliser ce qu'on appelle les gardes (ou early returns). Au lieu de dire : "Si j'ai de l'argent, ALORS si le magasin est ouvert, ALORS si j'ai mes clés, j'y vais", essayez de dire : "Si je n'ai pas d'argent, je m'arrête là. Si le magasin est fermé, je m'arrête là. Sinon, j'y vais". Ça garde le code bien droit sur la gauche, c'est beaucoup plus facile pour mon cerveau de débutante. C'est une façon de simplifier sa logique avant même qu'elle ne devienne trop complexe.
Le week-end dernier : le déclic du "elif"
Le moment où tout a vraiment cliqué, c'était le week-end dernier au petit-déjeuner. J'essayais d'ajouter une troisième option à mon script de budget. Ce n'était plus juste "Oui" ou "Non", mais aussi "Peut-être si c'est en solde". J'ai découvert elif. Au début, j'ai cru que c'était une faute de frappe pour "else if", mais c'est une vraie commande Python qui permet de tester plusieurs scénarios à la suite.
Mon script a enfin tourné sans afficher de rouge quand j'ai testé trois scénarios différents. J'ai même réussi à le rendre un peu plus vivant en apprenant à utiliser la fonction input python pour créer un programme interactif, ce qui me permet de taper mon montant directement au lieu de le changer dans le code à chaque fois. Voir l'ordinateur me répondre "Vas-y, achète ce livre !" parce que j'avais 15 euros sur mon compte, c'était une petite victoire qui m'a fait oublier toutes les erreurs de syntaxe de la semaine.

La clause else est optionnelle, je l'ai appris aussi. Le script peut simplement continuer sa route si la condition if n'est pas remplie. On n'est pas obligés de prévoir une alternative pour tout, parfois on veut juste agir si quelque chose de spécifique arrive, sinon on passe à la suite. C'est un peu comme si je décidais de ne sortir les poubelles que si le sac est plein ; s'il ne l'est pas, je continue ma vie normalement sans avoir besoin d'une instruction alternative.
En fin de compte, apprendre ces conditions, c'est apprendre à structurer sa propre pensée. On se rend compte qu'on prend des milliers de décisions par jour basées sur des if sans même s'en rendre compte. Le plus dur, c'est de les décomposer assez pour qu'une machine puisse les suivre sans se tromper d'un seul espace. Je commence doucement à apprendre à créer des fonctions python pour arrêter de copier-coller mes conditions partout, ce qui est une autre étape de ce long voyage. Ce n'est pas encore de l'intelligence artificielle, mais voir mon script répondre correctement à une question me donne l'impression d'avoir enfin appris une langue étrangère utile, même si je la parle encore avec un accent terrible et beaucoup d'hésitations.
Ce soir, je vais fermer l'ordinateur sur une réussite. Le script fonctionne. Il n'est pas parfait, il n'est pas élégant selon les standards des pros, mais il fait ce que je lui demande. Et dans le silence de ma cuisine clermontoise, c'est déjà énorme. Demain, j'essaierai peut-être de rajouter des conditions encore plus complexes, ou de comprendre pourquoi mes chaînes de caractères font parfois n'importe quoi, mais pour l'instant, je vais juste savourer ce petit message dans la console qui me dit que tout est en ordre.