prof404
← Retour aux ressources du module
Sommaire (5 sections) · 11 min
Ce que tu travailles iciTableaux de bord et visualisationPourquoi ces compétences ?
  • BC06Tableaux de bord et visualisation. Construire des tableaux de bord qu'une personne du métier peut lire seule, et en tirer des recommandations.

Ce sont les compétences du titre RNCP 38616, celles sur lesquelles le jury évalue.

Rafraîchir une source BI et garder sa trace

Ton graphique montre seulement RJ et SP alors que la requête contient maintenant MG, RJ et SP. Le nouvel export existe. L'écran utilise-t-il encore l'ancien fichier, ou un filtre masque-t-il MG ? Pour trouver où la mise à jour s'est arrêtée, tu as besoin d'une trace à chaque étape.

Cette fiche travaille la préparation de rapports automatisés du BC06. Un rafraîchissement est le chargement d'une nouvelle version de la source dans l'outil de BIBusiness Intelligence : transformer des données brutes en tableaux de bord lisibles par des gens qui ne font pas de SQL., pour business intelligenceL'ensemble des outils et méthodes qui transforment des données brutes en tableaux de bord lisibles par des gens qui ne font pas de SQL.. Il ne prouve pas à lui seul que la requête, le fichier et l'écran portent la même version.

Le geste enseigné ici est un rafraîchissement manuel contrôlé. Il fonctionne avec un CSV et ne dépend pas d'un compte professionnel ni d'un service planifié. L'automatisation de l'horaire, des accès et des alertes reste une capacité à préparer avec l'équipe une fois l'outil et l'infrastructure arbitrés.

Ce qui bloque Ce que tu travailles ici
L'écran ne montre pas le nouveau périmètre Sections « Comparer deux versions » et « Localiser l'arrêt »
Tu dois rendre une mise à jour vérifiable Section « Écrire une fiche de rafraîchissement »
Tu veux vérifier que tu peux refaire le geste ailleurs « Transfert autonome »

Comparer deux versions de la même source

Dans la table geolocation, une ligne source associe un préfixe de code postal à des coordonnées, une ville et un État. Des lignes peuvent répéter ces mêmes informations. Ici, on compte les lignes conservées dans la source, sans retirer les répétitions : ce n'est ni un nombre de lieux distincts ni un nombre de codes postaux distincts.

Cette requête regroupe les lignes de géolocalisation limitées à RJ et SP. Dans son résultat, une ligne représente un État ; lignes_source est le nombre de lignes comptées pour cet État :

SQL
SELECT geolocation_state AS etat,
       COUNT(*) AS lignes_source
FROM geolocation
WHERE geolocation_state IN ('RJ', 'SP')
GROUP BY 1
ORDER BY 1;

Le résultat complet contient deux lignes : RJ | 121169 et SP | 404268. Le bac à sable affiche au maximum 200 lignes ; les deux lignes sont donc visibles ici sans troncature.

Le périmètre demandé inclut ensuite MG. Avant d'exécuter la nouvelle version, prédis les deux changements attendus dans sa forme : nombre de lignes et nouvel État présent.

SQL
SELECT geolocation_state AS etat,
       COUNT(*) AS lignes_source
FROM geolocation
WHERE geolocation_state IN ('MG', 'RJ', 'SP')
GROUP BY 1
ORDER BY 1;

La seconde version contient trois lignes. Elle ajoute MG | 126336 sans modifier les valeurs de RJ et SP. Ces repères permettent de reconnaître la version chargée sans se fier au nom du fichier.

Écrire une fiche de rafraîchissement

À côté du CSV, crée bi/exports/suivi-geolocalisation.md et remplis ces champs :

source : nombre de lignes de géolocalisation par État, répétitions conservées
population : lignes dont l’État est MG, RJ ou SP
maille : une ligne par État
requête : bi/02_requetes.sql, commentaire suivi_geolocalisation
export : bi/exports/suivi-geolocalisation.csv
produit le : date et heure avec fuseau
contrôle source : 3 lignes de résultat, MG présent avec 126336 lignes source
contrôle total : 651773 lignes source
outil BI rafraîchi le : date et heure avec fuseau
contrôle écran : États affichés et somme de lignes_source, sans filtre supplémentaire

