Politique de sécurité des données

Mesures techniques et organisationnelles, gestion des incidents, signalement de vulnérabilités.

---

1. Objectif

Cette politique décrit les mesures de sécurité appliquées à GoLynk afin de protéger la confidentialité, l'intégrité et la disponibilité des données de nos utilisateurs.

2. Chiffrement

2.1 Chiffrement en transit

Toutes les communications entre votre navigateur et nos serveurs sont chiffrées via HTTPS/TLS.

2.2 Chiffrement au repos (côté client)

Les données applicatives sensibles (trésorerie, messagerie) sont chiffrées côté client avec l'algorithme AES-256-GCM avant d'être transmises à nos serveurs. La clé de chiffrement est dérivée de votre compte et n'est jamais transmise en clair à GoLynk. Cela signifie que même en cas d'accès non autorisé à la base de données, vos données métier restent illisibles.

2.3 Rotation des clés

Vous pouvez renouveler votre clé de chiffrement depuis les paramètres de sécurité de votre compte. Toutes les données sont alors re-chiffrées avec la nouvelle clé.

3. Contrôles d'accès

• Row Level Security (RLS) : chaque table de la base de données est protégée par des règles qui garantissent qu'un utilisateur ne peut accéder qu'à ses propres données. Ces règles sont appliquées au niveau de la base de données (Supabase/PostgreSQL), indépendamment du code applicatif.
• Séparation des rôles : les opérations sensibles (ajout de crédits, activation d'abonnement) ne sont exécutables que par le service role (Edge Functions), jamais par le client.
• Protection des champs sensibles : le champ account_plan est protégé par un trigger SQL qui empêche toute modification directe par l'utilisateur.

3 bis. Accès tokenisé pour tiers (portail client)

• Entropie du token : chaque lien de portail contient un token cryptographique de 288 bits d'entropie, généré côté serveur via crypto.getRandomValues. La probabilité de collision ou de brute-force est statistiquement nulle.
• Isolation par RLS : les tokens sont stockés dans une table dédiée protégée par Row Level Security stricte. Aucun client tokenisé ne peut accéder à un autre token ni énumérer d'autres clients ; aucune requête directe à la base depuis le portail public n'est possible.
• Validation côté serveur uniquement : un Edge Function dédié valide le token avant de retourner les données. Le portail public ne dispose jamais des credentials base de données.
• Rate-limiting : l'endpoint de validation applique une limitation stricte (max 20 requêtes/minute par IP). Les tentatives répétées sont rejetées et journalisées.
• Révocation instantanée : la régénération d'un token invalide l'ancien immédiatement (aucun délai de propagation cache). La prochaine requête utilisant l'ancien token est rejetée.
• Confidentialité du token : les tokens ne sont jamais inclus dans les logs serveur, les exports ou les sauvegardes en clair. Ils ne sont affichés à l'Utilisateur émetteur que sur demande explicite (bouton « Révéler »).
• Audit non-intrusif : seuls le compteur d'accès et la date du dernier accès sont conservés. Aucune adresse IP du tiers accédant n'est stockée de manière persistante.

4. Authentification

• Authentification par email et mot de passe.
• Option d'authentification à deux facteurs (2FA/TOTP) disponible.
• Limitation des tentatives de connexion échouées (rate limiting).
• Vérification par e-mail lors de la création du compte.

5. Paiements

Les paiements sont traités par Payrexx AG (Thun, Suisse). GoLynk ne stocke, ne traite et ne transmet aucune donnée bancaire (numéro de carte, IBAN de paiement). Les webhooks de paiement sont protégés par vérification d'intégrité (HMAC, referenceId, vérification du montant).

6. Stockage local

Certaines données peuvent être stockées sur l'appareil de l'utilisateur (localStorage) pour améliorer l'expérience (sessions, préférences, cache). En environnement sensible, l'utilisateur peut désactiver ce stockage ou le vider régulièrement via la déconnexion.

7. Sous-traitants

Nous sélectionnons des prestataires (hébergement, email, paiement) et encadrons la sous-traitance par des engagements contractuels et des exigences de sécurité. La liste complète figure dans la Politique de confidentialité.

8. Gestion des incidents

• Détection, qualification, confinement, correction et documentation.
• Notification aux autorités et/ou aux personnes concernées lorsque requis par la loi (LPD).
• Post-mortem et amélioration continue.

9. Signalement de vulnérabilités

• Description de la vulnérabilité
• Étapes de reproduction
• Impact estimé

Nous nous engageons à traiter votre signalement de manière responsable et à vous tenir informé des suites.

9 bis. Intégrité des exports comptables & transmission à des organes officiels

• À la clôture annuelle, le bilan, le compte de résultat et le journal des écritures sont exportés au format PDF horodaté.
• Chaque PDF généré est accompagné d'une empreinte cryptographique SHA-256 pour garantir son intégrité (détection de toute modification ultérieure).
• La transmission de ces documents à des organes officiels (autorité fiscale cantonale, AFC, caisse de compensation AVS, OCR) n'est effectuée qu'après vérification de conformité explicite par le Client. Aucune transmission automatique.
• Chaque envoi est journalisé : horodatage, destinataire, hash du fichier, identifiant du Client validant, sont conservés pendant la durée légale de conservation comptable (10 ans, CO art. 958f).
• Les journaux de transmission sont consultables sur demande dans le cadre d'une procédure de contrôle.

10. Sauvegardes

GoLynk propose un système de sauvegarde cloud automatique et manuelle. Les sauvegardes sont chiffrées. L'utilisateur est néanmoins encouragé à maintenir ses propres sauvegardes (export depuis les paramètres).

11. Amélioration continue

Nous réévaluons périodiquement nos mesures de sécurité et adaptons nos contrôles en fonction des risques et de l'évolution du Service.