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
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ètres → Journal 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ées | Mé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 |
| Sauvegardes | Chiffré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
| Fournisseur | Rôle | Ce qu'il voit |
|---|---|---|
| Supabase | Base de données, authentification, stockage | Toutes les données clients |
| Vercel | Hébergement de l'interface | Aucune donnée client persistante |
| Railway | Hébergement de l'API et des travailleurs | Données en transit; journaux applicatifs |
| Google (Gemini) | Analyse IA des documents | Texte des documents; selon les modalités payantes de l'API Gemini, non utilisé pour l'entraînement |
| OpenAI | Analyse IA — fournisseur de secours et sélectionnable | Texte des documents, lorsque activé pour votre déploiement |
| xAI | Analyse IA — fournisseur sélectionnable | Texte des documents, lorsque activé pour votre déploiement |
| PostHog | Suivi des erreurs, analytique produit, relecture de session | Traces 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.
Related Articles
Was this page helpful?