Documentation de la plateforme

Les fonctionnalités sont importantes, mais l'intégrité de la plateforme que vous utilisez l'est tout autant. La performance, la disponibilité et la sécurité sont essentielles, c'est pourquoi nous avons compilé des informations clés sur la plateforme Mews.

For your convenience, we have provided a French translation of this page. This translation is for informational purposes only and is currently being updated. The definitive version of this page is the English version.

Contents

Back

exit icon

Philosophie

Mews est une plateforme SaaS cloud-native, sans serveur et multi-locataire. Cela a de nombreuses implications dans tous les aspects de son fonctionnement, ainsi que dans la manière dont Mews répond aux divers besoins et exigences de conformité. Il est important de considérer Mews sous cet angle tout en lisant les autres sections de cette documentation, car cela peut différer des systèmes plus traditionnels, et certaines exigences ou questions ne sont pas applicables lorsqu'on considère la plateforme Mews.

Cloud-native

 

Dès le premier jour, Mews a été conçu pour le cloud. L'architecture du système a été pensée pour un déploiement dans le cloud, tirant pleinement parti de tous les avantages que cela procure. Mews n'est pas un système conçu à l'origine pour fonctionner sur site, puis adapté ou porté pour un déploiement cloud, ce qui signifie que certains processus ou procédures fonctionnent différemment, voire ne se produisent pas du tout.

Sans serveur (Serverless)

 

Il existe plusieurs façons d’opérer dans un environnement cloud. À un extrême, vous pouvez utiliser uniquement les services cloud de bas niveau tels que des machines virtuelles et gérer tout le reste vous-même. L’avantage de cette approche est que tous les fournisseurs de cloud proposent des services primitifs, ce qui facilite le changement de fournisseur – bien que cela nécessite des compétences en configuration de serveurs, bases de données, etc., ainsi qu’un entretien constant.

À l'autre extrême, vous pouvez aller au-delà des fonctionnalités de bas niveau et utiliser le cloud en tant que service, par exemple, des services informatiques ou de stockage. Dans ce cas, le fournisseur de cloud prend en charge la configuration et la maintenance – l'inconvénient étant que vous devenez plus dépendant d’un fournisseur de cloud spécifique.

Nous sommes un partenaire fier de Microsoft et utilisons pleinement Microsoft Azure. Par conséquent, nous sommes du côté "sans serveur" du spectre. Nous utilisons des services comme Azure App Service pour l’hébergement d’applications web, et Azure SQL Database et Azure Storage pour les services de stockage. Nous ne gérons donc pas de machines virtuelles, de serveurs web ou de serveurs de bases de données – cela relève de la responsabilité de notre fournisseur de cloud, y compris pour la conformité et la sécurité de ces services.

Ces services ont leurs propres SLA définis par Azure. Nous avons construit notre solution en superposant ces services et SLA avec notre système, afin de garantir nos propres SLA. Nous utilisons la même approche pour garantir notre conformité, sécurité, reprise après sinistre et d'autres aspects détaillés dans les sections suivantes.

Multi-locataire (Multi-tenant)

 

Il n’existe qu’une seule "installation" de production de la plateforme Mews que tous nos clients utilisent. Cela signifie que nos clients utilisent toujours la version la plus récente de la plateforme, avec les mêmes fonctionnalités disponibles pour tous les utilisateurs de la plateforme (en fonction du niveau d’abonnement). Du point de vue des données, celles-ci ne sont pas séparées, le stockage est partagé.

D'un point de vue sécurité, c'est très similaire à un système mono-locataire. Dans ce cas, nous devrions nous assurer que les utilisateurs ayant des niveaux de privilège différents n'accèdent qu'aux données auxquelles ils sont autorisés. Dans les systèmes multi-locataires, le locataire peut être compris comme un autre "niveau" de privilèges. Disposer d’une solution multi-locataire nous permet de mettre en œuvre des scénarios d’entreprises de grande taille ou de chaînes, et d’offrir une excellente expérience pour les invités, notamment dans le portail des invités.

SaaS (Software as a Service)

 

