Contexte : Une table contenant plusieurs milliards de lignes est fréquemment interrogée sans partitionnement. Le Problème : Chaque requête scanne l’intégralité de la table, entraînant des coûts très élevés. Extrait actuel : CREATE TABLE transactions ( id STRING, transaction_date TIMESTAMP, amount FLOAT64 ); Aucune partition ni clustering. Contraintes : Introduire un partitionnement adapté. Ajouter un clustering pertinent. Migrer les données sans perte. Livrable attendu : Proposer une nouvelle définition de table optimisée et une stratégie de migration réduisant drastiquement le volume scanné.