Le contexte
Un SaaS de réservation destiné aux salons de coiffure, instituts d’esthétique et praticiens du bien-être. Chaque établissement dispose d’une page de réservation publique, et pilote depuis l’outil son calendrier, ses équipes, ses prestations et ses clients.
L’enjeu
Trois contraintes ont structuré le projet, et aucune des trois n’est un détail d’implémentation.
Le rendez-vous non honoré est le vrai problème du métier. Dans ces professions, un créneau perdu ne se rattrape pas : c’est du chiffre d’affaires qui disparaît. Le rappel n’est donc pas une fonctionnalité de confort, c’est la principale valeur économique du produit. Encore faut-il qu’il soit lu — et l’e-mail ne l’est plus vraiment.
L’arabe n’est pas une traduction de plus. Passer une interface en arabe signifie l’inverser entièrement : sens de lecture, alignements, position des icônes, direction des flèches, ordre des colonnes. Un projet qui ajoute le RTL après coup ne le fait jamais complètement — il reste toujours un écran oublié.
Le calendrier multi-employés est un problème plus difficile qu’il n’en a l’air. Horaires individuels, absences, durées variables selon la prestation, chevauchements à interdire : la disponibilité réelle d’un salon ne se calcule pas naïvement.
Ce que nous avons fait
- Les rappels par WhatsApp, via l’API officielle — parce que dans ce secteur, c’est le canal réellement lu, contrairement à l’e-mail. Les envois sont traités par des tâches de fond, pour qu’un service de messagerie lent ou indisponible ne bloque jamais une réservation en cours.
- Le multilingue traité dès le départ, y compris l’arabe en écriture de droite à gauche. L’internationalisation a été posée comme contrainte d’architecture, pas comme couche ajoutée — c’est la seule manière de ne pas laisser traîner des écrans à moitié inversés.
- Une réservation publique sans création de compte. Obliger un client à créer un compte pour prendre rendez-vous, c’est perdre une partie des réservations à l’étape la plus fragile du parcours.
- Un calendrier multi-employés gérant les horaires propres à chaque personne, avec le multi-établissements sur un même compte.
Le résultat
La plateforme est en développement actif.
Ce projet est un bon exemple de décision produit qui ressemble à une décision technique. Choisir WhatsApp plutôt que l’e-mail pour les rappels engage une intégration, une gestion de tâches de fond et une dépendance à une API externe — pour un bénéfice qui n’est pas technique du tout : un rendez-vous honoré au lieu d’un créneau perdu. C’est le genre d’arbitrage qui se prend avec le client, pas à sa place.