La seule chose dont vous avez besoin pour utiliser la plateforme Mews, c'est d’une connexion à Internet et d’un navigateur web. Tout le reste est pris en charge par nos soins. Nous gérons tous les aspects couverts dans cette documentation et nous nous efforçons de les exécuter du mieux possible tout en continuant à nous améliorer. Il est de notre responsabilité de garantir que le système soit rapide, toujours disponible, avec des sauvegardes, sécurisé, conforme à toutes les législations, toujours à jour, accessible à tous dans le monde entier et utilisable par un large éventail d'utilisateurs.

Les clients sont seulement responsables de la conservation des documents externes lorsque cela est exigé par la loi. En France, les clients ont l’obligation de conserver les documents fiscaux sur un support physique externe sécurisé pour la période légale requise.

Infrastructure

Nous utilisons Microsoft Azure comme fournisseur de cloud. Certains services cloud sont mondiaux avec géo-réplication et haute disponibilité intégrée par Azure ; d'autres services sont liés à une seule région.
 
Nous utilisons quatre régions :
  • Europe de l’Ouest (Pays-Bas)
  • Europe du Nord (Irlande)
  • Allemagne Ouest Central (Francfort)
  • Suède Central (Gävle)
Notre base de données principale est un cluster à haute disponibilité situé en Allemagne Ouest Central, avec des répliques en Europe du Nord.

Tech Stack


Nous utilisons plusieurs langages de programmation, frameworks et technologies. Principalement :
  • C# et .NET pour le backend
  • JavaScript/TypeScript et React pour le frontend
  • Flutter et Kotlin pour les applications mobiles

Environnements

 
La plateforme Mews fonctionne dans plusieurs instances appelées environnements ; certains sont publics, d’autres privés :
  • Environnement de production
  • Environnement de démonstration
  • Environnement de développement
  • Environnements de branche de fonctionnalités

Récupération après sinistre

En tant que système cloud-native, notre stratégie de récupération après sinistre repose sur les sauvegardes de données et la capacité de les restaurer en cas d'incident. Tous les autres services sont « sans état » ce qui signifie qu'en cas de sinistre, nous pouvons les restaurer sans perte d'informations. Nous comptons largement sur les fonctionnalités offertes par Microsoft Azure dans ce domaine, et nous avons nos propres niveaux de sauvegardes ajoutés aux fonctionnalités standard d’Azure.
 

Base de données Azure SQL


Nous utilisons le niveau premium de la base de données Azure SQL avec une réplique dans la région géographique secondaire. Cette configuration comprend déjà plusieurs couches et mécanismes de sauvegarde intégrés, décrits en détail dans la documentation de la base de données Azure SQL. En plus de cela, nous avons nos propres processus de sauvegarde. Toutes les options, qu’elles soient intégrées ou propres à Mews, sont décrites ci-dessous :

Dans un centre de données, le service de base de données fonctionne en tant que cluster à haute disponibilité composé de deux répliques identiques de la base de données avec une latence des données proche du temps réel (quelques millisecondes). En cas de sinistre sur la base de données principale, le service passe immédiatement à la base de données secondaire. De plus, nous avons la possibilité de déclencher cette bascule manuellement.

Le service de base de données propose une restauration à un moment donné, ce qui nous permet de restaurer une base de données complète à un moment précis, jusqu’à 35 jours en arrière.

Le cluster de base de données dans la région principale est répliqué géographiquement vers le cluster de haute disponibilité dans la région secondaire. En cas de sinistre dans la région principale, nous pouvons effectuer un basculement vers la région secondaire et promouvoir la réplique secondaire en tant que base principale. Cela peut être fait rapidement et de manière fiable grâce aux groupes de basculement automatique.

Nous effectuons des instantanés quotidiens de la base de données principale en utilisant la fonctionnalité de restauration à un moment donné vers un autre serveur de sauvegarde. Le serveur de sauvegarde conserve deux copies complètement restaurées, âgées au maximum de 24 et 48 heures, prêtes à être utilisées immédiatement en cas de sinistre affectant à la fois la base de données principale et secondaire. Alternativement, ces instantanés peuvent être utilisés en cas de corruption partielle des données pour restaurer les données immédiatement.
 

Stockage Azure


