# Plan de Migration vers la Nouvelle API d'Authentification (Backend V2)

## 1. Contexte et Objectif

Ce document décrit le plan d'action pour migrer le frontend Next.js afin qu'il utilise la nouvelle API d'authentification du backend refactorisé (`/backend`), en remplacement de l'ancienne implémentation (`/amifond/apps/authentication`).

L'objectif est d'adopter la nouvelle architecture backend, qui offre une gestion des utilisateurs plus riche, une sécurité renforcée et des endpoints plus structurés, tout en minimisant l'impact sur l'expérience utilisateur.

## 2. Analyse des Changements Majeurs

La nouvelle API d'authentification (`/backend/apps/authentication`) introduit plusieurs changements par rapport à l'ancienne :

1.  **Modèle `User` enrichi** : Le nouveau modèle `User` contient des champs spécifiques au métier (`user_type`, `additional_roles`, `employee_id`, etc.) et une logique de sécurité avancée (verrouillage de compte).
2.  **Endpoints API personnalisés** : L'ancienne implémentation reposait principalement sur les endpoints par défaut de `dj-rest-auth`. La nouvelle utilise des `ViewSet` et des vues personnalisées (`CustomLoginView`, `UserViewSet`, etc.) qui offrent plus de contrôle.
3.  **Structure de réponse JWT** : La réponse de l'endpoint de connexion (`/api/v1/auth/token/`) inclut désormais l'objet `user` complet, ce qui simplifie la récupération des données au login.
4.  **Gestion des erreurs** : Les messages d'erreur sont plus structurés et spécifiques.
5.  **Séparation des responsabilités** : Le nouveau backend sépare mieux la logique d'authentification (`authentication` app) de la logique des profils (`users` app), ce qui est une meilleure pratique.

## 3. Plan d'Action Détaillé

La migration se déroulera en plusieurs étapes pour assurer une transition en douceur.

### Étape 1 : Configuration et Variables d'Environnement

-   [ ] **Mettre à jour l'URL de l'API** :
    -   Dans le fichier `.env.local` (et `.env.example`), s'assurer que `NEXT_PUBLIC_API_URL` pointe vers le serveur du nouveau backend (par exemple, `http://localhost:8000`).

-   [ ] **Mettre à jour la configuration des endpoints** :
    -   Dans `src/lib/api-config.ts`, vérifier que les chemins des endpoints correspondent à la nouvelle structure d'URL définie dans `/backend/apps/authentication/api/urls.py`.
    -   **Action** : Remplacer `login: "/auth/login/"` par `login: "/auth/token/"` pour utiliser la nouvelle vue `CustomTokenObtainPairView` qui retourne l'objet `user`.
    -   **Action** : Vérifier que les endpoints `register`, `logout`, `token/refresh` et `user` sont corrects.

### Étape 2 : Mise à jour du Store d'Authentification (Zustand)

Le fichier `src/stores/auth/auth-store.ts` est au cœur de la logique.

-   [ ] **Adapter la fonction `login`** :
    -   La nouvelle API (`CustomTokenObtainPairView`) retourne un objet `{ access, refresh, user }`.
    -   **Action** : Modifier la fonction `login` pour qu'elle utilise directement l'objet `user` retourné dans la réponse, au lieu de faire un appel séparé pour récupérer les détails de l'utilisateur.
    -   **Action** : L'endpoint à appeler est maintenant `/api/v1/auth/token/` (ou celui configuré pour `CustomTokenObtainPairView`).

-   [ ] **Adapter la fonction `register`** :
    -   Le nouveau `CustomRegisterSerializer` attend des champs supplémentaires (`first_name`, `last_name`, `phone_number`).
    -   **Action** : S'assurer que le formulaire d'inscription et le type `RegisterRequest` incluent ces champs et les envoient à l'API.

-   [ ] **Mettre à jour les types TypeScript** :
    -   Le type `User` dans `src/types/auth.ts` doit être mis à jour pour correspondre au `UserSerializer` du nouveau backend.
    -   **Action** : Ajouter les nouveaux champs comme `user_type`, `user_type_display`, `permissions_level`, `profile`, `additional_roles`, etc.

