Réponses courtes et honnêtes aux questions que posera votre équipe sécurité.

1. Analytics privacy-first

Conformément à ADR-0004, le pipeline de scan ne journalise jamais une adresse IP ni un User-Agent brut. À l'ingestion, nous lisons CF-IPCountry (pays) et faisons passer le UA par une regex de classe d'appareil (mobile / tablet / desktop / unknown), puis nous supprimons la chaîne brute. Les données au niveau ville sont un agrégat peuplé depuis request.cf.city, pas de ligne par scan, pas d'identifiant joignable. Les agrégats de pays sous 5 scans sont regroupés dans "Other" pour éviter la ré-identification.

2. Sauvegardes chiffrées

Chaque nuit à 03:00 UTC, un Worker distinct crée un snapshot D1 vers R2. Les sauvegardes sont chiffrées AES-GCM avec une clé de données rotative via KDF enveloppée par BACKUP_ENCRYPTION_KEY. Chaque bundle porte un digest SHA-256 + manifeste pour la détection d'altération (voir la table backups). Rétention : 7 ans pour les tenants Pro. La clé de chiffrement est conservée en trois copies indépendantes (secret Worker, coffre-fort 1Password, hors ligne scellé), la perte des trois rendrait les sauvegardes historiques irrécupérables, nous la traitons donc comme un point opérationnel unique.

3. API Shield + CSP stricte

Notre spec OpenAPI 3.1 publique est téléversée dans Cloudflare API Shield et chaque requête vers /api/* est validée contre elle. La dérive de schéma est éliminée par un hook post_deploy qui retéléverse la spec à chaque déploiement en production. Côté frontend, une Content Security Policy stricte interdit les scripts inline partout, chaque page référence son JS via <script src>, et notre make check pré-déploiement refuse d'expédier une page qui viole cette règle.

4. Journal d'audit + registre GDPR

Chaque mutation (création/patch/suppression de code, invitation d'équipe, émission de clé, changement de plan, modification de webhook) écrit une ligne append-only dans audit_log avec l'acteur, le périmètre et l'horodatage, conservée 180 jours puis purgée. Le registre des requêtes GDPR (gdpr_requests) trace chaque export / suppression / restauration ; les lignes survivent à la suppression du compte (FK ON DELETE SET NULL, email préservé) pour que nous puissions prouver le traitement dans les délais de chaque demande légale des années après la disparition du compte.

5. Protections d'authentification

L'authentification est déléguée à la couche d'identité partagée abundera.ai (JWT EdDSA via JWKS). Disponible pour les clients Pro :

• 2FA (TOTP), mots de passe à usage unique basés sur le temps RFC 6238, toute application d'authentification standard, codes de secours émis à l'inscription.
• SSO SAML 2.0, Okta, Entra ID, JumpCloud, Google Workspace, IdPs personnalisés. Disponible sur Team+ (inclus sur Agency/Enterprise).
• Provisionnement SCIM 2.0, cycle de vie utilisateurs + groupes RFC 7643/7644, limité en débit par token, journalisé dans l'audit. Désactivé par défaut ; activé par client.
• Clés API, Business+, stockées en sha256(raw) ; la valeur brute abnd_qrpro_... n'est renvoyée qu'à la création et jamais ensuite.

6. Sous-traitants

La liste courte : Cloudflare (hébergement, D1, KV, R2, API Shield), Stripe (paiements), Zoho / ZeptoMail (email transactionnel), Twilio (vérification téléphonique + SMS). Voir /trust/subprocessors/ pour la liste canonique avec les régions, les catégories de données et notre engagement de notification de changement sous 30 jours.

7. Accord de traitement des données

Notre DPA aligné GDPR (EU SCCs, avenant UK, avenant FADP suisse) est téléchargeable sur abundera.ai/legal/dpa/. Il s'applique automatiquement à tous les niveaux payants, pas de contre-signature séparée requise, sauf si votre processus d'achat en exige une (nous signerons sur demande à legal@abundera.ai).

8. SOC 2

SOC 2 Type II, en cours, cible T3 2026. Nous sommes en phase de cadrage / planification de la fenêtre d'observation avec un cabinet d'audit de premier plan. Jusqu'à la publication du rapport, nous n'afficherons pas de badge SOC 2. Si la réalisation du SOC 2 est une exigence ferme pour vous aujourd'hui, écrivez à enterprise@abundera.ai, nous pouvons partager les preuves de contrôle actuelles, notre ébauche de description système et la date d'attestation projetée sous NDA.

9. Jamais de pixels tiers

C'est une promesse structurante et une limite produit, pas un paramètre par défaut que nous pourrions modifier discrètement. Nous n'injectons pas Google Analytics, Google Tag Manager, Meta Pixel, TikTok Pixel, LinkedIn Insight, Hotjar, FullStory ou tout autre tracker tiers, ni dans nos réponses de redirection, ni dans nos pages d'accueil hébergées, ni dans les surfaces du tableau de bord que voient vos scanners. Vos scanners ne sont jamais reciblés. Si vous avez besoin d'une attribution basée sur les pixels sur votre propre destination, ajoutez vos propres paramètres UTM (ou pixels) à l'URL de destination ; nous restons en dehors de la boucle. La redirection elle-même est un 302 de notre worker vers votre URL, rien d'autre ne s'exécute.

10. Divulgation responsable

Vous avez trouvé quelque chose ? Commencez par /.well-known/security.txt pour le contact actuel, la clé PGP et le périmètre. Écrivez à security@abundera.ai, nous accusons réception sous 24h (jours ouvrables), trions sous 72h, et coordonnons la correction + divulgation avec vous. Les chercheurs qui signalent de bonne foi reçoivent un crédit public sur abundera.ai/security/thanks/ une fois le correctif déployé.

11. État + disponibilité

L'état en direct, la santé des composants et l'historique des incidents sont sur /status/. Le chemin de redirection est surveillé toutes les 5 minutes par un Worker externe ; les composants dégradés ou en panne sont reflétés sur la page d'état dans un cycle de sondage.