Pour stocker les données binaires, nous utilisons Azure Storage configuré pour utiliser des capacités de stockage géo-redondant. Les données sont automatiquement répliquées trois fois dans la région principale et trois fois dans la région secondaire. Le compte de stockage utilise également une fonctionnalité de suppression douce (soft-delete) qui empêche les problèmes spécifiques à l'application et nous permet de récupérer des données potentiellement corrompues. De manière similaire à la base de données SQL, nous effectuons des sauvegardes incrémentielles quotidiennes de toutes les données dans le stockage vers un stockage de sauvegarde qui est prêt à être utilisé immédiatement en cas de sinistre affectant le stockage principal.
 

Cosmos DB


Nous avons Cosmos DB configuré pour être répliqué dans plusieurs régions. Cosmos DB réplique de manière transparente les données vers toutes les régions associées à notre compte et prend en charge le basculement automatique en cas de panne régionale. Actuellement, nous stockons uniquement des données non critiques pour l'entreprise dans Cosmos DB (par exemple, les journaux), et nous n’avons donc pas de couche de sauvegarde supplémentaire au-delà des fonctionnalités proposées par le service.

Déploiements

Notre philosophie en matière de déploiements est de déployer aussi souvent que possible et plus les changements déployés sont petits, mieux c'est. La principale raison est que cela nous permet de livrer des fonctionnalités et des corrections de bugs à nos clients dès que possible, afin qu'ils puissent en bénéficier immédiatement. La deuxième raison est de minimiser les problèmes pendant les déploiements et de simplifier l'investigation et le retour en arrière en cas de problèmes. Tous nos déploiements ne causent aucun temps d'arrêt pour l'utilisateur final.
 

Calendriers de déploiement


Notre plateforme n'est pas une seule application que nous déployons dans son ensemble, mais plutôt un assemblage de systèmes et d'applications qui fonctionnent et communiquent ensemble et qui ont leurs propres calendriers de déploiement. Il existe trois catégories principales d'applications avec leurs calendriers de déploiement respectifs :
 
Plateforme backend (serveur) déployée au moins une fois chaque jour ouvré. En plus de cela, si nécessaire, des déploiements ad-hoc peuvent être effectués pour diverses raisons, par exemple pour des corrections urgentes. Le scénario standard est que tous les changements (fonctionnalités, corrections de bugs, améliorations) sont déployés en continu dans l'environnement de développement. Une fois par jour, nous prenons automatiquement un instantané de la version de l'environnement de développement et la déployons dans l'environnement de démonstration (ce que l’on appelle un « feature-freeze »). Le jour suivant, si aucune anomalie n'est détectée sur le site de démonstration, cette version est déployée en production. Tous les déploiements se font progressivement sur toutes les instances et régions. Pendant le processus, nous surveillons le système et, en cas de problème, nous pouvons annuler le déploiement.

Applications web (par exemple, Commander, Distributor ou Navigator) déployées indépendamment chaque fois qu’un changement est finalisé dans l’application. Cela signifie que chaque fois qu'une fonctionnalité est mise en œuvre ou qu'un bug est corrigé et validé, il est immédiatement déployé à la fois dans l'environnement de démonstration et en production. C’est un véritable processus de livraison continue, ce qui signifie qu’il peut y avoir 50 ou 0 déploiements en une journée, en fonction du nombre de changements finalisés ce jour-là. Là encore, nous surveillons la santé des applications et pouvons annuler tout processus si nécessaire.

Applications mobiles déployées de manière irrégulière, en raison des processus de vérification dans les magasins d'applications. De temps en temps, lorsque nous déterminons que l'ensemble des changements finalisés dans la version de développement de l'application est suffisamment important, ou lorsque cela est nécessaire pour d'autres raisons, nous publions une nouvelle version de l'application. Elle est ensuite publiée dans le magasin d'applications respectif, où elle passe par le processus de vérification. Après un certain temps (heures ou jours), la nouvelle version atteint les appareils des utilisateurs finaux.
 
Nous nous réservons l'option d'une période d’indisponibilité programmée nécessaire pour les changements système, bien que notre objectif soit de ne jamais utiliser cette option. Jusqu'à présent, nous n'avons eu à l'utiliser qu'une seule fois en 2013 lorsque nous avons migré notre fournisseur de cloud d'AppHarbor vers Microsoft Azure. Depuis, nous n'avons eu aucune période d'indisponibilité programmée.

Processus de publication


