1. Périmètre de l'intégration
Trailboard est un outil indépendant de préparation de trail. La connexion Strava est optionnelle et sert à afficher, dans l’espace privé de l’athlète, des copies transitoires de ses activités autorisées et des indicateurs descriptifs personnels calculés à partir de ces copies.
Trailboard ne crée, ne modifie et ne supprime aucune activité sur Strava. L'application n'utilise pas les activités Strava pour établir un classement public entre athlètes.
Le périmètre public soumis à Strava se limite aux usages décrits sur cette page. Toute extension au-delà de ces usages nécessite une confirmation écrite de Strava avant son activation pour les utilisateurs.
2. Autorisation OAuth
- Le bouton de connexion redirige le navigateur vers l'écran OAuth officiel de Strava.
- Les permissions demandées dans le code sont « read » et « activity:read_all ». La seconde permet à l'athlète d'autoriser l'accès à ses activités privées pour son propre espace Trailboard.
- Le retour OAuth vérifie un état aléatoire à usage unique contre les attaques CSRF avant d'échanger le code d'autorisation.
- Les nouvelles écritures de jetons d'accès et de renouvellement utilisent un chiffrement AES-256-GCM dans PostgreSQL. Les secrets ne sont jamais inclus dans cette page publique ni dans les réponses du frontend.
3. Données Strava lues et finalité
Trailboard demande uniquement les ressources nécessaires aux fonctions personnelles actuellement proposées. Le code ne dispose d'aucun droit d'écriture sur les activités Strava.
Identité technique de l'athlète
Données : Identifiant Strava nécessaire à la liaison OAuth.
Finalité : Relier le compte autorisé à une identité interne. Le prénom, le nom, la photo, la ville et le pays reçus de Strava ne sont pas copiés dans le profil partageable Trailboard.
Résumés d'activité
Données : Identifiant, nom, sport, date, durée, distance, dénivelé, statistiques disponibles et visibilité.
Finalité : Afficher les activités et calculer, uniquement pour l'athlète connecté, des totaux, moyennes, tendances par période, records et progressions vers ses objectifs personnels. Ces résultats ne sont ni comparés entre membres, ni utilisés pour des analyses internes, l'amélioration du produit ou une fonctionnalité non déclarée sur cette page.
Détails, efforts et flux
Données : Détails de sortie, splits, efforts, GPS, altitude, temps, vitesse et flux capteur disponibles selon les autorisations et le matériel.
Finalité : Afficher la carte, le profil et les détails bruts liés à cette activité.
Photos et commentaires
Données : Photos et commentaires rattachés à l'activité lorsqu'ils sont accessibles par l'API.
Finalité : Compléter la vue privée du détail de l'activité.
4. Webhooks et synchronisation
- Trailboard expose un callback serveur public pour les événements Strava. Le secret de vérification n'est jamais publié.
- Une création ou une modification d'activité crée un travail ciblé de rafraîchissement. Une suppression crée un travail de suppression locale. Une désautorisation de l'athlète crée un travail de purge de la connexion et des activités synchronisées.
- Le traitement lourd est placé dans une file PostgreSQL durable afin que le callback réponde rapidement, que les tentatives soient contrôlées et qu'un redémarrage ne perde pas l'événement.
- Aucun polling périodique de l’API Strava n’est exécuté. Les appels proviennent uniquement de l’import initial, d’une action explicite de l’utilisateur ou d’un événement webhook ciblé.
- La subscription webhook de l’application de production est contrôlée séparément de la présence du callback dans le code.
5. Protection des quotas
- Les lectures du tableau de bord servent d'abord les données PostgreSQL et ne déclenchent pas un appel Strava bloquant à chaque affichage.
- Des verrous PostgreSQL empêchent deux synchronisations simultanées pour le même athlète ou la même application.
- Lorsqu'une réponse 429 est reçue, Trailboard enregistre le cooldown de l'application concernée et reporte les travaux jusqu'à la fenêtre de reprise.
- Les imports explicites sont bornés et s'arrêtent dès qu'une limite est rencontrée.
6. Désautorisation et suppression
- Un événement de désautorisation Strava annule les synchronisations actives et supprime la connexion, les copies Strava et les données personnelles dérivées correspondantes.
- La suppression du compte Trailboard supprime le compte et les enregistrements liés par transaction, confirme l’effacement à l’utilisateur et enregistre durablement la révocation distante du jeton Strava.
- Une suppression d'activité reçue par webhook supprime la copie locale possédée par cet athlète.
- Chaque copie Strava porte son propre horodatage de récupération et expire au plus tard après sept jours, indépendamment de la date de l’activité.
7. Sécurité et isolation
- Chaque route d'activité vérifie l'identité Trailboard courante et filtre les données par identifiant d'athlète.
- Le dépôt chiffre les nouvelles écritures OAuth avec AES-256-GCM et sérialise les renouvellements pour éviter les écritures concurrentes. L'absence de toute ancienne valeur en clair doit être vérifiée sur la base de production.
- Les callbacks et travaux transportent une génération de connexion : un événement ancien ne peut pas agir sur une connexion recréée plus récemment.
- Trailboard ne vend pas les données Strava et ne les utilise pas pour de la publicité ciblée.
8. Application Strava enregistrée
Toutes les nouvelles connexions et reconnexions passent par l’unique application Trailboard enregistrée auprès de Strava.
L’interface publique ne demande et n’accepte aucun Client ID ou Client Secret appartenant à un utilisateur. Les anciens champs techniques, désormais désactivés, ne peuvent subsister que sous forme chiffrée le temps d’une révocation distante ou de leur suppression.
9. Revue publique du processus Strava
- Avant chaque resoumission à Strava et après toute modification de l'intégration, Trailboard confronte le code concerné à l'API Policy, à l'API Agreement et à la documentation développeur alors en vigueur.
- La revue couvre OAuth et les scopes, l'isolation par athlète, les données et finalités déclarées, les statistiques privées, les webhooks, les quotas, les jetons invalides, la rétention par âge de copie, la désautorisation et la suppression.
- Les preuves sont séparées par niveau : tests et build du code, migrations et configuration, puis vérification réelle en production. La présence d'un callback ne prouve pas une subscription active, et un déploiement ne prouve pas un événement de bout en bout.
- Tout usage ambigu ou dépassant les textes publiés reste désactivé jusqu'à confirmation écrite de Strava. La date de cette page est mise à jour lorsque le processus ou son périmètre change.
10. Preuves à contrôler avant une resoumission
- L'application a atteint la capacité d'athlètes affichée dans le tableau de bord Strava.
- La subscription webhook de production est active et les événements create, update, delete et deauthorization sont observés de bout en bout.
- Le callback répond avec le code et dans le délai attendus par la documentation Strava courante.
- Les jetons invalides ou athlètes inactifs sont identifiés et retirés sans dépendre uniquement d'une ouverture du site par l'utilisateur.
- La rétention, le rafraîchissement et la suppression de chaque copie directe ou dérivée sont démontrés par ressource.
Références officielles
Cette description doit toujours être lue avec les textes Strava en vigueur.