Le guide de l’opérateur sur la sécurité des données restaurant et l’intelligence multi-tenant

La question de confiance que tout opérateur pose

Avant qu’un groupe de restaurants n’adopte une plateforme d’intelligence cloud, quelqu’un dans la salle pose la question : "Nos données sont-elles en sécurité ?"

C’est la bonne question. Les données opérationnelles d’un restaurant sont commercialement sensibles. Vos chiffres de ventes, vos coûts de main-d’œuvre, vos pourcentages de food cost, vos prix fournisseurs et votre intelligence concurrentielle représentent de vrais secrets d’affaires. Si un concurrent obtenait l’accès à vos données de P&L au niveau établissement, il saurait exactement où vous êtes vulnérable et comment vous attaquer.

Pour les opérateurs multi-sites, l’enjeu est encore plus fort. Vous ne protégez pas seulement les données d’un restaurant - vous protégez l’intelligence opérationnelle de tout un portefeuille. Et si vous utilisez une plateforme qui sert aussi vos concurrents, la question devient encore plus nette : "Comment savoir que mes données sont totalement isolées de tous les autres opérateurs de la plateforme ?"

Cet article répond à cette question en détail - non pas avec du langage marketing, mais avec des spécificités architecturales que votre équipe tech peut évaluer.

Architecture multi-tenant : vos données vivent à part

Sundae repose sur une architecture multi-tenant où les données de chaque organisation sont totalement isolées au niveau de la base de données. Voici ce que cela signifie en pratique.

Isolation des données au niveau organisation

Chaque enregistrement de données dans Sundae - chaque transaction, chaque entrée de main-d’œuvre, chaque benchmark, chaque requête d’intelligence - est tagué avec un identifiant d’organisation. Ce n’est pas un simple filtre logiciel qu’on pourrait contourner par erreur. C’est appliqué au niveau de la base via des politiques de Row-Level Security (RLS).

La Row-Level Security signifie que la base elle-même - pas le code applicatif - impose que les requêtes ne puissent retourner que les données de l’organisation authentifiée. Même s’il y avait un bug applicatif qui oubliait de filtrer par organisation, la base refuserait de renvoyer les données d’une autre organisation. C’est une stratégie de défense en profondeur : plusieurs couches de protection indépendantes, chacune suffisante en elle-même.

Ce que cela signifie concrètement :

• Quand vous vous connectez à Sundae, votre session est liée à votre organisation
• Chaque requête base de données inclut automatiquement le périmètre de votre organisation
• Il n’existe ni endpoint API, ni dashboard, ni chemin de requête qui puisse accéder aux données d’une autre organisation
• Vos données ne peuvent pas apparaître dans les benchmarks, rapports ou sorties d’intelligence d’une autre organisation (les benchmarks utilisent des données de marché anonymisées et agrégées - jamais des données brutes d’organisation)

Comment fonctionnent les benchmarks sans exposer les données

Question naturelle : si Sundae fournit des benchmarks concurrentiels, cela veut-il dire que vos données sont partagées ?

Non. Les données de benchmark sont produites par agrégation et anonymisation. Quand Sundae Benchmarks affiche que le "food cost moyen casual dining à Dubaï" est de 31,2 %, ce chiffre provient de données agrégées sur de nombreux opérateurs. Aucune donnée individuelle n’est identifiable. Les seuils d’agrégation garantissent que les catégories de benchmark contiennent toujours assez d’opérateurs pour empêcher toute rétro-ingénierie de la performance individuelle.

Vos données brutes ne sont jamais, sous aucune circonstance, visibles par une autre organisation. Les benchmarks sont des agrégats statistiques - utiles directionnellement, strictement anonymes.

Contrôle d’accès par rôle

L’isolation entre organisations est la base. Le contrôle d’accès par rôle (RBAC) au sein de votre organisation est la deuxième couche.

Comment le RBAC fonctionne dans Sundae

Tout le monde dans votre organisation ne doit pas tout voir. Le CFO a besoin des données P&L. Le responsable régional a besoin des données opérationnelles au niveau établissement. La direction marketing a besoin des données clients et campagnes. Le directeur de restaurant a besoin des données de son site, mais pas des détails financiers des autres.

Sundae applique le RBAC au niveau des fonctionnalités et des données :

• Administrateur organisation : accès complet à toutes les données, toutes les fonctionnalités, tous les sites. Peut gérer les utilisateurs et les permissions.
• Exécutif : visibilité à l’échelle du portefeuille sur tous les modules. Peut consulter mais pas modifier la configuration système.
• Responsable opérations : données opérationnelles multi-sites (ventes, main-d’œuvre, stocks, retours clients). Peut être limité à une région ou un sous-ensemble de sites.
• Manager établissement : accès à un seul établissement pour les modules opérationnels pertinents.
• Finance : accès aux modules financiers (P&L, budgets, prévisions) sur l’ensemble du portefeuille.
• Analyste : accès en lecture seule à certains modules pour le reporting et l’analyse.

