Déclaration de sécurité des informations et des données

Mis à jour le 26 mai 2026

Merci de faire confiance à Stamped pour les données de votre cabinet. Nous prenons cette responsabilité très au sérieux et nous nous efforçons d'être transparents quant aux mesures techniques et organisationnelles mises en place pour protéger vos données.

La sécurité chez Stamped est supervisée par la direction technique et mise en œuvre par l'ensemble de l'équipe. Toutes nos pratiques sont conçues pour être conformes à la Loi 25 du Québec, à la LPRPDE (PIPEDA) du Canada et, lorsqu'il s'applique, au RGPD.

Divulgation de vulnérabilités

Pour signaler une vulnérabilité, écrivez à engineering@stamped.ai en incluant une preuve de concept, la liste des outils utilisés et les résultats obtenus. Nous travaillons rapidement à reproduire chaque vulnérabilité signalée afin d'en vérifier l'état avant d'y remédier. Stamped s'engage à ne pas poursuivre les chercheurs en sécurité qui agissent de bonne foi conformément aux pratiques de divulgation responsable.

Conformité et cadres de référence

Loi 25 (Québec) et LPRPDE (Canada)

Stamped exerce ses activités à partir du Québec et se conforme à la Loi modernisant des dispositions législatives en matière de protection des renseignements personnels (« Loi 25 ») ainsi qu'à la Loi sur la protection des renseignements personnels dans le secteur privé (RLRQ, chap. P-39.1). Nous effectuons des évaluations des facteurs relatifs à la vie privée (ÉFVP) avant tout transfert hors Québec, tenons un registre des incidents de confidentialité et nommons une personne responsable de la protection des renseignements personnels (engineering@stamped.ai). Nous nous conformons également à la LPRPDE au niveau fédéral.

RGPD

Stamped traite les renseignements personnels conformément aux principes du Règlement général sur la protection des données (RGPD) lorsque celui-ci s'applique. Les demandes relatives aux droits des personnes concernées peuvent être adressées à engineering@stamped.ai.

PCI DSS (via Stripe)

Le traitement des paiements est confié à Stripe, fournisseur de services certifié PCI DSS de niveau 1. Stamped ne stocke pas de numéros de carte de paiement complets ni de codes de sécurité sur son infrastructure.

ISO/IEC 27001

Le programme de sécurité de Stamped est aligné sur les contrôles de la norme ISO/IEC 27001. Stamped n'est pas actuellement certifié ISO 27001 ou SOC 2. Nous nous appuyons par ailleurs sur des fournisseurs d'infrastructure (Google Cloud Platform, Cloudflare) qui maintiennent ces certifications pour leurs propres environnements.

Hébergement et résidence des données

Notre infrastructure est hébergée sur Google Cloud Platform, dans la région du Canada (Montréal — northamerica-northeast1). Les composantes principales :

• Cloud Run — exécution applicative (couche web 2–6 instances, files de travail 2–4 instances) avec mise à l'échelle automatique;
• Cloud SQL pour PostgreSQL — base de données principale, réplica en lecture seule et base de réplication dédiée à l'ingestion des journaux d'audit;
• Cloud Memorystore (Redis) — deux instances distinctes (file de traitement Sidekiq en haute disponibilité et cache applicatif), avec authentification et chiffrement en transit;
• Cloudflare en amont de l'équilibreur de charge Google Cloud, avec Cloud Armor pour les règles WAF — DNS également géré chez Cloudflare;
• Cloud Logging et Sentry pour la journalisation applicative et la surveillance des erreurs;
• AWS S3 via ActiveStorage pour le stockage des pièces jointes téléversées par les utilisateurs.

L'ensemble de l'infrastructure est défini et versionné en tant que code à l'aide de Terraform; toute modification suit un processus de révision par les pairs avant d'être appliquée.

Isolement multi-locataire

Chaque cabinet client est isolé dans son propre schéma PostgreSQL grâce au gem Apartment. Cette segmentation au niveau de la base de données empêche les données d'un cabinet d'être exposées à un autre, même en cas d'erreur applicative. Les données stockées dans S3 sont préfixées par l'identifiant de locataire et soumises aux politiques d'accès correspondantes.

Chiffrement

En transit

