Distribution hôtelière
Mapping hôtelier : rapprocher les chambres sans effacer leurs différences
Deux fournisseurs peuvent désigner le même hôtel et vendre des chambres ou conditions très différentes. Un bon rapprochement distingue l’identité du lieu, le type de chambre et le tarif réellement réservable.
Réponse directe
Rapprocher trois objets différents
L’établissement est un lieu identifié par son nom, son adresse et sa position. La chambre décrit un espace et ses caractéristiques. Le tarif ajoute dates, occupation, prestations incluses, paiement et conditions. Un même hôtel peut ainsi avoir plusieurs chambres et chaque chambre plusieurs tarifs. Réduire ces niveaux à une seule fiche crée des comparaisons trompeuses.
La documentation Google sur les ensembles chambre et tarif distingue également les données de chambre et les caractéristiques associées à une offre tarifaire. Cette séparation est une bonne base de modélisation, même hors de ce canal.
Constituer une identité d’établissement vérifiable
| Champ | Utilité | Contrôle |
|---|---|---|
| Identifiant interne | Stabilité des liens et de l’historique | Unique, jamais recyclé |
| Identifiants sources | Retrouver les offres de chaque fournisseur | Source et date du mapping |
| Nom et adresse | Reconnaître l’établissement | Variantes linguistiques et changements |
| Coordonnées | Écarter les homonymes | Vérifier bâtiment et entrée réelle |
| Statut | Publication et vente | Ouvert, déplacé, fermé ou incertain |
Une correspondance automatique peut proposer un candidat, mais les cas ambigus doivent rester en file de vérification. Conservez la source de la décision humaine et la possibilité de séparer deux fiches fusionnées à tort.
Comparer les caractéristiques qui changent l’expérience
Pour les chambres, distinguez capacité maximale et occupation tarifée, type de lit garanti ou demandé, configuration, étage si pertinent, salle de bains et attributs d’accessibilité vérifiés. Les qualificatifs « supérieure » ou « deluxe » ne sont pas standardisés entre sources. Une photo de l’hôtel n’est pas une preuve de la chambre réservée.
Pour le tarif, gardez séparés régime de repas, politique d’annulation, paiement sur place ou anticipé, taxes, devise et éventuelles restrictions de marché. Deux offres de même chambre mais de conditions différentes doivent rester comparables côte à côte. Reliez chaque image et texte à la chambre ou à l’établissement qu’il décrit réellement.
Recette sur un échantillon difficile
- Choisir des établissements homonymes dans une même ville et un hôtel présent chez trois fournisseurs.
- Comparer une chambre standard, une chambre familiale et une chambre accessible avec leurs tarifs.
- Vérifier les images, l’occupation, les repas et les conditions sur les fiches sources.
- Réaliser une réservation test puis comparer confirmation et promesse affichée.
- Modifier ou annuler le séjour pour vérifier que la référence renvoie toujours à la bonne offre.
Suivez le taux de correspondances revues, les faux regroupements et les écarts entre offre affichée et confirmation. Une couverture plus faible mais exacte peut mieux servir le voyageur qu’un grand catalogue mal rapproché.
Maintenir le mapping dans le temps
Déclenchez une revue quand une adresse change, qu’un hôtel ferme, qu’un fournisseur remplace ses identifiants ou qu’un libellé de chambre varie fortement. Les équipes service doivent pouvoir signaler une erreur depuis un dossier client. Publiez une correction avec une date et gardez la trace des réservations affectées.
Une fiche de rapprochement par établissement avec identifiants sources, règles de fusion, date de vérification et responsable de correction.
Comparer des lignes différentes dans le même séjour
Une réservation peut combiner des chambres et pensions différentes. Le mapping doit conserver ce qui distingue leurs offres et permettre de retrouver chaque tarif fournisseur. Le rapprochement d’un établissement ne justifie pas de fusionner les conditions de toutes ses chambres dans une seule règle client.
Lire le dossier Réservation multi-chambres : conditions et opérations par chambre, avec sa fiche de contrôle et son registre de suivi.
Rapprocher le lieu avant sa catégorie de chambre
Une correspondance de chambres doit partir d’établissements correctement identifiés. Deux catalogues peuvent nommer de façon proche des bâtiments, annexes ou exploitants distincts. Conservez la preuve du lieu, puis les références propres à chaque catégorie. Le rapprochement d’adresse ne garantit ni même couchage ni mêmes services.
Après une fusion éditoriale, rejouez une offre dont la catégorie reste distincte. Le test doit retrouver la source, l’occupation et les conditions, sans déplacer une réservation vers une chambre simplement parce que les fiches de lieu ont été réunies.
Identité des lieux : traiter doublons, déménagements et changements de nom : méthode, cas de contrôle et limites.
Séparer la chambre physique du paquet tarifaire dans la recette
Google distingue les données de chambre et les caractéristiques du paquet tarifaire dans ses Room Bundles. Sa documentation différencie aussi occupation prévue et capacité physique. Gardez ces dimensions séparées dans une correspondance : une catégorie proche peut être vendue avec un autre repas, une autre occupation ou d’autres conditions. Le scénario compare une même chambre sous deux paquets et vérifie que le mapping ne fusionne pas leurs engagements.
Google Hotel Prices : Room Bundles — référence consultée le 10/10/2026 ; portée précisée dans les sources du guide.
Cas à rapprocher : Configuration des lits : distinguer catégorie, couchages et demande
Le mapping des catégories doit préserver les configurations de lits et leur portée. Une correspondance de nom ne suffit pas pour aligner des chambres dont les couchages diffèrent. Rapprochez type source, espaces et arrangement vendu avant de fusionner les offres.
Configuration des lits : distinguer catégorie, couchages et demande · Vérifier les preuves de ce dossier
Exercice de rapprochement · offres fictives
Même hôtel, trois offres : laquelle correspond à la famille ?
La demande porte sur deux adultes et un enfant de huit ans, avec couchage confirmé et petit déjeuner inclus. Les trois offres ci-dessous concernent le même établissement et les mêmes dates. Les catégories, capacités et conditions sont inventées pour l’exercice.
| Attribut | Offre A | Offre B | Offre C |
|---|---|---|---|
| Catégorie | Double standard | Chambre familiale | Double standard |
| Couchages annoncés | Un lit double | Un lit double et un lit simple | Un lit double ; lit supplémentaire sur demande |
| Occupation explicitement acceptée | Deux adultes, aucun enfant ajouté | Deux adultes et un enfant de huit ans | À confirmer avec le lit supplémentaire |
| Petit déjeuner | Inclus pour deux personnes | Inclus pour les trois voyageurs | Inclus pour les adultes ; supplément enfant non confirmé |
| Annulation | Non remboursable | Annulable selon l’échéance de l’offre | Condition à rapprocher du supplément |
| Lecture de la demande | Incompatible avec l’occupation demandée | Conforme aux attributs annoncés de l’exercice, mais dans une autre catégorie | Informations insuffisantes pour une promesse ferme |
Le nom « double standard » ne démontre pas l’équivalence
A et C partagent un libellé, mais aucune ne démontre à ce stade un couchage confirmé et un petit déjeuner pour les trois personnes. B répond aux attributs demandés dans cet exercice, tout en représentant une autre catégorie. Il faut conserver cette distinction dans le mapping plutôt que fusionner les trois offres sous un même identifiant de chambre.
Quelle clé conserver dans le catalogue ?
Rattachez l’identifiant établissement à la source, puis l’identifiant chambre et l’identifiant de l’offre tarifaire. Conservez séparément occupation, repas, annulation et suppléments. Une traduction du nom commercial doit garder les attributs d’origine et la date de leur lecture.
Que faut-il demander pour l’offre C ?
Une confirmation du couchage et de l’occupation autorisée, le prix du supplément éventuel, la couverture du petit déjeuner enfant et les conditions applicables à l’ensemble. Un champ vide reste une information manquante, pas une gratuité ni une capacité garantie.
Refaites ce contrôle après une modification de l’âge des enfants, du nombre de voyageurs ou des dates. La correspondance des hôtels peut rester stable tandis que les offres vendables changent. Consulter la grille d’occupation et de couchage · Structurer le registre de mapping.
Mews : fenêtres de synchronisation et références de canal
La version d’opération 2023-06-06 sépare les identifiants de réservation des références reçues d’un canal OTA, GDS ou CRS.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| ReservationIds | Le filtre accepte au maximum 1 000 identifiants de réservation. | Fractionner une reprise de références sans tronquer silencieusement la liste. |
| ChannelNumbers | Les références de canal ont leur propre filtre, limité à 100 éléments. | Conserver le type de référence ; une chaîne OTA n’est pas automatiquement l’Id Mews. |
| CreatedUtc et UpdatedUtc | Les intervalles de ces filtres sont limités à trois mois. | Découper un historique plus long et suivre les bornes réellement traitées. |
| Accès | Les réservations retournées sont limitées au périmètre de l’AccessToken. | Un résultat vide ne démontre pas l’absence de réservation dans les établissements hors périmètre. |
| Version de l’opération | ChannelNumbers accepte 1 000 éléments dans la version 2017-04-12, contre 100 dans la version 2023-06-06. | Conserver le chemin versionné avec la limite avant de construire les lots. |
Limites propres à cette opération documentée ; elles ne décrivent pas toutes les API Mews ni les droits d’un contrat particulier.
Mews Connector API — reservations/getAll/2023-06-06 · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
Google Hotel Prices : capacité physique et occupation du tarif
Une chambre pouvant accueillir quatre personnes n’est pas forcément vendue pour quatre dans chaque offre. Dans les messages Transactions, Google distingue la capacité, l’occupation prévue et le détail adultes/enfants.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Capacité de la chambre | Capacity décrit le nombre maximal de personnes que la chambre peut physiquement accueillir ; Occupancy ne doit pas dépasser cette capacité. | Ne transformez pas la capacité de la pièce en nombre de personnes couvertes par le tarif. |
| Détail des voyageurs | OccupancyDetails précise les types de voyageurs. Sans détail de type, les occupants sont considérés comme adultes. | Conservez la répartition adultes/enfants au lieu d’envoyer uniquement un total ambigu. |
| Tarif imbriqué | Si un RoomBundle contient OccupancyDetails, un Rate imbriqué ne doit pas le remplacer par un simple Occupancy : il hérite du détail ou le répète à l’identique. | Vérifiez la structure du tarif enfant autant que celle de son bloc parent. |
| Mode de transmission | La référence indique de transmettre les tarifs avec enfants via Live pricing queries With Context, pas via Pull ou Changed pricing. | Identifiez le mode d’intégration avant d’appliquer ces éléments ; ne transposez pas cette règle au flux ARI. |
Lire trois niveaux avant de comparer un tarif
Exemple de contrôle éditorial ; les chiffres du cas ne décrivent aucun hôtel réel.
- La pièce
Capacity=4 : quatre personnes peuvent physiquement y être accueillies selon la donnée transmise.
- L’offre
Occupancy=2 : cette offre ne doit pas être présentée comme couvrant quatre personnes.
- Le groupe
OccupancyDetails permet de distinguer adultes et enfants ; retrouvez le détail correspondant à la demande.
Deux erreurs de rapprochement à éviter
Fragments fictifs simplifiés, sans tarif réel ni transmission à Google.
La chambre est assez grande, l’offre reste prévue pour deux
Un produit associe une chambre de capacité quatre à une offre prévue pour deux occupants.
Capacity : 4
Occupancy : 2
Demande : 4 voyageursLecture du cas. La capacité ne démontre pas qu’un tarif pour quatre existe. Retrouvez une offre correspondant au groupe ; ne multipliez pas ni ne prolongez automatiquement le tarif de deux personnes.
Le tarif imbriqué perd la répartition familiale
Le RoomBundle contient deux adultes et un enfant ; son Rate imbriqué réintroduit seulement Occupancy=3.
Parent : OccupancyDetails présent
Répartition : 2 adultes + 1 enfant
Rate : simple Occupancy=3Lecture du cas. Le total trois ne remplace pas le détail du parent. Dans le cas décrit par la référence, laissez le Rate hériter de la répartition ou répétez OccupancyDetails à l’identique, puis validez le message.
Périmètre : messages Transactions XML de Google Hotel Prices. Ce sont des règles d’intégration et de représentation des tarifs ; elles ne garantissent ni l’acceptation d’une famille par un hôtel ni les équipements de la chambre.
Google Hotel Prices — Pricing & Room Inventory, Transactions XML Reference · mise à jour par la source le 06/08/2026 · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
Booking.com Rooms API : compter les unités, décrire les lits et séparer les demandes supplémentaires
Une unité vendable peut contenir plusieurs pièces et configurations de lits. Le catalogue doit conserver ces niveaux au lieu de transformer toute quantité en nombre de chambres ou de couchages garantis.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Nombre d’unités | number_of_units indique la quantité d’unités de ce type dans l’établissement. | Ne l’utilisez pas comme nombre de chambres à coucher à l’intérieur d’un appartement ni comme disponibilité restante sur une date. |
| Pièces dans l’unité | configuration.rooms conserve les pièces et leur type ; la documentation distingue notamment chambre à coucher et salon. | Gardez le rattachement de chaque couchage à sa pièce : un couchage dans le salon ne décrit pas une chambre séparée. |
| Type et configuration de lits | bed_count est le nombre de lits du type indiqué ; is_default_configuration identifie la configuration par défaut. | Conservez la configuration avant de compter les lits. Ne cumulez pas comme simultanées deux dispositions présentées comme alternatives. |
| Lit supplémentaire et lit bébé | extra_beds et cribs décrivent des équipements disponibles sur demande. is_crib_and_extra_bed_allowed indique si les deux peuvent être demandés ensemble. | Ne promettez pas leur installation automatique ni leur cumul. Vérifiez l’accord de l’établissement et l’occupation autorisée pour le séjour. |
Deux quantités qui ne prouvent pas le couchage annoncé
Configurations fictives destinées à expliquer les champs, sans correspondance avec un hébergement réel.
Cinq appartements sont présentés comme cinq chambres dans un appartement
Une fiche fictive lit number_of_units: 5 alors que la configuration d’une unité décrit deux chambres à coucher et un salon.
number_of_units : 5
Composition d’une unité : deux chambres à coucher et un salon
Résumé erroné : appartement de cinq chambresLecture du cas. La valeur cinq porte sur la quantité d’unités de ce type dans l’établissement. Décrivez séparément les pièces d’une unité et les lits dans chacune ; ce champ ne donne pas non plus le stock restant pour le séjour.
Deux équipements sur demande sont additionnés comme acquis
Une configuration fictive indique un lit supplémentaire et un lit bébé, mais leur demande simultanée n’est pas autorisée dans le champ prévu.
extra_beds : 1
cribs : 1
is_crib_and_extra_bed_allowed : falseLecture du cas. Les deux quantités ne suffisent pas à promettre les deux équipements ensemble. Vérifiez le besoin du client, les règles d’occupation et la réponse de l’établissement pour la configuration retenue.
Périmètre : Rooms API de Booking.com Connectivity, consultée le 23 octobre 2026. Ces champs de description et de configuration ne constituent pas une réponse de disponibilité ou une confirmation d’installation pour un client. Ne transposez pas leurs noms à Demand API sans vérifier le modèle utilisé.
Booking.com Connectivity — Rooms API, Managing units · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
Sources et périmètre des faits documentés
La date de consultation figure avec chaque référence. Les méthodes d’essai et recommandations de ce guide sont éditoriales ; les conditions d’accès et d’usage se vérifient dans la documentation actuelle.
- Google Hotel Prices : Room Bundles : Distinction RoomData, PackageData, occupation et capacité dans cette interface ; pas une identité de chambre commune à toutes les sources. (consultée le )
- DGCCRF — Hôtels : droits et obligations des professionnels : Classement français volontaire, critères d’équipement, de confort et de services ; décision individuelle de classement valable cinq ans. (consultée le )
- Atout France — Classement des hébergements et distinction Palace : La distinction Palace suit une procédure propre parmi les hôtels classés cinq étoiles. (consultée le )
- Commission européenne — EU Ecolabel, hébergement touristique : Périmètre environnemental et validité des critères courants jusqu’au 31 décembre 2027 ; cette échéance ne constitue pas une preuve de certification d’un établissement. (consultée le )
- Booking.com Demand API 3.2 — Filtering and sorting : Filtres distincts pour les étoiles, le score d’avis et la certification de durabilité. L’extrait de filtre et les cas de contrôle sont éditoriaux. (consultée le )
- Mews Connector API — reservations/getAll/2023-06-06 : Limites propres à cette opération documentée ; elles ne décrivent pas toutes les API Mews ni les droits d’un contrat particulier. (consultée le )
- Google Hotel Prices — Pricing & Room Inventory, Transactions XML Reference : Périmètre : messages Transactions XML de Google Hotel Prices. Ce sont des règles d’intégration et de représentation des tarifs ; elles ne garantissent ni l’acceptation d’une famille par un hôtel ni les équipements de la chambre. (consultée le )
- Booking.com Connectivity — Rooms API, Managing units : Périmètre : Rooms API de Booking.com Connectivity, consultée le 23 octobre 2026. Ces champs de description et de configuration ne constituent pas une réponse de disponibilité ou une confirmation d’installation pour un client. Ne transposez pas leurs noms à Demand API sans vérifier le modèle utilisé. (consultée le )
Questions fréquentes
Questions utiles avant de décider
Deux chambres portant le même nom sont-elles identiques ?
Pas nécessairement. Comparez occupation, literie, superficie quand elle est fournie, accessibilité, vue, repas, conditions et prestations incluses. Le nom commercial seul ne constitue pas une preuve.
Quel identifiant garder après un changement de fournisseur ?
Gardez un identifiant interne stable pour l’établissement et une table de correspondance datée vers les identifiants de chaque source. Ne réutilisez pas un identifiant de chambre pour un produit devenu différent.
Comment contrôler un moteur de déduplication ?
Échantillonnez les rapprochements acceptés et refusés, particulièrement les hôtels voisins et les chambres aux noms proches. Mesurez séparément faux regroupements et doublons restants.
Une fusion de lieu valide-t-elle le mapping des chambres ?
Non. Identité du lieu et correspondance des catégories sont deux décisions avec leurs preuves propres.
Une note de 4,6 sur 5 peut-elle devenir un classement de 4,6 étoiles ?
Elle reste une note de voyageurs sur l’échelle de sa plateforme. Conservez sa source, son effectif et sa date. Le classement hôtelier et ses preuves se suivent séparément.
