Politique de sécurité

15 juin 2026

Sommaire

Streya Technologies Inc. offre une plateforme sécurisée qui permet aux organisations de poser des questions d’affaires sur leurs propres données et d’obtenir des réponses prêtes à la décision, fondées sur des mesures validées. Streya se connecte à l’entrepôt de données d’un client, l’interroge en temps réel avec un accès en lecture seule et renvoie des réponses sous forme de cartes, de graphiques et de tableaux dans des conversations et des tableaux de bord. Ce document présente notre programme de sécurité, conçu pour protéger les données des clients, maintenir l’intégrité des systèmes et s’aligner sur les normes de l’industrie, dont le RGPD et le droit canadien de la vie privée (notamment la Loi 25 du Québec). Streya est en cours d’obtention de la certification SOC 2.

Notre approche de la sécurité repose sur cinq principes fondamentaux :

  1. Architecture « zéro confiance » : nous vérifions chaque demande d’accès, quelle qu’en soit la source ou l’emplacement.
  2. Protection de la vie privée dès la conception : nous ne recueillons, ne stockons et ne traitons des données qu’avec une justification d’affaires claire et des protections appropriées.
  3. Privilège minimal : nous accordons les autorisations en fonction des exigences du poste et révisons régulièrement les droits d’accès.
  4. Sécurité dès la conception : nous intégrons les contrôles de sécurité dans nos produits et services, de la planification initiale au développement et au déploiement.
  5. Surveillance continue : nous surveillons nos systèmes en continu, analysons les données de sécurité et réagissons rapidement aux menaces potentielles.

Nous voulons que les utilisateurs d’affaires comprennent pleinement les mesures en place pour protéger leurs données :

  • Vos données restent dans votre entrepôt. Streya interroge votre entrepôt de données en temps réel avec un accès en lecture seule. Elle ne copie pas, n’ingère pas et ne stocke pas vos données d’entrepôt. Les seules données que Streya conserve pour votre compte sont vos identifiants de connexion chiffrés, votre modèle sémantique et les conversations et tableaux de bord que vous créez.
  • Vous contrôlez ce à quoi Streya peut accéder. Les connexions sont en lecture seule et limitées à votre espace de travail. Au moyen des politiques d’accès, vous pouvez restreindre des colonnes et des lignes et masquer des valeurs sensibles — y compris masquer les renseignements personnels identifiables (RPI) pour l’agent IA, afin qu’il puisse raisonner sur la forme de vos données sans jamais lire de renseignements personnels bruts.
  • Vérification indépendante. Notre architecture de sécurité fait l’objet d’examens par des tiers afin de valider nos contrôles et notre alignement sur les normes de l’industrie. Notre plus récente évaluation indépendante a été réalisée en 2025.

Cette politique s’applique à l’ensemble des employés, des clients, des utilisateurs et des partenaires de la plateforme Streya. Toutes les parties sont tenues de respecter ces politiques selon leur rôle.

1. Gouvernance et administration

1.1 Parties concernées

Ce document traite de la relation de sécurité entre :

  • Streya Technologies Inc. (« Fournisseur ») : entité juridique constituée au Canada (6570 Av. de l’Esplanade, Montréal, QC, Canada, H2V 4L5)
  • Employés : les personnes employées par Streya Technologies Inc.
  • Clients : les organisations qui utilisent l’application Streya
  • Utilisateurs : les membres de l’organisation d’un client qui utilisent l’application Streya

1.2 Direction de la sécurité

Contrôleur de la sécurité :
Matthew Bélair, chef de la direction
matthew@streya.app
(514) 291-7424

Le contrôleur de la sécurité est responsable de :

  • Superviser le programme de sécurité
  • Approuver les accès aux systèmes sensibles
  • Gérer le processus de réponse aux incidents
  • Veiller au respect de la présente politique de sécurité
  • Agir comme point de contact principal pour les questions de sécurité

1.3 Application de la politique

Les violations de cette politique peuvent entraîner :

  • Une formation corrective de sensibilisation à la sécurité
  • La révocation de l’accès aux systèmes
  • Des mesures disciplinaires pouvant aller jusqu’au congédiement
  • Des poursuites judiciaires, le cas échéant

