La méthode de travail

Ce fichier est le mode d'emploi de tout le repo. Les leçons donnent le contenu ; ce fichier donne comment travailler pour que le contenu tienne. Le lire une fois en entier au démarrage (15 min), puis y revenir quand une routine dérape.

1. Principes

Cinq principes. Tout le reste du fichier en découle.

1. Comprendre > copier. Une ligne de code que tu ne peux pas expliquer à voix haute est une ligne que tu n'as pas apprise. Le test est binaire : tu sais l'expliquer ou tu ne sais pas. « Je vois à peu près » = tu ne sais pas.
2. Taper le code soi-même. Jamais de copier-coller pendant l'apprentissage, même pour les exemples des leçons. Taper force à lire chaque caractère — c'est là que tu remarques les deux-points, les parenthèses, l'indentation. La mémoire des doigts est réelle.
3. Les erreurs sont la leçon. Un traceback n'est pas un échec, c'est le programme du jour. La méthode complète est en section 10, et le guide de lecture des erreurs dans docs/erreurs-frequentes.md.
4. Régularité > volume. 30 minutes par jour battent 4 heures le dimanche. Le cerveau consolide entre les sessions, pas pendant. Six petites sessions créent six consolidations ; une grosse session en crée une.
5. Tout versionner. Chaque exercice terminé = un commit. Chaque fin de session = un push. Les règles exactes sont dans GIT_WORKFLOW.md — c'est le règlement, pas une suggestion.

2. La session type

Toute session, quelle que soit sa durée, suit ce squelette dans cet ordre :

1. Échauffement (5 min, non négociable) — SANS ouvrir la leçon du jour : relire les « questions de révision » (section 14) de la leçon d'hier et y répondre de tête, à voix haute ou par écrit. Si tu sèches sur plus de la moitié : la session du jour commence par relire cette leçon-là, pas par avancer. C'est la révision J+1 (voir section 8).
2. Apprentissage — lire la leçon du jour en tapant tous les exemples, ou continuer celle en cours.
3. Exercices — faciles d'abord, puis moyens, puis difficiles. Solutions seulement après avoir terminé ou séché sérieusement (> 15 min sur un difficile, indices d'abord).
4. Journal — une entrée courte dans journal/ : ce que j'ai fait, ce qui a bloqué, ce que je fais demain. 3 minutes, pas un roman.
5. Commit + push — cycle complet de GIT_WORKFLOW.md. Le push de fin de session est obligatoire, même si la session a été mauvaise. Surtout si elle a été mauvaise : le journal du jour est ta preuve que tu as travaillé.

L'ordre compte. L'échauffement AVANT la nouveauté (sinon tu ne le fais jamais), le journal AVANT le push (sinon le commit journal saute).

3. Routine 30 minutes

Le format minimum viable. En dessous de 30 min, on révise seulement, on n'apprend pas de nouvelle notion.

Règle des 30 minutes : une leçon se fait sur 2 à 3 sessions de ce format, c'est normal et prévu. Ne pas bâcler une leçon pour la finir en une session.

4. Routine 1 heure

Le format confortable : on avance ET on consolide dans la même session.

Si la leçon est difficile (scope, mutabilité, POO — les leçons le disent), inverser les blocs : 15 min de leçon, 30 min d'exercices. On apprend en faisant.

5. Routine 2 heures

Pourquoi la pause est obligatoire. Au-delà de 45–50 minutes de concentration réelle, la qualité d'attention chute — tu continues à taper mais tu ne remarques plus tes erreurs, et c'est précisément le moment où tu prends de mauvaises habitudes sans t'en rendre compte. Pire : les erreurs de fatigue (typo, indentation) sont indiscernables des erreurs de compréhension, donc tu tires de mauvaises conclusions (« je n'ai pas compris les boucles » alors que tu as juste raté un :). Dix minutes debout, sans écran, et le second bloc vaut le premier. Une session de 2 h sans pause vaut environ 1 h 15 de travail réel — autant prendre la pause et avoir 1 h 50.

6. Routine hebdomadaire (le bilan)

Une fois par semaine, à jour fixe (dimanche recommandé), 30–45 min. Ce n'est pas une session d'apprentissage : aucune nouvelle notion ce jour-là.

1. Mettre à jour PROGRESS.md — cocher ce qui est réellement acquis (les checklists de leçons cochées, pas les leçons juste lues).
2. Relire tout le code de la semaine — git log --oneline pour retrouver les commits, puis relire ses fichiers dans mes-reponses/. Quoi chercher : section 12.
3. Refaire de tête 2 exercices ratés ou laborieux de la semaine, dans un nouveau fichier, sans regarder ni l'ancienne réponse ni la solution. C'est le cœur du bilan : un exercice raté puis refait de tête est acquis ; un exercice raté puis relu ne l'est pas.
4. Un push propre — git status vide, tout commité avec de bons messages, push vérifié.
5. Préparer la semaine suivante — ouvrir docs/plannings.md, noter dans le journal les leçons prévues et LE point faible de la semaine à retravailler. Une phrase suffit : « semaine prochaine : niveau 3, et je refais les exercices de boucles imbriquées lundi. »

