RMS et PMS : le Revenue Management doit-il devenir une simple fonctionnalité du PMS ?

Faut-il choisir un RMS natif du PMS, ou rester sur un RMS indépendant ? La question revient de plus en plus alors que plusieurs PMS lancent leur propre module de Revenue Management. Ce n’est pas qu’une question de fonctionnalités : c’est un choix qui engage la vitesse d’innovation, la vision produit et, au fond, la qualité des recommandations tarifaires que reçoit l’hôtelier. Voici les trois scénarios possibles, et pourquoi l’intégration ne veut pas dire consolidation. 

Le retour d’un débat déjà connu dans l’Hotel Tech 

Je réfléchis beaucoup à cette question ces derniers temps. Pas parce que je pense que les PMS ne devraient pas développer leur propre Revenue Management. Ils devraient le faire, de leur point de vue. Et pas non plus parce que je pense que les RMS indépendants devraient être protégés de la concurrence. Bien au contraire. La concurrence est saine. Mais quand je regarde ce qui se passe dans l’Hotel Tech, je ne peux pas m’empêcher de penser que nous sommes peut-être en train de rejouer une histoire que nous avons déjà connue. 

Certains PMS viennent récemment d’annoncer leur propre Revenue Management System. Et cela m’a fait réfléchir un instant, parce que le sujet dépasse largement le lancement d’un nouveau module par un PMS. 

Pendant des années, l’Hotel Tech a évolué dans une direction : la spécialisation. Nous avons créé des systèmes dédiés à la distribution, au CRM, à la réputation, à l’upselling, à la Business Intelligence et, bien sûr, au Revenue Management. Puis est arrivée l’ère de l’intégration. Les APIs ont permis à tous ces spécialistes de travailler ensemble. 

Aujourd’hui, le mouvement semble repartir dans l’autre direction. Les PMS ajoutent de plus en plus de fonctionnalités à leur propre plateforme. Et le Revenue Management est l’une des fonctionnalités les plus stratégiques, et potentiellement les plus valorisables, à intégrer directement au sein de la plateforme. 

Alors je reviens toujours à la même question : le RMS va-t-il devenir une simple fonctionnalité du PMS ? 

Je ne pense pas que la réponse soit aussi simple qu’un « oui » ou un « non ». Parce qu’il existe trois manières très différentes d’imaginer le futur du Revenue Management. 

Construire : quand le RMS devient une fonctionnalité du PMS

La logique est difficile à contester. Le PMS sait déjà ce qui se passe dans l’hôtel. Il connaît les réservations, l’inventaire, l’occupation, le rythme des réservations, les types de chambres et les canaux. Alors pourquoi un système séparé devrait-il récupérer toutes ces informations avant de faire une recommandation tarifaire ? 

Un RMS natif peut réduire la distance entre la donnée, la décision et son exécution. Pour beaucoup d’hôtels, c’est une proposition très attractive. Une plateforme. Une interface. Un contrat. Une intégration de moins à maintenir. 

Et il y a un avantage encore plus important : un RMS simple et intégré peut rendre le Revenue Management accessible à des hôtels qui n’auraient jamais investi dans une solution standalone sophistiquée. 

C’est une vraie bonne chose pour l’industrie. Mais il y a un autre côté à l’histoire : un PMS a beaucoup de choses à faire. Le Revenue Management, lui, en a une. Et un RMS n’est pas une fonctionnalité que l’on construit une fois avant de passer à autre chose. 

Le Revenue Management évolue en permanence. Les données changent. Les modèles changent. La distribution change. Les comportements des clients changent. L’IA change ce qu’il est possible de faire. Le meilleur RMS de demain ne sera pas simplement celui qui possède la plus longue liste de fonctionnalités. Ce sera celui qui continue à progresser. Nous connaissons tous des RMS qui ont été progressivement écartés du marché parce qu’ils n’ont pas su innover en continu. 

C’est la première question que je me poserais lorsqu’un RMS devient un module parmi beaucoup d’autres dans un PMS : recevra-t-il le même niveau d’attention lorsque les priorités commenceront inévitablement à entrer en concurrence ? 

Nous avons déjà vu une évolution similaire avec les Channel Managers. Et c’est précisément pour cela que je pense que la question mérite d’être posée avant de considérer que le natif est nécessairement meilleur.

Acheter : quand le spécialiste rejoint un groupe

Deuxième modèle : l’acquisition. 

Plutôt que de construire un RMS de zéro, un PMS ou un groupe plus large d’Hotel Tech peut simplement en acheter un. Là encore, la logique est séduisante. On achète une technologie qui a demandé des années de développement. On achète une expertise. On achète des clients. On gagne en taille et en puissance de distribution. Le spécialiste bénéficie de davantage de ressources. Le groupe récupère un produit qui a déjà fait ses preuves. 

Tout le monde peut y trouver son compte. 

Mais une acquisition change aussi quelque chose que l’on sous-estime facilement : qui possède la vision produit ? 

