Au cours des dernières décennies, l’architecture client-serveur a été la norme IT dans le monde entier. Même si cette méthode a répondu aux besoins fondamentaux du secteur pendant de nombreuses années, elle a également été à l’origine de systèmes inefficaces, difficiles à mettre à l’échelle et dépourvus de la souplesse requise dans l’environnement de voyage actuel, qui évolue rapidement. Alors que le reste des technologies, qu’il s’agisse des consommateurs ou des entreprises, se transforme et évolue, les technologies d’infrastructure sont restées bloquées une décennie en arrière, ce qui fait qu’il est difficile pour les entrepreneurs de prendre la bonne décision commerciale. Cette forme traditionnelle d’architecture est connue sous le nom d’architecture “monolithique”. Heureusement, il existe une solution : l’architecture PMS de l’hôtel “microservice”. Il offre évolutivité, durabilité et sécurité et est en passe de devenir l’avenir de l’infrastructure technologique des voyages. Dans cet article, nous allons faire une plongée en profondeur dans l’architecture microservice des PMS d’hôtels et expliquer pourquoi il s’agit de l’avenir de l’architecture des technologies de voyage. Mais pour comprendre les microservices, comprenons, ce que ce n’est pas : Architecture client-serveur.
Qu’est-ce que l’architecture client-serveur ?
On estime que plus de 90 % des hôtels disposent actuellement d’infrastructures applicatives patrimoniales. Cela signifie que 9 propriétés sur 10 utilisent actuellement des systèmes qui ont été construits et conçus dans les années 80 et 90 et qui sont basés sur la norme de l’époque : l’architecture client-serveur.
Les hôtels continuent d’utiliser l’architecture client-serveur parce qu’elle fonctionne toujours dans le cadre prévu à l’origine. En outre, le passage à une nouvelle technologie peut être décourageant et, pendant longtemps, il n’y a pas eu beaucoup d’alternatives.
En fait, il ne s’agit pas seulement d’un problème d’hospitalité. Lorsque l’on examine la pile technologique utilisée au cours des quatre dernières décennies par pratiquement n’importe quelle entreprise, il est courant de tomber sur la même architecture :
- Un serveur : Un dispositif physique complexe et coûteux qui stocke une base de données (par exemple Oracle, Microsoft, sur un site, dans un fichier partagé, etc.)
- Clients multiples : PC de l’utilisateur (fonctionnant généralement sous Windows ou, avant cela, sous DOS et avec des entrées basées sur des terminaux comme le GDS).
- Applications : Logiciel physiquement installé sur les clients, communiquant avec la base de données du serveur.
Dans l’architecture client-serveur, vous avez, d’une part, le stockage des données dans une base de données centrale (généralement une base de données relationnelle telle que SQL) stockée sur un serveur physique et, d’autre part, de multiples interfaces utilisateur, des applications basées sur Windows/DOS qui communiquent avec le serveur. Le principal problème de cette architecture est que la logique d’entreprise est répartie sur les deux sites. Sur la base de données, par exemple, il est courant de trouver non seulement le stockage des données, mais même un peu de codage. Jusqu’à la fin des années 90, les serveurs étaient responsables du stockage des bases de données et de l’exécution de la logique commerciale. Cette question peut sembler triviale et sémantique, mais elle a de nombreuses implications négatives.
Par exemple, si un processus commercial particulier s’exécute plus rapidement dans la base de données que sur le client, les développeurs placeront une partie de la logique commerciale directement dans la base de données ou dans la couche d’interface utilisateur, au lieu de suivre la procédure conventionnelle qui consiste à faire des allers-retours entre le client et la base de données, ce qui crée un mélange bogué et propice aux erreurs.
Nouvelles plateformes, ancienne architecture
Pendant des années, des logiciels ont été écrits et développés sur la base d’une infrastructure client-serveur, mais au début des années 2000, grâce à l’avènement de l’internet et aux attentes accrues des clients et des entreprises, la pression a commencé à se faire sentir pour trouver une meilleure solution. Pourtant, même lorsque les applications web frontales HTML ont commencé à se généraliser, certains développeurs ont continué à créer des logiciels en utilisant les mêmes processus obsolètes, en changeant simplement la manière dont les applications étaient affichées tout en conservant la même architecture client-serveur intacte dans les coulisses.
Ce n’est qu’à la fin des années 2000, avec l’augmentation de la connectivité Internet et du nombre d’utilisateurs, que le monde du développement a réalisé que les applications devenaient si volumineuses (en termes de quantité de données) que l’architecture client-serveur ne pouvait plus les prendre en charge. En outre, la prolifération de navigateurs et d’appareils nouveaux et différents, tous dotés de spécifications distinctes, a fait prendre conscience aux développeurs qu’ils devaient gérer non pas une, mais une multitude d’interfaces.
Les leaders du secteur, tels que Google, Amazon et Netflix, ont rapidement compris ce changement et, afin de maintenir la stabilité et l’évolutivité, ont commencé à disséquer l’ensemble du processus de traitement, d’utilisation et de gestion des données, en veillant à ce que leurs couches de présentation et leurs logiques commerciales soient clairement séparées les unes des autres – l’une des nombreuses mesures prémonitoires qui ont permis à ces entreprises de connaître le succès.
Architecture à trois niveaux ou architecture client-serveur
La solution de Google et d’autres leaders de l’industrie était simple mais brillante. IT a consisté tout d’abord à diminuer la responsabilité des serveurs pour se concentrer uniquement sur le stockage des données, ensuite à augmenter la capacité de traitement des données des serveurs (pour collecter et analyser, pratiquement en temps réel, des téraoctets de données), et enfin à réduire les responsabilités des serveurs en matière de logique d’entreprise.
Ce nouveau concept a marqué la naissance de ce que nous appelons aujourd’hui l’architecture à trois niveaux, composée de trois parties indépendantes : un système complet de stockage/récupération de données en aval (transparent, rapide et stable), une logique d’entreprise (exposant ses fonctionnalités par le biais d’API spécifiques) et un niveau de présentation (l’interface utilisateur en amont).
Les microservices compartimentent les fonctionnalités alors que les monolithiques les centralisent. En d’autres termes, les microservices compartimentent les problèmes potentiels alors que les monolithes les centralisent.
La construction et la maintenance de logiciels en tant que modules indépendants sur des plates-formes distinctes était un concept révolutionnaire, mais nécessaire, à des années-lumière de l’architecture standard des années 80 et 90. La division de toutes les fonctionnalités d’un système en plusieurs paquets dotés de fonctionnalités composées rend le développement de logiciels évolutif et facile à maintenir, alors que tout est développé dans une seule et unique plateforme.
Cette nouvelle façon de faire est connue sous le nom d’”architecture microservice”, tandis que l’ancienne façon est connue sous le nom d’”architecture monolithique”.
“Les applications monolithiques peuvent avoir du succès, mais elles suscitent de plus en plus de frustrations”.
“Les applications monolithiques peuvent avoir du succès, mais elles suscitent de plus en plus de frustrations”.
– Martin Fowler
Le principal problème de l’architecture monolithique est qu’il est pratiquement impossible de la faire évoluer, tant pour les fournisseurs de technologie que pour les utilisateurs finaux. L’ajout d’une nouvelle fonctionnalité simple à une application existante peut, dans le pire des cas, faire planter tout le système ou, dans le meilleur des cas, prendre beaucoup de temps de développement, ce qui entraîne des coûts plus élevés pour toutes les parties concernées.
De l’architecture monolithique à l’architecture microservice
Les clients des hôtels ont certaines attentes. Ils voudront peut-être pouvoir s’enregistrer depuis leur téléphone ou commander un dîner via une application. Les hôtels seraient ravis d’offrir ces services, car la satisfaction du client est un élément fondamental de l’hospitalité. Pourtant, le plus souvent, les hôtels ne sont pas en mesure de servir correctement leurs clients uniquement parce que leurs systèmes obsolètes n’ont pas la capacité d’intégrer de nouvelles fonctionnalités, car chaque couche supplémentaire de personnalisation doit être codée en dur dans la base de données ou dans l’application client. La plupart des logiciels hôteliers sont constitués d’un gros morceau de code désordonné, où chaque ligne est tellement interdépendante qu’il devient pratiquement impossible d’innover sans casser tout le système, d’où l’incapacité du secteur à s’adapter aux nouveaux besoins du marché.
Avec l’approche microservices, en revanche, vous disposez de plusieurs petits programmes totalement indépendants les uns des autres, mais reliés entre eux par des règles écrites dans les API. Par conséquent, tant que les règles de l’API sont respectées, un système basé sur les microservices peut être maintenu et amélioré indéfiniment sans risquer d’anéantir l’ensemble du système à chaque mise à jour. D’un point de vue opérationnel, le risque d’effet domino d’un bogue est contenu par la décentralisation propre à l’architecture de microservices – si une application reçoit une mise à jour ou tombe en panne, cela n’affecte pas l’ensemble de la structure. L’ensemble de l’écosystème devient résilient, et il est beaucoup plus facile d’isoler les erreurs et de récupérer les défaillances du système.
Le rôle des API
L’augmentation du taux d’adoption des API dans l’industrie hôtelière a joué un rôle crucial dans le passage d’une architecture PMS monolithique à une architecture microservice. Les API sont au cœur de cette approche plus souple et décentralisée, car elles simplifient l’acte de programmation et augmentent les possibilités d’interconnexion.
Cette indépendance donne aux développeurs la liberté de coder sans avoir besoin de comprendre parfaitement le langage de programmation utilisé pour le système central. Les programmeurs qui travaillent à l’intégration d’une fonction particulière d’une application tierce, par exemple, n’ont pas besoin de comprendre l’ensemble du système de fichiers, de la structure de programmation et du langage, et peuvent simplement se concentrer sur l’obtention d’informations spécifiques pour résoudre un problème spécifique. Les microservices compartimentent les fonctionnalités alors que les monolithiques les centralisent. En d’autres termes, les microservices compartimentent les problèmes potentiels alors que les monolithes les centralisent.
Architecture du PMS hôtelier en microservices et protection des données
Il ne se passe pas un jour sans que l’on entende parler de violations de données. L’industrie du voyage a toujours été vulnérable aux violations de données, principalement parce que (contrairement à la plupart des industries) pour fonctionner correctement, elle doit collecter une énorme quantité d’informations sur les clients et la valeur de ces données est corrélée à la capacité de l’hôtel à les servir.
Sur le marché noir, les informations personnelles identifiables sont vendues à environ 1 dollar chacune, mais, selon Justin Lie, PDG de CashShield, leur valeur “est multipliée par 5 avec chaque information associée ajoutée”. Si l’on ajoute un numéro de téléphone portable, une adresse électronique personnelle et une date de naissance aux données originales volées, leur valeur monte en flèche pour atteindre 125 dollars.
Il n’est pas difficile de comprendre que les bases de données des hôtels sont littéralement des mines d’or pour les pirates, car elles stockent un profil individuel plus complet et plus précis que, par exemple, un blog web ou une application de jeu. Les hôtels collectent des données extrêmement précieuses, telles que les numéros de téléphone, les détails des cartes de crédit et, surtout, les passeports. Aux États-Unis, un passeport volé permet à pratiquement n’importe qui de demander un numéro de sécurité sociale en ligne et, par conséquent, de demander des cartes de crédit ou des prêts.
La principale difficulté réside dans le fait que la structure de base de la plupart des logiciels hôteliers a été codée des décennies avant l’avènement du web, et qu’ils ne sont tout simplement pas prêts à se défendre contre les cyber-attaques en ligne. Le philosophe français Paul Virilio a dit un jour : “Quand on invente le bateau, on invente aussi le naufrage”. Dans les années 80 et pendant une bonne partie des années 90, alors qu’il n’y avait pratiquement pas de connexion Internet, le concept de piratage du web n’était tout simplement pas envisagé, ce qui explique pourquoi tant de systèmes logiciels hôteliers sont sans défense lorsqu’il s’agit de fuites de données.
Aujourd’hui, grâce à l’architecture microservice du PMS hôtel, les développeurs peuvent séparer les données personnelles des données non personnelles, et choisir de concevoir autour de l’un ou l’autre des ensembles de données en fonction de la tâche spécifique qui doit être exécutée.
Cette flexibilité de construire chaque fois que possible uniquement autour de données non personnelles donne un avantage inestimable aux logiciels de microservices, en particulier lorsqu’il s’agit de restrictions de stockage de données de pays spécifiques qui demandent que les informations de leurs citoyens soient stockées localement. Dans les architectures monolithiques, les données sont souvent dispersées, ce qui signifie que les données personnelles des clients russes devraient être légalement stockées dans leur pays. Pour faire des affaires avec la Russie, l’ensemble du système doit être déplacé et les données ne peuvent être consultées qu’en mémoire cache, ce qui crée un cercle de complexité difficile (et coûteux).
Des entreprises telles qu’Amazon et Netflix sont des adeptes de la première heure de l’architecture microservices, et leur grande évolutivité est principalement due au fait que leurs applications sont développées et déployées comme un ensemble de microservices plutôt que comme un gros morceau de code.
Systèmes basés sur le cloud : La flexibilité à bon marché
Souvent mal compris (ou sciemment déformé par les entreprises technologiques), le principal avantage du “cloud” réside moins dans la possibilité d’exécuter une application à partir d’un navigateur que dans les économies réalisées, ou le coût total de possession (TCO). Les coûts directs et indirects du déploiement d’un système dans le cloud sont tout simplement bien inférieurs à ceux du maintien de ce système sur une plateforme existante.
Tout d’abord, les hôtels n’ont pas besoin d’acquérir du matériel coûteux (coûts directs). De plus, en externalisant, les hôtels peuvent bénéficier de l’expertise et des ressources du prestataire en cas de problème, au lieu de devoir compter uniquement sur les experts internes pour le support et la maintenance (coûts indirects). Les fournisseurs de services cloud garantissent même souvent des temps de fonctionnement plus élevés que les systèmes patrimoniaux autogérés, ce qui diminue considérablement le risque de perte potentielle de revenus. De plus, la fusion de différentes technologies devient exponentiellement plus facile avec les architectures microservices.
En bref, les solutions cloud ( solutions PMS et PDV pour l’hôtellerie ) rendent possible l’évolutivité, la croissance et la durabilité pour les entreprises de toute taille en minimisant la nécessité d’investissements initiaux prohibitifs (matériel, configuration du centre de données, coûts d’installation, etc.) et en prolongeant le cycle de vie des applications.
L’essor de l’architecture Microservice Hotel PMS
Il n’est pas surprenant qu’au cours des dernières années, des entreprises prospères telles que Netflix, Google et Amazon aient toutes abandonné l’architecture monolithique au profit des microservices. Aujourd’hui, avec de nouvelles lois sur la protection de la vie privée, des exigences variées, une technologie plus rapide, des systèmes de paiement perturbateurs et des systèmes de distribution toujours plus étendus, il est évident que l’approche monolithique ne pourra pas suivre.
De plus, en utilisant une approche “plug-and-play”, les développeurs ne perdent pas de temps à résoudre des problèmes qui ont déjà été résolus par quelqu’un d’autre. Les nombreuses implications de l’adoption des microservices hotel pms et autres architectures IT peuvent sembler écrasantes pour certains, mais à terme, chaque entreprise, quelle que soit sa taille, devrait pouvoir choisir n’importe quel outil disponible sur le marché et le connecter sans friction à d’autres outils – tout comme ils installent des applications sur leur smartphone personnel. Pour les hôtels, cela peut signifier quelque chose d’aussi simple que la modification d’un processus interne de nettoyage ou d’entretien des chambres.
Les IT devraient faciliter la gestion d’une entreprise et le service aux clients. En ce qui concerne les hôtels, les stratégies ne devraient jamais être déterminées par les limites de l’infrastructure IT sous-jacente, mais améliorées par sa flexibilité. Il est temps pour l’industrie de l’hôtellerie et de la restauration d’adopter l’innovation, la durabilité et l’évolutivité. Il est temps pour l’industrie hotellerie et restauration d’adopter l’architecture microservice.
