Pour pérenniser vos modules Move sur Sui sans compromettre la compatibilité, vous devez planifier soigneusement les mises à niveau car les modules publiés sont immuables, mais le système de mise à niveau des packages de Sui vous permet de déployer de nouvelles versions qui maintiennent la compatibilité tout en ajoutant ou en modifiant des fonctionnalités. L'une des meilleures stratégies consiste à utiliser un modèle « objet principal », dans lequel un objet central (tel qu'un objet Version ou Config) stocke la version logique actuelle et pointe vers les modules actifs, ce qui vous permet de rediriger les appels vers une logique mise à jour sans modifier les interfaces existantes. Vous pouvez définir cet objet dans votre module initial avec un champ de version et une fonction de mise à niveau, comme public fun update_version (config : &mut Config, new_package : address), en vous assurant qu'il ne peut être appelé que par des parties autorisées (par exemple, à l'aide d'un UpgradeCap). Cela permet de maintenir la stabilité de l'API publique de votre application, afin que les utilisateurs ou les autres contrats ne soient pas rompus lorsque vous publiez un nouveau package avec une logique mise à jour. Une autre approche consiste à concevoir des modules avec des modifications modulaires et additives : conserver les signatures des fonctions publiques et les structures de données inchangées dans les nouvelles versions, ajouter uniquement de nouvelles fonctions ou de nouveaux champs, et utiliser des contrôles de compatibilité (sui upgrade --verify-compatibility) pour détecter les problèmes avant le déploiement. Pour les objets partagés, incluez des balises de version et une logique de migration pour gérer les mises à jour des données de manière fluide, comme le transfert des soldes vers de nouvelles structures. Dans la pratique, le modèle d'objet principal brille pour les applications complexes telles que les protocoles DeFi, comme en témoignent des projets tels que Cetus, où il simplifie les échanges logiques sans perturber les utilisateurs. Faites attention aux risques de sécurité : limitez strictement les autorisations de mise à niveau, idéalement avec un multisig ou un DAO, pour empêcher les modifications malveillantes, et testez les mises à niveau sur le réseau de test de Sui pour simuler les impacts réels. Évitez de trop vous fier aux objets partagés, car ils peuvent compliquer les migrations en raison des exigences de consensus.