Prix par jour ou par occupation ? L’impact de la connectivité sur votre stratégie de revenus (Partie 1)

In English, en español, em português.

Dans la distribution hôtelière, l’attention se porte généralement sur la stratégie de prix (« le quoi »), laissant au second plan l’architecture de connectivité (« le comment »). Cependant, la capacité à maximiser les revenus dépend directement de la technologie qui transporte ces prix.

Techniquement, il existe deux standards pour connecter l’écosystème hôtelier (RMS, PMS, Channel Manager et moteur de réservations) aux canaux de vente : PDP (Per Day Pricing- Prix par jour) et OBP (Occupancy Based Pricing-Prix par occupation). Aucun modèle n’est intrinsèquement supérieur ; ce sont deux voies distinctes pour atteindre un même objectif avec des implications opérationnelles différentes.

PDP (Per Day Pricing) : le modèle de prix basé sur des règles

Ce modèle est le standard historique de l’industrie, conçu pour optimiser l’efficacité opérationnelle et la transmission des données.

• Qu’est-ce que c’est exactement ? Il repose sur un système de « prix maître » : il existe un tarif principal (la base) et tous les autres prix pour les différentes occupations en dépendent. Ce ne sont pas des prix libres, car ils sont calculés automatiquement en suivant le premier.
• Comment cela fonctionne-t-il généralement ? L’hôtel envoie un prix unique (souvent celui de la chambre Double) depuis son système (PMS ou Channel Manager). À partir de là, c’est généralement le Channel Manager qui gère le calcul : il applique une règle fixe (par exemple : Base + 30 € ou Base – 10 %) pour générer automatiquement les prix de l’individuelle, de la triple ou des enfants. Dans certains cas, cette règle de calcul peut même être déléguée directement à l’extranet de l’OTA.

Pour comprendre la limitation du modèle PDP en ce qui concerne la saisonnalité, il est nécessaire d’observer comment opèrent les grandes plateformes.

1. Dans les Channel Managers : le modèle de prix par jour (PDP) est souvent géré de deux manières :

• Gestion Manuelle : contrôle total, mais gestion lente.

Vous décidez du prix exact pour chaque occupation (individuelle, double, triple). C’est très précis, mais si vous modifiez le prix principal, les autres ne se mettent pas à jour automatiquement, ce qui génère beaucoup plus de travail.

• Gestion Dérivée : rapidité, mais moins de flexibilité. 

C’est l’option la plus courante car elle fonctionne de manière automatique. Vous définissez un prix de base et le système calcule le reste selon une règle fixe (par exemple : « ajouter 30 € » ou « ajouter 10 % »). Le problème est qu’en s’agissant d’une règle rigide, elle ne s’adapte pas bien aux variations de la demande de chaque saison.

2. Et comment font les OTA ? Dans la plupart des cas, la configuration standard est conçue selon une règle de prix fixe (supplément ou réduction) qui ne varie pas automatiquement avec la demande saisonnière. Les OTA qui acceptent des suppléments saisonniers nécessitent généralement une gestion manuelle constante qui augmente la charge de travail opérationnelle.

C’est un exemple de la configuration des variations par occupation dans l’extranet d’une OTA. Le canal permet d’établir une occupation de base et une réduction fixe pour les occupations inférieures à l’occupation de base.

Bien qu’il existe des overrides (la capacité de surcharger manuellement un prix dérivé pour une date précise), tant dans les Channel Managers que dans les OTA, ceux-ci ne résolvent pas le problème structurel. Ils fonctionnent comme un correctif pour des exceptions ponctuelles, mais dépendre d’eux pour une stratégie de revenue dynamique obligerait à une surveillance constante, retombant ainsi dans  l’obligation d’un suivi permanent, ce qui est impossible à gérer manuellement.

• Où se décide le calcul ? C’est là que réside la clé. Bien que le prix de base provienne du PMS ou du Channel Manager, la règle de calcul est souvent déléguée au Channel Manager ou, selon le flux, au canal ou au moteur de réservations lui-même. S’il reste « séquestré » par les règles de l’extranet de l’OTA, cela limite le contrôle réel de l’hôtelier sur son propre prix final.