Les rôles sont configurables. Si votre structure ne correspond pas aux rôles standards, les permissions peuvent être personnalisées pour s’aligner sur votre organisation réelle.

Requêtes d’intelligence en lecture seule

Sundae Intelligence - la couche IA conversationnelle - fonctionne avec un accès base de données en lecture seule. Quand un opérateur demande "Pourquoi le food cost a-t-il augmenté à l’établissement 7 la semaine dernière ?", le système exécute des requêtes analytiques sur les données. Ces requêtes sont strictement des opérations SELECT - elles peuvent lire les données pour générer des insights, mais ne peuvent ni modifier, ni supprimer, ni exporter les données brutes.

De plus, les requêtes Intelligence sont soumises à des limites de lignes et de complexité qui empêchent l’extraction massive de données. Le système est conçu pour répondre à des questions analytiques, pas pour servir d’outil d’export.

Chiffrement des données

En transit

Toutes les données transmises entre votre navigateur et les serveurs de Sundae sont chiffrées avec TLS 1.3 - la norme actuelle du transport chiffré. Cela vaut pour chaque interaction : connexion, consultation de données, appels API, uploads de fichiers et données de webhook issues d’intégrations.

Les données transmises entre les serveurs applicatifs de Sundae et les serveurs de base de données sont elles aussi chiffrées en transit, ce qui protège contre l’interception sur le réseau interne.

Au repos

Toutes les données stockées dans la base de Sundae sont chiffrées au repos avec un chiffrement AES-256. Cela signifie que même si quelqu’un accédait physiquement au matériel de stockage, les données resteraient illisibles sans les clés de chiffrement.

Les clés de chiffrement sont gérées via un service dédié de gestion des clés, séparé de l’infrastructure applicative. La rotation des clés suit les bonnes pratiques du secteur.

Chiffrement des sauvegardes

Les sauvegardes de base de données - essentielles à la reprise après sinistre - sont elles aussi chiffrées au repos. L’accès aux sauvegardes est limité aux membres de l’équipe infrastructure disposant d’une autorisation explicite, et tout accès est journalisé et auditable.

Sécurité d’authentification et de session

Authentification basée sur JWT

Sundae utilise l’authentification par JSON Web Token (JWT). Quand vous vous connectez, un jeton signé cryptographiquement est émis et encode votre identité et votre organisation. Ce jeton est stocké dans un cookie sécurisé HTTP-only auquel JavaScript côté client ne peut pas accéder - ce qui empêche les attaques XSS classiques de voler les identifiants de session.

Les jetons ont une durée de validité définie. Une fois expirés, une ré-authentification est nécessaire. Il n’existe pas d’option "se souvenir de moi pour toujours" qui laisserait une session vulnérable indéfiniment.

Isolation des sessions

Chaque session utilisateur est liée à une seule organisation. Si un opérateur gère plusieurs organisations (par exemple une société de management supervisant plusieurs groupes de restaurants), il doit changer explicitement de contexte. Il n’existe aucun moyen pour une session d’accéder simultanément à des données de plusieurs organisations, ce qui élimine le risque d’exposition accidentelle entre organisations.

Authentification multi-facteur (MFA)

Les mots de passe seuls ne suffisent pas pour protéger l’accès à des données financières et opérationnelles sensibles. Sundae prend désormais en charge l’authentification multi-facteur complète via des mots de passe à usage unique basés sur le temps (TOTP) - la même norme que les banques et les plateformes SaaS d’entreprise.

Comment cela fonctionne

Quand le MFA est activé, les utilisateurs s’authentifient avec leur mot de passe plus un code à 6 chiffres issu d’une application d’authentification (Google Authenticator, Authy, Microsoft Authenticator ou toute app compatible TOTP). Le code change toutes les 30 secondes et est lié cryptographiquement au compte utilisateur. Même si un mot de passe est compromis, l’attaquant ne peut pas accéder au compte sans l’appareil physique qui exécute l’application d’authentification.

Codes de secours

Lors de la configuration du MFA, Sundae génère un ensemble de codes de secours à usage unique. Ce sont des codes de récupération qui permettent l’accès si l’appareil d’authentification est perdu, endommagé ou remplacé. Chaque code de secours ne peut être utilisé qu’une seule fois. Nous recommandons de stocker ces codes dans un endroit sécurisé - un gestionnaire de mots de passe ou un coffre physique - séparé de l’appareil qui exécute l’application d’authentification.

Application du MFA au niveau organisation

