Sécurité et confiance

Dernière révision : 26 avril 2026 · Mise à jour continue

Vérifié et sécurisé par TAC Security ESOF

ChamsPilot a réalisé une évaluation de sécurité indépendante (Google CASA - Cloud Application Security Assessment), vérifiée via la plateforme TAC Security ESOF par un évaluateur CASA agréé (ADA).

Vue d'ensemble

ChamsPilot gère trois choses que les pirates adorent : l'argent (paiements créateurs, budgets marques), les identifiants tiers (OAuth Gmail / Outlook, mots de passe SMTP), et les contrats (signatures juridiquement contraignantes). Nous traitons chacun avec le sérieux qu'il mérite. Les sections ci-dessous décrivent exactement ce qui tourne en production · pas ce qui figure sur un PowerPoint.

• Défense en profondeur
• Privilège minimal
• Rayon d'impact limité
• Traçable

• Bcrypt+2FA : Hachage optimisé avec authentification à deux facteurs TOTP
• 30 min : Tokens d'accès à courte durée avec actualisation rotative
• Strict : Limites d'API par IP et verrouillage automatique en cas d'abus
• 24h : Pause automatique si les envois sortants semblent anormaux

Identité et authentification

L'authentification repose sur des cookies. Les jetons d'accès JWT ne touchent jamais localStorage, éliminant ainsi toute la classe de vol de jetons par XSS.

• Hachage des mots de passe : bcrypt avec un facteur de coût calibré pour rendre la force brute coûteuse en calcul.
• Politique de mot de passe (NIST 800-63B) : minimum 10 caractères, 3 des 4 classes de caractères, liste noire des 100 mots de passe les plus compromis, détecteur de séquences clavier, détecteur de répétitions, ne peut contenir la partie locale de votre email ni 4+ caractères de votre nom. Vérification k-anonymity HaveIBeenPwned à chaque inscription et changement de mot de passe.
• 2FA : mot de passe à usage unique basé sur le temps (TOTP, RFC 6238) via toute app d'authentification. Codes de secours uniques pour récupération.
• Jetons d'accès : JWT signé à courte durée de vie livré en cookie HttpOnly; Secure; SameSite=Lax.
• Jetons de rafraîchissement : jetons rotatifs · chaque rafraîchissement émet un nouveau jeton et invalide le précédent.
• Détection de réutilisation : si un ancien jeton de rafraîchissement est rejoué (l'attaquant l'a volé), toute la famille de jetons est effacée côté serveur, expulsant à la fois l'utilisateur légitime et l'attaquant, et une alerte de haute gravité se déclenche.
• Protection contre la force brute : les échecs de connexion répétés déclenchent un verrouillage temporaire du compte. Les pics anormaux d'échecs depuis une seule IP déclenchent des alertes d'anomalie.
• Support des passkeys : clés matérielles WebAuthn / FIDO2 pour une connexion résistante au phishing.
• Appareils de confiance : confiance d'appareil à fenêtre courte avec liaison IP pour une ré-authentification simplifiée.

Chiffrement

En transit : TLS 1.3 appliqué partout. Préchargement HSTS avec max-age étendu et couverture complète des sous-domaines.

Au repos : Les identifiants tiers sensibles sont scellés avec un chiffrement authentifié standard avant même d'atteindre la base de données. Le déchiffrement n'intervient qu'au moment de l'utilisation, en mémoire.

Enveloppe versionnée : les blobs scellés portent un préfixe de version pour permettre la rotation des algorithmes sans casser l'historique.

Stockage : Les volumes de base de données sont chiffrés AES-256 au niveau de la couche de stockage. Les sauvegardes héritent du même chiffrement.

• Jetons OAuth Gmail : access_token + refresh_token scellés avant stockage
• Jetons OAuth Outlook : access_token + refresh_token scellés avant stockage
• Jetons Google Calendar : Lecture seule · scellés comme les jetons mail
• Mots de passe SMTP : Mots de passe des connexions de boîte de réception chiffrés à l'écriture

