Sécurité

Nos principes

Pulzeo manipule des informations sensibles : identifiants d'accès aux comptes Google Ads, métriques de campagnes, budgets, performances commerciales. La sécurité n'est pas une fonctionnalité ajoutée à la fin. C'est une contrainte intégrée à chaque décision technique.

• Moins de données collectées = moins de risques. On ne stocke que ce qui est strictement nécessaire au service.
• Isolation par défaut : chaque organisation ne peut accéder qu'à ses propres données, enforcé au niveau base de données (Row Level Security).
• Chiffrement systématique des données sensibles au repos et en transit.
• Transparence : cette page est volontairement détaillée pour que vous puissiez juger sur pièces.

Sécurité des données

Chiffrement en transit

Toutes les communications entre votre navigateur, l'application Pulzeo, l'API Google Ads et nos sous-traitants utilisent TLS 1.2 ou supérieur. Aucun trafic en clair n'est accepté.

Chiffrement au repos

Les identifiants OAuth Google Ads (refresh tokens et access tokens) sont chiffrés via AES-256-GCMavant insertion en base de données, avec une clé de chiffrement séparée stockée en variable d'environnement applicative. Une compromission éventuelle de la base de données ne donnerait pas accès aux identifiants.

Le reste des données métier (métriques, paramètres, comptes) est chiffré au repos par notre fournisseur de base de données via les mécanismes natifs du moteur PostgreSQL.

Isolation par tenant

Chaque organisation Pulzeo voit uniquement ses propres données. Cette isolation est appliquée à 3 niveaux :

• RLS (Row Level Security) au niveau PostgreSQL. Chaque requête est filtrée par organization_id avant retour des données, indépendamment du code applicatif.
• Vérifications applicatives dans chaque endpoint API (defense in depth).
• Audit logs pour traçabilité des opérations sensibles.

Authentification

L'authentification utilisateur est gérée par Supabase Auth, basée sur des tokens JWT signés et des refresh tokens à courte durée de vie. Les mots de passe sont hachés via bcrypt avec salt unique par compte, jamais stockés en clair.

Pour vos comptes Google Ads, nous utilisons exclusivement le flux OAuth 2.0de Google. Pulzeo ne voit jamais vos identifiants Google et ne stocke pas votre mot de passe Google. Vous pouvez révoquer l'accès à tout moment depuis votre compte Google.

Politique d'accès interne

L'accès aux systèmes de production de Pulzeo est encadré par le principe du moindre privilège et limité au strict nécessaire pour le fonctionnement du service.

• Le cercle des personnes autoriséesà accéder à la production (console Vercel, console Supabase, console Stripe, consoles d'hébergement et de mailing) est restreint à l'équipe technique d'Ecom Liberty, à ce jour limité au dirigeant fondateur.
• L'ensemble des comptes d'administration tiers utilisés pour opérer Pulzeo (Vercel, Supabase, Resend, Google Cloud, Anthropic, Stripe, Upstash, OVH, etc.) est protégé par authentification multi-facteurs (MFA).
• Les secrets applicatifs(clés API, secrets d'encryption, OAuth client secrets) sont stockés exclusivement dans les variables d'environnement chiffrées du fournisseur d'hébergement et ne sont jamais commités dans le dépôt de code source.
• L'accès aux données utilisateur en clair (au-delà des métriques anonymisées) est exclusivement déclenché dans deux situations : (1) à la demande explicite de l'utilisateur dans le cadre d'un support technique (debug d'un bug que vous nous signalez), ou (2) sur obligation légale impérative (réquisition judiciaire dûment notifiée). Toute consultation est tracée.
• Tout sous-traitant amené à intervenir sur la production est lié par un accord de confidentialité (NDA) ainsi que par les obligations RGPD applicables.
• Lors de la fin de mission d'un intervenant (interne ou externe), tous ses accès sont révoqués sous 24 heures ouvrées.

Infrastructure

Pulzeo s'appuie sur des fournisseurs reconnus pour leur niveau de sécurité :

• Vercelpour l'hébergement applicatif (SOC 2 Type II, ISO 27001).
• Supabasepour la base de données et l'authentification (SOC 2 Type II, base hébergée sur AWS en région UE).
• Google Cloud pour les API Google Ads (ISO 27001, SOC 1/2/3).

Sauvegardes et continuité de service

Sauvegardes de la base de données

La base de données PostgreSQL hébergée par Supabase est sauvegardée automatiquement :

• Snapshots quotidiensautomatiques, conservés pendant 7 jours minimum sur le plan d'hébergement souscrit.
• Réplication continueau sein de la région d'hébergement pour garantir la haute disponibilité.
• Les snapshots sont chiffrés au repos et stockés dans la même juridiction que la base primaire.

Restauration, RPO et RTO indicatifs

• RPO(Recovery Point Objective) : 24 heures maximum. Au pire cas, perte des données générées depuis le dernier snapshot quotidien.
• RTO(Recovery Time Objective) : 4 heures maximum sur incident isolé Pulzeo, sous réserve de la disponibilité des sous-traitants impliqués (Vercel, Supabase).
• Une procédure de restauration documentée est testée périodiquement par l'équipe technique.

Continuité côté sous-traitants

Vercel, Supabase, Stripe, Resend et les autres sous-traitants critiques opèrent leurs propres plans de continuité avec des SLA documentés publiquement. En cas d'incident majeur affectant un sous-traitant, Pulzeo communique sur la situation dans les meilleurs délais (page de statut, email aux utilisateurs impactés).

Monitoring et journaux

Toutes les erreurs runtime de l'application sont collectées de manière agrégée et anonymisée pour permettre le debug et la détection d'anomalies. Les identifiants, mots de passe et autres secrets sont systématiquement filtrés ou masqués (ya29.<redacted>) avant toute écriture en journal.

Nous monitorons activement nos endpoints critiques (/api/google-ads/sync, /api/reports, endpoints d'authentification) et appliquons un rate limiting via Upstash Redis pour prévenir les abus.

Divulgation responsable

Si vous découvrez une faille de sécurité dans Pulzeo, nous vous remercions de nous la signaler de manière responsable plutôt qu'en la publiant publiquement.

Comment nous signaler une faille

• Écrivez à security@pulzeo.com avec une description précise du problème, les étapes de reproduction et, si possible, l'impact estimé.
• Nous accusons réception sous 72 heures ouvrées et vous tenons informé du traitement.
• Nous vous demandons de ne pas exploiter la faille au-delà de ce qui est strictement nécessaire pour la démontrer, et de ne pas la divulguer publiquement avant qu'elle ne soit corrigée.

Délais de correction indicatifs (SLA)

Une fois la faille confirmée, nous nous engageons à un délai de traitement aligné sur sa criticité, telle que nous l'évaluons conjointement avec le chercheur (échelle inspirée du standard CVSS) :

Ces délais sont des cibles internes communiquées de bonne foi, et non un engagement contractuel opposable. Nous communiquons toute déviation au chercheur ayant signalé la faille.

Ce qu'on s'engage à faire

• Vous tenir informé du statut de la correction tout au long du processus.
• Mentionner publiquement votre contribution si vous le souhaitez (hall of fame, mention dans les release notes).
• Ne pas engager de poursuites contre les chercheurs en sécurité qui agissent de bonne foi dans le respect de cette politique.

Contact sécurité

Pour toute question liée à la sécurité de Pulzeo, écrivez à security@pulzeo.com.