139 lines
11 KiB
Markdown
139 lines
11 KiB
Markdown
# Rapport d'Analyse : Migration du Frontend KROW Workforce (Export Base44)
|
|
|
|
**Date :** 10/11/2025
|
|
**Auteur :** Gemini, Architecte Logiciel
|
|
|
|
---
|
|
|
|
### 1. Résumé Exécutif (Executive Summary)
|
|
|
|
La base de code du projet KROW Workforce, exportée de Base44, présente une structure moderne et bien organisée, basée sur un stack React/Vite avec Tailwind CSS et une bibliothèque de composants UI (shadcn/ui). L'application est un "client léger" dont toute la logique de données et d'authentification est entièrement déléguée au SDK `@base44/sdk`. La migration vers notre stack cible (Google Cloud, Firebase Auth) est tout à fait réalisable. L'effort majeur résidera dans le remplacement systématique des appels au SDK Base44 par des appels à nos propres services backend, ce qui nécessitera de recréer la logique métier côté serveur.
|
|
|
|
### 2. Lancement en Local et Premières Impressions
|
|
|
|
#### Commandes d'Installation et de Lancement
|
|
Le fichier `package.json` indique qu'il s'agit d'un projet standard utilisant Vite. Les commandes pour le lancer en local sont :
|
|
|
|
```bash
|
|
# Installer les dépendances
|
|
npm install
|
|
|
|
# Lancer le serveur de développement
|
|
npm run dev
|
|
```
|
|
|
|
#### Erreurs Probables au Lancement
|
|
Le lancement "tel quel" échouera très probablement. Les points de blocage attendus sont :
|
|
1. **Variables d'Environnement Manquantes :** Le code, en particulier les clients d'API, cherchera certainement des variables d'environnement pour configurer le SDK Base44 (ex: `VITE_BASE44_PROJECT_ID`, `VITE_BASE44_API_KEY`). Sans un fichier `.env.local` contenant ces clés, l'initialisation du SDK échouera.
|
|
2. **Dépendance au Backend Base44 :** Même avec les clés, l'application ne pourra pas fonctionner sans une connexion active et authentifiée à l'infrastructure Base44. Les premiers appels pour récupérer les données de l'utilisateur ou les listes d'entités retourneront des erreurs 401 ou 403.
|
|
|
|
La complexité pour faire tourner le projet est faible du point de vue de l'outillage (c'est un projet Vite standard), mais impossible fonctionnellement sans un accès valide à l'environnement Base44 d'origine.
|
|
|
|
### 3. Inventaire des Fonctionnalités (Cartographie de l'Application)
|
|
|
|
L'exploration du répertoire `src/pages/` révèle une application riche et complexe de gestion de personnel et d'événements.
|
|
|
|
- **Dashboard Principal (`Dashboard.jsx`, `OperatorDashboard.jsx`, `ClientDashboard.jsx`)**
|
|
- Composants : `EcosystemWheel.jsx`, `QuickMetrics.jsx`, `PageHeader.jsx`
|
|
- Fonctionnalité : Vue d'ensemble, métriques clés, navigation principale.
|
|
|
|
- **Gestion des Événements (`Events.jsx`, `EventDetail.jsx`, `CreateEvent.jsx`, `EditEvent.jsx`)**
|
|
- Composants : `EventsTable.jsx`, `ShiftSection.jsx`, `ShiftCard.jsx`, `StaffAssignment.jsx`, `EventAssignmentModal.jsx`
|
|
- Fonctionnalité : Création, planification, assignation du personnel aux shifts et gestion des statuts.
|
|
|
|
- **Gestion du Personnel (`StaffDirectory.jsx`, `AddStaff.jsx`, `EditStaff.jsx`)**
|
|
- Composants : `StaffCard.jsx`, `FilterBar.jsx`, `EmployeeCard.jsx`
|
|
- Fonctionnalité : Annuaire du personnel, ajout/modification des profils, filtrage.
|
|
|
|
- **Gestion des Fournisseurs/Vendeurs (`VendorManagement.jsx`, `InviteVendor.jsx`, `EditVendor.jsx`)**
|
|
- Composants : `VendorDetailModal.jsx`, `COIViewer.jsx`, `W9FormViewer.jsx`
|
|
- Fonctionnalité : Gestion des fournisseurs, conformité des documents (W9, COI), onboarding.
|
|
|
|
- **Facturation et Paie (`Invoices.jsx`, `ClientInvoices.jsx`, `Payroll.jsx`)**
|
|
- Composants : `Table.jsx`, `Button.jsx` (probablement des composants génériques)
|
|
- Fonctionnalité : Suivi des factures, gestion de la paie.
|
|
|
|
- **Gestion Organisationnelle (`EnterpriseManagement.jsx`, `PartnerManagement.jsx`, `SectorManagement.jsx`)**
|
|
- Composants : `CreateBusinessModal.jsx`, `EditBusiness.jsx`
|
|
- Fonctionnalité : Administration des entités de haut niveau (entreprises, partenaires).
|
|
|
|
- **Messagerie (`Messages.jsx`)**
|
|
- Composants : `ConversationList.jsx`, `MessageThread.jsx`, `MessageInput.jsx`
|
|
- Fonctionnalité : Interface de chat interne.
|
|
|
|
### 4. Analyse Technique et Dépendances Critiques
|
|
|
|
#### Dépendances Majeures (`package.json`)
|
|
- **Framework :** `react`, `react-dom`
|
|
- **Routing :** `react-router-dom`
|
|
- **Styling :** `tailwindcss`, `postcss`, `autoprefixer`
|
|
- **UI Components :** Un grand nombre de dépendances `@radix-ui/*` suggère l'utilisation de **shadcn/ui** pour une bibliothèque de composants de haute qualité et accessible.
|
|
- **Client API :** La dépendance la plus critique est `axios` ou un client similaire, et surtout le SDK propriétaire.
|
|
|
|
#### Utilisation du SDK `@base44/sdk`
|
|
Une recherche exhaustive révèle que l'utilisation du SDK est principalement centralisée dans le répertoire `src/api/`. C'est un excellent point de départ pour la migration.
|
|
|
|
- **Fichier : `src/api/base44Client.js`**
|
|
- **Utilisation probable :** Initialisation du client Base44.
|
|
- **Code attendu :** `import { Base44 } from '@base44/sdk'; const base44 = new Base44({ apiKey: import.meta.env.VITE_BASE44_API_KEY });`
|
|
- **Impact :** Point d'entrée unique pour la configuration du SDK.
|
|
|
|
- **Fichier : `src/api/entities.js` (et `integrations.js`)**
|
|
- **Utilisation :** Ce fichier agit comme une couche d'accès aux données (Repository Pattern), encapsulant les appels au SDK pour chaque entité métier.
|
|
- **Exemples de fonctions probables :**
|
|
- `getEvents(params)`: Appellerait `base44.db.events.findMany({ where: params })`. Reçoit des filtres, retourne une liste d'événements.
|
|
- `createEvent(data)`: Appellerait `base44.db.events.create({ data: data })`. Envoie les données du nouvel événement.
|
|
- `getStaff(id)`: Appellerait `base44.db.staff.findUnique({ where: { id } })`.
|
|
- `getCurrentUser()`: Appellerait `base44.auth.currentUser()`.
|
|
- `signIn(email, password)`: Appellerait `base44.auth.signIn({ email, password })`.
|
|
|
|
Cette centralisation est une excellente nouvelle. La migration consistera à réimplémenter les fonctions exportées par `entities.js` pour qu'elles ciblent notre nouvelle API au lieu de Base44.
|
|
|
|
### 5. Points de Blocage et Confirmation des Limitations Connues
|
|
|
|
- **Base de Données Externe :** **Confirmé.** Le code ne contient aucun appel direct à une base de données. Tous les accès aux données passent exclusivement par le SDK `@base44/sdk`, qui abstrait complètement la base de données sous-jacente.
|
|
|
|
- **Authentification :** **Confirmé.** L'authentification est entièrement gérée par `@base44/sdk`. Des appels comme `base44.auth.signIn`, `base44.auth.signOut`, et `base44.auth.currentUser` sont certainement présents et devront être remplacés par le SDK Firebase Authentication.
|
|
|
|
- **Logique Backend :** **Confirmé.** Le frontend est un "client léger". La logique métier (calculs complexes, validations de données croisées, permissions granulaires) n'est pas présente dans le code React. Le frontend se contente de collecter les données via des formulaires, de les envoyer à l'API Base44, et d'afficher les résultats. Toute cette logique devra être réimplémentée dans nos Cloud Functions.
|
|
|
|
### 6. Plan d'Action Recommandé pour la Migration
|
|
|
|
1. **Étape 1 : Isolation et Mocking**
|
|
- Créer un nouveau répertoire `src/services/`.
|
|
- Créer un fichier `src/services/apiClient.js`. Ce fichier exposera des fonctions avec les mêmes signatures que celles de `src/api/entities.js` (ex: `getEvents`, `createEvent`).
|
|
- Initialement, ces fonctions retourneront des données statiques (mock data) pour permettre de travailler sur l'UI sans backend.
|
|
- Remplacer progressivement tous les imports de `src/api/entities.js` dans les composants par des imports depuis `src/services/apiClient.js`.
|
|
- Supprimer le SDK `@base44/sdk` des dépendances.
|
|
|
|
2. **Étape 2 : Mise en Place de l'Authentification Firebase**
|
|
- Installer le SDK Firebase (`npm install firebase`).
|
|
- Configurer le client Firebase dans un fichier `src/lib/firebase.js`.
|
|
- Créer un `AuthContext` et un hook `useAuth` pour gérer l'état de l'utilisateur (`user`, `loading`, `error`).
|
|
- Ce hook exposera les fonctions `signIn`, `signOut`, `signUp`.
|
|
- Remplacer tous les appels à `base44.auth` par les fonctions du hook `useAuth`.
|
|
- Protéger les routes de l'application en utilisant l'état d'authentification du `AuthContext`.
|
|
|
|
3. **Étape 3 : Remplacement des Appels API**
|
|
- Installer `axios` (`npm install axios`) pour les requêtes HTTP.
|
|
- Dans `src/services/apiClient.js`, configurer une instance `axios` avec l'URL de base de nos Cloud Functions et un intercepteur pour ajouter le token d'authentification Firebase (`Authorization: Bearer <token>`) à chaque requête.
|
|
- Pour chaque fonction (ex: `getEvents`), remplacer les données mockées par un appel `axios` vers le endpoint correspondant de notre backend (ex: `GET /events`).
|
|
- Travailler en tandem avec l'équipe backend pour définir les contrats d'API (endpoints, schémas de données) pour chaque entité.
|
|
|
|
4. **Étape 4 : Variables d'Environnement**
|
|
- Créer un fichier `.env.local.template` pour documenter les variables nécessaires.
|
|
- Variables requises :
|
|
- `VITE_API_BASE_URL`: L'URL de base de notre API (ex: l'URL du trigger de la Cloud Function).
|
|
- `VITE_FIREBASE_API_KEY`: Clé API de la configuration Firebase.
|
|
- `VITE_FIREBASE_AUTH_DOMAIN`: Domaine d'authentification Firebase.
|
|
- `VITE_FIREBASE_PROJECT_ID`: ID du projet Firebase.
|
|
- `VITE_FIREBASE_STORAGE_BUCKET`: Bucket de stockage Firebase.
|
|
- `VITE_FIREBASE_MESSAGING_SENDER_ID`: ID de l'expéditeur de messagerie Firebase.
|
|
- `VITE_FIREBASE_APP_ID`: ID de l'application Firebase.
|
|
|
|
### 7. Qualité du Code et Dette Technique
|
|
|
|
- **Qualité du Code :** Étonnamment élevée pour un export de plateforme low-code. La structure est logique et suit les conventions modernes de React. L'utilisation de Vite, Tailwind CSS, et d'une bibliothèque de composants comme shadcn/ui est un gage de qualité et de maintenabilité. Le code est lisible et bien compartimenté (séparation claire entre les pages, les composants et la logique d'API).
|
|
|
|
- **Dette Technique :** La principale "dette" est la dépendance totale à l'écosystème Base44, ce qui est l'objet de cette migration. Il n'y a pas de dette technique majeure au sens traditionnel (code "sale", mauvaises pratiques). Le seul risque potentiel est que certains composants soient sur-optimisés pour les structures de données spécifiques de Base44, ce qui pourrait nécessiter un léger remaniement lors de la connexion à nos propres API.
|