---
title: "Gestion des clés privées"
description: "La gestion des clés privées est le cycle de vie permettant de générer, d'utiliser, de sauvegarder, de récupérer, de faire pivoter ou de migrer et de retirer l'autorité de signature sans confondre une clé, une graine, un mnémonique, une phrase secrète, un appareil ou une politique de compte intelligent."
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.

# Gestion des clés privées

> À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

<a id="answer"></a>

## Réponse directe

La gestion des clés privées correspond au cycle de vie complet de l'autorité de signature : génération approuvée, utilisation protégée, sauvegarde, récupération testée, modification autorisée, migration des incidents et retrait. L’objectif est à la fois la confidentialité et la disponibilité. Un secret facile à voler est dangereux, mais un secret que personne ne peut récupérer après la perte de l'appareil est également dangereux.

Gardez les objets distincts. Une cle privee controle une identite cryptographique. Une seed racine HD peut deriver de nombreuses cles. Une phrase de recuperation BIP-39 encode l'entropie et, avec une passphrase facultative, derive une seed ; les memes mots avec une autre passphrase produisent un autre portefeuille. Un code PIN ou un mot de passe de portefeuille peut deverrouiller un appareil local ou un fichier chiffre, mais ne revoque pas la cle sous-jacente. Une adresse ou une cle publique etendue peut reveler des liens entre identites ou transactions sans accorder un pouvoir de depense ordinaire. Un portefeuille materiel est un dispositif de signature, pas l'actif ni la sauvegarde.

Un compte externe ne peut généralement pas remplacer sa clé tout en conservant la même adresse. Après un compromis, les actifs et chaque rôle ou approbation pertinent doivent être transférés à une nouvelle autorité. Un compte intelligent peut prendre en charge les changements de propriétaire ou de tuteur, les seuils et la validation ERC-1271, mais ses modules, gardes, contrôles de mise à niveau et code déployé exact deviennent partie intégrante de la limite de sécurité.

<a id="mechanism"></a>

## Comment ça marche

Partez d'un inventaire, pas d'un nom de produit. Recensez chaque reseau, compte, adresse, actif, autorisation de token, role contractuel, identifiant de validateur ou de retrait, dispositif de signature, origine de cle, norme de derivation et dependance de recuperation. Separez les pouvoirs operationnels courants de ceux lies a l'epargne, a la tresorerie, a l'administration et a la recuperation. La reutilisation d'une seed racine dans de nombreux comptes elargit l'impact d'une compromission meme si les adresses visibles different.

La génération nécessite une implémentation, un environnement et une source d'entropie fiables. N'inventez pas de mnémonique à partir de mots mémorables. Pour un portefeuille HD, conservez le format, la liste de mots, l'exigence de phrase secrète facultative, les chemins de dérivation, les index de compte et les identifiants publics nécessaires pour confirmer la récupération. Une clé publique étendue n'est pas une métadonnée inoffensive : elle peut révéler des relations d'adresse, et certaines constructions de dérivation ont des limites d'exposition supplémentaires.

Les sauvegardes échangent la confidentialité contre la disponibilité. Plusieurs copies complètes améliorent la récupération uniquement si leurs supports et emplacements restent utilisables, mais toute copie volée peut révéler l'intégralité du secret. Une sauvegarde à seuil standardisée telle que SLIP-39 nécessite suffisamment de partages et n'est pas la même chose que couper une phrase BIP-39 en morceaux. La signature multisignature et la signature à seuil distribuent l'autorisation entre les signataires ; ils ne divisent pas une sauvegarde et leur sécurité dépend de personnes, d'appareils, d'emplacements et d'administrateurs indépendants.

La signature quotidienne est un contrôle distinct. Un signataire matériel peut isoler une clé d'un hôte compromis, mais il ne peut pas sécuriser un destinataire, une chaîne, un montant, un domaine ou des données d'appel incorrects. Vérifiez l'intention sur un écran fiable, limitez les soldes chauds et les autorisations et préservez un chemin d'approbation vérifiable. Pour un compte contractuel, vérifiez le seuil de propriétaire actuel, le code de validation du signataire, les modules, les gardes, le comportement de secours, la politique de récupération et l'autorité de mise à niveau.

Utilisez ce flux de travail :