-   [ ] **Adapter la gestion des erreurs** :
    -   La fonction `transformError` est déjà bien conçue pour gérer les erreurs de validation de Django.
    -   **Action** : Tester intensivement les scénarios d'erreur (ex: email déjà utilisé, mot de passe invalide) pour s'assurer que les messages du nouveau backend sont correctement mappés.

### Étape 3 : Mise à jour des Composants et Hooks

-   [ ] **Mettre à jour les formulaires (`react-hook-form`)** :
    -   **Action** : Vérifier que les formulaires de connexion et d'inscription (`src/app/(auth)/auth/...`) utilisent les bons noms de champs (`email` pour le login, etc.).
    -   **Action** : Le formulaire d'inscription doit inclure les nouveaux champs obligatoires (`first_name`, `last_name`, `phone_number`).

-   [ ] **Mettre à jour l'affichage des informations utilisateur** :
    -   Les composants qui affichent des informations sur l'utilisateur (ex: `UserProfile` dans la barre de navigation) doivent utiliser les nouveaux champs disponibles dans `store.user`.
    -   **Action** : Remplacer les anciens champs par les nouveaux si nécessaire (ex: utiliser `user.full_name`).

-   [ ] **Adapter la logique de permissions (`usePermissions`)** :
    -   Le hook `usePermissions` dans `auth-store.ts` se base sur `user.user_type`.
    -   **Action** : Mettre à jour la logique pour qu'elle corresponde aux nouveaux `UserType` définis dans `/backend/apps/authentication/models.py` (ex: `super_admin`, `ca_member`, `manager`, `client`).

### Étape 4 : Tests et Validation

Il est crucial de tester l'ensemble du flux d'authentification de bout en bout.

-   [ ] **Tests du flux d'inscription** :
    -   Créer un nouveau compte.
    -   Tester les validations de champs (email invalide, téléphone déjà pris, mot de passe faible).
    -   Vérifier que les erreurs du backend s'affichent correctement sur les bons champs du formulaire.

-   [ ] **Tests du flux de connexion/déconnexion** :
    -   Se connecter avec un utilisateur valide.
    -   Vérifier que l'état (store, cookies) est correctement mis à jour et que l'utilisateur est redirigé.
    -   Tester la connexion avec des identifiants invalides et vérifier le message d'erreur.
    -   Tester le verrouillage de compte après plusieurs tentatives échouées.
    -   Se déconnecter et vérifier que l'état est complètement réinitialisé.

-   [ ] **Tests de persistance de session** :
    -   Se connecter, recharger la page et vérifier que l'utilisateur reste connecté.

-   [ ] **Tests des routes protégées** :
    -   Tenter d'accéder à une route protégée sans être connecté et vérifier la redirection.
    -   Se connecter avec un utilisateur n'ayant pas les permissions suffisantes et vérifier l'accès.

## 4. Risques Potentiels et Solutions

-   **Risque** : Incompatibilité des formats de données entre l'ancien et le nouveau backend.
    -   **Solution** : Mettre à jour rigoureusement les types TypeScript (`src/types/auth.ts`) en se basant sur les `serializers.py` du nouveau backend. Utiliser les DevTools pour inspecter les réponses de l'API.

-   **Risque** : Problèmes de CORS ou de CSRF avec le nouveau backend.
    -   **Solution** : S'assurer que la configuration (`settings.py`) du nouveau backend autorise bien l'origine du frontend (`http://localhost:3004` en développement).

-   **Risque** : Régression sur la gestion des erreurs.
    -   **Solution** : Tester chaque cas d'erreur manuellement (validation, authentification, serveur) pour garantir que l'UX reste cohérente.

## 5. Conclusion

Cette migration est une étape structurante qui alignera le frontend sur une base backend plus solide et évolutive. En suivant ce plan de manière méthodique, la transition devrait se faire de manière contrôlée, en améliorant la robustesse et les fonctionnalités de l'application.