Un RMS indépendant peut commencer chaque journée avec une question relativement simple : comment rendre le Revenue Management meilleur ? 

Une fois intégré dans un portefeuille plus large, les questions deviennent différentes. Comment cela s’intègre-t-il au PMS ? Que doit-on construire de manière centralisée ? Où doit-on investir ? Quel produit doit porter telle fonctionnalité ? Jusqu’où le RMS doit-il aller par rapport aux autres produits du portefeuille ? 

Aucune de ces questions n’est nécessairement mauvaise. En réalité, un groupe plus important peut donner à un RMS davantage de ressources et accélérer son développement. Mais la logique est différente. On n’optimise plus uniquement un produit. On optimise un portefeuille. 

Et lorsqu’on rachète un spécialiste, on ne rachète pas seulement sa technologie. On rachète aussi sa vision, sa culture et sa manière de prendre des décisions produit. 

La vraie question est alors de savoir ce qu’il advient de tout cela avec le temps. 

Rester indépendant : mais être connecté partout

Il existe une troisième voie. Le RMS reste indépendant. Pas isolé. Indépendant. 

La nuance est importante. Pendant longtemps, le principal argument contre les technologies spécialisées était l’intégration. Les hôtels se retrouvaient avec trop de systèmes, trop d’interfaces et trop de fournisseurs. 

Cette critique était légitime. Mais je ne pense pas que la réponse soit nécessairement de tout mettre sous le même toit. L’autre possibilité consiste à faire beaucoup mieux fonctionner ensemble des systèmes indépendants. 

Mais il y a une autre idée reçue qu’il me semble important de challenger : indépendant ne veut pas dire « petit ». 

Les financements existent. Un spécialiste peut avoir les moyens de construire un produit solide, d’investir dans la technologie et de se développer à l’international sans appartenir à un groupe plus important. 

Et la taille ne garantit pas non plus une meilleure qualité d’exécution. Dans certains cas, la relation peut même être inverse : plus une organisation devient grande, plus elle ajoute de couches, de process et de dépendances, plus il peut devenir difficile d’avancer rapidement. 

Être indépendant peut simplement vouloir dire être concentré. Concentré à 100 % sur un métier. Du premier message marketing, à la compréhension du projet par les équipes Sales, et surtout dans le déploiement, l’Account Management et la compréhension des évolutions du métier. 

Et cela compte particulièrement en Revenue Management, parce que la technologie ne peut pas rester immobile. L’innovation n’est pas un événement ponctuel. C’est une nécessité permanente. Beaucoup des mécanismes décrits par les théories économiques de l’innovation vont d’ailleurs dans le même sens : la spécialisation, la concentration et la capacité à expérimenter peuvent être de puissants moteurs d’innovation. 

Pour un RMS, cette capacité à rester proche du métier peut finalement être plus importante que la taille de l’entreprise qui se trouve derrière. 

Le PMS reste le système opérationnel. Le RMS reste la couche d’intelligence Revenue. Le Channel Manager reste la couche de distribution. Et les données circulent entre eux. 

L’hôtelier ne devrait pas avoir à se demander quelle entreprise possède quelle brique technologique. Il devrait simplement se demander si la technologie fonctionne. Les données arrivent-elles au bon endroit ? Les recommandations sont-elles disponibles au bon moment ? Les décisions sont-elles renvoyées dans les systèmes opérationnels ? Et, de plus en plus, les actions peuvent-elles être automatisées ? 

L’objectif n’est pas d’avoir plus de logiciels. L’objectif est d’avoir moins de friction.

L’intégration n’est pas la consolidation 

C’est probablement la distinction la plus importante de toute cette discussion. 

On confond souvent intégration et consolidation. Ce n’est pas la même chose. 

La consolidation consiste à réunir des produits, des entreprises ou des fonctionnalités sous une même propriété. L’intégration consiste à faire fonctionner différents systèmes ensemble. On peut avoir un seul fournisseur avec cinq produits qui restent mal connectés. Et on peut avoir plusieurs fournisseurs spécialisés qui fonctionnent comme un seul écosystème. 

Alors peut-être que la bonne question pour les hôtels n’est pas : combien de fournisseurs ai-je ? 

Mais plutôt : combien de friction ai-je ? 

Cela change complètement la discussion. 

Parce que si un RMS spécialisé est profondément intégré au PMS, si les données circulent automatiquement et si les décisions peuvent être exécutées sans étapes inutiles, est-ce vraiment important que les deux produits appartiennent à des entreprises différentes ? 

Je ne le pense pas. 

Le Revenue Management est un cas particulier

Cette question est particulièrement importante pour le RMS parce que le Revenue Management est un métier qui ne peut pas se permettre de rester immobile. J’ai passé suffisamment de temps autour du Revenue Management pour savoir que le métier évolue en permanence. Ce qui fonctionnait il y a cinq ans ne suffit pas forcément aujourd’hui. Et ce qui fonctionne aujourd’hui ne suffira probablement pas dans cinq ans. 

