Aller au contenu
jad-Elevator-web

Étude de cas · projet client

Jad Elevateur

Conçu pour une entreprise d’installation et de maintenance d’ascenseurs au Maroc : un seul back-office pour les chantiers, le stock, la facturation, la caisse, le pointage et la paie.

Rôle
Seul ingénieur, du cahier des charges à la production
Année
2026

Le défi

Une entreprise d’ascenseurs voulait toute son activité dans un seul back-office, selon les règles légales marocaines, avec les marges cachées à quiconque n’y est pas autorisé.

En chiffres

  1. 9 daysDu 17 au 25 juillet 2026 : tous les modules métier en place, 534 des 605 commits du projet.
  2. 186Routes d’API, chacune nommant les rôles et le scope autorisés à l’appeler.
  3. 13Règles métier, numérotées de P1 à P13 et citées dans le code là où elles s’appliquent.
  4. 3Langues : le français d’abord, puis l’anglais et l’arabe, de droite à gauche.

Ce qu’il fait

Une boucle, du contrat à la caisse

Un client signe un contrat de chantier ou passe une commande. Les produits sortent du stock, un devis devient une facture ou un bon de livraison avec son numéro légal, et les paiements arrivent en espèces, par chèque ou par virement avant d’entrer en caisse.

Les achats passent par des demandes aux fournisseurs, qui réapprovisionnent le stock à la réception. Côté équipe : le pointage quotidien, les congés sur un quota annuel de 18 jours, les déplacements vers d’autres villes à un taux journalier, et une fiche de salaire mensuelle pour chaque membre.

Chaque modification est écrite dans un journal en ajout seul, et le tableau de bord dépend du rôle : l’opérationnel pour tous, la finance seulement pour ceux qui y ont droit.

La boucle d’exploitation

Comment un chantier devient de la trésorerie

Un chantier, de la signature à la caisse, et l’achat qui remplit à nouveau le stock utilisé. Chaque flèche est un flux que l’API implémente.

Clientcompany or person · ICEChantiercontract · lines · chargesStockledger · alertsDevis → FactureFAC-2026-0007Paymentcash · cheque · transferCaisseappend-only ledgerFournisseurdemandesignstakes productsquote, then invoicepaid in partslands inlow stock: demandereceived: restock

L’argent

L’argent n’est jamais un décimal, ni jamais modifié

Chaque montant est un nombre entier de centimes et chaque taux de TVA est en points de base : 2000 vaut 20 %. Les compteurs, comme le montant payé ou le solde d’une caisse, ne bougent que par incréments atomiques, jamais par affectation.

Le grand livre de la caisse est en ajout seul. Chaque ligne porte le solde après elle, et une erreur se corrige comme le ferait un comptable : par une contre-passation, une ligne inverse, jamais en modifiant ou en supprimant la première.

Les prix, les coûts, les identifiants légaux de l’émetteur (ICE, IF, RC, patente, CNSS, RIB) et l’acheteur sont figés dans un document au moment de son émission. Clôturer un chantier fige sa marge ; valider une fiche de salaire fige ses chiffres, si bien qu’une correction de pointage ultérieure ne peut pas changer un mois déjà payé.

Comment il a été construit

Chaque module, les mêmes six étapes

  1. Étape 1 sur 6

    Spécification

    Une étude détaillée avant tout code : schéma, endpoints, écrans et critères d’acceptation. Dix au total, gardées dans le dépôt.

  2. Étape 2 sur 6

    Module API

    Un module par domaine sur Bun et Hono : modèles Mongoose, schémas Zod, et des routes qui déclarent chacune leurs rôles et leur scope.

  3. Étape 3 sur 6

    Back-office

    La tranche correspondante en React : routes typées, hooks de requêtes, formulaires validés avec les mêmes règles, en français d’abord.

  4. Étape 4 sur 6

    Scopes

    La liste des permissions du back-office est synchronisée depuis l’API par un script : aucun bouton n’apparaît pour une action que le serveur refuserait.

  5. Étape 5 sur 6

    Tests d’API

    Trente scripts Python pilotent la vraie API flux par flux : commandes, paiements, clôtures, paie, contre-passations.

  6. Étape 6 sur 6

    Claude Code

    Les deux dépôts portent les instructions, les skills et les agents de Claude Code : le même mode opératoire, appliqué à chaque module.

Visibilité financière

Les marges ne quittent jamais le serveur

Qui peut voir les coûts, les marges et la masse salariale se décide à deux étages : un interrupteur par rôle pour toute l’organisation, activé pour les managers et désactivé pour les RH par défaut, puis un blocage sur un membre précis. Les admins les voient toujours.

La règle s’applique à la réponse elle-même, pas à l’écran. Pour quelqu’un qui n’y a pas droit, les champs sont absents de ce que l’API envoie : aucun outil du navigateur ne peut les révéler.

Le blocage d’un membre prend effet dès sa requête suivante. L’interrupteur de l’organisation est mis en cache 30 secondes : le basculer prend effet en moins d’une demi-minute, sans que personne ne se déconnecte.

Construit avec

  • Bun
  • Hono
  • MongoDB
  • Mongoose
  • Redis
  • WebSocket
  • Zod
  • React 19
  • Vite
  • TanStack Router
  • TanStack Query
  • TanStack Table
  • Zustand
  • Tailwind CSS
  • shadcn/ui
  • PM2
  • Docker
  • Claude Code

Où il en est

Chaque module du cahier des charges, construit

Pointage, paie et déplacements, congés, produits et stock, chantiers, clients et facturation, les deux caisses, chèques, demandes aux fournisseurs et tableaux de bord sont en place, en français, anglais et arabe. Reste à venir : un accès en lecture seule pour les employés et les stagiaires.

Parlons du vôtre
Modules dans le cahier des charges du client, chacun construit en module d’API et en tranche de back-office.
11
Rôles, du stagiaire à l’admin ; trois d’entre eux se connectent au back-office.
5
Étude suivanteAissam Portfolio