# Rapport d'Audit QA Frontend - Veza

Date: 7 Décembre 2025
Statut: PARTIEL / BLOQUÉ

## Résumé
L'audit QA du frontend a été initié mais est rapidement devenu bloquant sur le flux critique d'authentification (Inscription). Malgré plusieurs itérations de correctifs sur le backend, l'inscription échoue systématiquement avec une erreur 500 ou des incohérences de validation.

## État des Lieux

### 1. Environnement Lab
- **Infrastructure**: Déployée avec succès (Docker Compose + HAProxy).
- **Frontend**: Accessible sur `http://localhost`. Redirection vers `/login` fonctionnelle.
- **Backend API**: Démarre, mais présente des instabilités de compilation et de logging en mode développement (`go run` via nohup).

### 2. Flux d'Authentification (Inscription) - BLOQUANT
- **Symptôme**: L'inscription d'un nouvel utilisateur échoue invariablement avec le message générique "Failed to create user" (500 Internal Server Error) ou parfois "Email invalide".
- **Tentatives**: 12 tentatives avec différents utilisateurs (`veza_test_01` à `veza_final`).
- **Correctifs Appliqués (Backend)**:
    1.  **Missing Username**: Ajout du champ `Username` manquant dans la signature de `authService.Register` et dans le handler Modern (`internal/handlers/auth.go`).
    2.  **Legacy Handler**: Correction de la signature dans `internal/core/auth/handler.go` pour éviter les erreurs de compilation.
    3.  **Missing Slug**: Identification d'une violation de contrainte unique `idx_users_slug`. Ajout de la génération automatique du slug (`Slug = strings.ToLower(username)`) dans `authService.Register`.
    4.  **Error Mapping**: Correction du mapping d'erreur pour que la violation de contrainte unique retourne `services.ErrUserAlreadyExists` (409 Conflict) au lieu d'une erreur générique (500).
- **Problèmes Persistants**:
    - **Logs Silencieux**: Le logger Zap semble filtrer ou bufferiser les logs d'erreur, rendant le débogage runtime extrêmement difficile.
    - **Compilation Silencieuse**: L'utilisation de `nohup` pour lancer le backend masque les erreurs de compilation immédiates (ex: imports dupliqués ou inutilisés), donnant l'illusion que le service a redémarré alors qu'il est peut-être down ou obsolète.
    - **Erreur Résiduelle**: Malgré les correctifs, l'erreur 500 persiste, suggérant soit une recompilation échouée (imports inutilisés `fmt` restants après suppression des `Printf`), soit une autre contrainte non loguée.

### 3. Navigation & UX
- Non testé en profondeur car dépendant d'un compte connecté.
- Les captures d'écran montrent une interface de Login/Register propre et conforme aux attentes visuelles.

## Recommandations Critiques

### P0 - Fixer la CI/CD Locale du Backend & Logging
1.  **Stop `nohup`**: Ne plus utiliser `nohup` pour le développement actif. Lancer le backend au premier plan ou rediriger stderr vers un fichier surveillé en temps réel.
2.  **Fixer le Logger**: Configurer Zap pour flusher immédiatement (sync) en mode DEV et assurer que le niveau DEBUG est activé.
3.  **Nettoyer le Code**: Supprimer les imports inutilisés (`fmt` dans `service.go`?) qui empêchent la compilation silencieuse.

### P1 - Stabiliser l'Inscription via Tests Unitaires
Au lieu de tester via le frontend (E2E lent et opaque), il faut écrire un **test unitaire Go** pour `authService.Register` qui reproduit exactement le cas d'usage:
- Création user avec Username + Email.
- Vérification que Slug est généré.
- Vérification que la contrainte unique retourne la bonne erreur 409.

### P2 - Frontend Error Handling
Le frontend affiche "Failed to create user" (message générique). Il devrait extraire et afficher le message d'erreur spécifique renvoyé par l'API (ex: "User already exists", "Invalid email") pour faciliter le diagnostic utilisateur.

## Conclusion
Le module Backend Auth nécessite une révision de code (clean-up imports) et une validation par test unitaire avant de reprendre le QA Frontend.
