front-end devs
Développeurs front-end responsables de l'interface utilisateur et de l'expérience utilisateur de nos applications
- Domains
- 1
- Services
- 5
- Messages
- 8
- Members
- 1
Vue d’ensemble
L’équipe front-end est responsable de l’application web Clairtyx, une SPA (Single Page Application) construite avec React 19, TypeScript 5, Vite 7 et TailwindCSS v4. Le routage est assuré par react-router-dom v7, et la bibliothèque de composants UI repose sur shadcn/ui + Radix UI. L’ensemble des pages authentifiées est encapsulé dans un layout principal (AppLayout) intégrant une sidebar collapsible et un système de fil d’Ariane dynamique.
Stack technique
| Catégorie | Librairie | Version |
|---|---|---|
| Framework | React | 19.2 |
| Build | Vite | 7.3 |
| Langage | TypeScript | 5.9 |
| Routage | react-router-dom | 7.13 |
| Styles | TailwindCSS v4 | 4.2 |
| UI / primitives | shadcn/ui + Radix UI | — |
| Graphiques | Recharts | 3.8 |
| Notifications | Sonner | 2.0 |
| Thème | next-themes | 0.4 |
| Icônes | lucide-react | 1.6 |
| Saisie téléphone | react-phone-number-input | 3.4 |
Travaux à réaliser
1. Connexion des données mockées aux APIs réelles
La majorité des pages CRM et de gestion d’équipe utilisent encore des données entièrement fictives (fichiers _data.tsx, constantes MOCK_*). L’équipe doit les remplacer par des appels API réels :
| Page / Module | Données actuellement mockées | API cible attendue |
|---|---|---|
Home.tsx (dashboard) | Un an de données revenus/dépenses générées localement | Endpoint analytics/metrics |
settings/teams.tsx | INITIAL_MEMBERS, INITIAL_INVITATIONS, actions simulées via setTimeout | GET/POST/PUT /team/v1/... |
settings/team-member.tsx | MOCK_MEMBERS, MOCK_ACTIVITY, MOCK_SESSIONS entièrement faux | Endpoints user + session |
account/company/company.tsx | COMPANY, TEAMS, MEMBERS hardcodés | Endpoint organisation |
account/subscription/ | Plans tarifaires mockés, aucun appel billing | API facturation (Stripe ou équivalent) |
CRM — ProspectsPage | DETAILS_MOCK dans _data.tsx | GET /crm/v1/prospects |
CRM — ContactsPage | CONTACTS_MOCK dans _data.tsx | GET /crm/v1/contacts |
CRM — CampagnesPage | CAMPAGNES_MOCK dans _data.tsx | GET /crm/v1/campagnes |
CRM — RapportsPage | Données dérivées des mocks CRM | Endpoint rapports/statistiques |
2. Création des pages manquantes
Plusieurs entrées de la sidebar pointent vers "#" — ces pages n’existent pas encore et doivent être créées :
- Documentation : Introduction, Démarrage rapide, Tutoriels, Changelog
- Paramètres : Général, Facturation, Limites
- Support
3. Nettoyage de la sidebar
Les libellés de navigation contiennent des marqueurs de statut de développement visibles en production ("home OK", "Rapports ~OK~", etc.). Ces annotations doivent être supprimées du fichier app-sidebar.tsx.
4. Complétion du module Compte (/home/account)
- Renseigner les variables d’environnement vides
VITE_VITRINE_CHANGE_PASSWORD,VITE_VITRINE_OTP,VITE_VITRINE_POPet les brancher sur les liens documentation correspondants dansAccount.tsx. - Finaliser l’onglet Préférences (langue, notifications, thème) avec persistence API.
- Vérifier le flux OTP/POP (
POST /security/v1/otp,POST /security/v1/pop) de bout en bout.
5. Consolidation des hooks dupliqués
useTeamRoles et useTeamPermissions appellent les mêmes endpoints que useRoles / usePermissions mais retournent des structures différentes. Ces hooks doivent être fusionnés ou factorisés pour éviter la désynchronisation des données.
6. Correction du typo de routage
Le fichier routes/AppRooter.tsx contient une faute de frappe dans son nom (Rooter au lieu de Router). Renommer le fichier et mettre à jour tous les imports.
7. Réactivation de la Suspense dans App.tsx
Le wrapper <Suspense> est commenté dans App.tsx. Le rétablir avec un fallback de chargement adapté (skeleton ou spinner) pour améliorer l’expérience perçue lors du lazy loading des routes.
8. Gestion centralisée des appels API
Actuellement les appels fetch() sont dispersés directement dans les composants et formulaires (LoginForm, SignupForm, Account, NavUser, etc.). L’équipe doit introduire une couche de service ou un client HTTP centralisé (ex. un module lib/api.ts) pour :
- Centraliser la gestion du token CSRF
- Uniformiser le traitement des erreurs
- Faciliter les tests et la maintenance
9. Module CRM — pages détail
Les pages de détail CRM (ProspectDetailPage, ContactDetailPage, NoteDetailPage, TacheDetailPage, CampagneDetailPage) sont actuellement affichées depuis des données mock statiques. Elles doivent être connectées aux endpoints REST correspondants et intégrer des formulaires de création/édition fonctionnels.
Ce qui fonctionne déjà
| Module | État |
|---|---|
| Authentification (login/register) | ✅ Opérationnel |
Guard de session (/session/v1/check) | ✅ Opérationnel |
Profil utilisateur (/user/v1/me) | ✅ Opérationnel |
| Gestion des rôles et permissions | ✅ Opérationnel |
| Feedback (WebSocket + REST) | ✅ Opérationnel |
| Déconnexion | ✅ Opérationnel |
| Changement de mot de passe | ✅ Opérationnel |