C
Docs

Aperçu de la sécurité et de la confidentialité

Comment Cothon protège vos données d'approvisionnement : les contrôles en place aujourd'hui, les travaux de conformité en cours et comment obtenir ce dont votre équipe TI a besoin

Updated 2026-07-228 min read

Aperçu de la sécurité et de la confidentialité

Cothon traite des données d'approvisionnement sensibles — analyses de soumission, ébauches de propositions, stratégies de prix, renseignement concurrentiel. Cette page est notre résumé honnête des contrôles de sécurité et de confidentialité appliqués aujourd'hui, de ce sur quoi nous travaillons activement, et de la façon d'obtenir la documentation que votre équipe TI demandera lors d'un examen de sécurité.

Si vous constatez un écart entre ce document et ce que vous observez dans le produit, c'est un bogue — dites-le-nous par vos canaux de soutien habituels.

Ce qui protège vos données en ce moment

  • Contrôles de confidentialité alignés sur la LPRPDE — les dix principes sont mis en œuvre dans le code, pas seulement en politique : gestion du consentement, exportation des données, suppression de compte et suivi des avis d'atteinte sont intégrés à la plateforme.
  • Sécurité au niveau des lignes sur chaque table client — l'isolation des données est appliquée dans PostgreSQL par des politiques RLS à portée d'organisation. Même si les contrôles applicatifs étaient contournés, la base de données rejetterait les lectures inter-organisations.
  • Authentification multifacteur (TOTP) — inscription d'un ou de plusieurs facteurs d'application d'authentification; chaque nouvelle session doit franchir un défi MFA. Les administrateurs peuvent l'exiger pour tous les membres, avec période de grâce configurable.
  • Journal d'audit en ajout seul — les événements liés à la sécurité sont consignés dans une table que ni mise à jour ni suppression ne peuvent modifier (un déclencheur PostgreSQL les rejette, même pour le rôle de service). Les administrateurs peuvent consulter et exporter ce journal.
  • Authentification unique d'entreprise (SAML) — connexion fédérée à votre fournisseur d'identité; la propriété du domaine est vérifiée manuellement par notre équipe des opérations avant activation, afin de prévenir l'usurpation.
  • Chiffrement en transit et au repos — TLS 1.2+ sur le réseau; AES-256 au repos chez notre fournisseur de base de données; les jetons OAuth des intégrations sont en plus chiffrés au niveau applicatif.

Architecture en bref

L'interface (Next.js, réseau périphérique de Vercel) et l'API dorsale (Flask, hébergée via Railway avec la base Supabase) sont séparées par des frontières d'API claires. La limitation de débit s'appuie sur Redis; la couche base de données applique chiffrement au repos, politiques RLS et journal d'audit.

Note sur la résidence des données : les données sensibles (téléversements, analyses, propositions, stockage) circulent directement du navigateur vers l'API dorsale — elles ne transitent pas par Vercel. Les routes IA de Vercel ne traitent que du texte prétraité, sans persistance, et peuvent être désactivées pour une résidence canadienne stricte (ca-central-1).

Authentification et contrôle d'accès

  • Mot de passe — stockage géré par Supabase Auth avec hachage unidirectionnel conforme aux normes de l'industrie (jamais en clair ni réversible); longueur minimale de 12 caractères; le changement de mot de passe exige la revalidation du mot de passe actuel.
  • Connexion sociale (OAuth 2.0) — Google et Microsoft, via Supabase Auth.
  • MFA (TOTP) — auto-inscription, facteurs multiples par utilisateur, défis à chaque nouvelle session, application par l'organisation avec période de grâce (0–90 jours) et rapport de conformité par membre. Pas de SMS, délibérément (NIST 800-63B).
  • SSO d'entreprise — SAML 2.0 avec vérification de domaine et approbation par nos opérations; approvisionnement juste-à-temps; pas de SCIM.
  • Rôles — trois rôles d'organisation : propriétaire, administrateur, membre, appliqués par RLS au niveau de la base. Les changements de rôle sont audités.

Voir Authentification et contrôle d'accès.

Journalisation d'audit

Le journal en ajout seul couvre l'authentification (connexions, changements de mot de passe, cycle de vie MFA), l'administration (membres, rôles, politiques MFA), le cycle de vie des données (exportations, suppressions de compte), la conformité (consentements) et le SSO (demandes, approbations, retraits de domaines).

Protections techniques :

  • Des déclencheurs de base de données rejettent inconditionnellement UPDATE et DELETE sur la table audit_events, y compris pour le rôle de service
  • Les entrées survivent à la suppression d'une organisation; l'attribution est préservée par un courriel d'acteur dénormalisé
  • Consultation et exportation CSV par les administrateurs via ParamètresJournal d'audit
  • Conservation par défaut de 730 jours (deux ans), et 1 095 jours (trois ans) pour les événements d'organisation et d'équipe
  • Les adresses IP et agents utilisateurs sont effacés des entrées de plus de 90 jours, conformément au principe 5 de la LPRPDE

