Un départ disponible, mais pas deux places pendant 90 minutes

Votre marketplace affiche une séance à 09h15 pour deux personnes. Le départ semble libre, le prestataire possède bien deux places le matin, mais une autre réservation réduit sa capacité à une place au milieu des 90 minutes vendues. Le client découvre le refus au paiement ou le support doit déplacer son rendez-vous. Le risque de survente n’est pas nécessairement lié au calendrier : le parcours a pu vérifier un instant au lieu de toute la prestation.

Une heure de départ ne suffit pas à établir une disponibilité. La quantité demandée doit rester admissible jusqu’à la fin de l’occupation, y compris la préparation prévue. En pratique, séparez quatre décisions : la précision de saisie du planning, les départs proposés, la durée du service et la capacité continue. Un exemple local montre comment sept départs conviennent à une personne, deux seulement à un duo et un seul après ajout de préparation.

Le journal des nouveautés Sharetribe d’octobre 2026 annonce des disponibilités réglables au quart d’heure dans Template v12.5.0. Cette amélioration facilite certains plannings ; elle ne transforme pas quinze minutes en durée universelle de service. Les sources ont été vérifiées le 24 octobre 2026. Les calculs présentés restent des scénarios fictifs, sans compte Sharetribe, paiement ni réservation réelle.

Notre accompagnement en création de marketplace relie ces choix au parcours opérateur. Pour une marketplace de services, la promesse doit rester cohérente entre la fiche prestataire, le sélecteur horaire, le prix, la confirmation et le back-office. Une grille plus fine vaut surtout si chaque choix mène à une prestation que les ressources peuvent réellement couvrir.

Pour qui vérifier la capacité sur toute la prestation

Les séances fixes avec plusieurs participants

Un atelier, un cours ou une visite guidée peut vendre une durée déterminée avec plusieurs places. Le client choisit son horaire et son groupe, sans composer librement la longueur de l’activité. Le responsable produit doit alors définir ce que signifie la capacité : personnes admises, postes de travail ou équipements disponibles. Deux accompagnateurs et deux machines ne constituent pas forcément deux unités interchangeables dans le modèle de réservation.

Le premier signal faible est un créneau qui disparaît quand le client passe d’une à deux personnes, alors que le calendrier affiche toujours la même ouverture. Cette disparition peut être correcte si une partie de l’intervalle ne conserve qu’une place. Le parcours doit l’expliquer plutôt que laisser croire à une panne. Le second signal est un refus récurrent juste après sélection, alors que le prestataire confirme que son planning était déjà à jour.

Les limites d’un simple compteur de places

Une prestation qui mobilise plusieurs ressources nommées exige une vérification supplémentaire. Deux places disponibles à chaque minute ne prouvent pas que le même intervenant reste présent pendant toute la séance si les ressources changent. Notre exemple représente une capacité homogène attachée à une seule offre, déjà ramenée en segments de disponibilité restante. Il ne résout pas l’affectation de personnes, les temps de trajet ou les compétences nécessaires.

Si votre service demande un technicien particulier, une salle et un matériel précis, décrivez d’abord cette combinaison. Le compteur de l’annonce ne remplace pas un agenda de ressources multiples. Le bon arbitrage consiste à conserver la réservation simple lorsqu’elle décrit réellement la prestation, puis à intégrer un moteur spécialisé ou une qualification supplémentaire lorsque l’interchangeabilité supposée devient fausse.

Ce que change le quart d’heure dans Sharetribe

Une amélioration ciblée du planning des offres fixes

La release v12.5.0 publiée le 15 octobre précise que les disponibilités au quart d’heure concernent les annonces de type unitType: fixed. Elle ajoute un composant de sélection avec une liste de hauteur limitée et défilement, utilisé dans plusieurs formulaires de disponibilité et de réservation. Vérifiez la version de votre propre template, surtout s’il a été personnalisé ou si son parcours de commande diffère du modèle fourni.