1. Inventoriez chaque chaîne, compte, adresse, actif, approbation, rôle contractuel, origine de clé, chemin de dérivation, signataire, module, dépositaire et dépendance de récupération.
2. Définir les menaces et les besoins de service : compromission à distance, vol, coercition, action interne, incendie ou dégâts des eaux, décès ou incapacité, fréquence de signature, valeur à risque et objectif de temps de récupération.
3. Générer du matériel clé avec une implémentation révisée et une entropie fiable sur un appareil contrôlé ; vérifier de manière indépendante la chaîne, l'adresse et l'empreinte digitale publique sans enregistrer le secret dans un système en ligne.
4. Choisissez des contrôles chauds, isolés du matériel, multisignatures, à seuil, de compte intelligent ou de garde par valeur et utilisation ; placez les sauvegardes, les partages, les phrases secrètes et les signataires dans des domaines de défaillance véritablement indépendants.
5. Effectuez un petit exercice de récupération isolé qui confirme le format exact, la liste de mots, la phrase secrète, le chemin de dérivation, le seuil, les adresses et la capacité de signature sans saisir de secrets de production dans un appareil non fiable.
6. Pour chaque opération, vérifiez la chaîne, le domaine, le destinataire, la valeur, le jeton, les données d'appel et la portée de l'autorité sur un écran fiable ; appliquer les limites, la séparation des tâches et remplir les journaux d'événements ou d'approbation.
7. Réconcilier régulièrement l'inventaire et répéter les pertes, les compromissions, les changements de personnel, les héritages et les sorties de fournisseurs ; récupérer après une perte, mais après une compromission, isoler les appareils propres, migrer les actifs et les rôles, révoquer les approbations, surveiller l'ancienne autorité et la retirer.

<a id="example"></a>

## Exemples

- **Longueur et somme de controle BIP-39.** Avec `ENT = 128 bits`, la longueur de la somme de controle est `CS = ENT / 32 = 4 bits` ; `132 / 11 = 12 words`. Avec `ENT = 256 bits`, on obtient `CS = 8 bits` et `264 / 11 = 24 words`. Un candidat aleatoire de 12 mots a une probabilite pedagogique de satisfaire la somme de controle de `1 / 16 = 6.25%`. La somme courte detecte certaines erreurs de transcription ; elle ne prouve ni authenticite, ni secret, ni metadonnees de derivation correctes.
- **Copies complètes par rapport aux partages de seuil.** Supposons que trois médias indépendants soient chacun disponibles avec une probabilité `0.98` et indépendamment compromis avec une probabilité `0.01`. Trois sauvegardes complètes sont récupérées si l'une d'elles survit : `1 - 0.02^3 = 0.999992`, tandis que la probabilité qu'au moins une fuite soit de `1 - 0.99^3 = 0.029701`. Un seuil `2-of-3` a une disponibilité `3 x 0.98^2 x 0.02 + 0.98^3 = 0.998816` et une probabilité de compromission `3 x 0.01^2 x 0.99 + 0.01^3 = 0.000298`. Les vrais médias et les dépositaires sont corrélés, ce sont donc des hypothèses et non des garanties.
- **Perte et remplacement du signataire.** Un compte intelligent a les propriétaires `A`, `B` et `C` avec un seuil `2-of-3`. La perte d’un propriétaire laisse quand même deux signatures ; compromettre un propriétaire est insuffisant. Si `B` est suspecté d'être compromis, `A + C` autorise le remplacement par `D`. Jusqu'à ce que ce changement soit exécuté selon les règles réelles du compte, `B` reste propriétaire ; ensuite l'ensemble est `A / C / D` avec le seuil `2`.
- **Etendue du risque lie a la reutilisation d'une seed.** La seed racine `S` derive deux comptes detenant `1.2 ETH` et `0.8 ETH` ; une cold seed independante detient `8.0 ETH`. Le solde direct connu expose par la compromission de `S` est `1.2 + 0.8 = 2.0 ETH`. Reutiliser `S` pour le compte froid le porterait a `10.0 ETH`. Tokens, NFT, autorisations, roles et autres reseaux exigent un inventaire separe ; le solde natif visible n'est pas un plafond complet de perte.

<a id="risks"></a>

## Risques