Il est important de distinguer le déploiement de la publication. Le déploiement est le moment où le changement atteint la production. Cependant, le changement ne doit pas nécessairement être disponible pour tous les clients. Le moment où le changement devient disponible pour un client est appelé la publication. Les petits changements, les corrections de bugs, les améliorations ou autres éléments non critiques sont publiés à tous nos clients dès qu'ils sont déployés. Cependant, pour les changements plus importants ou plus critiques, nous suivons le processus de publication en quatre étapes suivant :
  • Alpha interne : Le changement est publié uniquement aux employés de Mews. Nous utilisons Mews en interne aussi, donc nous sommes les "canaris" qui testent le changement.
  • Bêta privée : Le changement est publié à un sous-ensemble sélectionné de clients qui forment des groupes de premiers utilisateurs. Si le changement est particulièrement important pour quelqu'un ayant participé au processus de découverte et de livraison du produit, il peut être inclus dans la bêta privée. Pour cette étape et aussi pour l’alpha interne, nous utilisons LaunchDarkly pour gérer le groupe de clients impactés.
  • Bêta publique : Le changement est publié à toute personne qui choisit de l’accepter. En général, nous introduisons une option dans les paramètres permettant à chacun de choisir d'accepter le changement.
  • Disponibilité générale : Le changement est publié à tous nos clients.

Incidents

Pour tous types de problèmes, y compris les incidents, les incidents de sécurité, les bugs, les enquêtes ou les alertes de surveillance, nous suivons un processus strict de résolution. Ce processus est documenté dans notre base de connaissances interne. Chaque problème, quelle que soit sa gravité, se voit attribuer une équipe et est immédiatement communiqué à cette équipe via un canal Slack interne.

Pour les problèmes ayant un impact significatif sur les clients, il existe un processus d'escalade supplémentaire afin de garantir qu'ils soient traités de manière urgente. Ces incidents sont communiqués dans un canal d'incidents à l'échelle de l'entreprise et des mises à jour régulières sont partagées avec les parties prenantes internes et externes.
 
Après résolution, l'équipe procède à une analyse des causes profondes, conçoit des solutions et publie un document post-mortem. Les solutions issues du post-mortem sont mises en œuvre dans un délai défini par notre SLO interne.

Sécurité

La plateforme Mews travaille avec des données clients très sensibles, c'est pourquoi la sécurité et la confidentialité des données sont des éléments non négociables du système. Notre approche générale dans ce domaine est que rien ne doit dépendre des personnes ou de leurs connaissances. Toutes nos mesures de sécurité et nos processus internes sont conçus de cette manière ; par exemple, bien que nos développeurs soient régulièrement formés aux meilleures pratiques de codage sécurisé, nous ne comptons pas uniquement sur cela pour assurer la sécurité. Nos processus et cadres sont conçus pour interdire la création de bugs de sécurité, ou du moins rendre extrêmement difficile pour un développeur d'introduire des problèmes de sécurité dans notre système, si cela n'est pas techniquement possible de l'interdire complètement. Cela se reflète dans notre processus de résolution des problèmes de sécurité, qui est décrit plus loin. Notre stratégie de sécurité repose sur deux principes principaux :
  • Minimiser la surface d'attaque, réduire son étendue et sa complexité.
  • Effectuer des tests de pénétration continus de la surface d'attaque, avec une résolution approfondie et complète des éventuelles découvertes.
En plus de ces mesures proactives, nous passons très souvent par des audits, des certifications, des processus de diligence raisonnable et des tests de pénétration réalisés par des entreprises tierces, soit désignées par nos soins (par exemple PCI-DSS, ISO), soit par nos clients potentiels.

Minimisation de la surface d'attaque
 
