Aperçu de sécurité

Le présent Aperçu de sécurité est publié par la Société. L'identité complète de la Société, son adresse et ses coordonnées légales figurent au bas de la présente page.

La sécurité de vos données et de celles de vos utilisateurs finaux est une condition d'existence du Service, pas une fonctionnalité parmi d'autres. Ce document décrit, en langage clair, les contrôles techniques et organisationnels réellement en place sur la Plateforme — isolement des données, chiffrement, gestion des accès, journalisation, encadrement des sous-traitants et gestion des incidents. Nous avons choisi d'y être précis plutôt qu'exhaustifs : chaque affirmation ci-dessous correspond à un contrôle vérifiable, et nous préférons décrire honnêtement ce qui existe aujourd'hui plutôt que de laisser entendre plus que ce que nous pouvons démontrer.

1. Notre approche de la sécurité

> En bref : la sécurité est intégrée à la conception de la Plateforme, pas ajoutée après coup — et notre programme évolue en continu à mesure que le Service grandit.

Le Service héberge des agents conversationnels IA (texte et voix) opérant pour le compte de multiples organisations clientes sur une infrastructure partagée. Cette réalité multi-tenant façonne notre philosophie de sécurité : chaque contrôle décrit dans ce document part du principe qu'aucune organisation cliente ne doit jamais pouvoir accéder, directement ou indirectement, aux données d'une autre.

Nous appliquons une approche de sécurité par conception : les contrôles d'isolement, d'accès et de traçabilité ne sont pas des ajouts périphériques mais des propriétés structurelles de la manière dont la Plateforme est construite, au niveau de la base de données comme au niveau applicatif. Cette approche s'accompagne d'un principe de moindre privilège — chaque composant, chaque rôle et chaque intégration ne reçoit que les accès strictement nécessaires à sa fonction.

Nous sommes également transparents sur le fait qu'un programme de sécurité est, par nature, un chantier permanent plutôt qu'un état atteint une fois pour toutes. Nous documentons nos contrôles, nous les faisons évoluer à mesure que la Plateforme et les menaces changent, et nous préférons présenter ce travail tel qu'il est — réel, mesurable, en progression continue — plutôt que de le présenter comme achevé.

2. Isolement des données entre Clients

> En bref : les données de chaque organisation cliente sont séparées au niveau de la base de données elle-même, pas seulement au niveau de l'application.

Le Service repose sur une architecture multi-tenant où plusieurs organisations clientes partagent la même infrastructure applicative. L'isolement entre ces organisations est appliqué au niveau de la base de données, au moyen d'une politique de sécurité au niveau des lignes (« row-level security »), systématiquement mise en œuvre sur les tables contenant des données appartenant à plusieurs Clients.

Concrètement, cela signifie que l'accès aux données n'est pas seulement filtré par la logique applicative — qui pourrait comporter une erreur de programmation — mais également contraint directement par le moteur de base de données lui-même, à chaque requête. Une requête qui tenterait, par erreur ou par malveillance, de lire ou de modifier des données appartenant à une autre organisation cliente que celle de l'utilisateur authentifié est bloquée à la source par cette politique. Cette double couche — applicative et base de données — réduit substantiellement le risque qu'une défaillance logicielle isolée entraîne une fuite de données entre Clients.

3. Chiffrement

> En bref : vos données sont chiffrées lorsqu'elles transitent vers et depuis nos serveurs, et au repos grâce aux mécanismes de chiffrement de notre infrastructure d'hébergement.

Toutes les communications entre les utilisateurs, les intégrations et la Plateforme sont chiffrées en transit au moyen du protocole TLS (Transport Layer Security). Aucune donnée n'est transmise en clair sur le réseau public entre votre navigateur, vos systèmes intégrés et nos serveurs.

Les données au repos — c'est-à-dire stockées dans nos bases de données et nos systèmes de fichiers — sont protégées par le chiffrement conforme aux standards de l'industrie assuré par notre infrastructure d'hébergement sous-jacente. Nous nous appuyons sur des fournisseurs d'infrastructure reconnus dont les mécanismes de chiffrement au repos font partie de l'offre de base de la plateforme d'hébergement, plutôt que de gérer nous-mêmes une couche de chiffrement distincte à ce niveau.

4. Gestion des accès

> En bref : l'accès à l'espace d'administration est contrôlé par rôles, selon le principe voulant que chaque personne n'obtienne que les droits nécessaires à sa fonction.

L'espace d'administration de la Plateforme applique un contrôle d'accès basé sur les rôles (« role-based access control »). Chaque utilisateur administratif se voit attribuer un rôle qui détermine précisément les actions qu'il peut effectuer et les données auxquelles il peut accéder, plutôt qu'un accès global indifférencié.

Cette approche suit le principe du moindre privilège : les droits accordés à un rôle correspondent à ce qui est strictement requis pour exercer la fonction associée, et rien de plus. Les accès à privilèges élevés — comme la gestion des paramètres globaux du Service ou l'accès à des données sensibles à l'échelle de plusieurs organisations clientes — sont réservés à un nombre restreint de rôles définis à cette fin.

Nous précisons, par souci d'exactitude, que ce document ne présente pas l'authentification multifacteur comme un mécanisme actuellement garanti sur l'ensemble de la Plateforme; nous préférons ne rien affirmer à ce sujet plutôt que de décrire un contrôle qui ne serait pas uniformément en place.