Les RMS les plus avancés sont conçus pour calculer les prix par occupation (OBP) de manière indépendante, mais ils sont souvent contraints d’exporter au format PDP en raison des limitations de l’écosystème (PMS ou Channel Manager). En définitive : votre stratégie de revenue sera toujours limitée par le maillon le plus faible de votre chaîne de connectivité.

• Le grand avantage des tarifs dérivés est l’efficacité : vous gérez un prix unique et le reste se met à jour automatiquement en cascade. Cependant, l’erreur classique est de vouloir « forcer » le modèle : si vous finissez par créer autant de tarifs et de régimes qu’il existe d’occupations, vous détruisez cette efficacité et vous vous retrouvez avec un système ingouvernable, tout en gardant la même rigidité qu’auparavant.
• Quelles sont ses limites ?

Mapping lors de la descente des réservations. En déléguant le calcul du prix au canal ou au Channel Manager, le « voyage de retour » de la réservation est plus complexe.

L’effet de chaîne et sa mauvaise nouvelle : en modifiant le prix de base, vous entraînez tous les autres sans le vouloir. Comme ces règles sont généralement fixes (par exemple, le même supplément de 30 € pour toute l’année), vous ne pouvez pas vous adapter à la demande réelle de chaque saison. Si vous voulez augmenter le prix de la triple, vous êtes obligé d’augmenter également celui de la double.

OBP (Occupancy Based Pricing) : un prix indépendant pour chaque occupation

Ce modèle représente l’évolution vers la granularité de la donnée, traitant chaque occupation comme un produit indépendant.

• Que représente ce modèle ? Il rompt la hiérarchie des prix dérivés. Chaque occupation a son propre prix final, unique et déconnecté des autres.
• Comment fonctionne ce modèle ? Le système n’envoie pas d’instructions de calcul (« Base + 40 € »), mais des données absolues : « Individuelle : 90 € », « Double : 100 € », « Triple : 130 € ».

• Qui a le contrôle du prix final ? Il réside dans le système qui génère le prix (RMS, Channel Manager ou PMS avancé), et est transporté de manière explicite. Néanmoins, ces prix naissent souvent de calculs linéaires à l’origine.

Cependant, il existe une différence cruciale dans la capacité d’intervention du canal :

• Dans le modèle OBP, les grandes plateformes (OTA) se contentent d’afficher le prix exact que vous leur envoyez, sans effectuer de calculs de leur côté. Cela garantit que le client voit exactement ce que vous avez décidé dans votre système.
• Le moteur de réservations comme dernier mot : un moteur de réservations avancé permet d’intervenir. Il peut agir en surchargeant la logique d’occupation reçue, remplaçant les incréments linéaires du PMS ou du Channel Manager pour s’adapter aux courbes dynamiques de la demande.

Le défi du RMS : les RMS peuvent calculer et envoyer tous ces prix finaux, mais ils nécessitent un mapping exhaustif de toutes les occupations pour que la stratégie s’exécute correctement.

• Quels sont les avantages de ce modèle ? Le contrôle et la granularité. Permet de définir des stratégies spécifiques pour chaque occupation (élasticité indépendante) avant la distribution.
• Quelle est la principale limite ? La densité des données et le mapping. Cela exige une technologie capable de traiter un volume d’informations beaucoup plus important, car chaque occupation nécessite son propre identifiant unique (Rate ID). C’est comme passer de la gestion d’une seule clé pour une chambre à la gestion d’une clé différente pour chaque personne qui y entre. Si le canal n’est pas nativement OBP, cela oblige à créer des « tarifs miroirs » qui peuvent saturer la gestion de l’inventaire.

Quelle charge de travail supplémentaire chaque modèle implique-t-il ?

La différence réside dans le volume de données à superviser :

• En PDP (Gestion par exception) et en utilisant des tarifs dérivés : vous supervisez 10 prix de base (pour un hôtel de 10 typologies). Les variations s’appliquent seules.
• En OBP (Gestion par produit) : vous supervisez 10 chambres x 4 occupations = 40 prix finaux indépendants.