Le paramétrage des services récurrents et de leurs échéances reste une décision distincte de la cadence des départs. Une fenêtre de 09h15 à 12h15 peut ainsi mieux représenter l’horaire du prestataire qu’une ouverture arrondie à l’heure. Cela ne définit pas encore la séance vendue, les heures auxquelles elle peut commencer ni le nombre de participants admis. Lors d’une migration, comparez chaque configuration existante à son rendu après changement. Ne remplacez pas automatiquement une fenêtre historique par une succession de prestations de quinze minutes.

Distinguer précision de disponibilité et rythme des départs

L’aide Sharetribe sur la gestion des disponibilités sépare les unités jour, nuit, heure et durée fixe. Pour les offres fixes, le prestataire détermine une longueur de séance et peut proposer des départs à l’heure, à la demi-heure ou au quart d’heure. Le client ne choisit pas librement la durée comme dans une location horaire. Ces paramètres doivent rester distincts dans votre contrat de données.

Une séance de 90 minutes peut commencer toutes les quinze minutes sans être vendue en six unités de facturation. À l’inverse, un planning défini avec précision ne rend pas toutes ses bornes vendables : le départ doit laisser suffisamment de temps avant fermeture. Documentez la durée, la cadence et l’origine de la grille. Une interface qui arrondit le début vers le bas peut proposer un rendez-vous avant l’ouverture effective.

Partir de la disponibilité restante, pas du planning seul

Assembler plan, exceptions et réservations

La référence de disponibilité Sharetribe distingue le plan régulier, les exceptions sur une période concrète et les réservations. La requête de créneaux tient compte de ces éléments. Elle rappelle aussi que les états pending et accepted consomment la disponibilité, tandis que proposed, canceled et declined ne la consomment pas. Un statut métier traduit dans votre back-office doit conserver ce sens.

Le responsable des opérations vérifie donc ce qui occupe réellement la période. Un simple décompte de demandes envoyées ne donne pas la capacité restante : certaines propositions n’engagent rien, alors qu’une réservation en attente peut déjà bloquer des places. Le support doit retrouver l’état du processus et la réservation correspondante avant de supprimer une indisponibilité supposée. Une intervention manuelle peut sinon ouvrir une capacité déjà promise.

Nommer l’origine et la fraîcheur de l’observation

Les segments utilisés dans notre recette sont une photographie fictive de capacité restante, déjà calculée. Ils ne sont pas obtenus en rejouant le moteur Sharetribe ni en soustrayant nous-mêmes toutes les réservations d’un compte. Cette distinction évite de confondre deux preuves : interpréter correctement une disponibilité reçue et démontrer que sa production intègre toutes les contraintes du service.

Dans votre application, le contrat de journalisation conserve la ressource, la période, le contexte demandé et l’heure de lecture de chaque observation. Sa sortie est un ensemble de départs candidats, pas une confirmation. La responsabilité de l’équipe intégration porte sur la traçabilité ; produit définit les conditions d’affichage ; le processus transactionnel reste responsable de l’engagement. Une copie ancienne conservée dans le navigateur ne doit pas devenir l’autorité finale du calendrier.

Exemple : sept départs pour une personne, deux pour un duo

Construire une matinée dont la capacité varie

Cas fictif : une annonce propose une séance de 90 minutes dans une fenêtre de 09h15 à 12h15. Les départs sont espacés de quinze minutes. Il reste deux places jusqu’à 10h00, une seule entre 10h00 et 10h30, puis deux jusqu’à la fermeture. Les heures appartiennent à une même journée déjà résolue, sans transition horaire ; la recette ne convertit aucun fuseau. Les participants utilisent des places supposées équivalentes.

Pour une personne, les départs 09h15, 09h30, 09h45, 10h00, 10h15, 10h30 et 10h45 restent admissibles. Chacun dispose d’au moins une place durant ses 90 minutes. Un départ à 11h00 est exclu parce qu’il finirait à 12h30, après fermeture. Le nombre d’heures proposées décrit donc l’intersection entre la cadence commerciale, la durée et les segments observés.

Refuser les départs dont le milieu manque de places

