Livre blanc sécurité
Dernière mise à jour : mai 2026
Ce document décrit les contrôles techniques et les pratiques opérationnelles mis en œuvre par GA Flight pour protéger les données des partenaires et des opérateurs. Il est rédigé à l'attention des équipes techniques réalisant une due diligence partenaire. Les affirmations contenues ici reflètent ce qui est implémenté et vérifiable — et non des éléments de feuille de route ou des certifications que GA Flight ne détient pas.
Identité et contrôle d'accès
Les opérateurs s'authentifient via des JWT à courte durée de vie ; les intégrations partenaires utilisent des clés API à portée définie, hachées et révocables individuellement.
Les sessions opérateur sont émises sous forme de JSON Web Tokens (JWT) à courte durée de vie, signés par une clé serveur. L'expiration des jetons est appliquée côté serveur ; les jetons de rafraîchissement sont renouvelés à chaque utilisation et invalidés à la déconnexion. Les clés API partenaires suivent un schéma préfixe-plus-hachage : la clé brute (préfixée gaf_pk_) est affichée une seule fois à la création ; seul un hachage SHA-256 est stocké en base de données. Chaque clé porte une liste de portées déclarées (ex. public.flights:read, public.training:read) appliquée à chaque requête. Les clés peuvent être révoquées individuellement sans affecter les autres clés de la même organisation. L'authentification multi-facteurs (MFA) est disponible pour tous les comptes opérateur. La connexion unique (SSO) via OpenID Connect (OIDC) et SAML 2.0 est prise en charge pour les organisations qui gèrent leur identité via un fournisseur externe. Le contrôle d'accès basé sur les rôles (RBAC) détermine quels opérateurs peuvent agir sur quelles ressources. Toutes les actions d'émission de justificatif sont écrites dans le journal d'audit.
Sécurité du transport
Tout le trafic est chiffré en transit avec TLS 1.2 ou supérieur ; les charges utiles des webhooks sont signées avec HMAC-SHA256 pour que les récepteurs puissent vérifier leur authenticité avant traitement.
L'API GA Flight et les propriétés web imposent TLS 1.2 comme version minimale. TLS 1.3 est préféré et négocié lorsque le client le prend en charge. HTTP Strict Transport Security (HSTS) est envoyé sur toutes les réponses ; il n'existe pas de repli HTTP en clair pour les surfaces authentifiées. Les livraisons de webhooks sortants sont signées via HMAC-SHA256 calculé sur le corps brut de la requête. Le secret de signature (préfixé whsec_) est généré à la création du point de terminaison et partagé une seule fois. Chaque livraison porte trois en-têtes : X-GA-Webhook-Delivery (UUID unique), X-GA-Webhook-Timestamp (horodatage ISO 8601) et X-GA-Webhook-Signature (sha256=<condensé hex>). Les récepteurs doivent vérifier la signature avant de faire confiance à la charge utile et rejeter les livraisons dont l'horodatage a plus de cinq minutes. Les livraisons échouées font l'objet de cinq tentatives avec un délai exponentiel.
Résidence des données
Les données des organisations basées dans l'UE sont stockées sur une infrastructure hébergée en UE ; l'application de la politique de résidence par requête empêche les écritures inter-régions.
GA Flight applique la résidence des données au niveau applicatif via une politique évaluée à chaque requête d'écriture. Le middleware enforceDataResidencyPolicy valide que la région cible des données d'une organisation correspond à l'ensemble autorisé pour la configuration de résidence de ce client avant toute écriture en base de données. Les clients basés dans l'UE sont routés vers des nœuds de base de données hébergés en UE. Le stockage primaire est hébergé en France (membre de l'Union européenne). Aucune donnée opérationnelle des organisations UE n'est écrite dans un stockage hors UE par défaut. Cette implémentation est en production et vérifiable par examen du code de traitement des requêtes. Elle n'a pas encore fait l'objet d'un audit ou d'une certification par un tiers indépendant. GA Flight ne revendique pas de certification ISO 27001, SOC 2 ou tout autre cadre à ce jour. Les contrôles de résidence décrits ici sont des mesures techniques, non des certifications de conformité.
Journal d'audit
Chaque action opérateur significative est enregistrée dans un journal d'audit par organisation ; les enregistrements de validation de formation forment une séquence cryptographiquement chaînée garantissant la traçabilité.
GA Flight maintient une table audit_log à portée par organisation. Chaque action d'émission de justificatif, modification des droits d'accès, export de données et opération administrative est enregistrée avec l'identité de l'utilisateur, l'horodatage, la ressource concernée et le type d'action. Les journaux sont en ajout seul (append-only) au niveau applicatif. Les enregistrements de validation de programme de formation sont organisés dans une structure audit_chain. Chaque enregistrement de validation référence le hachage de l'enregistrement précédent dans la chaîne, créant une séquence à résistance aux falsifications. Cette conception de chaîne de conservation signifie qu'insérer ou modifier un enregistrement de validation historique briserait la chaîne au point de modification, rendant la falsification détectable sans nécessiter d'autorité d'audit centrale. Les entrées du journal d'audit sont accessibles aux administrateurs d'organisation dans la console GA Flight. L'export en masse est disponible pour les revues de conformité.
Limitation de débit
L'API publique applique 13 compartiments de limitation de débit nommés avec des plafonds par organisation et par locataire, offrant une résistance de base aux dénis de service.
L'API publique de GA Flight applique la limitation de débit via un système de compartiments en couches. Treize compartiments nommés couvrent des familles de ressources distinctes — par exemple, les lectures de vols, les requêtes d'enregistrements de formation, la relecture de webhooks et les points de terminaison d'authentification disposent chacun de compteurs indépendants. Cela empêche un consommateur à haut volume d'un type de ressource d'épuiser les limites sur des points de terminaison sans rapport. Les plafonds sont appliqués à deux niveaux : par clé API (limitant une seule intégration partenaire) et par organisation (plafonnant la charge agrégée qu'une seule organisation peut générer, quel que soit le nombre de clés émises). Les réponses incluent des en-têtes de limitation standard (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) afin que les intégrateurs puissent implémenter un backoff côté client sans avoir à deviner. Des allocations de rafale sont accordées pour les pics de trafic courts dans des limites définies.
Conformité RGPD
GA Flight respecte les droits des personnes concernées incluant l'export et la suppression, met un accord de traitement des données à disposition sur demande, utilise un stockage UE-primaire et n'intègre pas de balises analytiques par défaut.
GA Flight agit en tant que sous-traitant pour le compte des organisations opérateur (les responsables du traitement) pour les données opérationnelles, et en tant que responsable du traitement pour ses propres données de compte de plateforme. Un accord de traitement des données (DPA) est disponible pour toutes les organisations payantes sur demande à security@gaflight.io. Les droits des personnes concernées sont respectés : toute personne concernée peut demander un export complet de ses données personnelles ou en demander la suppression. Les demandes de suppression sont traitées dans les 30 jours et se propagent à tous les enregistrements associés, sous réserve des obligations de conservation. Les opérateurs peuvent initier les workflows d'export et de suppression via la console ou en contactant le support. Le site marketing de GA Flight n'intègre pas de balises analytiques tiers par défaut. Les analyses internes utilisent uniquement une mesure cookieless à portée de session. Le stockage primaire des données est hébergé en UE (France).
Sous-traitants
GA Flight utilise une liste restreinte et auditable de sous-traitants tiers. Les opérateurs peuvent demander la liste à jour via le DPA.
Les sous-traitants tiers suivants traitent des données personnelles pour le compte de GA Flight : Stripe, Inc. — traitement des paiements et facturation. Stripe traite les données de carte bancaire dans le cadre de son propre programme de conformité PCI DSS. GA Flight ne stocke pas les numéros de carte bruts. [À confirmer par l'opérateur avant publication : prestataire de distribution d'e-mails — confirmer le nom du prestataire, la localisation des données et le statut DPA avant de rendre ce document public.] [À confirmer par l'opérateur avant publication : prestataire de stockage de fichiers et documents — confirmer le nom du prestataire, la localisation des données et le statut DPA avant de rendre ce document public.] Sentry (Functional Software, Inc.) — surveillance des erreurs et rapports de plantage. Les charges utiles d'erreur peuvent inclure des traces de pile et des métadonnées de requête ; les données personnelles sont nettoyées dans la mesure du possible via les règles de suppression de Sentry. GA Flight révise les accords des sous-traitants chaque année et notifie les clients des modifications importantes de cette liste avec un préavis d'au moins 30 jours.
Gestion des incidents
GA Flight s'engage à notifier les clients concernés dans les 24 heures suivant un incident de sécurité matériel confirmé et à publier une revue post-incident.
GA Flight maintient une procédure interne de gestion des incidents couvrant les phases de détection, confinement, éradication et rétablissement. Les responsabilités de permanence sont assignées à des ingénieurs nommés avec des voies d'escalade définies. Pour les incidents classés comme matériels — ceux impliquant un accès non autorisé à des données personnelles, une perturbation significative du service ou la compromission de clés de signature — GA Flight s'engage à notifier les organisations opérateur concernées dans les 24 heures suivant la confirmation. La notification est délivrée via l'adresse e-mail de l'administrateur enregistré de l'organisation et, le cas échéant, par alerte dans la console. Après résolution d'un incident matériel, GA Flight publie une revue post-incident couvrant la chronologie, la cause racine, le périmètre d'impact et les mesures correctives prises. Cette revue est partagée avec les clients concernés et conservée pour référence future. GA Flight ne garantit pas une exploitation sans incident. L'engagement ici est une communication transparente et rapide, ainsi qu'une remédiation documentée lorsque des incidents surviennent.
Divulgation des vulnérabilités
GA Flight accepte les signalements de vulnérabilités à security@gaflight.io dans le cadre d'une fenêtre de divulgation coordonnée de 90 jours. Les signalements valides font l'objet d'une reconnaissance publique.
Les chercheurs en sécurité qui identifient une vulnérabilité dans la plateforme GA Flight sont invités à la signaler à security@gaflight.io. GA Flight suit un modèle de divulgation coordonnée : les rapporteurs sont invités à garder les découvertes confidentielles pendant 90 jours au maximum à compter du premier contact, donnant à GA Flight le temps d'enquêter, de développer un correctif et de déployer une remédiation avant que les détails ne soient rendus publics. GA Flight s'engage à : accuser réception d'un signalement dans les cinq jours ouvrés ; fournir une mise à jour de statut dans les 14 jours ; et coordonner le calendrier de divulgation publique avec le rapporteur dans la mesure du possible. GA Flight n'opère pas actuellement de programme de primes aux bugs. Les signalements valides ayant abouti à un correctif de sécurité confirmé sont reconnus publiquement dans le changelog ou l'avis de sécurité pertinent, avec le nom ou le pseudonyme du rapporteur inclus sauf si l'anonymat est demandé. Le périmètre inclut l'application web GA Flight, l'API publique et l'infrastructure de livraison de webhooks. Hors périmètre : ingénierie sociale, accès physique et services tiers (signalez-les directement au fournisseur concerné).
Questions sur ce document ou sur nos pratiques de sécurité : security@gaflight.io
Privacy Policy →