Contexte
LGCD édite un logiciel de gestion destiné aux conciergeries marocaines. Notre client n’exploite donc pas lui-même de logements : il vend l’outil à celles qui le font. Comprendre le métier de ses utilisateurs était la condition d’entrée du projet.
Au Maroc, la location courte durée s’est structurée plus vite que ses outils. Une conciergerie qui gère trente à cent logements pour le compte de propriétaires se retrouve à piloter son activité avec trois systèmes qui ne se parlent pas : les annonces et leurs calendriers sur Airbnb et Booking.com, le planning des équipes de ménage dans des groupes WhatsApp, la facturation et les relevés propriétaires dans un tableur.
Aucun de ces outils n’est mauvais isolément. C’est leur juxtaposition qui coûte cher, et elle coûte surtout au moment précis où l’erreur devient publique.
Le problème
Le calendrier est le point de rupture. Une nuitée vendue deux fois, sur deux plateformes, en l’espace des quelques minutes qui séparent deux synchronisations manuelles, se solde par une annulation, une pénalité plateforme et un avis négatif durable. C’est le risque que les gérants citent en premier, et c’est celui qu’aucun tableur ne peut couvrir.
La fiscalité locale ne pardonne pas l’approximation. La taxe de séjour et la taxe de promotion touristique se calculent par ville, par type de bien et par nuitée, avec des barèmes que les communes révisent. Un calcul rétroactif faux n’est pas une erreur de tableur : c’est un redressement.
Le terrain n’utilise pas de logiciel de bureau. Les femmes de ménage, les agents de maintenance et une partie des gérants n’ont pas d’adresse e-mail professionnelle. Ils ont un téléphone et WhatsApp. Toute solution qui suppose un ordinateur, un identifiant et un mot de passe classique est abandonnée dans les deux semaines.
Les propriétaires réclament de la visibilité. Ils confient un bien et attendent un relevé mensuel clair : occupation, revenus, charges, interventions. Le produire à la main pour quarante propriétaires occupe une personne à temps partiel.
La solution
Un cloisonnement qui ne dépend pas de la vigilance du développeur
Chaque agence est isolée par un périmètre appliqué directement au niveau des requêtes, via un scope global Eloquent, doublé du remplissage automatique de l’identifiant d’agence à la création de tout enregistrement.
La distinction est importante. Filtrer par agence dans chaque requête fonctionne — jusqu’à la première requête où le développeur oublie le filtre. Sur une plateforme multi-clients, cet oubli-là est une fuite de données entre concurrents. En plaçant l’isolation dans le modèle plutôt que dans l’appel, on transforme une discipline en garantie.
Le calendrier comme source de vérité
La synchronisation iCal fonctionne dans les deux sens avec Airbnb, Booking.com, VRBO et Abritel. À chaque import, toute réservation entrante est confrontée aux réservations existantes du bien : un chevauchement est refusé, comptabilisé, et remonté à l’agence sous forme de notification demandant un arbitrage humain.
Le choix de refuser plutôt que d’écraser est délibéré. Une double réservation détectée et signalée se règle par un appel ; une double réservation acceptée silencieusement se découvre le jour de l’arrivée du voyageur.
Cinq applications, une par métier
Plutôt qu’une application unique dont chacun n’utiliserait qu’un dixième, la plateforme expose cinq applications installables : agence, ménage, maintenance, propriétaire, voyageur. Chacune ne montre que ce que son métier exige — l’agent de ménage voit ses tâches du jour et valide par photo, le propriétaire consulte ses relevés, le voyageur accède au logement et aux informations pratiques.
La connexion se fait par numéro WhatsApp, pas par e-mail. Ce n’est pas un raccourci technique : c’est l’identifiant que le terrain possède réellement.
L’application voyageur existe en français, en anglais et en arabe. Elle lit la bande MRZ des passeports et des cartes d’identité directement depuis l’appareil photo pour pré-remplir la fiche de police, obligatoire au Maroc — une saisie fastidieuse et source d’erreurs devient une photo.
Une fiscalité figée au moment du calcul
Le calcul de la taxe de séjour et de la TPT s’appuie sur les barèmes par ville et par type de bien. Le résultat est enregistré sur la réservation sous forme d’instantané complet : taux appliqués, nombre de nuitées, personnes taxables, date de calcul.
Si une commune révise son barème six mois plus tard, les réservations passées conservent leur calcul d’origine. C’est cette immuabilité qui rend les déclarations défendables en cas de contrôle.
Une plateforme ouverte, pas une boîte noire
Une API REST de 84 points d’entrée, authentifiée par jetons, couvre les réservations, le calendrier, le ménage, la maintenance, la facturation, les documents d’identité et les rapports fiscaux.
Une vingtaine d’événements webhook — réservation créée, confirmée, annulée, paiement reçu, ménage terminé, conflit de calendrier détecté — permettent aux agences de brancher leurs propres outils. Chaque livraison est signée en HMAC-SHA256, porte un identifiant d’événement stable pour la déduplication côté consommateur, et conserve son contenu afin d’être rejouée sans avoir à provoquer de nouveau l’événement métier.
En cas d’échec, la reprise suit un espacement croissant — une minute, cinq, trente, deux heures, six heures — puis la livraison est marquée abandonnée et signalée dans le tableau de bord. Un webhook qui échoue en silence est pire qu’un webhook absent : l’agence croit son système synchronisé.
Chaque agence chez elle
Chaque agence dispose d’un site de réservation sur un sous-domaine, ou sur son propre nom de domaine via un simple CNAME, avec vérification de propriété avant activation. Les paiements passent par CMI, la passerelle bancaire marocaine, avec signature HMAC-SHA512.
Architecture
| Décision | Motif |
|---|---|
| Isolation par scope global Eloquent | Rend la fuite inter-agences impossible par oubli, pas seulement improbable |
| Applications installables plutôt que natives | Un seul code métier, aucune dépendance aux magasins d’applications, mise à jour immédiate |
| Connexion par numéro WhatsApp | L’identifiant que le personnel de terrain possède réellement |
| Instantané fiscal sur la réservation | Une révision de barème ne réécrit pas l’historique déclaré |
| Refus des chevauchements plutôt qu’écrasement | Un conflit signalé se règle ; un conflit absorbé se découvre à l’arrivée |
| Reprise des webhooks à espacement croissant | Absorbe une panne passagère du consommateur sans le saturer |
Résultats
La première version est sortie en moins d’un mois. Ce qui suit — les cinq applications installables, l’API publique, les webhooks, le moteur fiscal — a été ajouté par incréments successifs, chacun mis en production sans interrompre le service.
Le logiciel est aujourd’hui commercialisé sur lgcd.ma auprès des conciergeries marocaines. Il couvre 63 entités métier, 110 migrations et 89 suites de tests automatisés.
Les chiffres présentés ici sont ceux de la plateforme elle-même — nombre d’applications, de points d’API, d’événements webhook, de plateformes synchronisées — et non des indicateurs commerciaux des agences clientes. Nous préférons publier ce qui est vérifiable.
Le motif initial du projet, le conflit de calendrier, est traité à la source : détecté à la synchronisation, refusé, et signalé avant que la réservation ne soit confirmée au voyageur.
