Migration BigQuery : méthodologie et retour d'expérience

Vous avez un entrepôt de données qui tourne depuis dix ans sur Oracle, SQL Server ou Teradata. Il fonctionne — plus ou moins. Il est lent sur les requêtes volumineuses, coûteux à maintenir, et votre équipe passe plus de temps à le nourrir qu'à en extraire de la valeur. Vous savez que la migration vers BigQuery est inévitable. Mais vous avez peur de reproduire les erreurs des autres : des projets à 18 mois qui se terminent avec un système legacy déplacé dans le cloud, aussi lourd qu'avant, mais désormais facturé à l'heure.

Ce retour d'expérience est écrit pour vous. Voici ce que la migration BigQuery implique vraiment — phase par phase, avec les pièges, les décisions critiques et les résultats concrets.

Pourquoi le "Lift and Shift" est un piège à éviter

La tentation est forte : exporter les tables, les charger dans BigQuery, rediriger les dashboards. Mission accomplie. En apparence.

En réalité, c'est l'erreur la plus courante que nous observons sur les projets de modernisation data. BigQuery n'est pas un serveur SQL hébergé dans le cloud — c'est un moteur analytique à architecture radicalement différente. Le traiter comme un Oracle en ligne, c'est payer des ressources Google Cloud data pour obtenir les mêmes mauvaises performances qu'on-premise, mais avec une facture mensuelle qui surprend.

La vraie migration BigQuery commence avant d'écrire la première ligne de code. Elle commence par une question honnête : qu'est-ce qui mérite réellement de migrer ?

Phase 1 — L'évaluation : cartographier l'existant sans complaisance

La phase d'évaluation est systématiquement sous-estimée. Sur les projets que nous accompagnons, elle révèle invariablement la même réalité : entre 40 et 60 % des tables du système legacy n'ont pas été interrogées depuis plus d'un an.

Ce sont des actifs fantômes. Ils consomment du budget de migration, du temps de développement et de la complexité inutile. Ils ne doivent pas migrer vers BigQuery — ils doivent être archivés vers Google Cloud Storage Coldline, voire supprimés.

Voici les trois actions concrètes de cette phase :

• Analyser les logs de requêtes : depuis Oracle AWR, Teradata DBQL ou les DMV SQL Server, identifiez la fréquence d'accès, la date de dernière utilisation et les utilisateurs réels de chaque objet.
• Cartographier les dépendances : quels pipelines en amont alimentent ces tables ? Quels rapports en dépendent ? Un outil de lignage (data lineage) automatise cette validation et évite les mauvaises surprises le jour de la bascule.
• Décider ce qu'on n'emmène pas : c'est une décision stratégique, pas technique. Impliquez les métiers. Chaque table archivée est du temps et de l'argent économisés.

L'évaluation produit un seul livrable essentiel : un inventaire priorisé, classé par criticité métier et fréquence d'usage. C'est la fondation de tout ce qui suit.

Phase 2 — La conception du schéma : penser BigQuery, pas Oracle

C'est là que la plupart des équipes techniques font le plus d'erreurs. Elles copient leur modèle relationnel normalisé tel quel dans BigQuery. Résultat : des jointures massives entre des tables de plusieurs téraoctets, des requêtes qui s'éternisent, et des coûts qui explosent.

BigQuery repose sur un modèle fondamentalement différent : le stockage est bon marché, les jointures coûtent cher. La stratégie optimale est donc la dénormalisation — à rebours des réflexes du DBA SQL Server.

Dénormalisez avec les types natifs

Plutôt que de maintenir une table OrderItems séparée liée par clé étrangère, imbriquez les lignes de commande directement dans la table Orders via les types STRUCT et ARRAY. Ce pattern élimine les jointures coûteuses et multiplie les performances analytiques par un facteur de 5 à 10x sur les requêtes d'agrégation.

Partitionnez par date, systématiquement

Toute table de faits de plus de 10 Go doit être partitionnée par date (transaction_date, event_date). BigQuery ne scannera alors que les partitions pertinentes à votre filtre — ce qui transforme une requête sur un pétaoctet en un scan de quelques téraoctets. La différence de coût est de plusieurs ordres de grandeur.

Clusterisez pour les filtres récurrents

Au sein de chaque partition, clusterisez par les colonnes les plus fréquemment utilisées en filtre ou en GROUP BY (customer_id, region, product_category). Le clustering agit comme un micro-index natif : pas de maintenance, pas de rebuild, et une réduction significative des données scannées.

Phase 3 — La migration ETL/ELT : architecturer pour la résilience