Mais au fond, nous cherchons toujours à répondre à la même question : pour cette date et cette unité, ai-je besoin de Volume ou d’ADR ? 

Et si le concepteur, l’éditeur du RMS ne se pose même pas correctement cette question, alors vous pouvez ajouter toutes les données que vous voulez, multiplier les intégrations ou intégrer le RMS nativement dans un PMS : vous ne permettrez toujours pas à l’utilisateur de bénéficier de toute l’intelligence de votre plateforme. 

L’IA ne change pas la manière dont nous faisons nos analyses. Les mathématiques restent les mathématiques. Elle change en revanche notre capacité à passer à l’échelle et à automatiser. 

Les équipes Revenue attendent davantage de transparence. Les hôtels veulent plus d’automatisation, mais ils veulent aussi comprendre pourquoi une décision a été prise. 

Pour un RMS indépendant, cette pression est intense. Mais il y a quelque chose de sain dans cette pression. Un RMS indépendant a une raison d’exister très claire : rendre le Revenue Management meilleur. 

S’il cesse de le faire, les hôtels ont finalement peu de raisons de continuer à l’utiliser. Cela crée une incitation très forte à continuer d’investir, d’expérimenter et d’évoluer. 

Pour moi, c’est l’un des arguments les plus forts en faveur de la spécialisation. Pas parce qu’un spécialiste est automatiquement meilleur. Mais parce que sa survie dépend de sa capacité à rester à la pointe de son métier. 

Et puis arrive la prochaine couche d’intégration 

Pendant les dix dernières années, nous avons essentiellement parlé d’APIs. Les APIs ont changé l’Hotel Tech. Elles ont permis de construire un écosystème plutôt qu’un immense logiciel unique. Mais une nouvelle couche commence aujourd’hui à émerger. 

Les agents IA et des protocoles comme MCP pourraient changer la manière dont les logiciels interagissent entre eux. 

L’enjeu n’est plus simplement de faire passer une donnée de A à B. Il s’agit de donner à un système accès au bon contexte, à la bonne expertise et aux bonnes actions. 

Imaginez un agent IA qui analyse la situation actuelle d’un hôtel. Il peut accéder au contexte opérationnel depuis le PMS. Il peut demander au RMS pourquoi la demande a changé. Il peut comprendre la recommandation. Il peut l’expliquer au Revenue Manager. Et, lorsqu’il y est autorisé, il peut exécuter la décision. 

Vous venez d’imaginer Revbell aujourd’hui et demain. 

Dans ce monde, le RMS n’a pas besoin de devenir le PMS. Il doit être extrêmement bon en Revenue Management et capable de rendre cette expertise disponible au reste de l’écosystème. C’est une vision très différente de l’intégration. 

Alors, le RMS va-t-il devenir une simple fonctionnalité du PMS ? 

Pour certains hôtels, peut-être. 

Un RMS natif peut rendre le Revenue Management plus simple, plus accessible et plus facile à utiliser. C’est une vraie valeur. Mais cela ne signifie pas que tous les RMS doivent devenir des fonctionnalités du PMS. 

Il y aura toujours des hôtels pour lesquels le Revenue Management est trop stratégique, trop complexe et trop dynamique pour être traité comme une simple case à cocher. Et je pense que c’est là que le marché se dirige vers un équilibre intéressant. 

Le PMS peut gérer le workflow opérationnel. Le RMS peut gérer l’intelligence Revenue. Le Channel Manager peut gérer la distribution. 

Les spécialistes peuvent rester spécialistes. Et la technologie peut faire en sorte que l’ensemble ressemble à une seule plateforme. 

C’est le modèle auquel nous croyons chez Revbell 

Chez Revbell, nous avons choisi de rester un spécialiste. Pas parce que nous pensons que les hôtels ont besoin de davantage de systèmes. Bien au contraire. 

Nous pensons que le Revenue Management mérite une entreprise dont l’attention est entièrement consacrée au Revenue Management. 

Mais être spécialiste ne signifie pas être déconnecté. Notre RMS est, et doit rester, profondément connecté au PMS. Il doit récupérer automatiquement les bonnes données. Il doit renvoyer les décisions directement dans le workflow opérationnel. 

Et il doit continuer à évoluer au rythme du métier. 

Pour nous, l’indépendance ne consiste pas à rester à l’écart de l’écosystème. Elle consiste à avoir la liberté de continuer à faire progresser un métier. 

Independent by design. Integrated by default. 

Peut-être que c’est cela, finalement, l’avenir de l’Hotel Tech. Pas une plateforme qui fait tout. Pas une collection de spécialistes déconnectés. Mais un écosystème dans lequel chaque composant peut être excellent dans son domaine, tout en donnant à l’hôtelier l’impression d’utiliser une seule stack technologique cohérente. 

Et pour le Revenue Management, je pense que cette distinction va devenir de plus en plus importante.