Entourage Pro — Backend
API REST et worker asynchrone d'Entourage Pro, le premier réseau professionnel solidaire : la plateforme met en relation des candidats en recherche d'emploi et en manque de réseau, des coachs bénévoles, des prescripteurs (structures d'accompagnement) et des entreprises partenaires.
Stack : NestJS 11 · TypeScript 6 · PostgreSQL 17 + pgvector · Sequelize · Redis + BullMQ · Node 24
Démarrage rapide
Pré-requis : Docker (avec Compose) et Node.js 24.15.0 (voir .nvmrc) — plus pnpm 11.15.0 si tu travailles hors conteneur.
cp .env.dist .env # variables de l'API et du worker
cp .env.dist .env.test # variables utilisées par la suite e2e
pnpm all:dev:docker:build # API + worker + Postgres + Redis + agent Datadog
Les deux fichiers sont à créer soi-même et ne sont pas versionnés ; voir « Configuration » pour ce qu'il faut remplir.
L'API écoute sur http://localhost:3002, Swagger sur http://localhost:3002/api.
Le premier lancement construit l'image, installe les dépendances dans le volume et démarre en mode watch. Les migrations ne sont pas jouées automatiquement en local :
docker exec api pnpm db:create # si la base n'existe pas encore
docker exec api pnpm db:migrate
docker exec api pnpm db:seed # admin + référentiels (secteurs, métiers, langues, départements…)
Le seeder crée un compte administrateur utilisable immédiatement :
Email : [email protected]
Mot de passe : Admin123!
Sans Docker
Nécessite un Postgres 17 avec l'extension vector et un Redis joignables via DATABASE_URL / REDIS_URL.
pnpm install
pnpm db:migrate
pnpm api:dev # API en watch
pnpm worker:dev # worker en watch (autre terminal)
Compiler et lancer comme en production
pnpm build # nest build → dist/
pnpm api:start # node dist/main
pnpm worker:start # node dist/worker
Charger un dump SQL dans la base de dev
docker exec -i db psql -U entourage_pro -d entourage_pro < dump.sql
Ou en interactif (mot de passe : entourage_pro, cf. docker-compose.yml) :
docker exec -it db sh
psql -d entourage_pro -p 5432 -U entourage_pro -W
Les deux processus
Le repo produit deux applications à partir de la même base de code, avec deux racines de modules distinctes :
Le worker partage la configuration Sequelize de l'API (getSequelizeOptions() exporté par app.module.ts) avec un pool élargi (max: 10), et n'importe que ConsumersModule + CronModule.
Sur Heroku, les trois process du Procfile : release (migrations), web (API), mainWorker (worker).
pnpm api:dev:docker # API seule (+ db, redis, datadog)
pnpm worker:dev:docker # API + worker
pnpm all:dev:docker # idem, alias explicite
Architecture
Organisation du code
Un dossier par domaine sous src/, chacun suivant la même convention :
src/<domain>/
├── <domain>.module.ts # câblage NestJS
├── <domain>.controller.ts # routes HTTP
├── <domain>.service.ts # logique métier
├── <domain>.types.ts # enums, unions, types partagés
├── <domain>.utils.ts # helpers purs
├── <domain>.attributes.ts # listes d'attributs Sequelize réutilisables
├── <domain>.includes.ts # includes Sequelize réutilisables
├── dto/ # DTO validés par class-validator
└── models/ # modèles sequelize-typescript
Le domaine utilisateur est volontairement éclaté en modules à responsabilité unique plutôt qu'en un gros UsersModule — users, users-creation, users-deletion, users-stats, user-profiles, et une famille user-profile-* (experiences, formations, skills, languages, interests, media, embeddings, recommendations, moderation, analytics, contracts, nudges, shares, sector-occupations…).
Les intégrations tierces sont regroupées sous src/external-services/ : mailjet, salesforce, slack, vonage, pusher, anthropic, cv-extraction, voyageai, linkedin, shortio, aws, plus l'observabilité LLM (ai-observability, llm-metrics).
À côté des dossiers de domaine, src/ contient :
This is the beginning of the README. Read the rest at the original. Read the full README ↗
