MRA Lavage Automobile : remplacer un plugin de réservation WordPress

MRA Lavage Automobile exploite aujourd'hui quatre centres de lavage en Île-de-France — deux à Corbeil-Essonnes, deux à Montigny-le-Bretonneux. La réservation en ligne existait déjà : un plugin WordPress payant, qui a encaissé de vraies réservations de janvier 2024 à mai 2026. Le problème n'était donc pas d'obtenir la réservation, mais deux limites précises de la façon dont elle était modélisée. Réponse directe : on a fait du centre une entité de premier rang et de la durée du rendez-vous une somme calculée depuis le panier, migré les 136 réservations historiques, et remplacé le plugin par une application Laravel + React. Voici les deux limites, et ce que la migration a appris.

Les deux limites, précisément

Le centre n'était pas une donnée, c'était une réponse de formulaire. Le plugin proposait bien des tables de gestion multi-emplacements — elles étaient restées vides. À la place, le centre était demandé par un champ radio obligatoire, avec ses trois options en texte libre et même une information d'horaire glissée dans le libellé du champ. Ça marche pour prendre la commande. Ça ne permet pas d'attacher au centre ses propres horaires, ses propres fermetures, ni une contrainte de base de données.

Un rendez-vous durait une heure, toujours. Sur les 136 réservations reprises, 132 durent exactement soixante minutes. Or un lavage extérieur sur une citadine et une formule complète sur un SUV n'occupent pas le même créneau. La configuration en place ne dérivait pas la durée du contenu de la commande.

Une précision d'honnêteté, parce qu'on nous prête souvent ce mérite à tort : la grille tarifaire n'était pas le problème. WordPress gérait déjà trois catégories de véhicule avec des prix distincts. Le gain du sur mesure tient aux deux points ci-dessus, pas à la tarification.

Ce qui a été construit

Le moteur de créneaux est la pièce centrale. Il compose des horaires par centre avec plusieurs plages par jour, une pause déjeuner, des fermetures exceptionnelles, un délai de prévenance réglable depuis l'administration (trente minutes par défaut), le refus des créneaux passés — et surtout une durée égale à la somme des durées des prestations choisies, ces durées étant portées par le couple prestation × catégorie de véhicule.

Et une garantie qu'aucune vérification applicative ne peut offrir seule : une contrainte d'unicité en base sur (location_id, date, start_time). Le contrôle côté code sert à afficher un message clair ; la contrainte rend le double-booking structurellement impossible, même si deux clients valident à la même seconde.

Le tunnel de réservation enchaîne centre → catégorie de véhicule → prestations → date et créneau → coordonnées → récapitulatif, jusqu'à un numéro de confirmation.

L'administration couvre réservations, centres, prestations, prix par catégorie de véhicule, disponibilité par centre, horaires, fermetures exceptionnelles, codes promo et réglages, avec des écrans de statistiques et de santé système.

L'espace client se passe de mot de passe. À la place, un code à six chiffres envoyé par e-mail, valable dix minutes, avec limitation du nombre d'envois et de tentatives. Un client de centre de lavage ne crée pas de compte pour gérer un mot de passe : il veut retrouver son rendez-vous.

S'y ajoutent une application installable sur mobile avec notifications push, un rappel automatique la veille, des codes promo à plafonds et date d'expiration, et un formulaire de contact où le client peut laisser un message vocal enregistré depuis son navigateur.

Un fait à connaître pour comparer : il n'y a pas de paiement en ligne. Le règlement se fait sur place, et la réservation enregistre le moyen annoncé.

Notre procédure de migration, dans l'ordre

C'est la partie qu'on refait à chaque remplacement de plugin, et elle se fait avant d'écrire une ligne de code :

1. Lister les tables du plugin, puis vérifier lesquelles sont réellement peuplées. Un plugin expose souvent des fonctionnalités que l'installation n'utilise pas. Ici, les tables d'emplacements et d'extras étaient vides, les horaires tenaient en un seul jeu global.
2. Chercher où vivent les données que le plugin n'a pas de colonne pour stocker. C'est le point de vigilance principal, et le piège de cette migration : le centre n'était pas une colonne de la réservation mais une réponse à un champ de formulaire, rangée dans une table de métadonnées. Un import qui lit la table des réservations sans aller chercher ces métadonnées perd l'information sans le signaler.
3. Établir la correspondance des statuts et des prestations entre l'ancien et le nouveau modèle, et la relire ligne à ligne sur un échantillon.
4. Marquer les lignes importées avec leur origine, pour pouvoir plus tard les distinguer de l'activité de la nouvelle plateforme.
5. Rejouer l'import sur une copie, compter les lignes en entrée et en sortie, et comparer les bornes de dates avant de toucher la production.

