veza/docs/archive/root-md/report_qa_audit.md

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.