La maille décrit ce qu'une ligne représente. Le fuseau précise à quelle heure locale correspond l'horodatage. Le total ne se déduit pas des trois valeurs recopiées à la main : exécute un contrôle séparé.

SQL
SELECT COUNT(DISTINCT geolocation_state) AS etats,
       COUNT(*) AS lignes_source
FROM geolocation
WHERE geolocation_state IN ('MG', 'RJ', 'SP');

Le contrôle renvoie 3 | 651773. Il vérifie la forme et le total, sans refaire le graphique.

Localiser l'arrêt de la mise à jour

Procède dans cet ordre. Après chaque étape, écris le repère observé dans la fiche de rafraîchissement.

  1. Exécute la requête enregistrée et vérifie trois lignes, MG présent et 651 773 lignes source au total, avec la requête de contrôle séparée.
  2. Exporte le résultat par État, pas la ligne du contrôle total. Rouvre le CSV avec un lecteur de tableau et vérifie l'en-tête, les trois lignes et la présence de MG. Compter les retours à la ligne dans un fichier CSV n'est pas un contrôle fiable si une cellule peut elle-même contenir un retour à la ligne.
  3. Remplace la source utilisée par l'outil, puis déclenche son actualisation manuelle. Si l'outil retenu est Looker Studio avec Google Sheets, remplace les données de la feuille et actualise les données du rapport. Si Power BI Desktop est retenu, remplace le CSV au même emplacement puis utilise « Actualiser ».
  4. Note les filtres actifs, puis retire ceux qui restreignent le périmètre de ce contrôle. Affiche un tableau avec etat et la somme de lignes_source : MG doit apparaître, et le total du périmètre doit être 651 773. Compter les lignes du CSV donne le nombre d'États, pas le total des lignes source.

Si la requête contient MG mais pas le CSV, l'arrêt est entre requête et export. Si le CSV contient MG mais pas l'écran, relève le fichier ou la feuille réellement utilisé, puis contrôle son actualisation et les filtres. Un filtre resté sur RJ et SP peut masquer MG dans une source pourtant à jour. L'absence de MG ne suffit donc pas à conclure que l'ancien fichier est encore chargé.

Modification guidée

Copie la seconde requête et ajoute ES au périmètre. Ajoute aussi ES dans la requête de contrôle séparée pour comparer le même ensemble. Avant l'exécution, modifie la fiche de contrôle avec des cases vides pour le nombre d'États, la nouvelle ligne et le total. Exécute, complète les trois repères, exporte le résultat par État, puis actualise l'écran.

Pour vérifier ton travail, compare la liste des États dans la requête, le CSV et l'écran. Les trois doivent être identiques. Compare ensuite le total calculé par une requête de contrôle au total affiché. En cas d'écart, note la première étape où les valeurs divergent avant de modifier le graphique.

Si le nouvel État manque encore à l'écran

Ouvre le CSV exporté et cherche la ligne ES. Si elle manque, reviens à la requête enregistrée et à son export. Si elle est présente, note le nom et l'emplacement de la source réellement utilisée par l'écran, puis compare-les au fichier que tu viens d'ouvrir. Déclenche ensuite le rafraîchissement. Si ES reste absent, note puis retire les filtres du tableau de contrôle. Observe après chaque geste : lequel fait réapparaître ES ? Consigne ce geste et le résultat, sans attribuer tous les écarts à une source ancienne.

Transfert autonome : deux versions d'un suivi quotidien

Ce jeu est synthétique : il sert seulement à provoquer puis localiser un arrêt de rafraîchissement. Une ligne représente le nombre de demandes reçues pour une date et un canal. demandes est un flux du jour, pas un cumul depuis le début. Une même paire date,canal ne doit donc apparaître qu'une fois.

Crée suivi_v1.csv en UTF-8, avec des virgules comme séparateurs :

date,canal,demandes
2026-08-03,email,12
2026-08-03,telephone,5
2026-08-04,email,9
2026-08-04,telephone,7

