Plan et méthode

Ce parcours amène un développeur Java/Spring à écrire une API NestJS complète en 11 jours de travail à temps plein. Chaque jour combine une notion, son équivalent Spring et sa mise en pratique dans TaskFlow, une API de gestion de projets et de tâches. Cette page fixe le cadre : dates, prérequis, routine quotidienne, calendrier et suivi.

En bref

Élément	Détail
Démarrage	lundi 9 novembre 2026
Fin	mardi 24 novembre 2026
Durée	11 jours à temps plein, soit environ 2,5 semaines (le mercredi 11 novembre, férié, est sauté)
Prérequis	TypeScript déjà vu, Docker installé
Stack	NestJS, TypeScript, PostgreSQL, TypeORM, Docker Compose, Jest
Fil rouge	TaskFlow, une API de gestion de projets et de tâches

Les versions utilisées par TaskFlow, et donc par tous les extraits du site : NestJS 12.1, TypeScript 6.0, TypeORM 1.1, PostgreSQL 16, Jest 30, Express 5 comme plateforme HTTP. L'image Docker tourne sur Node 24 LTS : utilisez la même version majeure en local pour éviter les écarts.

Le fil rouge TaskFlow

TaskFlow grandit d'un jour à l'autre : un endpoint /health le premier jour, un CRUD en mémoire le deuxième, PostgreSQL le quatrième, l'authentification le huitième, l'image Docker et la CI le dernier. Le projet complet se trouve dans le dossier examples/ du dépôt de ce site. Il compile, passe le lint, 27 tests unitaires et 8 tests e2e sur une vraie base PostgreSQL. Tous les extraits de code des chapitres en sont tirés.

• Le domaine (utilisateurs, projets, membres, tâches) est décrit dans Modèle de domaine.
• L'arborescence et les conventions de nommage sont dans Structure du repo.
• Pour lancer le projet : Ressources, TaskFlow.

Vous pouvez suivre le parcours de deux façons : reconstruire TaskFlow vous-même jour après jour (c'est l'intention du plan), ou lire le projet fini et vous concentrer sur les explications. La première apprend davantage ; gardez le projet fini comme corrigé.

Méthode de travail

Chaque jour suit le même schéma :

Moment	Durée	Contenu
Matin	3 h	Théorie courte et correspondances Spring ↔ Nest, avec la documentation officielle
Après-midi	3 h	Implémentation dans TaskFlow, tests, commit
Fin de journée	30 min	Mise à jour de LEARNINGS.md (ce qui diffère de Spring, les pièges) et tag git jour-XX

Le matin, partez du chapitre du jour : la table « Spring → NestJS » donne le point d'entrée, la section « Comprendre » explique le fonctionnement, les liens « Pour aller plus loin » mènent à la documentation officielle. La table de correspondances complète sert de carte quand une notion Spring vous vient en tête sans que vous sachiez où elle se trouve côté Nest.

L'après-midi, travaillez dans TaskFlow en suivant la section « Cas TaskFlow » puis les « Exercices » du chapitre. Terminez par un commit qui compile et dont les tests passent.

Un commit par jour (ou par fonctionnalité) permet de relire l'historique comme un journal d'apprentissage : chaque commit raconte une étape, dans l'ordre où vous l'avez comprise.

Journal d'apprentissage

LEARNINGS.md est le carnet de bord du parcours. Le modèle livré avec TaskFlow propose trois rubriques par jour :

# LEARNINGS

Journal à remplir chaque fin de journée (30 min), puis `git tag jour-XX`.
Pour chaque jour : ce qui diffère de Spring, les pièges rencontrés, les questions ouvertes.

## J1 · Fondations Node et Nest

- Différence avec Spring :
- Piège rencontré :
- À creuser :

## J2 · Controllers, DTO, validation

- Différence avec Spring :
- Piège rencontré :
- À creuser :

<!-- Copier le bloc pour J3 à J11. -->

Notez surtout ce qui vous a surpris en venant de Spring : c'est ce que vous chercherez dans six mois. Les entrées courtes et concrètes (« @Query() reçoit des chaînes, il faut @Type(() => Number) ») valent mieux qu'un résumé de cours.

En fin de journée, taguez l'état du dépôt :

git add -A
git commit -m "J2 : CRUD projects en mémoire, DTO validés"
git tag jour-02

Les tags permettent ensuite de relire le parcours :

git log --oneline --decorate     # l'historique, avec les tags jour-XX
git diff jour-04 jour-05 --stat  # ce qu'a changé la journée des relations et migrations
git checkout jour-03             # revenir à l'état du J3 (git switch - pour repartir)

