12 — Projet final CLI

Niveau requis : 10 (tout le parcours) / Difficulté : 5/5 / Durée estimée : 2–4 semaines

Objectif

Concevoir et livrer, de bout en bout et en autonomie, un outil en ligne de commande de TON choix — un programme que tu as envie d'utiliser pour de vrai. Cette fiche ne donne pas de sujet à recopier : elle donne la MÉTHODE pour mener un projet du besoin flou au logiciel fini. C'est la compétence terminale de tout le parcours.

Le projet vit dans projects/final-projects/<ton-projet>/ (voir le README de ce dossier), avec son propre README, ses tests et sa structure.

Idées de calibre raisonnable (choisis ou invente) : suivi de dépenses avec rapports mensuels, gestionnaire de flashcards à répétition espacée, outil de suivi d'habitudes, agrégateur de flux RSS en terminal, générateur de site statique minimal, outil de sauvegarde incrémentale d'un dossier. Le bon sujet : utile POUR TOI, faisable en 2-4 semaines, et qui te fait un peu peur.

Notions utilisées

Tout le parcours, dont au minimum :

• Fonctions et découpage en modules — niveaux 4 et 5
• Structures de données adaptées au domaine — niveau 3
• Persistance (JSON/CSV/fichiers) et exceptions — niveau 5
• POO là où elle clarifie (pas partout) — niveau 6
• argparse pour une vraie interface CLI — niveaux 9-10
• Tests pytest — niveau 8
• Git : branches, commits atomiques, README — niveaux 0 et 10

Cahier des charges

Ici, le cahier des charges, c'est toi qui l'écris — et c'est la première épreuve du projet. Exigences non négociables sur le RÉSULTAT :

• Un dossier projet autonome dans projects/final-projects/, avec README.md (quoi, pourquoi, installation, exemples d'utilisation réels), le code en modules, un dossier tests/ avec des tests pytest qui passent.
• Une interface argparse avec au moins deux sous-commandes ou modes, plus --help propre.
• Des données persistées (l'outil se souvient d'un lancement à l'autre).
• Aucune entrée utilisateur ne provoque de traceback.
• Un historique Git lisible : petites étapes, messages en anglais au format du repo, développement des features en branches.

Et une exigence sur le PROCESSUS : les documents de cadrage (specs, roadmap, issues) existent AVANT le code correspondant, et sont mis à jour quand la réalité les contredit.

Étapes de construction

Ici les « étapes » sont les phases de la méthode. Chacune produit quelque chose de tangible — et à partir de la phase 3, un programme qui tourne à chaque fin de semaine au minimum.

1. Cadrage (une session, AVANT tout code). Écris SPECS.md dans ton dossier projet : le problème, l'utilisateur (toi), 5 à 10 exigences testables (« la commande add refuse un montant négatif »), et — crucial — une section « hors périmètre » listant ce que la v1 ne fera PAS. Un projet d'apprentissage meurt par excès d'ambition bien plus souvent que par manque.
2. Roadmap. Découpe en 3 jalons : v0.1 = le cœur utilisable (une seule fonctionnalité qui rend déjà service), v0.2 = confort, v1.0 = fini. Règle de calibrage honnête : si tu penses que v0.1 prend 3 jours, elle en prendra 6 — dimensionne en conséquence.
3. Découpage en issues. Transforme chaque jalon en tickets GitHub Issues (ou une simple TODO.md numérotée) : une issue = une tâche d'une session max, formulée par son résultat observable (« report affiche le total du mois »), pas par son implémentation. C'est ta liste de travail : une session = une issue, du début à la fin.
4. Squelette qui tourne (jour 1 du code). main.py + argparse + une sous-commande qui répond, un test pytest trivial qui passe, premier commit. À partir d'ici, le projet est TOUJOURS en état de marche — on n'enchaîne jamais deux features sur un programme cassé.
5. Boucle de développement, une issue à la fois : branche (git switch -c feat/report-command), test(s) de la fonctionnalité, code jusqu'à vert, mise à jour du README si l'usage change, merge dans main, issue fermée. Petit, fini, mergé — puis suivant.
6. Revue de mi-parcours (fin de v0.1). Utilise ton outil pour de vrai pendant 2-3 jours. Note ce qui agace. Mets à jour SPECS et roadmap en fonction — couper une feature prévue est une décision de pro, pas un échec. Consigne l'arbitrage dans le journal.
7. Finition v1.0. Passe la checklist « projet fini » (critères ci-dessous), traque les tracebacks sur entrées absurdes, relis le README comme si tu découvrais l'outil, tague la version (git tag v1.0).
8. Bilan. Entrée de journal longue : ce qui a pris plus de temps que prévu et pourquoi, ce que tu referais autrement, ce que le projet t'a appris sur TA façon de travailler. C'est cette page-là qui clôt le parcours.

Extensions possibles

1. Publier le repo en public avec un vrai README (badges, GIF de démo) — ton premier portfolio.
2. Empaqueter avec pyproject.toml pour installer ton outil via pip install -e . et l'appeler par son nom depuis n'importe où.
3. Ajouter l'intégration continue (GitHub Actions qui lance pytest à chaque push).
4. Un deuxième projet final, plus ambitieux, en réutilisant la méthode — c'est elle, le vrai livrable du niveau 10.

Erreurs fréquentes sur ce projet

• Commencer par coder. Sans SPECS ni découpage, au jour 4 tu ne sais plus quoi faire ensuite, et le projet s'arrête. La méthode n'est pas de la bureaucratie : c'est ce qui fait qu'on finit.
• Périmètre gonflé (« et aussi une interface graphique, et la synchro cloud… ») : c'est la cause n°1 de projet abandonné. La section « hors périmètre » de SPECS.md est ta défense — relis-la à chaque tentation.
• Tunnel d'une semaine sans commit ni programme qui tourne : impossible de savoir où on en est, ni de revenir en arrière. Si ta branche a plus de 2-3 jours, elle est trop grosse — découpe.
• Tests écrits « à la fin » : ils ne seront jamais écrits. Une issue n'est finie que testée — c'est la discipline du niveau 8, sur ton propre code cette fois.
• README écrit pour toi-même (« lancer le script ») : écris-le pour quelqu'un qui n'a jamais vu le projet. Test honnête : suivre ton propre README à la lettre dans un dossier vierge, et rien que le README.

Critères de réussite

Checklist « projet fini » — tout doit être cochable, sans indulgence :

• SPECS.md existe, avec périmètre ET hors-périmètre, écrit avant le code.
• Chaque exigence de mes specs v1.0 est implémentée ou explicitement coupée (décision notée).
• Installation depuis un clone vierge en suivant uniquement le README : ça marche.
• pytest passe ; les fonctions cœur du domaine sont testées.
• --help (global et par sous-commande) est exact et suffisant.
• Aucune entrée utilisateur essayée ne produit de traceback.
• Historique Git : features en branches, messages conformes, tag v1.0.
• Je me sers réellement de l'outil.
• Bilan écrit dans le journal.

Commit conseillé

Ici, ce n'est pas UN commit mais une discipline — le premier ressemble à :

git switch -c feat/project-skeleton
git add projects/final-projects/<ton-projet>/
git commit -m "project: add <name> skeleton with argparse and first test"

Puis une branche + des commits par issue, un merge par feature, git tag v1.0 à la fin — et à chaque session : entrée de journal + git push.