Commit du bilan : journal: add week N review + memory: update progress.

7. Routine de révision mensuelle

Une fois par mois, une session complète (1–2 h) remplacée par de la révision pure. Deux exercices :

1. Re-répondre aux questions de révision à J+30. Reprendre les sections 14 des leçons terminées il y a environ un mois et y répondre par écrit, de tête. Les questions ratées désignent les sections à relire — relire SEULEMENT ces sections, pas toute la leçon.
2. Refaire un ancien mini-projet SANS regarder son code. Choisir un mini-projet d'il y a un mois, créer un nouveau fichier, le refaire entièrement de mémoire (l'énoncé est autorisé, ton ancien code non). Puis ouvrir l'ancienne version et comparer les deux : la nouvelle est-elle plus courte ? mieux nommée ? découpée en fonctions ? Note les différences dans le journal.

C'est le meilleur détecteur de progrès qui existe : le sentiment de progresser est trompeur (dans les deux sens), la comparaison de deux versions du même programme à un mois d'écart ne l'est pas. Si la nouvelle version est identique à l'ancienne, tu as stagné sur ces notions-là — ce n'est pas grave, mais c'est une information : mets-les au programme.

Commit : project: redo <nom> from memory (monthly review) + journal: ....

8. La révision espacée, expliquée

Le cerveau retient ce qu'il est forcé de récupérer juste avant de l'oublier. Relire ne force rien (ça semble familier, donc ça semble su — c'est l'illusion de maîtrise). Se tester force la récupération. D'où le protocole :

• J+1 : le lendemain d'une leçon, répondre de tête à ses questions de révision (section 14). C'est l'échauffement de la session suivante — déjà intégré aux routines ci-dessus, coût zéro.
• J+7 : une semaine après, re-répondre aux mêmes questions. Intégré au bloc « révision » des routines 1 h et 2 h, et au bilan hebdomadaire.
• J+30 : un mois après, dernière passe. C'est la routine mensuelle (section 7).

Application concrète : chaque leçon a sa section 14 exactement pour ça. Pas besoin d'outil ni de fiches — le journal te dit quelle leçon a été faite quel jour, donc tu sais toujours quoi réviser : celle d'hier (J+1), celle d'il y a une semaine (J+7), celles d'il y a un mois (J+30). Règle de score : une question ratée deux fois de suite = relire la section correspondante ET se créer un exercice dessus (section 10, étape 4).

Pourquoi ça marche : chaque récupération réussie espace le prochain oubli. Après J+30, la notion est là pour des mois. Sans révision, une leçon lue est oubliée à 80 % en une semaine — ce n'est pas un défaut personnel, c'est le fonctionnement normal de la mémoire, et la méthode est construite autour.

9. Vérifier qu'on a VRAIMENT compris

Quatre tests, du plus rapide au plus exigeant. La checklist de fin de leçon (section 15) n'est cochable que si ces tests passent.

1. Expliquer à voix haute. Sans notes, expliquer la notion comme à quelqu'un qui ne l'a jamais vue. Si tu bafouilles à un endroit précis, c'est exactement l'endroit non compris — relis cette section-là.
2. Prédire des sorties. Prendre un exemple de la leçon, cacher la sortie, écrire ta prédiction, exécuter. Prédiction fausse = compréhension fausse, même si « ça avait l'air logique ».
3. Modifier et prédire. Changer une chose dans un exemple (une valeur, un opérateur, l'ordre de deux lignes), prédire l'effet PAR ÉCRIT, exécuter. C'est le test le plus rentable : il révèle les modèles mentaux faux que la simple lecture masque. Python Tutor aide beaucoup ici (voir docs/ressources.md).
4. Ré-écrire de tête. Fermer la leçon, ré-écrire l'exemple central dans un fichier vierge. Pas mot à mot — un programme qui fait la même chose. Si tu n'y arrives pas, la notion est reconnue mais pas acquise.

10. Noter ses blocages, transformer une erreur en apprentissage

Noter les blocages dans l'entrée de journal du jour, format court et fixe :

BLOCAGE: [notion] — [symptôme en une phrase] — [résolu ? comment / non]

Exemple : BLOCAGE: boucles while — condition jamais fausse, boucle infinie — résolu: j'oubliais d'incrémenter i dans la boucle. Trois blocages sur la même notion en deux semaines = la notion passe au programme du bilan hebdomadaire.

Transformer une erreur en apprentissage — méthode en 4 étapes :

1. Lire le traceback en entier, de bas en haut : dernière ligne = quoi, lignes au-dessus = où. Interdiction de toucher au code avant d'avoir lu. (Anatomie complète dans docs/erreurs-frequentes.md.)
2. Reproduire l'erreur volontairement dans un fichier minimal (3–5 lignes, un fichier scratch.py fait l'affaire). Si tu sais la provoquer exprès, tu sais ce qui la cause. Si tu ne sais pas la reproduire, tu n'as pas encore compris — retour à l'étape 1.
3. Écrire la règle dans ses notes (notes/), une ou deux phrases, avec le nom exact de l'exception. Exemple : « TypeError sur "age: " + 25 : on ne concatène pas str et int, convertir avec str() ou utiliser une f-string. »
4. Créer un exercice pour soi-même : un petit bout de code qui contient cette erreur (ou pas), à re-diagnostiquer dans une semaine. Le garder dans notes/ ou en fin de fichier de notes. C'est ta banque personnelle de pièges — elle vaut plus que n'importe quel exercice du repo, parce que ce sont TES erreurs.