La meilleure façon d'éviter les problèmes de sécurité est de supprimer complètement la possibilité de les créer dès le départ. Cela s'aligne avec notre philosophie sans serveur : nous ne contrôlons pas le matériel, les systèmes d'exploitation, les serveurs web ou les serveurs de bases de données. Nous ne pouvons pas mal configurer l'un de ces systèmes, et nous ne pouvons pas oublier d'appliquer des patches de sécurité, etc. – c'est la responsabilité d'Azure, qui dispose de grandes équipes de sécurité. Nous utilisons une configuration très limitée des services Azure, pour lesquels il existe des options permettant d'activer des fonctionnalités de sécurité supplémentaires. Afin de nous assurer de ne rien manquer, nous utilisons Azure Security Advisor, qui nous avertit de toutes ces options, par exemple lorsque Azure introduit de nouvelles fonctionnalités qui pourraient renforcer la sécurité de nos systèmes. Grâce à tout ce qui précède, notre surface d'attaque (du point de vue du système) est effectivement réduite au code applicatif que nous développons. Pour plus d'informations sur les capacités de sécurité d'Azure, veuillez consulter la documentation sur les fondamentaux de la sécurité d'Azure.
 
Tests de pénétration continus
Comme déjà démontré, notre principale priorité est la sécurité au niveau de l'application. Afin de garantir que notre système soit sécurisé, nous subissons continuellement des tests de pénétration réalisés par cobalt.io. À tout moment, une partie de notre système ou un produit est soumis à des tests de pénétration et nous nous assurons que l'ensemble de la surface est couvert par des tests de manière continue.

Il existe plusieurs approches pour traiter les vulnérabilités de sécurité. Nous sommes fiers de notre méthode et traitons chaque problème de sécurité de manière post-mortem, ce qui signifie que nous effectuons une analyse détaillée des causes profondes et résolvons non seulement le problème individuel, mais aussi tous les cas similaires dans tous nos produits. En plus de cela, nous mettons en place des mesures pour empêcher que ces problèmes ne se reproduisent à l'avenir. Par exemple, si un problème est trouvé dans l'une de nos API, nous mettons à jour notre cadre API de manière à éliminer le problème de toutes nos API. Ou bien nous mettons en œuvre un analyseur de code statique qui peut vérifier automatiquement l'existence du problème dans notre base de code, ainsi que dans tout nouveau code que nous produisons. Ainsi, même si un produit est testé à la fois, nous appliquons nos conclusions à tous nos produits. Pour plus d'informations, consultez la section Incidents.

Mesures techniques de sécurité
 
Du point de vue technique, nous mettons en place de nombreuses actions pour garantir la sécurité non seulement de la plateforme elle-même, mais aussi de nos clients. Voici quelques-unes de ces mesures :
  • Les données sont chiffrées en transit, nous imposons au minimum TLS 1.2 et obtenons la note A+ lors du test de Qualys SSL Labs.
  • Les données dans tous les types de stockage que nous utilisons sont chiffrées au repos.
  • Nous utilisons plusieurs niveaux de journaux internes du système et fournissons des journaux d'audit à nos clients sur la plateforme.
  • Nous effectuons des scans ASV réguliers, ainsi que des scans de vulnérabilité internes et externes.
  • Tous nos appareils sont protégés par des logiciels antivirus/anti-malware et sont gérés de manière centralisée par des solutions MDM.
  • Nous appliquons une politique de mots de passe stricts, utilisons 1Password et imposons l'authentification multi-facteurs (MFA) pour tous les systèmes internes qui offrent cette fonctionnalité.
  • Nous utilisons Azure Active Directory et SSO pour tous les systèmes internes qui proposent cette fonctionnalité.
  • Nous suivons le principe du moindre privilège pour tous nos systèmes internes.
  • Notre plateforme prend en charge l'authentification multi-facteurs (MFA) et impose des mots de passe forts à nos utilisateurs.
  • Les mots de passe des utilisateurs sont hachés à l'aide de bcrypt et ne sont jamais stockés en clair.
  • Toutes les clés et tokens sensibles des utilisateurs utilisés pour l'authentification tierce (comme les mots de passe FTP) sont chiffrés dans la base de données Azure SQL.
  • Toutes les clés et tokens sensibles de Mews sont chiffrés dans la configuration.
  • Mesures de sécurité des personnes
  • Nous effectuons des vérifications pour tous les candidats aux postes sensibles que nous recrutons. L'étendue et la rigueur de ces vérifications dépendent du rôle et du niveau de séniorité du candidat.
  • Les contrats de tous nos employés contiennent des clauses de confidentialité et les employés sont tenus de respecter les règles internes concernant le traitement des données personnelles.
  • Tous les employés suivent une orientation à leur arrivée, incluant une formation obligatoire sur la sécurité et la confidentialité des données.
  • Tous les employés utilisent 1Password et génèrent leur mot de passe principal à l'aide de diceware.
  • Tous les membres du département technique (développeurs, analystes de données, assurance qualité, informatique) suivent une formation de sécurité obligatoire au moins une fois par an.