Pour deux personnes, seuls 10h30 et 10h45 restent admissibles. Les départs de 09h15, 09h30 et 09h45 possèdent bien deux places à leur début, mais traversent ensuite la demi-heure limitée à une place. Vérifier uniquement la première borne produirait cinq choix au lieu de deux. Les trois faux positifs ont une cause commune, identifiable avant le checkout.

Contre-intuitivement, la matinée possède 150 minutes avec deux places disponibles : 45 minutes avant 10h00 et 105 minutes après 10h30. Ce total dépasse largement la durée de 90 minutes, mais il ne permet pas de vendre une séance continue à 09h15. Additionner des fragments disponibles ne reconstitue pas une disponibilité sans interruption. Le contrôle doit respecter l’ordre des segments et leurs lacunes.

Vérifier chaque portion de l’occupation demandée

Traverser les segments adjacents sans inventer de continuité

La règle pédagogique parcourt les segments triés entre le début d’occupation et sa fin. Chaque portion doit conserver au moins le nombre de places demandé. Une lacune ou une capacité insuffisante entraîne un refus. Plusieurs segments adjacents peuvent toutefois couvrir la séance : exiger qu’un seul bloc contienne toutes les 90 minutes rejetterait des disponibilités valides lorsque la représentation est simplement découpée.

La fin de l’intervalle est traitée comme exclusive. Une occupation de 09h15 à 10h00 n’utilise pas la capacité de la période qui commence à 10h00. Cette convention doit être cohérente entre stockage, comparaison et confirmation. Le témoin vérifie ce raccord explicitement, puis refuse une occupation de deux places de 10h00 à 10h30 dans la photographie où une seule place reste disponible.

Ne pas additionner des représentations qui se chevauchent

La référence Marketplace API décrit des créneaux temporels et des intervalles étendus selon les paramètres de requête. Elle précise que les identifiants des timeSlot sont éphémères. Le contrat d’import doit donc préciser quelle représentation est reçue : des intervalles superposés ne sont pas automatiquement des ressources supplémentaires que l’on peut additionner.

Notre programme accepte uniquement des segments disjoints de capacité restante et refuse les superpositions. Il ne normalise pas toutes les réponses possibles de Sharetribe. Pour adapter un flux réel, conservez un exemple de réponse et prouvez sa transformation avant de réutiliser cette règle. Un identifiant différent lors d’une seconde lecture ne démontre pas non plus qu’un nouvel horaire s’est ouvert : comparez le contexte et les bornes.

Rejouer les cinquante-cinq contrôles locaux

Observer les témoins corrects et les raccourcis erronés

Le programme Python de capacité continue s’exécute avec la bibliothèque standard. Ses entrées sont des minutes de la journée et des nombres de places inventés. Il ne crée aucun agenda, aucune réservation et aucun paiement. Ses sorties donnent les départs candidats et les écarts produits par une lecture insuffisante, afin de rendre la discussion reproductible entre produit, développement et opérations.

python3 capacite_continue.py
# Résultat attendu : PASS, 55 contrôles
# Une place : 09:15 à 10:45, sept départs
# Deux places : 10:30 et 10:45
# Deux places avec préparation : 10:45 uniquement

Les contrôles rejouent les six ordres possibles des trois segments et vérifient le même résultat. Ils couvrent les segments adjacents, une lacune réelle, une capacité nulle, les bornes de fermeture et les quantités invalides. Trois départs admis à tort par le contrôle du seul début sont explicitement retrouvés. Le changement d’identifiants fictifs entre deux observations ne modifie pas les horaires admissibles.

Ne pas transformer cette recette en preuve de réservation atomique

Un autre témoin lit d’abord une fenêtre entièrement libre, puis une photographie où la capacité centrale a diminué. Le même départ passe d’admis à refusé. Cette comparaison montre pourquoi il faut relire l’état au moment pertinent, mais elle ne simule ni deux acheteurs concurrents ni un verrou distribué. La transaction réelle doit encore décider si la capacité peut être engagée.

