Le curseur clignote sur la même ligne pour la troisième fois, et Python me renvoie encore une erreur que je croyais avoir dépassée depuis longtemps. J'ai beau être une pure autodidacte, sans aucune notion de développement avant de me lancer dans Python, ce genre de blocage me fait toujours douter de toute la logique de programmation que je pensais avoir enfin apprivoisée. Je voulais juste écrire une condition toute simple : arrêter de travailler une fois une certaine heure dépassée. Une règle de vie basique, traduite en une poignée de mots pour ordinateur, et pourtant ça résiste.
Donner des ordres à un ordinateur, j'ai fini par comprendre que ça ressemble à diriger un commis de cuisine zélé mais sans la moindre initiative. Si personne ne lui précise quoi faire quand le lait commence à déborder, il regardera la casserole déborder jusqu'à ce que l'alarme se déclenche, sans bouger un cil. C'est exactement le rôle des conditions if et else en Python : le fameux si... alors... sinon. Sur le papier, ça paraît évident. Devant l'éditeur de texte, un soir comme un autre, c'est une autre histoire.
La logique du si, alors, sinon, telle que je l'ai comprise
La structure de base, une fois que j'ai arrêté de la complexifier dans ma tête, tient en trois lignes : on pose une question avec if, on ferme avec deux points, et ce qu'on veut faire figure juste en dessous. Si la réponse est vraie — ce qu'on appelle une valeur booléenne, True dans le jargon — le bloc s'exécute. Sinon, on tombe dans le else, et autre chose se produit à la place. Il n'existe que deux réponses possibles pour ces booléens, vrai ou faux, jamais d'entre-deux, jamais de « on verra plus tard ». Cette rigidité-là, au début, me semblait presque insultante pour mon cerveau habitué à négocier avec lui-même toute la journée.
Ce bloc en dessous du if, d'ailleurs, ne tient debout que grâce à l'indentation — un sujet que j'ai fini par apprivoiser à part, en cherchant justement à créer un environnement virtuel python pour mieux organiser ses codes, tellement la structure méritait un chantier à elle toute seule.
Pourquoi un seul signe égal peut-il tout faire planter ?
Une autre chose qui m'a fait perdre patience au début, c'est l'histoire du signe égal. Dans une phrase normale, dire que quelque chose est égal à une valeur prend un seul signe, et en Python ce signe unique sert uniquement à ranger une valeur dans une variable — un réflexe que j'ai fini par démêler à part, dans un tout autre chantier. Pour tester une égalité à l'intérieur d'une condition if, il faut en revanche doubler le signe, ==, sinon le programme refuse carrément de démarrer et hurle une erreur qu'on ne comprend pas tout de suite. Cette nuance-là m'a coûté plus d'une soirée avant de devenir un réflexe, et c'est précisément le genre de faute de frappe que j'ai appris à traquer grâce à mes astuces pour déboguer son code python sans perdre patience le soir, parce que les yeux fatigués en fin de journée ne voient plus rien.
Il y a eu une période, avant de vraiment m'accrocher à comprendre chaque ligne, où je piochais des bouts de code trouvés en ligne pour faire fonctionner mes conditions plus vite. Ça tournait, parfois, mais dès que je changeais un chiffre ou une variable, tout s'effondrait, et je me retrouvais aussi perdue qu'avant, sans même savoir par où chercher l'erreur. Comprendre vraiment chaque ligne, même la plus bête, a fini par me prendre bien plus de temps que copier-coller, mais c'est la seule chose qui a vraiment tenu sur la durée.
Redresser un code parti en escalier
Mes premiers scripts un peu plus ambitieux ressemblaient vite à des escaliers sans fin : un if, puis un autre if glissé à l'intérieur, puis encore un autre, jusqu'à devoir faire défiler l'écran vers la droite pour lire la fin d'une phrase de code. C'est ce qu'on appelle le code en escalier, ou en pyramide, et c'est franchement pénible à relire une fois que l'écran déborde.
L'astuce qui a tout changé, c'est d'arrêter d'imbriquer les conditions par réflexe et d'apprendre ce qu'on appelle des gardes. Plutôt que d'empiler « si j'ai de l'argent, alors si le magasin est ouvert, alors si j'ai mes clés, j'y vais », il suffit de dire « si je n'ai pas d'argent, je m'arrête là ; si le magasin est fermé, je m'arrête là aussi ; sinon, j'y vais ». Le code reste bien droit sur la gauche, et mon cerveau de débutante s'y retrouve beaucoup mieux.
L'arrivée du elif, sans prévenir
Le déclic est venu sans prévenir, alors que j'essayais d'ajouter une troisième option à mon petit script de budget loisirs. Ce n'était plus juste oui ou non, mais aussi peut-être, si l'article était en solde. C'est là que j'ai découvert elif, que j'ai d'abord pris pour une faute de frappe de else if, avant de comprendre que c'était une vraie commande capable de tester plusieurs scénarios à la suite sans empiler des if partout.
Mon script a fini par tourner sans virer au rouge sur mes trois cas de figure. Je l'ai même rendu un peu plus vivant en apprenant à utiliser la fonction input python pour créer un programme interactif, ce qui me permet de taper un montant directement au lieu de le modifier dans le code à chaque essai. Voir l'ordinateur me répondre positivement parce qu'il me restait encore un peu d'argent de côté, ça m'a fait oublier d'un coup toutes les erreurs de la semaine.
La clause else, d'ailleurs, est optionnelle — je l'ai appris un peu plus tard. Le script peut très bien continuer sa route si la condition if n'est pas remplie, sans qu'on ait besoin de prévoir une alternative pour absolument tout. Un peu comme décider de ne sortir les poubelles que si le sac est plein ; s'il ne l'est pas, la vie continue sans instruction spéciale. Je commence doucement à apprendre à créer des fonctions python pour arrêter de copier-coller mes conditions d'un script à l'autre, ce qui est encore un autre chantier.
Ce que la semaine huit a changé sans bruit
Vers la semaine huit, sans que ce soit un grand moment marqué d'une croix sur le calendrier, j'ai arrêté de paniquer devant un if mal fermé.
Valérian, mon collègue de bureau, commande toujours deux cafés au distributeur quand il me voit arriver l'air fatiguée, le sien et le mien, sans même demander si j'en veux un. Un matin, il m'a tendu un vieux fichier .py qu'un stagiaire avait laissé traîner sur le réseau commun, presque pour voir ma tête, et j'ai pu lui expliquer ce que faisait chaque bloc sans avoir besoin d'ouvrir un tutoriel à côté pour vérifier. Ça m'a surprise plus que lui, je crois.
Une leçon qui dépasse la syntaxe
Prendre une décision, même minuscule, revient toujours à la découper en morceaux assez simples pour qu'une machine parfaitement littérale puisse la suivre sans se perdre — c'est sans doute la vraie leçon derrière tous ces if. On enchaîne des centaines de choix dans une journée sans y penser — s'habiller selon la météo, répondre ou non à un message, ajouter une couche de farine à une pâte qui semble trop liquide — et il a fallu Python pour que je commence à les regarder d'un peu plus près.
Théophane, un lecteur qui commente depuis Lyon presque à chaque publication, m'a récemment rappelé dans un commentaire que ce journal touche surtout des adultes qui ne sont clairement plus dans leur vingtaine — ça m'a fait sourire, parce que je l'oublie parfois en écrivant, prise dans mes propres embrouilles de syntaxe du soir.
Le script tourne, ce soir. Il n'est pas élégant, il ne suivrait sans doute aucune norme de pro, mais il fait ce que je lui demande, et ça suffit largement pour l'instant. Il me reste sans doute à dompter les boucles et ces fameux try/except un de ces jours, et à comprendre pourquoi mes chaînes de caractères se comportent parfois n'importe comment dès qu'une condition s'en mêle — mais ça, ce sera pour un autre soir.