📖 Manuel
Learning Roadmap
Étape 1 — Cadrage initial (obligatoire avant de produire la roadmap)
Collecte ces 4 données avant tout :
| Question | Pourquoi |
|---|---|
| Objectif final précis | "Dev web" ≠ "déployer une API REST en prod sous 3 mois" |
| Niveau actuel | Évite de reformuler des bases déjà connues |
| Disponibilité (h/semaine) | Calibre la durée et la densité de chaque phase |
| Contrainte de format | Préférence vidéo / texte / projets / certifications |
Si ces infos sont absentes, pose les questions en une seule fois. Ne génère pas la roadmap à l'aveugle.
Étape 2 — Critères de découpage en phases
Utilise 3 phases maximum par défaut :
- Phase 1 — Fondamentaux : concepts et outils incontournables, temps de mise en place de l'environnement.
- Phase 2 — Pratique guidée : projets structurés, tutoriels actifs, premières contributions / déploiements réels.
- Phase 3 — Autonomie : projets personnels, debugging sans aide, benchmarks et optimisation.
Critères de passage de phase :
- Ne pas basculer tant que les checkpoints de la phase courante ne sont pas validés.
- Chaque checkpoint = livrable concret (commande qui tourne, fichier produit, PR mergée, score de quiz, etc.).
Étape 3 — Structure d'une phase (template)
### Phase N — <Nom> (semaines W1 à W2)
**Concepts clés**
- Concept A
- Concept B
**Ressources (priorité gratuit)**
- [Titre](URL) — format, durée estimée
- Docs officielles : <lien>
**Projet de validation**
> Exemple copiable : "Crée une CLI en Python qui lit un fichier CSV et génère un rapport JSON."
**Checkpoint — critère de passage**
- [ ] Tu peux expliquer X sans regarder tes notes.
- [ ] Le projet tourne sans erreur sur une machine tierce.
Étape 4 — Calibrage de la timeline
Formule de base :
durée_totale (semaines) = charge_totale (heures) / disponibilité (h/semaine)
Barèmes indicatifs (tech, full débutant) :
| Domaine | Charge estimée jusqu'au premier emploi / projet prod |
|---|---|
| Python scripting | 80–120 h |
| Dev web frontend | 150–250 h |
| Backend API REST | 200–350 h |
| Data / ML (bases) | 200–300 h |
| DevOps / Cloud | 250–400 h |
| Cybersécurité | 300–500 h |
Ajuste selon le niveau de départ et le critère de succès (personnel, professionnel, certif).
Étape 5 — Ressources : règles de sélection
Priorité décroissante :
- Docs officielles (toujours à jour, référence de vérité)
- Ressources gratuites reconnues : MDN, freeCodeCamp, Exercism, roadmap.sh, The Odin Project, CS50, Fast.ai
- Plateformes payantes si le ROI est justifié (Udemy <15 €, Pluralsight, O'Reilly)
- Livres : préfère les éditions < 3 ans pour les sujets évoluant vite
Ne propose jamais plus de 2–3 ressources par phase — trop de choix paralyse.
Étape 6 — Exemples concrets par domaine
Exemple : apprendre Python de zéro, 10 h/semaine, objectif scripting
Phase 1 — Fondamentaux (semaines 1–4, ~40 h)
Concepts : types, fonctions, boucles, modules, fichiers
Ressource : https://docs.python.org/3/tutorial/ + Exercism Python track
Projet : script CLI qui parse un CSV et sort des stats (min/max/moyenne par colonne)
Checkpoint : script tourne avec pytest sans erreur, explique la différence list/tuple/dict
Phase 2 — Pratique (semaines 5–10, ~60 h)
Concepts : requests, pathlib, argparse, logging, venv, pyproject.toml
Ressource : Real Python (realpython.com) articles ciblés
Projet : outil CLI packagé installable via pip install -e .
Checkpoint : le tool est publié sur TestPyPI et documenté dans un README
Phase 3 — Autonomie (semaines 11–14, ~40 h)
Concepts : typing, tests unitaires (pytest), CI GitHub Actions
Projet : automatise une tâche réelle du quotidien de l'utilisateur
Checkpoint : pipeline CI verte, coverage > 80 %
Anti-patterns / pièges à éviter
- Tutorial hell : enchaîner les tutos sans jamais produire un projet personnel. Règle : max 1 tuto actif, toujours avec un projet parallèle.
- Phases trop longues : au-delà de 6–8 semaines sans livrable, la motivation s'effondre. Découpe davantage.
- Ressources obsolètes : vérifier la date de publication pour tout ce qui touche cloud, frameworks JS, LLMs, Kubernetes. Seuil d'alerte : > 2 ans.
- Overengineering précoce : ne pas enseigner les design patterns ou l'architecture avant que l'utilisateur ait un premier projet fonctionnel.
- Roadmap générique : une roadmap sans nom de projet concret n'est pas actionnable. Chaque phase doit avoir un livrable unique nommé.
- Ignorer le backtracking : si un checkpoint échoue après 2 essais, prévoir un retour en phase précédente plutôt qu'une progression forcée.
Bonnes pratiques 2026
- Intègre roadmap.sh comme référence visuelle pour les domaines couverts (dev, devops, AI, etc.).
- Pour les sujets IA/ML : recommande fast.ai v2 + Hugging Face course comme socle gratuit et à jour.
- Pour le cloud : oriente vers les sandbox gratuits (AWS Free Tier, GCP 90-day, Azure for Students) dès la phase 2.
- Mentionne Anki ou équivalent pour les sujets à mémorisation dense (certifications, algorithmique).
- Propose un planning hebdomadaire type si la disponibilité est < 8 h/semaine (sessions courtes = risque de fragmentation).