Les minutes utilisées ne portent pas de date ni de zone ; les ressources sont homogènes et les segments déjà calculés. La recette exclut les calendriers externes, le moteur de prix Sharetribe, les erreurs réseau et les délais PSP. Ces limites bornent son usage : elle vérifie un contrat d’interprétation, à compléter ensuite par des essais sur votre processus réel, avec les permissions et les cas de reprise attendus.

Ne pas confondre résultat de recherche et départ confirmé

Une offre trouvée peut avoir une disponibilité ailleurs dans la plage

Le filtrage de recherche Sharetribe distingue notamment time-full et time-partial, avec une quantité de places et une durée minimale pour la recherche partielle. Trouver une annonce dans une matinée ne prouve donc pas que le premier horaire imaginé par le client convient. Le résultat doit conduire à la sélection des départs compatibles, pas préremplir arbitrairement le début de la plage demandée.

Dans notre scénario, une offre possède bien une période de 90 minutes pour deux personnes après 10h30. Elle peut être pertinente pour une recherche sur la matinée, tout en refusant le départ de 09h15. Le libellé produit peut annoncer une disponibilité dans la plage, puis présenter les horaires précis. Il ne devrait pas promettre « disponible à 09h15 » sur la seule présence de l’offre dans les résultats.

Faire correspondre le résumé calendrier et le détail

Les paramètres de requête peuvent limiter le nombre d’intervalles renvoyés pour résumer une journée. Un indicateur « au moins une séance possible » ne constitue pas nécessairement la liste exhaustive des départs. Le contrat de l’interface doit nommer cette différence. Le résumé sert à guider la navigation ; le panneau de réservation doit obtenir les données suffisantes pour les choix qu’il affiche.

Le suivi des crédits d’usage Sharetribe permet de mesurer le coût des lectures et des ressources affichées, sans justifier un calendrier incomplet. Si vous conservez un cache, sa clé inclut les conditions qui changent le résultat, notamment la ressource, la période et le nombre de places. Réutiliser la réponse pour une personne après sélection d’un duo donnerait un calendrier trop optimiste. Lorsque les données manquent, affichez un chargement ou une impossibilité de vérifier, plutôt qu’une disponibilité supposée qui devra être retirée au moment de payer.

Ajouter la préparation sans changer le service vendu

Distinguer horaire client et période réellement occupée

Sharetribe permet de distinguer les heures affichées et les bornes de réservation pour représenter, par exemple, une préparation avant la séance. Dans notre convention fictive, dix minutes sont nécessaires avant l’arrivée des participants. Un départ client à 10h30 occupe alors la ressource dès 10h20. Pour deux personnes, il traverse encore la portion limitée à une place et devient inadmissible.

Le départ de 10h45 occupe la période de 10h35 à 12h15 et reste possible. Il ne reste donc qu’un choix pour le duo. Le client continue de recevoir une séance de 90 minutes ; les opérations doivent voir les 100 minutes d’occupation. La confirmation et le planning prestataire n’affichent pas forcément les mêmes bornes, mais ils doivent retrouver la même réservation et la même politique de préparation.

Ne pas facturer le pas du calendrier comme une unité vendue

Prenons un prix fictif de 90 euros par participant pour la séance fixe, hors taxes et hors autres frais de l’exercice. Le duo représente 180 euros. Un calcul erroné qui compterait six quarts d’heure à 90 euros par personne produirait 1 080 euros, soit 900 euros de trop. La cadence des départs n’est pas une base de multiplication du prix.

Ce tarif n’est pas présenté comme une règle Sharetribe par défaut : il illustre un contrat commercial à implémenter et vérifier dans votre propre calcul. Le prix peut être par séance, participant ou autre unité explicitement vendue. La préparation peut avoir un coût sans être facturée comme du temps client. Produit et finance doivent décider de cette convention avant que le développeur relie durée, quantité et commission.

Faire comprendre le choix sur ordinateur et mobile

Conserver la quantité demandée pendant la sélection