Pour les opérateurs enterprise qui souhaitent imposer le MFA à toute leur équipe, Sundae prend en charge l’application du MFA au niveau organisation. Lorsqu’un administrateur active le MFA obligatoire, chaque utilisateur de l’organisation doit le configurer avant d’accéder à la plateforme. Il n’existe pas d’exception individuelle. C’est essentiel pour les organisations soumises à des exigences réglementaires ou à des politiques internes imposant une authentification à deux facteurs pour tout personnel accédant à des données financières.

Le réglage d’application se gère depuis la page des paramètres de sécurité de l’organisation. Une fois activé, les utilisateurs qui n’ont pas encore configuré le MFA sont redirigés vers le flux de configuration lors de leur prochaine connexion. Il n’y a pas de période de grâce - l’application est immédiate, ce qui garantit l’absence de faille de couverture.

Politiques de mot de passe

Les mots de passe faibles sont le vecteur d’attaque le plus courant contre les plateformes SaaS. Sundae applique des politiques de mot de passe configurables qui vont au-delà des exigences de complexité de base :

Exigences de complexité : longueur minimale, types de caractères requis (majuscule, minuscule, chiffres, caractères spéciaux) et blocage des mots de passe courants. Ces exigences sont appliquées à l’inscription, au changement de mot de passe et à la réinitialisation.

Verrouillage de compte : après un nombre configurable d’échecs de connexion, le compte est temporairement verrouillé. Cela empêche les attaques par force brute où un attaquant essaie des milliers de combinaisons. La durée de verrouillage et le seuil d’essais sont configurables par les administrateurs d’organisation, afin d’équilibrer sécurité et confort d’usage.

Historique des mots de passe : les utilisateurs ne peuvent pas réutiliser leurs anciens mots de passe, ce qui évite le schéma courant consistant à alterner entre deux ou trois mots de passe familiers.

Bannière d’état de sécurité : lorsque des événements liés à la sécurité surviennent - échecs de connexion, changements de politique de mot de passe, rappels d’inscription MFA - Sundae affiche des bannières de sécurité contextuelles aux utilisateurs concernés. Ce ne sont pas des messages marketing génériques. Ce sont des notifications de sécurité actionnables qui aident les utilisateurs et les administrateurs à maintenir leur posture de sécurité.

Masquage des PII

Pour les organisations ayant des exigences strictes de confidentialité, Sundae prend en charge le masquage automatique des PII (Personally Identifiable Information) dans l’interface admin. Lorsqu’il est activé, les champs sensibles - noms clients, adresses email, numéros de téléphone et autres identifiants personnels - sont partiellement ou totalement masqués dans les vues admin et les logs d’audit.

C’est particulièrement important pour les organisations soumises au RGPD, au CCPA ou à des réglementations régionales de protection des données où l’accès aux PII brutes doit être limité au personnel autorisé. Le masquage des PII permet aux équipes support, analystes et autres collaborateurs d’exercer leurs fonctions sans exposition inutile aux données personnelles.

Consentement cookies et contrôles de confidentialité

Sundae met en place un framework de consentement aux cookies conforme aux exigences du RGPD et de la directive ePrivacy :

Bannière de consentement : les visiteurs de première visite voient une bannière claire et actionnable qui explique quels cookies sont utilisés et pourquoi. Ils peuvent tout accepter, refuser les cookies non essentiels ou personnaliser leurs préférences.

Contrôles granulaires : les catégories de cookies sont présentées individuellement - essentiels (toujours actifs), analytics, marketing et fonctionnels. Les utilisateurs choisissent les catégories à activer, et leurs préférences sont respectées dans toutes les sessions.

Enregistrements de consentement : toutes les décisions de consentement sont journalisées avec horodatage et adresse IP, ce qui fournit la piste d’audit exigée par le RGPD pour démontrer un consentement valide.

Sécurité de l’infrastructure

Infrastructure cloud

Sundae tourne sur une infrastructure cloud de niveau enterprise avec :

• Isolation réseau : les serveurs applicatifs et les serveurs de base de données opèrent dans des réseaux privés, non directement accessibles depuis Internet
• Règles de firewall : seuls les ports et protocoles nécessaires sont ouverts. Tout le reste est bloqué par défaut.
• Protection DDoS : mitigation des attaques par déni de service distribué à la périphérie du réseau
• Patchs automatisés : correctifs de sécurité du système d’exploitation et de l’environnement appliqués automatiquement
• Résidence géographique des données : les données sont stockées dans des régions conformes aux réglementations locales de protection des données

Surveillance et alerting

Toute l’infrastructure est surveillée en continu pour détecter :

• les tentatives d’accès non autorisé
• les schémas de requête inhabituels qui pourraient indiquer une tentative d’exfiltration
• les anomalies de performance qui pourraient signaler un incident de sécurité
• les changements de configuration susceptibles d’affaiblir la posture de sécurité

