Processus et Workflow ProbatioVault¶

Cycle de vie d'une User Story¶

1. Spécification¶

EPIC identifiée
    ↓
Création dossier PD-XX-<short-name>/
    ↓
Rédaction PD-XX-specification.md
    ↓
Validation Product Owner

Responsable : Product Owner / Tech Lead Livrable : PD-XX-specification.md

2. Conception¶

Specification validée
    ↓
Rédaction PD-XX-plan.md
    ↓
Revue architecture
    ↓
Validation Tech Lead

Responsable : Tech Lead / Développeur Senior Livrable : PD-XX-plan.md

3. Critères d'acceptation¶

Implementation plan validé
    ↓
Rédaction PD-XX-acceptability.md
    ↓
Définition tests requis
    ↓
Validation QA

Responsable : QA / Tech Lead Livrable : PD-XX-acceptability.md

4. Implémentation¶

Acceptability validée
    ↓
Création branche feature/PD-XX
    ↓
Développement
    ↓
Tests unitaires
    ↓
Pull Request

Responsable : Développeur Livrable : Code + Tests

5. Validation¶

PR créée
    ↓
Code review
    ↓
CI pipeline (lint, test, sonar)
    ↓
Merge si OK

Responsable : Reviewer + CI Livrable : Code mergé

6. REX¶

US déployée
    ↓
Rédaction PD-XX-rex.md
    ↓
Capitalisation enseignements

Responsable : Développeur / Tech Lead Livrable : PD-XX-rex.md

Workflow Git¶

Branches¶

Commits¶

Format : <type>(<scope>): <description>

Types :

• feat : Nouvelle fonctionnalité
• fix : Correction bug
• docs : Documentation
• refactor : Refactoring
• test : Tests
• chore : Maintenance

Exemple : feat(crypto): implement HKDF-SHA3-256 key derivation

Pull Requests¶

1. Titre : PD-XX: <description courte>
2. Description : Lien vers spec + résumé changements
3. Checklist :
4. Tests passants
5. Coverage maintenue
6. Documentation à jour
7. Pas de secrets exposés

Pipeline CI/CD¶

Push/PR
    ↓
[lint] → ESLint + Prettier
    ↓
[type-check] → TypeScript
    ↓
[test] → Jest + Coverage
    ↓
[sonar] → Quality Gate
    ↓
[build] → EAS / Docker
    ↓
[deploy] → (si main)

Revue de code¶

Critères obligatoires¶

• Pas de any TypeScript
• Pas de secrets en dur
• Tests pour nouveau code
• Gestion d'erreurs appropriée
• Logging sans données sensibles

Bonnes pratiques¶

• Revue dans les 24h
• Maximum 400 lignes par PR
• Un reviewer minimum
• Discussion constructive