Importe cette version dans l'outil de ton choix : outil BI, tableur ou lecteur de CSV capable d'afficher un tableau. Affiche les trois colonnes, sans filtre, avec une ligne par paire date,canal. Note dans une fiche de trace le nom du fichier chargé, sa maille, sa période, son nombre de lignes et ses canaux.

La version suivante remplace entièrement la première. Elle n'est pas à ajouter sous suivi_v1.csv, sinon les jours déjà présents seraient comptés deux fois. Crée suivi_v2.csv, mais ne l'importe pas encore :

date,canal,demandes
2026-08-03,email,12
2026-08-03,telephone,5
2026-08-04,email,9
2026-08-04,telephone,7
2026-08-05,email,14
2026-08-05,telephone,6
2026-08-05,chat,4

Lis les deux CSV, puis annonce avant l'import :

  1. le nombre de lignes que l'écran devra afficher avec la version 2 ;
  2. la dernière date qu'il devra couvrir ;
  3. le canal qui devra apparaître pour la première fois ;
  4. le symptôme attendu si l'écran garde la version 1.

Vérifie l'unicité de la paire date,canal, puis remplace la source chargée par la version 2 et déclenche son rafraîchissement. Complète la trace avec les repères observés dans le CSV et dans l'écran.

Ouvrir l'aide après ta prédiction

Compare d'abord la liste des dates et des canaux, puis le nombre de lignes. La nouvelle version doit faire apparaître une date et un canal absents de la première. Si le CSV les contient mais pas l'écran, l'arrêt se situe après le fichier : source sélectionnée, actualisation ou filtre de l'écran.

Provoquer la panne

Recharge volontairement suivi_v1.csv et garde son tableau affiché. Ouvre ensuite suivi_v2.csv à côté, sans remplacer la source affichée et sans cliquer sur l'actualisation. Cet écart est observable sans logiciel BI : le fichier courant et le tableau affiché ne portent pas la même dernière date, les mêmes canaux ni le même nombre de lignes. Ce repli vérifie la comparaison des versions et la trace ; seul un outil BI avec une source connectée permet de pratiquer son actualisation.

Donne seulement les deux CSV, la capture ou l'export du tableau resté sur la version 1, et ta fiche de trace à une autre personne. Elle doit pouvoir nommer la version affichée et la première étape divergente. Corrige ensuite la panne, actualise la trace et demande-lui de refaire le contrôle. Si elle a besoin de ton historique oral, ajoute à la fiche le repère qui manquait.

Un export récent peut contenir les mêmes anciennes données

Reprends suivi_v2.csv sans changer ses lignes. Dans ce scénario fictif, l’export et l’actualisation portent la date du 9 septembre 2026 ; ce n’est pas une date relevée sur ton fichier. Une note annonce : « Rapport actualisé le 9 septembre, données jusqu’au 9 septembre. »

Avant d’ouvrir la vérification, repère dans le CSV la première et la dernière date observées. Quelle partie de la note peux-tu conserver selon le scénario ? Réécris la phrase sans promettre une couverture que les lignes ne démontrent pas. Un nouvel export des mêmes lignes changerait-il ta réponse ?

Comparer l’actualisation et les dates observées

Le CSV contient sept lignes, datées du 3 au 5 août 2026. Tu peux écrire : « Actualisation du 9 septembre selon le scénario ; dates observées dans la source : du 3 au 5 août. » Le fichier ne contient aucune observation de septembre. Le réexporter sans changer ses lignes n’en ajoute pas.

La dernière date observée ne prouve pas non plus que toutes les demandes jusqu’à cette date ont été collectées. Pour conclure sur la couverture, il faudrait la comparer à la période attendue et contrôler la collecte.

Dans ta fiche de trace, sépare export produit le, écran actualisé le et dates observées dans la source. Garde à côté la période attendue et le contrôle de collecte, ou indique qu’ils restent à confirmer. La date d’une opération ne remplace pas ces contrôles.

À la fin de la leçon

Le quiz de la leçon

Choisis une réponse, puis lis l’explication avant de continuer.

  • 6 questions
  • 3 min par question
  • Une explication après chaque réponse

Le chrono démarre à la première question. Un clic sur une réponse valide ton choix.