J’ai récemment créé un site pour une masseuse indépendante qui gère son propre cabinet. C’est le genre de projet où les exigences sont faciles à énoncer, mais où l’on risque de se tromper si l’on essaie de tout résoudre soi-même : une page d’accueil soignée, un système de réservation en ligne qui fonctionne vraiment, et un moyen pour la propriétaire de gérer son agenda et ses séances sans avoir à m’appeler à chaque fois qu’il y a un changement.

Voici comment nous avons choisi d'utiliser Hapio, et pourquoi cela a bien fonctionné.

Le point de départ

Ma cliente disposait déjà d'une page Facebook et prenait les réservations via Messenger. Cela fonctionne… jusqu'à ce que ça ne fonctionne plus. Réservations en double, rendez-vous oubliés, réponses manuelles aux mêmes questions sur les tarifs et les disponibilités. Elle souhaitait disposer de son propre site web où les clients pourraient réserver directement, et où elle pourrait fermer certains jours, modifier les horaires d'ouverture et ajouter de nouveaux soins par elle-même.

Ce qu’il faut retenir : c’est une masseuse, pas une administratrice système. Tout ce que nous développons doit être compréhensible pour quelqu’un qui ne raisonne pas en termes de bases de données et d’API.

Pourquoi ne pas développer nous-mêmes le système de réservation ?

I pourrait ont développé un système de réservation sur mesure. Laravel, un bookings tableau, logique relative aux créneaux disponibles, gestion des conflits, délais d'attente entre les traitements, gestion des jours de fermeture, vacances d'été…

Mais c’est exactement le genre de code qui semble simple sur un tableau blanc et qui, dans la pratique, se transforme en six mois de cas limites. Une seule ressource (un thérapeute), des horaires d’ouverture récurrents avec des exceptions, des marges avant et après chaque séance, des durées de séance variables… Ce n’est pas sorcier, mais cela représentebeaucoupde code qui n’apporte pas de valeur ajoutée spécifique à ce projet en particulier.

Hapio s'en charge. Nous disposons d'une API prête à l'emploi pour la disponibilité, les réservations, les services et la gestion des plannings. J'ai ainsi pu me concentrer sur l'essentiel du projet : créer un site agréable et un processus de réservation quileur ressemble, et non un système de réservation générique.

L'architecture que nous avons retenue

Nous avons développé une application Laravel légère servant d'enveloppe autour de Hapio. Il s'agit plutôt d'une « couche front-end + d'intégration » que d'un « système de réservation complet ».

Hapio est chargé de :

• Réservations (créer, consulter, annuler)
• Services/soins (nom, durée, prix, délais de transition)
• Horaires d'ouverture réguliers (du lundi au dimanche)
• Jours d'absence (jours fériés, congés maladie, etc.)
• Calcul du nombre de créneaux disponibles en tenant compte de tous les éléments ci-dessus

Laravel est chargé de :

• La page d'accueil et l'interface utilisateur de réservation (Livewire)
• Panneau d'administration permettant de gérer les horaires, les prestations et d'avoir une vue d'ensemble des réservations
• E-mail (confirmation, rappel, annulation – à la fois au client et au propriétaire)
• Liens d'annulation sécurisés (signés HMAC, afin que les clients ne puissent pas accéder à la réservation d'une autre personne en devinant le code)
• Mise en cache des créneaux horaires disponibles (Redis)
• Gestion des webhooks en cas de modification des données Hapio

La base de données Laravel ne contient en principe que les utilisateurs administrateurs, les sessions et les tâches en file d'attente. Aucune donnée relative aux réservations n'est stockée localement. Hapio est la source de référence.

Cela semble tout à fait adapté à une entreprise de cette taille. Une petite base de données locale, une instance Redis, rien à maintenir qui ne soit pas indispensable.

Le processus de réservation

Le client suit quatre étapes : choisir un soin → choisir un créneau horaire → remplir les informations demandées → c'est terminé.

Les soins sont récupérés depuis Hapio au chargement de la page. Les horaires sont récupérés par semaine ; nous les mettons en cache de manière intensive dans Redis, car ce sont les données les plus sollicitées. Une vue hebdomadaire permet au client de consulter les rendez-vous jusqu’à douze semaines à l’avance.

Une fois la réservation confirmée :

1. La réservation est créée dans Hapio
2. Les coordonnées du client (nom, numéro de téléphone, e-mail, message facultatif) sont enregistrées sous forme de métadonnées dans la réservation.
3. Un lien d'annulation est généré (signé HMAC à l'aide d'une clé secrète que nous contrôlons)
4. Un e-mail est envoyé au client et au propriétaire

