Notre modèle de sécurité
J Tools exécute vos opérations sur les tokens sans jamais prendre la garde de votre portefeuille. Les transactions de vos portefeuilles sont signées de votre côté, la plateforme les construit et les envoie, et des protections côté serveur encadrent l’ensemble.
En bref
#en-brefNon-custodial par conception
#non-custodial-par-conceptionJ Tools ne demande jamais votre phrase de récupération et ne détient jamais vos fonds. Quand vous utilisez un portefeuille connecté, chaque signature a lieu à l’intérieur de ce portefeuille, via l’adaptateur de portefeuille, et seule la transaction signée part vers le réseau. La clé privée du portefeuille ne le quitte jamais.
Page J Tools
1Vous préparez une action dans J Tools
La transaction arrive dans votre portefeuille
Votre portefeuille
2Votre portefeuille affiche la transaction
3Vous approuvez et signez dans votre propre portefeuille
Les clés d'un portefeuille connecté ne le quittent jamais
Seule la signature sort, jamais la clé
Solana
4La transaction signée est diffusée sur Solana
Certains outils peuvent aussi signer avec des clés privées que vous collez, parce qu’ils travaillent sur de nombreux portefeuilles qu’aucun adaptateur ne connecte : entre autres Trade groupé, Échange multiple, Envoi multiple, Collecteur par lot, les outils de relais, Pump.fun : créer et acheter en bundle et les outils de réclamation. Ces clés restent dans l’onglet de votre navigateur et y signent, sans jamais nous être envoyées. Une clé collée comme source de clé privée d’un outil est effacée au bout de 15 minutes. Traitez-les comme des portefeuilles chauds jetables. Holder Booster est le seul outil qui confie une clé à nos serveurs : il crée un portefeuille distributeur neuf pour chaque exécution, garde les clés des portefeuilles détenteurs dans le fichier de sauvegarde que vous téléchargez, et n’envoie que la clé du distributeur, chiffrée, pour que notre worker puisse terminer l’exécution après la fermeture de l’onglet. Si une page vous demande votre phrase de récupération, ce n’est pas nous.
Une chaîne d’audit qui révèle toute falsification
#une-chaine-daudit-qui-revele-toute-falsificationLes actions d’administration sont écrites dans un journal d’audit en ajout seul. Chaque ligne porte un prev_hash, une empreinte SHA-256 de la ligne précédente, ce qui relie les entrées comme les maillons d’une chaîne. Modifiez ou supprimez une ligne, et toutes les empreintes suivantes ne correspondent plus : la modification saute aux yeux. Les entrées du journal ne contiennent ni mots de passe ni jetons de session.
Liste blanche RPC et limites de requêtes
#liste-blanche-rpc-et-limites-de-requetesLe navigateur ne parle pas directement à un nœud Solana. Il passe par une passerelle qui n’autorise qu’une liste fixe de méthodes de lecture, plus l’envoi et la simulation de transactions, et qui plafonne les requêtes par IP. Les URL et les clés RPC restent côté serveur, donc le navigateur n’a rien à divulguer. Les limites s’appliquent par endpoint, et la véritable IP du client est lue dans la valeur la plus à droite de x-forwarded-for, pour qu’un en-tête falsifié ne permette pas de contourner la limite.
Protection contre le détournement des frais
#protection-contre-le-detournement-des-fraisQuand un outil facture des frais de la plateforme, le montant enregistré pour la commission vient de nos propres réglages de frais ou du SOL réellement arrivé on-chain sur le portefeuille de la plateforme, jamais d’un chiffre envoyé par le navigateur. Aucun chemin ne fait confiance à des frais fournis par le client. Vous voyez le détail complet (total, frais de la plateforme et frais réseau estimés) sur la carte des frais de l’outil avant de confirmer quoi que ce soit. Pour les valeurs de référence, consultez le récapitulatif des frais de l’application ou le Barème des frais.
Un accès à l’administration verrouillé
#un-acces-a-ladministration-verrouilleAccéder au panneau d’administration exige un mot de passe et un code TOTP, contrôlés côté serveur. Le parcours est conçu pour ne rien laisser filtrer.
Le TOTP est obligatoire. Les codes sont vérifiés côté serveur, et une série de tentatives échouées bloque la connexion pendant un délai de refroidissement. La raison du blocage n’est jamais renvoyée au client.
Les mots de passe d’administration ne sont stockés que sous forme d’empreintes à sens unique, configurées par variables d’environnement. Il n’existe aucun écran de réinitialisation du mot de passe, ni dans le panneau ni dans l’API ; un changement passe par une nouvelle valeur d’environnement et un déploiement.
Une connexion échouée renvoie le même message générique, que ce soit le nom d’utilisateur, le mot de passe ou le code qui soit faux, et la vérification d’un nom d’utilisateur inconnu prend autant de temps que celle d’un nom réel. Une connexion bloquée indique seulement qu’il y a eu trop de tentatives, jamais quelle limite a été atteinte. Les tentatives de connexion sont limitées à la fois par IP et par nom d’utilisateur.
Les sessions sont stockées côté serveur, avec des cookies httpOnly, Secure et SameSite=Strict et des identifiants aléatoires. Elles sont renouvelées à chaque connexion pour contrer la fixation de session, expirent après une période d’inactivité et sont limitées en nombre par administrateur.
L’OPSEC partout
#lopsec-partoutLa sécurité opérationnelle est une règle permanente sur chaque endpoint et chaque page. Les secrets, les clés privées et les jetons complets sont tenus à l’écart des journaux. Une réponse d’erreur envoyée au client contient un court message, souvent avec un code, sans trace de pile, chemin interne ni détail de base de données ; le tableau complet reste dans les journaux du serveur. Les articles de blog rédigés par automatisation restent des brouillons jusqu’à ce qu’un administrateur les publie, donc rien n’atteint les lecteurs sans la validation d’une personne.
© 2026 J Tools