Reporting du parc en direct

Dans le secteur de l'hôtellerie-restauration, la plupart des rapports destinés au conseil d'administration reposent sur une présentation préparée le mardi matin par un analyste financier, résumant les événements de la semaine précédente. Les données sont fiables, la mise en forme est cohérente, l'analyste est compétent. Le problème est que, lorsque quelqu'un en prend connaissance, la réalité opérationnelle qu'elle décrit date déjà d'une semaine.

Pour un exploitant mono-site, cela ne pose pas de problème. Ce bilan vieux d'une semaine est suffisamment détaillé pour prendre des décisions pour la semaine suivante. Pour un exploitant multi-site gérant 50, 200 ou 1 000 établissements, une vision datant d'une semaine devient un risque stratégique. Les décisions sont prises sur des données obsolètes parce que l'écosystème logiciel est incapable de produire des données fraîches sans l'intervention de cet analyste.

Cet article présente ce à quoi ressemble un reporting à l'échelle de tout un parc lorsque le tableau de bord de la direction n'est séparé de la source opérationnelle que par une seule requête SQL, ainsi que les compromis d'architecture en toute transparence qui permettent d'y parvenir.

Le problème de la plupart des reportings dans l'hôtellerie-restauration

La plupart des groupes multi-sites du secteur disposent d'un écosystème logiciel fragmenté : un PMS pour les hôtels, un POS pour le F&B, un channel manager pour les OTA, une plateforme de réservation de tables, un système de fidélité pour les abonnements, une plateforme marketing pour les e-mails, un CRM pour les ventes B2B, et un outil de reporting distinct superposé à l'ensemble.