Toutes les mesures d’application seront documentées et soumises à un examen approprié.

2. Cadre de protection des données

2.1 Ce que Streya stocke — et ce qu’elle ne stocke pas

Streya ne copie pas, n’ingère pas et ne stocke pas les données d’entrepôt du client. L’agent interroge l’entrepôt du client en temps réel, avec un accès en lecture seule, et uniquement lorsqu’une réponse est requise.

Les renseignements que Streya stocke pour le compte d’un client se limitent à :

  • Les identifiants de connexion — chiffrés et conservés dans un gestionnaire de secrets dédié (AWS). Utilisés uniquement pour exécuter des requêtes en lecture seule sur l’entrepôt du client.
  • Le modèle sémantique — les définitions de mesures et d’ensembles de données du client (cubes, vues, descriptions).
  • Les conversations et tableaux de bord — les réponses et les visuels créés dans un espace de travail, lesquels peuvent contenir des résultats de requêtes renvoyés par l’entrepôt.

Les clients contrôlent ce à quoi le Service peut accéder. Les connexions sont en lecture seule et limitées à un seul espace de travail. Les politiques d’accès permettent aux clients de restreindre des colonnes (sécurité au niveau des membres), de restreindre des lignes (sécurité au niveau des lignes) et de masquer des valeurs. L’usage canonique du masquage concerne les RPI : les colonnes sensibles peuvent être masquées pour l’agent IA afin qu’il raisonne sur la forme des données sans jamais lire de renseignements personnels bruts, tandis que les utilisateurs autorisés peuvent tout de même voir les valeurs réelles.

2.2 Demandes de suppression de données

Les clients peuvent demander la suppression permanente des données associées à une connexion — y compris son modèle sémantique, ses conversations et ses tableaux de bord. À la réception d’une telle demande, Streya retirera les données visées de tous les systèmes actifs et des sauvegardes dans les délais permis par la loi, sous réserve de toute exigence réglementaire ou contractuelle de conservation applicable. Comme les données d’entrepôt ne sont jamais stockées par Streya, la suppression d’une connexion met aussi fin à l’accès de Streya aux données sous-jacentes. Les actions de suppression sont journalisées et vérifiées par le contrôleur de la sécurité.

2.3 Contrôles d’accès aux données

  1. Streya applique des contrôles d’accès fondés sur le principe du privilège minimal. Les employés ne reçoivent que l’accès nécessaire à l’exercice de leurs fonctions.

  2. L’accès administratif aux systèmes de production exige :

    • L’authentification multifactorielle (AMF)
    • L’approbation explicite du contrôleur de la sécurité
    • Une justification d’affaires

  3. Les droits d’accès aux systèmes de production sont révisés trimestriellement afin de demeurer appropriés.

  4. L’accès aux systèmes sensibles est automatiquement révoqué lorsque le statut d’un employé change (p. ex. congédiement, changement de rôle).

  5. Les journaux d’accès sont conservés et examinés régulièrement pour détecter les tentatives d’accès non autorisé.

2.4 Chiffrement des données

  1. Toutes les données au repos sont chiffrées au moyen du chiffrement AES-256, conforme aux normes de l’industrie.

  2. Toutes les données en transit sont chiffrées au moyen de TLS 1.2 ou supérieur.

  3. Les identifiants de connexion sont chiffrés et conservés dans un gestionnaire de secrets dédié, avec des contrôles d’accès stricts et une rotation des clés.

  4. Les renseignements personnels identifiables (RPI) dans les données du client peuvent être masqués pour l’agent IA et pour les utilisateurs non autorisés au moyen des politiques d’accès, selon la sensibilité des données et la configuration du client.

  5. La mise en œuvre du chiffrement est révisée annuellement par des professionnels de la sécurité qualifiés.

