Apprenez à planifier et construire une application web pour salons de beauté multi‑sites : réservation, rotation du personnel, permissions et analyses de revenus, avec étapes pratiques.
Avant de dessiner des écrans ou de choisir des outils, définissez précisément ce que « mieux » signifie pour vos salons. Une application multi‑sites peut résoudre beaucoup de problèmes, mais si les objectifs ne sont pas clairs, vous livrerez des fonctionnalités sur lesquelles personne ne s’appuiera.
Choisissez 3–5 résultats et associez‑leur des chiffres. Exemples courants pour les salons :
Ces objectifs deviennent les critères d’acceptation de votre MVP : si l’app ne fait pas évoluer ces métriques, elle n’est pas terminée.
Les opérations multi‑sites impliquent généralement des rôles distincts :
Pour chaque rôle, notez ce qu’il fait au quotidien — et ce qu’il ne doit pas pouvoir modifier.
Documentez le « chemin heureux » et la réalité parfois chaotique :
Le multi‑site n’est pas juste « ajouter un champ emplacement ». Décidez en amont :
Répondre à ces questions tôt évite des refontes douloureuses — surtout pour les règles de réservation et le reporting.
Avant de concevoir des calendriers ou des tableaux de bord, il vous faut une « source de vérité » partagée pour votre activité : où vous opérez, qui y travaille, ce que vous vendez et qui vous servez. Des données cœur solides maintiennent la cohérence de la réservation, de la rotation et du reporting multi‑sites.
Chaque site doit stocker des détails opérationnels pratiques :
Astuce : modélisez explicitement les « ressources » (Chaise 1, Salle Coloration) plutôt qu’en notes. C’est la façon la plus simple d’éviter les doubles réservations plus tard.
Un profil de personnel doit contenir plus qu’un nom et un téléphone. Pour supporter la planification de rotation et une réservation correcte :
Choix de conception : stockez les compétences comme des tags structurés (avec niveaux) afin que les services puissent exiger « Compétence : Coloration Niveau 2+ » et que le moteur de réservation filtre le personnel éligible.
Créez un enregistrement client unique qui fonctionne sur tous les sites. Incluez :
Cela évite des doublons quand quelqu’un réserve dans une nouvelle branche et maintient des KPIs précis (taux de rétention, valeur vie client).
Définissez les services comme des items réservables avec :
Si vous traitez les services comme un catalogue — plutôt qu’en texte libre — vous aurez des réservations plus propres, moins d’erreurs à l’accueil et des analyses fiables.
Votre moteur de réservation est la « source de vérité » pour la disponibilité entre sites, personnel, salles et règles de service. Traitez l’interface calendrier comme une vue de ce moteur, pas comme le moteur lui‑même.
La réservation en ligne et à l’accueil doivent interroger la même API et respecter les mêmes règles. Sinon, vous vous retrouverez avec deux calendriers qui divergent.
Au minimum, la disponibilité doit considérer :
Définissez clairement les règles de conflit et appliquez‑les partout :
Pour garder les calendriers précis en temps réel, utilisez l’optimistic concurrency (numéros de version) ou des réservations courtes (p. ex. un créneau “en attente” de 5–10 minutes pendant le checkout). Cela réduit les conditions de concurrence quand deux personnes ciblent le même créneau.
Buffers (préparation/nettoyage), pauses et déjeuner doivent être des blocs d’occupation à part entière — pas des notes. Les bundles de services (ex. coupe + couleur) doivent être une seule réservation qui se déploie en segments temporels multiples, pouvant nécessiter des ressources différentes.
N’encodez pas ces politiques en dur. Stockez‑les comme paramètres par site (et parfois par service), par exemple :
Quand les politiques sont pilotées par les données, vous pouvez les ajuster sans changer le code — et conserver un comportement cohérent web, mobile et accueil.
La rotation est l’endroit où les opérations multi‑sites deviennent soit justes et prévisibles, soit chaotiques et politiques. Traitez la planification comme un ensemble de règles claires plus un moyen sûr de gérer les exceptions.
La plupart des salons bénéficient du support de plusieurs « templates » de rotation, car un site peut fonctionner de façon régulière alors qu’un autre est piloté par la demande.
Approche pratique : stocker des modèles réutilisables (ex. « Centre‑ville Semaine A »), puis générer des shifts pour une plage de dates au lieu de créer chaque semaine manuellement.
L’équité n’est pas « tout le monde a les mêmes shifts », mais « les règles sont visibles et cohérentes ». Décidez comment répartir :
Intégrez‑les comme objectifs souples (préférences) versus règles strictes (contraintes). Ex. : « Chaque styliste doit avoir au moins un créneau prime par semaine » (objectif) vs « Un coloriste senior doit être présent le samedi » (règle).
Votre ordonnanceur est aussi intelligent que les contraintes qu’il comprend. Contraintes courantes :
Modélisez‑les comme des données structurées, pas des notes, afin que le système avertisse avant publication d’un conflit.
Même le meilleur planning nécessite des exceptions. Fournissez des outils pour :
Cela garde le planning flexible sans perdre la responsabilisation — crucial en cas de litige, question de paie ou contrôle de conformité ultérieur.
En multi‑sites, « qui peut faire quoi » devient aussi important que des fonctionnalités comme la réservation. Les permissions protègent la vie privée des clients, réduisent les erreurs coûteuses et facilitent la confiance dans vos chiffres — surtout quand managers, accueil et personnels utilisent le même système.
Commencez par décider ce que chaque rôle peut voir et éditer :
Ajoutez ensuite des règles cross‑site. Par ex., une réceptionniste ne peut réserver que pour son site, tandis qu’un responsable de zone peut voir les calendriers de tous les sites mais ne peut pas éditer la paie.
Plutôt qu’un grand droit “admin”, segmentez par fonctionnalité pour être précis :
Cela fluidifie le quotidien tout en limitant les actions sensibles aux bonnes personnes.
Les approbations préviennent les pertes silencieuses de marge et le chaos d’emploi du temps. Déclencheurs fréquents :
Rendez les approbations rapides : afficher la raison, l’impact (montant, rendez‑vous affecté) et qui doit approuver.
Un journal d’audit doit répondre : quoi a changé, qui l’a fait, quand et d’où. Tracez les modifications de rendez‑vous, ajustements de paiements/commissions, remboursements et changements d’inventaire. Ajoutez des filtres interrogeables par site, membre du personnel et date pour que les propriétaires règlent les litiges sans fouiller des messages.
Le checkout transforme la planification en revenus : il doit être rapide à l’accueil et précis pour le reporting.
Commencez par un résumé « services rendus » tiré du rendez‑vous : services, durée, membre(s) du personnel, site. Laissez ensuite la réception ajouter des éléments sans changer d’écran : add‑ons, produits retail, remises (code promo ou manuelle), pourboires et taxes.
Gardez le calcul prévisible en définissant un ordre d’opérations (par ex. : remises appliquées aux services, taxe après remise, pourboire après taxe). Quelle que soit la règle, appliquez‑la uniformément entre les sites pour que les rapports restent comparables.
Décidez ce que vous autorisez :
Définissez aussi le comportement des paiements partiels : une facture peut‑elle rester ouverte avec un solde, ou chaque rendez‑vous doit‑il être soldé le jour même ? Si vous autorisez des soldes, spécifiez quand le service est considéré « payé » pour les calculs de commission et de revenu.
Les remboursements et annulations doivent exiger un motif (liste + notes optionnelles), enregistrer qui a fait l’action et conserver une piste d’audit. Distinguez clairement :
Bloquez les actions sensibles derrière des rôles (voir /blog/permissions-and-audit-logs) pour éviter les contournements faciles.
Choisissez vos prestataires de paiement et la livraison des reçus (email/SMS) tôt — ils influencent votre modèle de données. Même sans intégration comptable day‑one, stockez des enregistrements financiers propres : facture, lignes de ticket, tentatives de paiement, paiements réussis, pourboires, taxes et remboursements. Cette structure facilite ultérieurement les exports et un tableau de bord d’analyse des revenus fiable.
Vos analytics doivent répondre vite à deux questions : « Combien avons‑nous gagné ? » et « Pourquoi ça a changé ? » Commencez avec un petit ensemble cohérent de métriques de revenus pour que chaque site rapporte de la même manière.
Standardisez au minimum :
Décidez comment gérer les cas limites (paiements partagés, remboursements partiels, cartes cadeaux, dépôts) et documentez‑le pour éviter les débats sur les tableaux de bord.
Facilitez la comparaison par :
Pattern pratique : rangée de tuiles en haut (ventes nettes, rendez‑vous, ticket moyen), puis tables cliquables pour creuser par site ou membre du personnel.
Le revenu est le résultat ; l’opérationnel en est le levier. Incluez :
Ces KPI expliquent le « pourquoi » sans analyses compliquées.
Gardez les filtres simples et toujours visibles : plage de dates, site, personnel, service. Évitez de cacher l’essentiel dans des « paramètres avancés ». Chaque rapport doit être exportable en CSV avec les mêmes colonnes que l’affichage (plus IDs et timestamps) pour le partage avec comptables, paie ou un outil BI sans reconstruction.
Les commissions sont un point de confiance. Le personnel veut la transparence, les managers des exports simples, et les propriétaires des totaux prêts pour la paie sans feuilles de calcul interminables.
Commencez par supporter les règles les plus courantes et rendez‑les visibles dans la configuration des services :
Pour les équipes multi‑sites, permettez d’assigner les plans de commission par site, rôle ou individu. Un styliste détaché sur une autre branche peut être payé selon son plan d’origine ou celui de la branche — l’app doit supporter les deux politiques.
Gardez les inputs de paie simples mais flexibles :
C’est aussi ici que vous définissez si la commission se calcule sur le brut (avant remises) ou le net (après remises) et comment traiter les remboursements.
La réalité crée des cas limites : retouches, rétrofacturations, remises de bonne volonté, primes manuelles. Ajoutez un type d’entrée Ajustement qui exige :
Cette traçabilité réduit les litiges et facilite l’explication des totaux.
Générez un relevé qui reflète la manière dont le personnel pense son travail :
Les managers doivent pouvoir obtenir un aperçu par site et exporter pour l’outil de paie. Si vous prévoyez une intégration POS, alignez les catégories du relevé avec votre configuration de checkout pour une réconciliation facile (voir /blog/build-salon-pos-payments).
L’inventaire est optionnel pour certains salons, mais si vous vendez des produits retail (ou souhaitez contrôler les consommables comme colorant, révélateur, gants), un suivi basique évite les ruptures surprises et clarifie le reporting.
Commencez par un catalogue produit simple qui supporte plusieurs sites. Chaque article doit avoir : SKU/barcode (optionnel), nom, catégorie (retail vs consommable), coût, prix et quantité en stock par site. Pour les consommables, envisagez un flag « non destiné à la vente » pour usage interne.
Les salons multi‑sites ont besoin de transferts. Faites‑le léger : sélectionner “From location”, “To location” et les quantités — puis générer un enregistrement de transfert pour que les deux sites se mettent à jour correctement.
Pour les inventaires, supportez des cycles rapides (comptages partiels) et des inventaires complets (fin de mois). Enregistrez les ajustements avec un motif (comptage, endommagé, périmé) pour repérer les tendances.
Les alertes de faible stock doivent être par site. Permettez au personnel de définir un seuil de réapprovisionnement et d’attacher un fournisseur et une taille de paquet si besoin. Évitez de transformer cela en un système d’achats complet — la plupart des salons ont juste besoin de savoir « quoi est bas et où ».
Les articles retail doivent transiter par le même checkout que les services pour que stock et revenus restent cohérents. Lorsqu’un produit est ajouté à un ticket, le système doit :
Cela aligne les rapports avec la réalité sans étapes supplémentaires à la réception.
Une app de salon vit ou meurt sur la rapidité au comptoir et la lisibilité sur téléphone. Visez un petit ensemble d’écrans centraux qui se chargent vite, sont clairs au toucher et gardent le personnel concentré sur le client suivant.
Organisez la navigation autour de ce qui se passe chaque heure :
Le reste doit être à un tap, pas dans le flux principal.
Le personnel de l’accueil doit pouvoir réaliser trois actions en moins de 10 secondes :
Le calendrier doit par défaut afficher une vue jour avec de larges cibles tactiles et peu de scroll. Utilisez un en‑tête sticky (date, site, filtre) pour que le personnel ne « se perde » jamais.
Les statuts doivent indiquer la prochaine action, pas seulement l’état :
La couleur aide, mais affichez toujours le label pour l’accessibilité.
Les équipes occupées tapent mal. Ajoutez des garde‑fous :
Si vous planifiez un MVP, priorisez ces flux centraux avant d’ajouter paramètres et rapports avancés. Pour une séquence de déploiement propre, voir /blog/rollout-plan-mvp-pilot-training.
Une application de salon repose sur la fiabilité : les réservations ne doivent pas subir de latence, le personnel ne doit pas perdre l’accès en plein shift, et les propriétaires doivent pouvoir faire confiance aux chiffres. Commencez par des outils éprouvés que votre équipe peut maintenir.
La plupart des apps de gestion multi‑sites fonctionnent bien avec une configuration classique :
Si vous traitez des paiements, choisissez un provider avec de bonnes docs et webhooks (ex. Stripe) et concevez votre système pour que les événements de paiement soient re‑tentables en sécurité.
Si vous voulez aller plus vite pour une première version exploitable (calendrier + checkout + dashboards), une approche vibe‑coding peut aider. Par exemple, Koder.ai permet de générer une app React avec backend Go et PostgreSQL depuis un chat structuré, utiliser un mode planning avant de construire et exporter le code source quand vous prenez la suite en interne.
Exécutez trois environnements dès le départ. Staging doit refléter la production pour tester les changements de réservation et POS sans risquer les données live.
Prévoyez :
Si vous utilisez un workflow plateforme (y compris Koder.ai), privilégiez snapshots et rollback pour réagir vite aux modifications d’horaires et paiements aux heures de pointe.
Utilisez TLS partout, chiffrez les données sensibles au repos, et stockez les secrets dans un vault géré (pas dans le code). Appliquez le principe du moindre privilège via permissions basées sur les rôles et exigez MFA pour les admins et propriétaires. Ajoutez des journaux d’audit pour remboursements, modifications d’emploi du temps et changements de permissions.
Anticipez des pics de trafic aux pauses déjeuner et en soirée. Utilisez du cache pour les vues en lecture (dashboards), des queues pour les tâches lentes, et isolez les charges analytiques pour que l’analytics ne ralentisse pas la réservation et le checkout.
Lancer une app de gestion multi‑sites n’est pas un « big bang » mais un déploiement contrôlé qui protège la réception et rassure les propriétaires sur les chiffres.
Votre première release doit couvrir la boucle quotidienne de bout en bout :
L’objectif du MVP : rapidité et précision à l’accueil, pas une automatisation parfaite. Si le calendrier est instantané et les totaux concordent avec la caisse, l’adoption suivra.
Si le temps est limité, envisagez un prototype MVP sur Koder.ai, puis itérez avec les parties prenantes en cycles courts. La capacité de déployer rapidement, d’attacher un domaine et de rollbacker est utile pendant les pilotes.
Faites un pilote avec un manager « champion » et un petit groupe de réceptionnistes et stylistes. Gardez le pilote court (2–4 semaines) et définissez des métriques de succès :
Évitez de changer les règles centrales en milieu de semaine. Logguez les problèmes et regroupez les mises à jour.
Fournissez une formation par rôle : accueil, managers, stylistes, propriétaires. Utilisez des checklists courtes et des pratiques scénarisées (walk‑in, client en retard, transfert de client à un autre membre). Une page « Que faire quand… » intégrée à l’app (ex. /help/front-desk) réduit la panique aux heures de pointe.
Collectez du feedback chaque semaine : vitesse à l’accueil, clarté du planning, utilité des rapports. Priorisez ensuite les améliorations dans une roadmap visible :
Ce rythme permet d’améliorer l’app sans perturber l’opérationnel. Si vous publiez vos apprentissages, notez que des plateformes comme Koder.ai proposent des programmes de crédit pour créer du contenu ou des parrainages — utile si vous documentez votre build en public tout en itérant le produit.
Commencez par 3–5 résultats mesurables et donnez‑leur des chiffres (par exemple : no‑shows de 12% → 7%). Utilisez ces indicateurs comme critères d’acceptation pour le MVP.
Cibles pratiques pour un salon :
Dressez la liste de chaque rôle et de leurs tâches quotidiennes, puis précisez ce qu’ils ne doivent pas pouvoir modifier.
Rôles typiques :
Considérez le multi‑site comme des règles métier, pas seulement comme un champ “emplacement”.
Décidez tôt :
Ces choix impactent la logique de réservation et la structure des rapports — les modifier ensuite coûte cher.
Modélisez d’abord les entités centrales en données structurées (pas en texte libre) pour garder la planification et les rapports fiables :
Construisez un moteur d’indisponibilité unique que tous les canaux (réservation en ligne et accueil) utilisent.
Au minimum, l’indisponibilité doit prendre en compte :
Pour éviter les conflits en temps réel, utilisez des (5–10 minutes) ou de l’ lors de la sauvegarde des rendez‑vous.
Supportez des modèles de rotation réutilisables et générez des plages de shifts sur une période donnée, avec des exceptions contrôlées.
Modèles utiles :
Rendez les dérogations sûres via des approbations et conservez une piste d’audit pour les échanges et changements de dernière minute.
Appliquez des permissions par rôle, par site et par fonction, puis ajoutez des approbations pour les actions à fort impact.
Déclencheurs d’approbation courants :
Concevez le checkout autour d’une facture prévisible issue du rendez‑vous, puis permettez d’ajouter rapidement :
Définissez tôt les règles pour les paiements partiels (autorisés ou non) et distinguez clairement (annulation avant rapprochement) et (remboursement après règlement), avec motifs requis et contrôles de permission. Pour davantage de contexte, voir /blog/build-salon-pos-payments.
Standardisez les définitions d’abord pour que chaque site rapporte de la même façon.
Métriques minimales à uniformiser :
Ajoutez des KPI opérationnels qui expliquent les variations :
Rendez les règles de commission explicites et auditées, et alignez‑les sur les calculs du checkout.
Modèles courants :
Pour les équipes multi‑sites, autorisez des plans par , ou . Définissez si la commission se calcule sur le et comment les remboursements affectent les paiements. Fournissez des relevés de paie clairs et des ajustements avec motif + approbation.
Si vous vendez des produits retail ou voulez contrôler les consommables, suivez le stock par site.
Bonnes pratiques :
Assurez‑vous que la vente retail passe par le même checkout : diminuer le stock au paiement, enregistrer revenus/taxes/remises, et restaurer le stock lors de remboursements.
Concevez la navigation autour des actions fréquentes :
Objectifs de rapidité : trois actions en < 10s :
Conservez des journaux d’audit interrogeables (qui/quoi/quand/de où) pour remboursements, modifications d’emploi du temps et actions impactant la paie. Voir aussi /blog/permissions-and-audit-logs.
Permettez des filtres simples (date, site, personnel, service) et l’export CSV avec colonnes stables (IDs et timestamps).
Utilisez des statuts d’appartement clairs : Confirmé, Arrivé, En service, Terminé, No‑show. Prévoyez des filets de sécurité (Undo, confirmations seulement pour actions coûteuses, validations utiles). Pour un plan de déploiement MVP, voir /blog/rollout-plan-mvp-pilot-training.