Données de carte de paiement

Un excellent exemple de réduction de la surface d'attaque est la manière dont nous traitons les données sensibles des cartes de paiement. Mews utilise PCI Proxy comme fournisseur de tokenisation des cartes. Les données sensibles des cartes, telles que le numéro ou le CVV, ne parviennent même pas à notre infrastructure. Par exemple, considérons un simple flux de réception des détails de la carte par un tiers (par exemple, un canal de réservation) puis de facturation de cette carte :
  • Lorsque le tiers doit nous envoyer les détails de la carte, il ne nous dirige pas directement la demande comme cela se fait habituellement, mais il la redirige vers PCI Proxy.
  • PCI Proxy reçoit la demande, détecte les détails de la carte, les stocke et les remplace par des tokens qui ne sont plus sensibles. Cette étape est appelée la tokenisation.
  • PCI Proxy transmet la demande, maintenant contenant des tokens, vers nous.
  • Nous stockons le token dans notre base de données.
  • Afin de facturer la carte, nous créons une demande pour le passerelle de paiement. Cependant, au lieu d'utiliser directement les données de la carte (que nous n'avons pas), nous utilisons les tokens. Et au lieu d'envoyer la demande directement à la passerelle de paiement, nous la redirigeons vers PCI Proxy.
  • PCI Proxy reçoit la demande de notre part, détecte les tokens et les remplace par les détails sensibles de la carte. Cette étape est appelée la dé-tokenisation.
  • PCI Proxy transmet la demande, maintenant contenant les données sensibles, à la passerelle de paiement.
De nombreux types d'attaques sont rendus inutiles, du fait que nos stockages de données ne contiennent pas les données sensibles.

Confidentialité des données

La plateforme Mews traite des données personnelles et d'autres types de données sensibles. Cependant, nous ne sommes pas un simple service SaaS de traitement des données, donc pour comprendre tous les flux de données, il est important de distinguer les deux rôles que Mews occupe:
 
Sous-traitant : Dans la relation entre nos clients (hôtels) et nous, nous agissons en tant que responsable du traitement pour toutes leurs données entrant dans la plateforme, y compris les données personnelles de leurs clients. Cela fait partie du service que nous fournissons à nos clients.
 
Responsable du traitement : Dans la relation entre nos utilisateurs (individus) et nous, nous agissons en tant que responsable du traitement des données personnelles – nous fournissons un service de « portefeuille de voyage » et d'autres applications à nos utilisateurs.
 
Ces deux rôles et modes opérationnels de Mews sont strictement distincts, et les données ne se mélangent jamais. Et comme nous sommes une solution multi-locataire, une personne physique peut avoir ses données personnelles dans N+1 copies sur la plateforme Mews. Si la personne a interagi avec N de nos clients (par exemple, a effectué des réservations dans N hôtels différents), alors N comptes clients sont stockés, et Mews est le responsable du traitement des données dans ce cas. Le "+1" représente une autre copie des données personnelles stockée au cas où la personne se serait inscrite à Mews en tant qu'utilisateur pour utiliser le service « portefeuille de voyage ». Pour cette unique copie, Mews est responsable du traitement des données. Nous n'avons aucun arrangement de coparticipation de responsabilité.
 
Toutes les données sont stockées dans notre stockage de données Azure, conformément à la section Infrastructure de cette documentation. Nous ne procédons à aucun archivage des données et les sauvegardes sont conservées pendant une période limitée.
 
Données de nos clients

Les données entrent dans le système soit manuellement par un employé de notre client, soit fournies par leurs clients, directement (en les partageant du portefeuille de voyage vers le client) ou indirectement, par exemple via les canaux de réservation et nos API. Les données se composent des détails personnels des clients de nos clients, principalement des voyageurs du monde entier.
 
