Occupation des chambres : l'erreur de configuration qui bloque vos ventes sur Booking, Expedia et Airbnb

Un hôtelier configure sa première chambre familiale dans son channel manager. « Maximum 4 personnes, toutes combinaisons possibles » : il tape logiquement 2 dans le champ adultes, 2 dans le champ enfants. Ça paraît juste — 2 adultes, 2 enfants, 4 personnes. Trois mois plus tard, il ne comprend pas pourquoi aucun groupe de 4 adultes ne trouve jamais cette chambre, ni pourquoi il est incapable d'afficher un tarif pour 3 personnes.

C'est l'erreur de configuration la plus fréquente sur les types de chambre, et elle ne reste jamais confinée à un seul endroit : dès que le type de chambre est mappé, elle se propage automatiquement vers Booking.com, Expedia, Agoda, Airbnb, Hotelbeds et tous les autres canaux connectés.

Trois champs qui décrivent des couchages, pas des personnes

La confusion vient d'une intuition trompeuse. On lit « occ_adults » et « occ_children » et on y voit une répartition théorique de voyageurs — comme si on décrivait qui a le droit de dormir dans la chambre. Ce n'est pas ça. Ces champs décrivent des lits, des couchages physiques, indépendamment de l'âge de la personne qui les occupe. Un enfant qui dort dans un lit double occupe un couchage adulte, un point c'est tout.