Une erreur traitée comme ça ne revient presque jamais. Une erreur « corrigée en bidouillant jusqu'à ce que ça passe » revient toujours.

11. Reprendre après une pause

Après plus de 4–5 jours sans session, ne PAS reprendre où tu t'étais arrêté. Reprendre là où tu t'étais arrêté te met face à la notion la plus récente — donc la plus fragile — au moment où tu es le plus rouillé. C'est la recette du découragement. À la place :

1. Relire son journal des 2 dernières semaines (5 min). Ça recharge le contexte : où j'en étais, ce qui bloquait.
2. Reprendre une leçon en arrière : re-répondre aux questions de révision de l'avant-dernière leçon, pas de la dernière.
3. Refaire la dernière série d'exercices faite avant la pause, de tête, dans de nouveaux fichiers. Si ça passe bien : reprendre la progression normale dès la session suivante. Si ça rame : encore une session de révision avant d'avancer.

Coût total : une à deux sessions « perdues ». Elles ne sont pas perdues — c'est une révision espacée imprévue. Une pause de plus de 3 semaines : reculer d'un niveau entier en mode rapide (relire les « à retenir » + refaire un exercice moyen par leçon du niveau).

12. Relire son ancien code

À faire au bilan hebdomadaire (code de la semaine) et à la révision mensuelle (code du mois dernier). Quoi chercher, dans l'ordre :

1. Noms flous : x, truc, data2, resultat_final_v2. Un nom doit dire ce que la variable contient. temperature_max bat t.
2. Répétitions : le même bloc de 3+ lignes copié deux fois ou plus. C'est le signal d'une boucle manquante (niveaux 2–3) ou d'une fonction manquante (niveau 4+).
3. Absence de fonctions : à partir du niveau 4, un fichier de 40 lignes sans aucun def est un défaut. Chaque bloc qui fait « une chose » devrait avoir un nom.
4. Bonus : nombres magiques (un 86400 non expliqué → une constante nommée), commentaires qui répètent le code au lieu d'expliquer le pourquoi.

Quoi en faire : choisir UN fichier, l'améliorer (renommer, dé-dupliquer, extraire une fonction), vérifier qu'il marche encore, committer (fix: rename unclear variables in calculator ou fix: extract compute_total function). Un seul fichier par bilan — l'objectif est d'entraîner l'œil, pas de tout réécrire. Ne JAMAIS améliorer sans ré-exécuter : du code « nettoyé » mais cassé est pire que du code moche qui marche.

13. Ne pas se décourager

À lire le jour où tu en as besoin.

• Le progrès n'est pas linéaire. Il ressemble à des paliers : des semaines où rien ne semble avancer, puis un déclic. Les paliers ne sont pas des pannes, c'est la consolidation en cours.
• Le plateau des niveaux 3–4 est normal et documenté. Mutabilité, scope, découpage en fonctions : c'est là que « connaître la syntaxe » devient « penser comme un programmeur », et c'est là que la plupart des gens abandonnent. Les leçons de ces niveaux prévoient plus de temps et plus d'exercices exprès. Si tu rames au niveau 3–4, tu es exactement dans les temps.
• Le second plateau, au niveau 6 (POO), est pareil. Les classes demandent de penser en « objets qui se gèrent eux-mêmes » — un changement de perspective, pas juste de la syntaxe nouvelle. Deux semaines prévues, pas une.
• Le journal est ta preuve objective. Le jour où tu penses « je n'avance pas », ouvre le journal d'il y a six semaines et lis ce qui te bloquait alors. Ce qui te paraissait dur est devenu évident — tu ne l'as juste pas senti passer, parce qu'on ne sent jamais passer ce qui devient facile. git log --oneline | wc -l donne la même preuve en chiffres.
• La comparaison mensuelle de mini-projets (section 7) est l'autre preuve. Deux versions du même programme à un mois d'écart ne mentent pas.
• En dernier recours : réduire la voilure, pas arrêter. Passer à la routine 30 min (section 3) ou au rythme lent (docs/plannings.md) est une décision de gestion, pas un échec. Zéro session pendant trois semaines, ça, c'est le vrai risque.