Partie 1 – Quels concepts et bonnes pratiques permettent de construire un dashboard \u00e0 rafraichissement automatique?<\/strong><\/h2>\n\n\n\nCette section est une courte checklist des bonnes pratiques pour garantir que les donn\u00e9es utilis\u00e9es dans votre dashboard restent fiables et \u00e0 jour.
L\u2019objectif est simple: des donn\u00e9es correctes, fra\u00eeches, et exploitables \u00e0 chaque ouverture du dashboard, avec un minimum d\u2019effort op\u00e9rationnel.<\/p>\n\n\n\n
1) Comment d\u00e9finir ce que \u201cauto-actualis\u00e9\u201d signifie vraiment?<\/strong><\/h3>\n\n\n\nToutes les situations ne n\u00e9cessitent pas des donn\u00e9es en temps r\u00e9el. Il peut \u00eatre utile de vous poser les bonnes questions qui vous aideront \u00e0 d\u00e9finir ce que signifie vraiment \u201crafra\u00eechissement automatique\u201d dans votre contexte et \u00e0 choisir la bonne approche.<\/p>\n\n\n\n
\n- \u00c0 quelle fr\u00e9quence avez-vous r\u00e9ellement besoin que les donn\u00e9es soient mises \u00e0 jour?<\/strong>
Le dashboard doit-il afficher des donn\u00e9es \u00e0 la seconde pr\u00e8s, ou une mise \u00e0 jour quotidienne ou hebdomadaire suffit-elle?
Cela d\u00e9pend de l\u2019usage. Si votre dashboard sert \u00e0 suivre des performances mensuelles, hebdomadaires ou quotidiennes, un batch quotidien est largement suffisant. Le streaming en temps r\u00e9el n\u2019est n\u00e9cessaire que pour des usages tr\u00e8s sp\u00e9cifiques.<\/li>\n\n\n\n- Comment souhaitez-vous rafra\u00eechir les donn\u00e9es?<\/strong>
Souhaitez-vous recharger l\u2019ensemble du dataset \u00e0 chaque ex\u00e9cution, ou seulement les lignes nouvelles ou modifi\u00e9es?\n\n- L\u2019incremental load<\/a> est g\u00e9n\u00e9ralement plus rapide, moins co\u00fbteux et exerce moins de pression sur les syst\u00e8mes sources.<\/li>\n\n\n\n
- Le full reload est plus lent et plus co\u00fbteux, mais parfois utile lorsqu\u2019une reconstruction compl\u00e8te est n\u00e9cessaire.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
2) Comment mod\u00e9liser pour la durabilit\u00e9, et pas seulement pour aujourd\u2019hui?<\/strong><\/h3>\n\n\n\nTravaillez en couches pour garder chaque \u00e9tape simple et r\u00e9utilisable:<\/p>\n\n\n\n
\n- Raw<\/strong>: ingestion des donn\u00e9es telles quelles.<\/li>\n\n\n\n
- Transform<\/strong>: nettoyage minimal (types, nulls, normalisation, joins, pre-aggregations).<\/li>\n\n\n\n
- Presentation<\/strong>: dataset final d\u00e9normalis\u00e9, pr\u00eat pour le dashboard.<\/li>\n<\/ul>\n\n\n\n
Pour une architecture robuste, pensez aussi \u00e0:<\/p>\n\n\n\n
\n- Indexing<\/strong>: choisissez une cl\u00e9 primaire fiable (ou cr\u00e9ez-en une).<\/li>\n\n\n\n
- Slowly Changing Dimensions (SCD)<\/strong>: si vos sources r\u00e9\u00e9crivent l\u2019historique, utilisez created_ts \/ updated_ts + soft delete.<\/li>\n\n\n\n
- Pre-aggregations<\/strong>: regrouper par jour \/ r\u00e9gion \/ cat\u00e9gorie r\u00e9duit fortement le co\u00fbt et la variabilit\u00e9 des queries.<\/li>\n<\/ul>\n\n\n\n
3) Comment rendre votre pipeline de refresh idempotent?<\/strong><\/h3>\n\n\n\nUn pipeline \u00e0 rafraichissement automatique doit pouvoir rerun proprement, sans dupliquer ni casser quoi que ce soit.<\/p>\n\n\n\n
Pour cela:<\/p>\n\n\n\n
\n- Inputs d\u00e9terministes<\/strong> : Utilisez un champ updated_since ou une fen\u00eatre de 24\u201348 h pour g\u00e9rer les retards d\u2019arriv\u00e9e des donn\u00e9es.<\/li>\n\n\n\n
- Merges<\/strong> : Faites des upserts sur les cl\u00e9s uniques au lieu d\u2019append-only.
Si un run \u00e9choue, relancer ne doit pas cr\u00e9er de doublons.<\/li>\n\n\n\n- Outputs atomiques<\/strong> : \u00c9crivez d\u2019abord dans une table temporaire, puis remplacez la table finale seulement si tout a r\u00e9ussi.<\/li>\n\n\n\n
- Retries<\/strong> : Essentiel pour les APIs sujettes aux timeouts ou quotas.<\/li>\n<\/ul>\n\n\n\n
4) Comment g\u00e9rer les contr\u00f4les de qualit\u00e9 et les alertes?<\/strong><\/h3>\n\n\n\nLa qualit\u00e9 des donn\u00e9es doit \u00eatre v\u00e9rifi\u00e9e d\u00e8s le d\u00e9but du pipeline. Pour cela, posez-vous les bonnes questions \u00e0 chaque \u00e9tape.<\/p>\n\n\n\n
\n- Contr\u00f4les de volume<\/strong> : Est-ce que le nombre de lignes attendu est toujours sup\u00e9rieur \u00e0 0? Comment \u00e9voluent les moyennes mobiles? Une baisse soudaine peut r\u00e9v\u00e9ler un flux partiel. <\/li>\n\n\n\n
- Contr\u00f4les de sch\u00e9ma<\/strong> : Est-ce que les noms de colonnes ou les types peuvent changer? Que doit-il se passer si une nouvelle colonne appara\u00eet dans la source?<\/li>\n\n\n\n
- R\u00e8gles m\u00e9tier<\/strong> : Le conversion rate peut-il \u00eatre n\u00e9gatif? Est-il normal que le revenu tombe soudainement \u00e0 0%?<\/li>\n\n\n\n
- Alertes actionnables<\/strong> : Les alertes doivent \u00eatre envoy\u00e9es au bon canal, avec suffisamment de contexte pour diagnostiquer rapidement: dataset concern\u00e9, \u00e9tape, run ID, derni\u00e8re ex\u00e9cution r\u00e9ussie, et un lien pour investiguer.<\/li>\n<\/ul>\n\n\n\n
5) Documentation<\/strong><\/h3>\n\n\n\n\n- Documentez clairement les transformations du mini-pipeline qui alimente votre dashboard.<\/li>\n\n\n\n
- Pensez \u00e0 ajouter un fichier README.md<\/strong> pour capturer des informations plus d\u00e9taill\u00e9es comme la data lineage<\/em>, les param\u00e8tres utilis\u00e9s ou toute logique sp\u00e9cifique.<\/li>\n<\/ul>\n\n\n\n
6) Prendre en compte la performance et le co\u00fbt<\/strong><\/h3>\n\n\n\n\n- Privil\u00e9giez les incremental<\/em> ou delta loads<\/em> plut\u00f4t que les full refreshes<\/em> lorsque c\u2019est possible.
Ces approches ne chargent que les donn\u00e9es mises \u00e0 jour, au lieu de recharger l\u2019ensemble du dataset.<\/li>\n\n\n\n- \u00c9vitez une fr\u00e9quence de rafra\u00eechissement trop \u00e9lev\u00e9e si elle n\u2019est pas n\u00e9cessaire.<\/li>\n\n\n\n
- Limitez les joins trop volumineux ainsi que les colonnes texte tr\u00e8s larges dans la couche Presentation<\/em>.<\/li>\n\n\n\n
- Surveillez l\u2019historique des refresh et les taux d\u2019\u00e9chec pour d\u00e9tecter les d\u00e9rives ou fragilit\u00e9s du pipeline.<\/li>\n<\/ul>\n\n\n\n
Partie 2 \u2013 Walkthrough des fonctionnalit\u00e9s ClicData<\/strong><\/h2>\n\n\n\nVoyons maintenant comment utiliser certaines fonctionnalit\u00e9s cl\u00e9s de ClicData en construisant un data pipeline structur\u00e9 (pr\u00e9sent\u00e9 ici sur un jeu de donn\u00e9es simplifi\u00e9 pour l’exemple) qui sera visualis\u00e9 dans un dashboard et se rafra\u00eechira automatiquement.<\/p>\n\n\n\n
Les donn\u00e9es factices incluent :<\/p>\n\n\n\n
\n- commandes<\/strong> : d\u00e9tails de commande (date, produits, quantit\u00e9, prix)<\/li>\n\n\n\n
- clients<\/strong> : r\u00e9gion, segment\/type<\/li>\n\n\n\n
- produits<\/strong> : cat\u00e9gorie, marque<\/li>\n\n\n\n
- d\u00e9penses marketing<\/strong> : spend_date, canal, montant<\/li>\n<\/ul>\n\n\n\n
![\"\"](\"https:\/\/www.clicdata.com\/wp-content\/uploads\/2025\/09\/clicdata-landing-page-3100631.webp\")
ClicData<\/a><\/figcaption><\/figure>\n<\/div>\n\n\n\u00c9tape 1 : Connecter les sources de donn\u00e9es<\/strong><\/h3>\n\n\n\nAjoutez chaque source comme dataset. ClicData propose de nombreux connecteurs (API, fichiers, spreadsheets, OData, bases de donn\u00e9es).
Dans cet exemple, nous avons ajout\u00e9: orders.csv<\/strong>, customers.csv<\/strong>, products.csv<\/strong>, marketing.csv<\/strong>.<\/p>\n\n\n\nConseils<\/strong><\/p>\n\n\n\n\n- Normalisez les types de datas d\u00e8s l\u2019ingestion (dates, nombres).<\/li>\n\n\n\n
- Pour les APIs, identifiez les param\u00e8tres n\u00e9cessaires (pagination, p\u00e9riodes).<\/li>\n\n\n\n
- Pour les fichiers, verrouillez la structure des onglets pour \u00e9viter les ruptures en aval.<\/li>\n<\/ul>\n\n\n\n
![\"\"](\"https:\/\/www.clicdata.com\/wp-content\/uploads\/2025\/09\/connectors-available-on-clicdata-3100631.webp\")
De nombreuses connexions<\/a> tierces sont disponibles en natif dans ClicData<\/figcaption><\/figure>\n<\/div>\n\n\n\u00c9tape 2 : Construire un Data Flow pour les transformations<\/strong><\/h3>\n\n\n\nCr\u00e9ez un Data Flow avec quatre inputs : commandes, clients, produits, marketing.<\/p>\n\n\n\n
Les \u00e9tapes typiques incluent :<\/p>\n\n\n\n
\n- Nettoyage<\/strong> : cast des types, trim des textes, standardisation des statuts<\/li>\n\n\n\n
- Enrichissement<\/strong> : joins entre les datasets<\/li>\n\n\n\n
- Agr\u00e9gation<\/strong> : calcul de m\u00e9triques quotidiennes (revenue, nombre de commandes)<\/li>\n\n\n\n
- Sortie<\/strong> : d\u00e9finition des tables finales<\/li>\n<\/ul>\n\n\n\n
![\"\"](\"https:\/\/www.clicdata.com\/wp-content\/uploads\/2025\/09\/data-flow-clicdata-3100631-1024x540.webp\")
<\/a>Data Flows dans ClicData sont parfaits pour visualiser le mouvement des data vers le dashboard<\/figcaption><\/figure>\n\n\n\n\u00c9tape 3 : Orchestrer avec un planning quotidien<\/strong><\/h3>\n\n\n\nCr\u00e9ez un calendrier unique qui ex\u00e9cute les t\u00e2ches dans le bon ordre :<\/p>\n\n\n\n
\n- Rafra\u00eechissement des sources en mode incremental<\/li>\n\n\n\n
- Recalcul des transformations<\/li>\n\n\n\n
- Mise \u00e0 jour de la table finale utilis\u00e9e par le dashboard<\/li>\n\n\n\n
- Ajout de notifications (email\/Slack\/webhook) et d\u2019une simple retry policy<\/li>\n<\/ul>\n\n\n\n
L\u2019objectif est simple: des donn\u00e9es correctes, fra\u00eeches, et exploitables \u00e0 chaque ouverture du dashboard, avec un minimum d\u2019effort op\u00e9rationnel.<\/p>\n\n\n\n
Toutes les situations ne n\u00e9cessitent pas des donn\u00e9es en temps r\u00e9el. Il peut \u00eatre utile de vous poser les bonnes questions qui vous aideront \u00e0 d\u00e9finir ce que signifie vraiment \u201crafra\u00eechissement automatique\u201d dans votre contexte et \u00e0 choisir la bonne approche.<\/p>\n\n\n\n
- \n
- \u00c0 quelle fr\u00e9quence avez-vous r\u00e9ellement besoin que les donn\u00e9es soient mises \u00e0 jour?<\/strong>
Le dashboard doit-il afficher des donn\u00e9es \u00e0 la seconde pr\u00e8s, ou une mise \u00e0 jour quotidienne ou hebdomadaire suffit-elle?
Cela d\u00e9pend de l\u2019usage. Si votre dashboard sert \u00e0 suivre des performances mensuelles, hebdomadaires ou quotidiennes, un batch quotidien est largement suffisant. Le streaming en temps r\u00e9el n\u2019est n\u00e9cessaire que pour des usages tr\u00e8s sp\u00e9cifiques.<\/li>\n\n\n\n- Comment souhaitez-vous rafra\u00eechir les donn\u00e9es?<\/strong>
Souhaitez-vous recharger l\u2019ensemble du dataset \u00e0 chaque ex\u00e9cution, ou seulement les lignes nouvelles ou modifi\u00e9es?\n- \n
- L\u2019incremental load<\/a> est g\u00e9n\u00e9ralement plus rapide, moins co\u00fbteux et exerce moins de pression sur les syst\u00e8mes sources.<\/li>\n\n\n\n
- Le full reload est plus lent et plus co\u00fbteux, mais parfois utile lorsqu\u2019une reconstruction compl\u00e8te est n\u00e9cessaire.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
2) Comment mod\u00e9liser pour la durabilit\u00e9, et pas seulement pour aujourd\u2019hui?<\/strong><\/h3>\n\n\n\n
Travaillez en couches pour garder chaque \u00e9tape simple et r\u00e9utilisable:<\/p>\n\n\n\n
- \n
- Raw<\/strong>: ingestion des donn\u00e9es telles quelles.<\/li>\n\n\n\n
- Transform<\/strong>: nettoyage minimal (types, nulls, normalisation, joins, pre-aggregations).<\/li>\n\n\n\n
- Presentation<\/strong>: dataset final d\u00e9normalis\u00e9, pr\u00eat pour le dashboard.<\/li>\n<\/ul>\n\n\n\n
Pour une architecture robuste, pensez aussi \u00e0:<\/p>\n\n\n\n
- \n
- Indexing<\/strong>: choisissez une cl\u00e9 primaire fiable (ou cr\u00e9ez-en une).<\/li>\n\n\n\n
- Slowly Changing Dimensions (SCD)<\/strong>: si vos sources r\u00e9\u00e9crivent l\u2019historique, utilisez created_ts \/ updated_ts + soft delete.<\/li>\n\n\n\n
- Pre-aggregations<\/strong>: regrouper par jour \/ r\u00e9gion \/ cat\u00e9gorie r\u00e9duit fortement le co\u00fbt et la variabilit\u00e9 des queries.<\/li>\n<\/ul>\n\n\n\n
3) Comment rendre votre pipeline de refresh idempotent?<\/strong><\/h3>\n\n\n\n
Un pipeline \u00e0 rafraichissement automatique doit pouvoir rerun proprement, sans dupliquer ni casser quoi que ce soit.<\/p>\n\n\n\n
Pour cela:<\/p>\n\n\n\n
- \n
- Inputs d\u00e9terministes<\/strong> : Utilisez un champ updated_since ou une fen\u00eatre de 24\u201348 h pour g\u00e9rer les retards d\u2019arriv\u00e9e des donn\u00e9es.<\/li>\n\n\n\n
- Merges<\/strong> : Faites des upserts sur les cl\u00e9s uniques au lieu d\u2019append-only.
Si un run \u00e9choue, relancer ne doit pas cr\u00e9er de doublons.<\/li>\n\n\n\n- Outputs atomiques<\/strong> : \u00c9crivez d\u2019abord dans une table temporaire, puis remplacez la table finale seulement si tout a r\u00e9ussi.<\/li>\n\n\n\n
- Retries<\/strong> : Essentiel pour les APIs sujettes aux timeouts ou quotas.<\/li>\n<\/ul>\n\n\n\n
4) Comment g\u00e9rer les contr\u00f4les de qualit\u00e9 et les alertes?<\/strong><\/h3>\n\n\n\n
La qualit\u00e9 des donn\u00e9es doit \u00eatre v\u00e9rifi\u00e9e d\u00e8s le d\u00e9but du pipeline. Pour cela, posez-vous les bonnes questions \u00e0 chaque \u00e9tape.<\/p>\n\n\n\n
- \n
- Contr\u00f4les de volume<\/strong> : Est-ce que le nombre de lignes attendu est toujours sup\u00e9rieur \u00e0 0? Comment \u00e9voluent les moyennes mobiles? Une baisse soudaine peut r\u00e9v\u00e9ler un flux partiel. <\/li>\n\n\n\n
- Contr\u00f4les de sch\u00e9ma<\/strong> : Est-ce que les noms de colonnes ou les types peuvent changer? Que doit-il se passer si une nouvelle colonne appara\u00eet dans la source?<\/li>\n\n\n\n
- R\u00e8gles m\u00e9tier<\/strong> : Le conversion rate peut-il \u00eatre n\u00e9gatif? Est-il normal que le revenu tombe soudainement \u00e0 0%?<\/li>\n\n\n\n
- Alertes actionnables<\/strong> : Les alertes doivent \u00eatre envoy\u00e9es au bon canal, avec suffisamment de contexte pour diagnostiquer rapidement: dataset concern\u00e9, \u00e9tape, run ID, derni\u00e8re ex\u00e9cution r\u00e9ussie, et un lien pour investiguer.<\/li>\n<\/ul>\n\n\n\n
5) Documentation<\/strong><\/h3>\n\n\n\n
- \n
- Documentez clairement les transformations du mini-pipeline qui alimente votre dashboard.<\/li>\n\n\n\n
- Pensez \u00e0 ajouter un fichier README.md<\/strong> pour capturer des informations plus d\u00e9taill\u00e9es comme la data lineage<\/em>, les param\u00e8tres utilis\u00e9s ou toute logique sp\u00e9cifique.<\/li>\n<\/ul>\n\n\n\n
6) Prendre en compte la performance et le co\u00fbt<\/strong><\/h3>\n\n\n\n
- \n
- Privil\u00e9giez les incremental<\/em> ou delta loads<\/em> plut\u00f4t que les full refreshes<\/em> lorsque c\u2019est possible.
Ces approches ne chargent que les donn\u00e9es mises \u00e0 jour, au lieu de recharger l\u2019ensemble du dataset.<\/li>\n\n\n\n- \u00c9vitez une fr\u00e9quence de rafra\u00eechissement trop \u00e9lev\u00e9e si elle n\u2019est pas n\u00e9cessaire.<\/li>\n\n\n\n
- Limitez les joins trop volumineux ainsi que les colonnes texte tr\u00e8s larges dans la couche Presentation<\/em>.<\/li>\n\n\n\n
- Surveillez l\u2019historique des refresh et les taux d\u2019\u00e9chec pour d\u00e9tecter les d\u00e9rives ou fragilit\u00e9s du pipeline.<\/li>\n<\/ul>\n\n\n\n
Partie 2 \u2013 Walkthrough des fonctionnalit\u00e9s ClicData<\/strong><\/h2>\n\n\n\n
Voyons maintenant comment utiliser certaines fonctionnalit\u00e9s cl\u00e9s de ClicData en construisant un data pipeline structur\u00e9 (pr\u00e9sent\u00e9 ici sur un jeu de donn\u00e9es simplifi\u00e9 pour l’exemple) qui sera visualis\u00e9 dans un dashboard et se rafra\u00eechira automatiquement.<\/p>\n\n\n\n
Les donn\u00e9es factices incluent :<\/p>\n\n\n\n
- \n
- commandes<\/strong> : d\u00e9tails de commande (date, produits, quantit\u00e9, prix)<\/li>\n\n\n\n
- clients<\/strong> : r\u00e9gion, segment\/type<\/li>\n\n\n\n
- produits<\/strong> : cat\u00e9gorie, marque<\/li>\n\n\n\n
- d\u00e9penses marketing<\/strong> : spend_date, canal, montant<\/li>\n<\/ul>\n\n\n
\nClicData<\/a><\/figcaption><\/figure>\n<\/div>\n\n\n \u00c9tape 1 : Connecter les sources de donn\u00e9es<\/strong><\/h3>\n\n\n\n
Ajoutez chaque source comme dataset. ClicData propose de nombreux connecteurs (API, fichiers, spreadsheets, OData, bases de donn\u00e9es).
Dans cet exemple, nous avons ajout\u00e9: orders.csv<\/strong>, customers.csv<\/strong>, products.csv<\/strong>, marketing.csv<\/strong>.<\/p>\n\n\n\nConseils<\/strong><\/p>\n\n\n\n
- \n
- Normalisez les types de datas d\u00e8s l\u2019ingestion (dates, nombres).<\/li>\n\n\n\n
- Pour les APIs, identifiez les param\u00e8tres n\u00e9cessaires (pagination, p\u00e9riodes).<\/li>\n\n\n\n
- Pour les fichiers, verrouillez la structure des onglets pour \u00e9viter les ruptures en aval.<\/li>\n<\/ul>\n\n\n\n
De nombreuses connexions<\/a> tierces sont disponibles en natif dans ClicData<\/figcaption><\/figure>\n<\/div>\n\n\n \u00c9tape 2 : Construire un Data Flow pour les transformations<\/strong><\/h3>\n\n\n\n
Cr\u00e9ez un Data Flow avec quatre inputs : commandes, clients, produits, marketing.<\/p>\n\n\n\n
Les \u00e9tapes typiques incluent :<\/p>\n\n\n\n
- \n
- Nettoyage<\/strong> : cast des types, trim des textes, standardisation des statuts<\/li>\n\n\n\n
- Enrichissement<\/strong> : joins entre les datasets<\/li>\n\n\n\n
- Agr\u00e9gation<\/strong> : calcul de m\u00e9triques quotidiennes (revenue, nombre de commandes)<\/li>\n\n\n\n
- Sortie<\/strong> : d\u00e9finition des tables finales<\/li>\n<\/ul>\n\n\n\n
<\/a>Data Flows dans ClicData sont parfaits pour visualiser le mouvement des data vers le dashboard<\/figcaption><\/figure>\n\n\n\n \u00c9tape 3 : Orchestrer avec un planning quotidien<\/strong><\/h3>\n\n\n\n
Cr\u00e9ez un calendrier unique qui ex\u00e9cute les t\u00e2ches dans le bon ordre :<\/p>\n\n\n\n
- \n
- Rafra\u00eechissement des sources en mode incremental<\/li>\n\n\n\n
- Recalcul des transformations<\/li>\n\n\n\n
- Mise \u00e0 jour de la table finale utilis\u00e9e par le dashboard<\/li>\n\n\n\n
- Ajout de notifications (email\/Slack\/webhook) et d\u2019une simple retry policy<\/li>\n<\/ul>\n\n\n\n
- Enrichissement<\/strong> : joins entre les datasets<\/li>\n\n\n\n
- Nettoyage<\/strong> : cast des types, trim des textes, standardisation des statuts<\/li>\n\n\n\n
- clients<\/strong> : r\u00e9gion, segment\/type<\/li>\n\n\n\n
- Privil\u00e9giez les incremental<\/em> ou delta loads<\/em> plut\u00f4t que les full refreshes<\/em> lorsque c\u2019est possible.
- Contr\u00f4les de sch\u00e9ma<\/strong> : Est-ce que les noms de colonnes ou les types peuvent changer? Que doit-il se passer si une nouvelle colonne appara\u00eet dans la source?<\/li>\n\n\n\n
- Merges<\/strong> : Faites des upserts sur les cl\u00e9s uniques au lieu d\u2019append-only.
- Slowly Changing Dimensions (SCD)<\/strong>: si vos sources r\u00e9\u00e9crivent l\u2019historique, utilisez created_ts \/ updated_ts + soft delete.<\/li>\n\n\n\n
- Transform<\/strong>: nettoyage minimal (types, nulls, normalisation, joins, pre-aggregations).<\/li>\n\n\n\n
- Le full reload est plus lent et plus co\u00fbteux, mais parfois utile lorsqu\u2019une reconstruction compl\u00e8te est n\u00e9cessaire.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
- Comment souhaitez-vous rafra\u00eechir les donn\u00e9es?<\/strong>