5. Journalisation et audit

> En bref : les actions sensibles et administratives sont consignées avec horodatage, identification de l'auteur et, lorsque c'est pertinent, le motif de l'action.

La Plateforme maintient une journalisation d'audit des actions sensibles et administratives effectuées par les utilisateurs disposant d'accès élevés. Chaque entrée de journal est horodatée et associée à l'acteur ayant effectué l'action, ce qui permet de reconstituer qui a fait quoi, et quand.

Lorsque le contexte s'y prête, ces journaux conservent également le motif déclaré de l'action, apportant une couche de traçabilité supplémentaire pour les opérations administratives significatives. Cette journalisation appuie à la fois nos propres capacités de détection d'anomalies et, le cas échéant, les besoins d'investigation d'un Client sur les actions effectuées dans son propre environnement.

6. Sécurité de nos sous-traitants

> En bref : nous exerçons une diligence raisonnable sur les fournisseurs et sous-traitants qui participent à l'exploitation du Service, et nous en publions la liste.

Le Service s'appuie, comme toute plateforme SaaS moderne, sur un ensemble de fournisseurs d'infrastructure et de services tiers — notamment pour l'hébergement, le traitement de données, et certaines fonctionnalités spécialisées (par exemple, les capacités d'intelligence artificielle ou de synthèse vocale sous-jacentes aux agents conversationnels). Nous n'identifions pas ces fournisseurs nommément dans le présent document.

Nous appliquons une diligence raisonnable à la sélection et au suivi de ces sous-traitants avant de leur confier tout traitement de données lié au Service. La liste à jour des sous-traitants impliqués dans le traitement des données du Service, ainsi que la nature des traitements qui leur sont confiés, est disponible dans notre Liste des sous-traitants, un document distinct maintenu à jour et accessible aux Clients.

7. Gestion des incidents de sécurité

> En bref : nous disposons d'un processus de détection, de confinement et de traitement des incidents de sécurité, et nous respectons nos obligations légales de notification lorsqu'un incident touche des renseignements personnels.

Un incident de sécurité désigne tout événement compromettant, ou susceptible de compromettre, la confidentialité, l'intégrité ou la disponibilité des données traitées par le Service. Notre approche de gestion des incidents repose sur trois étapes : la détection de l'événement, le confinement de son impact afin d'en limiter la portée, puis l'analyse et la remédiation de la cause sous-jacente.

Lorsqu'un incident de sécurité touche des renseignements personnels d'un Client ou de ses utilisateurs finaux, nous en informons les parties concernées dans les meilleurs délais raisonnables, conformément aux obligations légales applicables — notamment celles prévues par la Loi modernisant des dispositions législatives en matière de protection des renseignements personnels (Loi 25) applicable au Québec, par la Loi sur la protection des renseignements personnels et les documents électroniques (LPRPDE/PIPEDA) applicable au Canada, ainsi que par toute autre loi sur la protection des renseignements personnels applicable selon la juridiction du Client. Nous ne nous engageons pas ici sur un délai chiffré précis : chaque incident diffère par sa nature, sa portée et la complexité de son investigation, et nos communications reflètent l'information disponible au moment où elle peut être communiquée de façon fiable, dans le respect du cadre légal applicable.

8. Signaler une vulnérabilité

> En bref : si vous croyez avoir découvert une faille de sécurité dans le Service, nous voulons en être informés rapidement et de façon responsable.

Nous accueillons les signalements de bonne foi concernant des vulnérabilités de sécurité potentielles dans le Service. Si vous identifiez ce que vous croyez être une faille de sécurité, nous vous demandons de nous la communiquer de manière responsable — c'est-à-dire de ne pas exploiter la vulnérabilité au-delà de ce qui est strictement nécessaire pour en démontrer l'existence, de ne pas accéder à des données qui ne vous appartiennent pas, et de ne pas divulguer publiquement l'information avant que nous ayons eu l'occasion raisonnable d'y remédier.

Pour signaler une vulnérabilité, veuillez utiliser les coordonnées affichées au bas de la présente page. Nous accusons réception des signalements reçus et nous nous engageons à en assurer un suivi diligent.

9. Notre posture de certification

> En bref : nos contrôles de sécurité sont réels et documentés, mais nous n'avons obtenu, à ce jour, aucune certification tierce formelle — une posture normale pour un SaaS en croissance, que nous préférons énoncer clairement.

De nombreuses plateformes SaaS affichent des certifications tierces telles que SOC 2 Type II ou ISO 27001. Nous choisissons de ne revendiquer aucune certification de ce type tant qu'elle n'a pas été formellement obtenue et auditée par un tiers indépendant. À ce jour, notre programme de sécurité repose sur des contrôles internes documentés et vérifiables — ceux décrits dans les sections précédentes du présent document — plutôt que sur un label externe.

Il s'agit d'une posture délibérée, propre à une organisation en croissance qui investit dans la maturation continue de ses pratiques de sécurité : nous préférons documenter honnêtement ce qui est en place aujourd'hui et faire évoluer ce programme de manière rigoureuse, plutôt que d'afficher une certification qui ne refléterait pas fidèlement notre état actuel. Nous évaluons périodiquement l'opportunité d'entreprendre une démarche de certification formelle, et toute évolution à ce sujet sera reflétée dans une version mise à jour du présent document.