L'annulation s'effectue via le lien signé – aucune connexion n'est requise. Nous appliquons une règle des 24 heures : vous ne pouvez ni réserver ni annuler avec un préavis inférieur à ce délai. Cette règle est appliquée dans notre code au moment de la lecture, et non dans le cache ; elle fonctionne donc de manière cohérente même si le cache n'a pas encore été invalidé.

Le panneau d'administration

Le propriétaire se connecte et dispose de quatre onglets :

• Réservations– à venir et passées, avec possibilité d'annulation
• Agenda– cliquez sur un jour du calendrier pour l'ouvrir ou le fermer
• Horaires d'ouverture– le programme hebdomadaire récurrent, jour par jour
• Services– ajouter, modifier, désactiver des soins

Tout passe par l'API Hapio. Le panneau d'administration est essentiellement une interface conviviale qui s'appuie sur leur modèle de données. Lorsqu'elle modifie les horaires d'ouverture ou qu'elle ferme un jour, Hapio envoie un webhook, nous invalidons le cache et nous recalculons les créneaux horaires en arrière-plan.

Il a fallu un peu de travail pour rendre le flux du webhook fiable – vérification de la signature, idempotence, recours à un vidage complet du cache en cas de problème –, mais une fois le système en place, cela en valait la peine. Les créneaux disponibles sont mis à jour rapidement sans que nous ayons à interroger l'API.

Ce qui a bien fonctionné

Séparation des préoccupations.Nous n'avons pas à nous occuper de la logique de réservation. Hapio gère les conflits, les marges de temps et la planification. Nous nous chargeons de l'expérience utilisateur et des spécificités du site.

Webhooks + cache.Les créneaux disponibles sont mis en cache pendant 24 heures. Lorsqu’un changement survient dans Hapio (nouvelle réservation, modification d’horaire, nouveau service) et qu’un événement est déclenché, nous invalidons le cache concerné puis le réinitialisons. Les clients voient ainsi les horaires mis à jour sans que nous ayons à récupérer toutes les données depuis l’API à chaque consultation de la page.

Métadonnées relatives aux réservations.Les informations sur les clients sont stockées sous forme de métadonnées dans la réservation Hapio. Nous n’avons pas besoin d’une table « clients » distincte. Pour une entreprise unipersonnelle, cela suffit.

Liens d'annulation.Liens signés HMAC dans les e-mails de confirmation et de rappel. Le client n'a pas besoin de se connecter ni de se souvenir d'un numéro de réservation. Nous vérifions le jeton côté serveur avant d'autoriser l'annulation.

Une gestion administrative sans contraintes techniques.La propriétaire peut gérer elle-même son emploi du temps et ses prestations. Je n'ai pas besoin d'intervenir lorsqu'elle souhaite fermer son salon un jour ou ajouter un nouveau soin.

Les points sur lesquels nous avons dû réfléchir

SDK et gestion des erreurs.Nous utilisons le SDK PHP de Hapio en tant que dépendance de chemin. Ce SDK génère parfois des avertissements PHP qui masquent les véritables messages d'erreur ; nous avons donc encapsulé les appels et désactivé les avertissements afin que les erreurs de l'API soient bien signalées.

La règle des 24 heures.La règle métier « au moins 24 heures avant la réservation/l'annulation » est appliquée dans notre code au moment de la lecture, et non dans Hapio. Cela signifie que le cache peut contenir des créneaux horaires qui ne sont pas affichés au client : nous les filtrons lors du renvoi des données. C'est simple et prévisible.

Une seule ressource, un seul site.La configuration fait référence à un seul site et à une seule ressource (le thérapeute). Si l'entreprise venait à compter plusieurs thérapeutes ou plusieurs sites, il faudrait repenser le système, mais pour la configuration actuelle, c'est parfait.

Résumé

Pour un petit cabinet de massage dont la propriétaire doit tout gérer elle-même, Hapio s'est avéré être le choix idéal. Nous n'avons pas développé un système de réservation à proprement parler, mais plutôt un site et une couche d'intégration qui permettent d'utiliser Hapio d'une manière adaptée à l'activité.

Laravel + Livewire pour l'interface utilisateur et les e-mails. Hapio pour toute la logique de réservation. Redis pour la mise en cache. Des webhooks pour synchroniser le cache.

Grâce à Hapio – et à l’aide de l’IA tout au long du processus –, il lui a fallu environ un week-end pour créer de toutes pièces l’ensemble du site et en faire un outil qu’elle pouvait réellement commencer à utiliser pour son activité.

Ce n'est pas l'architecture la plus complexe que j'aie jamais conçue, mais c'est l'une de celles qui me semblent le mieux adaptées au projet. Et c'est exactement ce qu'on recherche.

Brouillon. Les références à un site, un lieu ou une personne spécifiques ont été omises intentionnellement.