---
title: "Pause d’urgence d’un protocole DeFi"
description: "Une pause d’urgence peut arrêter certaines actions de contrats intelligents pendant l’examen d’un incident. Découvrez comment vérifier sa portée, son autorité, les preuves on-chain, les voies de sortie et les conditions de reprise."
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.
# Pause d’urgence d’un protocole DeFi
> À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.
## Réponse directe
Une pause d’urgence est un contrôle de contrat intelligent qui bloque certaines actions pendant que les opérateurs examinent ou contiennent un incident. À elle seule, elle ne prouve pas une perte de fonds, ne les rend pas récupérables et n’arrête pas toute fonction. Le code déployé détermine si dépôts, retraits, emprunts, remboursements, liquidations, swaps, transferts, frappe ou mises à niveau sont touchés.
L’utilitaire `Pausable` d’OpenZeppelin fournit un état de pause, les modificateurs `whenNotPaused` et `whenPaused`, ainsi que les événements `Paused(account)` et `Unpaused(account)`. Le protocole doit encore relier ces contrôles aux fonctions concernées et protéger ses propres points de pause et de reprise. D’autres protocoles utilisent plusieurs indicateurs, des gels par marché, des plafonds ou une machine à états.
Considérez la pause comme outil de réponse et pouvoir privilégié. Vérifiez contrat et réseau exacts, état actuel, transaction déclenchante, appelant, détenteurs de rôles, fonctions disponibles, comptabilité pendant la pause et conditions de reprise. Un bouton désactivé sur un site n’est pas une preuve on-chain faisant autorité.
## Fonctionnement
1. **Un déclencheur est détecté.** Surveillance, contributeurs, auditeurs ou utilisateurs peuvent repérer défaut de code, panne d’oracle, variation anormale de solde, attaque de gouvernance ou perturbation de marché.
2. **Un compte autorisé envoie une transaction.** Il peut s’agir du propriétaire, gardien, multisig, rôle d’accès, exécuteur de gouvernance ou autre contrat. Les étiquettes ne sont pas des autorisations : inspectez le chemin d’autorisation déployé et tout administrateur de proxy.
3. **Le contrat change d’état.** Un commutateur global bloque toutes les fonctions protégées ; des contrôles fins peuvent arrêter un seul marché ou une seule action. Les fonctions sans contrôle pertinent continuent.
4. **État et événements apportent des preuves.** Lisez variable ou getter de pause, entrée et reçu de transaction, événements émis, heure du bloc et appelant. Les événements reconstituent l’historique, mais le stockage actuel détermine l’état présent.
5. **La comptabilité peut continuer.** Indices d’intérêt, financement, récompenses, mises à jour d’oracle, files de retrait ou délais de liquidation peuvent continuer, geler ou rattraper ensuite. Il n’existe pas de comportement universel.
6. **Réponse et correction se poursuivent.** Les opérateurs peuvent enquêter, communiquer, révoquer des rôles, changer des paramètres, mettre à niveau le code, combler un déficit ou offrir un retrait d’urgence. Chaque action exige sa propre autorité et vérification.
7. **La reprise est une autre action privilégiée.** Confirmez qui peut reprendre, si timelock ou vote s’applique, quels code et configuration ont changé, quels tests ou audits couvrent le changement et si anciennes approbations ou contrats restent risqués.
Utilisez un explorateur de blocs et le code source ou bytecode vérifié pour établir une matrice : action, adresse du contrat, condition de pause, disponibilité actuelle, appelant autorisé et effet sur soldes ou dette. Recoupez les annonces via domaine habituel, forum de gouvernance et comptes officiels ; ne vous fiez pas aux réponses ou publicités apparues pendant l’incident.
## Exemple
Supposons qu’un protocole de prêt détecte que son oracle de garantie s’écarte de `30%` du marché de référence. Un gardien arrête nouveaux emprunts et liquidations, mais maintient remboursements et dépôts de garantie. Cela limite l’exposition et évite les liquidations au prix contesté, sans montrer que retraits, intérêts ou tous les autres marchés sont arrêtés.
L’utilisateur doit vérifier transaction du gardien, adresse du marché, indicateurs de pause, état de l’oracle, réserves, indice de dette et avis officiel. Si l’interface affiche seulement « Protocole en pause », ce message ne révèle pas toute la matrice des fonctions.
Si la gouvernance installe ensuite un nouvel oracle et rouvre le marché, vérifiez changements d’implémentation et de paramètres, portée de l’audit, appelant de reprise et état ultérieur. La réouverture ne prouve pas le retour de la liquidité, solvabilité ou profondeur normale.
## Risques
- **Autorité trop large.** Une clé de pause peut aussi mettre à niveau le code, changer l’oracle, frapper des actifs, déplacer des réserves ou accorder des rôles. Énumérez chaque permission ; ne supposez pas qu’un gardien peut seulement arrêter.
- **Signataires compromis ou indisponibles.** Une clé volée peut arrêter le service ; des signataires multisig absents ou corrélés opérationnellement peuvent empêcher une pause ou reprise rapide.
- **Contournements cachés.** Administrateur de proxy, module, entrée alternative, exécuteur inter-chaînes ou fonction non protégée peut contourner le contrôle annoncé.
- **Sorties bloquées et obligations actives.** Les retraits peuvent cesser tandis qu’intérêts, financement, rang dans la file ou autres obligations changent. Lisez les règles comptables avant d’agir.
- **Reprise dangereuse.** Elle peut survenir avant vérification complète de la cause, identité du déploiement, configuration de l’oracle, réserves et intégrations dépendantes.
- **Hameçonnage pendant les incidents.** De fausses pages de « récupération » ou « migration » peuvent demander phrase de récupération, clé privée, signature ou approbation illimitée. Ne divulguez jamais les secrets du portefeuille et vérifiez séparément chaque adresse et approbation.
- **Fausse confiance.** La pause réduit seulement les chemins réellement protégés. Elle ne prouve pas la solvabilité, n’est ni audit ni assurance et ne garantit pas de récupérer les pertes.
Avant toute nouvelle interaction, archivez transaction et annonce, comparez le code vérifié au proxy et à l’implémentation actifs, contrôlez rôles et timelocks, révoquez les approbations obsolètes si nécessaire et testez les actions essentielles avec un montant que vous pouvez perdre. Les appels directs contournent une interface défaillante, mais aussi ses contrôles de sécurité ; n’improvisez pas sans comprendre calldata et état.
## Idées fausses courantes
- **« En pause signifie que tous les actifs ont disparu. »** La pause peut être préventive ; confirmez soldes, obligations, réserves et fonctions touchées.
- **« Une interface désactivée signifie que le contrat est inutilisable. »** Disponibilité du frontend et état du contrat sont distincts. N’effectuez d’appels directs que si vous pouvez vérifier cible, fonction, arguments et conséquences.
- **« Un gardien peut seulement mettre en pause. »** L’étiquette n’a pas d’autorisations standard. Lisez on-chain rôles, propriétaires, modules et pouvoir de mise à niveau.
- **« Le temps s’arrête pendant la pause. »** Comptabilité économique et files peuvent continuer ou reprendre avec des changements accumulés.
- **« Repris signifie corrigé et sûr. »** Rouvrir est une transition ; correction, audits, solvabilité, approbations et liquidité exigent encore une vérification indépendante.
## Sujets connexes
- [Audit de contrat intelligent](/fr/crypto/contract-audit/)
- [Opération de timelock de gouvernance](/fr/crypto/governance-timelock-operation/)
- [Portefeuille multisig](/fr/crypto/multisig-wallet/)
- [Attaque d’oracle](/fr/crypto/oracle-attack/)
- [Contrat évolutif](/fr/crypto/upgradeable-contract/)
## Sources
- [API Pausable](https://docs.openzeppelin.com/contracts/5.x/api/utils#Pausable) - OpenZeppelin Documentation (consulté : 2026-08-21)
- [Contrôle d’accès](https://docs.openzeppelin.com/contracts/5.x/access-control) - OpenZeppelin Documentation (consulté : 2026-08-21)
- [Considérations de sécurité](https://docs.soliditylang.org/en/latest/security-considerations.html) - Solidity Documentation (consulté : 2026-08-21)
- [Sécurité Ethereum et prévention des arnaques](https://ethereum.org/security/) - Ethereum.org (consulté : 2026-08-21)
Source: https://wiki.fcontext.com/fr/crypto/protocol-emergency-pause/index.mdx