Nos clients peuvent enregistrer divers points de données sur leurs clients, tels que prénom, nom, deuxième prénom, date de naissance, nationalité, documents d'identité (passeport, carte d'identité, permis de conduire, visa), adresses, adresse e-mail, numéro de téléphone, etc. En ce qui concerne les détails des cartes de paiement, ceux-ci sont également collectés, mais ne sont ni directement accessibles à notre client ni à nous. Pour plus de détails, veuillez vous référer à la section Sécurité de cette documentation.
 
Traitement

Nous traitons les données personnelles conformément à l'Addendum de traitement des données que nous signons avec nos clients. Nous pouvons accéder aux données lorsque cela est nécessaire pour fournir notre service (par exemple, pour enquêter sur des bugs ou aider nos clients de diverses manières en fonction de leurs demandes). Nous pouvons utiliser les données à des fins statistiques et analytiques internes ; cependant, elles sont toujours anonymisées et nous respectons les obligations contractuelles. Veuillez vous référer à la section Sous-traitants qui liste les entreprises tierces agissant en tant que sous-traitants des données des clients, ou une partie de celles-ci.
 
Conservation des données

Nous conservons les données personnelles aussi longtemps que nécessaire, en fonction des objectifs pour lesquels elles ont été fournies ou collectées. Étant donné que nous agissons en tant que sous-traitant pour les données personnelles que nos clients (les responsables du traitement) collectent, nous sommes soumis à leurs instructions sur la manière de gérer ces données. Il incombe au client de s'assurer que les périodes de conservation applicables aux données personnelles sont conformes à la législation. Pour permettre à nos clients de gérer les périodes de conservation, nous leur offrons la possibilité de :
  • Effacer manuellement l'intégralité du profil client et des données personnelles qui y sont stockées. Cela affecte tous les points de données mentionnés ci-dessus, et la suppression complète des données est effectuée.
  • Mettre en place un nettoyage automatique des profils clients après une période spécifiée sans utilisation. Dans ce cas, le système effectue ce qui aurait autrement dû être fait manuellement en utilisant la première option.

En ce qui concerne les données de paiement, nos clients peuvent facilement définir la période, en jours, après laquelle les informations de la carte de paiement du client seront automatiquement supprimées. Il s'agit d'un processus automatisé qui efface toutes les données de carte liées au profil du client. L'effacement signifie que Mews ne conserve pas le token de la carte, et que PCI Proxy n'aura plus d'informations sur cette carte. Lorsque le processus est configuré, le système efface tous les tokens de la base de données Mews, et la carte de PCI Proxy est également supprimée.

Lorsque nous supprimons définitivement des données d'un des stockages de données Azure que nous utilisons, Microsoft suit des normes strictes pour écraser les ressources de stockage avant leur réutilisation, ainsi que pour la destruction physique du matériel hors service.

Demandes de données

Nous fournissons des moyens à nos clients pour satisfaire les demandes de données et les demandes de suppression de données provenant de leurs clients. Nous offrons également un portail utilisateur avec une fonction de messagerie qui permet à nos clients de communiquer facilement avec leurs clients. En cas de demande adressée à notre Délégué à la Protection des Données (dpo@mews.com) qui est destinée à nos clients et non à nous, nous transférons cette demande au destinataire approprié.

Données de nos utilisateurs

Les données entrent dans le système uniquement manuellement, lorsque l'utilisateur remplit ou met à jour son profil, ou lors de l'inscription. Pour offrir la meilleure expérience, par exemple lors de l'enregistrement dans un nouvel hôtel, nos utilisateurs peuvent enregistrer toute donnée que n'importe quel hôtel pourrait avoir besoin pour le processus d'enregistrement. Il appartient aux utilisateurs de décider s'ils souhaitent partager leurs données avec un client particulier et dans quelle mesure.

En plus de ces points de données partageables, nous enregistrons les noms d'utilisateur, les mots de passe (hachés), les moyens d'authentification 2FA, ainsi que d'autres détails nécessaires à une utilisation sans friction de notre plateforme.
 
Nous traitons les données personnelles de nos utilisateurs conformément à notre politique de confidentialité Mews.

Conservation des données

En raison de la nature du produit, dont la fonction principale est de servir de portefeuille de données personnelles pouvant être utilisé à tout moment dans le futur pour partager les données avec nos clients, les données sont conservées tant que l'utilisateur a un compte chez nous.
 
Demandes de données