- L'entropie est faible, biaisée ou générée par une source aléatoire cassée.
- Le périphérique de génération, la construction du portefeuille ou la dépendance est malveillant.
- Un signataire matériel, un micrologiciel ou une chaîne d'approvisionnement est falsifié.
- Une graine ou une clé atteint une capture d'écran, un presse-papiers, une imprimante, un cloud ou une note en ligne.
- Le phishing ou le faux support permet d'obtenir du matériel de récupération ou une signature.
- L'hébergeur substitue la chaîne, le destinataire, le montant, le domaine ou les données d'appel.
- Une phrase secrète est oubliée ou mal saisie dans un autre portefeuille valide.
- Une seule sauvegarde est perdue en raison d'un vol, d'un incendie, de l'eau ou de la dégradation des supports.
- Les sauvegardes complètes en double agrandissent la surface de vol.
- La liste de mots, le format, le chemin de dérivation, le type de pièce ou l'index du compte sont erronés.
- Une clé publique étendue ou des métadonnées de dérivation divulguent la confidentialité financière.
- La récupération n'a jamais été testée et a échoué lors de l'incident.
- Les signataires multisignatures partagent un appareil, un emplacement, un cloud ou un administrateur.
- Un seuil est trop élevé pour la disponibilité ou trop bas pour la résistance aux compromissions.
- Les tuteurs s'entendent, deviennent obsolètes ou sont socialement manipulés.
- Un module de compte intelligent, un garde, un gestionnaire de secours, un proxy ou une politique de contournement de mise à niveau.
- Les dossiers de départ, de décès, d'incapacité ou de succession du personnel ne sont pas mis à jour.
- Après compromission, l'ancienne clé est réutilisée ou la modification d'un code PIN est confondue avec une rotation.
- Un dépositaire, un HSM, un MPC ou un fournisseur de récupération se bloque, échoue, s'entend ou se retire.
- La migration manque une autre chaîne, un jeton, un NFT, une approbation, un rôle ou un identifiant de validateur spécialisé.

<a id="misconceptions"></a>

## Idées fausses courantes

- **Un portefeuille matériel sécurise chaque transaction.** L'isolation est utile, mais les risques liés aux intentions malveillantes, à l'affichage, au micrologiciel, à la chaîne d'approvisionnement et à la récupération demeurent.
- **Une phrase de départ et la clé privée d'un compte sont le même objet.** Une graine peut dériver plusieurs clés, tandis que les formats et les phrases secrètes déterminent la récupération.
- **Des sauvegardes plus complètes ne font qu'améliorer la sécurité.** Elles améliorent la disponibilité tout en augmentant le nombre de copies qu'un attaquant peut voler.
- **La multisignature n'est qu'une graine divisée en morceaux.** Les signataires indépendants, les signatures à seuil et les sauvegardes de partage de secrets sont des mécanismes différents.
- **La modification du mot de passe ou du code PIN d'un portefeuille révoque une clé EOA divulguée.** L'ancienne clé contrôle toujours son adresse ; migrez les actifs et les autorités et gérez les approbations de manière explicite.

<a id="related"></a>

## Sujets connexes

- [Portefeuille matériel](/fr/crypto/hardware-wallet/)
- [Clés publiques et privées](/fr/crypto/public-private-key/)
- [Phrase de départ](/fr/crypto/seed-phrase/)

<a id="sources"></a>

## Sources faisant autorite

- [Recommandation pour la gestion des clés : Partie 1 - Général](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final) - National Institute of Standards and Technology (consulté : 13 août 2026)
- [Recommandation pour les sources d'entropie utilisées pour la génération de bits aléatoires](https://csrc.nist.gov/pubs/sp/800/90/b/final) - National Institute of Standards and Technology (consulté : 13 août 2026)
- [Code mnémonique pour générer des clés déterministes](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) - Propositions d'amélioration Bitcoin (consulté : 13 août 2026)
- [Portefeuilles déterministes hiérarchiques](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) - Propositions d'amélioration du Bitcoin (consulté : 13 août 2026)
- [SLIP-0039 : Partage de secrets de Shamir pour les codes mnémoniques](https://github.com/satoshilabs/slips/blob/master/slip-0039.md) - Propositions d'amélioration de SatoshiLabs (consulté : 13 août 2026)
- [Sécurité Ethereum et prévention des arnaques](https://ethereum.org/en/security/) - ethereum.org (consulté : 13 août 2026)
- [Concepts de compte intelligent](https://docs.safe.global/advanced/smart-account-concepts) - Safe Docs (consulté : 13 août 2026)
- [ERC-1271 : Méthode standard de validation des signatures pour les contrats](https://eips.ethereum.org/EIPS/eip-1271) - Propositions d'amélioration d'Ethereum (consulté : 13 août 2026)

Source: https://wiki.fcontext.com/fr/crypto/private-key-management/index.mdx