---
title: "Signature de portefeuille"
description: "Une signature de portefeuille prouve qu'une clé ou un compte contrat a approuvé des données exactes selon des règles précises. Distinguez messages, transactions, permits, rejeu et hameçonnage."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Signature de portefeuille
> À visée éducative uniquement ; ne constitue pas un conseil en investissement ou en sécurité. Une demande de signature malveillante peut causer une perte irréversible.
## Réponse directe
Une signature de portefeuille est la preuve cryptographique qu'une clé privée, ou la politique d'un compte intelligent, a approuvé un message codé précis. La vérification identifie le compte pour ces octets et ces règles ; elle ne prouve ni l'identité juridique, ni la compréhension du signataire, ni l'honnêteté de la description du site.
Signer n'est pas une action uniforme. Une signature de transaction autorise directement une opération réseau. Un message hors chaîne peut être un défi de connexion sans pouvoir sur les actifs, ou un ordre, un permit de jeton, une instruction de gouvernance ou une autre autorisation qu'un relayeur soumettra plus tard. L'absence de demande de gas ne signifie pas l'absence de risque.
Avant de signer, identifiez le type de requête, l'action lisible, le domaine ou vérificateur prévu, la chaîne, le contrat vérificateur, les adresses, montants, nonce et échéance. Refusez tout hachage inexpliqué, octets illisibles, champs inattendus ou affichage insuffisant.
## Fonctionnement
1. L'application code une transaction, un message simple ou des données typées. Une modification minime produit un condensat différent.
2. Le portefeuille affiche ce qu'il peut décoder et demande l'accord. La clé privée reste dans le portefeuille ou l'appareil ; seule la signature du condensat est renvoyée.
3. Le vérificateur reconstruit le même condensat. Pour un compte externe, il récupère ou contrôle généralement l'adresse ; un compte contrat peut appliquer sa politique actuelle via ERC-1271.
4. Le vérificateur interprète le résultat selon les règles applicatives. Un serveur peut créer une session ; un contrat peut consommer un permit, exécuter un ordre, modifier la gouvernance ou réaliser un autre appel autorisé.
5. La protection contre le rejeu est propre à l'application. EIP-712 fournit codage typé et séparation de domaine, mais pas cette protection ; l'application doit imposer nonce, deadline, vérificateur prévu, chaîne ou autre limite à usage unique.
ERC-191 sépare les données signées du codage ordinaire des transactions Ethereum et définit des formats comme `personal_sign`. EIP-712 lie les champs structurés à un domaine pouvant inclure `name`, `version`, `chainId` et `verifyingContract`. Les messages ERC-4361 ajoutent domaine, URI, ID de chaîne, nonce et heure d'émission, mais le service doit aussi les valider.
## Exemple
Leah reçoit du service officiel une connexion ERC-4361 avec le domaine et l'URI attendus, un nonce neuf et une courte validité. Elle ne demande que l'authentification. Après vérification, Leah signe ; le serveur valide et crée une session. Ce message ne crée à lui seul ni allowance de jeton ni transaction on-chain.
Sur un faux site, le bouton dit toujours « Se connecter », mais le portefeuille affiche des données EIP-712 `Permit` avec jeton, spender, montant, nonce et deadline. La signature peut permettre à un relayeur de créer un pouvoir de dépense selon le contrat. Leah doit refuser : le texte du bouton ne modifie pas les octets signés.
## Risques et contrôles
- **Sens trompeur :** une page peut appeler connexion un permit ou un ordre. Fiez-vous à la charge décodée et au contrat vérifié, pas au bouton.
- **Signature aveugle :** hachages bruts et octets opaques empêchent un examen éclairé. Annulez si le message exact et son exécution ne sont pas reproductibles avec un outil fiable.
- **Mauvais domaine :** une marque connue n'authentifie pas `chainId`, `verifyingContract`, domaine web ou URI. Vérifiez chaque champ et l'adresse complète séparément.
- **Rejeu ou exécution tardive :** le détenteur d'une signature valide peut l'utiliser avant consommation du nonce ou expiration du deadline. Utilisez des nonces neufs, des délais courts et ne publiez jamais la signature.
- **Pouvoir étendu :** permits, ordres, clés de session et opérations de compte intelligent peuvent autoriser des actions futures sans nouvelle alerte. Vérifiez actif, spender, destinataire, montant, portée et annulation.
- **Signataire compromis :** un portefeuille matériel protège contre l'extraction de clé, pas contre un message malveillant. Si phrase de récupération ou clé privée a fuité, considérez tout le compte compromis.
Après une signature suspecte, conservez charge décodée et signature sans les publier, déconnectez le site et identifiez le schéma. Pour une approbation ou transaction on-chain, vérifiez l'état sur la bonne chaîne et utilisez révocation, invalidation du nonce ou migration documentée. Il n'existe pas de révocation universelle des signatures hors chaîne ; déconnecter le site ne les invalide pas.
## Idées reçues
- **« Toute signature déplace des fonds. »** Beaucoup ne font qu'authentifier ou exprimer une intention ; certaines autorisent un déplacement ultérieur.
- **« Sans gas, aucun danger. »** Un relayeur peut payer le gas et soumettre un permit, ordre ou autre autorisation signée.
- **« EIP-712 garantit la sécurité. »** Il améliore l'affichage et la séparation du domaine, mais n'empêche pas le rejeu et ne vérifie pas les affirmations de l'application.
- **« L'adresse récupérée prouve un consentement éclairé. »** Elle relie données exactes et clé selon une règle, sans prouver identité, compréhension ou liberté.
- **« Les signatures des portefeuilles contrats sont ordinaires. »** La validité ERC-1271 peut dépendre de l'état et de la politique actuels ; le vérificateur doit interroger le contrat.
## Sujets liés
- [Signature typée EIP-712](/fr/crypto/eip712-typed-signature/)
- [Approbation de portefeuille](/fr/crypto/wallet-approval/)
- [Risque de signature Permit2](/fr/crypto/permit2-signature-risk/)
- [Simulation de transaction](/fr/crypto/transaction-simulation/)
- [Hameçonnage](/fr/crypto/phishing-scam/)
## Sources
- [ERC-191: Signed Data Standard](https://eips.ethereum.org/EIPS/eip-191) - Ethereum Improvement Proposals (consulté le : 2026-08-22)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (consulté le : 2026-08-22)
- [ERC-1271: Standard Signature Validation Method for Contracts](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals (consulté le : 2026-08-22)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (consulté le : 2026-08-22)
- [ERC-4361: Sign-In with Ethereum](https://eips.ethereum.org/EIPS/eip-4361) - Ethereum Improvement Proposals (consulté le : 2026-08-22)
Source: https://wiki.fcontext.com/fr/crypto/wallet-signature/index.mdx