Sécurité applicative

• Limitation globale du débit : plafonds stricts par (utilisateur authentifié OU IP) sur chaque route /api/*. Renvoie 429 avec indication Retry-After en cas de dépassement.
• Limites par route : plafonds renforcés sur la connexion, l'inscription, la réinitialisation de mot de passe, la génération IA et les points d'accès invités par lien public.
• Audit IDOR terminé : chaque requête multi-tenant est filtrée par (resource_id, user_id). Les fuites inter-tenants ont été corrigées dans les séquences de prospection, contrats, briefs et points d'accès créateurs liés.
• Suppression des DCP dans les logs : emails, JWT, en-têtes Authorization, numéros de carte et numéros de téléphone sont nettoyés au niveau du logger avant écriture sur disque.
• En-têtes de sécurité : Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy strict-origin-when-cross-origin, Permissions-Policy verrouillant caméra / micro / géolocalisation / paiement.
• Durcissement du téléversement : liste noire d'extensions, liste blanche MIME, inspection des octets magiques (rejette PE/ELF/Mach-O/shebang/HTML/PHP), nettoyage des noms de fichiers, réponses de téléchargement isolées pour les types non-média.
• Vérification de signature webhook : les webhooks Stripe échouent systématiquement si leur secret de signature n'est pas défini · la production ne peut accepter d'événements non signés.
• Intégrité des signatures : les signatures de contrat sont validées en taille côté client et serveur · les PNG transparents 1x1 et charges vides sont rejetés.

Détection et surveillance des menaces

Un système de détection d'anomalies fonctionne en continu. Les alertes sont dédupliquées et acheminées vers notre boîte de réception sécurité. Les charges utiles d'alerte contiennent des identifiants utilisateur hachés en SHA256 · la table d'alertes reste sans DCP.

Journal d'audit admin : chaque action privilégiée (usurpation d'identité, changement de plan, attribution de crédits, réinitialisation de mot de passe) est enregistrée dans un admin_audit_log immuable avec IP de l'acteur et user agent.

• Bourrage d'identifiants : Échecs de connexion répétés visant une même adresse e-mail
• Attaque par force brute au niveau IP : Pics d'échecs anormaux depuis une seule IP
• Vagues de verrouillages : Rafales de verrouillages de comptes en peu de temps
• Volume d'envoi inhabituel : Schémas sortants anormaux entre utilisateurs
• Réutilisation de jeton de rafraîchissement : Rejeu d'un jeton de rafraîchissement pivoté
• Pics de taux de rebond : Pause automatique de l'expéditeur au-dessus des seuils sûrs

Sécurité des e-mails et délivrabilité

• Plafonds sortants quotidiens selon le plan : empêchent les comptes compromis d'être transformés en relais de spam.
• Disjoncteur de rebond : met automatiquement en pause un autopilote pendant 24 heures lorsque les taux de rebond dépassent les seuils de sécurité.
• Authentification : alignement SPF, DKIM et DMARC validé pour chaque domaine connecté.
• Portées OAuth : nous demandons les portées adaptées aux fonctionnalités que vous activez (par ex. lecture de la boîte mail, envoi en votre nom, lecture de l'agenda).
• Traitement du contenu : le contenu des e-mails est traité pour faire fonctionner les fonctionnalités que vous avez activées ; les métadonnées et un contenu limité peuvent être mis en cache, conformément à notre calendrier de conservation.

Protection des données et RGPD

ChamsPilot est conçu dans le respect des principes du RGPD. Les points de terminaison ci-dessous sont opérationnels.

• Sous-traitants : Stripe gère les paiements. ELDIN AI alimente toutes les fonctionnalités IA (inférence éphémère, jamais utilisée pour entraîner un modèle). L'hébergement repose sur une infrastructure de niveau entreprise dans l'UE et aux États-Unis. Les e-mails sortants sont délivrés via une infrastructure d'envoi reconnue. Les sous-traitants externes sont engagés selon des conditions de traitement des données appropriées.
• Résidence des données : infrastructure principale dans des régions de l'UE et des États-Unis. Les transferts transfrontaliers, lorsqu'ils ont lieu, reposent sur des mécanismes de transfert appropriés (par ex. les clauses contractuelles types).
• Conservation : durées de conservation indicatives · environ 90 jours après la fermeture du compte pour les données personnelles, jusqu'à 7 ans pour les dossiers financiers et jusqu'à 12 mois pour les journaux de sécurité. Les durées précises peuvent varier selon les obligations légales.
• Aucune vente de données personnelles : nous ne vendons pas de données personnelles contre une contrepartie monétaire. Lorsque la loi applicable retient une définition plus large de la « vente » ou du « partage », nous honorons les demandes d'opposition comme elle l'exige.
• Entraînement de l'IA : nous ne fournissons pas votre contenu à des fournisseurs d'IA dans le but d'entraîner leurs modèles de fondation.
• GET /api/gdpr/export : Article 15 · retourne votre dossier complet : profil, briefs, scripts, factures, contacts, séquences, paiements et les deux côtés de chaque transaction dont vous êtes partie. Les jetons, hachages de mot de passe et secrets 2FA sont supprimés.
• POST /api/gdpr/delete : Article 17 · nécessite la phrase de confirmation DELETE MY ACCOUNT. Anonymise votre dossier utilisateur (préserve _id pour l'intégrité FK), supprime définitivement les artefacts personnels, efface les jetons de rafraîchissement et les intégrations connectées, et écrit une entrée d'audit de sécurité.

Gestion des clés

• Clé de chiffrement maître : stockée uniquement dans notre magasin de secrets de production. Jamais commitée dans git, jamais journalisée.
• Procédure de rotation : un outil dédié de rotation de clés déchiffre chaque blob scellé avec la clé précédente et le rescelle avec la nouvelle. La procédure est idempotente et peut être exécutée à blanc.
• Clé de signature JWT : distincte de la clé de chiffrement au repos. La rotation invalide proprement les sessions actives.
• Secrets de production : un fournisseur de secrets enfichable abstrait notre gestionnaire de secrets d'entreprise derrière un seul appel d'hydratation au démarrage. .env reste le chemin pour le développement local · les pods de production hydratent os.environ depuis le fournisseur configuré au démarrage.

Réponse aux incidents

Si nous détectons ou sommes informés d'un incident de sécurité :

Sauvegardes : instantanés de base de données chiffrés quotidiens avec conservation de 30 jours. Restauration testée trimestriellement.

RPO de reprise après sinistre : 24 heures. RTO : 4 heures.

• < 1 heure : Triage, périmètre et confinement
• < 24 heures : Notification de tout utilisateur dont les données étaient à risque
• < 72 heures : Notification au régulateur si nécessaire (RGPD Art. 33)

Divulgation des vulnérabilités

Nous accueillons favorablement la recherche en sécurité. Si vous avez trouvé quelque chose, veuillez nous en informer avant d'en informer quiconque d'autre.

Protection pour la recherche de bonne foi :

Signalez vos découvertes à [email protected]. Pour les rapports sensibles, demandez notre clé PGP dans votre email initial et nous répondrons avec l'empreinte.

Accusé de réception sous 48 heures, classification de gravité sous 5 jours ouvrables, calendrier de correction communiqué en fonction de la gravité. Crédit au tableau d'honneur disponible sur demande.

• Testez uniquement sur des comptes que vous possédez ou pour lesquels vous avez une permission explicite de tester.
• Pas de DoS, pas de spam, pas d'ingénierie sociale de notre personnel ou de nos utilisateurs.
• N'accédez pas, ne modifiez pas et ne détruisez pas les données d'autres utilisateurs.
• Accordez-nous une fenêtre raisonnable (généralement 90 jours) avant la divulgation publique.

Frontières de confiance et flux de données

ChamsPilot est organisé en quatre zones de confiance, chacune appliquant ses propres contrôles :

Flux de données principal : une requête va du navigateur au CDN, puis à l'application monopage, ensuite à l'API authentifiée, et enfin à la base de données. Les intégrations sortantes utilisent des jetons OAuth propres à chaque utilisateur, chiffrés au repos et transmis uniquement via TLS ; les fonctionnalités d'IA sont assurées par Eldin, notre propre IA.

• Internet public vers la périphérie CDN : un WAF managé, terminaison TLS 1.3, agrafage OCSP, protection anti-DDoS et limitation de débit.
• Périphérie vers la couche web : l'application est servie derrière une Content-Security-Policy stricte, HSTS et des en-têtes de réponse renforcés.
• Couche web vers la couche applicative : chaque route d'API est authentifiée par des JWT à courte durée de vie et validée par des protections anti-injection et une validation de schéma.
• Couche applicative vers la base de données : la base de données exige une authentification et n'est accessible que sur un réseau interne privé, sans port public.

Classification des données et niveaux de protection

Toutes les données sont classifiées, et chaque catégorie porte des exigences de protection définies :

Pour chaque catégorie, nous appliquons le TLS 1.3 en transit, des sauvegardes chiffrées AES-256 au repos avec une rétention de 14 jours, et le moindre privilège.

• Secrets et identifiants : (jetons OAuth, clés d'API) : chiffrés au repos avec un chiffrement authentifié AES-256, TLS en transit, jamais consignés dans les journaux.
• Données personnelles : (noms, adresses e-mail, profils) : contrôle d'accès limité au propriétaire, incluses dans les sauvegardes chiffrées et couvertes par les droits d'export et de suppression du RGPD.
• Données métier : (deals, contrats, messages) : protégées par un contrôle d'accès basé sur les rôles du propriétaire et de l'équipe.
• Données opérationnelles et analytiques : non sensibles et agrégées.

Journalisation des accès et audit

L'activité pertinente pour la sécurité est enregistrée afin que les administrateurs autorisés puissent détecter et enquêter sur les abus, sans jamais stocker les valeurs sensibles elles-mêmes.

Les journaux d'accès sont conservés conformément à nos obligations de protection des données et ne sont accessibles qu'aux administrateurs autorisés.

• Les actions administratives : sont écrites dans une piste d'audit dédiée avec l'acteur, l'action, l'horodatage et l'adresse IP source.
• Les événements d'authentification et de session : (connexions, appareils de confiance, anomalies) sont journalisés pour examen.
• Les valeurs sensibles ne sont jamais journalisées : les mots de passe et jetons de session ne sont stockés que sous forme hachée ou irréversible, et les détails de paiement ne sont jamais consignés.

Feuille de route de conformité

Où nous en sommes aujourd'hui et où nous allons.

Prospects entreprise : un questionnaire de sécurité fournisseur (VSQ) et notre dernière liste de sous-traitants sont disponibles sous NDA · envoyez un email à [email protected].

• Actif : CASA (Cloud Application Security Assessment) - évaluation indépendante alignée sur OWASP ASVS réussie
• Actif : Points de terminaison RGPD Article 15 (export) et Article 17 (suppression)
• Actif : Traitement des données aligné CCPA et opt-out
• Actif : Réduction du périmètre PCI · données de carte gérées exclusivement par Stripe
• En cours : Lancement de l'audit SOC 2 Type II
• Prévu : Certification ISO 27001 (post-SOC 2)
• Prévu : Rapport de test d'intrusion (annuel, disponible sous NDA)

Contacter l'équipe sécurité

Pour les questions de sécurité, les rapports de vulnérabilité ou les demandes DPA / VSQ :

Équipe Sécurité ChamsPilot · Rapports de vulnérabilités : [email protected] · Demandes de confidentialité et de données : [email protected] · Entreprise et DPA : [email protected]

• Conditions Générales d'Utilisation
• Politique de confidentialité
• Politique relative aux cookies
• Centre d'aide
• Documentation
• État du système