# 9. Guide de développement

## Flux Git

Le flux pratiqué est `feature/*` vers `dev`, puis `dev` vers `main`. Ne pas développer directement sur `main`.

```bash
git fetch origin --prune
git switch main
git pull --ff-only origin main
git switch -c feature/nom-court
```

Si `dev` contient les dernières intégrations, partir de `dev` est préférable pour une fonctionnalité destinée à la prochaine version :

```bash
git switch dev
git pull --ff-only origin dev
git switch -c feature/nom-court
```

Avant une PR, fusionner ou rebaser selon la convention de l’équipe, résoudre les conflits, tester, pousser puis vérifier la comparaison base/compare dans GitHub.

## Ajouter ou modifier une règle métier

1. Localiser toutes les utilisations avec `rg` : écran, service, export, état, validation et tests.
2. Écrire les exemples métier, dont dates limites et valeurs nulles.
3. Modifier le service backend, pas seulement l’interface.
4. Adapter les validators et la route si le contrat API change.
5. Adapter le frontend et les types.
6. Ajouter des tests de non-régression.
7. Tester avec un compte aux droits limités.
8. Documenter l’impact base/exploitation.

Exemple : la règle “salarié actif” apparaît dans la liste, le compteur et des états à date. Une correction dans un seul emplacement crée des nombres contradictoires.

## Ajouter un champ de base

1. Modifier `schema.prisma`.
2. Créer une migration explicite.
3. Examiner le SQL généré, notamment nullabilité, valeurs par défaut et index.
4. Mettre à jour les seeds/imports et éventuels scripts Access.
5. Modifier services, validators, routes, types et formulaires.
6. Tester sur une copie réaliste de MySQL.
7. Préparer le plan de retour arrière.

## Ajouter un endpoint

- créer la route dans `src/app/api` ;
- appliquer l’authentification et la permission dès le début ;
- valider paramètres et corps avec Zod ;
- déléguer le métier au service ;
- retourner les codes 400/401/403/404/409/422/500 appropriés ;
- documenter OpenAPI ;
- tester accès autorisé et interdit.

## Commandes de qualité

Backend :

```bash
cd backend/backend_envie2e
npm ci
npm run lint
npm test
npm run test:coverage
npm run build
```

Frontend :

```bash
cd frontend
npm ci
npm run lint
npm run build
```

Les noms exacts de scripts doivent être vérifiés dans le `package.json` de la branche courante.

## Tests et CI

La version analysée contient environ 81 fichiers de test, dont des tests d’intégration. Le workflow GitHub construit frontend et backend, mais la commande de tests backend est commentée. C’est une dette de qualité importante : une PR verte garantit surtout la compilation, pas l’ensemble des comportements.

Avant de réactiver les tests en CI, stabiliser les dépendances MySQL, les secrets de test et les données fixtures. Puis rendre le test obligatoire progressivement.

## Données de test

Ne jamais utiliser de vraies données RH dans des fixtures committées. Anonymiser noms, e-mails, matricules, COS, contrats et PDF. Ne jamais copier un `.env.production` dans une branche de test.