La question du pipeline est souvent traitée comme une décision technique secondaire. Elle est en réalité structurante. Les scripts cron et les ETL maison hérités du système legacy sont fragiles, opaques et impossibles à monitorer à l'échelle du cloud.

Nous recommandons systématiquement une architecture en trois couches :

1. Landing Zone : les données brutes arrivent dans un dataset BigQuery dédié, sans transformation. C'est la zone de quarantaine — un espace de traçabilité totale.
2. Couche Curated (dbt) : dbt (data build tool) orchestre les transformations SQL, les tests de qualité et la documentation. Chaque modèle est idempotent — c'est-à-dire qu'il peut être relancé sans créer de doublons, même en cas d'échec partiel.
3. Couche Consommation : les tables finales, dénormalisées, optimisées pour les outils BI (Looker, Data Studio, Tableau).

Pour les flux temps réel ou les transformations complexes, Dataflow (Apache Beam) reste la référence. Pour les migrations initiales volumineuses depuis Oracle ou Teradata, Cloud Data Fusion offre une interface visuelle qui accélère le développement.

La règle d'or : concevez chaque pipeline pour l'idempotence. Si un job échoue à 3h du matin, votre équipe doit pouvoir le relancer le matin sans risque de corruption. C'est la différence entre un projet qui passe en production sereinement et un projet qui génère des incidents en cascade.

Phase 4 — La gestion des coûts : slots ou on-demand ?

BigQuery propose deux modèles de facturation, et ce choix a un impact significatif sur votre budget à long terme.

• On-demand : vous payez par téraoctet scanné (~5 $ / To). Simple, sans engagement, idéal pour démarrer ou pour les charges imprévisibles.
• Slots réservés (éditions BigQuery) : vous achetez une capacité de calcul dédiée en vCPU. Plus prévisible, plus avantageux à partir d'un certain volume de requêtes.

Notre recommandation : commencez en on-demand, instrumentez vos requêtes via INFORMATION_SCHEMA.JOBS pendant 60 jours, puis analysez votre profil de charge. Si votre coût mensuel dépasse 2 000 $, les slots réservés deviennent généralement plus économiques.

Deux pratiques à mettre en place dès le premier jour :

• Taguer toutes les ressources par projet, équipe et environnement pour une attribution précise des coûts.
• Activer les alertes budgétaires à 50 %, 80 % et 100 % du budget mensuel prévu.

La bascule : la stratégie de double exécution

Ne basculez jamais d'un coup. La confiance des équipes métier est votre actif le plus précieux — et la moindre divergence de chiffres entre l'ancien système et BigQuery peut la détruire en quelques heures.

Appliquez le pattern de double exécution pendant 2 à 4 semaines :

1. Les deux systèmes ingèrent les mêmes données quotidiennement.
2. Un script de reconciliation compare automatiquement les agrégats clés (revenus, volumes de transactions, KPI critiques).
3. La bascule définitive n'est prononcée que lorsque l'écart est de 0,0 % pendant 14 jours consécutifs.

Cette rigueur semble excessive — jusqu'au jour où elle vous évite un incident de production qui coûte bien plus cher que les 4 semaines de validation.

Ce que l'expérience enseigne vraiment

Après plusieurs migrations menées depuis des environnements Oracle, SQL Server et Teradata, voici les enseignements qui comptent :

• Le risque technique est rarement le principal obstacle. C'est l'alignement des équipes métier, la gouvernance des données et la gestion du changement qui déterminent le succès.
• La phase d'évaluation est toujours trop courte. Doublez systématiquement le temps alloué — vous l'économiserez en évitant les régressions en phase 3.
• BigQuery ML change la nature du projet. Une fois la migration stabilisée, la possibilité d'exécuter des modèles de machine learning directement en SQL transforme l'entrepôt de données en plateforme d'intelligence. C'est là que la valeur réelle commence.
• Le coût de ne pas migrer augmente chaque année. Chaque mois passé à maintenir un legacy on-premise est un écart compétitif qui s'élargit.

Prêt à transformer votre capital data ?

Une migration BigQuery réussie n'est pas qu'un projet technique — c'est une décision stratégique qui redéfinit la capacité d'innovation de votre organisation. Elle exige une méthodologie rigoureuse, une expertise des architectures cloud natives, et une gestion fine de la transition humaine et organisationnelle.

Chez Avenia Consulting, nous accompagnons les entreprises dans leurs migrations de data warehouse cloud à fort enjeu — de la phase d'évaluation jusqu'à la mise en production et l'optimisation continue. Explorez nos services Cloud Engineering ou contactez-nous pour un premier diagnostic de votre environnement legacy. Construisons ensemble une plateforme data qui crée de la valeur, pas seulement qui stocke des données.