Le prix founding est ouvert : Pro au prix d'aujourd'hui, verrouillé tant que tu restes. Places limitées. Voir l'offre
Sécurité
Cette page décrit les mesures auxquelles le contrat de sous-traitance renvoie. Elle est écrite pour être vérifiable : chaque mesure nomme ce qui l'applique, pour qu'une revue de sécurité puisse contrôler plutôt que croire.
Chiffrement
Tout le trafic est servi en TLS. Les jetons OAuth tiers (Shopify, Google, Meta, Klaviyo, Notion, Figma) sont chiffrés au repos en AES-256-GCM sous une clé qui supporte la rotation : un dump de base ne rend donc pas d'identifiants exploitables. Les rapports de vérification d'identité sont chiffrés selon le même schéma et ne sont jamais affichés dans le produit.
Cloisonnement des locataires
Toute requête qui atteint des données d'organisation ou de boutique est filtrée par l'appartenance, et ce filtrage est couvert par des tests qui font échouer le build plutôt que par une discipline de relecture. Les rôles sont owner, admin, member et viewer, et les permissions sont vérifiées côté serveur à chaque requête, jamais dans le client.
Authentification
La connexion se fait par code à six chiffres envoyé par e-mail. Aucun mot de passe à fuiter, aucun lien magique à transférer. Les sessions sont portées par un cookie préfixé __Secure-, expirent au bout de 30 jours, et tombent à 24 heures lorsque vous vous connectez sans demander à être reconnu.
Journal d'audit
Les événements de sécurité et de facturation sont écrits dans un journal en ajout seul, consultable dans l'activité de votre compte. Les actions administratives de la plateforme sont enregistrées à part. Les charges utiles brutes des webhooks sont purgées selon un calendrier plus court que les événements eux-mêmes : le journal survit, les charges utiles non.
Secrets
Aucun identifiant n'est commité dans le dépôt. Le tableau de bord opérateur qui rend compte de la configuration d'environnement n'expose que l'état posé/absent d'une clé, jamais sa valeur. Un test refuse toute valeur ressemblant à un secret dans le fichier de configuration MCP versionné.
Intégrité et gestion du changement
Les évolutions du schéma de base sont dérivées automatiquement et appliquées de façon idempotente, avec une garde qui refuse tout changement susceptible d'échouer en production dès qu'une table contient des lignes. Un hook de pre-push exécute des gardes offline rapides (schéma, claims de doc, copy, versions) avant qu'un changement parte vers le remote. Lint, typecheck et la suite de tests complète tournent en CI sur chaque pull request. La documentation que vous lisez est elle-même gardée : les chiffres publiés sont comparés au code qui les implémente.
Infrastructure
La plateforme tourne sur Vercel avec une base PostgreSQL managée chez Neon, qui assure sauvegardes continues et restauration à un instant donné. Cache et files d'attente tournent sur Upstash. Les paiements ne touchent jamais nos serveurs : les données de carte sont traitées par Stripe. La région de chaque prestataire est publiée sur la page sous-traitants.
Supervision
La plateforme publie une page de statut en direct avec 90 jours d'historique et un bulletin mensuel de disponibilité. Les incidents y sont déclarés, avec un flux RSS et une inscription e-mail. Les défaillances au niveau plateforme (inscriptions, paiements échoués) sont résumées à l'opérateur toutes les heures.
Signaler une vulnérabilité
Écrivez à contact@boostecom.app avec assez de détails pour reproduire. Nous accusons réception sous trois jours ouvrés. Nous n'engagerons aucune action en justice contre une recherche de bonne foi qui respecte la vie privée des utilisateurs, évite toute destruction de données et ne dégrade pas le service. Merci de ne pas tester sur le compte ou la boutique d'un autre utilisateur.
Mis à jour le 12 septembre 2026