288 lines
12 KiB
Markdown
288 lines
12 KiB
Markdown
# ORIGIN_FEATURE_VALIDATION_STRATEGY.md
|
|
|
|
## 📋 RÉSUMÉ EXÉCUTIF
|
|
|
|
Ce document définit la stratégie de validation stricte pour garantir que chaque feature soit **100% fonctionnelle** avant d'être marquée comme complétée. Cette stratégie élimine le problème des features "complétées" mais non fonctionnelles.
|
|
|
|
## 🎯 OBJECTIFS
|
|
|
|
### Objectif Principal
|
|
Garantir que **chaque feature implémentée est 100% fonctionnelle** dès le début, peu importe sa complexité, en suivant un processus de validation rigoureux conforme aux standards ORIGIN.
|
|
|
|
### Objectifs Secondaires
|
|
- Éliminer les features "complétées" mais non fonctionnelles
|
|
- Réduire le temps de debugging post-implémentation à zéro
|
|
- Assurer la cohérence entre le code et le comportement attendu
|
|
- Maintenir la confiance dans le statut "complété" des tâches
|
|
|
|
## 🔒 RÈGLES IMMUABLES
|
|
|
|
1. **Aucune tâche ne peut être marquée "complétée" sans validation manuelle complète**
|
|
2. **Chaque feature DOIT être testée dans le navigateur/app avant validation**
|
|
3. **Tous les chemins d'utilisation DOIVENT être testés** (happy path + edge cases + error cases)
|
|
4. **Les erreurs console DOIVENT être résolues avant validation**
|
|
5. **Les tests automatisés DOIVENT passer avant validation**
|
|
6. **La documentation DOIT être à jour avant validation**
|
|
7. **Les dépendances backend/frontend DOIVENT être vérifiées**
|
|
8. **Les intégrations (API, WebSocket, etc.) DOIVENT être fonctionnelles**
|
|
9. **L'UX DOIT être cohérente et intuitive**
|
|
10. **Les performances DOIVENT être acceptables (< 100ms pour actions utilisateur)**
|
|
|
|
## 📋 CHECKLIST DE VALIDATION OBLIGATOIRE
|
|
|
|
### Phase 1: Validation Technique (Backend)
|
|
|
|
#### ✅ Backend API
|
|
- [ ] **Routes configurées** : Routes définies dans `routes.go` et accessibles
|
|
- [ ] **Handlers implémentés** : Tous les handlers nécessaires existent et fonctionnent
|
|
- [ ] **Services implémentés** : Services métier complets avec logique correcte
|
|
- [ ] **Repositories implémentés** : Accès données fonctionnel
|
|
- [ ] **Validation des données** : Validation des inputs (binding, required, format)
|
|
- [ ] **Gestion d'erreurs** : Erreurs gérées proprement avec codes HTTP appropriés
|
|
- [ ] **Authentification** : Middleware auth appliqué si nécessaire
|
|
- [ ] **Logging** : Logs appropriés pour debugging
|
|
- [ ] **Tests unitaires** : Tests passent avec coverage ≥ 80%
|
|
- [ ] **Tests d'intégration** : Tests API passent (curl/Postman)
|
|
|
|
#### ✅ Base de données
|
|
- [ ] **Migrations** : Migrations SQL créées et appliquées
|
|
- [ ] **Schéma** : Tables/colonnes créées correctement
|
|
- [ ] **Indexes** : Indexes créés pour performance
|
|
- [ ] **Contraintes** : Foreign keys, unique constraints, etc.
|
|
- [ ] **Données de test** : Données de test créées si nécessaire
|
|
|
|
### Phase 2: Validation Technique (Frontend)
|
|
|
|
#### ✅ Composants React
|
|
- [ ] **Composants créés** : Tous les composants nécessaires existent
|
|
- [ ] **Props typées** : TypeScript types corrects
|
|
- [ ] **État géré** : State management (Zustand/Context) fonctionnel
|
|
- [ ] **Handlers d'événements** : onClick, onSubmit, etc. implémentés
|
|
- [ ] **Validation formulaire** : Validation côté client si nécessaire
|
|
- [ ] **Gestion d'erreurs** : Erreurs affichées à l'utilisateur
|
|
- [ ] **Loading states** : États de chargement affichés
|
|
- [ ] **Accessibilité** : ARIA labels, keyboard navigation
|
|
- [ ] **Responsive** : Design responsive fonctionnel
|
|
|
|
#### ✅ Intégrations
|
|
- [ ] **API calls** : Appels API fonctionnels (GET, POST, PUT, DELETE)
|
|
- [ ] **WebSocket** : Connexions WebSocket fonctionnelles si nécessaire
|
|
- [ ] **Token management** : Gestion des tokens JWT correcte
|
|
- [ ] **Error handling** : Gestion des erreurs API (401, 404, 500, etc.)
|
|
- [ ] **Retry logic** : Logique de retry si nécessaire
|
|
|
|
### Phase 3: Validation Fonctionnelle (Manuelle)
|
|
|
|
#### ✅ Test dans le navigateur
|
|
- [ ] **Feature accessible** : Feature accessible via navigation/URL
|
|
- [ ] **UI visible** : Interface utilisateur s'affiche correctement
|
|
- [ ] **Interactions fonctionnelles** : Clics, saisies, soumissions fonctionnent
|
|
- [ ] **Flux complet** : Flux utilisateur complet testé de bout en bout
|
|
- [ ] **Edge cases** : Cas limites testés (champs vides, valeurs invalides, etc.)
|
|
- [ ] **Error cases** : Cas d'erreur testés (API down, timeout, etc.)
|
|
- [ ] **Navigation** : Navigation entre pages fonctionnelle
|
|
- [ ] **Redirections** : Redirections après actions fonctionnent
|
|
|
|
#### ✅ Console du navigateur
|
|
- [ ] **Aucune erreur console** : Pas d'erreurs JavaScript/TypeScript
|
|
- [ ] **Aucun warning critique** : Warnings non bloquants acceptables
|
|
- [ ] **Network requests** : Requêtes réseau réussies (200, 201, etc.)
|
|
- [ ] **WebSocket connections** : Connexions WebSocket établies si nécessaire
|
|
|
|
#### ✅ UX/UI
|
|
- [ ] **Design cohérent** : Design conforme au système de design
|
|
- [ ] **Feedback utilisateur** : Messages de succès/erreur affichés
|
|
- [ ] **Loading indicators** : Indicateurs de chargement visibles
|
|
- [ ] **Animations** : Animations fluides (si applicable)
|
|
- [ ] **Performance** : Temps de réponse < 100ms pour actions utilisateur
|
|
|
|
### Phase 4: Validation des Intégrations
|
|
|
|
#### ✅ Backend ↔ Frontend
|
|
- [ ] **Endpoints accessibles** : Endpoints backend accessibles depuis frontend
|
|
- [ ] **Format de données** : Format de données cohérent (JSON, types)
|
|
- [ ] **Authentification** : Tokens JWT transmis correctement
|
|
- [ ] **CORS** : CORS configuré si nécessaire
|
|
- [ ] **Rate limiting** : Rate limiting respecté
|
|
|
|
#### ✅ Services externes
|
|
- [ ] **WebSocket server** : Serveur WebSocket accessible et fonctionnel
|
|
- [ ] **Database** : Base de données accessible et fonctionnelle
|
|
- [ ] **Redis** : Redis accessible si utilisé
|
|
- [ ] **Email service** : Service email fonctionnel si utilisé
|
|
|
|
### Phase 5: Validation des Tests Automatisés
|
|
|
|
#### ✅ Tests unitaires
|
|
- [ ] **Tests passent** : Tous les tests unitaires passent
|
|
- [ ] **Coverage ≥ 80%** : Couverture de code ≥ 80%
|
|
- [ ] **Tests pertinents** : Tests couvrent les cas critiques
|
|
|
|
#### ✅ Tests d'intégration
|
|
- [ ] **Tests API passent** : Tests d'intégration API passent
|
|
- [ ] **Tests E2E passent** : Tests end-to-end passent (si applicable)
|
|
|
|
### Phase 6: Documentation
|
|
|
|
#### ✅ Documentation code
|
|
- [ ] **Commentaires** : Commentaires pour logique complexe
|
|
- [ ] **JSDoc/GoDoc** : Documentation pour fonctions publiques
|
|
- [ ] **README** : README mis à jour si nécessaire
|
|
|
|
#### ✅ Documentation utilisateur
|
|
- [ ] **Documentation feature** : Feature documentée si nécessaire
|
|
- [ ] **Changelog** : Changelog mis à jour
|
|
|
|
### Phase 7: Validation Éthique (OBLIGATOIRE pour discovery, métriques, social)
|
|
|
|
Toute feature touchant la découverte, les métriques ou les interactions sociales **DOIT** passer cette checklist avant validation :
|
|
|
|
- [ ] **Pas de maximisation d'engagement** : La feature ne maximise pas l'engagement ou le temps passé sur la plateforme
|
|
- [ ] **Métriques au service du créateur** : Les métriques exposées servent le créateur, pas la plateforme
|
|
- [ ] **Aucun dark pattern** : Aucun dark pattern UX détecté
|
|
- [ ] **Algorithme explicable** : L'algorithme impliqué est documenté et explicable
|
|
- [ ] **Minimisation des données** : Aucune donnée comportementale n'est collectée sans nécessité justifiée
|
|
- [ ] **Accessibilité WCAG AA** : L'accessibilité WCAG AA est vérifiée
|
|
- [ ] **Résilience** : La feature fonctionne en conditions dégradées (faible connectivité, PWA)
|
|
|
|
> ⚠️ **Cette phase est bloquante** : aucune feature discovery/métriques/social ne peut être marquée "complétée" si un de ces critères échoue.
|
|
|
|
## 🔄 PROCESSUS DE VALIDATION
|
|
|
|
### Étape 1: Implémentation
|
|
1. Implémenter la feature (backend + frontend)
|
|
2. Écrire les tests automatisés
|
|
3. Vérifier que le code compile sans erreurs
|
|
|
|
### Étape 2: Validation Technique
|
|
1. Exécuter les tests automatisés
|
|
2. Vérifier la compilation (Go, TypeScript)
|
|
3. Vérifier les linters (golangci-lint, ESLint)
|
|
4. Vérifier la couverture de code
|
|
|
|
### Étape 3: Validation Fonctionnelle
|
|
1. **Démarrer tous les services** (backend, frontend, database, Redis, etc.)
|
|
2. **Ouvrir le navigateur** et naviguer vers la feature
|
|
3. **Tester le flux complet** :
|
|
- Happy path (cas normal)
|
|
- Edge cases (champs vides, valeurs limites)
|
|
- Error cases (erreurs API, timeout)
|
|
4. **Vérifier la console** : Aucune erreur
|
|
5. **Vérifier le réseau** : Requêtes réussies
|
|
6. **Vérifier l'UX** : Feedback utilisateur, loading states
|
|
|
|
### Étape 4: Validation des Intégrations
|
|
1. Vérifier que backend et frontend communiquent correctement
|
|
2. Vérifier que les services externes sont accessibles
|
|
3. Vérifier que les WebSockets fonctionnent (si applicable)
|
|
|
|
### Étape 5: Marquage "Complété"
|
|
1. **Toutes les cases de la checklist doivent être cochées**
|
|
2. **Aucune erreur console**
|
|
3. **Tous les tests passent**
|
|
4. **Feature fonctionnelle dans le navigateur**
|
|
5. **Documentation à jour**
|
|
|
|
## 📝 TEMPLATE DE VALIDATION
|
|
|
|
Pour chaque feature, créer un fichier de validation :
|
|
|
|
```markdown
|
|
# Validation: [Nom de la Feature]
|
|
|
|
## Informations
|
|
- **Tâche**: [ID de la tâche]
|
|
- **Date**: [Date]
|
|
- **Validateur**: [Nom]
|
|
|
|
## Checklist
|
|
|
|
### Phase 1: Backend
|
|
- [ ] Routes configurées
|
|
- [ ] Handlers implémentés
|
|
- [ ] Services implémentés
|
|
- [ ] Repositories implémentés
|
|
- [ ] Validation des données
|
|
- [ ] Gestion d'erreurs
|
|
- [ ] Tests unitaires (coverage ≥ 80%)
|
|
- [ ] Tests d'intégration
|
|
|
|
### Phase 2: Frontend
|
|
- [ ] Composants créés
|
|
- [ ] Props typées
|
|
- [ ] État géré
|
|
- [ ] Handlers d'événements
|
|
- [ ] Validation formulaire
|
|
- [ ] Gestion d'erreurs
|
|
- [ ] Loading states
|
|
- [ ] Accessibilité
|
|
|
|
### Phase 3: Test Manuel
|
|
- [ ] Feature accessible
|
|
- [ ] UI visible
|
|
- [ ] Interactions fonctionnelles
|
|
- [ ] Flux complet testé
|
|
- [ ] Edge cases testés
|
|
- [ ] Error cases testés
|
|
- [ ] Aucune erreur console
|
|
- [ ] Network requests réussies
|
|
|
|
### Phase 4: Intégrations
|
|
- [ ] Backend ↔ Frontend
|
|
- [ ] Services externes
|
|
|
|
### Phase 5: Tests Automatisés
|
|
- [ ] Tests unitaires passent
|
|
- [ ] Tests d'intégration passent
|
|
- [ ] Coverage ≥ 80%
|
|
|
|
### Phase 6: Documentation
|
|
- [ ] Commentaires code
|
|
- [ ] Documentation fonctions
|
|
- [ ] README mis à jour
|
|
|
|
## Résultat
|
|
- [ ] ✅ Feature 100% fonctionnelle
|
|
- [ ] ❌ Feature non fonctionnelle (détails ci-dessous)
|
|
|
|
## Notes
|
|
[Notes sur les problèmes rencontrés, solutions, etc.]
|
|
```
|
|
|
|
## 🚨 PROCÉDURE EN CAS D'ÉCHEC
|
|
|
|
Si une validation échoue :
|
|
|
|
1. **Ne PAS marquer la tâche comme "complétée"**
|
|
2. **Documenter le problème** dans le fichier de validation
|
|
3. **Corriger le problème** immédiatement
|
|
4. **Re-valider** en suivant la checklist complète
|
|
5. **Marquer comme "complétée"** uniquement après validation réussie
|
|
|
|
## 📊 MÉTRIQUES DE SUCCÈS
|
|
|
|
- **Taux de validation réussie** : 100% (toutes les features validées doivent être fonctionnelles)
|
|
- **Temps de debugging post-validation** : 0 (aucun bug découvert après validation)
|
|
- **Confiance dans le statut "complété"** : 100% (toutes les tâches "complétées" sont fonctionnelles)
|
|
|
|
### Métriques éthiques
|
|
|
|
- **Diversité dans la découverte** : Artistes émergents exposés proportionnellement aux artistes établis
|
|
- **Score d'accessibilité Lighthouse** : ≥ 95
|
|
- **Zéro dark pattern détecté** : Audit manuel trimestriel
|
|
|
|
## 🔄 AMÉLIORATION CONTINUE
|
|
|
|
- **Revue trimestrielle** : Analyser les échecs de validation et améliorer la checklist
|
|
- **Feedback équipe** : Collecter le feedback des développeurs sur le processus
|
|
- **Mise à jour** : Mettre à jour la checklist selon les leçons apprises
|
|
|
|
---
|
|
|
|
## 📜 HISTORIQUE DES VERSIONS
|
|
|
|
| Version | Date | Changements |
|
|
|---------|------------|-----------------------------------------------------------------------------|
|
|
| 1.0.0 | 2025-01-XX | Version initiale — stratégie de validation des features |
|
|
| 2.0.0 | 2026-03-04 | Ajout Phase 7 « Validation éthique » obligatoire, métriques éthiques ajoutées |
|
|
|