Le panneau rappelle le nombre de participants et la durée fixe près du sélecteur. Si le client change de quantité, les départs sont recalculés et un choix devenu invalide ne reste pas silencieusement sélectionné. Proposez une prochaine action compréhensible : choisir un autre horaire, réduire le groupe si cela correspond au besoin, ou revenir à la recherche. Le parcours ne modifie pas la demande sans accord.

Sur mobile, vérifiez la liste ouverte avec suffisamment d’horaires pour provoquer son défilement. Le choix actif doit rester identifiable et la navigation clavier doit atteindre les mêmes possibilités que le toucher. Une liste qui déborde derrière le bouton de validation peut masquer un départ disponible ou conserver une valeur non relue. La recette porte sur l’usage réel, pas seulement sur la présence du composant dans le code.

Revoir les libellés après la mise à jour du template

La documentation officielle des textes ajoutés par les nouvelles releases recense les clés du 15 octobre pour les heures de début, de fin et l’absence de sélection. Il explique comment reprendre les nouvelles clés dans une configuration existante. Vérifiez aussi les libellés destinés aux lecteurs d’écran ; un bouton visuellement clair peut perdre son contexte lorsqu’il est annoncé seul.

La traduction ne suffit pas à qualifier une disponibilité. Faites relire les messages de refus par les opérations avec le cas de 09h15 pour deux personnes. Le message devrait expliquer qu’aucune capacité continue ne couvre cette demande, sans exposer les données d’un autre client. Il peut proposer 10h30 ou 10h45 avant préparation, puis seulement 10h45 lorsque cette contrainte fait partie de la prestation.

Erreurs fréquentes qui créent de faux créneaux

Arrondir le planning ou additionner les minutes libres

Arrondir 09h15 à 09h00 ajoute une période que le prestataire n’a pas déclarée. Arrondir 12h15 à 13h00 autorise des fins trop tardives. Additionner les fragments à deux places masque l’interruption centrale. Ces raccourcis semblent simplifier le calendrier, mais ils changent l’offre. La recette conserve les bornes exactes puis applique la grille commerciale à l’intérieur de cette disponibilité.

Une autre erreur est de rejeter toute séance traversant une frontière entre deux segments. Si la capacité reste suffisante de part et d’autre et que les intervalles sont adjacents, la continuité existe. Le test doit donc réfuter les faux positifs et les faux négatifs. Bloquer trop de départs protège artificiellement contre les incidents tout en retirant des ventes que le prestataire pouvait servir.

Promettre le créneau avant que le processus l’engage

Une sélection locale ne doit pas être présentée comme une réservation acquise. Le processus transactionnel et ses états donnent la preuve d’engagement. Après un refus ou une réponse incertaine, le support retrouve la transaction avant de demander au client de recommencer. Une répétition aveugle peut multiplier les demandes, brouiller les paiements et rendre le calendrier plus difficile à interpréter.

Une hypothèse de douze reprises mensuelles de huit minutes représente 96 minutes de support, sans compter les remboursements éventuels. Cette valeur sert à cadrer une mesure, pas à promettre un retour sur investissement. Classez les incidents selon leur cause : capacité discontinue, donnée ancienne, préparation oubliée ou message trompeur. La correction utile dépend de cette distribution, pas du seul nombre de tickets.

Plan d’action : recetter une offre avant d’élargir le catalogue

Écrire le contrat de disponibilité avec les opérations

Choisissez une offre dont la durée, les places et la préparation sont connues. Les entrées du contrat sont le planning, les exceptions et l’état observé ; les sorties sont les départs candidats, les raisons de refus et l’engagement ensuite obtenu. Nommez les responsabilités du prestataire, du support et de l’intégration. Un changement de capacité doit avoir une origine et une procédure de vérification, même lorsqu’il ne modifie aucun prix.

Rejouez la matinée fictive avec une personne, un duo, une préparation et une fermeture exacte. Ajoutez un changement de quantité après sélection, puis une capacité modifiée entre affichage et confirmation. Les dépendances vers le processus transactionnel et le paiement sont contrôlées séparément. La réussite du calcul local ne dispense pas de vérifier les messages envoyés au client et les horaires reçus par le prestataire.