L'architecture réelle

Navigateur ──► Laravel ──► Inertia ──► React + TypeScript (Vite)
                  │
                  ├─► /api/wizard/*  créneaux · prestations · code promo
                  │
                  ├─► Filament (/admin)  administration
                  │
                  └─► Eloquent ──► MariaDB
                                    services · service_prices (prestation × catégorie véhicule)
                                    locations · location_service
                                    opening_hours · exceptional_closures
                                    bookings ◄── UNIQUE (location_id, date, start_time)
                                    clients · codes de connexion (OTP)
                                    promo_codes · abonnements push

Pas de front séparé, pas d'API à maintenir en double : Inertia sert les composants React directement depuis les routes Laravel. L'authentification repose sur les sessions du framework, avec deux périmètres distincts — l'équipe d'un côté, les clients par code e-mail de l'autre.

Sur la tarification : les prix varient par prestation et par catégorie de véhicule, pas par centre. Ce qui se règle par centre, c'est la disponibilité — quelles prestations sont proposées où, et selon quels horaires.

Combien de temps

La première version était en production huit jours après le premier commit. L'historique compte au total onze journées de commits réparties sur plusieurs mois : la mise en service, puis des itérations au fil des besoins.

L'IA a servi à produire vite les écrans et une première passe de code. Ce qui a demandé du jugement humain, c'est le modèle de données et les règles de disponibilité — précisément ce qu'on ne peut pas déléguer sans se retrouver avec un prototype qui tombe au premier cas limite.

Avant / après

Avant : une réservation en ligne fonctionnelle, mais un centre réduit à une case à cocher, une durée de rendez-vous fixe, et un historique prisonnier du plugin.

Après : des centres modélisés avec leurs propres horaires et fermetures, une durée dérivée du panier et du véhicule, une contrainte de base qui interdit le double-booking, et 136 réservations historiques reprises.

Une leçon honnête sur ce projet, parce qu'elle vaut pour tout réseau qui s'agrandit : quand un quatrième centre a été ajouté quelques mois plus tard, la ligne en base s'est créée depuis l'administration, mais le site a demandé une passe de correction — le nombre de centres était encore écrit en dur dans une quinzaine d'endroits, du bandeau d'en-tête aux mentions légales. C'est le genre de dette qu'on ne voit qu'au moment où le réseau grandit. Elle est corrigée ; elle méritait d'être citée plutôt que tue.

Questions fréquentes

Faut-il quitter WordPress pour avoir de la réservation en ligne ?

Non, et ce cas le montre : la réservation fonctionnait depuis plus de deux ans sur un plugin payant. On bascule sur du sur mesure quand la logique métier dépasse ce que l'installation modélise — ici, un centre traité comme une entité à part entière, et une durée de rendez-vous dérivée du panier et de la catégorie du véhicule.

Peut-on récupérer l'historique des réservations ?

Oui, et ça se prépare. Le point de vigilance n'est pas la table des réservations elle-même, c'est ce que le plugin n'y stockait pas : une information saisie dans un champ de formulaire vit dans une table de métadonnées séparée, et un import qui l'ignore la perd silencieusement. On vérifie donc d'abord où chaque donnée utile est réellement rangée, avant d'écrire l'import.

Comment éviter deux réservations sur le même créneau ?

Par une contrainte d'unicité en base de données, pas seulement par une vérification dans le code. La vérification sert à afficher un message clair ; la contrainte garantit que même deux validations simultanées ne peuvent pas produire un double-booking.

Le client peut-il ajouter un centre ou changer un tarif lui-même ?

Les prestations, prix, horaires, fermetures et codes promo se gèrent entièrement depuis l'administration. Pour un nouveau centre, la ligne se crée aussi depuis l'administration — mais prévoyez une relecture du site si des compteurs ou des mentions ont été écrits en dur, ce qui est fréquent sur une v1.

Combien de temps pour une plateforme de réservation sur mesure ?

Sur ce périmètre, la première version était en ligne huit jours après le premier commit, migration de l'historique comprise. Le cadrage fait la différence : plus les règles de disponibilité sont explicites au départ, moins on itère ensuite.

Un projet similaire à confier ?

Ce cas illustre ce qu'on fait au-delà des mots-clés « WordPress » ou « Shopify » : une application cadrée autour d'une règle métier précise, et une migration qui ne jette pas l'historique. Décrivez votre besoin via le devis en ligne, ou commençons par un diagnostic de cadrage pour trancher entre corriger l'existant et repartir sur une base neuve.