Le portail utilisateur fournit aux utilisateurs l'accès à toutes les données personnelles que nous stockons ainsi que la possibilité de supprimer leur profil. Une autre option est de contacter directement notre DPO à dpo@mews.com.

Sous-traitants

Pour soutenir la fourniture de nos services, Mews engage et utilise des prestataires de services ayant accès à certaines données personnelles. Un sous-traitant tiers est un service que nous, en tant que sous-traitant de données, utilisons pour fournir des services à nos clients (hôtels) qui sont responsables du traitement des données. 

Nous sélectionnons ces sous-traitants tiers avec beaucoup de soin et exigeons d'eux au minimum un audit/certification SOC 2, PCI-DSS ou un autre équivalent dans l'industrie. 

Pour la fourniture de nos services, nous faisons appel aux sous-traitants suivants : 

  • Microsoft Corporation – États-Unis – Infrastructure, stockage de données, autres services. Les données sont stockées dans l'Union européenne. 
  • Google Ireland, Ltd. – Irlande – Notifications push, autres services. Les données sont stockées aux États-Unis. 
  • SFDC Ireland, Ltd. – Irlande – Support technique, portail communautaire. Les données sont stockées dans l'Union européenne. 
  • Datatrans AG – Suisse – Tokenisation des cartes de crédit. Les données sont stockées en Suisse. 
  • Twilio, Inc. – États-Unis – Envoi de courriels et messages texte. Les données sont stockées aux États-Unis. 
  • Learnupon, Ltd. – Irlande – Système de gestion de l'apprentissage. Les données sont stockées dans l'Union européenne. 
  • Aircall SAS – France – Système téléphonique intégré basé sur le cloud. Les données sont stockées aux États-Unis.  
  • OKTA, Inc. – États-Unis – Logiciel de gestion des identités et des accès basé sur le cloud. Les données sont stockées dans l'Union européenne. 
  • Gooddata Ireland Limited – Irlande – Plateforme d'analyse et de business intelligence basée sur le cloud. Les données sont stockées dans l'Union européenne. 
  • Cloudflare, Inc. – États-Unis – Réseau de diffusion de contenu. Les données sont stockées partout dans le monde. Le trafic est automatiquement dirigé vers le centre de données le plus proche. 
  • Confluent Europe LTD – Plateforme de diffusion de données en temps réel basée sur le cloud. Les données sont stockées dans l'Union européenne. 

Dans certains cas, Mews peut faire appel à des prestataires de services (partenaires certifiés) qui fournissent des services de consultation professionnelle et de déploiement au nom de Mews pour des clients spécifiques (hôtels) qui achètent ces services auprès de Mews. Le choix du prestataire de services et de son emplacement peut varier en fonction de la disponibilité et de la localisation du client. 

Filiales

Le groupe Mews comprend les filiales suivantes :
  • Mews Systems B.V. – Pays-Bas
  • Mews Systems, s.r.o. – République tchèque
  • Mews Systems, Ltd. – Royaume-Uni
  • Mews Systems Sarl – France
  • Mews Systems GmbH – Allemagne
  • Mews Systems Iberica S.L. – Espagne
  • Mews Systems, S.R.L. – Italie
  • Mews Systems, Pty Ltd. – Australie
  • Mews Systems, Inc. – États-Unis
  • Planet Winner, BVBA – Belgique
  • PMS Winner, AB – Suède
  • Databasics Hospitality System, Ltd. – Royaume-Uni
  • Bizzon Limited – Royaume-Uni
  • Bizzon d.o.o. – Croatie
  • Cenium Scandinavia AS – Norvège
  • Cenium North America Inc – États-Unis
  • Mingus Software Inc – Canada

Certifications

Notre approche des certifications consiste à les évaluer au cas par cas et de manière ponctuelle. Nous ne sommes pas proactifs dans ce domaine, car bien que certaines certifications puissent être utiles pour améliorer certains processus et garantir que ce que nous faisons est considéré comme une bonne pratique, nous constatons également que certaines certifications ont du mal à suivre les nouvelles technologies et les pratiques modernes de développement logiciel. Par conséquent, nous entreprenons uniquement les certifications qui ont du sens pour nous ou qui sont absolument nécessaires. Actuellement, nous avons les certifications suivantes :