Aller au contenu

Roadmap missions — jobPipeline

Contexte

Plan de missions découlant de la vision produit (jobPipeline/architecture/vision-produit-pipeline-recherche-emploi-ia), découpé pour être exécuté mission par mission via le workflow d'orchestration Claude Code du projet.

Contenu

Étape 1 — Valider le socle

cd /home/kanmaber/projets/jobPipeline/BackEnd
npx tsc --noEmit        # 0 erreur attendu
npm run start:dev       # serveur démarre
curl http://localhost:3000/api/health

Étape 2 — Module Auth (prérequis de tous les modules)

Le middleware JWT doit exister avant toute route protégée. Routes : POST /api/v1/auth/connexion, /rafraichir, /deconnexion. Modèles concernés : Utilisateur + Candidate.

(Mise à jour depuis la rédaction de ce plan : le module Auth a finalement été câblé via un package partagé @kanmaber/auth-backend plutôt qu'écrit de zéro — voir jobPipeline/architecture/procedure-cablage-auth-package.)

Phase 1 — Pipeline manuel (ordre des missions)

# Mission Ce qu'elle crée
1 architecture_backend ✅ Socle partagé (ErreurMetier, Prisma, logger, Redis, BaseActionHandler, GestionnaireModulaire, authMiddleware, DIContainer, app.ts, server.ts)
2 module_auth ✅ Connexion JWT, Utilisateur + Candidate en base — via @kanmaber/auth-backend + authMiddleware.ts réécrit (format jose/idUtilisateur/role.nom) et testé end-to-end (2026-07-04)
3 module_resume_master ✅ CRUD du CV maître JSON — 1 CV actif par utilisateur, versionné (incrément à chaque modification), testé end-to-end (2026-07-04)
4 module_job_offer ✅ Ajout manuel d'offre + liste (+ obtention par id) — backend et frontend conformes aux deux guides de référence, testés end-to-end (2026-07-06)
5 agent_analyse Offre → JobAnalysis via Anthropic API
6 agent_scoring JobAnalysis × ResumeMaster → MatchingScore
7 agent_resume_version CV ciblé depuis ResumeMaster + analyse
8 agent_cover_letter Lettre de motivation depuis CV ciblé + analyse
9 module_application Validation humaine + suivi des statuts

Phase 2 — Collecte automatique

# Mission Ce qu'elle crée
10 connecteur_greenhouse Connecteur JSON public
11 connecteur_lever Connecteur API publique Lever
12 connecteur_remotive Connecteur API Remotive (remote/tech)
13 connecteur_adzuna Connecteur API Adzuna (quota journalier)
14 connecteur_france_travail Connecteur API France Travail
15 orchestrateur_cron BullMQ — collecte quotidienne 6h (Africa/Lagos)
16 dashboard_quotidien Récap des nouvelles offres matchées

Phase 3 — Suivi enrichi (futur)

Relances automatiques (email si pas de réponse sous N jours), préparation entretiens (contexte entreprise + questions probables via IA), analytics (taux de match par source, par type de poste, évolution score).

Commande pour lancer une mission module

cd /home/kanmaber/projets/jobPipeline
HORODATAGE=$(date +%Y%m%d_%H%M%S)
MISSION=module_auth
mkdir -p .claude/missions/${HORODATAGE}_${MISSION}
cp .claude/MISSION_TEMPLATE.md .claude/missions/${HORODATAGE}_${MISSION}/lePrompte.md
nano .claude/missions/${HORODATAGE}_${MISSION}/lePrompte.md
./.claude/run-mission.sh ${HORODATAGE}_${MISSION}

Décision / Conclusion

Document daté du 2026-06-27 — mission #1 (architecture_backend) seule marquée faite à cette date. Depuis, le module Auth (mission #2) a été traité différemment du plan initial : via l'intégration d'un package partagé extrait de ProjetESM plutôt qu'écrit spécifiquement pour jobPipeline (voir jobPipeline/architecture/procedure-cablage-auth-package).

Mise à jour 2026-07-04 : mission #2 (module_auth) marquée ✅. L'ancien authMiddleware.ts (format payload.sub/role en chaîne, hérité de jsonwebtoken) était câblé dans app.ts/GestionnaireModulaire mais jamais réellement invoqué (monterModules([]) — zéro route métier enregistrée). Supprimé et remplacé au même emplacement par une version jose alignée sur le format exact émis par @kanmaber/auth-backend (idUtilisateur, role: {idRole, nom, permissions[]}, sessionId). Vérifié : compilation TS propre, démarrage serveur réel, test end-to-end complet (inscription → connexion → décodage d'un token réel avec la logique exacte du nouveau middleware).

Mise à jour 2026-07-04 (suite) : mission #3 (module_resume_master) marquée ✅. Module DDD complet (5 couches) suivant strictement 1_GUIDE_ARCHITECTURE_DDD.md — CRUD POST/GET/PUT/DELETE sur /api/v1/resume-master, sans route dynamique /:id car un seul CV maître actif par utilisateur (règle métier). Suppression = soft-delete (actif: false). version incrémentée automatiquement à chaque modification. A nécessité la création d'une brique partagée manquante : IAuditLogRepository / AuditLogRepositoryPrisma (table AuditLog déjà présente dans le schéma depuis la mission #1 mais jamais implémentée côté code), pour respecter l'étape 3 obligatoire (audit non-bloquant) du pattern use case. Testé end-to-end en conditions réelles : dépôt → doublon rejeté (409) → obtention → modification (v1→v2) → suppression → obtention après suppression (404) → accès sans token (401) — et les 3 entrées d'audit correspondantes vérifiées en base.

Mise à jour 2026-07-06 : mission #4 (module_job_offer) marquée ✅, backend et frontend, avec exigence explicite de Bernard de conformité à 100% aux deux fichiers de référence (spécs/1_GUIDE_ARCHITECTURE_DDD.md et spécs/2_REFERENCE_FRONTEND_FINAL.md).

Backend : JobOffer est une entité globale (pas de filtre idUtilisateur, contrairement à ResumeMaster) — 3 use cases (Ajouter/Lister/Obtenir, pas de Modifier/Supprimer : hors scope roadmap). Déduplication par hash entreprise::titre (règle métier déjà définie dans OBJECTIFS_PROJET.md) : une offre déjà connue est rejetée (409 OFFRE_DEJA_EXISTANTE). Routes /api/v1/job-offers (GET /, POST /, GET /:id).

Frontend : module complet en 4 couches (domain/application/infrastructure/ presentation), page JobOfferPage (formulaire d'ajout + liste), route /offres, nav ajoutée dans RootLayout.

Bug corrigé au passage : FrontEnd/tsconfig.json n'avait pas noEmit: true — npm run build (tsc && vite build) faisait donc émettre par tsc un .js à côté de chaque fichier .ts/.tsx du projet (pollution découverte dans Modules/ResumeMaster/ lors du démarrage de cette mission, provenant du build de la mission #3). Fichiers .js générés supprimés, noEmit: true ajouté — tsc ne sert plus que de garde de type avant le build Vite, comme prévu par la référence frontend.

À faire

  • Missions #5 à #9 (Phase 1) : non commencées.
  • Prochaine étape recommandée : mission #5 (agent_analyse), premier agent IA du pipeline (offre → JobAnalysis via Anthropic API).

Liens connexes