Pas encore au journal : les opérations de lecture (qui a consulté quelle analyse). Nous consignons les écritures seulement; l'audit des lectures peut être activé pour les organisations qui l'exigent.

Protection des données

État des donnéesMéthode
En transit (Internet public)TLS 1.2 ou plus, imposé par le CDN et l'équilibreur de charge
En transit (connexions à la base)TLS entre l'application et la base, imposé par Supabase
Au repos (base de données)AES-256, géré par Supabase
Au repos (jetons d'intégration)Chiffrement applicatif additionnel avant stockage
SauvegardesChiffrées par Supabase

Résidence : vos données résident dans la région Supabase de déploiement de votre instance (le Canada, ca-central-1, est offert). La résidence est une décision de déploiement, pas un contrôle en code — si votre politique l'exige, obtenez de nous une confirmation écrite de la région avant de signer.

Confidentialité (LPRPDE)

Cothon est conçu pour se conformer à la LPRPDE. Nous nous auto-évaluons contre les dix principes; aucun audit LPRPDE par un tiers n'a été réalisé. Contrôles concrets : gestion du consentement (journal de 7 ans), accès individuel (exportation JSON), droit à l'effacement (suppression définitive avec pseudonymisation de l'audit), limites de conservation configurables avec nettoyage automatisé, et suivi des avis d'atteinte dans la fenêtre de la LPRPDE.

Sous-traitants tiers

FournisseurRôleCe qu'il voit
SupabaseBase de données, authentification, stockageToutes les données clients
VercelHébergement de l'interfaceAucune donnée client persistante
RailwayHébergement de l'API et des travailleursDonnées en transit; journaux applicatifs
Google (Gemini)Analyse IA des documentsTexte des documents; selon les modalités payantes de l'API Gemini, non utilisé pour l'entraînement
OpenAIAnalyse IA — fournisseur de secours et sélectionnableTexte des documents, lorsque activé pour votre déploiement
xAIAnalyse IA — fournisseur sélectionnableTexte des documents, lorsque activé pour votre déploiement
PostHogSuivi des erreurs, analytique produit, relecture de sessionTraces d'erreurs avec assainissement des RP; événements d'utilisation; relectures de session qui masquent la saisie mais captent le texte affiché

Posture de conformité — ce que nous avons et n'avons pas

Nous avons : une auto-évaluation LPRPDE complète, une interface bâtie sur des primitives accessibles (WCAG 2.1 AA, non auditée formellement) et une architecture défensive (RLS, MFA, journal d'audit, SSO) réellement mise en œuvre dans le code.

En cours : préparation SOC 2 Type II (aucune fenêtre d'audit active pour l'instant), alignement ISO 27001 (habituellement après SOC 2), tests d'intrusion tiers (planifiés, aucun mandat complété).

Nous n'avons pas : de rapport SOC 2 Type II courant, de certificat ISO 27001, de sommaire récent de test d'intrusion tiers, de SLA de disponibilité publié appuyé sur un historique réel, ni de déploiement sur site. Si votre politique d'approvisionnement exige un rapport SOC 2 Type II comme préalable ferme, dites-le-nous tôt afin d'obtenir des attentes réalistes.

Demander de la documentation

Par vos canaux de soutien habituels, nous pouvons habituellement fournir : un questionnaire de sécurité rempli (CAIQ ou personnalisé), une revue de l'architecture et des flux de données, la confirmation écrite de la région de déploiement, la liste courante des sous-traitants et la description de la mise en œuvre d'un contrôle précis. Nous ne pouvons pas fournir aujourd'hui : rapport SOC 2, certificat ISO 27001 ou résultats de test d'intrusion (nous n'en avons pas encore).

Signalement de vulnérabilités

Si vous découvrez une faille dans Cothon, contactez-nous par votre canal de soutien. Nous accuserons réception rapidement et conviendrons d'un échéancier de résolution. Merci de ne pas divulguer publiquement le problème avant que nous ayons pu y remédier.

Bonnes pratiques pour votre équipe

  • Activez l'authentification à deux facteurs sur chaque compte; les propriétaires peuvent l'exiger pour tous les membres
  • Utilisez des mots de passe robustes et uniques gérés par un gestionnaire (minimum 12 caractères; 16+ recommandés)
  • Consultez périodiquement le journal d'audit (administrateurs) pour repérer les changements de membres ou exportations inattendus
  • Utilisez des liens de partage à expiration et révoquez-les dès qu'ils ne sont plus nécessaires
  • Retirez promptement les membres partis

Dernière mise à jour : le 22 juillet 2026. Ce document est maintenu en phase avec le produit par l'ingénierie; si une affirmation ne correspond pas à ce que vous voyez dans l'application, prévenez-nous.

Was this page helpful?