Vue d'ensemble technique¶

Cette section s'adresse aux équipes support, aux développeurs et à toute personne ayant besoin de comprendre comment Jigi est construit, au-delà de son usage fonctionnel.

Ce qu'est Jigi¶

Jigi est une plateforme SaaS multi-tenant de gestion d'entreprise : chaque société cliente (« tenant ») dispose d'un espace de données totalement cloisonné, sur une infrastructure mutualisée. La plateforme couvre les RH, la comptabilité, les réservations de ressources, les achats/prestataires et la gestion documentaire.

Stack technique¶

Couche	Technologie
Backend	Spring Boot 4, Java 21, Maven
ORM	Spring Data JPA / Hibernate (`ddl-auto: validate` — le schéma réel doit toujours correspondre exactement aux migrations)
Base de données	PostgreSQL 17
Cache	Redis 7
Migrations	Flyway (fichiers `V<version>__<module>_<description>.sql`, jamais modifiés après application)
Authentification	JWT (JJWT), Spring Security, 2FA TOTP
Frontend	Next.js 16, React 19, TypeScript
Style	Tailwind CSS v4
État serveur	TanStack Query v5
État client	Zustand v5
Formulaires	React Hook Form + Zod v4
Temps réel	STOMP over WebSocket (SockJS)
Stockage fichiers	MinIO (local) / S3 (production)
File de messages	RabbitMQ (emails, notifications)
Observabilité	Prometheus + Grafana

Organisation du code backend (`app.jigi.*`)¶

Le backend est organisé par domaine métier, pas par couche technique :

app.jigi/
├── auth/             # Authentification JWT, 2FA, gestion des mots de passe
├── tenant/           # Résolution et propagation du contexte tenant
├── hr/
│   ├── employee/     # Profils, contrats, organigramme
│   ├── leave/        # Congés et absences
│   ├── appraisal/    # Cycles d'évaluation de performance
│   ├── satisfaction/ # Enquêtes de satisfaction
│   └── recruitment/  # Recrutement : postes, candidats, entretiens, offres
├── accounting/       # Facturation, notes de frais, paie, comptabilité générale
├── booking/          # Réservation de salles et ressources
├── document/         # Stockage et versionnage de fichiers
├── supplies/         # Demandes et commandes de fournitures
├── prestataire/      # Prestataires externes
├── notification/     # Dispatch de notifications multi-canal
├── workflow/         # Moteur d'approbation générique
├── admin/            # Rôles, organisation, import en masse, tenants, opérateurs
├── subscription/      # Abonnements et cycle de vie (essai, paiement, renouvellement)
├── license/          # Licences on-premise
└── common/           # Éléments partagés : audit, config, exceptions, web

Chaque module suit la même architecture en couches :

controller/   ← endpoints REST, validation d'entrée
service/      ← logique métier, transactions
repository/   ← accès aux données (Spring Data JPA)
domain/       ← entités JPA et enums
dto/          ← objets de requête/réponse

Toutes les réponses API suivent une enveloppe standard ApiResponse<T> (success, data, error, meta).

Organisation du frontend¶

Deux applications Next.js distinctes cohabitent dans le même dépôt :

(dashboard)/dashboard/* — l'application utilisée par les employés, managers, RH, comptables de chaque société cliente (tenant).
admin-jigi/ — le backoffice réservé aux opérateurs internes de la plateforme Jigi, séparé du reste (voir Guide Administrateur plateforme Jigi).

Des routes publiques existent également pour des parcours sans authentification préalable : candidature à une offre d'emploi (apply/), confirmation d'entretien (interview/rsvp/), acceptation d'une lettre d'offre (offer/), activation de licence on-premise (license/activate).

Les quatre piliers architecturaux¶

Multi-tenance — comment les données de chaque société sont isolées.
Rôles & permissions (RBAC) — comment les accès sont contrôlés, avec un modèle de rôles dynamique et configurable par tenant.
Moteur de workflow — le moteur d'approbation générique partagé par tous les modules qui ont besoin d'un circuit de validation.
Notifications — comment les emails, notifications in-app et alertes temps réel sont envoyés, de façon asynchrone via une file de messages.