Politique de sécurité et 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é appliquees a GoLynk afin de proteger 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'etre transmises à nos serveurs. La clé de chiffrement est dérivée de votre compte et n'est jamais transmise en clair a 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 de cles

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 cle.

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 acceder qu'a ses propres données. Ces règles sont appliquees au niveau de la base de données (Supabase/PostgreSQL), indépendamment du code applicatif.
• Separation des roles : les operations 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 protege par un trigger SQL qui empeche 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 a deux facteurs (2FA/TOTP) disponible.
• Limitation des tentatives de connexion échouées (rate limiting).
• Verification par email lors de la creation de compte.

5. Paiements

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

6. Stockage local

Certaines données peuvent être stockées sur l'appareil de l'utilisateur (localStorage) pour ameliorer l'experience (sessions, preferences, cache). En environnement sensible, l'utilisateur peut désactiver ce stockage ou le vider régulièrement via la deconnexion.

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 complete figure dans la Politique de confidentialité.

8. Gestion des incidents

• Detection, qualification, confinement, correction et documentation.
• Notification aux autorites et/ou aux personnes concernees lorsque requis par la loi (LPD).
• Post-mortem et amélioration continue.

9. Signalement de vulnérabilités

• Description de la vulnérabilité
• Etapes de reproduction
• Impact estime

Nous nous engageons a traiter votre signalement de manière responsable et a vous tenir informe 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 neanmoins encourage a maintenir ses propres sauvegardes (export depuis les paramètres).

11. Amelioration continue

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