TheHandyMan : une marketplace de services à domicile au Maroc

TheHandyMan est la marketplace de services à domicile pour le Maroc conçue par ShipFastDev : le client parcourt des prestations (plomberie, électricité, ménage, jardinage…), compare les prix en dirhams (MAD) et réserve un créneau auprès d'un artisan. Les écrans client et prestataire sont construits et le backend gère déjà les comptes et l'authentification ; la prochaine étape consiste à relier les deux. La plateforme n'est pas publique ; une démonstration est possible lors d'un appel.

Ce que le client peut faire

• Chercher par métier. La page d'accueil présente les catégories les plus demandées (plomberie, électricité, ménage, peinture, jardinage, menuiserie, réparation d'électroménager, déménagement) et la page des services se filtre par catégorie.
• Comparer les offres. Chaque fiche affiche le prix en MAD (à la séance ou au forfait), la durée habituelle et la note, par exemple pour un ménage régulier ou un grand nettoyage.
• Réserver un créneau. Le client choisit une date et un créneau horaire disponible, saisit l'adresse d'intervention et vérifie un récapitulatif : prix, durée, horaire prévu et prestataire.
• Gérer son compte. Inscription, connexion, réinitialisation du mot de passe par e-mail, et suivi des réservations et des moyens de paiement depuis un tableau de bord.

Ce que reçoit le prestataire

L'espace prestataire a d'abord été décrit dans un court cahier des charges produit, autour de trois fonctions :

• Un profil public : informations sur l'entreprise, zones d'intervention, certifications (avec envoi de justificatifs) et galerie photo des réalisations.
• « Mes services » pour ajouter, modifier, suspendre ou supprimer une prestation. Chaque service a une catégorie, une description, une durée, des photos, un statut (actif, en pause ou brouillon) et un mode de tarification : prix fixe, tarif horaire, fourchette de prix ou sur devis.
• Les disponibilités : un planning hebdomadaire par créneaux, des exceptions pour les congés ou les heures bloquées, et un temps tampon entre deux interventions.

Le prestataire dispose aussi d'un tableau de bord avec indicateurs, activité et avis clients.

Ce qui a été construit

• Frontend. Next.js 14 avec l'App Router, TypeScript et Tailwind CSS ; React Query pour les données, Zustand pour l'état, React Hook Form et Zod pour la validation des formulaires, et FullCalendar pour les plannings. i18next est en place pour les versions arabe, française et anglaise prévues.
• L'interface d'abord, sur des données fictives. Les pages appellent des hooks, les hooks appellent une couche de services, et cette couche renvoie pour l'instant des données fictives. Le jour où l'API est prête, seule la couche de services change ; les pages restent identiques.
• Backend. NestJS en TypeScript, avec PostgreSQL via TypeORM. Il fournit l'inscription, la connexion et le profil avec authentification JWT et routes protégées, la réinitialisation du mot de passe par e-mail, un modèle de données prestataire, une documentation d'API Swagger, la journalisation des requêtes, un filtre d'erreurs global et des points de contrôle de santé et de métriques.
• Architecture cible. Le README du dépôt prévoit des services distincts pour les utilisateurs, les réservations, les paiements, la messagerie, les avis et l'administration, avec un back-office pour vérifier les prestataires.

Comment la fiabilité est assurée

• Une réinitialisation de mot de passe soignée. Les jetons sont aléatoires, longs de 64 caractères, expirent au bout de 30 minutes et ne servent qu'une fois. Le point d'accès « mot de passe oublié » renvoie le même message que l'adresse existe ou non, ce qui empêche de deviner les comptes, et les nouveaux mots de passe doivent respecter des règles de complexité.
• Données de compte. Les mots de passe sont hachés, jamais renvoyés dans les réponses, et les données reçues sont validées par des règles typées.
• Le schéma évolue par migrations. En production, la base ne change que par des migrations TypeORM exécutées au déploiement ; le script de synchronisation rapide est réservé au développement. La documentation de TypeORM le dit elle-même : synchroniser automatiquement le schéma n'est pas sûr en production dès que la base contient des données.
• Tests. Tests unitaires Jest du service d'authentification, tests de bout en bout du parcours inscription, connexion et profil, et Jest avec Testing Library côté frontend.
• Des environnements reproductibles. Docker Compose en local (avec pgAdmin pour la base), Dockerfiles de production, Nginx en HTTPS devant l'API et déploiement sur Fly.io via un workflow GitHub Actions.

Dernières versions

Le dépôt compte 17 commits entre le 20 mars et le 24 mai 2025.

• 24 mai 2025 : fonctions prestataire (profil, services, disponibilités) avec leurs hooks et données fictives, tableaux de bord prestataire, avis et moyens de paiement, et messages d'erreur plus clairs sur les formulaires de connexion.
• 2 mai 2025 : tableaux de bord client et prestataire avec indicateurs et activité, gestion des réservations et avis sur les services.
• 27 avril 2025 : images des services avec composant de repli et préchargement, et hooks de données pour les réservations et les services.
• 6 avril 2025 : migrations de base de données, modèle prestataire, journalisation des requêtes, points de santé et de métriques, et documentation de l'authentification.

La suite

Le cahier des charges prestataire fixe l'étape suivante : brancher les écrans prestataire sur la vraie API, puis le parcours de réservation qui tient compte des plannings. Pour cadrer une marketplace comparable, voir Comment cadrer un MVP et Combien coûte un MVP ; l'étude de cas Driveway Morocco présente un produit de réservation déjà en ligne. D'autres projets figurent dans le portfolio.

Questions fréquentes

TheHandyMan est-il en ligne ?

Non. La plateforme n'est pas publique et les écrans fonctionnent pour l'instant sur des données fictives. Une démonstration est possible lors d'un appel.

Comment les prix sont-ils fixés et affichés ?

Les prix sont affichés en dirhams (MAD). Chaque prestataire choisit son mode de tarification par service : prix fixe, tarif horaire, fourchette de prix ou devis.

Comment un artisan contrôle-t-il ses disponibilités ?

Il définit un planning hebdomadaire par créneaux, bloque des dates ou des heures précises et ajoute un temps tampon entre deux interventions. Le client choisit ensuite une date et l'un des créneaux libres.

Pourquoi construire les écrans avant d'avoir terminé le backend ?

Le cahier des charges a retenu une approche « interface d'abord » avec une couche de données fictives : les parcours client et prestataire ont pu être construits et validés sans attendre chaque API. Au branchement du backend, seule la couche de services change.

Sources

1. Documentation NestJS, NestJS, consulté en octobre 2026
2. Documentation Next.js, Vercel, consulté en octobre 2026
3. How migrations work?, TypeORM, consulté en octobre 2026
4. Continuous deployment with Fly.io and GitHub Actions, Fly.io, consulté en octobre 2026
5. Documentation FullCalendar, FullCalendar, consulté en octobre 2026