Tout le trafic vers la plateforme est servi en HTTPS exclusivement. Nous appliquons force_ssl côté application ainsi que la directive Strict-Transport-Security (HSTS) avec inclusion des sous-domaines et préchargement (preload, durée d'un an). Le trafic interne entre Cloud Run, Cloud SQL et Memorystore est chiffré en transit.

Au repos

Le chiffrement au repos est appliqué par défaut sur l'ensemble du stockage Google Cloud (AES-256). Les champs particulièrement sensibles — adresse courriel, secrets, jetons OAuth — sont également chiffrés au niveau applicatif à l'aide de la bibliothèque Lockbox, avec un blind index sur le courriel pour permettre les recherches sans déchiffrement. La clé maîtresse de Rails est gérée hors du dépôt et obligatoirement présente au démarrage (config.require_master_key = true).

Authentification et contrôle d'accès

L'authentification utilisateur s'appuie sur Devise et OmniAuth, avec :

• connexion par lien magique (« magic link ») limitée dans le temps;
• confirmation obligatoire par courriel;
• politique de robustesse de mot de passe basée sur devise_zxcvbn;
• jetons OAuth et empreintes de liens magiques chiffrés au repos via Lockbox.

L'autorisation applicative est gérée par ActionPolicy et Rolify, suivant le principe du moindre privilège. L'accès au panneau d'administration et aux outils de production est restreint, journalisé et soumis à l'authentification multifacteur.

Limitation de débit et protection contre les abus

Rack::Attack applique les limites suivantes au niveau applicatif :

• plafond général de 300 requêtes par minute par adresse IP;
• 20 tentatives de connexion par heure par adresse IP;
• limitation des envois de liens magiques pour prévenir l'énumération et l'abus.

Au-dessus de cette couche, Cloudflare et Cloud Armor filtrent le trafic au niveau réseau, atténuent les attaques par déni de service distribué (DDoS) et bloquent les schémas d'attaque connus.

En-têtes de sécurité et défense contre les attaques web

• Politique de sécurité du contenu (CSP) stricte, fondée sur des nonces, sans script en ligne, avec rapports de violation envoyés à un point de terminaison dédié;
• jetons CSRF par formulaire pour toute action mutative;
• protection anti-robots via Google reCAPTCHA sur les formulaires publics.

Journalisation et audit

Stamped utilise le gem audited pour journaliser les modifications apportées aux utilisateurs et aux identités (les secrets sont exclus des journaux). Les accès console en production sont enregistrés et révisés à l'aide de console1984 et audits1984. Une base de données dédiée reçoit les flux d'audit afin que les journaux puissent être conservés et interrogés indépendamment de la base de production. Les journaux applicatifs et d'infrastructure sont centralisés dans Cloud Logging.

Continuité des activités et reprise après sinistre

Haute disponibilité

Cloud Run met à l'échelle automatiquement les couches web et de traitement par lots. La base de données est répliquée et le réplica en lecture est utilisable en lecture seulement. Les déploiements sont à vert sans interruption avec retrait automatique en cas d'erreur.

Sauvegardes

Cloud SQL exécute des sauvegardes automatiques quotidiennes et conserve les journaux nécessaires à la récupération à un instant donné (PITR) dans la même région. Les paramètres de rétention sont gérés via Terraform.

Plan de reprise

Comme l'infrastructure est entièrement décrite en Terraform, nous pouvons reconstruire des copies complètes d'environnement à partir du code source et des sauvegardes. Notre plan de reprise est révisé périodiquement.

Sécurité du cycle de développement

Stamped pratique l'intégration et la livraison continues avec révision obligatoire des demandes de tirage par les pairs, analyse de sécurité automatisée des dépendances, tests automatisés et déploiements progressifs. Les secrets ne sont jamais stockés en clair dans le dépôt; ils sont gérés via les services de gestion de secrets de Google Cloud.

Sécurité organisationnelle

• Vérifications préalables à l'emploi — vérification des antécédents et des références pour les nouveaux employés;
• Formation annuelle obligatoire couvrant le OWASP Top 10 et la sensibilisation à la confidentialité;
• Accès aux postes de travail — chiffrement intégral du disque, authentification multifacteur, gestion centralisée des appareils.

Notification d'incident

En cas d'incident de confidentialité présentant un risque de préjudice sérieux, Stamped avisera sans délai la Commission d'accès à l'information du Québec ainsi que les personnes concernées, conformément à l'article 3.5 de la Loi sur la protection des renseignements personnels dans le secteur privé. Lorsque le RGPD s'applique, nous notifierons l'autorité de contrôle compétente dans un délai de 72 heures. Nous tenons un registre des incidents que nous mettons à la disposition des autorités sur demande.

Nous joindre

Pour toute question relative à la sécurité ou à la vie privée, écrivez à engineering@stamped.ai.