Sécurité et confidentialité

La sécurité est fondamentale pour une plateforme où les utilisateurs nous confient leurs autorisations de portefeuille et l'exécution de leurs transactions. Ce document décrit ce que nous faisons pour vous protéger, ce que vous pouvez faire pour vous protéger vous-même, et la façon dont nous traitons les données.

Contre quoi nous vous protégeons

Nous avons mis en place des défenses contre chacune de ces menaces.

Sécurité du portefeuille

Nous ne détenons jamais vos fonds. Vos USDC restent dans votre portefeuille. Predite signe des transactions en votre nom uniquement lorsque vous le confirmez explicitement. Nous ne pouvons pas déplacer vos fonds sans votre autorisation active.

Stockage chiffré des clés. Pour trader sur le CLOB de Polymarket, Predite conserve la private key du portefeuille que vous connectez — il n'existe aucun flux de pop-up dans le navigateur, car le CLOB est une API et les ordres sont signés côté serveur. La clé arrive via HTTPS, est chiffrée avec AES-256-GCM (clé dérivée par scrypt, un IV aléatoire neuf par enregistrement), et seul le ciphertext est stocké. Elle est déchiffrée en mémoire le temps qu'un ordre soit signé, et n'est jamais écrite dans les journaux. Soyons lucides : il s'agit bien de la conservation d'une clé de trading chaude. La mesure qui vous protège réellement, c'est d'alimenter un portefeuille dédié uniquement avec votre capital de trading.

Les approbations on-chain sont illimitées — et c'est Predite qui les pose, pas vous. Avant votre premier ordre, le portefeuille doit approuver les contrats de Polymarket, et ces approbations sont envoyées en votre nom sous forme d'approbation ILLIMITÉE, plus une approbation générale sur les outcome tokens. C'est ainsi que fonctionne polymarket.com également, mais cela signifie que l'allowance n'est pas votre contrôle d'exposition. Ce qui borne réellement votre exposition : les plafonds par ordre et quotidiens, les limites par bot, votre kill switch, et la taille du portefeuille dédié que vous avez alimenté.

Révocable. Vous pouvez révoquer notre accès à tout moment via les paramètres d'approbation de jetons de votre portefeuille sur Polygonscan.

Sécurité du compte

Authentification via Clerk. Nous ne gérons pas les mots de passe nous-mêmes — Clerk s'en charge. Ils sont spécialisés dans l'authentification et suivent les meilleures pratiques du secteur (hachage des mots de passe avec bcrypt, limitation du débit, détection des fuites).

Plan Bot + flag bêta par compte. Le trading en direct est verrouillé deux fois : un abonnement Bot actif et un flag bêta par compte que seul le support peut activer. Ni l'API ni l'UI ne peuvent le contourner.

Gestion des sessions. Les sessions expirent automatiquement. Vous pouvez consulter et révoquer les sessions actives à tout moment dans votre profil.

Vérification de l'e-mail. Les modifications d'adresse e-mail nécessitent une vérification de la nouvelle adresse avant de prendre effet.

Sécurité applicative

HTTPS partout. TLS 1.3 pour toutes les connexions. Aucun repli sur HTTP.

Content Security Policy. Des en-têtes CSP stricts empêchent l'injection de scripts.

Limitation du débit. Des limites de débit agressives préviennent les attaques par force brute, les abus d'API et les tentatives de DDoS.

Protection CSRF. Chaque action modifiant l'état nécessite un nouveau jeton CSRF. Cela empêche la falsification de requête intersite (CSRF).

Prévention des injections SQL. Des requêtes paramétrées partout. Aucune concaténation de chaînes dans les opérations de base de données.

Prévention des attaques XSS. Les saisies utilisateur sont assainies à chaque limite de rendu. L'échappement automatique de React aide, mais nous ne nous y fions pas seul.

Sécurité de la base de données

Chiffrement au repos. Supabase chiffre toutes les données sur disque.

Sécurité au niveau des lignes. Chaque utilisateur ne voit que ses propres données — une règle appliquée au niveau de la base de données, et non au niveau applicatif. Même si le code de notre application présentait un bug, la base de données refuserait les requêtes non autorisées.

Journalisation d'audit. Chaque action sensible (transaction, retrait, changement de mot de passe, activation/désactivation du MFA) est journalisée avec horodatage et adresse IP.

Procédures de sauvegarde. Sauvegardes chiffrées quotidiennes avec une rétention de 90 jours. Restauration à un instant donné disponible.

Sécurité réseau

Protection DDoS Cloudflare. Notre couche de périphérie absorbe les attaques de trafic.

Infrastructure Vercel. Le trafic de production transite par le réseau renforcé de Vercel.

Aucun accès direct à la base de données. Notre base de données n'est pas accessible depuis l'internet public. Seule notre application peut s'y connecter.

Limites de débit de l'API. Des limites par utilisateur et par IP préviennent les abus et le scraping.

Ce que les utilisateurs peuvent faire

Mot de passe fort + MFA : un mot de passe unique généré par un gestionnaire de mots de passe, associé à un MFA par application d'authentification. Cela bloque 99 % des attaques.

Portefeuille matériel : pour des capitaux importants (>1 000 $), utilisez un Ledger ou un Trezor. Même si nos systèmes sont compromis, le portefeuille refuse les signatures non autorisées.

Vérifiez les URL : ajoutez directement predite.io à vos favoris. Les sites de phishing peuvent paraître identiques aux vrais — ne cliquez jamais sur des liens de connexion provenant d'e-mails.

Limitez les approbations : fixez des plafonds de dépense USDC bas. Renouvelez l'approbation en cas de besoin. Cela limite l'exposition à tout incident de sécurité.

Restez méfiant : un support légitime ne vous demandera jamais vos phrases de récupération, vos mots de passe ou vos codes 2FA. Quiconque vous les demande est un escroc.

Que se passe-t-il en cas de violation

Nous disposons d'un processus documenté de réponse aux incidents :

1. Détecter : la surveillance alerte notre équipe dans les minutes suivant une anomalie
2. Contenir : rotation des clés, révocation des sessions, arrêt de toute activité suspecte
3. Enquêter : analyse forensique complète avec chronologie
4. Notifier : les utilisateurs concernés sont avertis dans les 72 heures (exigence du RGPD)
5. Remédier : correction de la vulnérabilité, documentation de la leçon apprise, partage public
6. Restaurer : restauration à partir des sauvegardes si nécessaire

Nous n'avons jamais subi de violation. Mais si cela devait arriver, la transparence prime sur la commodité.

Conformité

Confidentialité

Nous ne vendons jamais les données des utilisateurs. Point final.

Signaler des problèmes de sécurité

Un programme de bug bounty est en préparation. Il est actuellement informel — les découvertes significatives donnent lieu à une reconnaissance, un crédit et des avoirs de compte/goodies.

Revue de sécurité indépendante

Nous divulguons actuellement nos affirmations de sécurité en toute honnêteté — nous parlons d'une « architecture prête pour SOC2 » et non d'une « certification SOC2 », car nous n'avons pas encore réalisé l'audit. De nombreuses plateformes font des affirmations trompeuses ; ce n'est pas notre cas.

Documents connexes