Limiter l’ouverture et rendre la reprise exécutable

Le pilote conserve une version du paramétrage et quelques transactions de test autorisées. Surveillez les départs proposés puis refusés, les corrections de participants et les écarts d’horaire dans les confirmations. Le seuil acceptable dépend du service, mais chaque refus inexpliqué doit pouvoir être rejoué avec les données qui ont produit l’affichage. Un total de réservations réussi ne montre pas les candidats abandonnés avant paiement.

Le repli ferme les nouveaux départs concernés sans supprimer les engagements déjà confirmés. L’équipe vérifie ensuite la cause : mauvaise interprétation des segments, cache incomplet ou configuration de durée. La reprise s’appuie sur un cas corrigé et un témoin ordinaire toujours valable. Évitez de décaler rétroactivement les horaires existants simplement pour faire correspondre l’historique à la nouvelle grille.

• Si la quantité change, recalculer les départs avant de conserver une sélection.
• Si une portion manque de capacité, refuser la séance même lorsque son début est libre.
• Si la transaction n’établit pas l’engagement, retrouver son état avant de confirmer ou de recommencer.

Guides complémentaires pour conserver le même engagement

La continuité de capacité s’insère entre la résolution de l’horaire et le cycle de réservation. Ces deux contrôles restent nécessaires lorsque le calendrier devient plus précis, car ils répondent à des incidents différents du manque de places au milieu d’une séance.

Résoudre une heure locale avant de comparer des intervalles

Le dossier sur les deux créneaux portant la même heure pendant une nuit de transition traite l’identité temporelle. Avant de calculer une occupation, il faut savoir quel instant a été choisi. Une heure répétée ne doit ni fusionner deux possibilités ni produire un décalage implicite dans la confirmation.

Notre exemple de capacité évite volontairement cette transition pour isoler le calcul continu. Dans votre recette complète, faites ensuite traverser les deux situations au même parcours. Le calendrier doit conserver l’instant résolu et appliquer les places disponibles à cet intervalle précis, sans revenir à une comparaison de simples libellés horaires.

Relier capacité, expiration et confirmation transactionnelle

Le cycle de verrouillage d’une réservation de service complète la sélection par les règles d’engagement et de reprise. Une durée admissible doit encore être réservée selon le processus prévu, puis libérée ou confirmée avec les mêmes bornes et la même quantité.

Vérifiez particulièrement la réponse tardive après expiration et le retour du client sur un ancien écran. La disponibilité observée auparavant ne suffit plus à conclure. Le support doit retrouver l’engagement réel et la prochaine action autorisée, plutôt que reconstruire une réservation à partir d’un horaire encore affiché dans le navigateur.

Conclusion : vendre une durée que la capacité couvre entièrement

Une disponibilité au quart d’heure rend le planning plus fidèle, mais elle ne décide ni la longueur de la séance ni ses ressources. La preuve utile couvre toute l’occupation. Dans la matinée fictive, les sept départs d’une personne deviennent deux pour un duo, puis un seul avec préparation : chaque réduction correspond à une contrainte explicable.

Le calcul doit accepter les segments adjacents, refuser les lacunes et conserver une convention claire sur les bornes. Il doit aussi rester distinct de la réservation effective. Les cinquante-cinq contrôles locaux rendent ces règles vérifiables ; ils ne remplacent pas les essais de votre processus Sharetribe, de vos agendas et de vos confirmations.

La conception d’une marketplace de services relie durée, quantité, préparation et prix à une même promesse. Ce contrat permet aux prestataires et au support d’expliquer un refus, de proposer une alternative et de retrouver les conditions réellement acceptées par le client.

Pour transformer ces règles de capacité en parcours exploitable, Dawap vous accompagne dans la création et l’évolution de votre marketplace. Nous pouvons raccorder les systèmes nécessaires et éprouver les situations difficiles avant généralisation. Nous travaillons sur vos ressources et vos règles de service afin que chaque horaire proposé corresponde à une prestation que votre plateforme sait engager et suivre.