Contexte : Une table Cassandra stocke l’historique complet des transactions financières par client. Le Problème : Certains clients génèrent des millions d’enregistrements, créant des partitions extrêmement volumineuses qui dégradent les performances. Extrait actuel : PRIMARY KEY (client_id, transaction_time) Toutes les transactions d’un client sont dans la même partition. Contraintes : Réduire la taille des partitions sans perdre la capacité de requêter efficacement par client et par date. Minimiser les migrations massives de données. Livrable attendu : Proposer une stratégie avancée de partitionnement (bucketing temporel ou hashing) permettant d’éviter les partitions surdimensionnées.