2.5 Prévention des fuites de données

  1. L’exposition de renseignements dans les journaux et les systèmes de surveillance est strictement interdite. Le contenu des journaux est géré de manière à empêcher l’inclusion de données sensibles.

  2. Toute activité d’API non autorisée ou anormale déclenche des alertes au contrôleur de la sécurité, qui peut bloquer les adresses IP fautives.

  3. Après plusieurs tentatives de connexion infructueuses, les comptes d’utilisateurs sont automatiquement verrouillés et le contrôleur de la sécurité est avisé.

  4. Des tests d’intrusion et des analyses de vulnérabilité réguliers vérifient l’efficacité des contrôles de protection des données.

  5. Les tentatives d’accès à des données hors de la portée d’autorisation d’un utilisateur sont bloquées et déclenchent des alertes.

3. Gestion des accès

3.1 Exigences d’authentification

L’authentification des utilisateurs est assurée par Clerk. La plateforme applique :

  1. Des exigences de mot de passe robuste pour tous les utilisateurs :

    • Au moins 8 caractères
    • Une force de mot de passe minimale est exigée
    • Le rejet des mots de passe compromis, vérifiés au moyen de bases de données de fuites connues (p. ex. HaveIBeenPwned)

  2. L’authentification multifactorielle (AMF) pour :

    • Tout accès des employés aux systèmes de l’entreprise
    • Les comptes administrateurs des clients
    • L’accès aux données ou fonctions sensibles

  3. L’intégration de l’authentification unique (SSO), offerte et recommandée pour les clients d’entreprise.

  4. La détection des robots et des attaques par force brute, avec blocage automatique des activités suspectes.

  5. La protection contre les fuites de mots de passe, qui alerte les utilisateurs si leurs identifiants apparaissent dans des bases de données de fuites connues.

3.2 Contrôles d’autorisation

  1. Le contrôle d’accès basé sur les rôles (RBAC) régit l’accès aux systèmes. L’accès est organisé à deux niveaux — l’organisation et l’espace de travail — avec des rôles prédéfinis pour chacun.

  2. L’accès aux données d’un espace de travail et aux réponses qu’il contient est limité aux utilisateurs autorisés au sein de l’organisation du client.

  3. Les politiques d’accès appliquent la sécurité au niveau des colonnes, la sécurité au niveau des lignes et le masquage des données au sein d’un espace de travail.

  4. Les tentatives d’accès hors de la portée autorisée d’un utilisateur sont bloquées et déclenchent des alertes.

  5. L’accès aux comptes privilégiés est limité au personnel essentiel et fait l’objet d’une surveillance renforcée.

4. Gestion des risques liés aux tiers

4.1 Évaluation des sous-traitants ultérieurs

  1. Tous les sous-traitants ultérieurs font l’objet d’une évaluation de sécurité avant leur engagement, notamment :

    • L’examen des certifications de sécurité (SOC 2, ISO 27001, etc.)
    • L’évaluation des politiques et des capacités de protection des données
    • L’évaluation des procédures de réponse aux incidents
    • La vérification de la conformité aux lois et règlements applicables

  2. Les sous-traitants ultérieurs doivent atteindre ou dépasser les exigences de sécurité de Streya et s’engager contractuellement à maintenir ces normes.

  3. Les sous-traitants ultérieurs actuels comprennent :

    • Amazon Web Services (AWS) : hébergement infonuagique et gestion des secrets, dans la région Canada Centre (ca-central-1) (conforme SOC 2 Type 2, ISO 27001).
    • Anthropic : les grands modèles de langage (Claude) qui propulsent l’agent Streya. En vertu des conditions commerciales d’utilisation d’Anthropic — qui régissent l’utilisation de l’API par Streya et incluent un addendum relatif au traitement des données — Anthropic n’entraîne pas ses modèles sur les entrées ou les sorties soumises par l’intermédiaire de son API.
    • Clerk : services d’authentification (conforme SOC 2 Type 2).

4.2 Gestion continue des sous-traitants ultérieurs

  1. Tous les sous-traitants ultérieurs sont officiellement réévalués au moins une fois par année afin de vérifier le maintien de leur conformité.

  2. Les clients sont avisés 30 jours à l’avance de tout changement important aux relations avec les sous-traitants ultérieurs.

  3. Les sous-traitants ultérieurs sont contractuellement tenus de signaler les incidents de sécurité susceptibles de toucher les données des clients.

  4. Une liste à jour des sous-traitants ultérieurs est maintenue et mise à la disposition des clients sur demande.