Les alertes de sécurité sont envoyées à l’équipe d’ingénierie 24 h / 24 et 7 j / 7 avec des SLA de réponse définis.

Conformité et préparation à l’audit

Parcours SOC 2

Sundae suit un parcours défini vers la certification SOC 2 Type II, la référence du secteur pour la sécurité et la disponibilité des SaaS. Cela implique :

• Des politiques et procédures de sécurité formalisées
• Des évaluations de sécurité régulières et des tests d’intrusion
• Des procédures de réponse aux incidents
• La gestion de la sécurité des fournisseurs
• La formation sécurité des collaborateurs

Pour les prospects enterprise qui exigent la certification SOC 2 comme prérequis d’achat, nous pouvons partager notre statut de conformité actuel, les réponses au questionnaire sécurité et le calendrier de certification.

RGPD et protection des données

Pour les opérateurs ayant des clients ou employés européens, l’architecture de Sundae prend en charge la conformité RGPD :

• Minimisation des données : nous ne collectons que ce qui est nécessaire à la fonctionnalité d’intelligence
• Droit à l’effacement : les données d’une organisation peuvent être purgées sur demande
• Portabilité des données : les organisations peuvent exporter leurs données dans des formats standards
• Registres de traitement : nous tenons les registres des activités de traitement comme l’exige le RGPD

Journalisation d’audit

Chaque action significative dans Sundae est journalisée :

• Connexions et déconnexions utilisateur
• Schémas d’accès aux données
• Changements de configuration
• Modifications de permissions
• Requêtes d’intelligence
• Exportations de données

Ces logs d’audit sont immuables (ils ne peuvent pas être modifiés ni supprimés) et accessibles aux administrateurs d’organisation à des fins de conformité et d’audit interne.

Ce que nous ne faisons pas

La transparence sur ce que nous ne faisons pas est aussi importante que la description de ce que nous faisons :

• Nous ne vendons pas vos données. Vos données opérationnelles vous appartiennent. Point. Nous ne les monétisons pas, ne les partageons pas avec des tiers et ne les utilisons pour aucune autre fin que vous fournir des services d’intelligence.
• Nous n’entraînons pas de modèles IA sur vos données. Les données de votre organisation ne servent pas à entraîner des modèles de machine learning destinés à d’autres clients. Les modèles d’intelligence sont entraînés sur des données sectorielles anonymisées et agrégées - jamais sur des données organisationnelles identifiables.
• Nous ne fournissons pas d’accès de secours caché. Il n’existe pas de "mode admin" permettant aux employés de Sundae de parcourir vos données à leur guise. L’accès interne aux données client nécessite une autorisation explicite, est journalisé et limité aux fonctions support et engineering avec un besoin métier documenté.
• Nous ne conservons pas vos données après résiliation. Si vous quittez Sundae, vos données vous sont exportées puis purgées de nos systèmes dans une fenêtre de rétention définie. Nous ne gardons pas vos données historiques comme levier de rétention.

La conversation sécurité avec l’entreprise

Pour les groupes hôteliers enterprise qui évaluent Sundae, nous savons que la sécurité n’est pas une case à cocher - c’est une relation continue. Nous accompagnons :

• Réponses aux questionnaires sécurité : réponses détaillées à l’évaluation de votre équipe achats
• Revues d’architecture : analyses techniques approfondies avec votre équipe de sécurité IT
• Résultats de tests d’intrusion : partage des constats d’évaluations de sécurité tierces
• Exigences de sécurité personnalisées : pour les organisations ayant des besoins de conformité spécifiques (PCI-DSS pour les données de paiement, réglementations régionales, politiques internes)
• Contact sécurité dédié : une personne nommée qui gère vos questions et préoccupations de sécurité

Construire la confiance par la transparence

La sécurité des données dans l’intelligence restaurant n’est pas une fonctionnalité à marketer. C’est un engagement fondamental qui rend tout le reste possible. Si les opérateurs ne font pas confiance à la plateforme pour leurs données, les capacités d’intelligence les plus sophistiquées du monde ne valent rien.

L’approche de Sundae consiste à gagner cette confiance par des décisions architecturales (isolation multi-tenant, RLS, chiffrement), des pratiques opérationnelles (surveillance, patching, réponse aux incidents) et la transparence (cet article, la documentation sécurité, des échanges directs avec votre équipe technique).

Vos données restaurant sont votre avantage concurrentiel. Les protéger n’est pas négociable - c’est le prérequis de base de tout ce que Sundae délivre.

Réservez une démo pour discuter des besoins sécurité spécifiques de votre organisation et voir comment l’architecture de Sundae protège vos données tout en délivrant une intelligence à l’échelle du portefeuille.