--- title: "Contrat proxy" description: "Un contrat proxy transmet les appels au code d'implémentation tout en conservant l'adresse et l'état du proxy. Découvrez son fonctionnement et les risques liés aux mises à niveau, au stockage et à l'administration." 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. # Contrat proxy > À des fins éducatives uniquement ; ceci ne constitue pas un conseil en investissement. Tout investissement peut entraîner des pertes. ## Réponse directe Un contrat proxy est un contrat intermédiaire qui transmet les appels à un autre contrat, généralement appelé contrat d'implémentation ou contrat logique. Dans une architecture EVM courante, le proxy utilise `delegatecall` : le code de l'implémentation s'exécute alors dans le contexte du proxy, tandis que l'état et les soldes restent à l'adresse du proxy. Cette couche d'indirection permet à un système de conserver une adresse stable pour les utilisateurs tout en changeant d'implémentation. Elle peut aussi réduire le coût de déploiement lorsque de nombreux proxys partagent le même code. Un proxy n'est pas automatiquement évolutif : certains proxys minimaux pointent définitivement vers une implémentation, tandis que les proxys évolutifs ajoutent un moyen contrôlé de changer l'implémentation ou le beacon. Les utilisateurs doivent donc évaluer à la fois l'implémentation active et l'autorité capable de la modifier. Le seul bytecode vérifié du proxy ne permet pas de déterminer quel code sera exécuté demain. ## Fonctionnement Lorsqu'un appel atteint le proxy, son chemin de repli copie ou transmet les données d'appel à une implémentation. Avec `delegatecall`, `address(this)` désigne le proxy, les lectures et écritures de stockage touchent le proxy, et les valeurs d'origine de `msg.sender` et `msg.value` sont conservées. Le proxy renvoie ensuite les données retournées par l'implémentation ou annule l'appel avec elle. Comme les métadonnées du proxy partagent son espace de stockage avec l'état de l'application, des emplacements normalisés aident à éviter les collisions accidentelles. ERC-1967 définit des emplacements pour une adresse d'implémentation, une adresse de beacon et un administrateur facultatif, et recommande d'émettre des événements lorsque ces valeurs changent. Cette norme facilite l'inspection des proxys, mais ne suffit pas à sécuriser une mise à niveau. Les architectures courantes placent l'autorité de mise à niveau à différents endroits : - **Proxy transparent :** le proxy distingue les appels administratifs des appels ordinaires des utilisateurs, généralement au moyen d'un contrat d'administration séparé. - **Proxy UUPS :** la logique de mise à niveau réside dans l'implémentation, qui doit autoriser les changements et rester compatible avec l'interface prévue. - **Proxy beacon :** le proxy demande son implémentation à un beacon ; modifier un beacon peut affecter tous les proxys qui le suivent. - **Clone minimal :** de nombreux petits proxys délèguent au même code, souvent sans aucune possibilité de mise à niveau. ## Exemple Supposons qu'un proxy de coffre détienne les soldes des utilisateurs et délègue à l'implémentation A. Les utilisateurs déposent à l'adresse du proxy, et le code de A met à jour les soldes dans le stockage du proxy. La gouvernance remplace ensuite l'implémentation dans l'emplacement ERC-1967 par l'implémentation B. L'adresse du proxy et les soldes enregistrés ne bougent pas, mais les appels futurs exécutent le code de B. Si B conserve l'organisation du stockage et applique les règles prévues, les utilisateurs bénéficient d'un nouveau comportement à la même adresse. Si B réorganise les variables de stockage, omet un contrôle d'autorisation ou ajoute un chemin de retrait contrôlé par l'autorité de mise à niveau, la même opération peut corrompre la comptabilité ou exposer les actifs. La question opérationnelle n'est donc pas seulement de savoir si le contrat est un proxy, mais qui peut modifier son chemin d'exécution, avec quel délai et quelles vérifications. ## Risques - **Compromission de la clé de mise à niveau :** un administrateur, un multisig ou un processus de gouvernance peut installer du code malveillant ou défectueux. - **Incompatibilité de l'organisation du stockage :** modifier l'ordre, le type ou l'héritage des variables peut amener le nouveau code à mal lire ou écraser l'état existant. - **Échec de l'initialisation :** les constructeurs n'initialisent pas le stockage du proxy ; une protection absente ou réutilisable peut permettre à un autre compte d'obtenir des rôles privilégiés. - **Routage inattendu des appels :** des collisions de sélecteurs, un routage réservé à l'administrateur ou un beacon inattendu peuvent rendre le chemin exécuté différent de l'interface visible. - **Large portée d'une mise à niveau partagée :** une décision concernant un beacon ou une implémentation peut modifier simultanément de nombreuses instances de contrats. Avant de déposer des actifs ou d'accorder des autorisations, il faut identifier sur la chaîne l'implémentation ou le beacon actuel, l'autorité de mise à niveau et tout timelock, examiner le code source vérifié et la compatibilité du stockage, puis consulter, le cas échéant, les événements récents `Upgraded`, `BeaconUpgraded` et `AdminChanged`. La surveillance reste nécessaire après la première analyse, car le chemin d'exécution peut changer. ## Idées reçues - **« Le proxy ne stocke aucun état significatif. »** Avec `delegatecall`, l'état de l'application et souvent les actifs appartiennent au proxy, même si la logique provient d'une autre adresse. - **« Une implémentation vérifiée rend le système sans confiance. »** Les clés de mise à niveau, la gouvernance, les beacons, l'initialisation et les futures implémentations restent dans le modèle de confiance. - **« Tous les proxys peuvent être mis à niveau. »** Les clones et autres proxys fixes peuvent déléguer définitivement ; la capacité de mise à niveau dépend de l'architecture précise et du code d'autorisation. ## Sujets connexes - [Risque de stockage avec Delegatecall](/fr/crypto/delegatecall-storage-risk/) - [Collision de stockage du proxy](/fr/crypto/proxy-storage-collision/) - [Surveillance des mises à niveau du proxy](/fr/crypto/proxy-upgrade-monitoring/) - [Smart contract](/fr/crypto/smart-contract/) - [Contrat évolutif](/fr/crypto/upgradeable-contract/) ## Sources - [Introduction aux smart contracts](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html) - Solidity Documentation (consulté le 2026-08-21) - [ERC-1967 : emplacements de stockage des proxys](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (consulté le 2026-08-21) - [ERC-1822 : norme universelle de proxy évolutif (UUPS)](https://eips.ethereum.org/EIPS/eip-1822) - Ethereum Improvement Proposals (consulté le 2026-08-21) - [Proxy](https://docs.openzeppelin.com/contracts/5.x/api/proxy) - OpenZeppelin Documentation (consulté le 2026-08-21) Source: https://wiki.fcontext.com/fr/crypto/proxy-contract/index.mdx