5. Sécurité du personnel

5.1 Obligations des employés

  1. Tous les employés doivent suivre une formation de sensibilisation à la sécurité :

    • À l’embauche
    • Annuellement par la suite
    • À la suite de changements importants à la politique de sécurité

  2. Les employés doivent activer et utiliser l’AMF sur tous les systèmes de l’entreprise et des tiers. Le contrôleur de la sécurité en vérifie le respect périodiquement.

  3. Les employés doivent respecter une politique de « bureau propre », en veillant à ce que :

    • Les ordinateurs soient verrouillés lorsqu’ils sont laissés sans surveillance
    • Les renseignements sensibles ne soient pas laissés à la vue
    • Les appareils mobiles soient sécurisés lorsqu’ils ne sont pas utilisés

  4. Des mots de passe robustes et uniques doivent être utilisés pour tous les systèmes de l’entreprise, conformément à la section sur les exigences d’authentification.

  5. Des vérifications des antécédents sont effectuées pour tous les employés avant qu’ils n’obtiennent accès à des systèmes ou des données sensibles.

5.2 Pratiques de travail sécuritaires

  1. Le partage de renseignements est limité aux systèmes et canaux de communication approuvés par l’entreprise.

  2. Les télétravailleurs doivent prendre des précautions supplémentaires, notamment :

    • Travailler dans des lieux privés
    • Sécuriser leurs appareils lorsqu’ils ne sont pas utilisés
    • N’utiliser que des appareils approuvés pour accéder aux systèmes de l’entreprise

  3. Les employés doivent signaler immédiatement les préoccupations de sécurité au contrôleur de la sécurité, notamment :

    • Les appareils perdus ou volés
    • Les soupçons d’atteinte à la protection des données
    • Les violations potentielles de la politique
    • Les vulnérabilités de sécurité

5.3 Procédures de fin d’emploi

  1. Les employés dont l’emploi prend fin doivent :

    • Remettre tout l’équipement de l’entreprise
    • Remettre tous les documents contenant des renseignements sensibles
    • Voir tous leurs accès aux systèmes révoqués immédiatement

  2. Les obligations légales de confidentialité subsistent après la fin de l’emploi.

6. Réponse aux incidents

6.1 Catégories d’incidents

Les incidents de sécurité sont classés comme suit :

  • Critique : atteinte confirmée à la protection des données, compromission d’un système ou autre événement ayant un impact d’affaires important
  • Majeur : exposition soupçonnée de données, perturbation importante d’un système ou activité d’une menace persistante avancée
  • Mineur : violation isolée de la politique, maliciel circonscrit ou autre événement de portée limitée

6.2 Processus de réponse aux incidents

  1. Détection et signalement : tous les employés doivent signaler immédiatement les incidents de sécurité soupçonnés au contrôleur de la sécurité.

  2. Évaluation et classification : le contrôleur de la sécurité évalue et classe les incidents signalés.

  3. Confinement : des actions immédiates sont prises pour contenir l’incident et prévenir d’autres dommages.

  4. Enquête : une enquête approfondie est menée pour déterminer la portée et l’impact.

  5. Correction : des actions sont prises pour traiter la cause profonde et prévenir toute récurrence.

  6. Notification : les parties touchées sont avisées conformément aux obligations contractuelles et aux exigences réglementaires, y compris les obligations de notification d’atteinte prévues par les lois applicables sur la protection de la vie privée (comme la Loi 25 et le RGPD).

  7. Documentation : tous les incidents et les mesures de réponse sont documentés en détail.

7. Conformité et audit

7.1 Évaluations de sécurité

  1. Streya réalise des évaluations de sécurité régulières, notamment :

    • Des tests d’intrusion annuels
    • Des analyses de vulnérabilité trimestrielles
    • Une surveillance de sécurité automatisée et continue
    • Des examens réguliers de la sécurité du code

  2. Les résultats des évaluations de sécurité sont examinés par le contrôleur de la sécurité et traités selon le niveau de risque.

8. Continuité des affaires