L’effet multiplicateur : ce nombre peut croître de manière combinatoire en le croisant avec les différents régimes (Logement Seul, Petit-déjeuner inclus, Demi-pension) et politiques d’annulation (Flexible, Non Remboursable).

La balance opérationnelle 

Scénario : hôtel de 10 typologies x 4 occupations x 2 régimes x 2 conditions d’annulation :

Le risque de la fausse agilité

Sans automatisation, la granularité de l’OBP devient une vulnérabilité opérationnelle. La probabilité d’erreur humaine rend le contrôle manuel irréalisable. 

De nombreux hôtels tentent « d’échapper » à la rigidité du PDP en créant des dizaines de tarifs indépendants dans leur PMS. Le résultat est le pire des deux mondes :

• Ils perdent l’agilité du PDP (la mise à jour en cascade ne se fait plus).
• Ils ne gagnent pas l’intelligence de l’OBP (ils n’ont toujours pas de vision par occupation).
• Hypertrophie de l’inventaire : des centaines de tarifs à mapper et à superviser un par un.

Tableau comparatif des architectures

Pourquoi le modèle traditionnel reste-t-il le plus utilisé ?

Bien que le système par occupation (OBP) soit plus précis, le modèle de prix par jour (PDP) demeure le plus courant par pure praticité :

• Habitude et stabilité : pendant des années, on a privilégié une connexion rapide et sans erreurs plutôt que de rentrer dans le détail de chaque prix.
• Conception des canaux : les grandes plateformes (comme Booking ou Expedia) sont conçues pour que ce modèle fonctionne bien. Pour la majorité des hôtels, c’est une solution robuste et facile à gérer, tandis que le modèle par occupation reste l’étape suivante pour ceux qui recherchent une précision totale.

Exemple réel : l’argent que vous ne gagnez pas à cause d’une technologie rigide

Hypothèse : Chambre Double à 300 € en haute saison

• Scénario A : modèle PDP (règle statique) Le supplément pour la 3e personne est fixe dans le Moteur/Canal (+ 30 €).

– Prix Final Triple : 330 €

– Conséquence : pour augmenter la Triple, vous devriez augmenter la Double et vous perdriez en compétitivité. Ou pire : vous seriez obligé de fermer la vente de la chambre triple pour ne pas brader, perdant de l’occupation totale simplement à cause de la rigidité du système.

• Scénario B : modèle OBP (Stratégie dynamique). Une forte demande familiale est détectée. La Triple est fixée à 375 €, en gardant la Double intacte.

– Prix Final Triple : 375 €

– Conséquence : Une valeur supplémentaire de 45 € par chambre/nuit est capturée.

Projection financière : 

En supposant une occupation moyenne de 100 % et en extrapolant cette différence à un inventaire de 20 chambres pendant 60 jours de haute saison, le différentiel de revenus bruts s’élève à 54 000 €. Dans le modèle PDP, ce revenu n’est pas capturé en raison de la limitation de la règle générale ; en OBP, il est le résultat direct d’une décision de tarification ponctuelle. Et plus important encore, en PDP, en augmentant le prix de la triple, il se peut que vous vous « sortiez du marché » pour la double (qui est celle qui se vend généralement le mieux).

Et ceci n’est que pour une typologie, la marge est exponentielle si l’on tient compte du reste des occupations, régimes, tarifs…

L’équilibre entre architecture et stratégie

Au final, le choix entre PDP et OBP n’est pas une question de savoir quelle technologie est la meilleure, mais de quel niveau de granularité l’opérationnel de l’hôtel peut absorber sans perdre le contrôle. Alors que le PDP offre un environnement de gestion simplifiée et agile, l’OBP ouvre la porte à une segmentation précise par occupation.

La question clé pour l’hôtelier aujourd’hui n’est pas seulement de savoir lequel choisir, mais comment surmonter la barrière technique qui les sépare : est-il possible d’atteindre la précision des revenus de l’OBP avec l’agilité opérationnelle du PDP ? Pouvons-nous automatiser la complexité pour qu’elle cesse d’être un frein ?

Dans la deuxième partie, nous analyserons comment la connectivité évolue pour intégrer les deux philosophies et éliminer la friction entre le chargement des données et la stratégie de revenue.