Champ	Ce qu'il représente	Piège fréquent
occ_adults	Le nombre maximum de personnes, tous âges confondus, pouvant dormir dans la chambre	Le confondre avec « nombre d'adultes » dans une répartition type
occ_children	Les couchages réservés exclusivement à un enfant (couchette étroite, lit d'appoint enfant), en plus de occ_adults	L'utiliser pour dire « la chambre accepte des enfants » — les enfants dorment déjà dans les lits adultes
occ_infants	Le nombre de lits bébé réellement installables — 0 ou 1 dans la grande majorité des cas	Déclarer un nombre supérieur à ce que la chambre peut physiquement accueillir

La capacité totale vendue à un canal, c'est occ_adults + occ_children. Les berceaux s'ajoutent par-dessus sans consommer de couchage. Retenez cette addition, tout le reste en découle.

L'erreur la plus fréquente, en pratique

Reprenons la chambre familiale « 4 personnes, toutes combinaisons ». La bonne configuration met toute la capacité dans occ_adults :

	occ_adults	occ_children	Résultat
Correct	4	0	Accepte 1 à 4 personnes, quelle que soit la répartition adultes/enfants
Incorrect	2	2	Le canal comprend 2 adultes + 2 couchages enfant en plus — jamais 3 ou 4 adultes

Avec la seconde ligne, une famille de 2 adultes et 2 enfants trouve bien la chambre. Un groupe de 4 adultes, non : le canal ne lui propose tout simplement pas cette chambre, puisqu'elle n'est déclarée capable d'accueillir que 2 adultes. Et aucun tarif à 3 ou 4 personnes ne peut exister, pour la raison qu'on verra plus loin.

La règle qui évite ce piège tient en une phrase : n'utilisez occ_children que si un lit précis, en plus des lits adultes, ne peut physiquement accueillir qu'un enfant — une couchette intégrée, par exemple, où un adulte ne rentre pas. Dans tous les autres cas, la capacité entière va dans occ_adults et occ_children reste à 0.

Quatre questions pour trouver vos valeurs

1. Combien de personnes peuvent dormir dans la chambre, tout âge confondu ? C'est votre occ_adults.
2. Existe-t-il un lit supplémentaire qu'un adulte ne peut pas utiliser ? Si non, occ_children reste à 0. Si oui, occ_children compte ces lits-là précisément.
3. Combien de berceaux pouvez-vous installer sans encombrer la chambre ? C'est occ_infants — presque toujours 0 ou 1.
4. Combien de personnes la chambre accueille-t-elle sans lit d'appoint déployé ? C'est default_occupancy, qui doit toujours rester inférieure ou égale à occ_adults.

Ce que ces valeurs verrouillent en aval

occ_adults n'est pas qu'une case administrative : elle plafonne directement vos options tarifaires. Un plan « par personne » propose une ligne de prix par nombre d'occupants — 1, 2, 3... — et ce nombre de lignes ne peut jamais dépasser occ_adults. Avec occ_adults à 1, une seule ligne existe, et il devient impossible de facturer différemment 2 ou 3 personnes, même si la chambre les accueille physiquement.

Deuxième point à connaître avant de connecter un canal : réduire occ_adults ou occ_children après qu'une option d'occupation a été mappée est refusé par défaut. Il faut alors forcer l'opération — ce qui supprime définitivement l'option et les mappages associés sur le canal concerné. Augmenter une capacité est simple ; la réduire ne l'est pas. Réglez donc ces champs correctement avant, pas après, la connexion aux canaux.

Dernier point de clarification : les suppléments enfant et bébé ne se règlent pas sur le type de chambre. Ils vivent sur le plan tarifaire, et les seuils d'âge qui déterminent leur application sont définis dans l'extranet de chaque canal — Keral, comme la plupart des channel managers, ne stocke aucune tranche d'âge. Les champs du type de chambre ne décrivent que des couchages.

Ce que chaque canal en fait

Chaque canal projette votre configuration à sa manière, mais une règle gouverne l'ensemble : la capacité déclarée doit toujours être supérieure ou égale à l'occupation attendue par le canal, et le nombre d'options d'occupation disponibles reste plafonné par occ_adults.

Canal	Ce qu'il faut surveiller
Booking.com	Mapping par occupation : chaque ligne doit être mappée, et une seule option doit porter le marqueur « tarif principal », celui qui reçoit les restrictions.
Agoda	Mapping toujours multi-occupation. Une ligne non mappée bloque la vente sur cette occupation précise.
Expedia	Pas de grille d'occupation dans l'écran de mapping : la capacité maximale côté Expedia doit correspondre à occ_adults + occ_children, sous peine de survente ou d'invisibilité.
Airbnb	Un seul plan mappable ; la capacité de l'annonce doit refléter occ_adults + occ_children, et le tarif par voyageur supplémentaire se règle ensuite dans l'annonce elle-même.
Hotelbeds	L'occupation est portée par le contrat ; la capacité déclarée doit rester cohérente avec lui, faute de quoi certains tarifs contractuels refusent purement et simplement le prix.

Dans tous les cas, la séquence à suivre après une correction est la même : corriger le type de chambre, compléter la grille d'options tarifaires jusqu'au nouveau occ_adults, aligner la capacité dans l'extranet de chaque canal, puis rouvrir la page de mapping — les nouvelles lignes d'occupation apparaissent et attendent d'être mappées.

Ce que Keral ne gère pas

Trois limites à garder en tête pour ne pas chercher un réglage qui n'existe pas au mauvais endroit. Aucune tranche d'âge n'est stockée : les seuils enfant/bébé se paramètrent canal par canal, dans chaque extranet. Aucune règle de composition du type « 2 adultes maximum parmi 4 personnes » n'est modélisable — Keral ne décrit que des couchages, jamais des combinaisons. Et aucune capacité côté canal n'est mise à jour automatiquement : le channel manager transmet prix, disponibilités et restrictions, mais la capacité déclarée dans chaque extranet reste de la responsabilité de l'hôtelier, et doit être alignée manuellement.

Pour aller plus loin sur le choix de votre channel manager et l'impact d'une bonne stratégie multi-canal, retrouvez notre guide pour choisir un channel manager et notre article sur la construction d'un channel mix efficace.

Annexe : faire faire la configuration par une IA

Tout ce qui précède se laisse déléguer. La section ci-dessous rassemble les règles, le format d'entrée et le prompt prêt à copier pour qu'un assistant IA (Claude, ChatGPT ou autre) traite votre parc de chambres à votre place — sans jamais deviner en silence : chaque hypothèse est écrite noir sur blanc, chaque information manquante devient une question avant qu'aucune écriture ne soit proposée.

Mode d'emploi : copiez le prompt de la dernière sous-section dans votre assistant, collez à la suite votre liste de chambres au format indiqué, et laissez-le travailler. Il vous rendra un bloc par chambre avec les valeurs cibles et la requête API correspondante, jamais l'inverse : c'est vous qui validez avant toute écriture.

Les dix règles qu'elle doit appliquer

#	Règle
R1	occ_adults = nombre total de personnes pouvant dormir dans la chambre, tous âges confondus. Un enfant occupe un couchage adulte.
R2	occ_children = couchages utilisables exclusivement par un enfant, en supplément de occ_adults. Par défaut : 0.
R3	occ_infants = nombre de lits bébé installables. En pratique 0 ou 1. Ne consomme pas de couchage.
R4	Capacité totale annoncée aux canaux = occ_adults + occ_children.
R5	default_occupancy ≤ occ_adults. Contrainte dure : toute violation est refusée à l'enregistrement.
R6	Les options d'un plan tarifaire sont exprimées en nombre d'occupants et plafonnées par occ_adults. occ_children ne crée aucune option tarifaire.
R7	Ne jamais répartir une capacité en « X adultes + Y enfants » pour une chambre familiale polyvalente : toute la capacité va dans occ_adults.
R8	Réduire occ_adults ou occ_children après mappage à un canal échoue ; forcer l'opération détruit les mappages existants. Configurer avant de connecter les canaux.
R9	Les tarifs enfant/bébé (children_fee, infant_fee) sont des champs du plan tarifaire, jamais du type de chambre.
R10	Aucune tranche d'âge n'est stockée côté type de chambre : les seuils adulte/enfant/bébé sont définis dans l'extranet de chaque canal.

Ce qu'il faut lui fournir

Une IA n'a besoin que de deux informations par chambre : la capacité maximale en personnes, et la nature des lits (existe-t-il un couchage qu'un adulte ne peut pas occuper). Le reste s'en déduit. Le format le plus efficace est une ligne par chambre :

