Politique de sécurité des informations

1. Périmètre et responsable

Cette politique couvre le site slygo.fr, l'app Slygo, son extension navigateur, ses serveurs et les personnes qui les exploitent.

• Responsable de la sécurité : Khaled El Ghandri, président de Kera Consulting, chargé d'appliquer et de revoir cette politique.
• Contact pour toute question ou tout signalement de sécurité : support@slygo.fr.

2. Principes

• Minimisation : Slygo ne lit que ce qui sert au calcul du bénéfice net, en lecture seule, et ne demande jamais le nom, l'email, le téléphone ou l'adresse des acheteurs.
• Moindre privilège : chaque personne et chaque composant n'a que les accès nécessaires.
• Défense en profondeur : chiffrement, isolement réseau, règles d'accès en base et tests automatiques protègent les données chacun de leur côté.
• Transparence : les vendeurs sont informés par la politique de confidentialité et l'accord de traitement des données (DPA).

3. Classification des données

• Confidentiel : jetons d'accès des plateformes connectées, clés d'API et secrets du serveur. Chiffrés au repos par l'application (AES-256-GCM) en plus du chiffrement de la base, jamais envoyés au navigateur, jamais journalisés, conservés hors du code.
• Interne : données commerciales des vendeurs (produits, coûts, commandes, remboursements, frais, dépenses publicitaires). Chiffrées au repos par l'hébergeur de la base, isolées par vendeur par des règles d'accès en base.
• Public : le site et les documents publiés.

Les données personnelles des acheteurs sont exclues par conception.

4. Chiffrement

• En transit : HTTPS (TLS 1.2 ou plus) pour toute connexion, y compris les appels aux plateformes connectées ; le serveur n'accepte que du HTTPS depuis l'extérieur.
• Au repos : stockage de la base chiffré par l'hébergeur (Supabase, AES-256) ; jetons d'accès chiffrés en plus par l'application avec une clé dédiée, présente uniquement sur le serveur.
• Les notifications reçues des plateformes (webhooks) sont refusées si leur signature cryptographique n'est pas valide.

5. Infrastructure et réseau

• Hébergement dans l'Union européenne : serveur d'application chez OVHcloud (France), base de données chez Supabase (Irlande).
• Pare-feu : seuls HTTPS (443), HTTP (80, redirigé vers HTTPS) et SSH (22) sont ouverts ; tous les autres ports sont fermés.
• Cloisonnement : l'application et les bases n'écoutent que sur l'interface interne du serveur et ne sont joignables que par le proxy HTTPS ; chaque service tourne dans son propre conteneur isolé.
• Accès d'administration aux serveurs par clé SSH uniquement, avec blocage automatique des tentatives répétées.
• Mises à jour de sécurité du système installées automatiquement.

6. Contrôle des accès

• L'accès à la production (serveurs, base, consoles cloud et plateformes, DNS, dépôt de code) est réservé au responsable de la sécurité.
• L'authentification à plusieurs facteurs est exigée sur chaque compte d'administration.
• Dans l'app, des règles d'accès en base (row-level security) limitent chaque vendeur à ses propres données ; elles sont couvertes par des tests automatiques à chaque changement.
• La clé serveur qui contourne ces règles est limitée à un seul module serveur, vérifié par un test automatique, et chaque écriture est restreinte au vendeur concerné.
• Les droits d'accès sont revus chaque trimestre et retirés dès qu'ils ne sont plus nécessaires.

7. Sécurité au quotidien et postes de travail

• Les postes de l'entreprise ont le disque chiffré, le verrouillage automatique de l'écran, la protection anti-logiciels malveillants intégrée au système et les mises à jour automatiques.
• Des mots de passe forts et uniques sont conservés dans un gestionnaire de mots de passe ; l'authentification à plusieurs facteurs est activée partout où elle existe.
• Les secrets ne sont jamais échangés par email ou messagerie, ni stockés dans le code.

8. Développement sécurisé

• Chaque changement passe par une demande de fusion et une chaîne automatique : tests unitaires, tests d'intégration, tests des règles d'accès en base, typage et lint.
• Le build de production est refusé s'il contient un secret ou une adresse locale.
• Les plateformes connectées sont lues avec des permissions en lecture seule.

9. Gestion des vulnérabilités et des menaces

• Les systèmes des serveurs reçoivent les mises à jour de sécurité automatiquement ; les dépendances de l'app sont revues au moins une fois par mois au regard des alertes de sécurité publiées.
• Les vulnérabilités critiques sont corrigées ou atténuées sous 7 jours, les élevées sous 30 jours.
• Jetons et clés peuvent être révoqués et renouvelés à tout moment ; une connexion compromise est coupée immédiatement.

10. Réponse aux incidents

• Rôles : le responsable de la sécurité pilote la réponse (évaluation, confinement, communication) et documente chaque incident.
• Canal de signalement : toute personne peut signaler un incident ou une vulnérabilité supposés à support@slygo.fr.
• Étapes : détecter et évaluer ; confiner (révoquer les jetons, renouveler les clés, couper l'accès concerné) ; corriger ; notifier ; tirer les enseignements.
• Notification : les vendeurs concernés et les plateformes concernées (TikTok Shop, Shopify, Meta, Amazon) sont prévenus sans délai injustifié et dans les 48 heures après la découverte d'une violation de données personnelles ; la CNIL est notifiée sous 72 heures lorsque c'est requis.

11. Conservation et suppression

• Les données d'un vendeur sont conservées tant que son compte existe, puis supprimées avec lui ; le vendeur peut le faire lui-même depuis les réglages de l'app.
• Les jetons d'une connexion sont effacés dès qu'elle est retirée ou révoquée par la plateforme.
• Le journal technique des notifications des plateformes est purgé au bout de 30 jours.
• Sur demande d'un vendeur ou d'une plateforme, les données sont fournies, corrigées ou supprimées.

12. Sous-traitants

• OVH SAS (OVHcloud), hébergement de l'app, France.
• Supabase Inc., base de données et authentification, centre de données en Irlande (UE).
• Resend Inc., emails de connexion et de notification.

La liste complète et ses mises à jour figurent dans l'accord de traitement des données.