Comment nous protégeons les données de votre club.
Sans le baratin marketing.
Le renseignement footballistique est sensible. Une shortlist divulguée fait échouer une transaction. Un dossier médical divulgué brise une carrière. Voici le modèle de sécurité complet de Scout Atlas — ce que nous faisons, comment nous le faisons, et ce que nous choisissons explicitement de ne pas faire.
Six engagements. Vérifiables.
Pilier 01
Chiffré par défaut
TLS 1.3 en transit. AES-256-GCM au repos. Les messages de la Deal Room sont chiffrés de bout en bout avec des clés propres à chaque salle, que nous ne pouvons pas lire.
Pilier 02
Identité vérifiée
Authentification par lien magique avec TOTP MFA en option. Adresses e-mail professionnelles liées au domaine. L'attribution des rôles requiert l'approbation d'un administrateur, et non une simple case à cocher soi-même.
Pilier 03
Isolation au niveau des lignes
Le RLS de Postgres applique les frontières entre clubs au niveau de la base de données. Un bug dans l'application ne peut pas exposer les données d'un autre club.
Pilier 04
Audit par défaut
Chaque action authentifiée — consultation, notation, message, dérogation — est journalisée de manière immuable. Les administrateurs de club peuvent exporter le journal d'audit de leur organisation à la demande.
Pilier 05
Soucieux de la conformité
GDPR, KVKK, SOC 2 Type II visés pour le 4ᵉ trimestre 2026. Un délégué à la protection des données dirigé par le fondateur traite chaque demande sous 30 jours.
Pilier 06
Aucun entraînement de modèle sans consentement
Les jeux de données publics entraînent Match et Vision. Les données privées des clubs membres sont chiffrées avec des clés propres à chaque club et ne sont jamais utilisées pour entraîner des modèles inter-clubs sans consentement écrit.
La liste complète, par domaine.
Si votre équipe de sécurité dispose d'un questionnaire d'achat, cette section en couvre environ 70 %. Nous remplirons volontiers le reste.
Authentification et accès
- OTP par lien magique Supabase, TOTP par clé matérielle en option
- Matrice de permissions par rôle appliquée dans le middleware + RLS
- Les administrateurs de club gèrent l'invitation, le rôle et la révocation
- Expiration de session : 7 jours d'inactivité, 30 jours en absolu, configurable par organisation
Protection des données
- AES-256-GCM au repos pour les colonnes sensibles (PII, données biométriques)
- TLS 1.3 en transit, HSTS preload, suites de chiffrement modernes uniquement
- Enveloppes de clés propres à chaque club pour les flux GPS/biométriques privés
- Sécurité au niveau des lignes dans Postgres pour chaque table rattachée à un club
Sécurité applicative
- Content-Security-Policy stricte + Trusted Types
- Validation des entrées sur chaque endpoint (liste d'autorisation, longueur maximale, coercition de type)
- Requêtes préparées uniquement — aucune concaténation de chaînes en SQL
- Dependabot + analyse des secrets activés à chaque commit
Opérationnel
- Test d'intrusion trimestriel par un cabinet indépendant (à partir de la 2ᵉ année)
- Ingénieurs ayant fait l'objet d'une vérification des antécédents ; aucun sous-traitant offshore avec accès à la production
- Sauvegardes chiffrées, rétention de 30 jours, testées chaque trimestre
- Runbook de réponse aux incidents avec rotation d'astreinte du fondateur
Confidentialité
- Demandes au titre des articles 15/17 du GDPR + KVKK traitées sous 30 jours
- Aucune revente de données. Aucun pistage publicitaire. Aucune analyse inter-contextuelle.
- Résidence des données en région UE disponible à partir du palier Analyst
- Suppression des données sur demande : suppression logique sous 30 jours, puis effacement cryptographique
Comment les messages de la Deal Room restent privés.
La messagerie de la Deal Room est chiffrée de bout en bout avec les mêmes primitives que Signal — l'accord de clés X3DH et le Double Ratchet — et s'exécute entièrement dans le navigateur via l'API Web Crypto. Le serveur achemine le texte chiffré et les préclés publiques ; il ne détient jamais les clés qui déchiffrent une conversation.
Étape 01
Accord de clés X3DH
Chaque membre détient une clé de signature Ed25519 et une clé ECDH X25519. Pour ouvrir un canal, l'initiateur récupère le bundle de préclés du destinataire — une préclé signée et, lorsqu'elle est disponible, une préclé à usage unique — et exécute un échange Diffie-Hellman triple (3-DH). La préclé signée prouve que le bundle appartient au destinataire et non à un serveur qui l'usurpe.
Étape 02
Double Ratchet
Le secret partagé amorce un Double Ratchet. Une chaîne de clés symétriques HKDF-SHA256 avance à chaque message, de sorte qu'une clé divulguée ne révèle rien sur les messages antérieurs (confidentialité persistante). Une étape de cliquet Diffie-Hellman sur de nouvelles clés éphémères rétablit la session après une brève compromission d'un appareil (sécurité post-compromission).
Étape 03
Scellement de message AES-256-GCM
Chaque clé par message scelle le texte en clair avec AES-256-GCM (chiffrement authentifié, IV de 96 bits). Le serveur ne conserve que le texte chiffré, l'IV et la clé éphémère publique de l'expéditeur. Il n'a aucun accès aux clés de message dérivées sur le client.
Des clés que le serveur ne détient jamais.
Les clés privées d'identité, de préclé et de cliquet sont générées et conservées sur les appareils des membres. Le point de terminaison du bundle ne stocke que des préclés publiques opaques ; les clés de message n'existent que dans la mémoire du navigateur. Conséquence pratique : même Scout Atlas ne peut pas lire le contenu de la Deal Room — il n'existe aucune clé côté serveur que l'on pourrait exiger.
Où en sommes-nous aujourd'hui.
Il s'agit de la conception de chiffrement actuellement déployée à un stade précoce (v0). La cryptographie est implémentée et éprouvée par des tests, mais elle n'a pas encore fait l'objet d'un audit indépendant par un tiers et nous ne la décrivons pas encore comme durcie pour la production. Le canal de préclés se dégrade en douceur — les préclés à usage unique conservent un seuil de réserve, de sorte qu'un pool épuisé bascule vers un X3DH à préclé signée uniquement plutôt que d'échouer de manière ouverte. Nous mettrons cette page à jour à mesure que la conception mûrira et sera examinée.
Résidence en région UE et base de transfert.
Les clubs membres établis dans l'UE peuvent demander la résidence des données en région UE à partir du niveau Analyst. Lorsque des données personnelles sont transférées hors de l'EEE ou du Royaume-Uni, nous nous appuyons sur les clauses contractuelles types (CCT/SCC) de la Commission européenne ou sur une décision d'adéquation applicable ; les transferts hors de Türkiye sont effectués sous les garanties exigées par l'article 9 de la KVKK. La politique complète figure dans notre avis de protection des données.
Ce sur quoi nous ne transigerons pas.
Vendre ou partager vos données.
Aucune revente de données, aucun partenariat avec des courtiers, aucun jeu de données « anonymisé » en coulisses. Votre effectif vous appartient.
Entraîner des modèles sur des données privées sans consentement.
Les données privées des clubs membres (GPS, biométrie, médical) n'entraînent aucun modèle. Point final. Les jeux de données publics sont divulgués publiquement.
Lire les messages de votre Deal Room.
La messagerie de la Deal Room est chiffrée de bout en bout. Même sur réquisition judiciaire, nous ne pourrions pas en produire le contenu.
Étouffer les incidents.
Tout incident de sécurité touchant les données des membres est divulgué aux clubs concernés sous 72 heures, avec un post-mortem écrit sous 14 jours.
Vous avez trouvé une faille ? Nous voulons en être informés.
Nous menons un programme ouvert de divulgation responsable. Écrivez à security@scoutatlas.co en précisant les détails et les étapes de reproduction. Nous répondons sous 48 heures et créditons les chercheurs dans notre changelog lors de la publication des correctifs.