🛡️ Exigences techniques

Principe : cette page fixe les regles de travail d equipe. Elle doit aider a prendre une decision vite, pas a produire du texte de conformite.

flowchart LR
    J[Jira] --> B[Branche Git]
    B --> PR[Pull Request]
    PR --> CI[Lint + Tests]
    CI --> DOC[Docs a jour]
    DOC --> DONE[Done]

1. Gestion du code source (GitHub)

1.1 Branches

• La branche main est protegee — aucun push direct autorise
• La branche develop est la branche d'integration — toute feature en part et y revient
• Toute nouvelle branche part de develop et y est mergee via Pull Request

Type	Convention	Exemple
User Story	us/BDD-<num>/<nom-court>	us/BDD-42/depot-fichier
Bug fix	fix/BDD-<num>/<nom-court>	fix/BDD-57/upload-timeout
Technical Story	ts/BDD-<num>/<nom-court>	ts/BDD-12/setup-nestjs
Hotfix production	hotfix/BDD-<num>/<nom-court>	hotfix/BDD-99/auth-crash

Le numero BDD-<num> correspond au numero du ticket Jira — cela permet la tracabilite automatique entre GitHub et Jira.

1.2 Commits

Commits reguliers et atomiques — un commit = une intention claire.

Convention Conventional Commits obligatoire :

Prefixe	Usage
feat:	Nouvelle fonctionnalite
fix:	Correction de bug
refactor:	Refactoring sans changement de comportement
test:	Ajout ou modification de tests
docs:	Mise a jour de la documentation
chore:	Tache technique (config, dependances)
style:	Formatage, lint (sans changement logique)

Exemple : feat(upload): add file size validation before S3 transfer

Le message de commit doit etre en anglais, au present, et explicite.

1.3 Pull Requests

• Toute US ou ticket Jira fait l'objet d'une PR dediee
• La PR doit referencer le ticket Jira dans son titre : [BDD-42] Depot de fichier client
• Au moins 1 approbation requise avant de merger
• La PR ne doit contenir que ce qui est defini dans le ticket associe — pas de changements hors perimetre
• Le merge sur develop se fait en squash merge
• Le merge de develop vers main se fait en merge commit (releases uniquement)
• Toute PR doit passer les checks CI (lint, tests) avant d'etre mergeable

2. Qualite du code

2.1 Lint et formatage

• ESLint et Prettier sont configures et ne doivent pas etre desactives
• Ne jamais modifier le lint ou le formatage de code qui n'est pas dans le perimetre du ticket en cours
• Si une regle lint pose probleme, ouvrir un ticket dedie (ts/BDD-<num>/fix-lint-rule)
• Le CI bloque le merge en cas d'erreur lint

2.2 Perimetre des modifications

• Chaque ticket ne doit modifier que ce qui est strictement necessaire a son implementation
• Toute modification hors perimetre (refactoring opportuniste, nettoyage de code) doit faire l'objet d'un ticket separe
• Les dependances (packages npm) ne doivent pas etre mises a jour hors d'un ticket dedie

2.3 Variables d'environnement

• Aucun secret, cle d'API ou credential ne doit apparaitre dans le code ou etre commite
• Toutes les variables sensibles sont gerees via .env (non commite)
• Un fichier .env.example est maintenu a jour avec toutes les variables necessaires (sans leurs valeurs)

3. Tests

3.1 Structure

• Tests unitaires places au plus pres du code teste : *.spec.ts dans le meme dossier (convention NestJS)
• Tests fonctionnels (e2e) places dans le dossier test/ a la racine du projet backend, et e2e/ pour le frontend

3.2 Couverture

• Chaque US ou ticket fonctionnel doit etre accompagne de tests couvrant ses criteres d'acceptance
• Les tests unitaires couvrent la logique metier des services et des guards
• Les tests e2e couvrent les endpoints API de bout en bout
• Un ticket n'est considere comme termine que si ses tests passent

3.3 CI

• Les tests sont executes automatiquement a chaque push et a chaque PR
• Le merge est bloque si les tests echouent

4. Documentation

4.1 Principe de separation

Ou	Quoi
Repo GitHub (docs/)	Documentation technique et utilisateur, vivante, versionnee avec le code
Confluence	Documentation projet : US, maquettes, ADR, personas, roadmap, decisions

4.2 Regles de mise a jour

• Toute US ou ticket fonctionnel → mise a jour ou creation de la page docs/ correspondante
• La documentation est redigee en francais
• La documentation est rendue via VitePress
• Une PR sans mise a jour de la documentation ne peut pas etre mergee si la fonctionnalite est visible par l'utilisateur

5. Gestion des tickets Jira

5.1 Cycle de vie d'un ticket

Un ticket suit le cycle : To Do → In Progress → In Review → Done

Statut	Description
To Do	Ticket pret a etre demarre (criteres d'acceptance rediges)
In Progress	Developpement en cours, branche creee
In Review	PR ouverte, en attente de revue
Done	PR mergee, tests passants, documentation mise a jour

5.2 Definition of Done (DoD)

Un ticket est considere Done uniquement si :

• Le code est merge sur develop
• Les tests unitaires et/ou e2e couvrant les criteres d'acceptance passent
• La documentation (docs/) est mise a jour si applicable
• Les temps sont saisis sur le ticket
• La PR a ete approuvee par au moins 1 autre developpeur

6. Versioning de l'API

• L'API NestJS est versionnee des le depart : /api/v1/...
• Toute modification breaking change sur un endpoint existant necessite une nouvelle version (/api/v2/...) et un ticket dedie
• Les anciennes versions sont maintenues le temps de la migration des clients

7. Securite

• Aucune donnee sensible (tokens, mots de passe, cles) ne transite dans les logs
• Les inputs utilisateurs sont systematiquement valides cote backend (NestJS Pipes + class-validator)
• Les dependances sont auditees regulierement (npm audit) — les vulnerabilites critiques font l'objet d'un ticket correctif immediat
• Les headers de securite HTTP sont configures (ex. via helmet dans NestJS)