titre | identifiant | lits | capacité max | berceau : oui/non | unités

Familiale Supérieure | 152492411 | 1 double + 2 simples | 4 | oui | 4
Triple Comfort        | 152492410 | 1 double + 1 simple  | 3 | oui | 3

Si la configuration des lits est inconnue, l'IA doit poser occ_children = 0 par hypothèse et le signaler explicitement — jamais l'inverse. Si la capacité maximale elle-même est inconnue ou contradictoire, elle doit vous poser la question plutôt que de deviner.

Le format de réponse à exiger

Demandez un bloc par chambre, sans prose autour :

CHAMBRE   : <titre> (<id>)
CONFIANCE : CERTAIN | DEDUIT | MANQUANT
ACTUEL    : occ_adults=? occ_children=? occ_infants=? default=?
CIBLE     : occ_adults=? occ_children=? occ_infants=? default=?
DELTA     : AUCUN | AUGMENTATION | REDUCTION (confirmation requise)
HYPOTHESE : <une ligne, ou "aucune">
PAYLOAD   : PUT /room_types/<id> { occ_adults, occ_children, occ_infants, default_occupancy }

Trois garde-fous à faire respecter par l'assistant : jamais de occ_children > 0 sans lit exclusivement enfant documenté, jamais de occ_infants > 1 sans déclaration explicite, et aucune requête envoyée avant votre validation — l'IA produit les payloads, vous les exécutez.

Le prompt prêt à copier

Tu configures l'occupation de types de chambre pour un channel manager,
selon les dix règles suivantes :

R1. occ_adults = nombre total de personnes pouvant dormir dans la chambre,
    tous âges confondus. Un enfant occupe un couchage adulte.
R2. occ_children = couchages exclusivement enfant, en plus de occ_adults.
    Par défaut : 0.
R3. occ_infants = nombre de lits bébé installables (0 ou 1 en pratique).
R4. Capacité totale = occ_adults + occ_children.
R5. default_occupancy doit toujours être <= occ_adults.
R6. Les options tarifaires par occupation sont plafonnées par occ_adults ;
    occ_children n'en crée aucune.
R7. Ne jamais répartir une capacité familiale en "X adultes + Y enfants" :
    toute la capacité va dans occ_adults, sauf lit exclusivement enfant
    documenté.
R8. Réduire une valeur déjà mappée à un canal détruit ce mappage : à
    signaler, jamais à exécuter sans confirmation.
R9. children_fee et infant_fee vivent sur le plan tarifaire, pas sur la
    chambre.
R10. Aucune tranche d'âge ne se règle ici : c'est l'affaire de chaque canal.

Pour chaque chambre que je te fournis, rends un bloc :
CHAMBRE / CONFIANCE (CERTAIN, DEDUIT ou MANQUANT) / ACTUEL / CIBLE /
DELTA / HYPOTHESE / PAYLOAD.

Ne devine rien en silence : toute hypothèse est explicite, toute
information manquante devient une question avant tout payload. N'exécute
aucune requête, tu produis les payloads, je les valide.

Voici mes chambres (titre | identifiant | lits | capacité max |
berceau : oui/non | unités) :

[coller ici la liste des chambres]

---

FAQ

Que représentent exactement occ_adults, occ_children et occ_infants ?

Des couchages, pas des personnes. occ_adults est le nombre maximum de personnes pouvant dormir dans la chambre, tous âges confondus. occ_children ne compte que les lits réservés exclusivement à un enfant, en plus de occ_adults. occ_infants compte les berceaux installables, sans consommer de couchage.

Pourquoi mon plan tarifaire n'affiche-t-il qu'une seule option de prix ?

Parce que occ_adults plafonne le nombre de lignes d'occupation disponibles. Avec occ_adults à 1, une seule ligne existe et aucun prix différencié pour 2 ou 3 personnes n'est possible, même si la chambre les accueille réellement.

Puis-je réduire ces valeurs après avoir connecté un canal ?

Pas directement : l'opération est refusée si une option est déjà mappée. Il faut forcer la modification, ce qui supprime définitivement l'option et les mappages du canal concerné. D'où l'intérêt de régler ces champs correctement avant de connecter vos canaux.

Où se règlent les suppléments enfant et bébé ?

Sur le plan tarifaire (children_fee, infant_fee), jamais sur le type de chambre. Les seuils d'âge qui déclenchent ces suppléments sont eux-mêmes définis dans l'extranet de chaque canal — Keral ne stocke aucune tranche d'âge.