Chaque système possède sa propre couche de reporting. Chaque couche apporte des réponses dans son propre format, selon son propre modèle de données et son propre cycle de rafraîchissement. Les questions transversales (celles que pose réellement le conseil d'administration) nécessitent un rapprochement manuel.

Exemple de question typique du conseil d'administration : « Quels groupes d'établissements ont enregistré le chiffre d'affaires par siège-heure disponible le plus élevé au dernier trimestre, ventilé par marque, et comment se situe-t-il par rapport au même trimestre de l'année précédente ? »

Dans un écosystème fragmenté, répondre à cette question nécessite de :

1. Exporter les données du POS depuis l'outil de reporting du fournisseur de POS (par établissement, par mois, puis regroupées manuellement)
2. Exporter les données de réservation depuis le fournisseur de réservations (format différent, nécessitant un rapprochement avec le POS pour éviter les doubles comptages)
3. Organiser le regroupement d'établissements dans un tableur distinct (car aucun système pris isolément ne connaît les « groupes d'établissements » en tant que cluster multi-marques)
4. Calculer le REVPASH manuellement (chiffre d'affaires ÷ sièges-heures disponibles), car aucun système ne le génère en natif
5. Effectuer la comparaison d'une année sur l'autre via un autre jeu d'exportations pour la période équivalente

Lorsque l'analyste a terminé, trois jours se sont écoulés. Le chiffre est exact. Mais il est déjà trop tard pour agir en conséquence. Le temps que le conseil d'administration se réunisse pour en discuter, une semaine de plus s'est écoulée.

Il ne s'agit pas d'un échec de l'analyste. C'est un échec de l'architecture.

Ce qui change lorsque le reporting réside dans la même base de données

L'architecture de reporting de mDOS adopte une approche différente. Il n'y a pas de base de données de reporting séparée. Il n'y a pas de tâche ETL qui transfère les données opérationnelles vers un entrepôt la nuit. Le tableau de bord de la direction exécute des requêtes SQL directement sur les mêmes tables Postgres que celles dans lesquelles le POS, le PMS, le système de réservation et le moteur de fidélité écrivent en temps réel.

Cela ressemble à un désastre en matière de performances. Ce le serait si l'architecture était simpliste. Ce n'est pas le cas.

La conception réelle est hybride. Les tableaux de bord opérationnels (ceux que les directeurs d'établissement et les responsables régionaux consultent heure par heure pendant le service) s'exécutent sous forme de requêtes en direct sur les tables opérationnelles. Ceux-ci sont restreints à un seul établissement ou à un petit groupe d'établissements, de sorte que les plans de requête sont rapides (p95 inférieur à la seconde lors des tests de charge mesurés sur la plateforme). Les données sont à jour au moment précis du chargement de la page.

Pour les synthèses de direction à l'échelle de l'ensemble du parc, la plateforme intègre également une couche d'instantanés précalculés : une tâche planifiée (exécutée sur Trigger.dev, notre planificateur géré) agrège les données opérationnelles dans une table d'instantanés chaque nuit à 3 h UTC. À l'échelle actuelle de la plateforme, les tableaux de bord de la direction fournissent toujours ces synthèses sous forme de requêtes en direct sur l'ensemble du parc (également en moins d'une seconde lors des tests de charge mesurés) ; la lecture à partir de la table d'instantanés précalculés constitue la voie de montée en charge à mesure que les parcs évoluent vers « l'ensemble des 300 établissements, l'historique complet des transactions, d'une année sur l'autre », où l'agrégation en direct deviendrait à terme trop lente pour être utile.

La plateforme est transparente sur ce compromis. Les tableaux de bord opérationnels affichent les données « en temps réel ». La couche d'instantanés, lorsqu'un écran de direction la consulte, affiche des données « à 3 h ce matin » : chargement instantané, mais données datant de 24 heures au maximum. Dans tous les cas, si le directeur financier a besoin des données du service en cours pour une décision spécifique, il consulte en détail le tableau de bord opérationnel et les obtient en direct.

Les quatre périmètres qui rendent l'analyse à l'échelle du parc réellement efficace

La raison pour laquelle les questions transversales sont si complexes dans des écosystèmes fragmentés est qu'aucun système pris isolément ne connaît la véritable structure organisationnelle du client. Le POS connaît les établissements. La plateforme de réservation connaît les établissements. Le CRM connaît éventuellement les marques. Rien ne connaît les regroupements arbitraires multi-marques.

mDOS résout ce problème grâce à quatre niveaux de périmètre, intégrés au cœur même de l'architecture de la couche de reporting.

Périmètre entreprise : tous les établissements de l'ensemble du parc. Les rapports sous-jacents s'exécutent simplement sans aucun filtre d'établissement.

Périmètre marque : tous les établissements rattachés à une marque spécifique, identifiés en recherchant les établissements appartenant à cette marque.

Périmètre groupe d'établissements : des clusters arbitraires multi-marques, définis en listant les établissements appartenant à chaque groupe. Un établissement peut faire partie de plusieurs groupes, et les groupes ne chevauchent jamais plusieurs entreprises. C'est la fonctionnalité que la plupart des concurrents ne savent pas proposer. Un groupe tel que « tous les établissements de centre-ville, toutes marques confondues » constitue un seul groupe d'établissements dans mDOS, interrogeable en une seule requête. Dans un écosystème fragmenté, cette requête nécessite de combiner des rapports spécifiques par marque issus de plusieurs systèmes fournisseurs et de les rapprocher manuellement.

Périmètre établissement : un seul établissement. La vue standard par établissement.

La question du conseil d'administration qui nécessitait auparavant trois jours (« Quels groupes d'établissements ont enregistré le REVPASH le plus élevé au dernier trimestre, ventilé par marque et en glissement annuel ? ») s'effectue désormais en une seule sélection de filtre dans le tableau de bord. La requête s'exécute en moins d'une seconde sur la table d'instantanés. Le CFO obtient la réponse avant même de passer au point suivant de l'ordre du jour.

Ce que le tableau de bord exécutif affiche réellement

La vue d'ensemble exécutive présente ces indicateurs à l'échelle de l'ensemble du parc d'établissements, avec une analyse détaillée multi-périmètres :

Les revenus issus de cinq flux (POS, hébergement, restauration, OTA, channel manager) sont consolidés en un chiffre unique pour l'ensemble du parc. Le RevPAR, l'ADR et le taux d'occupation proviennent d'un calcul dédié aux KPI hôteliers. Le REVPASH est calculé de manière native. La ventilation du chiffre d'affaires B2B est présentée séparément.

Les couverts et la rotation des tables au sein des espaces de restauration, avec les pourcentages d'utilisation des capacités, la répartition par jour de la semaine et les taux de no-show. Les chiffres de membres du programme de fidélité à l'échelle du groupe, la répartition par statut, les taux d'utilisation des points et les meilleures récompenses. Les soldes du pool de points entreprise et la valeur à vie des contacts au seuil du 75e percentile.

Le volume d'envoi d'e-mails et de SMS, les taux d'ouverture et les taux de clic par campagne et par scénario automatisé. Les pourcentages de conversion de l'entonnoir avec attribution des revenus à chaque étape et suivi UTM. Le mix de canaux entre direct, OTA, organique et payant. La note moyenne des avis du groupe avec une analyse du sentiment au fil du temps.

Tout cela peut être filtré sur les quatre périmètres (entreprise, marque, groupe d'établissements, établissement), regroupé par jour/semaine/mois, et comparé à la période précédente ou à la même période de l'année précédente. La gestion des fuseaux horaires prend en compte chaque établissement : lorsque le CFO compare les établissements de Londres à ceux de New York, la comparaison respecte les heures d'ouverture locales de chaque établissement plutôt qu'un fuseau UTC simpliste.

Une limite en toute transparence

Cet article ne doit pas prétendre que l'architecture est parfaite.

Un point de terminaison de rapport hérité (reporting POS) utilise actuellement un paramètre mono-établissement obsolète et ne prend pas en compte le périmètre par groupe d'établissements. Il bascule silencieusement sur un mode mono-établissement. Le correctif est en cours et sera déployé durant ce sprint. Une fois déployé, tous les points de terminaison de rapport prendront en compte le modèle à quatre périmètres de manière uniforme.

Nous le mentionnons parce que la due diligence d'un acquéreur le découvrira. Le coût de prétendre le contraire est bien plus élevé que celui d'être transparent.

Pourquoi cela importe pour les décisions du conseil d'administration

Le CFO d'un groupe hôtelier de 200 établissements prend un petit nombre de décisions par trimestre qui ont un impact significatif sur le P&L. La qualité de ces décisions dépend de la fraîcheur, de la précision et de la granularité des données sur lesquelles il s'appuie.

Une architecture de reporting qui fournit le REVPASH de l'ensemble du parc en une seconde, consultable jusqu'aux groupes d'établissements, avec une comparaison d'une année sur l'autre intégrée, transforme le rythme de prise de décision. Les conseils d'administration passent de l'« examen du rapport d'analyse du trimestre dernier » à l'« exploration de questions en direct sur le tableau de bord pendant la réunion ». Les discussions stratégiques deviennent plus précises car les données qui les étayent sont plus proches de la réalité opérationnelle.

Une architecture de reporting qui fournit les mêmes données trois jours plus tard, via un rapprochement manuel, rend ces discussions plus lentes, plus floues et plus dépendantes de l'intuition. L'intuition peut être juste. Mais elle peut aussi être fausse. L'architecture doit éliminer cette incertitude, pas la préserver.

C'est précisément le rôle du reporting en direct sur l'ensemble du parc. Il ne s'agit pas de remplacer les analystes : ils apportent une réelle valeur ajoutée grâce à leur interprétation et leurs recommandations. Il s'agit de s'assurer que le temps des analystes est consacré à l'interprétation, et non au travail mécanique de consolidation de cinq exports de fournisseurs pour obtenir un chiffre qui devrait être accessible en une seule requête.

---

L'architecture de reporting repose sur Postgres avec des requêtes hybrides direct/instantané. La documentation méthodologique est disponible sous accord de confidentialité (NDA) mutuel.