Snowflake se justifie dans une cible décisionnelle lorsque le socle à remplacer doit absorber des volumes variables, servir plusieurs usages SQL et dissocier la capacité de calcul de la conservation des données. Il ne justifie pas, à lui seul, la reprise d’un parc de rapports peu utilisé ou mal gouverné.
En bref
- Snowflake est pertinent si votre data warehouse doit soutenir des charges de requêtes irrégulières sans imposer un dimensionnement permanent du calcul.
- La séparation du stockage et des entrepôts virtuels répond à un besoin précis de performance, mais elle ajoute une surveillance nécessaire de la consommation.
- Une migration depuis BusinessObjects, SAP BW, OBIEE ou PowerCenter doit commencer par les usages réellement consultés, pas par le choix de la plateforme cible.
- Le coût dépend des crédits consommés, du stockage, des éditions souscrites et des règles d’arrêt des entrepôts virtuels. Aucun budget sérieux ne peut se limiter à une estimation annuelle globale.
- La recette doit accepter des écarts expliqués entre l’ancien socle et la nouvelle cible décisionnelle, avec des seuils validés avant la bascule.
Ce contenu s’adresse aux responsables BI qui préparent la sortie d’un socle décisionnel existant et évaluent Snowflake comme plateforme de stockage et de traitement. Il ne traite ni la négociation contractuelle, ni la protection des données personnelles, ni l’architecture cloud computing au-delà de ses effets sur les flux décisionnels.
Dans quels cas Snowflake devient-il une cible décisionnelle défendable ?
Snowflake n’est pas une cible décisionnelle à retenir parce qu’un programme de modernisation l’a inscrit sur une feuille de route. La décision se défend lorsque les limites du socle actuel sont identifiées dans les flux, les temps de réponse et la capacité à faire évoluer les usages. Un entrepôt relationnel correctement tenu, alimentant cinquante rapports stables, ne devient pas inadapté parce qu’une solution cloud existe.
Le premier critère est la variabilité réelle de la charge. Un parc de tableaux de bord qui concentre ses requêtes entre 8 h 30 et 10 h, lors des clôtures ou au lancement des campagnes commerciales, crée une contrainte différente d’un reporting mensuel figé. Snowflake propose des entrepôts virtuels qui exécutent les requêtes séparément de la couche de stockage. La documentation de l’éditeur décrit cette séparation entre stockage, calcul et services cloud dans son architecture, consultée le 12 juin 2026 sur la documentation Snowflake consacrée aux concepts fondamentaux.
Cette séparation ne garantit pas une performance constante. Elle permet surtout de ne pas lier mécaniquement la taille du stockage à la puissance de calcul réservée. Dans un environnement décisionnel, cette distinction prend du sens lorsqu’un flux de chargement nocturne, une extraction réglementaire et les requêtes des utilisateurs finaux se concurrencent aujourd’hui sur la même base ou le même serveur.
Le deuxième critère concerne la diversité des sources. Une cible Snowflake peut accueillir des données relationnelles, des fichiers et certains formats semi-structurés, puis les mettre à disposition de modèles sémantiques et d’outils de restitution. Cela ne dispense pas d’établir un modèle de données. Charger les tables d’un ancien data warehouse telles quelles ne recrée ni les règles portées par les univers BusinessObjects, ni les jointures masquées dans les rapports OBIEE.
Le besoin à démontrer avant de choisir la plateforme
Un dossier d’arbitrage doit partir des contraintes observables. Il faut relever le nombre de sources, la fréquence des chargements, les périodes de saturation, les temps de réponse des requêtes critiques et le nombre de jeux de données réellement distribués. Sans cet inventaire, Snowflake devient une réponse technique à un problème encore non formulé.
Sur un parc inférieur à cent rapports, dont plus de la moitié n’est plus consultée, la priorité reste l’élagage. Reprendre un entrepôt entier dans Snowflake sans supprimer les extractions inutiles conserve le même bruit fonctionnel, avec une facture de consommation différente. Lorsque le parc dépasse trois cents rapports et que les règles de gestion sont enfouies dans des objets, conditions et contextes de requête, une couche centralisée peut en revanche fournir un point de reprise plus lisible.
Le troisième critère est la coexistence des outils de restitution. Snowflake est un data warehouse, pas un modèle sémantique pour les utilisateurs métier. Power BI, Tableau, Qlik Sense, BusinessObjects Web Intelligence ou un outil de planification pourront interroger les données selon des modalités distinctes. L’intégration est utile si elle réduit le nombre de copies et de flux intermédiaires, non si elle pousse chaque équipe à reconstruire ses propres tables.
La décision devient fragile lorsque l’argument se limite à la scalabilité. Une montée en charge n’est utile que si elle correspond à des requêtes, des flux ou des échéances réellement constatés. La section suivante porte donc sur les objets à reprendre et sur ceux qui doivent rester hors du périmètre.
Quels objets de l’ancien socle faut-il réellement intégrer dans Snowflake ?
La migration vers Snowflake commence par un inventaire fonctionnel, pas par un export de tables. Dans un socle SAP BusinessObjects 4.3, le rapport Web Intelligence ne contient pas toujours toute la règle de calcul visible à l’écran. Une condition peut être définie dans l’objet d’univers, une jointure peut dépendre d’un contexte, et une mesure peut changer selon la granularité demandée. Ces éléments doivent être recensés avant toute intégration.
Le même problème apparaît avec SAP BW 7.5. Un InfoCube, une requête BEx et une variable peuvent répartir une logique de gestion entre plusieurs objets. Un chargement technique vers Snowflake ne restitue pas automatiquement cette logique. La cible doit préciser où chaque règle sera portée, dans une table préparée, une vue, une procédure de chargement, une couche sémantique ou le rapport lui-même.
Un inventaire utilisable croise les objets techniques avec l’usage métier. Il ne suffit pas de compter les rapports publiés. Les logs d’audit sur douze mois, les abonnements actifs, les exécutions planifiées et les entretiens avec les propriétaires fonctionnels permettent de distinguer un rapport actif d’un document conservé par habitude.
| Objet du socle source | Équivalent possible dans Snowflake | Risque lors de la reprise | Vérification attendue avant recette |
|---|---|---|---|
| Table de faits alimentée par ETL | Table chargée puis transformée par flux ELT | Perte d’un filtre appliqué en amont du flux historique | Comparer les volumes par période, statut et entité |
| Univers BusinessObjects 4.3 | Vue ou couche préparée pour le modèle sémantique cible | Jointure, contexte ou condition d’objet non repris | Rejouer les requêtes les plus consultées avec les mêmes paramètres |
| Requête BEx sur BW 7.5 | Vue SQL documentée et modèle de restitution | Variable ou hiérarchie non transposée | Comparer les agrégats aux niveaux de navigation utilisés |
| Rapport Web Intelligence | Rapport reconstruit dans l’outil de restitution retenu | Colonne calculée, rupture ou alerte absente | Contrôler les indicateurs, filtres et mises en forme décisionnelles |
Ce tableau ne décrit pas une correspondance automatique. Il sert à établir la liste des pertes possibles. La source de la distinction entre données stockées, ressources de calcul et services de plateforme est la documentation officielle Snowflake, consultée le 12 juin 2026 sur la page des concepts clés. Les équivalences fonctionnelles doivent, elles, être validées contre votre propre parc.
Évaluer la charge avec des hypothèses explicites
Une estimation de reprise peut être construite sans promettre une durée irréaliste. Prenons un parc de 240 rapports encore ouverts sur douze mois. L’hypothèse retenue est de 144 rapports de restitution standard, à deux heures d’analyse et de reconstruction chacun, puis 96 rapports complexes, à six heures chacun. La reprise de ces seuls rapports représente 864 heures, soit 144 × 2 + 96 × 6.
Cette fourchette ne couvre ni la recette, ni la reprise des droits, ni la formation, ni la correction des anomalies découvertes après comparaison. En ajoutant une recette égale à 40 % de la reprise, le volume atteint 1 210 heures. Ce ratio de 40 % est une hypothèse de dimensionnement pour un parc où les règles sont partiellement documentées, pas une norme éditeur ni une promesse de charge.
- Les rapports ouverts moins de deux fois sur douze mois doivent être soumis à confirmation fonctionnelle avant d’entrer dans le périmètre.
- Les mesures utilisées dans plusieurs restitutions doivent être centralisées et documentées avant la reconstruction des écrans.
- Les rapports de clôture nécessitent une période de comparaison plus longue que les tableaux de bord quotidiens.
- Les flux d’alimentation doivent être traités séparément des rapports, car leur charge dépend des sources et des contrôles attendus.
Le volume des objets ne mesure donc pas le chantier à lui seul. La complexité réside dans les règles implicites, les exceptions et les usages qui n’apparaissent pas dans la liste des tables.
Comment la séparation du calcul et du stockage change-t-elle la performance ?
Le fonctionnement de Snowflake repose sur une distinction utile pour le décisionnel. Les données sont stockées séparément des entrepôts virtuels qui exécutent les requêtes. Un entrepôt virtuel est une ressource de calcul choisie pour un groupe de traitements, des chargements, des requêtes de reporting ou des travaux de préparation. Cette mécanique vise à limiter la concurrence directe entre usages, sous réserve que les équipes aient réellement isolé leurs charges.
La documentation Snowflake précise que les virtual warehouses sont les ressources de calcul utilisées pour exécuter les requêtes, les chargements et les autres opérations de données. Cette description a été relevée le 12 juin 2026 sur la documentation officielle relative aux entrepôts virtuels. Pour une cible décisionnelle, le point à retenir est opérationnel : un traitement de nuit n’a pas à partager exactement la même capacité qu’un tableau de bord consulté le matin.
Cette organisation est particulièrement défendable lorsqu’un socle actuel connaît deux problèmes simultanés. Les flux d’intégration allongent la fenêtre de nuit, tandis que les utilisateurs signalent des lenteurs à certaines heures. Dans cette situation, créer des ressources séparées pour les chargements et la restitution peut rendre les arbitrages plus lisibles. Le gain n’est toutefois pas acquis : il dépend de la taille retenue, des règles de suspension et du volume réel de requêtes.
La scalabilité ne remplace pas le réglage des requêtes
Augmenter la puissance de calcul face à toute lenteur reporte souvent le problème. Une requête qui joint une table de sinistres à une table de contrats sans condition de période ou de granularité peut consommer davantage de ressources sans produire un résultat plus fiable. Le travail préalable porte sur les clés, les filtres obligatoires, les doublons potentiels et la documentation des agrégats.
Les tables dynamiques de Snowflake introduisent une autre mécanique à examiner avec prudence. La documentation indique qu’une latence cible définit le retard maximal attendu entre une table dynamique et les données de base, sous réserve que le système puisse rafraîchir la table. Cette règle est présentée par l’éditeur dans la documentation sur les tables dynamiques, consultée le 12 juin 2026.
Une latence cible de cinq minutes ne constitue pas une garantie fonctionnelle qu’un chiffre sera toujours mis à jour dans les cinq minutes. Elle doit être confrontée à la fréquence des arrivées de données, aux dépendances entre transformations et à la tolérance métier. Pour un rapport de suivi de sinistres, le métier doit accepter explicitement la période de retard affichée. Pour une clôture mensuelle, la priorité portera davantage sur la traçabilité de la version chargée.
La couche de présentation conserve son rôle. Les utilisateurs n’interrogent pas une architecture, ils lisent des indicateurs, appliquent des filtres et exportent parfois des listes. Un modèle sémantique mal conçu au-dessus d’un entrepôt performant recréera les mêmes incohérences de vocabulaire que l’ancien univers. Le choix de Snowflake doit donc s’accompagner d’un dictionnaire de mesures et d’une gouvernance des objets exposés.
La séparation des ressources donne des moyens d’action, mais elle impose un suivi précis. Le sujet suivant est celui qui bloque le plus souvent les budgets : la facture n’est pas déterminée par le seul volume stocké.
Quel coût faut-il chiffrer avant de retenir Snowflake ?
Le coût d’une cible Snowflake ne se réduit pas à un prix de licence par utilisateur. Le modèle commercial repose notamment sur la consommation de crédits pour le calcul et sur le stockage, avec des paramètres qui dépendent de l’édition, de la région d’hébergement, de l’engagement souscrit et des conditions contractuelles. La présentation générale de ces éléments est accessible dans la documentation Snowflake sur les crédits, consultée le 12 juin 2026.
Un budget décisionnel doit séparer quatre postes. Le premier est la consommation des entrepôts virtuels pour les chargements et l’analyse de données. Le deuxième est le stockage des données et des copies. Le troisième couvre les outils de restitution, de catalogue ou d’intégration qui restent nécessaires autour de Snowflake. Le quatrième correspond à la charge de migration et de recette, qui ne relève pas du prix de la plateforme.
Cette séparation évite une confusion fréquente. Une consommation de calcul plus faible que prévu ne compense pas nécessairement une reprise de 240 rapports sous-estimée. Inversement, un chantier de migration bien borné n’empêche pas une dérive d’exploitation si les entrepôts restent actifs par défaut après le départ des utilisateurs.
Construire un scénario de consommation exploitable
Le calcul ci-dessous n’est pas un tarif Snowflake. Il illustre la méthode à imposer dans un dossier d’arbitrage. Supposons trois entrepôts virtuels, un pour les chargements, un pour la préparation des données et un pour la restitution. Le budget doit mesurer les heures réellement actives, la taille choisie, les règles d’auto-suspension, les pics mensuels et la durée conservée des données.
| Usage décisionnel | Hypothèse de fonctionnement | Indicateur de suivi | Décision de pilotage |
|---|---|---|---|
| Chargements des sources | Exécution nocturne avec relances exceptionnelles | Durée médiane et durée maximale par flux | Réduire la taille après stabilisation ou isoler les flux lourds |
| Préparation des tables | Transformations planifiées avant les heures de consultation | Crédits consommés par chaîne de traitement | Revoir les jointures et les dépendances avant d’augmenter le calcul |
| Restitution et exploration | Forte activité sur les plages de pilotage | Temps de réponse et durée active des entrepôts | Appliquer une auto-suspension adaptée aux usages réels |
| Recette de migration | Exécutions parallèles entre ancien et nouveau socle | Volume de requêtes de comparaison | Prévoir un budget distinct et temporaire pour le double run |
Le prix exact doit être relevé dans votre compte, votre devis ou votre grille contractuelle, car il dépend de paramètres commerciaux qui ne sont pas publics dans un format unique. Un tarif annoncé sans unité de consommation, sans édition et sans remise négociée ne peut pas être défendu. La documentation officielle indique le principe des crédits, mais elle ne remplace pas les conditions de votre souscription.
À votre place, un projet sans suivi quotidien des crédits pendant la recette ne serait pas validé. Il faut d’abord établir une ligne de base sur quelques flux représentatifs, puis projeter les pics de clôture et les périodes de double run. Une estimation annuelle faite avant ces mesures reste une hypothèse, non un engagement de coût.
Comment organiser la recette entre l’ancien socle et Snowflake ?
La bascule vers Snowflake ne doit jamais être conditionnée à l’idée que les chiffres seront identiques à ceux de l’ancien socle. Des écarts apparaissent parce que les règles étaient incomplètes, parce que les dates de chargement diffèrent, parce qu’un filtre était appliqué dans un univers ou parce qu’une hiérarchie n’a pas été reprise au même niveau. Le travail de recette consiste à mesurer ces écarts, à les expliquer et à les faire accepter.
Un protocole utile commence par un périmètre réduit. Il faut sélectionner les indicateurs de pilotage, les rapports de clôture, les extractions réglementaires et les restitutions les plus ouvertes sur douze mois. Chaque comparaison doit préciser la période, la date de rafraîchissement, les filtres, la granularité, le périmètre organisationnel et la source de chaque chiffre.
La comparaison ne se limite pas au chiffre total. Un chiffre d’affaires consolidé peut sembler correct alors que deux entités sont compensées par erreur. Une analyse par mois, société, segment, statut et canal est nécessaire pour identifier où l’écart apparaît. Cette démarche prend plus de temps qu’un contrôle global, mais elle évite une validation fondée sur une coïncidence d’agrégat.
Fixer des seuils d’écart avant le double run
Un seuil de tolérance doit être écrit par indicateur. Pour une mesure de volume alimentée par une source stable, une différence de 0,1 % peut imposer une investigation. Pour une mesure monétaire intégrant des arrondis ou des corrections de période, le seuil peut être différent. Aucun seuil ne doit être repris sans préciser le type de mesure, la période et les règles de calcul.
Un double run consiste à produire, pendant une période définie, les résultats de l’ancien socle et de la nouvelle cible décisionnelle. Il ne s’agit pas de faire tourner deux plateformes pour rassurer les équipes. Chaque écart doit alimenter un registre avec son identifiant, son propriétaire, son origine présumée, sa décision de correction ou d’acceptation, et la date de validation fonctionnelle.
- Extraire les logs d’usage sur douze mois et valider la liste des rapports inclus dans la recette.
- Documenter pour chaque indicateur le calcul, les filtres, la granularité et le calendrier de chargement.
- Rejouer les rapports prioritaires sur des périodes closes avant de tester les données courantes.
- Comparer les résultats par niveaux de détail jusqu’à localiser l’origine de chaque différence.
- Faire valider les écarts acceptés par le propriétaire fonctionnel avant toute bascule.
La sécurité des accès et les règles de conservation des données doivent être traitées avec les équipes compétentes. La documentation Snowflake décrit ses mécanismes d’administration et de contrôle d’accès, mais la conformité applicable à vos données relève de votre DPO, de votre RSSI et de vos responsables juridiques. Le périmètre traité ici s’arrête à la recette décisionnelle.
Avant d’engager le chantier, sortez les logs d’audit sur douze mois, classez les rapports par usage réel et faites comparer trois indicateurs de clôture sur une période déjà validée. Ce test révèle rapidement si Snowflake répond à un besoin de cible ou s’il masque un problème de gouvernance plus ancien.
Snowflake remplace-t-il directement BusinessObjects ?
Non. Snowflake sert de plateforme de stockage et de calcul pour le data warehouse. BusinessObjects comprend aussi des univers, des rapports Web Intelligence, des droits et des mécanismes de diffusion qui doivent être repris, reconstruits ou abandonnés selon leur usage réel.
Quand Snowflake ne se justifie-t-il pas pour une migration décisionnelle ?
La plateforme se justifie mal si le parc de rapports est réduit, peu consulté, stable et correctement servi par le socle existant. Dans ce cas, l’audit des usages et la reconstruction ciblée apportent souvent davantage qu’une reprise complète du data warehouse.
Comment surveiller le coût de Snowflake pendant la recette ?
Suivez séparément les crédits consommés par les chargements, les transformations, les requêtes de restitution et le double run. Les règles d’auto-suspension, la taille des entrepôts virtuels et les pics de clôture doivent être documentés dès les premières semaines de recette.
Les chiffres seront-ils identiques après la bascule ?
Ils peuvent présenter des écarts. La recette doit les mesurer par période et par granularité, identifier les filtres ou règles de gestion en cause, puis faire valider les écarts acceptés avant la mise en production.
Le dossier complet Chantiers de migration : chiffrer la charge et sécuriser la bascule
