Retours client : état d’implémentation frontend
Synthèse des fonctionnalités intégrées dans l’administration, des éléments déjà présents et des dépendances qui nécessitent encore une évolution du backend.
Implémenté maintenant
Les données déjà exposées sont désormais visibles et lisibles
Le travail a porté sur les retours client que le backend sait réellement servir, avec des libellés explicites et des états vides ou d’erreur utilisables.
Uniquement le frontend et ses routes d’interface. Aucun code backend n’a été changé.
Tableau de bord
Les files prioritaires sont lisibles immédiatement, sans tableau horizontal.
- Libellés corrigés : Pros inscrits et Clients inscrits.
- Dossiers Pro avec documents, ancienneté et accès direct au contrôle.
- Clients avec contact, état du compte, vérifications et date d’inscription.
Liste des professionnels
Les alertes sont traitées avant la liste complète, qui tient en cinq colonnes utiles.
- Compte actif, bloqué ou supprimé séparé du statut de vérification.
- Alertes : espèces, inactivité, non-vérifié, refus, expiration, annulation.
- Profil, service, missions, état et actions ; cartes compactes sur mobile.
Vérification KYC
La file se lit comme une liste de travail, du dossier le plus ancien au plus récent.
- Pagination par lots de 20 dossiers.
- État d’erreur clair si la file ne charge pas.
- Nombre de documents, ancienneté et accès direct ; absence de document explicitée.
Revenus d’un professionnel
Le suivi hebdomadaire est hiérarchique : décision d’abord, contrôle détaillé ensuite.
- Plateforme, espèces, position et action visibles sans défilement latéral.
- Détail dépliable par mission : client, paiement, HT, TVA, commission et net Pro.
- Confirmation de virement avec montant recalculé par le serveur.
Détail d’une mission
La page regroupe maintenant la prestation, le paiement et le calcul du prix.
- Groupes et options de service sélectionnés.
- HT, TVA, taxes, remise, supplément, TTC, commission et reversement Pro.
- Paiement, facture disponible, photo, destination et commentaire client.
- Horaires précis et délai avant démarrage correctement nommé.
Comptabilité
La page suit désormais l’ordre réel de travail : soldes, transactions, puis analyse.
- Soldes Pro dépliables et action de versement directe.
- Transactions en cinq informations essentielles, sans double rendu mobile.
- Remboursement confirmé ; analyse avancée repliée à la demande.
Catalogue de services
La vue par défaut ne montre que ce qui sert à décider et agir.
- Service, commission, statut et actions visibles par défaut.
- TVA, durée et suppléments restent disponibles via le sélecteur de colonnes.
- Recherche, filtres et cartes mobiles intégrés à la table TanStack existante.
Focus clavier renforcé, vrais boutons de pagination, lignes de tableau sans faux rôle interactif, en-têtes de colonnes correctement annoncés, états de chargement et messages vides exposés aux technologies d’assistance.
Preuves visuelles
Captures des pages modifiées
Captures reprises sur le build de production local, connecté au backend réel. Elles ne contiennent ni données simulées ni overlay de développement.
Comparatif visuel
Avant / après sur les parcours concernés
Les images « avant » proviennent de l’audit initial. Les images « après » ont été reprises dans le navigateur sur le frontend local connecté au backend réel mis à jour.
Tableau de bord
Revenus du professionnel
Détail des revenus
Détail de mission
Comptabilité
Déjà présent
Fonctionnalités retrouvées dans le frontend avant cette livraison
Ces éléments du retour client n’ont pas été recréés : ils étaient déjà câblés et restent disponibles dans la configuration des services.
| Retour client | État | Constat |
|---|---|---|
| Groupes, prestations et options | Présent | Le catalogue permet déjà de structurer les services en groupes et éléments. |
| Activation des éléments | Présent | Les éléments du catalogue disposent déjà d’états actif ou inactif. |
| Choix d’icônes | Présent | Un sélecteur d’icônes est disponible à la création et à l’édition. |
| Historique et paiements de base | Présent | Les listes de missions et transactions existaient ; leurs détails ont été enrichis. |
À prévoir
Ce qui manque encore, classé par responsable
La refonte n’invente pas de données. Les points ci-dessous nécessitent soit un contrat backend fiable, soit une dernière interface frontend une fois ce contrat disponible.
| Besoin | Blocage | Suite recommandée |
|---|---|---|
| Présence et activité des administrateurs | Backend défaillant | Les lectures existent partiellement, mais les connexions sont écrites dans un autre journal et les durées additionnent des comptes. Unifier les événements, clôturer les sessions et produire les agrégats jour/semaine. |
| Traitement des documents par admin | Backend incomplet | Stabiliser le schéma des documents Admin puis historiser qui a contrôlé quel document, quand et avec quelle décision. |
| Affectation des nouveaux comptes | Backend manquant | Ajouter une affectation Admin ↔ Pro/Client et les permissions associées. |
| Vrais KPI « nouveaux ce mois » | Filtre manquant | Fournir des agrégats datés ou un filtre serveur avant de réutiliser ce libellé. |
| Historique des connexions Pro | Backend partiel + UI absente | Les routes existent, mais pas les agrégats matin/après-midi ni les missions par session. Compléter le contrat puis créer la timeline frontend. |
| Adresse dans le solde hebdomadaire Pro | Backend manquant | Ajouter l’adresse au payload de solde ; elle n’est pas disponible dans l’endpoint financier actuel. |
| Alertes métier avancées | Backend manquant ou incomplet | Ajouter les taux et événements pour supplément, pause, commentaire négatif, démarrage avant arrivée, note, dette et pagination complète des alertes. |
| Marques et types de produits | Contrat à confirmer + UI absente | Confirmer les champs réellement exposés par l’API publique, puis ajouter leur administration dans le catalogue frontend. |
| Règles commentaire, photo et seconde adresse par service | Configuration absente | Exposer ces drapeaux par service et les appliquer lors de la commande. |
| Totaux HT, TVA et commission exacts par service | Agrégats incomplets | Fournir les agrégats comptables serveur ; le frontend ne doit pas sommer seulement la page chargée. |
| Résumé global des soldes | Backend manquant | Retourner les agrégats toutes pages confondues. En attendant, l’interface indique explicitement « sur cette page ». |
| Nombre de missions par service | Jointure fragile | Remplacer la jointure par nom traduit par un service_id stable ou un compteur calculé côté backend. |
| Cohérence période ↔ missions des soldes | Données backend incohérentes | Le solde du 13–19 avril contient actuellement des missions datées de mars, mai et juin. Corriger la source ou la règle d’agrégation. |
| Facture téléchargeable et historique immuable | Backend puis frontend | Prévoir un téléchargement sécurisé et un snapshot des options au moment de la mission, puis exposer l’action dans l’interface. |
Backend et accès
Le backend local et l’envoi d’e-mail sont opérationnels
Le dépôt backend a été positionné sur la dernière branche distante d’Achille/Hashi, sans modification de son code, puis l’ensemble Docker a été relancé.
feat/impl-mobile · commit c92763e.GET /health répond 200 avec MongoDB connecté.POST /api/v2/auth/admin/login répond 200.
admin.itchek.fr affiche encore l’ancien dashboard Angular.
GET /api/v2/health reste en 503 quand Stripe dépasse son délai de
réponse. Le serveur, MongoDB et le parcours de connexion local fonctionnent ;
cette dépendance externe doit être surveillée séparément.
Qualité
Vérifications réalisées
La livraison a été testée contre l’environnement local réel. Les limites de la suite globale sont documentées séparément des changements de cette livraison.
32 scénarios ont passé avant quatre échecs sur le catalogue de services : sélecteurs de tests devenus obsolètes ou ambigus. Après de nombreux appels, l’environnement local a également déclenché sa limite API 429. Ces points ne proviennent pas des écrans livrés ici.