Cette page décrit les mesures auxquelles renvoie le contrat de sous-traitance. Elle est rédigée pour être vérifiable : chaque mesure indique ce qui la met en œuvre, afin que l'audit de sécurité d'un prospect puisse contrôler au lieu de faire confiance.

Chiffrement

Tout le trafic transite en TLS. Les jetons OAuth tiers (Shopify, Google, Meta, Klaviyo, Notion, Figma) sont chiffrés au repos en AES-256-GCM avec une clé qui peut faire l'objet d'une rotation : une copie de la base de données ne livre donc aucun identifiant exploitable. Les rapports de vérification d'identité sont chiffrés selon le même procédé et ne sont jamais affichés dans le produit.

Cloisonnement des données clients

Toute requête qui accède aux données d'une organisation ou d'une boutique est filtrée selon l'appartenance à l'organisation, et ce filtrage est couvert par des tests qui font échouer le build, et non par la seule rigueur des relectures. Les rôles sont Propriétaire, Admin, Membre et Observateur, et les autorisations sont vérifiées côté serveur à chaque requête, jamais dans le client.

Authentification

La connexion se fait par un code à usage unique de six chiffres envoyé par e-mail. Il n'y a donc aucun mot de passe susceptible de fuiter, ni de lien magique à transférer. Les sessions sont portées par un cookie préfixé __Secure-, expirent au bout de 30 jours, et sont ramenées à 24 heures lorsque vous vous connectez sans demander à mémoriser l'appareil.

Journal d'audit

Les événements de sécurité et de facturation sont consignés dans un journal en ajout seul, consultable dans l'activité de votre compte. Les actions administratives de la plateforme sont enregistrées à part. Les contenus bruts des webhooks sont purgés plus tôt que les événements eux-mêmes : le journal est conservé, les contenus bruts non.

Secrets

Aucun identifiant n'est versionné dans le dépôt. Le tableau de bord opérateur qui rend compte de la configuration de l'environnement indique seulement si une clé est renseignée, jamais sa valeur. Un test refuse toute valeur ressemblant à un secret dans le fichier de configuration MCP versionné.

Intégrité et gestion des changements

Les évolutions du schéma de la base de données sont dérivées automatiquement et appliquées de façon idempotente, avec un garde-fou qui refuse toute modification susceptible d'échouer en production dès qu'une table contient des lignes. Avant qu'une modification soit envoyée vers le dépôt distant, un hook de pre-push exécute des contrôles hors ligne rapides (schéma, affirmations de la documentation, textes, versions). Le lint, la vérification des types et la suite de tests complète s'exécutent en intégration continue sur chaque pull request. La documentation que vous lisez est elle-même sous contrôle : les chiffres publiés sont comparés au code qui les met en œuvre.

Infrastructure

La plateforme est hébergée sur Vercel, avec une base PostgreSQL managée chez Neon, qui assure des sauvegardes continues et la restauration à un instant donné. Le cache et les files d'attente reposent sur Upstash. Les paiements ne transitent jamais par nos serveurs : les données de carte sont traitées par Stripe. La localisation de chaque prestataire est publiée sur la page des sous-traitants.

Supervision

La plateforme publie une page de statut en direct avec 90 jours d'historique et un bilan mensuel de disponibilité. Les incidents y sont déclarés, avec un flux RSS et un abonnement par e-mail. Les alertes au niveau de la plateforme (inscriptions, paiements échoués) sont adressées à l'opérateur sous forme de récapitulatif horaire.

Signaler une vulnérabilité

Écrivez à contact@boostecom.app avec suffisamment de détails pour reproduire le problème. 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 effectuer de tests sur le compte ou la boutique d'un autre utilisateur.

Mis à jour le 12 septembre 2026