Calendrier

Jour	Date	Thème	Livrable TaskFlow
J1	lun. 9/11	Node, event loop, projet Nest, architecture modulaire	Squelette, Docker Compose, premier endpoint
J2	mar. 10/11	Controllers, routing, DTO, validation	CRUD Projects en mémoire
	mer. 11/11	Férié
J3	jeu. 12/11	Injection de dépendances, providers, services	Couche service, modules
J4	ven. 13/11	PostgreSQL, TypeORM, entités, repositories	Persistance Projects
J5	lun. 16/11	Relations, migrations, transactions	Tasks liées aux Projects, migrations
J6	mar. 17/11	Exceptions, filters, pipes, interceptors, middlewares	Gestion d'erreurs globale, logs de requêtes
J7	mer. 18/11	Configuration, profils, logging	ConfigModule validé, env par environnement
J8	jeu. 19/11	Authentification JWT, guards, rôles	Users, login, routes protégées
J9	ven. 20/11	Événements, tâches planifiées, async, queues	Notifications sur changement de statut
J10	lun. 23/11	Tests unitaires, intégration et e2e	Couverture sur les modules clés
J11	mar. 24/11	Swagger, health checks, Dockerfile, CI, revue finale	Image Docker, pipeline CI, doc OpenAPI

Sur trois semaines civiles : 4 jours la première (le mercredi est férié), 5 la deuxième, 2 la troisième.

Suivi de progression

Cochez une ligne quand le livrable du jour est commité et tagué.

• [ ] J1 : Fondations, squelette, Compose (chapitre)
• [ ] J2 : Controllers, DTO, validation (chapitre)
• [ ] J3 : DI et modules (chapitre)
• [ ] J4 : TypeORM et PostgreSQL (chapitre)
• [ ] J5 : Relations, migrations, transactions (chapitre)
• [ ] J6 : Exceptions, filters, interceptors (chapitre)
• [ ] J7 : Configuration et logging (chapitre)
• [ ] J8 : Auth JWT et rôles (chapitre)
• [ ] J9 : Événements, cron, queues (chapitre)
• [ ] J10 : Tests unitaires et e2e (chapitre)
• [ ] J11 : Swagger, health, Docker, CI (chapitre)

Conseils

Aucun jour de marge

Le calendrier enchaîne 11 jours sans tampon. Un retard le J4 (une connexion PostgreSQL qui refuse de s'établir, une entité mal décorée) se reporte sur toute la suite. Décidez dès le départ ce que vous sacrifierez si vous prenez du retard, et terminez chaque journée sur un état qui compile, même incomplet.

Ce qui est optionnel

Ces éléments peuvent sauter sans casser la suite du parcours :

Élément	Jour	Ce que fait TaskFlow
File BullMQ pour les notifications (Redis)	J9	Implémentée, mais activée seulement si REDIS_URL est défini ; sinon le listener écrit un log
Refresh token	J8	Non implémenté : un access token JWT de 15 min
Testcontainers pour les tests e2e	J10	Non utilisé : les e2e tournent sur le service Compose db-test

TypeScript à réviser si besoin

Le plan suppose TypeScript « déjà vu ». Si ce n'est qu'un souvenir, revoyez avant le J1 :

• interface et type (effacés à l'exécution) face aux class (qui existent à l'exécution) : c'est la clé de l'injection de dépendances et de la validation (différences) ;
• les propriétés de paramètre (constructor(private readonly service: ProjectsService) {}), utilisées dans chaque provider ;
• les unions et le rétrécissement de type (string | null, if (!task) throw …), les enum à valeurs chaînes ;
• ?. et ??, très présents dans le code Nest ;
• async/await et Promise<T> (J1) ;
• les imports et exports de modules, y compris import type ;
• les décorateurs (experimentalDecorators dans tsconfig.json) : ce sont des fonctions, pas des annotations (différences).

Écrire des tests dès le J3

Le plan regroupe les tests au J10, mais n'attendez pas : dès que le J3 isole ProjectsService derrière une abstraction, un test unitaire avec Test.createTestingModule et un store en mémoire s'écrit en quelques lignes (J10, module de test). Ajoutez ensuite un test par règle métier au fil des jours (accès réservé aux membres, transitions de statut, archivage). Le J10 sert alors à compléter les e2e et à fixer le seuil de couverture, pas à tout écrire d'un coup, et chaque refactorisation des jours suivants (passage à TypeORM au J4, ajout des utilisateurs au J8) est protégée.