8.1 Sauvegarde et récupération des données

  1. Les données que Streya stocke (identifiants, modèles sémantiques, conversations et tableaux de bord) sont sauvegardées régulièrement, avec une conservation conforme aux exigences de classification des données.

  2. Les systèmes de sauvegarde sont chiffrés et soumis aux mêmes contrôles de sécurité que les systèmes de production.

  3. La restauration des sauvegardes est testée périodiquement pour assurer la récupérabilité.

8.2 Reprise après sinistre

  1. Streya maintient des capacités de reprise après sinistre conçues pour :

    • Reprendre les opérations critiques dans un délai de 4 heures
    • Rétablir l’ensemble du service dans un délai de 24 heures
    • Prévenir la perte de données au moyen de systèmes redondants

  2. Le plan de reprise après sinistre est testé annuellement et mis à jour au besoin.

9. Utilisation de l’intelligence artificielle (IA)

L’intelligence artificielle est au cœur de la plateforme Streya : l’agent Streya utilise de grands modèles de langage pour interpréter les questions, planifier les requêtes et expliquer les résultats. Toute utilisation de l’IA respecte les exigences de sécurité, de confidentialité et de conformité énoncées dans la présente politique.

  1. Ce qui est transmis au modèle. Pour répondre à une question, Streya peut transmettre à l’agent le texte de la question de l’utilisateur, les métadonnées du modèle sémantique (comme les définitions de tables, de dimensions et de mesures) et les résultats de requêtes renvoyés par l’entrepôt du client. Les champs sensibles peuvent être masqués pour l’agent au moyen des politiques d’accès.

  2. Fournisseur. L’agent Streya est propulsé par les modèles d’Anthropic (Claude), accédés par l’intermédiaire de l’API d’Anthropic en vertu de ses conditions commerciales d’utilisation.

  3. Aucun entraînement sur les données du client. Les données du client ne servent jamais à entraîner ou à peaufiner des modèles d’IA. En vertu des conditions commerciales d’utilisation d’Anthropic — qui régissent l’utilisation de l’API par Streya et incluent un addendum relatif au traitement des données — Anthropic n’entraîne pas ses modèles sur les entrées ou les sorties soumises par l’intermédiaire de son API.

  4. Gouvernance et supervision. Les cas d’utilisation de l’IA sont examinés et approuvés par le contrôleur de la sécurité afin d’assurer la conformité aux lois, aux règlements et aux ententes avec les clients.

  5. Transparence. Comme l’IA fait partie intégrante du Service, les clients sont informés de la façon dont leurs données sont traitées par l’agent au moyen de la présente politique et de l’addendum relatif au traitement des données.

10. Gestion de la politique

10.1 Révision de la politique

Cette politique sera révisée :

  • Au moins une fois par année
  • À la suite d’incidents de sécurité importants
  • Lorsque des changements aux pratiques d’affaires ou à la réglementation l’exigent

Glossaire

  • AES-256 : Advanced Encryption Standard avec une clé de 256 bits, un algorithme de chiffrement robuste utilisé pour protéger les données
  • AMF : authentification multifactorielle — exiger deux méthodes de vérification ou plus pour accorder l’accès
  • RPI : renseignements personnels identifiables — données pouvant servir à identifier une personne
  • RBAC : contrôle d’accès basé sur les rôles — restreindre l’accès aux systèmes selon les rôles des utilisateurs
  • Modèle sémantique : la couche qui définit la signification des données d’un client — quelles tables comptent, comment elles se joignent et comment les mesures sont calculées — de sorte que chaque réponse utilise les mêmes définitions approuvées
  • SOC 2 : Service Organization Control 2 — une norme d’audit pour les organisations de services
  • SSO : authentification unique — un schéma d’authentification permettant à un utilisateur de se connecter une seule fois pour accéder à plusieurs systèmes
  • TLS : Transport Layer Security — protocoles cryptographiques assurant la sécurité des communications sur un réseau

Pour toute question concernant ce document, veuillez communiquer avec le contrôleur de la sécurité.

Matthew Bélair, chef de la direction
matthew@streya.app
(514) 291-7424