---
title: "Comment surveiller les mises à niveau des contrats proxy"
description: "Surveillez les changements d'implémentation, de beacon et de contrôle des proxys évolutifs, puis vérifiez le code, la compatibilité du stockage, l'initialisation, les droits et les comportements critiques."
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.
# Comment surveiller les mises à niveau des contrats proxy
> À but éducatif uniquement ; ne constitue pas un conseil en investissement. Tout investissement peut entraîner des pertes.
## Réponse directe
Surveillez le chemin de contrôle d'un système évolutif en plus de son adresse proxy. Une alerte doit identifier qui peut autoriser et exécuter une mise à niveau, tout délai obligatoire, l'ancienne et la nouvelle implémentation, ainsi que les calldata d'initialisation. Après l'exécution, relisez indépendamment la configuration on-chain et testez les comportements critiques.
L'adresse du proxy et ses soldes peuvent rester inchangés tandis que le code délégué modifie les droits, les frais, la comptabilité, la mise en pause ou la logique de retrait. Un audit antérieur ne couvre pas automatiquement une nouvelle implémentation ni son initialisation.
## Fonctionnement
Identifiez d'abord le modèle de proxy. ERC-1967 définit des emplacements de stockage séparés pour `eip1967.proxy.implementation`, `eip1967.proxy.beacon` et l'emplacement facultatif `eip1967.proxy.admin`. Les changements directs d'implémentation devraient émettre `Upgraded`, les changements d'adresse du beacon `BeaconUpgraded` et ceux de l'emplacement administrateur `AdminChanged`. Pour un proxy beacon, appelez aussi `implementation()` sur le beacon, car celui-ci peut changer d'implémentation sans modifier l'emplacement beacon du proxy.
Ne déduisez pas le modèle complet d'autorité de l'emplacement administrateur. Un proxy Transparent peut être contrôlé par un `ProxyAdmin`, tandis que l'autorisation des mises à niveau UUPS est implémentée dans le contrat logique courant via `_authorizeUpgrade`. Retracez propriétaires, rôles, seuils multisig, timelocks, gouverneurs, chemins d'urgence et capacité à modifier ces contrôles.
Utilisez à la fois des abonnements aux événements et des lectures périodiques de l'état. ERC-1967 recommande les événements sans obliger toutes les implémentations à les émettre. Enregistrez chaîne, bloc, transaction, proxy, implémentation ou beacon, empreinte du code d'exécution, exécutant et état de contrôle pertinent à partir de points d'accès RPC indépendants. Alertez sur les opérations programmées, annulées et exécutées, puis attendez la politique de confirmation ou de finalité choisie pour la chaîne avant de considérer l'état comme définitif.
## Exemple
Un proxy de prêt est contrôlé par un multisig 3 sur 5 via un timelock de 24 heures. Lorsqu'une mise à niveau est programmée, le moniteur enregistre l'identifiant de la proposition, la cible, les calldata, l'heure d'exécution la plus proche, l'implémentation actuelle, celle proposée et l'état de vérification du code source. Les réviseurs comparent le code et les dispositions de stockage, examinent l'appel d'initialisation et vérifient les changements de rôles, appels externes, frais, règles de pause et chemins de retrait.
Après l'exécution, le moniteur relit l'emplacement ERC-1967 concerné, vérifie le code d'exécution déployé et contrôle les postconditions attendues, comme la version de l'implémentation, les administrateurs ou titulaires de rôles, l'état de pause, la comptabilité des actifs et un aperçu de retrait en lecture seule. Une nouvelle alerte se déclenche si l'adresse ou l'empreinte observée diffère de la proposition examinée, ou si l'interrogation périodique détecte un changement non signalé par un événement.
## Risques
- **Risque de contrôle :** Un multisig nominal peut être contourné par un autre propriétaire, rôle, module, gouverneur, une clé d'urgence ou un timelock modifiable. Suivez chaque chemin jusqu'aux signataires finaux et au délai.
- **Risque lié au code et au stockage :** Du code non vérifié, des dispositions incompatibles, une initialisation dangereuse ou une dépendance modifiée peuvent corrompre l'état ou accorder des droits non prévus. Validez l'artefact exactement déployé, pas seulement une branche du dépôt ou le nom d'un audit.
- **Risque de surveillance :** Un RPC unique, un indexeur limité aux événements, une interface ou un explorateur de blocs peuvent être retardés ou erronés. Rapprochez événements, stockage, bytecode, reçus de transaction et état du protocole entre sources indépendantes.
- **Risque de réponse :** Une alerte sans responsable ni procédure testée peut arriver trop tard. Définissez qui examine, suspend les intégrations, communique ou sort pendant le délai, tout en reconnaissant le risque supplémentaire des approbations précipitées et liens de récupération non officiels.
Procédure minimale :
1. Inventoriez chaque proxy, beacon, implémentation, administrateur, rôle et point d'entrée de mise à niveau sur chaque chaîne.
2. Conservez une référence valide des emplacements, empreintes de code, états de contrôle et résultats critiques en lecture seule.
3. Alertez avant l'exécution lorsque la programmation par gouvernance ou timelock le permet, puis à nouveau lors de l'exécution ou de l'annulation.
4. Comparez la cible, les calldata, l'implémentation, le bytecode, la disposition de stockage et l'état après mise à niveau effectivement exécutés avec la proposition examinée.
5. Faites remonter les changements inattendus, postconditions échouées, sources non vérifiées ou délais raccourcis ou contournés ; ne considérez pas l'adresse proxy inchangée comme une preuve de sécurité.
## Idées reçues
- **Mythe 1 : « Surveiller `Upgraded` suffit. »** Les changements d'implémentation du beacon et les proxys non standard peuvent exiger de surveiller un autre contrat ou d'interroger l'état ; rapprochez les événements des lectures directes.
- **Mythe 2 : « L'emplacement administrateur révèle qui contrôle chaque mise à niveau. »** Cet emplacement est facultatif, et les modèles Transparent, UUPS, beacon, gouvernance et personnalisés placent l'autorité dans différents contrats et fonctions.
- **Mythe 3 : « Un code source vérifié ou un audit passé prouve la sécurité de la mise à niveau. »** Vérifiez le bytecode déployé, les hypothèses de compilateur et de constructeur, la compatibilité du stockage, l'initialisation, la configuration et le comportement de la version exacte.
## Thèmes connexes
- [Risque des modules multisig](/fr/crypto/multisig-module-risk/)
- [Contrat proxy](/fr/crypto/proxy-contract/)
- [Collision du stockage du proxy](/fr/crypto/proxy-storage-collision/)
- [Pause d'urgence du protocole](/fr/crypto/protocol-emergency-pause/)
- [Contrat évolutif](/fr/crypto/upgradeable-contract/)
## Sources
- [ERC-1967 : emplacements de stockage des proxys](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (consulté le 2026-08-21)
- [Proxy](https://docs.openzeppelin.com/contracts/5.x/api/proxy) - OpenZeppelin (consulté le 2026-08-21)
- [Écrire des contrats évolutifs](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin (consulté le 2026-08-21)
- [Contrôle des accès](https://docs.openzeppelin.com/contracts/5.x/access-control) - OpenZeppelin (consulté le 2026-08-21)
Source: https://wiki.fcontext.com/fr/crypto/proxy-upgrade-monitoring/index.mdx